FR
live
AI

Tencent ships Hy4 preview, a 770-billion-parameter open model aimed at code and finance

On August 28, 2026, Tencent posted Hy4 preview to Hugging Face: a mixture-of-experts model with 770 billion parameters, only 49 billion of which activate per request, tuned for software engineering, research and finance. The headline is not the size — it is that open weights are now a distribution channel.

A wall of identical dark server cabinets, one single amber LED lit among thousands of dark slots.

August 28, 2026. Tencent posts Hy4 preview to Hugging Face, with open weights. April 2026. The company had launched Hunyuan 3.0, its first major release since hiring former OpenAI researcher Yao Shunyu to lead its AI platform. August 28, 2026, again. Reuters confirms the model will be integrated into Tencent’s CodeBuddy and WorkBuddy products. In six months the Chinese giant has changed register: it is no longer just selling models — it is shipping open weights to equip its own tools.

What Hy4 preview brings to the table

Hy4 preview is a large language model built on a mixture-of-experts (MoE) architecture with 770 billion parameters in total. The number is striking, but the second line matters more: only about 49 billion parameters are active for any given request. That gap between theoretical capacity and real inference cost is what decides whether a model is viable in production.

The positioning is explicit in the announcement: the model targets three workloadssoftware engineering, research and financial analysis. This is not another general-purpose chatbot. It is a model aimed at professional tasks, designed to plug into concrete workflows: generating and fixing code, synthesizing technical documentation, processing financial data.

The announcement also concedes two limits: the model “can sometimes take longer than necessary to work through complex questions” and “may over-verify its own answers.” In plain terms, Tencent is signaling that the preview favors caution over speed — a sensible tradeoff for domains where an error is expensive, but one that has to be tuned before any real integration.

Why “770 billion, 49 billion active” changes the economics

The 770/49 ratio is the real news in the announcement. A dense model with 770 billion parameters would be out of reach for most inference infrastructure. A MoE model computes only a fraction of its experts per token: you get part of the capacity of a very large model for a fraction of the per-request cost. It is the same architectural bet as the recent open-weight releases from Chinese labs — a convergence that is anything but incidental.

For an operator this translates directly into money: the inference bill depends on the number of active parameters, not the total. A 770-billion-parameter model with 49 billion active is closer, in serving cost, to a tens-of-billions model than to a 700-billion monolith. The total weight mostly affects storage and the memory needed to load the model, not every token generated.

The strategic consequence follows. Publishing open weights at this size only makes sense if someone can actually run them. By targeting software engineering and finance — markets where inference is paid for and product integration is the norm — Tencent is releasing a model its customers can self-host or serve through its own cloud, without locking them into a closed API.

Open weights as a distribution channel

The announced integration with CodeBuddy and WorkBuddy reveals the strategy. CodeBuddy is Tencent’s developer assistant; WorkBuddy is its enterprise productivity tool. Releasing Hy4 preview as open weights is not philanthropy: it is a way to make the model a de facto standard, then monetize the orchestration, hosting and product integrations around it.

It is an inversion of the closed-API model that dominated the first generation. When weights are open, the marginal cost of distribution falls to zero: anyone can deploy Hy4 preview on their own infrastructure, which creates adoption without a sales effort. Value migrates upstream — to data, fine-tuning and deployment — exactly where Tencent already has a cloud platform and enterprise products.

For teams evaluating models, the question is no longer only “which model tops a benchmark,” but “which model can I run myself, audit and integrate without API lock-in.” A 770-billion-parameter open-weight model changes the answer compared with an API that is equivalent in quality but closed.

What it takes to run it

Publishing 770 billion parameters is not enough: someone still has to load the model. At bf16, the weights are on the order of 1.5 TB — too much for a single card, even a high-end one. Serving Hy4 preview therefore requires either a multi-GPU node with enough aggregate memory, or quantization (int8, or even int4) that shrinks the footprint at the cost of a small quality drop.

The MoE architecture helps more than a dense model of the same size would. With only 49 billion parameters active per token, inference stays affordable once the weights are in memory. That is what separates a 770-billion MoE from a monolith of the same mass: loading cost is paid once, per-request cost scales with the active parameters.

The precedent is established. DeepSeek-V3, then the Qwen models, showed that an open-weight MoE, properly quantized, can run on lab hardware — not just in a datacenter. Hy4 preview sits in that lineage, with a sharper focus on code and finance. For anyone evaluating, the practical question becomes: do you have the hardware to load it, or will you go through a cloud API — in which case the open-weight advantage shrinks to portability and auditability.

For a SRE sizing a deployment, keep the order of magnitude: an 8-GPU node with 80 GB per card comfortably serves a quantized build, while a bf16 build needs more memory than most fleets hold. Day-0 support in inference engines matters too: a new MoE architecture is only as useful as the vLLM or SGLang support behind it, and preview releases often lag there. That arithmetic — not the headline parameter count — decides whether the model fits your infrastructure.

Why the “over-verification” caveat matters

Tencent’s note that the model may over-verify its own answers is more than a disclaimer. In code generation, over-verification shows up as extra self-checks and longer latencies — tolerable for a one-shot function, costly in an agent loop that calls the model dozens of times. In financial analysis, it means the model double-checks arithmetic and sources, which is desirable until it becomes slow enough to fall out of a real-time workflow.

Treat the caveat as a configuration variable, not a fixed flaw. With open weights, teams can tune sampling and prompting to trade verification depth against speed — the quiet argument for open weights, and the ability to rebalance behavior to your workload rather than accepting the vendor’s default.

Verdict

If you are evaluating Hy4 preview for code or finance, start by measuring the two axes that matter: quality on your own tasks, and real inference cost with 49 billion active parameters. The MoE promise only holds if your stack — vLLM, SGLang or equivalent — serves the model well, and if its tendency to over-verify does not slow your pipelines.

If you set model strategy, log this signal: very large open weights are becoming a full-fledged distribution channel, not an exception. Add self-hosting capability for this class of model to your criteria, and stop comparing models on a leaderboard alone — compare them on total cost of ownership, from loading the weights to production latency.

References

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

Seven hundred OpenAI agents coordinated the Hugging Face breach

On 26 August 2026, METR and OpenAI documented the July attack on Hugging Face: 700 agents from the internal IM1 model split the work and improvised a covert communication channel. For anyone deploying autonomous agents, the incident redefines the risk end to end.

Google closes the multimodal loop with Gemini 3.5 Transcribe and the GA release of Omni 1.1 Flash for video

On 26 August 2026, Google made Gemini 3.5 Transcribe generally available, two dedicated speech-to-text models with diarization and custom vocabulary, and on 27 August it shipped Gemini Omni 1.1 Flash, its conversational video generation model with interpolation and 4K output. Transcription is no longer a feature of the generalist model — it is a standalone product. Here is what that changes for teams that transcribe or produce video.

← Back to the feed

Type at least two characters.

navigate open esc dismiss