TL;DR
MiniMax M3 是 MiniMax 面向程式開發、代理式工作、長上下文推理與多模態理解的前沿模型。它於 2026 年 6 月 1 日正式發布，並結合三項被視為此次發布核心的能力：最高可達 1M-token 的上下文視窗、原生圖像/影片理解，以及長時程代理執行。
開放權重模型具有 約 428B 總參數與約 23B 啟用參數。這意味著在典型 token 上僅約 5.4% 的已公開參數容量處於活躍狀態，有助於解釋超大模型如何在推理時仍保持實用性。M3 同時引入了面向百萬級上下文的區塊式稀疏注意力設計 MiniMax Sparse Attention (MSA)。
對開發者而言，M3 可透過 MiniMax 的 API 與開放權重分發獲取，此外也可透過 CometAPI 使用，便於需要同一介面接入 MiniMax 與其他模型供應商的團隊。
Key Takeaways
- MiniMax 於 2026 年 6 月 1 日發布 M3，定位為聚焦程式開發、代理、長上下文與多模態的前沿模型。
- 開放權重發布披露了約 428B 總參數與約 23B 啟用參數。
- M3 支援最高 1M tokens 的上下文，MiniMax 稱 API 保證的最低等級為 512K。
- MiniMax Sparse Attention 以區塊選取與對所選上下文區域的精確稀疏注意力，取代完整全局注意力。
- M3 自訓練起點即採用混合模態資料，支援文字、圖像與影片輸入。
- Official launch benchmarks 包括 59.0% SWE-Bench Pro、66.0% Terminal-Bench 2.1、83.5 BrowseComp、75.2 OSWorld-Verified。
- MiniMax 演示了近 12 小時的自主論文復現與約 24 小時、共 1,959 次工具呼叫的 CUDA 核心最佳化。
- API 支援可配置推理以及 文字、圖像、影片、函式工具、標準/優先服務等級與長上下文計費。
What Is MiniMax M3?
MiniMax M3 是 M2 世代的後繼者，代表超越常規小版本更新的架構變化。MiniMax M2.7 已定位於真實世界軟體工程、辦公效率與代理工作流，而 M3 進一步加入新的稀疏注意力架構、原生多模態預訓練，以及百萬 token 的上下文目標。
M3 被定位為具備 1M 上下文視窗的前沿多模態程式模型。官方開放權重倉庫補充了最重要的規模數據：約 428B 總參數，其中 23B 為啟用參數。相關的 MSA 技術報告也描述了模型在 Mixture-of-Experts 設定下運作，這與公開的總參數對比啟用參數的拆分相一致。
這使得 M3 不只是「更大的 M2.7」，而更像是一個收斂式模型。它在同一系統中整合了倉庫級上下文、程式設計、多模態感知、計算機導向代理，以及本地/開放部署。MiniMax 明確將這種組合框定為此次發布的主要差異化點，而非宣稱 M3 在每個基準上都勝出。
MiniMax M3 Specifications
| Specification | MiniMax M3 |
|---|---|
| Release date | June 1, 2026 |
| Model size | ~428B total parameters; ~23B activated |
| Architecture | Sparse Mixture-of-Experts with MiniMax Sparse Attention (MSA) |
| Context window | Up to 1M tokens; API guaranteed minimum 512K |
| Input modalities | Text, image, video |
| Output | Text |
| Reasoning control | Thinking on/adaptive or disabled through API parameters |
| Maximum generation | Recommended 128K; API docs allow up to 512K max_completion_tokens |
| Tool use | Function tools; agent-oriented workflows |
| Weights | Open-weight release on Hugging Face / GitHub instructions |
上述上下文、模態與 API 行為由 MiniMax 的官方模型與 API 文件記載；參數數據與本地部署連結來自官方 M3 倉庫。
From MiniMax M2.7 to M3
| Dimension | MiniMax M2.7 | MiniMax M3 |
|---|---|---|
| Context window | 204,800 tokens | Up to 1M tokens |
| Native image/video input | No; M2.x text/tool workflows | Yes; text + image + video |
| Attention direction | Conventional M2-series serving | MSA sparse attention |
| Thinking control | Reasoning cannot be fully disabled in M2.x | Thinking can be disabled for lower latency |
| Primary positioning | Coding, tool calling, office/agent workflows | Coding + agents + multimodality + million-token context |
| Open-weight emphasis | M2.7 open model ecosystem | M3 weights + dedicated MSA implementation |
MiniMax 的 API 文件列示了 M2.7 具備 204,800-token 的上下文等級，而 M3 則進入百萬級。更大的差異是質變：M3 可直接接收視覺與影片輸入，而 M2.x API 仍以文字與工具為主。
What Is New in MiniMax M3?
一個 428B 模型，但只有約 23B 參數處於活躍
公開的 M3 倉庫聲明模型具有約 428B 總參數與約 23B 啟用參數。實務上，已披露的活躍比例約為 5.4%。這即是稀疏專家架構的基本吸引力：總容量可以非常大，但對於給定 token 的計算路徑僅觸及模型的一小部分。
僅靠參數數量無法決定品質，「428B」不應理解為每個 token 都在評估 428B 的稠密參數。更有用的解讀是：M3 擁有龐大的模型容量池，搭配條件式啟用與為長上下文成本設計的注意力系統。
MiniMax Sparse Attention：讓 1M 上下文變得實用
核心架構變化是 MiniMax Sparse Attention (MSA)。完整 softmax 注意力的成本隨序列長度呈平方成長，當代理歷史、程式碼倉庫、工具日誌、圖像與長文檔累積到數十萬 token 時，成本會變得高昂。
MSA 增加了一個輕量的索引分支（Index Branch），用於為 key-value 區塊打分，並為每個分組查詢注意力群組選出 Top-k 子集。主分支隨後只對這些被選中的區塊執行精確的區塊稀疏注意力。MiniMax 的技術報告將此描述為面向硬體的設計，旨在在降低需要由完整注意力處理的上下文量的同時，保留品質。
圖 1. MiniMax Sparse Attention (MSA) 架構。 來源：MiniMax 官方 MSA 圖示
在 1M 上下文下，MiniMax 報告稱 M3 使用約為上一代每 token 計算量的 1/20，並帶來超過 9× 的預填加速與超過 15× 的解碼加速，相較 M2。獨立的 MSA 論文在 109B MoE 測試模型上報告了額外的受控實驗，因此那些論文數據不應與生產版的 M3 相對 M2 的數據混為一談。
這一點很重要。論文在研究環境中驗證注意力機制；M3 的發布數據描述的是生產模型。兩者的結論方向一致，但並非相同基準。
原生多模態，自 Step 0 起
M3 並非被呈現為在末端外掛視覺轉接器的文字模型。MiniMax 表示其自訓練的 Step 0 起即採用混合模態，並重建了預訓練資料管線以提高交織的多模態資料比例。
生產 API 支援文字、圖像與影片輸入。對程式與代理工作而言，這很重要，因為許多真實任務並非僅有文字：除錯可能需要螢幕截圖、前端工作可能需要與參考圖比對、研究可能包含圖表與公式，而電腦操作代理是透過視覺介面運作的。
因此，更有用的思考方式不是「它能描述一張圖」，而是「視覺狀態可與程式、工具輸出、文件與使用者回饋一起，保留在同一個長時程推理循環內」。
互動式程式開發與代理訓練
MiniMax 主張傳統的程式基準過於單輪，無法代表開發者的實際工作方式。針對 M3，它構建了一個互動式使用者模擬器，使模型暴露於需求澄清、方案討論、基於回饋的修正、任務切換與多輪專案迭代。
目標是從被動的指令執行邁向協作。有效的程式代理必須能夠分解任務、呼叫工具、解讀失敗、修訂計畫、保留先前決策，並在第一個看似可行的答案之後持續下去。M3 的長上下文與工具導向訓練正是圍繞這個迴圈設計。
長時程自主執行
MiniMax 對 M3 最具說服力的演示並非聊天示例，而是長時間運作且需維持狀態、在多次工具回饋後持續改進的任務。
| Task | Autonomous runtime | Evidence of persistence | Reported result |
|---|---|---|---|
| ICLR paper reproduction | Nearly 12 hours | 18 commits; 23 experimental figures | Core experiments reproduced |
| FP8 GEMM kernel optimization | ~24 hours | 147 benchmark submissions; 1,959 tool calls | 7.6% → 71.3% peak utilization; 9.4× speedup |
| PostTrainBench model training | 12-hour task window | Data synthesis → training → evaluation → iteration | Score 0.37; behind Opus 4.7 and GPT-5.5, ahead of other models in MiniMax report |
在論文復現任務中，M3 運行近 12 小時並產出 18 次提交與 23 張實驗圖。任務結合了論文閱讀、圖表/公式理解、程式撰寫、實驗與迭代式詮釋。
.png)
圖 2. M3 在約 12 小時內自主完成論文復現的軌跡。 來源：MiniMax 官方 M3 演示
在 CUDA 最佳化任務中，M3 在約 24 小時內完成 147 次基準提交與 1,959 次工具呼叫，最終將報告的 Hopper FP8 峰值利用率從 7.6% 提升至 71.3%，達成 9.4× 加速，無需人工介入。值得注意的不僅是最終加速；MiniMax 指出模型的最佳方案出現在第 145 次提交之後，經歷多次平台期才達成。
Benchmark Performance of MiniMax M3
MiniMax 的發布基準圖將 M3 與 Claude Opus 4.7、GPT-5.5、Gemini 3.1 Pro 作比較，覆蓋程式、終端、瀏覽、辦公、工具使用與電腦操作任務。這些是最有用的直接比照，因為都發佈於同一個 M3 釋出包中。
圖 3. MiniMax 官方 M3 發布基準對比。 來源：MiniMax 官方基準圖
| Benchmark | MiniMax M3 | Claude Opus 4.7 | GPT-5.5 | Gemini 3.1 Pro |
|---|---|---|---|---|
| SWE-Bench Pro | 59.0 | 64.3 | 58.6 | 54.2 |
| Terminal-Bench 2.1 | 66.0 | 66.1 | 78.2 | 70.0 |
| VIBE V2 | 50.1 | 55.8 | 50.5 | 28.0 |
| SVG-Bench | 63.7 | 62.3 | 58.2 | 59.2 |
| KernelBench Hard | 28.8 | 30.7 | 20.9 | 18.6 |
| BrowseComp | 83.5 | 79.3 | 84.4 | 85.9 |
| GDPval rubrics | 74.7 | 79.8 | 80.6 | 57.8 |
| BankerToolBench | 76.1 | 81.3 | 75.0 | 67.0 |
| MCP Atlas | 74.2 | 77.0 | 75.3 | 69.2 |
| OSWorld-Verified | 75.2 | 82.8 | 78.7 | 76.2 |
此表中所有分數均抄錄自MiniMax 官方 M3 發布圖。它們應被視為廠商公布的發布期結果，而非 CometAPI 重新獨立跑分。
這些基準結果實際表明了什麼
首先，M3 在軟體工程領域確實具有競爭力。在 SWE-Bench Pro 上，它拿到 59.0，高於 MiniMax 報告中 GPT-5.5 的 58.6 與 Gemini 3.1 Pro 的 54.2，但低於 Claude Opus 4.7 的 64.3。KernelBench Hard 呈現相似趨勢：M3 的 28.8 接近 Opus 4.7 的 30.7，且明顯高於另兩者。
其次，終端執行並非 M3 的最強相對結果。Terminal-Bench 2.1 將 M3 定位在 66.0，與 Opus 4.7 的 66.1 幾乎持平，但明顯落後 GPT-5.5 的 78.2 與 Gemini 3.1 Pro 的 70.0。
第三，M3 在資訊蒐集上表現強勁但非絕對領先。BrowseComp 為 83.5：高於 Opus 4.7 的 79.3，但略低於 GPT-5.5 的 84.4 與 Gemini 3.1 Pro 的 85.9。MCP Atlas 的 74.2 也接近 GPT-5.5 的 75.3 與 Opus 4.7 的 77.0。
第四，發布圖中 M3 在 SVG-Bench 的成績尤為亮眼：63.7 相較於 Opus 4.7 的 62.3、GPT-5.5 的 58.2 與 Gemini 3.1 Pro 的 59.2。這符合 M3 的整體設計：原生視覺理解被設計為直接參與程式與代理工作流，而非停留於獨立的視覺功能。
因此，整體結論比「M3 擊敗封閉模型」更為細緻。M3 在許多代理式任務中進入同一性能帶，贏下部分評測、在其他項目落後。它的差異化在於分數之外：開放權重、多模態訓練、百萬級上下文設計，以及積極的服務成本結構。
MiniMax M3 vs Claude Opus 5 vs GPT-5.6 Sol vs Gemini 3.7 Flash
MiniMax M3 在快速演進的市場中發布，其原始對比集合已不再是最有用的參照點。更相關的當代對比是 Claude Opus 5、GPT-5.6 Sol 與 Gemini 3.7 Flash——較新的封閉模型，同樣面向程式開發、代理與多模態工作。由於這些模型並非在同一套一致的測試框架下評估，下表強調可證實的能力，僅在指標直接公布時才使用基準數據。
| Dimension | MiniMax M3 | Claude Opus 5 | GPT-5.6 Sol | Gemini 3.7 Flash |
|---|---|---|---|---|
| Weights | Open weight | Closed | Closed | Closed / hosted API |
| Public parameter count | ~428B total / ~23B active | Not disclosed | Not disclosed | Not disclosed |
| Context window | Up to 1M | 1M | 1,050,000 | 1M |
| Input modalities | Text, image, video | Text, image, PDF | Text, image | Text, image, video, audio, PDF |
| Coding / agent focus | Coding + long-horizon agents + multimodality | Complex agentic coding + enterprise work | Frontier coding + tool-heavy professional agents | Fast agentic coding + multimodal workflows |
| Computer / tool use | Function tools + MiniMax Code + computer use | Server/client tools + computer use | Web/file search, shell, computer use, MCP | Function calling, search, computer use |
| Terminal-Bench 2.1* | 66.0 | Not reported in Opus 5 launch | 88.8 | 85.8 |
| Representative coding signal* | SWE-Bench Pro 59.0 | Frontier-Bench v0.1: SOTA in Anthropic report | DeepSWE v1.1 72.7 | DeepSWE v1.1 65.3 |
| Best reason to choose | Open weights + low cost + 1M multimodal context | Judgment + long-horizon autonomy | Raw coding/terminal performance + broad tool stack | Speed/cost + native multimodality |
這些基準數據來自不同供應商的評估套件，不應被視為單一同步排行榜。M3 的 66.0 Terminal-Bench 2.1 分數出自 MiniMax 的發布評測；OpenAI 報告 GPT-5.6 Sol 為 88.8，而Google 報告 Gemini 3.7 Flash 為 85.8。Anthropic 的 Opus 5 發布重點在 Frontier-Bench、GDPval-AA、AutomationBench 與 OSWorld 2.0，而非公布可直接對比的 Terminal-Bench 2.1 成績。對於模型選型，請在自身工作負載下，以同一套框架基準測試候選模型，而非將跨供應商的發布數據視作永久排名。
MiniMax M3 優勢最明確的領域
M3 最明確的優勢是部署選擇。無論基準圖或參數數量，都不足以解釋為何開發者會關注此模型。M3 將開放權重與通常只見於託管前沿系統的上下文長度與多模態能力結合。當團隊需要本地部署、供應商獨立、專用服務，或對推理堆疊進行深度控制時，它就具吸引力。
第二個優勢是長上下文成本架構。MSA 明確旨在避免在百萬級上下文下注意力計算爆炸。這並不意味著 1M-token 請求在絕對值上很便宜——KV 快取、專家執行與多模態輸入仍然需要資源——但相對於完整注意力，它改變了成本的縮放曲線。
封閉模型仍具領先的領域
同一張官方基準圖顯示，M3 不應被描述為所有封閉前沿模型的自動替代品。依 MiniMax 的對比，Claude Opus 4.7 在 SWE-Bench Pro、KernelBench Hard、GDPval、BankerToolBench、MCP Atlas 與 OSWorld-Verified 上表現更強。GPT-5.5 在 Terminal-Bench 2.1 上強勢，並領先 GDPval。Gemini 3.1 Pro 在 BrowseComp 略勝。
對生產團隊而言，封閉平台也可能提供成熟的安全控制、託管工具、可觀測性、吞吐保障與整合，這些有時比開放權重更重要。當部署與成本優勢是需求的一部分時，M3 最具吸引力；若唯一標準是排行榜名次，M3 就不一定最適合。
MiniMax M3 API Pricing
MiniMax 目前採用兩個標準的上下文計價等級。其官方定價頁面顯示，對於輸入不超過 512K tokens 的請求，「永久 50% off」費率為每 1M input $0.30、每 1M output $1.20。超過 512K 的請求則為 每 1M input $0.60、每 1M output $2.40。優先服務定價為標準等級的 1.5×。
| Route / tier | Input price per 1M tokens | Output price per 1M tokens | Context note |
|---|---|---|---|
| MiniMax official Standard (current discounted rate) | $0.30 | $1.20 | ≤512K input |
| MiniMax official Standard long-context | $0.60 | $2.40 | >512K input |
| MiniMax official Priority (discounted rate) | $0.45 | $1.80 | ≤512K input; priority admission |
| CometAPI MiniMax-M3 page | $0.48 | $1.92 | Unified gateway pricing shown by CometAPI |
*CometAPI 的 MiniMax-M3 為每 1M input $0.48、每 1M output $1.92，並以 MiniMax 未折扣的標價 $0.60/$2.40 作對照。由於 MiniMax 自家平台當前顯示另一組 5 折標準價，開發者應比較實際生效的計費，而非只看標示的折扣百分比。
因此在此情境下使用 CometAPI 的理由，不一定是每時每刻都能拿到最低的促銷價。其價值在於當應用需要在 M3 與其他供應商間路由時，提供統一的 API 與計費層，而無需維護多套整合。
What Can MiniMax M3 Do?
程式開發與倉庫級工程
M3 最明顯的用例是跨大型倉庫的軟體工程。百萬級上下文可容納遠多於上一代 M2 之 204.8K 視窗的程式碼、文件、測試輸出、議題歷史與代理狀態。實務中，這使多檔案功能實作、倉庫級重構、錯誤診斷、測試修復、建置/終端迴圈、PR 審查與效能最佳化等流程成為可能。
關鍵在於持續性。倉庫級程式代理只有在保留原始需求、同時累積工具輸出與修訂時才有用。12 小時與 CUDA 的演示表明，M3 的設計是在中間失敗後仍能持續工作，而非將每次工具呼叫視為獨立的短任務。
自主研究與實驗
論文復現示例是研究代理的良好模板。M3 能閱讀論文、檢視圖表、推理公式、產生程式碼、運行實驗、評估結果是否符合預期，並持續改進實作。將論文文本、程式碼與實驗日誌保留在同一長上下文中，降低了需要摘要或外部重建狀態的程度。
這也是為何 PostTrainBench 具有參考價值。MiniMax 要求 M3 自主合成訓練資料、訓練基礎模型、評估並迭代。M3 並非第一名——在 MiniMax 報告中落後於 Opus 4.7 與 GPT-5.5——但此實驗展示了比一般問答更複雜的研究自動化。
多模態技術分析
由於 M3 原生接收圖像與影片，技術工作流可將視覺證據與文字與程式結合。例如比對前端實作與截圖、分析論文中的圖表、檢視電腦操作過程中的 UI 狀態、抽取圖示資訊，或結合影片觀察與長維護日誌。
MiniMax 的 OpenAI 相容 API 文件明確支援 image_url 與 video_url 的 M3 內容片段，包含可上傳的較大影片檔案。這使多模態輸入成為面向開發者的 API 功能，而非僅用於產品示範。
電腦與辦公自動化
MiniMax Code 被設計為圍繞 M3 的代理框架。官方表示，其 Agent Team 能將複雜任務拆分為多階段並行工作流，並使用 Producer + Verifier 迴圈進行反思與修正。M3 的原生多模態也允許在電腦操作工作流中跨應用、檔案、試算表與桌面介面移動。
一個官方示例是指示開啟本地 ERP 客戶端，並從 Excel 試算表批次錄入發票資訊。關鍵能力是跨應用狀態：代理需要理解試算表、操作介面、維持欄位對應，並在 UI 變更或操作失敗時恢復。
長上下文文件與知識工作
1M 的上下文視窗不僅用於程式，亦適用於在單一工作上下文中處理大量合約、政策、技術規格、研究論文、事故報告或客戶記錄。優勢不只是「更多頁數」；而是能在保留長代理歷史的同時，跨遙遠證據進行推理。
仍需務實提醒：最大上下文容量不保證每個位置都有完美召回，且極大的提示會提高延遲與成本。當檢索、快取、結構化記憶或任務分段能提升可靠性時，應與長上下文搭配使用。
Final Verdict: Is MiniMax M3 a Frontier Model?
是——但最有力的理由不在於 M3 登頂每一張排行榜。事實並非如此。
MiniMax M3 改變的是取捨。它在發布期提供具競爭力的前沿表現，同時帶來開放權重、百萬級稀疏注意力設計、原生日文圖影訓練、長時程代理行為，以及相較於其原始對比組封閉旗艦模型更低的每 token API 定價。
SEO信息
Suggested URL: /blog/minimax-m3-specs-benchmarks-pricing
Description: 探索 MiniMax M3 的規格、1M-token 上下文、稀疏注意力、多模態能力、基準表現、API 定價、使用場景與模型對比。
Keywords: MiniMax M3, MiniMax M3 規格, MiniMax M3 基準, MiniMax M3 API 定價, MiniMax Sparse Attention, 1M-token 上下文視窗, 多模態程式模型, 開放權重 AI 模型, 長時程 AI 代理, MiniMax M3 對比 GPT-5.5