On August 28, Tencent Hunyuan released its new flagship Hy4 preview along with its weights: 770B total parameters, only 49B activated per token. Sitting at the same table are Kimi K3 at 2.8 trillion, DeepSeek V4-Pro at roughly 1.6 trillion, Qwen3.8-Max at 2.4T, and the post-training-route GLM-5.3. Total parameters span 770B to 2.8T -- a 3.6x spread -- but when you open the deployment ledger, the variable that actually decides cost is not total size. It is the one most coverage skips: the activation ratio and sparse attention.
Scope first: this is a representative comparison, not hands-on benchmarking. Specs, architecture, and eval figures come from official releases and public reporting; prices and repo stats are a 2026-08-29 snapshot, with the sourcing basis labeled per item (official release / media report / converted / engineering estimate / vendor internal blind eval). Defer to official repos and pricing pages. Not investment advice. One division of labor to note: our lite flagship price comparison covers the API unit-price and cache math of 320B-class lite flagships; this article does not redo the API price war. It covers the parameter, architecture, and deployment-threshold ledger of 700B-2.8T open-weight flagships. Two articles, two ledgers -- read both before you choose.
1. The Parameter Baseline: Five-Way Spec Table
| Dimension | Tencent Hy4 preview | Kimi K3 (Moonshot) | DeepSeek V4-Pro | Qwen3.8-Max (Alibaba) | Zhipu GLM-5.3 |
|---|---|---|---|---|---|
| Total parameters | 770B (official release) | 2.8T (official release) | ~1.6T (our earlier reporting) | 2.4T (our earlier fact-check) | Not collected |
| Active params/token | 49B (official release) | Not collected | Not collected | Not collected | Not collected |
| Context window | 1M (official release) | 1M (official release) | 1M (our earlier reporting) | 1M (our earlier fact-check) | Not collected |
| Attention / architecture highlights | Gated DSA sparse attention + IndexCache; 78 layers (1 dense FFN + 77 MoE; 256 routed + 1 shared expert, top-8 + shared) | KDA hybrid linear attention + attention residuals | Not collected | Not collected | Post-training scaling (base unchanged) |
| Speculative decoding | Native MTP layer (official release) | Not collected | Not collected | Not collected | Not collected |
| Weight format / quantization | BF16 + FP8 dual format (official release) | MXFP4 quantized weights (official release) | Not collected | Not collected | Not collected |
| License | Apache 2.0 (official release) | Commercial use allowed (terms per official repo) | Not collected | Per official repo (not verified in this snapshot) | Open weight (repo/license per official channels) |
| Weight channels | Hugging Face / ModelScope / GitCode / CNB | Hugging Face (weights opened 2026-07-27) | Not collected | Not collected | Zhipu official repo (THUDM) |
Three first-glance takeaways:
- Active parameters are buried in the press release. Only Hy4 preview puts its active parameter count (49B) front and center; for the other four, active counts are either not collected or inconsistently reported. That is no accident: the activation ratio (active/total) is the lifeline of inference cost. Hy4's 49B/770B is about 6.4% -- each token runs roughly 1/16 of the network. Total parameters decide how much the model knows; active parameters decide how much compute each token burns. Press releases love the former; the ledger cares about the latter.
- Sparse attention has become flagship standard equipment. Hy4's Gated DSA + IndexCache and K3's KDA hybrid linear attention attack the same problem: attention compute and KV cache blow-up at 1M context. The previous generation paid double inference cost to run 1M windows; this generation compresses that curve with sparse/linear hybrids. When a spec sheet says "supports 1M context," the real cost behind that sentence depends entirely on the attention architecture.
- Licenses and quantization formats are diverging. Hy4 ships Apache 2.0 with BF16/FP8 dual weights; K3 ships MXFP4 quantized weights; the GLM line is open but license terms defer to official channels. Quantization format is not a footnote: it directly determines how much VRAM the resident weights occupy (next section does that math).
2. The Deployment Threshold: Activation Saves Compute, Total Size Eats VRAM
The most common misreading of this cohort: small active parameters do not mean small VRAM needs. Our GLM-5.3-Flash integration SOP ran this math: activating 18B saves per-token compute (throughput, latency, power), but the full 320B of weights must still sit in VRAM. At 770B-2.8T scale, the same rule becomes a cluster-scale problem:
| Model | Resident weight VRAM (converted / engineering estimate) | Deployment shape | Key variable |
|---|---|---|---|
| Tencent Hy4 preview | ~770GB at FP8 / ~1.5TB at BF16 (converted at 1/2 byte per param) | Multi-node cluster (official vLLM image starts at TP8) | Active 49B saves compute; total 770B sets VRAM; MTP speculative decoding boosts throughput |
| Kimi K3 | ~1.4TB at MXFP4 (converted at 4 bits per param) | Multi-node cluster (earlier reporting: H100-class cluster floor) | Total 2.8T sets the VRAM ceiling; KDA compresses KV cache |
| DeepSeek V4-Pro | Not collected | Not collected | Not collected |
| Qwen3.8-Max | Not collected | Not collected | Not collected |
| Zhipu GLM-5.3 | Not collected | Not collected | Not collected |
Note: every VRAM figure above is a converted estimate (bit-width x parameter count; excludes KV cache and runtime overhead, so real requirements run higher). Defer to each official repo's deployment docs.
- The real 770B threshold: a cluster, not a single 8-GPU box. Hy4 preview's FP8 weights run about 770GB; 8x80GB gives 640GB of VRAM, which does not fit. You need at least 10-12 80GB cards or 16 48GB cards (engineering estimate). The official path is the prebuilt vLLM image (vllm/vllm-openai:hy4-preview, starting at TP8) and an SGLang image, with README deployment docs written for cluster scale. For individual developers and small teams, self-hosting stops here.
- The payoff of low activation is throughput, not VRAM. 49B active means small per-token compute, and paired with the native MTP speculative decoding layer (official basis), throughput per unit of hardware clearly beats a dense-activation model of the same total size. For offline batch workloads, a low activation ratio saves time and power; for low-latency online serving, it shapes first-token latency. The rule: activation ratio saves compute, total size sets VRAM -- keep the two ledgers separate.
- Sparse attention decides the KV cache curve. At 1M context, dense attention's KV cache explodes linearly with sequence length; Hy4's Gated DSA + IndexCache and K3's KDA hybrid linear attention both compress that curve. When choosing, do not stop at "supports 1M" -- look at the attention architecture, which decides your real VRAM and cost curve in long-context scenarios.
- The shared threshold of this cohort: nobody self-hosts any of the five on a single card. 770B-2.8T total parameters make self-hosting an institutional game. The realistic play for small teams is API plus open weights as fallback: run on API daily, migrate to self-hosting only for extreme price hikes or compliance scenarios. Migratability is exactly what open weights buy you -- but remember the migration target itself is a cluster-scale threshold.
3. Capability and Price Snapshot: One Blind Eval, One Aggregator Price, Three Caveats
| Dimension | Tencent Hy4 preview | Kimi K3 | DeepSeek V4-Pro | Qwen3.8-Max | Zhipu GLM-5.3 |
|---|---|---|---|---|---|
| Representative capability data | Vendor internal blind eval 2.99/4.00 (163 experts, 203 engineering tasks, official-release basis) | Frontend Code Arena 1679, topping Claude Fable 5 (media citation) | AA index 53 (media citation) | Not collected | Open-source first on Terminal Bench 3.0 and others (official release) |
| API price | OpenRouter snapshot: $0.834/M input, $2.501/M output, $0.042/M cache read (third-party aggregator snapshot 2026-08-28) | Output 100 RMB/M (official pricing via media, 3x+ the previous generation) | Peak output 27 RMB/M (media report 2026-08-27) | Not collected | API pricing per Zhipu official channels |
| Cache price | $0.042/M cache read (OpenRouter snapshot) | Not collected | V4-Flash off-peak 0.05 RMB/M (media report) | Cache hit 1 RMB vs miss 12 RMB (our earlier fact-check) | Not collected |
Three sourcing caveats:
- The 2.99 score is a vendor internal blind eval, not third-party benchmarking. It edges GLM-5.3's 2.92 (46.8% win / 12.8% tie / 40.4% loss) and Kimi K3's 2.94 (51.2% win / 7.9% tie / 40.9% loss), over 163 experts and 203 engineering tasks -- a decent sample, but the evaluator is the vendor itself, which picks the tasks, the experts, and the scoring rubric. Treat it as a reference point, not a verdict; run your own eval set before adopting.
- The OpenRouter snapshot price is an aggregator price, not Tencent's official rate card. $0.834/$2.501 per million tokens is a third-party aggregator snapshot from 2026-08-28; aggregators add margins, quotas, and FX conversion. It is not the official pricing page. Verify official rates through Tencent Cloud's official channels -- we did not collect unverified official pricing.
- Cache pricing is fragmented; do not compare cache rates directly across vendors. The five use wildly different cache bases: Hy4 cache read $0.042/M (OpenRouter snapshot), DeepSeek V4-Flash off-peak 0.05 RMB/M (media report), Qwen3.8-Max 1 RMB hit vs 12 RMB miss (our earlier fact-check) -- different currencies, billing units, and hit rules. In the Agent era, cache hit rate steers the bill (our lite flagship comparison showed selection conclusions can flip once hit rates exceed 90%). Before switching models, redo your cache math on a unified basis.
4. Pick by Scenario: Five Verdicts
- Want the newest open flagship and its architecture dividends: Tencent Hy4 preview. Apache 2.0 license, BF16/FP8 dual weights, native MTP speculative decoding, complete official vLLM/SGLang images -- the open ecosystem can absorb it. The 49B activation throughput dividend suits high-concurrency workloads. For the hands-on path, see our Hy4 preview self-hosting SOP (same batch).
- Want maximum scale and capability ceiling: Kimi K3. 2.8T total (the first open-source 3-trillion-class model), native vision, 1M context, Frontend Code Arena 1679 at the top. Output at 100 RMB/M is a capability premium tier -- not a value pick.
- Want maturity and ecosystem balance: Zhipu GLM-5.3 and DeepSeek V4-Pro. GLM-5.3 took open-source first on Terminal Bench 3.0 and more via post-training scaling, plus emergent security capability (2,436 vulnerabilities found jointly with security teams). V4-Pro leans on 1M context plus Anthropic API compatibility for cheap migration. Both are mature dual-line players: commercial API plus open weights.
- Alibaba ecosystem and compliance: Qwen3.8-Max. 1M context, cache hit at 1 RMB vs 12 RMB miss (our earlier fact-check), on top of Alibaba Cloud's ecosystem and enterprise compliance stack. Heavy-cache scenarios make that pricing interesting -- but its open-weight status and broader pricing were not verified in this snapshot; defer to official channels before purchasing.
- For every scenario: in the 770B-2.8T era, the activation ratio and sparse attention are the deciding variables of deployment cost. Total parameters set resident VRAM (self-hosting threshold), active parameters set per-token compute (throughput/latency), attention architecture sets the long-context cost curve -- keep three ledgers, choose by actual per-token cost, and stop ranking models by total size.
FAQ
Q1: 770B vs 2.8 trillion is a 3.6x gap -- does bigger total size always win? A1: No. Total parameters set resident VRAM (self-hosting threshold), active parameters set per-token compute (throughput/latency/power), and sparse attention sets the long-context cost curve. Treat them separately. Hy4 preview's 770B activates only 49B (about 6.4%) -- its activation ratio is actually the advantage. Choosing by total size alone gets you "buying big and running small." Put all three variables into your own workload and compute actual per-token cost.
Q2: Can Hy4 preview's 2.99 score be taken as "open-source No. 1"? A2: Not directly. The 2.99/4.00 comes from Tencent's internal blind eval (163 experts, 203 engineering tasks); the vendor picks tasks, experts, and the rubric. GLM-5.3's 2.92 and Kimi K3's 2.94 are from the same internal eval. A 0.02-0.07 gap is within sample noise -- use it as a coordinate, not a conclusion, and run your own eval set first.
Q3: Can small teams self-host these flagships? A3: Essentially no. 770B at FP8 is about 770GB of weights (converted estimate) and 2.8T at MXFP4 about 1.4TB -- both far beyond a single 8-GPU box's 640GB of VRAM, before KV cache and runtime overhead. Self-hosting is an institutional game. The realistic path for small teams: API daily, open weights as a migration fallback for extreme hikes or compliance scenarios. Do not put self-hosting on the near-term roadmap.
Q4: Are $0.834/$2.501 on OpenRouter Hy4's official prices? A4: No. That is a third-party aggregator snapshot from 2026-08-28, including platform margin, quotas, and FX conversion -- not Tencent's official rate card. Tencent's official pricing was not verified in this snapshot and is therefore marked not collected; verify via Tencent Cloud's official channels.
Q5: Is anyone on this list worth locking a price with now? A5: Do not lock with anyone. Price data in this snapshot is scattered across bases (aggregator prices, media citations, not-collected entries), the industry is in a pricing-power contest, and rate cards change fast. The right posture: budget by actual per-token cost plus cache hit rate, keep multiple API channels plus open-weight fallback in your architecture, and renegotiate quarterly.
References
- Tencent official press release (2026-08-28): Tencent releases and open-sources Tencent Hy4 preview -- 770B/49B, Gated DSA, MTP, 1M context, Apache 2.0, BF16/FP8 weight channels, 163-expert/203-task internal blind eval: https://www.tencent.com/tencent-releases-and-open-sources-tencent-hy4-preview
- Tencent Hunyuan Hy4 preview official repo (GitHub, snapshot 2026-08-29) -- architecture details, vLLM/SGLang deployment images, recommended temperature=0.9/top_p=1.0, known limitations: https://github.com/Tencent-Hunyuan/Hy4-preview
- OpenRouter Hy4 preview page (third-party aggregator snapshot 2026-08-28) -- $0.834/M input, $2.501/M output, $0.042/M cache read: https://openrouter.ai/tencent/hy4-preview
- Tencent Cloud Developer Community (2026-07-17): Kimi K3 with 2.8 trillion parameters officially released -- K3 specs, KDA, output 100 RMB/M: https://cloud.tencent.com/developer/news/4268105
- Our earlier fact-checks: Qwen3.8-Max 2.4T / 1M context / cache hit 1 RMB vs miss 12 RMB (fact-checked 2026-08-03); DeepSeek V4-Pro ~1.6T (earlier reporting)
- Further reading: our lite flagship price comparison (division of labor in the intro), Hy4 preview launch hotspot (same batch), Hy4 preview self-hosting SOP (same batch), GLM-5.3 deep dive, Zhipu GLM-5.3-Flash open-source hotspot, Kimi vs Qwen vs GLM long-context comparison, LLM cost-performance comparison
This is a representative comparison compiled from public reporting and official releases, snapshot 2026-08-29 (OpenRouter as of 2026-08-28), not hands-on benchmarking and not investment advice. Specs, licenses, and prices may change at any time; verify against official repos and pricing pages before purchasing.