小米公開 HySparse2，百萬 token 預填充運算量降至基準約五分之一

小米 MiMo 團隊的羅福莉於 9 月 23 日公開介紹 HySparse2，並將其定位為 MiMo-V3 的核心架構。研究針對代理常見的輸入負載：模型只輸出短指令，工具卻回傳大量文件、網頁與執行紀錄，讓每輪預填充及歷史快取成本增加。相關論文已於 9 月 22 日提交。[作者公告鏡像](https://twstalker.com/_LuoFuli)、[論文紀錄](https://arxiv.org/abs/2609.26368)

HySparse2 把模型分成自解碼器與交叉解碼器，外層的 KV Bridging 讓後半部全注意力層，從前半部的隱藏狀態投影出鍵值快取；內層則把全注意力層的快取與選取索引，交給後續稀疏層重用。如此一來，建立輸入快取所需的資訊可提前備齊，預填充能在自解碼器完成後結束。[作者架構說明](https://twstalker.com/_LuoFuli)

另一項調整是把整塊選取改成逐 token 選取，並將近期上下文強制納入稀疏注意力，取代原本獨立的滑動視窗分支。這讓局部與遠端資訊共用快取，也減少為取得少數相關位置而讀入整塊鄰近內容的浪費。[作者技術說明](https://twstalker.com/_LuoFuli)

論文比較三種總參數 800 億、每 token 啟用約 30 億參數的 MoE 配置。百萬 token、FP8 快取條件下，HySparse2 的預填充浮點運算量約為 Hybrid SWA 的五分之一，KV 快取由 12.09 GB 降至 2.69 GB。不過，配置同時由 GQA 改為 MQA，快取收益不能全部歸因於跨層共享。[實驗設定與分析](https://arxiv.org/html/2609.26368v1)

品質結果也需要分開看：後訓練後的長上下文評估最高到 256k，該長度的 RULER-v2 得分為 58.45，Hybrid SWA 為 35.74；一般推理與程式能力則有升有降。百萬 token 對應的是資源分析，論文並未以同長度的品質測試證實完整可用性。[評測結果](https://arxiv.org/html/2609.26368v1)

對推論系統工程師而言，這提供了縮短長輸入處理路徑的設計方向。但五倍差距是運算量分析，實際延遲仍受核心效率、資料搬移與排程影響。後續應觀察可重現實作、真實多輪任務成功率及首 token 延遲。依這些條件推論，部署評估也應記錄批次大小與工具回傳長度，並檢查中文文件及跨檔案程式任務，避免只用合成檢索分數推估代理的實際完成能力。