小米 HySparse2：共享 KV 快取，長文本檢索也不落下

多輪 AI 代理程式常會把工具回傳的大段內容接在既有對話後面。歷史愈長，模型處理新一輪輸入時的「預填充」（prefill）負擔就愈重；但若只顧節省運算，又可能漏掉前面的重要資訊。小米提出的 HySparse2，目標正是同時壓低長上下文的處理與快取成本，並保留檢索近期和遠處 Token 的能力。這是與 MiMo-V3 規劃相關的架構研究，不是 MiMo-V3 新開放權重版本已發布的證據。34

長輸入為何不必跑完整個解碼器？

HySparse2 採用類似 YOCO 的兩段式設計：自解碼器（self-decoder）先處理長輸入，後面的交叉解碼器（cross-decoder）則透過 KV 橋接（KV Bridging），讓全注意力層利用自解碼器的隱藏狀態建立鍵與值（K/V）。因此，對已存在的長上下文進行預填充時，流程可在自解碼器完成後停止，不必再讓整段輸入跑過交叉解碼器；模型接著產生新 Token 時，交叉解碼器仍會參與運算。4615

第二層共享發生在交叉解碼器內：每個混合區塊的稀疏層，透過 KV 重用（KV Reuse）沿用前一個全注意力層的 KV 快取與 Token 選取索引。HySparse2 按單一 Token、而非整個區塊挑選內容，並強制把近期 Token 納入選取，取代獨立的滑動視窗注意力分支。這讓近期內容與選中的遠處內容共用快取，減少重複儲存和選取工作。4615

數字說明了什麼？

在一組配置相當的混合專家模型（MoE）比較中，模型總參數為 800 億，每個 Token 約啟用 30 億參數。當上下文長達 100 萬 Token，HySparse2 的預填充浮點運算量（FLOPs）降至 Hybrid SWA 的 1/5.02；報告中的 KV 快取大小為 2.69 GB，對照組為 12.09 GB，約縮小 4.5 倍。小米也報告，HySparse2 的 MRCRv2、RULER-v2 長文本檢索分數較高，AgentPPL 與 LongPPL 較低；相關評估報導指出，它在所評測的長文本檢索測試中領先 HySparse 與 Hybrid SWA。615

一項消融比較固定了模型骨幹和注意力預算，只將「按區塊選取」改成「按 Token 選取」。在 3.2 萬 Token 以下或等於 3.2 萬 Token 的測試中，RULER-v2 提高 6.57 個百分點、雙線索 MRCR-v2 提高 8.14 個百分點、GraphWalks 提高 5.55 個百分點。這支持更細緻的選取方式在該設定下有幫助，但不能把提升全數歸功於 KV 橋接、KV 重用或近期 Token 強制窗口中的任何一項。6

**解讀時仍須留意邊界：**現有引述資料不足以給出 HySparse 與 HySparse2 在百萬 Token 下的數值差距、各機制逐項帶來的增益，或確認同樣改善已在更大規模模型上重現。資料也未交代 2.69 GB 快取數字所用的精度，不能稱它是已核實的 FP8 測量值；預填充 FLOPs 與快取容量，更不等於實際部署環境測得的延遲。615