剛剛，MiniMax M3 正式官宣發布。

根據官方介紹，MiniMax M3 是國內首個同時具備「Coding Frontier+ 1M 上下文窗口 + 原生多模態」三個核心能力的開源模型，同時還推出了配套代碼智能體產品 MiniMax Code。不過，開發者體驗下來，M3 的體感全面超過Sonnet 4.6，但官方坦誠表示，其與 Opus 4.7、GPT-5.5 仍存在一定差距。

具體來說，在 SWE-Bench Pro 上超過了 GPT-5.5 和 Gemini 3.1 Pro，接近 Claude Opus 4.7。而在面向自主 Agent的端到端評測 Claw-Eval 上，M3 拿到了最高分。

更為重要的是，在此之前，能同時跑通這三項的只有極少數閉源模型，例如 claude opus 4.8、gemini 3.1、gpt5.5；而 MiniMax M3 是第一個把完整 frontier 能力帶進開放世界的模型。

也就是說，M3 的真正難點不在于單項能力的突破，而在于讓三項能力在同一個模型中協同工作，但長程 Agent 任務需要超長上下文支撐；多模態理解能力影響論文復現、代碼審查等復雜場景的上限；而編程能力則直接決定了 Agent 的自主執行質量，任何一項的短板，都會拖垮整體表現。

那么，在“集齊”敘事之后，M3 在技術路徑上做了哪些關鍵選擇？這些選擇背后的理念是什么？實際效果如何？

為什么 Frontier Agent 必須同時具備三項能力？

如果只看單輪問答，模型能力可以被拆成文本、代碼、視覺等多個獨立維度。但 Agent 場景不是這樣。

一個真實的軟件工程任務里，模型要處理的信息通常包括：

• 代碼倉庫結構、依賴關系和歷史實現；

• README、issue、PR、測試腳本和報錯日志；

• 用戶多輪反饋、方案變更和臨時約束；

• 論文圖表、產品截圖、設計稿、表格和桌面應用界面；

• 工具調用軌跡、失敗記錄和中間產物。

這意味著 Coding、長上下文、多模態不是三個并列賣點，而是一個系統能力的三個接口。

圖 1：MiniMax M3 的三塊 Agent 地基

所以 M3 的技術敘事不是“某項能力很強”，而是這三項能力開始在一個國產開源模型中匯合。

MSA：1M 上下文的關鍵不是窗口，而是注意力計算

長上下文的難點從來不是把 context_length 寫成 1M，而是如何在 1M token 下仍然算得動、跑得快、找得準。

標準 Transformer 的全注意力需要讓每個 query 關注所有 key。序列長度增長時，注意力計算量按近似平方級上升。窗口從 128K 擴到 1M，不是多買幾張卡就能解決的問題，必須在注意力機制上動刀。

MiniMax 給出的答案是MSA，MiniMax Sparse Attention。架構如下圖：

官方披露的 MSA 有三個關鍵詞：

• 稀疏注意力：通過篩選機制避免全量 token 兩兩交互；

• 更精確的 KV 分塊：相比 DSA、MoBA 等方案，提高有效上下文覆蓋；

• 硬件友好算子：采用 KV outer gather Q，以 KV 塊為外層聚合命中的 query，使每塊 KV 只讀一次、訪存更連續。

官方數據稱，在 100 萬上下文下，M3 每 token 計算量僅為上代模型的 1/20；prefilling 階段超過 9 倍加速，decoding 階段超過 15 倍加速；在 M3 的 head 配比下，算子比開源 Flash-Sparse-Attention、flash-moba 快 4 倍以上。

這組數字真正重要的地方不是“快了多少”，而是說明 MiniMax 把長上下文問題同時放在了兩個層面解決：

• 算法層：減少不必要的注意力連接；

• 系統層：讓剩下的連接更適合 GPU 執行。

圖 2：稀疏注意力路線對比

1. 從固定稀疏到動態稀疏：國際前沿的共同方向

稀疏注意力不是新概念。Longformer、BigBird 這類早期方案通過滑動窗口、全局 token、隨機連接等固定模式降低復雜度。它們證明了“不是所有 token 都必須互相關注”，但問題是固定模式很難適配真實任務。

代碼倉庫、論文、終端日志這類上下文沒有穩定結構。關鍵 token 可能出現在幾千行之前，也可能藏在某個工具輸出里。固定窗口容易漏掉遠距離依賴。

因此，近年的前沿方向明顯轉向動態稀疏：讓模型或檢索模塊根據輸入內容決定應該看哪里。

DeepSeek 的 DSA、Moonshot / Kimi 相關工作中的 MoBA、以及更通用的 NSA、SeerAttention 等研究，都在探索“先篩選，再精算”的路線。M3 的 MSA 也處在這條技術主線上。

如上表，MSA 的差異化不是“稀疏”本身，而是兩個更工程化的問題：

第一，稀疏之后到底能不能找準？如果篩選機制漏掉關鍵上下文，長窗口越長，模型越容易出現“看似讀了很多，其實沒看對”的問題。

第二，找準之后能不能高效算？稀疏注意力會帶來不規則訪存。如果實現方式讓 GPU 頻繁隨機讀取、重復加載 KV 塊，理論計算量下降也未必轉化成真實速度。

MSA 試圖同時回答這兩個問題：用更精確的 KV 分塊解決有效覆蓋，用 KV 外層聚合命中 query 的方式解決訪存效率。

2、MSA 與 DeepSeek、Kimi 路線的共識與非共識

從公開資料來看，M3、DeepSeek、Kimi 等長上下文模型已經形成幾個共識。

共識一：全注意力不適合無腦擴到百萬級上下文。百萬 token 下繼續依賴全注意力，成本、延遲和顯存都會失控。稀疏化是通向可用長上下文的主路線之一。

共識二：稀疏不能只是固定窗口。Agent 任務的關鍵依賴非常不規則。單純滑窗或固定塊很難處理跨文件引用、長日志回溯和多輪用戶約束。

共識三：長上下文必須軟硬結合。算法節省計算只是第一步，GPU 訪存、kernel 調度、prefill/decode 分離優化，都會直接決定最終體驗。

不同點在于，幾條路線對“稀疏粒度”和“硬件執行順序”的取舍不一樣。

如果用一句話概括： DSA 更強調“選哪些 token / KV”，MoBA 更強調“選哪些塊”，MSA 則把“怎么分塊、怎么讀塊、怎么讓 GPU 連續高效地算”放到了前臺。

這正是 MSA 比較值得關注的地方。過去很多長上下文方案容易停留在算法敘事，但目前披露的MSA信息中，把算子層實現當成核心賣點。這更接近產業模型的真實需求：模型要被大量用戶和 Agent 長時間調用，最終必須算得便宜、跑得穩定。

3、1M 上下文真正要測什么？

M3 的 1M 版本還未正式開放，因此不能提前下結論。但等上線后，真正應該測的不是“能不能塞進 1M token”，而是以下幾類任務：

如果 M3 在這些任務上穩定，1M 上下文才不只是窗口參數，而是可被 Agent 真實使用的工作記憶。

原生多模態：不是“看圖插件”，而是統一 token 空間

M3 的第二條技術主線是原生多模態。MiniMax 披露，M3 從 Step 0 開始做多模態混合訓練，支持圖片和視頻輸入，并能操作電腦桌面。

這和“文本大模型 + 外接視覺編碼器”的思路不同。

外接式多模態通常是先訓練一個強文本模型，再用視覺編碼器、投影層或適配器把圖像特征接進去。這條路線工程上高效，但模態之間的語義對齊更多發生在后期。

原生多模態則希望在訓練早期就讓文本、圖像、視頻等信息進入同一建模過程。模型不是先成為文本專家，再學習“看圖”，而是一開始就學習混合模態序列中的規律。

圖 3：原生多模態與后接式方案對比

M3 特別強調了interleaved data，也就是文本、圖片等模態在同一序列中自然交錯的數據。MiniMax 稱，在重構數據管線后，訓練數據 token 規模已可提升至 100 萬億量級。

這個判斷與國際多模態研究的趨勢一致。Flamingo、Chameleon、Emu3 等工作都在不同方向上證明，交錯圖文、早期融合、統一 next-token 建模對通用多模態能力有價值。

原生多模態對 Coding Agent 的意義很直接。

今天的開發任務不是純文本。用戶會給模型設計稿截圖、控制臺截圖、論文曲線圖、網頁錄屏、Excel 表格和桌面應用界面。模型如果只能把這些輸入轉成一段 caption，再交給文本模型推理，信息會在轉換過程中損失。

M3 的論文復現案例就說明了這一點。復現一篇機器學習論文，不只是讀 PDF 正文，還要理解圖表趨勢、公式關系、實驗設置、代碼實現和輸出日志。長上下文讓這些信息能放在同一線程里，原生多模態讓模型有機會在同一語義空間里處理它們。

MiniMax 把一篇 ICLR 2025 Outstanding Paper Award 獲獎論文扔給它，這篇論文研究的是大模型微調過程中的學習動力學。M3 自主運行了接近 12 小時，全程自主產出 18 次 commit 與 23 張實驗圖表，并跑通了核心實驗：不僅成功吻合了 SFT 階段的預測概率變化趨勢，清晰觀測到 DPO 實驗重點討論的squeezing 效應，還順利驗證了原論文提出的 Extend 緩解方法。

換句話說，原生多模態不是“模型能不能看圖”的問題，而是 Agent 能不能理解真實工作現場的問題。

交互式用戶模擬器：Coding SOTA 的訓練范式變化

M3 第三條技術主線是 Coding / Agentic 能力。

官方給出的 M3 成績包括：

但對技術受眾來說，更值得關注的不是這些數字本身，而是 MiniMax 對 Coding 訓練范式的判斷。

當前大部分 Coding Benchmark 仍然偏單輪任務：給模型一個 issue 或需求，讓它一次性修復。這個設定有價值，但和真實開發體驗有距離。

真實開發通常是多輪協作：

• 用戶先提出一個不完整需求；

• Agent 需要讀項目、提出方案、執行修改；

• 運行測試后發現新錯誤；

• 用戶補充約束或改變優先級；

• Agent 需要保留前文狀態，重新規劃任務；

• 多輪之后交付一個可運行結果。

MiniMax 因此構建了交互式用戶模擬器框架，讓模型在訓練和評測階段接觸更接近生產環境的行為模式，包括需求補充、方案討論、反饋修正、連續任務切換和復雜項目迭代。

圖 4：交互式用戶模擬器閉環

這代表了一個重要變化：Coding Agent 的訓練目標正在從“生成正確代碼”轉向“完成長期協作任務”。為此，MiniMax 也用幾道題目測試了它的實際表現。

FP8 矩陣乘（GEMM）是大模型推理中計算量最集中的環節之一，也是優化難度最高的之一。通常需要資深團隊1-2 周的投入。

MiniMax 把這道題丟給 M3，起點只有一份任務描述、一個 benchmark 腳本、一個跑不起來的 Triton 骨架，沒有任何 reference 高性能實現可供參考。但在隨后約 24 小時的連續執行中，M3 共完成 147 次 benchmark 提交、1959 次工具調用，完全自主地走完了從 baseline 實現到生產級優化的全部路徑。

最終M3 經過 6 輪標志性優化，將 Hopper FP8 硬件峰值利用率從首版 7.6% 推進至 71.3%，實現相較于原始版本的 9.4× 加速。

除此之外，MiniMax 還能自己訓練模型。

MiniMax 在 PostTrainBench 上讓它接手四個只完成預訓練的 Base 模型，任務是在 12 小時內自主完成數據合成、訓練、評測、迭代的全部流程，最終讓這些模型在數學推理、工具調用、科學知識推理、代碼生成等任務上具備基本能力。

整個流程全程無人干預，M3 需要自己決定合成什么樣的數據、選擇什么訓練策略、如何根據評測結果調整下一輪方案。M3 最終得分 0.37，略低于 Opus 4.7（0.42）和 GPT-5.5（0.39），但明顯領先其余模型。

以上幾個長程案例都在說明，成功不取決于一次輸出，而取決于長時間閉環：計劃、執行、驗證、修正，再繼續執行。

這也是為什么 MSA 和交互式訓練要放在一起看。沒有長上下文，模型很難記住長程工具軌跡；沒有真實交互式訓練，長上下文也可能只是“更大的輸入框，不會自動變成穩定協作能力。

M3 的下一步是做你的“AI同事？”

M3 這次發布同時更新了 MiniMax Code。MiniMax Code 被定位為專為 M3 設計、并與 M3 一起訓練的 Agent 產品，目標是對標 Claude Code / Codex。

這點不只是產品信息，也解釋了 M3 的技術取舍。

如果目標只是聊天，1M 上下文、原生視頻輸入、長期工具調用訓練都不是最高優先級。但如果目標是 Coding Agent，三者就是剛需。

這也解釋了為什么 M3 的成本結構值得關注。Agent 調用天然消耗大量 token：它要讀倉庫、掃日志、反復運行測試、生成 diff、總結失敗原因。如果模型能力接近前沿，但調用成本仍然很高，就很難成為日常工具。

MiniMax 新 Token Plan 給出的價格是：

以 Max 套餐為例，每月 119 元可獲得 18億+ token，對比來看，Claude Max 套餐每月 100 美元（約合人民幣 720 元）提供約 9 億 token，同價位下 M3 的 Token 容量約為其 2 倍；而 DeepSeek API 按量計費的價格為每百萬 Token 2 元（輸入）/ 8 元（輸出），M3 Max 套餐的均攤成本同樣顯著更低。

這樣親民的定價，讓 1M 上下文更加普惠適用，更貼合開發者的真實需求。

這意味著 M3 的競爭策略不是只拼“最強模型”，而是拼一個更完整的工程組合：足夠前沿的能力、足夠長的上下文、足夠低的 token 成本、以及專門適配模型的 Agent 產品。

MSA之后，長上下文的故事講到了哪？

MiniMax M3 最值得討論的地方，是它把國產開源模型帶進了 Frontier Agent 的主戰場。

MSA 回答了百萬級上下文如何可用化的問題；原生多模態回答了模型如何理解真實工作環境的問題；交互式用戶模擬器回答了 Coding Agent 如何從單輪代碼生成走向長期協作的問題。

這三條線合在一起，M3 的定位就很清楚：它不僅僅局限于聊天工具，而是一個可以幫你啃下百萬字代碼庫、獨立復現頂會論文、在24小時內自主迭代上千次優化內核的AI搭子。

Opus 仍然很強，GPT 和 Gemini 仍然是前沿閉源模型的重要參照。但 M3 的出現意味著，國產開源模型第一次在 Coding Frontier、1M 上下文和原生多模態三個關鍵維度上同時進入牌桌。

但可以肯定的是，M3 把過去屬于少數閉源旗艦的 Frontier 能力，第一次完整地、免費地、可部署地交到了全球開發者手中。

這本身就是一種進步。