MiniMax M3 發布：程式碼 Agent、1M 上下文和原生多模態

Mon, 01 Jun 2026 09:00:00 +0800

MiniMax 在 2026 年 6 月 1 日發布了 MiniMax M3。從官方介紹看，M3 的定位很清楚：面向程式碼、Agent 和長上下文任務，同時加入原生多模態能力。

這次發布最值得關注的不是單一跑分，而是 MiniMax 把三類能力放到同一個模型裡：

程式碼與 Agent 任務能力；
最高 1M tokens 上下文視窗；
原生多模態，支援圖像和影片輸入；
計畫開放權重，支援後續私有化部署和微調。

如果你正在關注國產模型在程式設計助手、自動化工作流、長文件處理和多模態理解上的進展，M3 值得單獨看一下。

M3 的核心定位

MiniMax 對 M3 的表述是：程式碼與 Agent 前沿模型，1M 上下文，原生多模態。

這幾個關鍵詞對應的是實際使用裡的幾個痛點：

程式碼任務不只是補全函式，還需要讀專案、改檔案、執行工具、修復錯誤；
Agent 任務會產生大量工具呼叫記錄、日誌和中間結果；
長文件、長影片、完整程式碼庫都需要更大的上下文視窗；
圖表、截圖、公式、影片幀等內容，不能只靠純文字理解。

因此 M3 更像是給「長鏈路任務」準備的模型，而不是只面向普通聊天或短文字生成。

1M 上下文來自 MSA 架構

M3 使用 MiniMax 自研的 MSA，也就是 MiniMax Sparse Attention。官方解釋裡，MSA 的目標是解決傳統全注意力在長上下文下計算複雜度快速膨脹的問題。

簡單說，全注意力在上下文變長時成本上升很快。MSA 透過稀疏注意力和更適合硬體執行的 KV block 存取方式，讓模型在長上下文場景下更容易擴展。

官方稱，M3 API 支援最高 1M tokens 上下文，並保證最低 512K tokens。這對幾類任務很有意義：

讀取完整專案或大型模組；
處理長研究報告、合約、日誌和知識庫材料；
保留多輪 Agent 執行過程中的工具呼叫記錄；
分析長影片或多模態材料。

不過要注意，長上下文並不等於所有任務都應該塞滿上下文。實際使用時，檢索、分塊、快取和任務拆分仍然重要。1M 上下文更像是給複雜任務提供上限，而不是替代工程設計。

程式碼和 Agent 是重點

官方報告裡，M3 在多個程式碼與 Agent benchmark 上給出了成績，包括：

Benchmark	官方公布成績
SWE-Bench Pro	`59.0%`
Terminal-Bench 2.1	`66.0%`
SWE-fficiency	`34.8%`
KernelBench Hard	`28.8%`
MCP Atlas	`74.2%`

這些數字可以作為參考，但不建議只看榜單下結論。更值得注意的是 MiniMax 把 M3 的訓練和評估重點放在更接近真實協作的 Agent 場景上。

真實的程式碼工作並不是「一句話生成一個函式」。它通常包括：

反覆釐清需求；
閱讀既有程式碼；
制定修改計畫；
執行命令和測試；
根據錯誤繼續修；
在多輪上下文裡保留決策依據。

這也是 M3 和 MiniMax Code 綁定發布的原因。模型能力只是底層，真正能不能完成工程任務，還要看外層 Agent harness、工具呼叫、上下文管理和驗證流程。

官方展示的幾個長鏈路任務

MiniMax 在報告裡列了幾個更接近真實工作的案例。

第一個是論文復現。官方讓 M3 獨立復現一篇 ICLR 2025 Outstanding Paper。M3 連續運行接近 12 小時，產生 18 次 commit 和 23 張實驗圖，完成了核心實驗復現。

這個案例的重點不是「會寫論文摘要」，而是它同時用到了：

多模態能力，理解論文裡的曲線、公式和圖表；
長上下文，把論文、程式碼和實驗日誌放進同一任務鏈路；
程式碼與 Agent 能力，持續運行、實驗、驗證和修正。

第二個是 CUDA kernel 優化。官方讓 M3 從一個不能直接執行的 Triton 骨架開始，優化 NVIDIA Hopper GPU 上的 FP8 GEMM kernel。M3 在約 24 小時裡完成 147 次 benchmark submission 和 1,959 次工具呼叫，把硬體峰值利用率從 7.6% 提升到 71.3%，相當於 9.4x 加速。

這個案例說明 M3 更強調長時間自主迭代。普通程式碼生成模型往往在前幾輪失敗後就停住，而 Agent 型模型需要能持續根據回饋調整方向。

第三個是讓 M3 自主訓練模型。官方在 PostTrainBench 中給 M3 四個只完成預訓練的 base model，讓它在 12 小時內完成資料合成、訓練、評估和迭代。最終 M3 得分 0.37，低於 Opus 4.7 和 GPT-5.5，但明顯領先其他模型。

這些案例都來自 MiniMax 官方測試，不能直接等同於第三方獨立評測結果。但它們能說明 M3 的產品方向：把模型放進長週期、可驗證、有回饋的任務循環裡。

原生多模態的意義

M3 不是在文字模型後面簡單外掛視覺能力。官方稱它從訓練早期就進行混合模態訓練，並重建了資料管線，把訓練資料擴展到 100T+ 級別。

對開發者來說，多模態的價值主要在這些場景：

讀取截圖、圖表、公式和設計稿；
分析 PDF、論文、報告和實驗圖；
理解長影片中的畫面變化；
在桌面自動化任務中識別介面元素。

MiniMax Code 也圍繞這一點做了產品化。官方提到，MiniMax Code 可以結合 M3 的多模態能力做 computer use，例如根據表格內容跨應用批量錄入資訊。

MiniMax Code 與 Agent Team

隨著 M3 發布，MiniMax Code 也同步更新。官方把 MiniMax Code 定位為更適合 M3 的 Agent 產品，用來釋放 M3 的長上下文、程式碼、Agent 和多模態能力。

MiniMax Code 的 Agent Team 可以把大任務拆成多階段、並發、可動態調整的流程，並透過類似 Producer + Verifier 的對抗式循環持續產出、反思和修正。

這個方向和 Claude Code、Codex CLI、opencode 等工具處在同一大類：不是只讓模型回答問題，而是讓模型進入本地或雲端開發環境，讀檔案、改檔案、執行命令，再根據結果繼續推進。

區別在於，MiniMax 更強調：

M3 的 1M 長上下文；
多模態和 computer use；
Agent Team 的長時間自主執行；
Token Plan 下的大額度使用。

Token Plan 和 API

MiniMax 這次也更新了 Token Plan。官方公布的三檔額度是：

套餐	月費	M3 月額度
Plus	`$20/month`	約 `1.7B tokens`
Max	`$50/month`	約 `5.1B tokens`
Ultra	`$120/month`	約 `9.8B tokens`

這些額度看起來非常激進，適合高頻程式碼助手、批處理、長文件處理和多模態任務。但實際是否划算，還要看可用地區、並發限制、速度、穩定性、上下文計費和任務成功率。

API 方面，M3 已經可用。官方說明裡有幾個點值得注意：

輸入長度 <=512K tokens 按標準價格計費；
超過 512K tokens 會進入更高的長上下文價格；
支援開啟或關閉 thinking；
thinking 開啟時更適合複雜推理、Agent 和長週期協作；
thinking 關閉時回應更快，適合對話和程式碼補全；
支援 standard 和 priority 服務等級，priority 面向更高並發和更穩定延遲。

官方示例裡的模型名是：

`1`	`"model": "MiniMax-M3"`

介面示例使用：

`1`	`https://api.minimax.io/v1/text/chatcompletion_v2`

如果你要把 M3 接入現有程式碼工具，重點要先確認三件事：OpenAI-compatible 相容程度、串流輸出支援、工具呼叫格式。

開放權重值得關注，但要等落地

MiniMax 稱 M3 將在 Hugging Face 和 GitHub 上開源權重，支援私有叢集部署和微調。這個點很重要。

如果權重真正開放，並且推理框架適配順利，M3 可能會進入幾類企業場景：

私有程式碼庫助手；
內部知識庫和文件分析；
高敏感資料場景；
政企和本地化部署；
低成本批量 Agent 工作流。

但這裡還需要等具體資訊落地，包括：

權重大小和授權；
量化方案；
vLLM、SGLang、llama.cpp 等框架支援；
顯存需求；
多模態和長上下文在本地部署時的實際成本；
是否開放完整訓練或微調工具鏈。

所以現在可以關注，但不宜過早把「開源權重」當成已經可生產部署的事實。

適合誰先試

M3 更適合下面幾類使用者先試：

經常使用 AI coding agent 的開發者；
想用國產模型替代部分 Claude、GPT 或 Gemini 程式碼任務的團隊；
有長文件、長程式碼庫、長日誌分析需求的人；
做自動化工作流、MCP、agent harness 的開發者；
需要大量 token 額度做批處理的人；
對本地化部署和開放權重有長期需求的團隊。

如果只是普通聊天、短文字改寫、簡單問答，M3 未必是最需要優先嘗試的模型。它的重點明顯放在更重的 Agent 和工程任務上。

我的看法

MiniMax M3 這次發布，最有意思的是路線選擇：不只和通用聊天模型比，而是直接把程式碼、Agent、長上下文和多模態打包成一個面向工程工作流的模型。

這條路線是對的。未來 AI 程式設計工具的競爭，不會只看模型能不能寫一段程式碼，而會看它能不能在長時間任務裡持續規劃、執行、驗證、糾錯，並且把上下文成本控制住。

不過，真正決定 M3 能不能進入主力工作流的，還是幾個更樸素的問題：

API 是否穩定；
長上下文價格是否可控；
MiniMax Code 的工具鏈是否成熟；
OpenAI-compatible 和主流 agent 工具適配是否順暢；
開放權重能否及時落地；
第三方評測和真實專案體驗是否能支撐官方說法。

如果這些問題後續表現不錯，M3 會成為國產程式碼 Agent 模型裡很值得關注的一支。

MiniMax on KnightLi的博客