重點摘要 MiniMax M3 結合了1,000,000 token 的上下文視窗、原生文字-圖像-影片理解、強大的程式與 Agent 能力,以及 MiniMax Sparse Attention(MSA)。開發者可透過 CometAPI 的 OpenAI 相容閘道 https://api.cometapi.com/v1 以模型 ID minimax-m3 呼叫 MiniMax M3。
本指南涵蓋模型規格、官方基準測試數據、API 設定、串流、推理控制、多模態請求、工具呼叫、定價,以及與其他 2026 前沿 API 的比較。
關鍵要點
- MiniMax M3 支援最多 1M tokens 的上下文,可用於倉庫級程式協作與長時間 Agent 工作階段。
- 該模型自訓練第一步即為原生多模態,可接受文字、圖像與影片輸入。
- 其 MiniMax Sparse Attention 架構旨在讓百萬級上下文在計算上更可行。官方結果包含 SWE-Bench Pro 59.0% 與 Terminal-Bench 2.1 66.0%,同時在 Agent 與工具使用上表現強勁。
- MiniMax 的 OpenAI 相容 API 支援自適應或關閉的 thinking、串流、工具與 reasoning_split。
- 在 CometAPI 上,目前的模型 ID 為 minimax-m3,主要端點為 /v1/chat/completions。
什麼是 MiniMax M3?
MiniMax M3 圍繞三類日益定義前沿開發者模型的工作負載設計:大規模軟體工程、自主 Agent 執行,以及多模態長上下文推理。MiniMax 將 M3 描述為在程式與 Agent 任務上達到前沿級效能、同時結合了百萬級上下文、原生多模態與 MSA 的模型。實際效果是,該模型更適合隨時間累積檔案、工具結果、螢幕擷取、程式變更與推理狀態的工作流程,而非孤立的單輪對話。
M3 既可透過 MiniMax 自有 API 生態存取,也可透過CometAPI 的 MiniMax M3 端點使用。對已使用 OpenAI SDK 的開發者而言,CometAPI 路徑在保留熟悉的 Chat Completions 介面同時,讓比較 M3 與 Anthropic、Google、Moonshot AI 等供應商的模型更容易。
MiniMax M3 技術規格
| 規格 | MiniMax M3 |
|---|---|
| 供應商 | MiniMax |
| 官方發佈 | 2026 年 6 月 1 日 |
| CometAPI 模型 ID | minimax-m3 |
| 官方 API 模型 ID | MiniMax-M3 |
| 架構 | MiniMax Sparse Attention(MSA) |
| 上下文視窗 | 最多 1,000,000 tokens;MiniMax 模型頁註記保證最少 512K |
| 輸入型態 | 文字、圖像、影片 |
| 輸出 | 文字 |
| 推理控制 | thinking.type = adaptive 或 disabled |
| 工具呼叫 | 支援 |
| 串流 | 支援 |
| OpenAI 相容 API | 支援 |
| CometAPI 端點 | POST /v1/chat/completions |
上述上下文與多模態數字來自於 MiniMax 的 API 文件,而模型架構與發佈定位來自官方 M3 發佈。
MiniMax M3 的差異化在哪裡?
MiniMax Sparse Attention 與 1M 上下文
百萬 token 的上下文只有在服務架構能以可接受的速度與成本處理時才有用。M3 透過 MiniMax Sparse Attention(MSA) 解決這個問題:先識別相關的 KV 區塊,接著僅在選定區域執行稀疏注意力,而非對所有位置套用完整的二次方注意力。
MiniMax 報告在 1M 上下文長度下,M3 的每 token 計算量約為前一代的 1/20,且預填加速超過 9 倍、解碼加速超過 15 倍。這些是供應商回報的工程結果,非第三方服務測量,但解釋了為何 MSA 是 M3 長上下文設計的核心。

圖 1. MiniMax Sparse Attention 架構。來源: MiniMax 官方 M3 發佈
原生多模態
MiniMax 表示 M3 從訓練第一步即進行混合模態訓練,而非在文字預訓練後額外疊加視覺層。在 OpenAI 相容 API 中,M3 接受由多段內容構成的文字、圖像與影片輸入。可透過 image_url 提供圖像、video_url 提供影片;支援的圖像格式包含 JPEG、PNG、GIF、WEBP,而支援的影片格式包含 MP4、AVI、MOV、MKV。
對開發者而言,這讓單一模型即可處理如基於截圖的除錯、圖表解讀、UI 審查、技術文檔分析、與影片理解等任務,無需為每個視覺輸入另外路由至其他模型。
程式與 Agent 工作流程
M3 的公開定位重點不在一般聊天。MiniMax 聚焦於修復錯誤、前後端開發、終端執行、效能最佳化、工具調用與長期協作。官方 M3 基準集因此強調軟體工程與 Agent 基準,而非僅有學術 QA 測試。
| 基準 | 測試內容 | MiniMax M3 |
|---|---|---|
| SWE-Bench Pro | 真實世界軟體工程 | 59.0% |
| Terminal-Bench 2.1 | 基於終端的 Agent 任務 | 66.0% |
| SWE-fficiency | 高效率軟體工程 | 34.8% |
| KernelBench Hard | GPU 核心最佳化 | 28.8% |
| MCP Atlas | MCP / 工具使用之 Agent 能力 | 74.2% |
| BrowseComp | 自主瀏覽與檢索 | 83.5 |
| PostTrainBench | 自主後訓練工作流程 | 0.37 |
可配置的 Thinking
在 MiniMax 的 OpenAI 相容 API 中,M3 支援明確的推理控制:thinking 可設定為 adaptive 或 disabled。若在 MiniMax 的 OpenAI 相容端點省略該欄位,thinking 預設為開啟。對於生產整合,明確設定更安全,有助於跨環境復現延遲與行為。
長時程 Agent 表現
MiniMax 也發佈兩個長時間個案研究,顯示 M3 的上下文設計意義所在。在重現論文任務中,M3 自主運行近 12 小時,產生 18 次提交與 23 個實驗圖表,重現一篇 ICLR 2025 傑出論文的核心實驗。任務需要閱讀圖表與公式、編輯程式、追蹤實驗並保留長期的執行歷史。
在另一個 CUDA 核心最佳化練習中,MiniMax 報告在約 24 小時內提交 147 次基準測試並進行 1,959 次工具呼叫,將 Hopper FP8 硬體峰值使用率由 7.6% 提升至 71.3%,相當於 9.4 倍加速。這些示例為受控演示,並非對所有生產 Agent 的保證,但說明了其預期用例:持續的工具迴圈,且進展可能在多次迭代後才出現。

為何透過 CometAPI 使用 MiniMax M3 API?
CometAPI 透過與數百個其他模型相同的通用 API 環境來暴露 M3。當團隊希望基準測試多個供應商、維持單一計費面或在不重建應用的情況下保留回退路徑時,這非常重要。
- OpenAI 相容整合:僅需更換 base URL、API key 與模型 ID,即可重用現有的 OpenAI SDK 用戶端。
- 一把金鑰對多家模型供應商,便於實作 A/B 測試與回退路由。
- 集中使用量與模型級成本追蹤,無需切換多個供應商儀表板。
- 在工作負載需要不同品質、延遲、多模態支援或價格平衡時,可快速切換模型。
即時的 MiniMax M3 CometAPI 頁面目前列出模型 ID minimax-m3、POST /v1/chat/completions,並提供 OpenAI SDK 範例。
如何透過 CometAPI 使用 MiniMax M3 API
步驟 1:建立 CometAPI 帳號並取得 API Key
建立或登入你的 CometAPI 帳號,然後在金鑰主控台產生 API token。將 token 儲存在環境變數中,避免提交到版本控制。
export COMETAPI_KEY="your-key-here"
步驟 2:設定 OpenAI 用戶端
CometAPI 的 OpenAI 相容 base URL 為:
https://api.cometapi.com/v1
安裝 OpenAI SDK 並將用戶端指向 CometAPI:
pip install openai
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["COMETAPI_KEY"],
base_url="https://api.cometapi.com/v1",
)
步驟 3:發送你的第一個 MiniMax M3 請求
使用 CometAPI 模型 ID minimax-m3。最小化的 cURL 請求如下:
curl https://api.cometapi.com/v1/chat/completions \
-H "Authorization: Bearer $COMETAPI_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "minimax-m3",
"messages": [
{
"role": "system",
"content": "You are a precise software engineering assistant."
},
{
"role": "user",
"content": "Review this migration plan and list three high-risk failure modes."
}
],
"max_completion_tokens": 1200,
"reasoning_split": true
}'
Python:
completion = client.chat.completions.create(
model="minimax-m3",
messages=[
{"role": "system", "content": "You are a precise technical assistant."},
{"role": "user", "content": "Explain how sparse attention helps long-context coding agents."},
],
max_completion_tokens=1200,
extra_body={"reasoning_split": True},
)
print(completion.choices[0].message.content)
CometAPI 的即時 M3 頁面在其 Python 範例中使用相同的reasoning_split 模式。此開關會改變推理內容的返回方式;本身不會開啟或關閉 thinking。
步驟 4:啟用串流
串流對於聊天介面、程式助手與長回覆很有用,因為使用者可以即時看到輸出。MiniMax 的 OpenAI 相容文件確認 M3 支援串流。
stream = client.chat.completions.create(
model="minimax-m3",
messages=[{"role": "user", "content": "Create a phased plan for migrating a monolith to services."}],
stream=True,
max_completion_tokens=3000,
)
for chunk in stream:
delta = chunk.choices[0].delta
if delta.content:
print(delta.content, end="", flush=True)
步驟 5:啟用或關閉 Thinking
MiniMax 為 M3 定義了自適應與關閉兩種 thinking 模式。對於困難的程式、規劃與 Agent 任務使用 adaptive;對於簡單擷取、分類或延遲敏感的回覆則關閉。通過 OpenAI 相容路由使用供應商特定欄位時,建議在進入生產前先在 CometAPI playground 驗證,因為穿透行為可能會演進。
# Deeper reasoning
completion = client.chat.completions.create(
model="minimax-m3",
messages=[{"role": "user", "content": "Find the root cause of this distributed transaction failure."}],
extra_body={"thinking": {"type": "adaptive"}},
)
# Faster direct answer
completion = client.chat.completions.create(
model="minimax-m3",
messages=[{"role": "user", "content": "Extract the invoice number from this text."}],
extra_body={"thinking": {"type": "disabled"}},
)
步驟 6:使用圖像輸入
M3 的 OpenAI 相容 API 接受 image_url 內容段。同樣的型別化內容模式是透過 OpenAI 風格路由傳送螢幕截圖、示意圖或圖表的自然方式。
response = client.chat.completions.create(
model="minimax-m3",
messages=[{
"role": "user",
"content": [
{"type": "text", "text": "Review this dashboard screenshot and identify the likely UI problems."},
{
"type": "image_url",
"image_url": {
"url": "https://example.com/dashboard.png",
"detail": "default"
}
}
]
}]
)
MiniMax 文件列出支援 JPEG、PNG、GIF 與 WEBP,且圖像細節層級可為 low、default 或 high。供應商也提供請求大小限制,傳送大型資產前請查閱最新多模態 API 限制。
步驟 7:使用影片輸入
M3 也支援 video_url 內容段。MiniMax 文件列出 MP4、AVI、MOV 與 MKV,並透過其 Files API 支援更大型影片。
response = client.chat.completions.create(
model="minimax-m3",
messages=[{
"role": "user",
"content": [
{"type": "text", "text": "Summarize the workflow in this product demo and list every visible error state."},
{
"type": "video_url",
"video_url": {"url": "mm_file://your_file_id", "detail": "default"}
}
]
}]
)
若你的應用透過 CometAPI 路由多模態請求,請確認作用中的 M3 路由所支援的檔案傳輸方式;供應商原生的 mm_file:// 識別符屬於 MiniMax 的 Files 流程。
步驟 8:加入函式與工具呼叫
MiniMax M3 支援 OpenAI 相容 API 的工具定義。生產級 Agent 應執行所請求的工具,將完整的 assistant 工具呼叫訊息附加到對話歷史,然後將工具結果返回給模型。MiniMax 明確提醒,保留完整回應對於推理延續性很重要。
tools = [{
"type": "function",
"function": {
"name": "get_build_status",
"description": "Get the current CI build status for a repository.",
"parameters": {
"type": "object",
"properties": {
"repo": {"type": "string"},
"branch": {"type": "string"}
},
"required": ["repo", "branch"]
}
}
}]
response = client.chat.completions.create(
model="minimax-m3",
messages=[{"role": "user", "content": "Check whether the main branch of acme/payments is passing CI."}],
tools=tools,
)
步驟 9:善用長上下文與提示快取
擁有 1M token 上下文視窗不代表每個請求都該塞滿 1M。只打包與任務相關的檔案、日誌、文件與工具輸出。MiniMax 的自動提示快取可在系統提示、工具清單或對話歷史於多次請求重複出現時降低成本與處理時間。
對倉庫級 Agent,一個良好模式是保留穩定的專案摘要與工具結構,只檢索當前步驟相關的檔案,並定期壓縮陳舊歷史,而非讓工作階段無限制成長。
重要的 MiniMax M3 API 參數
| 參數 | 用途 | 備註 |
|---|---|---|
| model | 模型識別符 | CometAPI 上為 minimax-m3;直連 MiniMax 為 MiniMax-M3 |
| messages | 對話與工具歷史 | Chat Completions 必填 |
| max_completion_tokens | 生成長度上限 | 新整合優先於舊的 max_tokens |
| temperature | 取樣隨機度 | 0-2;MiniMax 預設 1 |
| top_p | 核心取樣(Nucleus) | 0-1;MiniMax M3 預設 0.95 |
| thinking | 推理行為 | adaptive 或 disabled |
| reasoning_split | 推理輸出格式 | 啟用時分離推理欄位 |
| stream | 漸進式輸出 | 用於互動式應用 |
| stream_options.include_usage | 串流使用量中繼資料 | 有助成本監控 |
| tools | 函式定義 | 用於 Agent 工作流程 |
| service_tier | 服務等級/排程優先權 | MiniMax 直連 API 上為 standard 或 priority |
| image_url | 圖像內容段 | JPEG、PNG、GIF、WEBP |
| video_url | 影片內容段 | MP4、AVI、MOV、MKV |
以上參數定義遵循MiniMax 目前的 OpenAI 相容 API 參考。部分供應商特定欄位經由聚合器路由時可能需要穿透支援,導入前請在當前 CometAPI 端點測試非標準欄位。
MiniMax 官方 API 與 CometAPI 比較
| 項目 | MiniMax 官方 | CometAPI |
|---|---|---|
| 模型 ID | MiniMax-M3 | minimax-m3 |
| OpenAI 相容 | 是 | 是 |
| Anthropic 相容 | 是;MiniMax 建議用於進階功能 | CometAPI 文章聚焦於 OpenAI 相容路由 |
| Base URL | https://api.minimax.io/v1 | https://api.cometapi.com/v1 |
| 主要優勢 | 直接取得供應商原生功能 | 單一金鑰共通路由多家供應商 |
| 最適合 | 標準化於 MiniMax 原生行為的團隊 | 比較或同時運營多家模型供應商的團隊 |
MiniMax 官方同時支援 Anthropic 相容與 OpenAI 相容的呼叫方式。MiniMax 建議直接走 Anthropic 路由以獲得進階 thinking 行為;CometAPI 的 M3 模型頁目前強調 OpenAI 風格的 /v1/chat/completions 整合。
MiniMax M3 API 定價
定價需要謹慎處理,因為 MiniMax 直連的有效費率與 CometAPI 比較頁所示的標示費率目前並不相同。截止 2026 年 8 月 10 日,CometAPI 將 M3 標為每百萬輸入 $0.48、輸出 $1.92。同一頁面將其與 MiniMax 標示價 $0.60/M 輸入、$2.40/M 輸出比較。
然而,MiniMax 的當前隨用隨付定價頁顯示對標準 M3 流量提供永久 50% 折扣:若輸入不超過 512K tokens,直連有效價格為 $0.30/M 輸入、$1.20/M 輸出、$0.06/M 快取讀取。超過 512K 輸入時,折扣後直連費率為 $0.60/M 輸入、$2.40/M 輸出、$0.12/M 快取讀取。
| 路由 / 等級 | 輸入 | 輸出 | 定價說明 |
|---|---|---|---|
| CometAPI M3 | $0.48/M | $1.92/M | 多模型統一路由 |
| MiniMax 直連,<=512K 輸入 | $0.30/M | $1.20/M | 目前折扣後的標準費率 |
| MiniMax 直連,>512K 輸入 | $0.60/M | $2.40/M | 目前折扣後的長輸入層級 |
這意味著 CometAPI 目前低於 MiniMax 名目標示價,但不低於供應商針對 <=512K 的折扣直連價。對大規模用量部署,請比較即時價格,而非依賴固定的「便宜 20%」說法。兩平台定價可能獨立變動。
成本範例
以 CometAPI 當前 M3 費率,若請求包含 100,000 個輸入 token 與 5,000 個輸出 token,約成本為:
| 輸入:0.10 x $0.48 = $0.048 輸出:0.005 x $1.92 = $0.0096 總計:$0.0576 |
|---|
若該請求符合供應商當前 <=512K 折扣層級,在 MiniMax 直連可能更便宜,但對多模型團隊而言,統一閘道的運營簡化仍具價值。
MiniMax M3 vs Claude Sonnet 5 vs Gemini 3.6 Flash vs Kimi K3
四款模型皆面向 Agent 與程式工作負載,並提供非常大的上下文視窗。其差異更多體現在模態支援、推理控制、供應商生態與目前 CometAPI 定價。官方文件確認 Claude Sonnet 5 的 1M 上下文視窗、Gemini 3.6 Flash 的大上下文多模態 API、以及旗艦 Kimi K3 的 1M token。
| 模型 | 上下文 | 輸入 | 推理 | 最適合 | CometAPI 每百萬輸入 / 輸出 |
|---|---|---|---|---|---|
| MiniMax M3 | 1M | 文字、圖像、影片 | 自適應或關閉 | 程式 Agent、長上下文、多模態工作流程 | $0.48 / $1.92 |
| Claude Sonnet 5 | 1M | 文字、圖像、文件 | 自適應 thinking;努力度控制 | 程式 Agent、專業知識工作、工具使用 | $1.60 / $8.00 |
| Gemini 3.6 Flash | ~1.05M | 文字、圖像、影片、音訊、PDF | Thinking 等級 | 快速多模態 Agent、Google 原生工具 | $1.20 / $6.00 |
| Kimi K3 | 1M | 文字 + 原生視覺理解 | 永遠推理;reasoning_effort 控制深度 | 長期程式與知識工作 | $2.40 / $12.00 |
表中當前 CometAPI token 價格取自即時模型頁面:MiniMax M3、Claude Sonnet 5、Gemini 3.6 Flash、Kimi K3。
圖 4. 當前 CometAPI token 價格比較,檢視時間:2026 年 8 月 10 日。模型頁面來源: M3、 Gemini 3.6 Flash、 Claude Sonnet 5、 Kimi K3。
應該選哪個模型?
- 當你優先考慮較低的 CometAPI token 定價、1M 上下文、原生圖像/影片理解與長時間的程式或工具 Agent,選擇 MiniMax M3。
- 當你優先考慮精緻的程式 Agent、專業知識工作與成熟的 Anthropic 風格工具流程,選擇 Claude Sonnet 5。
- 當多模態、快速 Agent 迴圈、Google 原生工具、音訊/PDF 輸入與吞吐量最重要,選擇 Gemini 3.6 Flash。
- 當工作重心在長時程程式、深度知識工作與始終推理且具 1M 上下文的模型,選擇 Kimi K3。
不要僅憑單一基準或 token 價格做選擇。用自己的程式庫、文件、工具呼叫與失敗案例建立小型評測集,比較成功任務率、延遲、總 token、重試次數與人工修正時間。
MiniMax M3 API 最佳實務
- 明確設定 thinking。對真正困難的工作使用 adaptive;對簡單任務且重視延遲的情境關閉。明確設定更易於基準與復現。
- 有選擇地使用 1M 視窗。大視窗是能力上限而非目標。傳送大型倉庫或文件集前先檢索與壓縮。
- 保留工具呼叫歷史。多輪函式呼叫須保留完整的 assistant 回應與工具呼叫物件,避免打斷推理延續性。
- 串流長回覆。即使總完成時間不變,串流能改善對程式、研究與 Agent 應用的感知延遲。
- 利用重複上下文快取。穩定的系統提示、工具結構與重複歷史都適合提示快取(在路由支援時)。
- 衡量每個成功任務的成本。token 價格固然重要,但重試、工具迴圈、冗長推理與故障恢復往往決定最終經濟性。
- 重新測試供應商特定參數。OpenAI 相容閘道對非標準欄位的穿透可能不同。生產前驗證 thinking、reasoning_split、多模態載荷與工具行為。
結論
MiniMax M3 是需要在單一模型中同時滿足程式、Agent 執行、原生視覺理解與超長上下文需求的開發者的強力 API 選擇。其技術敘事高度一致:MSA 直面 1M 上下文的服務挑戰,原生多模態訓練拓寬輸入面,公開基準聚焦於開發者真正關心的軟體工程與工具使用工作負載。
對多數 CometAPI 使用者,最快的入門方式很直接:建立金鑰、將 base URL 設為 https://api.cometapi.com/v1、呼叫模型 minimax-m3,並用你的實際生產任務進行基準測試。再決定是否啟用更深的 thinking、加入多模態輸入或構建工具迴圈。由於定價與路由行為可能變動,最終上線前請重新查閱即時的 CometAPI M3 頁面與 MiniMax API 文件。
