Tencent Hy4 preview: open-source 770B, routing cost

49B active out of 770B total is the number you pay for

On August 28, 2026, Tencent opened the weights of the Hy4 preview, an MoE with 770B total parameters and only 49B active per token, Apache 2.0 license and 1M-token context, via the primary source on GitHub. The implication for anyone routing LLM workloads: each request pays for only 49B of compute, not the 770B.

The number that decides the bill at inference is the activated one, not the total. The total is the spec sheet; the active is the bill. A CTO who reads the sheet as "770B parameters, so expensive to serve" is looking at the wrong metric, and that is exactly what this release changes in the model-selection agenda.

What happened at the Hy4 preview launch

The Hy4 preview is the new flagship model from the Tencent Hy Team, officially announced on 2026-08-28 in the GitHub README, with the full spec sheet on Hugging Face. It is a Mixture-of-Experts (MoE) architecture whose cost decision lives in the activation density. The published data:

• 770B total parameters, 49B active per token.
• 78 layers: the first dense, the following 77 MoE, each with 256 routed experts and 1 shared expert. Each token activates the top-8 routed experts and the shared expert.
• 1 native MTP layer (10B total, 0.7B activated) for speculative decoding.
• Gated DeepSeek Sparse Attention (Gated DSA) with IndexCache, an architecture inspired by DeepSeek and GLM.
• 1M-token context.
• Apache 2.0 license, with open weights.
• Availability on Hugging Face, ModelScope, GitCode and CNB, in two variants: Hy4 preview and Hy4 preview-FP8.

Deployment uses the official vLLM and SGLang recipes, with the pre-built images vllm/vllm-openai:hy4-preview and lmsysorg/sglang:hy4-preview. The API is OpenAI-compatible and Tencent publishes recommended parameters: temperature=0.9, top_p=1.0, with default reasoning mode set to "high" (deep chain of thought) and a no_think option for direct responses.

The gains Tencent names are about productivity, not toy benchmarks: software engineering on long-horizon tasks, office and analysis work (artifacts, spreadsheets, financial models), game development from prompt to prototype, and scientific research.

In the blind evaluation, Tencent used 163 internal experts across 203 tasks. The Hy4 preview came slightly ahead of GLM 5.3 (2.99 vs 2.92, with 46.8% wins) and of Kimi K3 (2.99 vs 2.94, 51.2% wins). These numbers are vendor-supplied and measure internal human preference, not an objective score of cost or latency, so the correct reading is positioning, not verdict.

Tencent states the limitations directly: it is an early version, with real headroom in pre and post-training, and a tendency to over-reason and over-verify its own work on complex tasks. Factor that in when you measure in production.

Why 49B active matters for inference cost

In an MoE, each request only runs the activated slice of parameters. The compute bill per token is decided by the 49B, not the 770B. That is why the Hy4 preview spec sheet breaks the classic intuition: a giant model is not necessarily an expensive model to serve when the activation density is low.

The number is the activations/total ratio: 49B over 770B is about 6.4%. In self-hosted inference, the incremental cost per token is strongly determined by the capacity activated per token, by attention latency, and by the hardware you serve. The 770B still decides the memory size needed to load the weights and the initialization cost, but it is the 49B that cuts the price of each request.

That repositions the routing decision. The question stops being "which model is cheapest in the catalog?" and becomes "what is this model's measured cost per token for this class of task?". A frontier open-weight MoE like the Hy4 preview puts a small-model cost per token on top of large-model quality, and it is that combination that shifts the math between serving public and closing the door.

The blind eval comparison completes the picture: 49B active delivering a 2.99 result on Tencent's own blind test, ahead of two heavyweight models in the same measurement. For a CTO who routes by cost and quality, the data point is concrete enough to demand a route test, not to assume victory.

There is a limit to name. Activation density defines the FLOPs cost, but the observed cost in production depends on concurrency, continuous batching, KV-cache, and the sparse attention pattern, which is new. No cost-per-token value under real traffic has been published. Test on your workload.

What changes in practice for model selection

The Hy4 preview is not an automatic swap. It is a candidate route that changes how model selection used to work. The table below compares the fixed regime with the routing policy that a frontier MoE at 49B active enables.

The price of this reading is an honest observation: Tencent benchmarks, theoretical FLOPs cost, and activation density are signals, not the cost of your traffic. The part that only your operation answers is the measured cost per task, with your sample of requests.

What to do now: measure the route, don't guess the outcome

The Hy4 preview enters as a candidate route, under controlled testing, with the same discipline as any other frontier model, and not as an automatic swap in the application. Cost and quality measured on your workload decide the promotion. The actions below settle the sequence in practice.

1. Measure cost per task, not per model. Log the observed cost of each request class (short, long, reasoning, tool use) with the Hy4 preview served on your infrastructure, and compare with the current route. The data point that decides the bill is yours, not the published density.

2. Evaluate quality with criteria defined beforehand. Use a rubric tied to the work, on the task that justifies the route. Do not convert Tencent's blind eval (2.99 vs GLM 5.3 and Kimi K3) into independent production validation; treat it as vendor positioning and measure on your use case.

3. Test the reasoning mode by task class. The Hy4 preview over-reasons and over-verifies by default. For direct answers, no_think cuts the chain of thought. Define which class each mode applies to, otherwise you pay excess latency and output.

4. Add the Hy4 preview as a route in a gateway, not in the app code. A routing layer centralizes the choice by cost, performance, latency and context, as the Nexforce Router documents, and lets you test the route without reintegrating any application. The roundtrip of a test stops being a project.

5. Define the promotion criterion and the fallback. Only promote the route when cost, latency, context and quality meet the task limits, with availability confirmed. While the evidence does not close the math, keeping the Hy4 preview under evaluation is the correct decision, and the fallback protects the application.

FAQ about the Hy4 preview and the cost of routing

Is the Hy4 preview a 770B model, so is it expensive to serve?

Not necessarily. It has 770B total parameters, but only 49B active per token, because it is an MoE that only runs the top-8 of 256 experts on each request. The incremental cost per token in inference depends on the activated capacity, not the total number, although the 770B still define the memory needed to load the weights and the initialization cost.

What does "49B active per token" mean for whoever routes?

It means the metric that matters for each request's bill is the activation, not the total size. For a CTO, the swap is one of mindset: instead of judging the model by the big number on the sheet, measure the cost per task on the route. A frontier model with low activation density changes the math between open-weight and the closed frontier.

Does the 2.99 eval prove the Hy4 preview is better than the GLM 5.3 and the Kimi K3?

It does not prove it. The evaluation is blind and internal, run by 163 Tencent experts across 203 tasks, and the numbers are vendor-supplied. They serve to position the model on the map, not as independent validation of quality, cost or latency on your traffic. The production decision comes out of a test on your workload.

Should the Hy4 preview replace the closed frontier?

Not as a rule. It enters as a candidate route for long-horizon tasks where open-weight quality now competes with the closed frontier, at a cost per token of a model with 49B active. For the rest of the scale, the closed frontier remains justified. What decides by task class is the routing policy, not the launch news.

Can I already serve the Hy4 preview in production?

You can serve it today via vLLM or SGLang, with official images and recipes, and the weights under Apache 2.0. Run a controlled test before promotion. Tencent declares known limitations, including over-reasoning and over-verification, and the real production cost is still not public, so the recommendation is to measure per task before promising any gain.

References and Further Reading

The primary source of the launch is the official Hy4 preview README on GitHub, which publishes architecture, specs, deployment, blind eval and limitations, with the spec sheet on Hugging Face backing the model data. The announcement was made on 2026-08-28.

This analysis continues the thread that Qwen3.8-Flash-Next and the routing decision opened days earlier: an open-weight MoE with low activation changes the question from "which model is bigger" to "which cost per task". It also builds on the GLM-5.3-Flash coverage, another frontier open-weight with low cost, and on the reading of routing by complexity, which decides the route by the task rather than the most expensive model.

The next release will confirm or refute the scale

The short term is about testing, not verdicts. The Hy4 preview opens a concrete path: serving a frontier open-weight model at the bill of a 49B active slice, and that gives the buyer an option that did not exist before. Tencent named the headroom and the limitations; the realistic expectation is fast iteration in the coming weeks.

The route decision stays with the operations data. The test decides. Who serves through a model gateway can place the Hy4 preview as a candidate route, measure cost, latency and quality per task, and promote only what closes the math. What this release changes is the scale: from here on, the "big, expensive model" and the "small, cheap model" stop being read by the total number on the spec sheet, and start being decided by what each request actually activates.