一張生成的 hero 卡片,標題為「MiniMax-M3.1-Flash 現在會回應你的 M2.7 呼叫」,副標題為「相同模型 ID。不同模型。」兩張卡片比較 MiniMax-M2.7(具備 204,800 tokens 上下文、文字與工具、開放權重,且可停用思考)與 MiniMax-M3.1-Flash(具備 1,000,000 tokens、文字、圖像與影片輸入、未公布開放權重,且未禁止思考),兩者以標示「2026 年 10 月 19 日自動路由」的箭頭相連。
Guides & Insights

MiniMax-M3.1-Flash 現在開始回應你的 M2.7 呼叫:10 月 19 日有哪些變更

作者

Gideon Frost

發佈日期

最新模型 · 20查看全部模型 →
基準測試:Artificial Analysis · 每日更新
返回全部文章

如果你今天要將 MiniMax-M2.7傳送到 M​iniMax M Plan 或 Token Plan 金鑰,該名稱背後的模型已經變更。M​iniMax 自家的模型退役通知將 2026 年 10 月 19 日定為:在這些方案上,發往 MiniMax-M2.7 與 MiniMax-M2.5 的請求會自動路由至 MiniMax-M3.1-Flash 的日期——程式碼中的模型 ID 相同,但另一端卻是不同的模型,思考預算預設為最大值,而且完全無法關閉思考。這個模型本身並不新:自 2026 年 9 月 27 日起,MiniMax-M3.1-Flash 就已出現在廠商的文件中;當時我們首次在該處以 MiniMax-M3.1-Flash-Preview 這個名稱確認到它。真正的新增之處、也是標記為今日日期的部分,是這項替換——以及兩個較舊的模型系列會按同一時程被併入其中這件事。像這次發布背後的已記錄 AI 故障與代理事件,都收錄在 OrcaRouter AI Incident Archive,其中每筆條目都附有自己的來源、嚴重程度、信心評級與爭議標記。

該通知實際承諾的內容

MiniMax 在其自家的模型清單文件中公布了時程,而且對一項棄用來說異常具體。三個日期就決定了一切。

• 2026 年 10 月 19 日 — M2.5 與 M2.7 系列將不再開放給新使用者。 • 2026 年 10 月 19 日 — 在 M Plan 與 Token Plan 下對 M2.5 或 M2.7 的所有請求都會自動路由至 M3.1 Flash。現有模型名稱仍可繼續使用,且廠商表示方案用量額度維持不變。 • 2026 年 11 月 18 日 — 兩個系列皆正式退役。對它們的 API 請求將完全停止運作。

Screenshot of MiniMax's Model List documentation page showing the collapsed heading 'MiniMax M2.5 and M2.7 Model Retirement Notice', the Available Models table with the MiniMax-M3 row described as a frontier multimodal coding model with a 1M context window and tunable thinking depth, and a Retired Models table listing MiniMax-M2.7, MiniMax-M2.7-highspeed, MiniMax-M2.5, MiniMax-M2.5-highspeed, MiniMax-M2.1, MiniMax-M2.1-highspeed, MiniMax-M2, MiniMax-M2-her and MiniMax-Music-3.0, each marked Retired.

按量付費的處理方式則另行處理:M​iniMax 表示,現有的按量付費用戶可繼續使用至退役日期,而新用戶今天起即被切斷。公司的建議一如預期——檢查你的應用程式是否依賴這些模型,並開始規劃遷移——但對今早生產流量還指向 M2.7 的人來說,這稍嫌太晚。

通知裡最重要的字眼是自動。這不是那種會回傳錯誤、逼你改動程式碼的淘汰退場。這是一種無聲的替換:你的請求照樣成功,你的用量照樣從同一份額度中扣減,但產生 token 的東西已經不同了。如果你只記錄請求的模型,卻沒記錄回應的模型,你的監控就會顯示一個健康運作的服務,跑著你根本沒選的模型。

回應內部有三件事會改變

廠商的 API 參考文件將這兩個模型記錄在同一頁,因此能精確說明兩者的差異。MiniMax-M3.1-Flash 是前沿的多模態程式碼模型,具備 1,000,000 個 token 的上下文視窗與可調節的思考深度;MiniMax-M2.7 則是舊版的文字與工具模型,視窗為 204,800 個 token。

• 上下文 — MiniMax-M3.1-Flash 提供 1,000,000 個 token,MiniMax-M2.7 則為 204,800 個,約增加五倍。• 輸入 — MiniMax-M3.1-Flash 支援文字、圖像與影片,而 M2.x 系列僅支援文字與工具呼叫;廠商的舊版說明明確指出該系列不接受圖像或影片輸入。• 思考 — 在 MiniMax-M3.1-Flash 上永遠開啟且無法停用;傳送 thinking: {"type": "disabled"} 會傳回 HTTP 400,錯誤碼為 2013。• 思考深度 — effort 接受 low、medium、high、xhigh 與 max,省略時預設為 max。M2.7 沒有對應的控制項。• 推理輸出 — 傳回於 reasoning_content(OpenAI 相容協定),以及在 thinking 區塊中(Anthropic 相容協定)。reasoning_split: false 不被接受,因此思考內容無法推回 content 中並以 <think> 標籤形式呈現。• 輸出上限 — MiniMax-M3.1-Flash 建議生成上限為 131,072 個 token,硬性上限為 524,288 個;M2.7 的總上下文則為 204,800 個。• 准入層級 — service_tier: "priority"(准入速度加快 1.5 倍的層級)在 MiniMax-M3.1-Flash 上不受支援。原本仰賴優先准入的工作負載將失去此功能。• 取樣 — top_p 在 MiniMax-M3.1-Flash 上預設為 0.95,而 M2.x 模型則為 0.9。

其中兩項只是表面性的。思考預設值則不然。為 M2.7 打造的工作負載從來不必考慮推理投入程度,因為根本沒有東西可設定。同一個工作負載未經任何變更,現在每次請求都以最大投入程度執行——而 M​iniMax 會將思考 token 計入生成上限,這就是為什麼廠商自己的文件警告:過小的 max_tokens會導致max_tokens停止原因,完全沒有任何文字輸出。

A generated two-column scoreboard titled 'MiniMax-M2.7 vs MiniMax-M3.1-Flash — the scoreboard'. MiniMax-M2.7 lists 204,800-token context, text and tools, thinking off allowed, no thinking-depth control, open weights since April 2026, and $0.30 / $1.20 pricing; MiniMax-M3.1-Flash lists 1,000,000-token context, text, image and video, thinking off returning an HTTP 400 error, thinking depth low to max defaulting to max, no published open weights, and price not published. The footer reads 'Vendor documentation figures; MiniMax-M3.1-Flash has no independent benchmarks. Routing date 19 Oct 2026.'

預設值就是那個昂貴的設定。

陷阱就在一句話裡:遷移通知說你的用量額度維持不變,這是真的,但每個請求所消耗的 token 卻並非如此。

MiniMax 的 M Plan FAQ 明確指出,消耗量取決於思考深度,而 M3.1 Flash 的深度越高,就會產生越多思考內容並消耗越多。當 effort 預設為 max 時,一個遷移後的 M2.7 工作負載如今正以該模型所能提供的最高成本設定運行,而這並非任何人所選。

做個粗略示意,採用整數,並明確標示這只是算術推算而非實測:假設每天 40,000 個請求、6,000 個 token 的提示詞,以及在 最高設定下使用 3,000 個思考 token,對比 最低設定下約 600 個。這樣每天多出 9,600 萬個思考 token,或每月約 29 億個。若按 MiniMax-M3 公布的輸出費率每百萬個 token 1.20 美元計算——這是目前最接近的公布費率,因為 M​iniMax 並未公布 M3.1 Flash 的每 token 費率——這個差距每月略高於 3,400 美元。只要改動其中兩項假設,數字就會大幅變動;重點是正負號不會變。

修正方式只有一個欄位,而且會依通訊協定而異:output_config.effort 在與 A​nthropic 相容的端點上,reasoning_effort 在與 O​penAI 相容的端點上,reasoning.effort 在 Responses 端點上。M​iniMax 自家的程式設計工具指南正是建議這樣做——對簡單任務降低 effort,而不是試圖停用思考,因為停用思考並非可行選項。

在調整任何東西之前,有一個二階效應值得檢查。如果你的用戶端送出 max_tokens 是為 M2.7 的回答所設定的大小,那麼最高努力程度的模型可能會把整個預算都花在推理上,並回傳一則空訊息。MiniMax 的 Anthropic 相容參考文件會告訴你要明確地把 output_config.effort 設為 max;同一頁的參數表則警告,思考權杖會計入 max_tokens。這兩段敘述只相隔幾行,而這樣的組合正是你得到一個內容空無一物的 200 回應的方式。

目前仍然沒有按 token 計價的價格

這就是讓遷移難以估算成本、而非難以寫程式的地方。MiniMax 的按用量付費價目表只列出一個語言模型:MiniMax-M3,在提示最多 512,000 個輸入 token 時,每百萬輸入 token 為 0.30 美元、每百萬輸出 token 為 1.20 美元;超過此上限後則倍增至 0.60 美元與 2.40 美元,且劃線定價原價已套用永久 50% 折扣。提示快取讀取則分別為每百萬 0.06 美元與 0.12 美元。MiniMax-M3.1-Flash 完全沒有出現在該表中。

目前公布的是訂閱制定價。M Plan 的 Go 方案每月 22 美元、Explore 方案 55 美元、Build 方案 132 美元,三種方案都包含 M3.1 Flash Preview 文字模型,其中 Explore 方案的使用額度是 Go 的三倍,Build 則是七點五倍。Token Plan 仍為現有訂閱用戶保留,但已不再向新用戶販售;廠商的升級說明指出,無論是哪種情況,各方案都維持目前的價格與文字用量上限。

所以,對「M3.1 Flash 每 token 的成本是多少」這個問題,誠實的答案是:M​iniMax 以外的人目前都還無法告訴你,因為那個數字並不在頁面上。如果你這週需要一個每 token 的數字來建立商業案例,唯一站得住腳的做法就是實測:在每個投入等級執行固定的評估集,記錄 用量(從回應中取得),並依照你的方案所隱含的費率換算。一個公布模型卡但不公布費率卡的供應商,是在告訴你:它想要談訂閱,而不是按用量計費。

你實際上送出的是哪個模型 ID?

MiniMax 的文件彼此不一致,而這偏偏會在錯誤的時刻造成問題。API 參考、模型呼叫指南和模型清單都把該模型稱為 MiniMax-M3.1-Flash。M Plan 頁面、Claude Code 設定指南和 Codex 設定指南則都稱它為 MiniMax-M3.1-Flash-Preview,其中還包含一份 Claude Code 設定,將四個不同的環境變數設為 MiniMax-M3.1-Flash-Preview[1m]。

這兩種命名方式都未被標註為已棄用,文件中也沒有任何頁面公告正式推出日期或更名。這一點值得直接說明,而不是靠猜測:截至今日,廠商仍同時使用這兩種字串,而我們無法從公開文件確認隨用隨付金鑰會接受哪一種。唯一能定案的測試大約只需十秒,而且不花錢:

curl https://api.minimax.io/v1/models -H "Authorization: Bearer $YOUR_KEY"

請讀取回傳的 ID,並從中挑選一個照原樣使用。如果你要將模型接入 C​laude Code、Cursor、Codex 或 OpenCode,廠商指南預期採用 -Preview 的形式;此外,C​laude Code 指南還指出,當設定正確時,工具應回報 MiniMax-M3.1-Flash-Preview 為目前使用中的模型。

如果你自行架設,這些都不會波及到你

MiniMax-M2.7 是一個開放權重模型。它的檢查點自 2026 年 4 月起就一直在 Hugging Face 上、由 MiniMaxAI 組織託管,而讓 API 端點退役的通知並不會影響在你自己的硬體上運行的副本。M2.5 也是如此。如果你的 M2.7 流量是由你自己的叢集或私有部署提供服務,那麼今天的路由變更就是別人的問題。

MiniMax-M3.1-Flash 並不在那個位置上。MiniMaxAI 組織最近兩個公開儲存庫,是 2026 年 8 月 7 日建立的 M​iniMax-Music3,以及 2026 年 7 月 28 日建立的 M​iniMax-H3;而在 Hugging Face 搜尋 M3.1 則查無結果。對於你現在被路由到的模型,沒有檢查點、沒有授權條款檔案,也沒有自行託管的退路。如果你當初選擇 M2.7 是因為開放權重,那麼這次遷移即使在能力上是升級,在自主性上仍是實質降級。

遷移檢查清單,按真正重要的順序排列

• 今天 — 確認你使用的是訂閱金鑰還是隨用隨付金鑰。自動路由適用於 M Plan 與 Token Plan;隨用隨付會繼續為現有使用者提供 M2.5 與 M2.7,直到 11 月 18 日。 • 今天 — 記錄 API 回傳的模型 ID,而不只是你送出的那個,讓無聲替換能在你的資料中顯現。 • 本週 — 在每次呼叫時明確設定 effort。依任務類別挑選等級,而不是繼承 max。 • 本週 — 先提高 max_tokens 或 max_completion_tokens,再提高 effort,並檢查是否有因 max_tokens 停止原因而出現的空完成。 • 11 月 18 日前 — 如果你仍需 M2.7 的行為,請將其移植到自架檢查點,或接受新模型的行為。該日期過後,端點就會消失。 • 11 月 18 日前 — 重新測試任何使用過 service_tier: "priority"M3.1 Flash 不提供此功能,因此即使模型不變,延遲特性也會改變。

路由層在何處發揮價值

本週的教訓不是 M​iniMax 推出了更好的模型,而是你程式碼裡的模型 ID 是供應商可以改寫的承諾,而這個改寫不會在你的部署歷史裡附上一筆變更記錄。

這正是把模型選擇放在路由器後面、而非在十二個服務裡硬編碼廠商字串的理由。在 OrcaRouter 上,MiniMax-M3 以及 M2.5、M2.7 端點與其他 200 多個模型並列,共用同一把金鑰,0% 加成——供應商牌價直接原樣反映,這就是為什麼 MiniMax-M3 顯示的價格與廠商收費相同,每百萬個詞元為 $0.30 與 $1.20,也是為什麼廠商調價當天就會反映,而不是等到下一個計費週期。

這裡有兩件真正實用的事。首先,路由 DSL 可讓你為某個任務類別固定使用特定模型,並在第一個模型無法使用時容錯切換至第二個,因此未經證實模型的評估會與現行模型並行執行,而不是取而代之。其次,跨供應商的自動容錯移轉意味著上游一個狀況不佳的午後只會是降級路由,而不是服務中斷。

Screenshot of the OrcaRouter model page for MiniMax M3 showing the model path minimax/minimax-m3, 512K maximum output, text, image and video input, vision, tools, JSON and reasoning output badges, the Minimax vendor attribution, a model description and a code-sample panel.

有一點要說清楚:截至今天,MiniMax-M3.1-Flash 並不在我們的目錄中。我們提供的是按 token 計價的 MiniMax 系列——M3、M2.7、M2.5 和 H3——所以如果你想比較你剛被遷移到的模型與你被遷移離開的模型,原有的一方只差一個金鑰。新模型本身則可透過 MiniMax 自家的方案取得。

什麼會改變這個讀數?

三項公開資料能讓這件事從一則遷移故事變成一則發布故事,但這三者目前都還不存在。為 MiniMax-M3.1-Flash 公布每 token 價格,能讓任何人實際估算轉換成本。在 Hugging Face 上提供 checkpoint,將恢復 M2.7 使用者正在失去的自架選項。在 Artificial Analysis 上登錄一筆資料,將讓該模型獲得首個獨立智能分數——MiniMax-M3 在該指數上為 29.2,而 MiniMax 自家文件宣稱 M3.1 Flash 在 SWE、BrowseComp 和 xBench 上達到最先進的結果,卻沒有隨附公布任何一個數字。

在那之前,把這個模型當成它本來的樣子:可呼叫、有文件記載、未經基準測試,且未按 token 定價,如今正以名稱接收它未曾索取的流量。能在這件事中安然度過的團隊,是那些在第一天就注意到自家模型 ID 已變成別名的團隊。

本文中的比較1

根據本文內容識別 · 基準測試:Artificial Analysis · 每日更新