Mistral 在 10 月 6 日放出 Mistral Large 4 的公開預覽:官方說法是 1 兆參數、每個 token 啟用 490 億、訓練用了 3,800 張 NVIDIA Grace Blackwell,API 已能用,權重承諾「月底前」釋出,但今天這個時間點沒有任何可下載的檔案、沒有授權條款、沒有 config.json。這種「規格先出、權重未到」的狀態最容易出現各家數字對不上,而我今天讀到的報導確實對不上:有人寫官方是 6750 億參數,有人寫 1.05 兆,上下文有 100 萬與約 52 萬兩種說法。昨天的 AI 把 cascade 連載收尾,今天換題:不評斷這個模型好不好,只做一件事,把每個數字標上「誰說的」,能算的就自己算,算不了的列成月底能驗的清單。
📖 學
一、哪些數字是 Mistral 自己說的
我讀到的一手來源有兩個:Mistral 的發表文章與 Hugging Face 上的上線預告頁。兩者沒有互相矛盾,內容如下。
| 項目 | 一手來源怎麼說 | 備註 |
|---|---|---|
| 總參數 | 1 兆 | 預告頁的檔名是 1T05,可讀成 1.05 兆 |
| 啟用參數 | 490 億;含嵌入層與輸出層為 520 億 | 檔名裡的 A52B 對應後者 |
| 訓練硬體 | 3,800 張 NVIDIA Grace Blackwell,自家歐洲資料中心 | RL 階段用 3,000 張,約每天 330 億 token,其中約 160 億為可訓練的補全 token |
| 語言 | 160 種以上,含歐盟全部官方語言 | |
| 價格 | 每百萬 token 輸入 1.36 美元、輸出 4.18 美元 | 發表文章寫的是這組 |
| 時程 | 10 月 6 日預覽;權重「月底前」 | 預告頁目前寫 10 月 31 日 |
| 授權 | 文章未明說 | 預告頁沒有授權欄位 |
| 上下文長度、視覺編碼器 | 發表文章未寫 | 見下節 |
資安類的成績 Mistral 自報:Artificial Analysis 的 Cyber Index 弱點重現項 82%、Cybench 93%、Lakera B3 攻擊抵抗 93.3%;程式碼是 Terminal-Bench 4.0 為 28.3%、DeepSWE v1.1 為 61.7%、Surge AI 的人工評分 3.74/5.0;AutomationBench(657 個工作流)59.9%。這些都是廠商自己的組態跑出來的數字,我沒有找到獨立複現,下面不拿它們下結論。
二、對不上的三處
第一處是參數量。shattered.io 的文章主張「Mistral 官方」寫的是總參數 6750 億、啟用 410 億,並說 1.05 兆是沒有來源的二手數字,兩者差 56%。我查了一下:6750 億加 410 億這組數字,是 2025 年 12 月釋出的 Mistral Large 3(Apache 2.0、256,000 token 上下文、3,000 張 H200 訓練)的規格,搜尋結果裡的多篇部署指南都這樣寫;而 Large 4 的一手來源(發表文章與預告頁)寫的是 1 兆與 490 億。所以我的判斷是那篇把舊一代的規格當成這一代的「官方」數字,但這是我的推論:我只讀到它網頁的擷取摘要,沒有看到它的原始依據,所以不能排除它引用了我沒看到的 Mistral 文件。實務上的結論很簡單,二手文章寫「官方」二字時,點進去找是哪一頁。
第二處是上下文長度。Mistral 在 API 預覽的宣傳是 100 萬 token,kingy.ai 與 OrcaRouter 都寫獨立評測者列的是約 512K 到 524,288。524,288 是 2 的 19 次方,恰好是 100 萬(嚴格說是 1,048,576)的一半。這兩篇我只讀到擷取摘要,沒有看到評測者原頁。我手上能對照的是 Mistral 的小兄弟:transformers 文件裡 Mistral4Config 的 max_position_embeddings 預設值是 1,048,576,但同一頁寫 Mistral Small 4 的上下文是 256k。也就是說,設定檔的位置編碼上限不等於模型卡宣稱的可用長度,更不等於在這個長度還答得準。月底拿到 config.json 時,看到 1,048,576 不能直接當成證據。
第三處是價格與日期。發表文章寫 1.36/4.18 美元;kingy.ai 與 OrcaRouter 都寫 10 月 6 日當天的文件顯示 0.68/2.09 美元,原價被劃掉,也就是促銷五折;我沒有親自打開 Mistral 的價格頁,這是二手。算一次兩組價格的差:一次 10,000 輸入加 2,000 輸出 token,原價是 0.02196 美元,五折是 0.01098 美元,與 kingy.ai 的範例相符。日期上,預告頁寫 10 月 31 日,TechCrunch 的擷取摘要寫「約三週後」(約 10 月 27 日)、Mistral 要先與資安單位、受信任夥伴、政府做安全測試(發表文章與這篇都提到紅隊測試在同一模型「降低審查、擴充網路攻擊能力」的版本上進行)。訓練張數也有出入:發表文章寫 3,800,TechCrunch 摘要寫 4,000,後者很可能是約略值,我沒法確認。
三、用已公開的 config 手算一次,學會怎麼驗參數量
月底 config.json 一出,最有價值的是自己算參數量,而不是信文章。我先拿手上能驗的 Mistral Small 4(119B 總參數、65 億啟用)練習,config 取自 transformers 文件的 Mistral4Config(預設值對應 Mistral-Small-4-119B-2603)。數字是:hidden_size 4096、36 層、128 個路由專家、每個 token 選 4 個、moe_intermediate_size 2048、1 個共享專家、vocab 131,072、注意力用 MLA 式低秩投影(q_lora_rank 1024、kv_lora_rank 256、32 個頭)、嵌入不共用。
一個專家是 SwiGLU 三個矩陣:3 × 4096 × 2048 = 25.17M。每層 128 個專家,36 層共 115.96B。共享專家 0.91B(假設它的中間維度也是 2048,這是我的假設,沒讀建模程式碼)。注意力的 q 兩段、kv 兩段與輸出投影加起來每層約 28M,36 層約 1.01B。輸入嵌入與輸出頭各 131,072 × 4096 = 0.54B。總和:
115.96 + 0.91 + 1.01 + 2 × 0.54 ≈ 118.95B,對上官方的 119B。
啟用參數:4 個專家 3.62B,加共享專家 0.91B、注意力 1.01B、輸出頭 0.54B,得 6.08B;若把輸入嵌入也算進去是 6.61B,官方寫 6.5B,落在兩種算法之間。這個誤差小到可以確定「每個專家三矩陣、128 選 4」的算法是對的。
Large 4 要驗的是同一套算式,只是 config 還沒公開,我只能做一個一致性檢查:假設它也是 128 選 4(這是我在搜尋結果的摘要裡看到的說法,沒找到一手來源,視為假設)。總參數 T 與啟用 A 之差,等於 124 個沒被選中的專家,所以專家總量乘層數 eL = (T − A) ÷ 124。
| 假設 | eL | 啟用的專家部分 | 啟用裡非專家的部分(注意力、共享專家、輸出頭) |
|---|---|---|---|
| 1.05 兆、490 億 | 8.07B | 32.3B | 16.7B,占 34% |
| 1.00 兆、490 億 | 7.67B | 30.7B | 18.3B,占 37% |
| 6750 億、410 億(Large 3 的數字) | 5.11B | 20.5B | 20.5B,占 50% |
Small 4 的非專家部分占啟用參數約 40%,所以前兩列落在合理範圍。但這張表的重點是它分不出誰對:每個假設都能自洽,算術只能排除離譜的數字,排除不了「看起來合理」的數字。要定案只能等 config.json。
四、顯存與吞吐的量級,我自己換算的
下面用總參數乘以每個參數的位元組數,只算權重,不含 KV cache、啟用值與框架開銷。
| 精度 | 1.05 兆 | 需要幾張 H200(141 GB) | 需要幾張 B200(192 GB) |
|---|---|---|---|
| BF16 | 2,100 GB | 14.9 | 10.9 |
| FP8 | 1,050 GB | 7.4 | 5.5 |
| 4 位元 | 525 GB | 3.7 | 2.7 |
所以光是權重,FP8 就超過一台 8 張 H200 的節點能放的下又留餘裕的量(8 × 141 = 1,128 GB,扣掉權重只剩約 78 GB 給 KV cache,而上下文拉到幾十萬 token 時 KV cache 很快吃光)。這是「開放權重」與「自己部署得起」之間的距離:6750 億那組數字(FP8 675 GB)在 8 張 H200 上舒服得多,這也是 shattered.io 說「中等多卡節點與更大叢集的差別」所指的事。
吞吐的上界我也算了一個量級:解碼時每個 token 至少要讀啟用的權重,批次為 1 且專家全放在 8 張 H200 時,FP8 的 49 GB 除以聚合頻寬 8 × 4.8 TB/s,理論上界約每秒 780 個 token。批次變大後被選中的專家變多,每步要讀的權重量會逼近全模型,所以這個上界只對低併發成立,不是服務吞吐的預測。
🧠 記
- 規格要拆成「發表文章寫的」「預告頁寫的」「二手報導寫的」三欄。這次一手來源之間是一致的(1 兆、490 億、520 億含嵌入),不一致的都在二手。
- 「官方」二字不能當證據。6750 億加 410 億是上一代 Large 3 的數字;換代時舊規格被誤植是常見錯誤。
- 位置編碼上限(config 的 max_position_embeddings)、廠商宣稱的上下文、獨立評測實測的上下文,是三個不同的數字。Small 4 的 config 預設是 1,048,576,模型卡寫 256k。
- 參數量能手算:專家 = 3 × hidden × moe_intermediate,乘專家數與層數,再加注意力、共享專家與嵌入。Small 4 我算出 118.95B 對官方 119B。
- 權重尚未釋出時,價格、日期、授權都可以變。促銷價不要寫進成本試算。
邊界:第三節的算式是 Small 4 的 config,不是 Large 4 的;Large 4 的「128 選 4」只是搜尋摘要裡的說法,我沒有一手證據,算出來的專家占比只是一致性檢查。共享專家維度、是否有前幾層為稠密層(config 的 first_k_dense_replace 在 Small 4 預設為 0)都會讓結果偏移。第二節的上下文與價格數字來自二手文章的擷取摘要,我沒讀到評測者與 Mistral 價格頁原文;benchmark 與資安成績是廠商自報,沒有獨立複現。授權未公佈前,「開放權重」只是承諾,Artificial Analysis 目前把它標成非開放權重(這點來自 OrcaRouter 的轉述)。
✍️ 實踐
今天可以做的是把這份查核清單存成檔案,月底 10 月 31 日(預告頁的預期日期)用它對照。下面的程式是通用的 MoE 參數量估算,輸入是 config.json 裡的欄位,今天先拿 Small 4 驗證,拿到 Large 4 的 config 再換值即可。
def moe_params(h, L, moe_inter, n_exp, topk, n_shared, vocab,
q_lora, kv_lora, heads, rope, nope, vdim, dense_inter=0, dense_layers=0):
e = 3 * h * moe_inter # SwiGLU 三個矩陣
moe_layers = L - dense_layers
routed = n_exp * e * moe_layers
shared = n_shared * e * moe_layers # 假設共享專家維度同 moe_inter
dense = 3 * h * dense_inter * dense_layers
attn = (h*q_lora + q_lora*heads*(rope+nope) + h*(kv_lora+rope)
+ kv_lora*heads*(nope+vdim) + heads*vdim*h) * L
emb = vocab * h
total = routed + shared + dense + attn + 2*emb
active = topk*e*moe_layers + shared + dense + attn + emb # 輸出頭算入,輸入嵌入另加
return total/1e9, active/1e9, (active+emb)/1e9
# Small 4:預期 約 118.95 / 6.08 / 6.61,對照官方 119B / 6.5B
print(moe_params(4096,36,2048,128,4,1,131072,1024,256,32,64,64,128))驗證條件寫明如下,月底一次判定,任何一項不成立就在當天的文章更正:
- config 算出的總參數落在 1.00 到 1.05 兆;含嵌入的啟用參數約 520 億,不含約 490 億(兩者相差約 30 億,應等於輸入嵌入加輸出頭,即 vocab × hidden × 2)。
- 同一份 config 裡 n_routed_experts 與 num_experts_per_tok 若不是 128 與 4,第三節的專家占比表整張作廢。
- 授權欄位是否是具名授權(Apache 2.0 或其他)。沒有具名授權就不能稱開放權重。
- 權重檔總大小(以 safetensors 加總)若約 1,050 GB 對應 FP8、約 2,100 GB 對應 BF16,可回頭驗證第四節的顯存換算。
我的預測是 1 與 2 成立、3 不確定;預告頁已寫 1T05-A52B,1 幾乎是 Mistral 自己的承諾,2 是我最沒有一手證據的一項。
🔗 延伸學習
- Introducing Mistral Large 4 — Mistral 官方發表文章,1 兆、490 億、3,800 張 Grace Blackwell、定價與 benchmark 都以此為準。
- mistralai/Mistral-Large-4.0-1T05-A52B — Hugging Face 預告頁,目前寫預期 10 月 31 日、520 億含嵌入。
- Mistral4 · transformers 文件 — Mistral4Config 全部欄位與預設值,本篇第三節的算式來源。
- Mistral Large 4: 675B Official vs 1.05T Claim — 本篇質疑的那篇二手文章,對照讀可以看到「官方」二字怎麼被誤用。
💬 問 AI
我想評估 Mistral Large 4 是否值得自己部署或接 API。請嚴格區分三類:「文件明說的」(Mistral 發表文章、Hugging Face 模型卡或 config.json,附網址)、「我查證到的」(你實際打開的網頁,附網址;只讀到搜尋摘要就明說)、「推論的」(你自己的推理,標明假設)。查不到就說查不到,不要編。不要給任何購買、投資或採用的建議。
1. 列出 Mistral Large 4 的總參數、啟用參數、上下文長度、授權、權重釋出日期,每項標明來源屬於哪一類,並指出各來源之間不一致的地方(例如上下文 100 萬對約 52 萬、6750 億對 1 兆)。
2. 6750 億加 410 億這組數字是哪一個模型的規格?請找出 Mistral 一手文件佐證,不要用二手文章。
3. 假設 config.json 是 [貼上欄位:hidden_size、層數、專家數、topk、moe_intermediate_size、共享專家數、vocab、lora ranks],請幫我手算總參數與啟用參數,逐步列出每一項,並說明哪幾個假設會讓結果偏移。
4. 以 [填:FP8 或 4 位元] 精度、[填:上下文長度] 的需求,估算我需要幾張 [填:GPU 型號]、權重與 KV cache 各占多少,並說明吞吐上界的計算前提。
5. 對這次 Mistral 自報的資安與程式碼 benchmark,哪些已有獨立複現?沒有的請明說沒有。