MiniMax M3 API：定價、百萬上下文與生產環境應用

MiniMax M3 API 於6月1日正式上線。那一週我就開始測試了。兩週後才動筆——在那之前，你還沉浸在demo的驚艷裡出不來。

這是一篇工作筆記，不是模型評測。基準測試到處都有。我關心的範圍更窄：minimax m3 模型在生產環境中究竟適合什麼場景，1M上下文的實際成本如何，以及直接調用API還是走聚合器——選哪個、什麼時候選。

先說幾點。

大多數頭條數字（59.0% SWE-Bench Pro、>9×/15× 的速度提升、BrowseComp 83.5分）都是廠商自報。我會把它們當作有利條件下的上限，而不是你自己代碼庫上的下限。

1M上下文是真實的。它的定價分兩個層級。這一點比大多數人意識到的更重要。

開放權重在第十天左右上架了Hugging Face。如果你看到一篇發佈文說「權重即將放出」，那已經過時了。

MiniMax M3 是什麼（面向開發者）

API可用性與接入方式

三條路。直接通過MiniMax開放平台接入。通過聚合器——OpenRouter、Fireworks等。或者從Hugging Face自行部署。

前兩條我都試過了。自部署留給有足夠GPU的人——minimax m3 參數總量約428B，每個token激活約23B（MoE架構），這不是單張消費級顯卡能搞定的事。

我測試的兩條路，感覺上有些差異，從文檔裡看不太出來。直接調用每token更便宜。聚合器讓你在多個模型上只有一個計費入口。哪個更重要，取決於一個大多數團隊還沒想清楚的問題——這個問題我稍後會回來談，因為這是我看到大家卡住的地方。

1M上下文，512K有保障

這一行值得仔細讀。MiniMax M3 API支持最多1M token的上下文。要按512K規劃——這是有保障的最低值。1M上限是有條件的。

我在約480K做了一次測試（拼接了一個倉庫+設計文檔+一條很長的討論串）。三次運行結果一致，延遲在預期範圍內。

推到約700K（加入了項目的完整issue歷史）。延遲波動明顯變寬。計費層級也變了。

所以實際上：512K是你可靠的工作數字。窗口的上半段存在，但它是一個預算項，不是免費容量。

底層架構是MSA——MiniMax稀疏注意力——在發佈文中有說明。對成本規劃來說，關鍵細節是：在1M上下文下，每token算力降至M2的約1/20。沒有這個比例，長上下文層級在經濟上根本無法實現。

M3 是為什麼場景而生的

編程與Agent工作負載

minimax m3 模型的定位是長程編程和Agent工作。從兩週的測試來看，這個定位是誠實的。

單輪問答沒問題。沒什麼驚喜，但沒問題。真正有所不同的是長會話——讀取倉庫、規劃、執行、迭代、從中途崩潰中恢復。MiniMax自己的demo讓M3運行了12小時、提交了18次commit，復現了一篇ICLR論文。這才是架構所針對的工作負載。

相關的minimax m3 基準測試數字——全部是廠商自報——是59.0% SWE-Bench Pro、66.0% Terminal Bench 2.1、74.2% MCP Atlas。VentureBeat的報道將它們與GPT-5.5和Gemini 3.1 Pro進行了對比。「超越」這個說法我會降溫30%。數字是真實的。條件是MiniMax的實驗室和MiniMax的腳手架。

對開發者的意義：如果你在做編程助手、桌面Agent或任何需要持有多步驟計劃的東西，M3在候選名單上。如果你的工作負載是高並發的短提示，你在為用不上的上下文付錢。

原生多模態（圖像、視頻）輸入

多模態是原生的，不是拼上去的。文本、圖像和視頻進入同一個上下文。輸出是文本。

我給了它一張UI截圖+30秒的屏幕錄製+一段相關後端代碼，讓它搞清楚用戶究竟想做什麼。它做到了。不是一次就到位的——我在第二輪需要給它一個提示。（第一次猜測合理但錯了。）按我的標準，這算是能用。

我想特別指出一個細節，因為在另一個測試裡它坑了我：圖像和視頻token與文本共享同一個池子。一個短片段在任何提示文本之前就能佔用你512K窗口的相當大一塊。我查了一下15秒720p片段的token數——比我腦子裡的預估高多了。在推算之前值得先量一量。

生產成本與限制

我不在這裡列具體的每百萬token價格。提供商費率會變，關於minimax m3 定價機制有另一篇文章專門處理這個數學問題。在規劃階段你需要的是大致形態。

標準層級 vs 長上下文層級（>512K）費率

MiniMax M3 API 有兩個層級：

≤512K輸入token — 標準費率。涵蓋大多數聊天、編程和Agent循環。
>512K輸入token — 更高的長上下文費率。針對全倉庫推理、超長文檔、數小時的Agent會話。

這個分割是我唯一會在設計上圍繞它轉的事情。一個常駐在100K–300K區間的系統，和一個習慣性碰到700K的系統，單位經濟學完全不同。我發現這一點的方式，我猜大多數團隊也是這樣發現的：看賬單的時候。

對我有用的做法：默認路由上限設512K，超過這個需要顯式標記。這樣成本就出現在調用點，而不是月末。

跨模態共享token池

前面已經提到了，但值得單獨說一行。沒有獨立的多模態配額。圖像是token。視頻幀是token。它們和文本吃同一個窗口，以同樣的方式越過512K。

對於每輪都拉入截圖的Agent循環，這個累積速度比紙上計算的要快。審計一次真實會話的token數。不要相信合成基準。

直接調用API vs 聚合層

我看到團隊卡在這個決策上。他們大多數卡的時間比應有的更長。

各自適合什麼情況

走直接調用，如果：

M3 已確定為你的主模型，你不打算換。
每token成本比整合界面更重要。
你需要完整的1M（部分聚合器上限更低——Fireworks上線時上限是500K，正在分階段提升）。
維護一個模型專屬集成對你來說不是問題。

走聚合器，如果：

你在生產環境已經運行多個模型，或者你需要這樣做。
你想在不重建請求路徑的情況下對比M3和Claude Opus或DeepSeek V4。
統一計費、重試、回退路由和可觀測性很重要。
你還不知道你的工作負載最終會落在哪個模型上。

選聚合的誠實理由不是更低的每token成本。通常會略高一點。理由是換模型的自由度有經濟價值，而且你的產品跨提供商觸及的生成場景越多，這個價值的複利效應越大。WaveSpeedAI就在這一層，OpenRouter和Fireworks也是——各自在路由、延遲和覆蓋面上做著不同的取捨。

我的粗略原則，僅供參考：單模型編程Agent → 直接調用。跨提供商混合文本+圖像+視頻 → 聚合器。不是硬性規則，是一個起點。

限制與取捨

開放權重、技術報告，以及仍缺失的東西

權重在Hugging Face上。社區GGUF量化版本也有了。有兩件事值得知道：

許可條款尚未完全確定。不要假設是Apache 2.0或MIT——在本地部署路徑上構建商業產品之前先確認。

而且不是所有推理引擎都支持MSA。不支持的會回退到密集注意力，這會喪失一部分速度優勢。如果你自部署，在跑基準之前先驗證引擎支持——否則你的數字會看起來比實際應有的更差。

ARC-AGI差距

發佈報道往往略過的一點。M3在編程和Agent上的數字，並不能乾淨地遷移到ARC-AGI這類通用抽象推理基準上。這個模型的形狀就是它所宣傳的——編程、工具使用、長程Agent、多模態落地——而不是抽象謎題。

這不是批評。這是模型的形狀。了解它能省去一次錯誤的押注。

常見問題

MiniMax M3 API 現在是否已上線並可穩定用於生產？

是的。2026年6月1日起上線。穩定程度足以讓多個聚合器路由真實流量。和任何上線不足三個月的模型一樣，隨著提供商調整，預期偶爾會有行為變化——固定你的提示，保持一套評估套件。

MiniMax M3 實際保障的上下文長度是多少（512K還是1M）？

512K有保障，1M是上限。低於512K的行為一致。超過之後，你就進入了更高定價和更大延遲波動的區間。部分聚合器上線時上限低於1M。按512K規劃。

MiniMax M3 是否原生支持圖像和視頻輸入的多模態？

是的。原生支持，不是適配器。文本、圖像和視頻共享同一個token池和上下文窗口。輸出僅為文本。

MiniMax M3 的開放權重是否已經可用？

是的。上線後約第十天在Hugging Face上架。總參數約428B，每token激活約23B（MoE）。單張消費級顯卡跑不起來——預期需要多GPU或量化推理。許可條款——商業使用前請核實。

我應該直接接入MiniMax M3還是通過聚合器？

如果你確定只用一個模型並且想要最低的每token成本，就直接接入。如果你在運行多個模型或預期會切換，就用聚合器。答案取決於你的工作負載，而不是哪個「更好」。

結論

MiniMax M3 API 有趣的地方，與其說是它在某個單一維度領先，不如說是它的組合——前沿級別的編程能力、原生多模態、真實（儘管分層）的1M上下文、開放權重，全在一個模型裡。這個組合消除了過去需要拼接多個提供商的集成負擔。

在決定投入生產之前我會做的事：

跑你的真實工作負載，而不是基準測試。 測量提示相對於512K的落點。在上線前確定路由策略。根據你要運行多少個模型來選直接調用還是聚合器，而不是根據標牌價格。如果你自部署，確認你的推理引擎支持MSA。

兩週時間不長。模型會持續演進，定價也是。這就是這篇文章的有效期。

一切仍需在你實際動手構建那天對照文檔核實。

往期文章：