MiniMax M3.1：外洩的預覽文件揭露了什麼——以及尚未有人證實的事

Hugging Face 上有一個名為 MiniMax-M3.1-preview-private 的 250 GB checkpoint，除了少數幾家推論合作夥伴之外，沒有人能開啟。有一份日期標為 9 月 22 日的文件，讀起來完全像廠商的架構說明，卻是在一個公開的合作夥伴工程 repository 中流傳，而不是在廠商自家網站上。接著在 9 月 26 日，一位廣受關注的模型觀察者發文說，MiniMax M3.1 是「下週即將推出的下一款模型」，而且他們已經在測試它的 preview。把這三件事放在一起，你就得到了 MiniMax M3.1 的完整公開紀錄——這款模型的名稱、架構差異、權重數量和登場的那一週全都在流傳，而廠商對其中任何一項都未曾在公開場合說過一個字。它所承襲的前代 MiniMax M3 則是另一回事：那一款已經正式推出，而正因為如此，大家才會在意這一個。

這就是一個尚未發布的模型從外部看起來的樣子，而值得精確說明證據的樣態，因為這三條線索的強度並不相等。該檢查點的存在已獲佐證：多條獨立線索指向同一個私有倉庫名稱與相同的檔案數量。架構文件則未以那種方式獲得佐證——它是第三方的轉錄，可能真實、可能過時，也可能部分出於虛構。「下週」這個說法是一個人的預期，而不是時程。本文中的每一項內容都按其實際具備的強度標示，此處沒有任何內容應被解讀為發布公告。

MiniMax M3.1 之所以還沒問世就值得寫一篇文章，原因在於它的前代。就多數評價而言，MiniMax M3 是 MiniMax 歷來推出的最強開放權重模型——一個具備 100 萬 token、文字—圖像—影片能力的模型，在 Artificial Analysis Intelligence Index 上達到 29.2，而且至今仍是少數能把真正超長上下文維持在一起的開放模型之一。如果 M3.1 在九月最後一週登場，對開發者真正重要的數字並非這份外洩消息的可信度，而是各層架構究竟改變了什麼，以及提供服務的成本是多少——而在這兩點上，外洩文件寫得異常具體。

什麼是已確認的，什麼只是流傳中的

截至2026年9月27日，誠實的拆分：

• 已確認：MiniMax M3.1 並不存在公開版本。在 Hugging Face 上，MiniMaxAI 組織對於 MiniMaxAI/MiniMax-M3.1、MiniMaxAI/MiniMax-M3.1-preview 以及 MiniMaxAI/MiniMax-M3.1-preview-private 一律回傳 401 —— 也就是該平台「找不到，或你無權檢視」的回應。其最新的公開上傳檔案仍是 MiniMax-Music3（2026 年 8 月 7 日）與 MiniMax-H3（2026 年 7 月 28 日）。

• 已確認：MiniMax M3.1 在我們能查核的任何地方都無法路由。它並未出現在 OrcaRouter 的模型目錄中，也未出現在我們監控的公開清單裡；你今天實際能呼叫的 MiniMax 模型是 MiniMax M3，位於 minimax/minimax-m3。

• 已確認：MiniMax 未發布任何內容。沒有模型卡、沒有部落格文章、沒有定價頁面、沒有權重、沒有 API 模型 ID。由於根本沒有推出，因此也沒有任何關於推出的媒體報導。

• 流通中：該架構文件。它被逐字轉載於一個公開儲存庫——longsco/innoferra-eval，一套用於託管模型端點的合作夥伴導入套件，建立於 2026 年 9 月 23 日——檔案名稱為 PREVIEW-20260922.md，其標頭將其描述為一份於 9 月 25 日分享的供應商文件，並附帶一項但書：「模型名稱、供應商發布日期與公開發布仍須以實際發布為準。」那是文件自身的保留說法，不是我們的，而且它也是正確的：第三方對供應商備註的副本並非 MiniMax 的聲明。

• 流通中：250 GB 檢查點及其第二次發布。該儲存庫的入門規格記錄了一個位於 MiniMaxAI/MiniMax-M3.1-preview-private 的私有多模態檢查點——62 個檔案、48 個 safetensors 檔案、約 250 GB，架構字串為 MiniMaxM3SparseForConditionalGeneration——接著是更大的第二次發布，MiniMax-M3.1-preview2-dspark-private，有 101 個檔案、約 236 GB，新增了一個 2.3 GB 的 fp8 推測性草稿。兩者都是私有的。我們無法開啟其中任何一個，你也不能。

• 流傳中：時間線。9月26日的貼文是任何人唯一公開提供的日期，而「下週」是一種預期。把9月28日那一週視為值得關注的時間窗口，而不是一個確切日期。

唯一承載工程細節的文件

關於 MiniMax M3.1 設計的所有具體已知資訊，都可追溯至那一份 Markdown 檔案，外加同一儲存庫中的兩份配套檔案：一份 SGLang 示範文件，描述該檢查點預計如何提供服務；以及一份 spec.yaml，某個合作夥伴端點理應符合其規範。把整個儲存庫讀下來，看起來就像一家推論供應商在做推論供應商該做的事——收到 MiniMax 的早期交付、寫下變更了什麼，並為它建立一套驗證套件。這個儲存庫不是公關資料包，也不是為了說服任何人而寫。

那一點對它有利，但也是它所能證明的極限。其中沒有任何內容由 MiniMax 署名。這三份文件彼此一致的方式，就像真實文件會有的那種一致——相同的量化常數、相同的環境變數名稱、相同的啟動旗標——而它們彼此分歧的方式，也像真實發布版本會有的那種分歧：9 月 22 日的預覽版說新的推測解碼方法沒有置信度頭，而第二批 checkpoint 發布則交付了一份草稿配置，其中 enable_confidence_head 設為 true。偽造內容通常不會包含一段更正軌跡。但「異常連貫」不等於「已獲證實」，而讀者的失誤模式，就是把以下常數吸收為 MiniMax 已發表的設計，然而它們充其量只是他人所解讀出的 MiniMax 私人設計。

根據該文件所述的五項工程變更

以下是文件所述 MiniMax M3 與 MiniMax M3.1 之間的差異。每一行皆源自廠商且未經審核——沒有任何獨立第三方測量過 MiniMax M3.1 的任何輸出。

• 注意力覆蓋範圍。前三個層中的全注意力被稀疏注意力取代，因此所有層都是稀疏的。在 MiniMax M3 上，前三個層曾是稀疏堆疊的全注意力錨點。

• 注意力精度 ——「Q8KV4」。查詢，包括索引器的查詢，會從投影中以 BF16 輸出，並轉型為 FP8 E4M3。鍵與值——同樣包括索引器的——則以 16 為區塊量化為 E2M1、四位元，每區塊的 E4M3 尺度為 amax/6，並夾限於 [1/512, 448]。文件強調，此階梯採用四捨六入（round-half-to-even）並搭配非對稱閾值，外部張量尺度恰為 1，且零量值必須編碼為正零。M3 使用了同家族的八位元 KV 路徑，因此這再次將 KV 位元組減半。

• 專家精度。MoE 路由專家從 MXFP8 改用 W4A4 NVFP4，而共享專家則刻意排除在外。兩個專家投影採用不同的活化方案：FC1 使用動態的逐列縮放，其值為 2688 除以該列的絕對最大值，並在 GEMM 之後、活化函數之前套用該列縮放；FC2 則使用固定外部縮放值 16。合作夥伴 README 中明確寫出的實際後果很直白：「若供應商透過通用 NVFP4 路徑執行該檢查點，卻沒有這些設定，將會默默產生不同的數值結果。」

• 推測解碼。EAGLE 風格的多 token 預測頭已移除，改由 MiniMax 稱為 DSpark 的方法取代——一個樸素的馬可夫頭，而在 9 月 22 日的文件中，並沒有置信度頭。這是對已提供服務端點的實際感受影響最大的變更，因為它是設計中唯一能提升每串流速度的槓桿。MiniMax 隨檢查點一同發布的示範引擎並不包含 DSpark，而供應商量測了這個落差：在相同且未使用推測的 80,000-token 框架上，每串流吞吐量在並行度 1 時為每秒 63.9 個 token，到了並行度 4 時會降至 60 以下，因此該文件自身的結論是：若沒有 DSpark，這套堆疊在負載下無法維持其延遲目標。

• 一個新的請求欄位。MiniMax M3.1 新增了一個頂層的 reasoning_effort 欄位，可接受 max、xhigh、high、medium 或 low，並由聊天模板以 effort 標籤的形式注入系統提示中。M3 只有一個思考開關，值為 adaptive 和 disabled。該文件特別且奇特地指出，這個欄位在傳遞時既未經驗證，也沒有強制的預設值——而供應商將此解讀為允許自行選擇接受或拒絕未列出的值，這也意味著兩個同樣合規的端點，對同一個請求可能會有不同的行為。

checkpoint 中有兩個細節值得分別提出來，因為它們正是發布文章會略過的那類事情。首先，這個 checkpoint 同時隨附了圖像前處理器設定與影片前處理器設定——MiniMax M3.1 在架構上就是多模態模型，而不是先做成文字模型、事後才把視覺能力硬接上去，而且供應商自家的指引也說不要在新堆疊上拒絕圖像輸入。其次，第二次 checkpoint 發布完全移除了 MTP 和 NEXTN 鍵，也沒有加入任何能替代它們的東西，這就是為什麼 DSpark 草稿必須以一個獨立的 2.3 GB 產物形式出現。主要權重中沒有可啟用的草稿頭。

為什麼沒有 M3.1 的基準測試數據，以及為什麼那不是疏忽

每一篇爆料文最終都會寫到那一段：要嘛編出一張基準測試表，要嘛坦承自己一張也沒有。MiniMax M3.1 兩者皆無。合作夥伴規格書明白寫出這一點，用的正是一個純粹為了防止有人犯下這個錯誤而存在的欄位：

• 「尚未發布 3.1 基準值；請勿沿用 M3 的數字作為驗收門檻。」

那條指令是整份語料庫裡最有用的一句話，因為這篇文章的偷懶版本會把 MiniMax M3 的 Artificial Analysis 分數寫在 MiniMax M3.1 的標題底下。但不該如此。同一個儲存庫會針對 MiniMax 自家的 M3.1 端點執行 AIME-25 與 GPQA-Diamond 探測，並將它們記錄為團隊成員對供應商的比較，且分數尚未底定：在 GPQA-Diamond 上，團隊執行得到 0.904，供應商則為 0.813；而在一個 600 題的 MMLU-Pro 子集上，分別是 0.898 對 0.821。那些是同一項評估的兩次執行結果彼此不一致，而不是模型結果，而且它們被標示為預覽版，並計入了重複次數。今天任何人若引用單一 MiniMax M3.1 基準測試數字，所引用的都是還不存在的東西。

MiniMax M3 是什麼，好讓續作的規模得以評估

MiniMax M3 於 2026 年 5 月底推出，並在 6 月 2 日上架 Hugging Face——總參數量 4,280 億、啟用參數 230 億，60 層，128 個路由專家搭配 top-4 路由，4 個 KV 頭對上 64 個注意力頭，上下文視窗為 1,048,576 個 token，最大輸出 512,000。在獨立評測方面，Artificial Analysis 在 Intelligence Index 上給它 29.2 分，在 145 個受測模型中排名第 60，程式碼指數為 58.6，而在我們自家的路由遙測中，首個 token 的 p50 為 3,348 毫秒。MiniMax 自家主打的數字是 BrowseComp 上的 83.5，這是廠商提供的數據，因此未經稽核。

在洩密週期中，定價是最經得起時間考驗的一環。MiniMax M3 每百萬輸入 token 為 0.30 美元、每百萬輸出 token 為 1.20 美元，快取讀取為 0.06 美元——而且它已以 minimax/minimax-m3 在 OrcaRouter 上線，採用供應商的表定費率並提供 0% 加價，因此若 MiniMax 對 M3.1 採取相同的定價方式，新費率在問世當天就會在我們這邊上線，而不必等到下一個計費週期。

重述這一切的重點並不在於懷舊。而在於：本週之所以會有人不斷重新整理 Hugging Face 組織頁面，全是因為 MiniMax M3 表現得夠好，好到它的後繼者已成為一個實際投入生產的問題，而不是讓人看熱鬧的賽事——而且一款具備 1M 上下文、擁有 4280 億參數、價格為 $0.30/$1.20 的模型，所設下的是一道 M3.1 必須跨越的性價比門檻，而不只是能力門檻。

匿名房源的角度，以及為什麼它可能已經被解答了

九月早些時候有條線索值得在此做個了結。一個匿名隱身項目無預警出現在第三方程式編寫平台上，具備 1,000,000 個 token 的上下文、$0 定價與強制性的推理等級，我們以 Space Bunny Alpha 之名報導了它，並指出這類匿名上架項目的基準率——這類匿名項目最終都會被某家廠商認領：Pony Alpha 成了智譜的模型，Hunter Alpha 成了小米的，Ox Alpha 則成了 MiniMax 以另一個名稱發布的產品。該項目中的分詞器與異常指紋都指向一個 MiniMax 預覽檢查點。如果 MiniMax M3.1 真的在本週登場，最合理的解讀是：那次匿名上架就是它的實地測試，而這個謎團將透過發布公告、而非更多鑑識工作來解開。這是推論，不是證據，也是本文的最後一項推論。

本週要留意什麼，以及該做什麼

能把這件事從外洩變成正式發布的訊號，是具體且可查證的，而且它們並不是大多數評論所追蹤的那些。在 MiniMaxAI 組織底下的一個公開 Hugging Face 儲存庫——不是私有的——且附有模型卡，是最強烈的單一指標；該組織的上傳歷史是公開的，並把每次發布確切標註到日期。MiniMax 的模型頁面或 API 模型 ID 是第二個。已公布的價格是第三個，也是對預算而言最重要的那個。在 Artificial Analysis 上、日期在發布之後的基準測試表是第四個，也是唯一獨立的那個。

在那之前，對任何正在打造產品的人來說，實際處境與其他任何發佈前一週並無不同：你今天能路由的模型是 MiniMax M3，一組 API 金鑰就能連上它，同時還能觸及 200 多個其他模型，自動容錯移轉意味著某個端點抖動不會變成你的服務中斷，而透過路由 DSL 固定或混合的路由，或是一組模型透過模型融合一起回答，正是你為尚未正式上線的模型降低風險的方法。如果 M3.1 推出，那只是換一個模型 ID，而不是一次遷移——這正是不要針對外洩資訊打造客製化整合的完整理由。

這篇文章不會做的一件事，就是假裝知道時間。那個檢查點是真的，文件是具體明確的，而最近一項公開說法是有人說「下週」。在這三者之中，只有前兩項是你可以自行驗證的事。