MiniMax Sparse Attention，簡稱MSA，是MiniMax在M3模型中提出的長上下文稀疏注意力架構。它先從大量KV區塊中選出和當前Query更相關的部分，再只對這些區塊執行精確注意力，避免100萬Token序列在每一層都進行完整兩兩計算。
MSA的目標不是讓模型「記得所有內容」，而是讓長Context的Prefill、Decode、記憶體存取與硬體利用更可負擔。模型是否真的找到正確資訊，仍取決於訓練、檢索、Context組裝與外部驗證。
重點快讀
- MSA先篩選KV Blocks，再對候選區塊計算注意力。
- MiniMax M3 API支援最高1M Context，官方保證至少512K可用範圍。
- 官方表示1M時每Token計算約為前代的1／20，Prefill快9倍以上、Decode快15倍以上。
- 這些倍率來自MiniMax自身系統與測試，部署結果會受硬體、Batch與序列分布影響。
- MSA降低注意力成本，不取代RAG、來源、版本、權限與Citation。
- M3目前可透過API、Token Plan與MiniMax Code使用；完整開放權重仍標示為即將推出。
Full Attention為何在1M Context變昂貴？
Full Attention需要讓每個Query和大量Key建立關係。序列長度增加時，Prefill計算與KV Cache都快速成長。對Agent而言，Context還會包含Tool Result、程式、圖片描述、日誌與長時間Task State，成本很容易超出單次文件問答。
- Prefill：模型第一次讀取整段Prompt。
- Decode：生成每個新Token時查詢既有KV。
- KV Cache：保存歷史Token的注意力狀態。
- Memory Bandwidth：長序列時反覆讀取大量KV。
- Tail Latency：超長請求可能阻塞短請求。
長Context瓶頸不只在FLOPs，也在HBM容量、I/O與多卡通訊。MSA把注意力從「全部讀取」改成「先選區塊，再集中讀取」。
MSA的兩個主要步驟
1. KV Block選擇
MSA把歷史KV分成區塊，使用選擇機制判斷哪些Block和目前Query最相關。只有被選中的區塊進入後續注意力計算。這和固定滑動視窗不同：滑動視窗主要看附近Token，MSA則能依內容選擇較遠位置。
2. 精確注意力
候選區塊確定後，模型對較小集合執行精確Attention。選擇器若漏掉關鍵區塊，後段計算再精確也無法補回，因此稀疏策略需要同時評估效率與Recall。
Full Attention:
Query → all KV tokens → attention
MSA:
Query → block selector → selected KV blocks → attentionKV Outer Gather Q是什麼？
MiniMax表示，MSA在Operator層使用「KV Outer Gather Q」：以KV Block作為外層迴圈，聚合命中該Block的Queries。每個Block只需連續讀取一次，再處理多個Query，提高Memory Access連續性與Arithmetic Intensity。
一般實作若每個Query各自Gather KV，可能反覆讀取相同Block並造成離散記憶體存取。KV Outer方式試圖讓硬體真正取得稀疏注意力的理論效益，而不只減少數學運算量。
官方效能數字怎麼解讀？
| 官方敘述 | 代表意義 | 驗證注意 |
|---|---|---|
| 每Token計算約前代1／20 | 稀疏Attention大幅降低長序列工作 | 需確認比較模型、硬體與Context |
| Prefill快9倍以上 | 大型Prompt首次讀取縮短 | 受Input Length、Batch與Cache影響 |
| Decode快15倍以上 | 長Context下每Token讀取更有效率 | 受Output、KV分布與Kernel影響 |
| Operator快4倍以上 | 硬體友善實作優於比較Kernel | 不等於完整API任務快4倍 |
這些數字來自MiniMax官方測試，適合說明設計方向，不能直接當成所有雲端、GPU與流量的SLA。企業應使用自己的Context分布、Concurrency與Output Length重跑。
MSA和其他長Context方法差在哪？
| 方法 | 核心 | 主要限制 |
|---|---|---|
| Full Attention | 所有Token精確互看 | 長序列成本高 |
| Sliding Window | 主要關注固定附近範圍 | 遠距資訊需全域層補足 |
| 線性注意力 | 用狀態或Kernel壓縮歷史 | 精確Recall與訓練較困難 |
| 內容式稀疏Attention | 依Query選擇重要Block | Selector錯誤會漏資訊 |
| RAG | 模型外檢索文件片段 | Retriever與Chunk可能失敗 |
MSA屬於模型內部內容式稀疏注意力。它可以和RAG、Context Cache、Artifact及外部Memory同時使用，不需要二選一。
1M Context適合哪些Agent工作？
- 大型Repository與跨模組依賴。
- 數百次工具呼叫形成的結構化Trace。
- 長影片、圖片與文字混合分析。
- 多份研究、財務與法律文件。
- 長時間Coding與多輪測試結果。
- 需要保留完整歷史再局部查詢的Task。
即使Attention更省，錯誤、過期與越權資料仍會進入Context。長視窗放大了資料品質問題，因此需要更嚴格的Context Manifest、Source、Valid Time與Permission。
MSA不會取代RAG
RAG回答哪些外部文件應進入模型；MSA回答已進入長序列後，哪些KV區塊需要被注意。兩者位於不同層級。
| 需求 | 較適合 |
|---|---|
| 知識庫有數百萬文件 | RAG先縮小範圍 |
| 同一大型Repository要反覆查詢 | 檔案搜尋加長Context |
| 需要完整來源與版本 | RAG／Context Graph |
| 長Tool Trace要保留關係 | MSA長Context加Compaction |
| 固定大前綴反覆使用 | Context Cache |
企業文件治理可閱讀企業知識文件怎麼進入RAG？。
MiniMax M3的多模態位置
M3從預訓練開始進行原生多模態訓練，可接收圖片與影片，並能操作桌面環境。長Context因此不只保存文字，也可能包含視覺Token、截圖、工具結果與Computer Use歷史。
- 圖片和影片Token會增加Context成本。
- 截圖可能包含帳號、客戶與內部系統資料。
- Computer Use動作需要外部Policy與人工Gate。
- 視覺理解仍要用已知答案樣本測試。
- 多模態輸入應保留原始Artifact和位置。
如何建立長Context Benchmark？
- 準備32K、128K、512K與1M不同長度。
- 把答案分布在開頭、中段、結尾與跨段關係。
- 加入不存在答案與互相衝突資料。
- 測單輪問答、多輪Agent與工具Trace。
- 記錄TTFT、完整Latency、Input與Output Token。
- 比較Full Context、RAG、摘要與混合策略。
- 檢查Citation、版本與人工修改。
| 指標 | 用途 |
|---|---|
| Needle Recall | 能否找到指定事實 |
| Relational Accuracy | 能否連接跨段資訊 |
| Conflict Handling | 能否辨識矛盾與時間 |
| Abstention | 沒有答案時是否拒答 |
| TTFT／TPOT | Prefill與生成體驗 |
| Cost per Accepted Task | 長Context是否值得 |
部署與開放狀態
MiniMax M3目前可透過MiniMax Code、Token Plan與API使用。官方模型頁表示完整開放權重和私有叢集部署將在後續提供；在正式權重、授權與推論Kernel出現前，不應把它描述成已能完整本地部署。
API目前支援最高1M Context，官方表示至少保證512K。實際產品要檢查Account、Endpoint、Input類型、Rate Limit、Retention與地區。
常見問題
MSA是MoE嗎？
不是。MSA選擇哪些KV區塊參與注意力；MoE選擇哪些前饋專家處理Token。
1M Context一定比RAG好嗎？
不一定。大量知識庫仍需要RAG縮小候選；長Context適合保留一個大型工作集合和跨段關係。
MiniMax M3已經能本地部署嗎？
官方已建立公開Repository並宣告將完整開源，但模型頁仍寫「soon」。正式自架需要等待權重、授權、Kernel與部署指南。
官方資料
MSA把長上下文競爭從「可以放多少Token」推向「模型能否用硬體友善方式找到需要的區塊」。它提高長任務的可行性，真正品質仍要由資料、Context、Tools與驗收決定。
發表迴響