HySparse2：百萬 Token 預填充點樣慳，舊資料又點樣搵得返？

Agent 連續幾輪工作時，往往只輸出一小段操作，卻會從工具收回大量網頁、程式碼或記錄。對話歷史愈積愈長，模型每次處理這些輸入，運算和記憶體開銷都會上升。小米提出的 HySparse2，想解決的正是這個問題：減少處理長輸入的成本，同時仍能檢索近期和較早之前的內容。現階段公布的是與 MiMo-V3 規劃相關的架構研究，不能當作 MiMo-V3 已有新一輪開放權重推出。34

長輸入點解可以少行半段？

HySparse2 沿用 YOCO 式分工，把模型分成前段的自解碼器（self-decoder）和後段的交叉解碼器（cross-decoder）。前段先處理長輸入；透過 KV Bridging（KV 橋接），後段的全注意力層會利用前段產生的隱藏狀態建立 key 和 value（KV）。既然後段所需的 KV 可由前段狀態取得，對已有長文本做「預填充」（prefill，即生成回答前處理輸入）的流程，便可以在自解碼器完成後停下，不用再把整段舊輸入送過交叉解碼器。模型之後生成新 Token 時，交叉解碼器仍會參與運算。4615

第二層共享是 KV Reuse（KV 重用）：在交叉解碼器的每個混合區塊內，稀疏注意力層會重用前一個全注意力層的 KV 快取，以及已選好哪些 Token 的索引，減少重複儲存和選取工作。HySparse2 改為逐個 Token 選取，而非按整塊選；它亦強制把近期 Token 納入選擇，取代獨立的滑動窗口注意力分支。這樣，近期內容和被選中的遠處內容可以共用同一套快取，而非為了慳資源就放棄眼前的上下文。4615

慳幾多？檢索有冇受影響？

在一組對齊配置的混合專家模型（MoE）比較中，模型總參數為 80B（800 億），每個 Token 約啟用 3B（30 億） 參數。按報告數字，在 100 萬 Token 長度下，HySparse2 的預填充運算量（FLOPs）比 Hybrid SWA 低 5.02 倍；KV 快取為 2.69 GB，對比 12.09 GB，約小 4.5 倍。小米亦報告，HySparse2 的 MRCRv2、RULER-v2 長文本檢索分數較高，AgentPPL 和 LongPPL 較低；對測試結果的報道指，它在受評估的長文本檢索測試中領先 HySparse 和 Hybrid SWA。615

一項消融測試進一步比較「按塊選」和「逐 Token 選」：在保持模型骨幹與注意力預算相同、測試長度為 32k Token 或以下的條件下，逐 Token 選擇令 RULER-v2 提高 6.57 個百分點、雙線索 MRCR-v2 提高 8.14 個百分點、GraphWalks 提高 5.55 個百分點。這支持較細緻選取在該設定下有幫助，但不能據此把增益分別歸功於 KV Bridging、KV Reuse 或近期 Token 強制窗口。6

這些數字亦有清楚界線：現有資料不足以列出 HySparse 與 HySparse2 在 100 萬 Token 下的數值差距，或確認同等改善已在更大模型規模重現。所引資料沒有交代 2.69 GB 的快取數字採用甚麼精度，因此不能稱它為已核實的 FP8 快取量測。最後，預填充 FLOPs 和快取大小並不等於實際部署時量到的延遲。615