Tencent Hy4 Preview 開放權重：1M Context、770B MoE 與盲測怎麼看？（2026）

2026 年 8 月 28 日，Tencent 在官網發布〈Tencent Releases and Open-Sources Tencent Hy4 preview〉；Tencent Hy4 Preview 的官方 repo 提供可下載權重，LICENSE 標示為 Apache-2.0，模型主打 770B backbone、每個 token 啟用 49B 參數，以及 1,048,576 tokens 的 configured maximum。

這組規格很容易被濃縮成一句「能讀 1M token、只跑 49B 的頂尖開源模型」。但三個詞各自少了一半：1M 是設定容量，不是長文品質保證；49B 是每 token 的計算路徑，不是只需載入 49B 權重；「領先」則主要來自 Tencent 自己的 benchmark 與內部盲測。

以下先忠實還原原文交付了什麼，再把參數、部署配方、盲測與「自我改進」逐一對帳，最後回答一個更實際的問題：誰現在真的能從 Hy4 Preview 得到價值，誰應該先等證據補齊。

先說結論：這是重要的開放權重發布，但最強賣點仍在等待驗證

• 授權與交付範圍要分開讀：官方 repo 的 LICENSE 標示 Apache License 2.0。截至 2026 年 8 月 31 日，repo 公開了 BF16／MXFP8 權重、設定與 tokenizer、chat template、部署文件，以及 SFT 微調程式；這仍不等於已公開完整預訓練資料資訊與完整預訓練流程。
• 770B／49B 要分開讀：770B 與 49B 都是 backbone 口徑；另有約 10B／0.7B active 的 MTP 模組。49B active 能降低每個 token 的計算量，無法把完整 checkpoint 縮成 49B。
• 1M 是上限，不是成績：公開 config 的上限是 1,048,576 tokens，TokenHub API 也宣告 1M context；但官方 SGLang 自架配方目前示範 131K 或 262K，首發材料沒有展示從短 context 一路拉到 1M 的品質曲線。
• 效能證據要看標籤：Tencent 公布的 coding、工具使用、163 人盲測與 31.8% 吞吐提升都值得關注，但仍是廠商自測；公開資料不足以判斷細小差距是否穩健。
• Preview 的名字很誠實：官方主動承認複雜任務可能過度思考、過度驗證；vLLM 與 SGLang 也已有專用 recipe，卻仍處於指定 image／nightly 的首發整合期。

Tencent Hy4 Preview 到底交付了什麼？

官方 model card把模型拆成 770B backbone 與 native MTP。Backbone 每個 token 啟用 49B 參數；MTP 另有約 10B 總參數、啟用時約 0.7B。模型共 78 層，第一層是 dense layer，其餘 77 層是 MoE；每層有 256 個 routed experts 加 1 個 shared expert，每個 token 選 8 個 routed experts。

注意力部分採用 Gated DSA 與 IndexCache。前者把長序列中每個 query 真正要看的 key 壓到稀疏集合，後者再重用跨層索引結果；設計方向很清楚：當 context 變長，不能讓每一層都對全部 token 做同樣昂貴的注意力計算。這些元件有各自的公開論文；截至 2026 年 8 月 31 日，model card 連結的是 DSA 與 IndexCache 元件論文，沒有在該頁列出 Hy4 專屬、含完整訓練與 ablation 的 technical report。

官方 config.json把 max_position_embeddings設為 1,048,576；BF16 與 FP8 權重也都可以直接下載。這些是第三人能核對的 artifact，不只是新聞稿形容詞。

49B active 不等於「只需載入 49B」

MoE 的價值是稀疏計算：對每個 token，只喚醒一部分 expert。這會影響推論時每步要做多少乘加運算，卻不會讓其他 expert 永久消失。下一個 token 可能被路由到不同 expert，整套權重仍要留在 GPU 記憶體、跨 GPU 高速互連可及的位置，或接受速度明顯下降的分層載入。

Hugging Face 檔案清單在 2026 年 8 月 31 日顯示，BF16 safetensors 約 1.56 TB，FP8 repo 約 813.8 GB。這只是 checkpoint 儲存量；真正 serving 還要預留 KV cache、engine workspace 與 CUDA graph 等空間。官方 vLLM recipe列出的也是 B200／B300 級多卡部署。

SGLang cookbook估計 KV／index cache 約需每 token、每個 tensor-parallel rank 95 KB；公開例子包括 16 張 H200 以 BF16 跑 131K、8 張 B200 以 FP8 跑 262K，以及 4 張 B300 以 FP8 跑 262K。MXFP8 路徑要求 SM100 以上 Blackwell，不能直接套到 H200。硬體、精度與 context 任何一項改變，門檻都會跟著變。

因此，「49B active」對雲端供應商與大型研究團隊很有意義：它可能改善單 token 成本與吞吐。但對一般工作站，它不是一張把 780B 級 checkpoint 變成 49B 本機模型的折價券。想先建立顯存、量化與 context 成本的直覺，可接著看 本地 LLM 顯存指南。

自架不是唯一入口。Tencent 表示 Hy4 已接入 WorkBuddy、CodeBuddy、Yuanbao、ima、Tencent Cloud TokenHub 與 OpenRouter；截至 2026 年 8 月 31 日，OpenRouter 的 Tencent Cloud provider列價為每百萬 tokens 輸入 0.834 美元、輸出 2.501 美元、cache read 0.042 美元。發布頁另稱 WorkBuddy 與 CodeBuddy 提供兩週 launch promotion；這是首發期間資訊，不應視為長期方案。對多數開發者，先用 API 跑代表性任務，比直接跨進資料中心級自架更合理。

Benchmark 顯示世代進步，還不能證明全面領先

Tencent 公布的首發圖涵蓋 12 項 coding agent、工具、專業任務與推理評測；在這 12 項 Tencent 自報結果中，Hy4 都高於圖中的 Hy3。這仍不是一個把所有模型放進同一受控流程的實驗：appendix 說帶 *的競品分數才是 Tencent 自測，且不同項目使用不同 reasoning 設定、agent scaffold、timeout 或 judge。尤其多個 agentic rows 衡量的是「模型＋harness＋預算＋評分器」，不能外推成模型本體的全面排名。

Tencent 另報告一場內部盲測：163 名內部專家對 203 個工程任務的模型輸出評分。Hy4 平均 2.99；對 GLM-5.3 為 2.92，勝／和／負 46.8%／12.8%／40.4%；對 Kimi K3 為 2.94，勝／和／負 51.2%／7.9%／40.9%。Hy4 的數字確實較高，但差距很小；公開頁面沒有逐題 prompt、評分 rubric、評分者一致性、變異或 confidence interval，因此無法從目前資料判斷差距是否穩健，更不能把它外推成所有 coding 場景的排名。

這不代表結果沒有價值。真實工程任務往往比單一 benchmark 更貼近產品需求；問題只在證據層級。廠商內部測試適合用來形成下一個可驗證假設，不適合直接當作獨立裁判。近期其他開放權重模型也面臨相同閱讀難題；例如 GLM-5.3 開放權重分析，真正關鍵同樣是把模型規格、運行條件與供應商評測分開。

Tencent Hy4 Preview 的 1M context：能放得下，和能用得好，是兩個問題

一個模型的 context 能力至少有三層：config／API 宣告的窗口、engine 與硬體實際能配置的長度、模型在窗口各位置是否仍能正確檢索與推理。Hy4 Preview 的 config 證明第一層；Tencent TokenHub 的公開規格另列 1M context、最大輸入 960K 與最大輸出 64K。自架方面，SGLang 目前列出的標準配方則是 131,072 或 262,144，尚未展示 1,048,576-token recipe。

品質層更需要一條「長度—正確率」曲線，而不是單一最大值。RULER 論文早已指出，模型標示的 nominal context 往往高於複雜任務中的有效 context；token 越多、干擾項越多，精準檢索與多步推理未必同步維持。這是長 context 模型的通用評估原則，不是對 Hy4 的反證。

首發表格裡的 OneMillionBench也容易望文生義。這個 benchmark 的名稱來自任務所代表的專家勞務價值超過一百萬美元，不是每題都輸入一百萬 tokens。因此它不能單獨證明 Hy4 在全長窗口仍保有相同準確率。

所以更準確的說法是：Tencent Hy4 Preview 已把 1,048,576-token 上限寫進公開 config，TokenHub 也提供接近全窗的 API 介面規格；完整 1M 自架的實用性與模型在窗口各位置的有效推理品質，仍需要公開的 length-sweep 測試與第三方重現。

最有野心的主張，不是 1M，而是模型參與打造自己

Tencent 原文最值得追蹤的一句，其實不是參數量：

“Hy4 preview also contributed to its own development process”

中文：Hy4 Preview 也參與了自身的開發流程。

Tencent 官方發布頁

Tencent 的官方研究頁補充，Hy4 管理多個 Codex sessions，按評估結果調整研究方向；公開例子是一項未具名小模型的 post-training 任務，圖中八項評估都標示正向變化。這支持「模型參與研發協調」的說法，卻沒有把成果綁定到某個 Hy4 checkpoint；單憑公開材料，不能證成 Hy4 已單獨重新訓練自己。

另一張官方圖把推論系統的 baseline 正規化為 100%，列出六輪 kernel、通訊與 graph-capture 相關改動，最後到 131.8%。這些材料支持的是「模型參與研發與推論系統優化迴圈」，尚不足以證成 Hy4 能脫離既定目標、工具與權限邊界，自主改寫並重新訓練自己。官方圖也列出 4K–256K context 與多種 concurrency 的 workload heatmap；但截至 2026 年 8 月 31 日，官方材料未提供可定位的 baseline image tag／digest、GPU 與互連、engine／precision、絕對吞吐、重複測量與誤差，也未公開對應 code／完整 logs。因此 31.8% 只能寫成 Tencent 內部正規化結果，不能當成已獨立重現或可跨部署外推的數字。

這個邊界也能和 Ornith 1.5 自我改進研究一起讀：模型參與迭代足以形成值得測試的研發假說，但單憑這些官方敘述，不能證成模型具備脫離既定目標、工具與權限邊界的自主自我改進能力。真正可累積的能力，來自每輪實驗是否留下可驗證的變更與失敗記錄。

Apache-2.0 很重要，但「開放權重」仍是更精準的名稱

Hy4 Preview 官方 repo 的 LICENSE標示 Apache License 2.0；在該文本中未見另加非商用或特定用途條款。它為已授權 Work 的使用、重製、修改與散布提供標準條款，同時仍有授權副本／notice、修改告知、商標、專利範圍與免責等條款。

不過，license 回答的是已公開檔案可以怎麼用，沒有自動提供足以重建實質等同系統的預訓練資料資訊與 provenance、完整資料治理、訓練程式、run logs 與可重現 pipeline。Open Source Initiative 的 Open Source AI Definition要求提供足夠的資料資訊、完整程式碼與參數，讓具備相關能力的人可以建出實質等同的系統。以 2026 年 8 月 31 日的公開 repo 來看，稱 Hy4 為「Apache-2.0 開放權重模型」最清楚；稱它「整套 AI 系統完全開源」則超出已交付範圍。

Preview 的限制，反而是這次發布最可信的部分

官方 model card 沒有只放漂亮數字，也直接列出已知限制：

“spending longer than necessary reasoning through complex tasks, and a tendency to over-verify its own work.”

中文：處理複雜任務時，可能花比必要更久的時間推理，也傾向過度驗證自己的工作。

Tencent Hy4 Preview model card

這項已知限制可能增加特定代理工作流的輸出 token、延遲或 timeout 風險；影響幅度仍需在固定任務與推理模式下量測。Chat template 提供 high與no_think兩種 reasoning effort；截至 2026 年 8 月 31 日，官方 model card 與連結的部署文件未報告 overthinking 發生率，也沒有提供兩種模式的受控品質比較。

同樣地，vLLM 與 SGLang 已經有官方適配文件，卻不能被簡化成「裝穩定版就能跑」。截至 2026 年 8 月 31 日，vLLM 最新 tagged stable 是 v0.28.0，而 Hy4 recipe 要求最低 v0.29.0、標記 nightly_required: true，並提供專用 hy4-preview image 或 nightly／source-build 路徑。SGLang 最新 tagged stable 是 v0.5.18；cookbook 仍要求專用 image，兩節點 BF16 cells 標為 In Progress，長時間 CUDA graph soak validation 也仍在進行。其 tool parser 已實作，但目前不是 grammar-constrained，tool_choice: required或指定函式不會被強制。這是已有適配、仍需嚴格鎖版本與配置的 Preview 部署狀態。

AlphaLab 的判讀：Hy4 真正改變的是選項，不是結論

我同意什麼

• Hy4 讓高階可下載權重模型多了一個官方 repo 標示 Apache-2.0 的選項。這是今天可直接核對的 LICENSE 與模型檔案，不是 benchmark 行銷形容詞。
• MoE、稀疏注意力與索引重用是合理的長 context 工程方向。模型規模繼續上升時，讓每個 token 只走必要的 expert 與注意力位置，是控制計算成本的核心機制。
• 模型參與研發迴圈值得持續追蹤。公開材料支持模型參與提案、執行、分析與迭代工程實驗；這可能縮短模型與推論系統的優化週期，但尚不足以證成脫離既定權限邊界的自主自我改進。

我存疑什麼

• 1M context 尚未證明是 1M effective context。要看不同長度、不同干擾密度、不同推理深度下的成功率與成本，而不是只看 config。
• 細小的內部盲測領先不能承擔「最佳」結論。如果任務、評分與輸出沒有公開，外界無法判斷差距來自模型、harness、推理預算或抽樣波動。
• 31.8% 還缺可重現邊界。官方圖已列出 4K–256K context、prefill／decode 與不同 concurrency 的相對增益，但未公開可定位的 baseline image tag／digest、硬體、precision 與 runtime、完整 request mix、絕對吞吐、run count 或變異；因此百分比無法轉成你的成本預估，也不能證明改善會出現在別的 engine 或部署環境。

因此，Hy4 Preview 的最佳定位不是「1M context 已被解決」，而是一個授權寬鬆、架構有野心、自行部署硬體門檻極高，且仍需要外部對帳的研究與工程候選。它增加了團隊可測試的選項，沒有替團隊省掉評估。

現在該怎麼做？按你的角色決定

• 應用開發者：先透過託管 API 或小規模代表任務比較，不要為了 1M 標籤直接採購硬體。測試集要包含你真正會用的 coding、tool call、長文檢索與 timeout。
• 基礎設施團隊：把 BF16／FP8 checkpoint、KV cache、網路互連、engine 版本與容錯列成同一張容量表。49B active 只能估計計算路徑，不能替代完整 memory plan。
• 評測團隊：至少做 32K、128K、262K、512K、1M 的 length sweep，固定 harness 與推理預算，分別記錄成功率、首 token 延遲、輸出速度、token 用量與失敗類型。
• 研究者：優先追問 self-improvement loop 的可審計 artifact：提案、實驗、拒絕、回滾與跨環境重現。這比再比較一張供應商總榜更能判斷機制是否成立。

如果你要自行設計模型評測，可參考 Terminal-Bench 科學化評測教學：先固定任務、harness 與成本，再談誰贏。若要保存這類大型開放權重 artifact，Hugging Face 離線備份指南則能幫你把版本與檔案來源固定下來。