MiniMax M3 程式設計：基準測試、實際定價，以及如何透過 API 呼叫（2026）

從程式設計角度看，MiniMax M3 是什麼

M3 於 2026 年 6 月 1 日發布。它是一個混合專家（Mixture-of-Experts）模型 — 根據社群追蹤者對已發布檢查點的分析，總參數量約為 428B，每個 token 約有 23B 參數處於啟用狀態，不過 MiniMax 本身尚未公布完整的參數拆解，因此應將這些確切數字視為次要資訊。它原生支援多模態（輸入文字、影像和影片；輸出文字），也是一個具備推理能力的模型，可依每次請求切換思考模式。

在談機制之前，先說明動機：為什麼程式設計模型會在意上下文長度？因為實際的工程工作不是單一檔案，而是一個程式碼庫、一段堆疊追蹤、測試輸出，以及你需要修改的三個檔案 — 必須長時間放在同一處，才能跨檔案進行推理。M3 的答案是 100 萬 token 的上下文視窗，以及保證可用的 512K token 下限。底層引擎是 MiniMax Sparse Attention（MSA），會選取鍵值快取的區塊，而不是對每一對 token 進行注意力運算。MiniMax 表示，在 100 萬 token 的情況下，這會將每個 token 的計算量降至上一代的約二十分之一，預填充速度約快 9 倍，解碼速度約快 15 倍。這些是架構的供應商數據，而非獨立測量結果，但其方向與稀疏注意力理論上應帶來的效益一致。

此外還有第一方程式設計介面 — MiniMax Code，也就是他們基於該模型打造的自有代理。知道它存在很有用；但這不是本文的重點，因為你來這裡是想從自己的程式碼呼叫模型。

請記住這一句：M3 是為大型上下文中的持續、多步驟工作而打造，不是為一次性的程式碼片段而設計。這個定位幾乎解釋了下文的所有取捨。

程式設計基準測試：MiniMax 的報告與獨立測量結果

以下是大多數文章都會混為一談的區分。左側是 MiniMax 自行報告的程式設計與代理式評分；右側則是中立第三方測量的結果。

供應商表格不會告訴你的兩件事。第一，這些測試由供應商執行，在這裡比平常更重要：SWE-Bench Pro 的數字是在 MiniMax 自己的環境中，使用 Claude Code 作為測試工具產生的，而獨立複製測試仍在追趕中。請將 59% 視為 M3 所處競爭層級的強烈訊號，而不是已經確立的結果。第二 — 這是我在任何一篇以程式設計為主的文章中都沒有看到的細節 — 當 Artificial Analysis 將 M3 與前代模型拆解比較時，大多數評估都有提升（Humanity's Last Exam 28→37、GPQA Diamond 87→93、長上下文推理 69→74），但 SciCode，也就是該測試組合中的程式設計評估，卻從 47 小幅下降至 45。這是小幅退步，我不會過度解讀。但它是唯一讓「程式設計能力大幅提升」這個簡潔說法變得複雜的數據點，而它在各處都未被提及，這點很值得注意。

我的看法是：M3 在應用軟體工程上確實接近前沿水平 — 能撰寫修補程式、進行多檔案編輯、處理終端機工作 — 而支援這一點的獨立指數（55，所屬類別第一）是真實的，不是行銷話術。它並未在每個程式設計面向都較上一代產生飛躍式提升，而抽象推理差距也確實存在（下文會詳述）。結論是：相信它所處的層級，但要用自己的任務驗證確切數字。

在程式設計工作負載下的實際成本

先看標價，因為誠實的比較並不是你在大多數文章中看到的那種。透過 GPT Proto 模型頁面，M3 在標準方案下的價格是每百萬輸入 token 0.48 美元、每百萬輸出 token 0.96 美元。

作為參考，MiniMax 自己的實際費率 — 在其對牌價永久提供 5 折優惠後 — 約為輸入 0.30 美元、輸出 1.20 美元。因此，與其籠統地說「更便宜」，不如精確比較：透過 GPT Proto 路由時，輸入成本高於直接呼叫 MiniMax，輸出成本則較低。哪一種方案更划算，完全取決於工作負載的讀寫比例。會讀取大型程式碼庫並輸出小型差異檔的程式設計代理，屬於輸入密集型，因此輸入費率占主導；以生成為主的工作則相反。透過聚合服務路由 M3 的理由不是醒目的折扣 — 而是營運上的便利：只需一組金鑰和一個與 OpenAI 相容的介面，就能在同一個 目錄中使用 M3 與其他模型，而不必另外建立 MiniMax 帳戶、區域端點和訂閱金鑰。

現在談真正決定程式設計帳單的部分，也是「1M 上下文」需要加上星號的原因。輸入 token 不超過 512K 時，價格是固定的。一旦超過這條線，整個請求 — 輸入、輸出和快取讀取 — 都會以 2 倍計費。這是階梯式函數，而不是漸進式增加。想像一個正常的代理迴圈：一開始有 400K 輸入和 100K 輸出，輕鬆低於門檻。但代理迴圈會持續追加內容。到了第十或第十五輪，沒有任何內容被刪減，其中一輪悄悄超過 512K — 此時整輪內容的所有項目都會以雙倍計費，而不只是超過門檻的 token。輸入量增加 20%，可能讓一次呼叫的成本增加一倍以上。

能抵銷成本的是快取：重複的輸入（你的系統提示、程式碼庫中穩定不變的部分）會以標準費率的一小部分計費。在代理迴圈中，大量輸入都可以快取，因此值得及早整合。結論是：對 M3 而言，程式設計帳單取決於你攜帶多少上下文，以及快取使用得多好，而不是定價卡上的每 token 數字。應該為工作負載編列預算，而不是只看標價。

如何透過 GPT Proto API 呼叫 M3

端點是與 OpenAI 相容的聊天介面。驗證方式是在 Authorization 標頭中直接放入原始 API 金鑰 — 不需要 Bearer 前綴，這一點常讓從其他供應商轉來的使用者困惑。將模型字串替換為 MiniMax-M3，即可開始執行。

import requests, json, glob
 
# 將幾個原始碼檔案拉入一個長上下文提示中。
# M3 的下限是 512K token，因此放入十幾個檔案也不會觸發價格門檻。
files = glob.glob("src/**/*.py", recursive=True)[:20]
codebase = "\n\n".join(f"# ---- {p} ----\n{open(p).read()}" for p in files)
 
prompt = (
    "這是 Python 服務的一部分。找出所有資料庫連線可能在例外路徑中洩漏的位置，並以統一差異檔的形式回傳修正內容。\n\n"
    + codebase
)
 
resp = requests.post(
    "https://gptproto.com/v1/chat/completions",
    headers={
        "Authorization": "sk-your-gptproto-key",  # 原始金鑰，不要加上 "Bearer" 前綴
        "Content-Type": "application/json",
    },
    data=json.dumps({
        "model": "MiniMax-M3",
        "messages": [{"role": "user", "content": prompt}],
        "temperature": 0.2,   # 預設值為 0.95 — 若要進行確定性的程式碼編輯，請調低此值
        "stream": False,
    }),
    timeout=120,
)
 
print(resp.json()["choices"][0]["message"]["content"])

有兩點實務注意事項。此介面預設的 temperature 是 0.95，對程式碼來說偏高 — 如果你想要可重現的差異檔，而不是有創意的變化，我會將它調低至 0.2 或更低。還有一點需要揭露：此端點和原始金鑰驗證模式已透過 GPT Proto 的即時 MiniMax 模型文件確認，模型字串替換為 MiniMax-M3；但我本人尚未對 M3 進行這個確切呼叫的冒煙測試，因此在整合至 CI 前，請先執行一次即時請求並確認回應格式。

「支援 1M」不等於「應該在 1M 下執行」

值得將兩個常被混淆的說法分開。M3 支援 100 萬 token 的視窗。至於你 是否應該 填滿它，則是另一個問題；對程式設計來說，答案通常是否定的。長上下文模型有一個已知傾向：能很好地注意提示開頭和結尾的內容，卻可能遺漏埋在中間的資訊；MiniMax 表示 M3 曾針對這個問題進行專門訓練，早期報告也顯示它在大部分視窗中維持良好的檢索能力，但這句話中的「大部分」確實很關鍵，我會在你自己的檢索敏感型任務中，於極端長度進行驗證。再加上 512K 的價格門檻，建議就很明確：有意識地使用長上下文 — 只在真正需要跨檔案理解時進行整個程式碼庫的推理 — 不要把它當成隨手傾倒所有檔案的預設場所。

M3 與 DeepSeek V4 Pro 的程式設計比較

如果你正在兩個前沿級中國開放權重模型之間做程式設計選擇，差異軸線很清楚。M3 提供原生多模態能力和 1M 視窗 — 它可以同時接收故障使用者介面的螢幕截圖與程式碼。DeepSeek V4 Pro 僅支援文字，價格較低，並且在經驗證的軟體工程測試組合中表現出色。我的粗略定位是：如果多模態輸入或超長上下文能帶來實際效益，就選 M3；如果你想要最便宜、能力足夠的純文字程式設計模型，而且不需要視覺能力，就選 DeepSeek。兩者的正面數據值得另寫一篇文章，因此本文只聚焦於選擇軸線，詳細比較請參閱 MiniMax M3 與 DeepSeek V4 Pro。

誰適合使用 M3 進行程式設計，以及誰不適合

如果你的工作具有代理式和多檔案特性，就適合使用它：跨程式碼庫的修補程式、由終端機驅動的任務、需要保留歷史記錄的長時間除錯，或是真正能從螢幕截圖回傳給模型的工作流程。這正是 M3 受訓所針對的使用情境，而且成果確實顯示了這一點。

以下三種情況則應跳過它，或至少先進行嚴格測試。如果你需要絕對最便宜的純文字程式設計模型，且從不處理影像或超大上下文，那麼更精簡的文字模型每 token 成本會更低。如果你的問題需要真正新穎的抽象推理，而不是稱職的執行能力 — 那位欣賞 M3 應用程式設計能力的獨立評測者也指出，它在抽象推理基準測試中落後 — 那麼抽象推理並不是 M3 的強項。如果你的計畫是自行託管權重以供商業使用，請在承諾之前閱讀授權條款：M3 採用 MiniMax Community License，其限制比部分競爭對手使用的 MIT 或 Apache 條款更嚴格，而且自發布以來，其開放權重狀態一直在變動。對於透過 模型頁面使用 API 的情況，這些授權摩擦都不適用 — 你是在租用存取權，而不是重新分發權重。