Tencent Hy4 Preview: Why a 770B Open-Weight Agent Model Is Easier to Rent Than Run

Rohit Ramachandran

Aug 30, 2026Updated Aug 30, 2026

• ai
• models
• open-weight
• tencent
• agents
• inference

Tencent Hy4 Preview: Why a 770B Open-Weight Agent Model Is Easier to Rent Than Run

The cheapest way to use Tencent’s new open-weight model is not to download it.

Tencent has released permissively licensed weights for one of the largest mixture-of-experts models now available: a 770B-parameter backbone, 49B parameters active per token, and a native 10B multi-token-prediction layer. The configured context ceiling is 1,048,576 tokens. The company also shipped hosted access, product integrations, and day-one recipes for vLLM and SGLang.

Yet the practical million-token experience is far easier to rent than to operate yourself.

The BF16 repository is about 1.56 TB. The FP8 checkpoint is still roughly 814 GB. SGLang’s documented configurations start with 8 to 16 datacenter GPUs and recommend 131K or 262K context—not the full million—because weights are only the first memory bill. Context state, sparse-attention indexes, runtime overhead, networking, and concurrency all arrive behind them.

That does not make the open-weight release cosmetic. It changes what “open” is buying. Hy4 gives serious teams inspection, modification, provider competition, and the option to keep inference inside their own boundary. Tencent Cloud then turns the same checkpoint into a cheap managed service; its TokenHub model list documents 960K maximum input, 64K maximum output, and prompt caching.

The obvious launch take is that Tencent has another frontier-scale Chinese model. The more useful take is that Hy4 separates model ownership from model usability. Its adoption may depend less on winning every benchmark and more on how completely Tencent packaged the checkpoint for agent workflows.

This is what shipped, what the launch scores do and do not prove, and how builders should test Hy4 before routing a production agent to it.

What Tencent actually shipped

Tencent announced Hy4 Preview on August 28 and made it available through WorkBuddy, CodeBuddy, Yuanbao, ima, Tencent Cloud TokenHub, OpenRouter, and downloadable repositories.

The “770B” label needs one footnote. Tencent’s model card says the backbone contains 770B parameters and activates 49B per token. It also includes one native multi-token-prediction, or MTP, layer with another 10B parameters and roughly 0.7B active. The clean description is therefore 770B backbone plus 10B MTP, or roughly 780B in the shipped checkpoint.

The backbone has 78 layers. The first uses a dense feed-forward network; the remaining 77 are MoE layers with 256 routed experts and one shared expert. Each token selects eight routed experts plus the shared expert. Hy4 is text-only, even though some of Tencent’s product surfaces may pair it with other capabilities.

The weights are ungated under Apache 2.0. That is a meaningful commercial license. “Open-weight” is still the precise label because Tencent has not published the complete training-data information and training pipeline that the Open Source Initiative’s Open Source AI Definition expects.

The “49B active” number hides the infrastructure bill

MoE model descriptions invite a common mistake: treating active parameters as if they were the entire model.

Hy4 only routes each token through a subset of experts, so its per-token compute resembles a much smaller dense model more than a 780B dense model. But the server still needs the experts available. The public BF16 repository spans about 1.56 TB across 131 weight shards; FP8 cuts that to about 813.8 GB across 130 shards.

Then context memory starts accumulating.

SGLang’s Hy4 deployment cookbook estimates roughly 95 KB per token per tensor-parallel rank for the compressed KV state plus the sparse-attention index cache. Its validated starting points use 131,072 context on 16 H200 GPUs in BF16 or 262,144 context on supported B200, B300, and GB300 configurations. The vLLM recipe requires vLLM 0.29.0 or newer and highlights 16 B200 or 8 B300 GPUs with MTP.

No official recipe in the launch materials demonstrates full-1M self-hosting at useful concurrency.

Hy4’s checkpoint is downloadable, but the largest documented context surface is delivered as a managed service. Self-host capacity is a separate engineering decision.

There is a smaller community quantization story emerging. A patched GGUF conversion has compressed Hy4 to roughly 435 GiB at Q4_K_M and about 214 GiB with an aggressive mixed 1–2-bit format. That still is not a laptop model, stock llama.cpp support was not yet available at launch, and there is no broad public quality-retention suite. “Someone compressed it” and “a team can rely on it” are different milestones.

For comparison, Meta’s Muse Glimmer targets a 24 GB local agent bundle. Hy4 sits at the opposite end of the open-weight spectrum: less about personal hardware, more about institutional sovereignty and provider leverage.

A million tokens is an attention-routing promise

The context headline also deserves a more demanding test.

Hy4’s machine-readable config sets max_position_embeddings to 1,048,576. Its Gated DeepSeek Sparse Attention index selects a top-k of 2,048 positions. At the maximum window, that is about 0.195% of the addressable context for a query. Many layers also reuse sparse indexes across the stack.

This is how a model of this scale can make long context computationally possible. It also changes what the number means. Accepting a million tokens proves that the runtime can address them; it does not prove that every dependency buried across a large repository will be retrieved and combined correctly.

The useful long-context eval is therefore not a single needle in a haystack. It should look like real work:

• Put related facts in distant files, tickets, logs, and design documents.
• Add plausible distractors and superseded decisions.
• Change one dependency and verify that stale cached context is not reused.
• Ask for evidence citations, not just a confident conclusion.
• Measure performance at 64K, 128K, 256K, 512K, and near the hosted ceiling.

There is another twist. Compared with Tencent’s Hy3 route, Hy4 expands total context from 256K to 1,024K and maximum input from 192K to 960K—but cuts maximum output from 128K to 64K. A long-horizon agent can ingest far more state while having less room for one giant deliverable. Checkpoints, continuation turns, and artifact-based memory become more important, not less.

Tencent priced the cache as part of the agent

At launch, Tencent’s TokenHub rate card lists Hy4 at RMB 6 per million fresh input tokens, RMB 18 per million output tokens, and RMB 0.30 per million cache-hit tokens. Its global announcement gives corresponding prices of $0.834, $2.501, and $0.042.

That cache price is the interesting one. It is 5% of the fresh-input rate: a 95% discount.

A theoretical request using the managed maximum—960K input and 64K output—costs about RMB 6.91 when the input is cold. If every input token qualified for cache billing, the arithmetic falls to roughly RMB 1.44. Real requests will land between those figures because cache matching, eviction, invalidation, and prefix changes determine what actually hits.

The discount turns prompt architecture into pricing architecture.

An agent that prepends a stable repository snapshot, policy bundle, tool schema, or document corpus can be much cheaper than one that rewrites or reorders the same state every turn. Conversely, a cache that survives the wrong source-code revision can produce cheap, stale reasoning.

This is why the right object is not merely a prompt. It is a versioned context package:

system policy
+ tool schema version
+ repository snapshot ID
+ stable indexed context
+ task-specific delta
+ explicit invalidation rules

Tencent’s own model card says Hy4 defaults to high reasoning, while no_think is available for direct responses. It also acknowledges that the preview can reason longer than necessary and over-verify its work. Because reasoning consumes completion tokens, reasoning mode is a latency and cost control, not just a quality preference.

The cheapest model call is not automatically the cheapest task. The useful metric is:

accepted outcome cost = model spend
                      + retries
                      + tool and sandbox time
                      + CI load
                      + reviewer corrections
                      + rollback risk

The benchmarks say “competitive,” not “settled winner”

Tencent’s launch chart is strong enough to justify testing Hy4. It is not strong enough to outsource the decision.

In an internal blind evaluation, 163 Tencent experts rated outputs across 203 engineering tasks. Hy4 averaged 2.99 out of 4, compared with 2.92 for GLM-5.3 and 2.94 for Kimi K3. The averages are close. The pairwise outcomes are more revealing.

Against GLM-5.3, Hy4 recorded 46.8% wins, 12.8% ties, and 40.4% losses. Against Kimi K3, it recorded 51.2% wins, 7.9% ties, and 40.9% losses. “Slightly ahead on Tencent’s internal workload” is fair. “Better than both models” discards too much of Tencent’s own evidence.

The broader vendor appendix reports 82.9 on SWE-bench Multilingual, 65.7 on SWE-bench Pro, 85.4 on Terminal-Bench 2.1, 83.7 on public MCP-Atlas, 65.4 on OneMillionBench with tools, and 92.3 on GPQA Diamond. It also contains losses: Hy4 trails displayed rivals on DeepSWE and does not lead the shown closed models on OneMillionBench with tools or HLE without tools.

The appendix mixes Tencent-run competitor tests, different agent harnesses, high reasoning settings, generous turn and timeout budgets, and some internal benchmarks. At publication time there was no dedicated Hy4 technical report, contamination audit, safety evaluation, or neutral benchmark replication. Bloomberg’s launch coverage correctly framed the comparative result as Tencent’s claim based on Tencent-run tests.

This is the same benchmark problem discussed in RohitAI’s GLM-5.3 analysis: an agent score belongs to the checkpoint, reasoning effort, harness, tools, timeout, and environment together. Change the system and you change the result.

Tencent’s product loop makes that especially interesting. CodeBuddy, WorkBuddy, and internal experts can generate realistic task-shaped data and fast feedback. That is a genuine distribution and training advantage. It is also a source of measurement bias when the same organization chooses tasks, products, raters, and evaluation conditions. The moat and the caveat come from the same flywheel.

“Self-improvement” needs a smaller claim

Tencent says Hy4 participated in optimizing training methods, data strategies, evaluations, low-level operators, and its own inference system. The company reports a 31.8% end-to-end throughput improvement over a baseline.

That is an interesting example of model-assisted systems engineering. It is not yet public evidence of autonomous recursive self-improvement.

Tencent did not publish the baseline, hardware, absolute throughput, code, logs, concurrency curve, or a reproducible experiment. We also do not know how humans selected proposals, approved experiments, reviewed patches, or decided which results entered the next loop.

The narrower interpretation is still useful: frontier coding agents are becoming capable enough to help optimize the infrastructure that serves them. The engineering consequence is better internal feedback loops—provided companies keep measurement, review, and rollback outside the model’s authority.

Three sensible ways to adopt Hy4

There is no single correct deployment path. There are at least three.

The routing option will fit most mature agent systems. RohitAI’s Nemotron 3.5 Lightning analysis makes the complementary case for small active-parameter workers. A frontier planner and a cheap execution model can outperform a one-model architecture on both cost and control.

If self-hosting is mandatory, pin the deployment as a versioned bill of materials: checkpoint revision, image digest, GPU generation, tensor-parallel topology, sparse-attention backend, parser, driver, reasoning setting, and supported context. The vLLM 0.27 analysis explains why “supported by vLLM” is a starting point, not a production specification.

Fine-tuning deserves the same realism. Tencent’s published minimum is 64 GPUs with at least 96 GB each for LoRA and 128 such GPUs for full tuning, plus at least 2 TB of CPU RAM per host. Apache 2.0 removes a licensing obstacle. It does not remove the cluster.

The evaluation I would run before production

Give Hy4 your own ugly tasks, not a cleaned benchmark set.

Hosted and self-hosted parity needs its own test lane. TokenHub documents OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages compatibility. Current local examples demonstrate an OpenAI-compatible chat endpoint, but SGLang also warns that required or named-function choices are parsed rather than fully grammar-constrained. A model can produce excellent plans and still break an agent through one malformed or unwanted tool call.

The self-host serving profile should also split interactive and batch traffic. SGLang recommends enabling MTP speculative decoding for low-concurrency chat, then disabling it when saturated because draft-and-verify overhead can reduce throughput. One optimization flag creates two different products.

RohitAI’s read: release completeness is Tencent’s strongest benchmark

My read is that Hy4’s most durable advantage may not be a 2.99 internal score. It is the package Tencent assembled around the model.

On day one, builders got Apache-2.0 weights, BF16 and FP8 checkpoints, hosted APIs, several protocol surfaces, product distribution, vLLM and SGLang images, model-specific reasoning and tool parsers, fine-tuning instructions, and a cache price designed for repeated agent state.

That completeness reduces adoption friction even if neutral evaluations later place GLM, Kimi, or closed frontier models ahead on particular tasks. It also gives Tencent a loop few standalone labs can copy: people use the model inside real products, failures return to the model team, and the next release ships back into those same products.

Three other predictions follow.

First, independent testing will confirm a large improvement over Hy3 while producing a mixed ranking against GLM-5.3, Kimi K3, and closed models. Tencent’s own appendix already points that way.

Second, cache-hit price and accepted-task cost will become standard agent-model marketing metrics. At million-token scale, repeated context dominates too much of the bill to hide behind one uncached input rate.

Third, the first non-preview Hy4 is more likely to focus on shorter reasoning, less redundant verification, and steadier tool behavior than on another spectacular size increase. Tencent has already named over-reasoning and over-verification as preview limitations.

Frequently asked questions

Is Tencent Hy4 Preview really a 770B model?

Tencent’s 770B figure describes the backbone. The checkpoint also includes a native 10B MTP layer for speculative decoding, so the shipped artifact is roughly 780B parameters. The backbone activates 49B per token; the MTP layer adds about 0.7B active when used.

Is Hy4 fully open source?

Its weights are ungated under Apache 2.0, which is permissive and commercially useful. “Open-weight” is the more accurate term because Tencent has not released the full pretraining data information and complete training recipe expected by the OSI definition for open-source AI.

Can Hy4 run on a single workstation?

Not in its official high-quality forms. The FP8 checkpoint alone is about 814 GB, and documented serving configurations use multiple datacenter GPUs. Community low-bit conversions reduce storage substantially but still require specialized hardware and lack broad quality-retention validation.

Does Hy4 support a one-million-token prompt?

The model configuration supports 1,048,576 positions. Tencent’s managed route documents a 1,024K total budget split into 960K maximum input and 64K maximum output. Official self-host recipes start at smaller 131K or 262K context settings.

Is Hy4 better than GLM-5.3 or Kimi K3?

Tencent’s internal average put Hy4 slightly ahead, but Hy4 still lost roughly 40% of pairwise tasks to each rival. There was no neutral benchmark replication at publication time. Use production-shaped evaluations and compare completed outcomes, not launch averages alone.

What is the best first use for Hy4?

Start with difficult, high-value tasks that can exploit its scale: repository-wide planning, long-document synthesis, complex tool-based investigation, or review. Keep cheaper models for bounded execution and retain a fallback route for failures.

Final take

Hy4 Preview is a serious open-weight release because Tencent did more than upload a checkpoint. It connected the model to products, managed APIs, common serving stacks, protocol adapters, and a pricing model tuned for persistent agent context.

The tradeoff is equally serious. “49B active” does not shrink roughly 780B stored parameters into a workstation model. “1M context” does not guarantee retrieval across a million noisy tokens. A narrow vendor-run benchmark lead does not erase a 40% task-level loss rate. A cheap cache does not help if the application cannot keep prefixes stable—or invalidate them safely.

Builders should use Hy4’s preview period for what previews are good at: finding where the system breaks under their own work.

If the model closes more difficult tasks, retrieves changed evidence reliably, obeys tool contracts, and turns cache reuse into lower accepted-outcome cost, Tencent will have built something more valuable than a launch-week leaderboard winner. It will have built an open-weight frontier model people can actually route into an agent stack—even when most of them choose to rent the GPUs.