Mistral Large 4 的上下文視窗：宣稱 1M、實測 524K，以及為何落差要計費

Mistral 的模型卡說一套，獨立測量卻說另一套，而這個落差並非表面問題。模型卡列出 100 萬個 token 的上下文視窗。Artificial Analysis 評估它實際能運行的配置後，測得 524,288 個 token。你送出的每個輸入 token 都會被計量，因此「我擁有多少上下文」這個問題，同時也是「我在單次請求中最多被允許花費多少」的問題。

這兩個數字之間的差異是 2×，而在每百萬輸入 token 收費 $1.36 的模型上，這可不是捨入誤差。

這些數字是什麼，以及每一個的來源

• 1,048,576 個 token — 這是 Mistral 隨權重一同提供的設定檔中的數值。這是廠商寫下的上限，模型卡也以「1M」重述。

• 524,288 個 token — 這是 Artificial Analysis 在其測試配置上測得的結果。上限的一半。

• 這要花多少成本——以每百萬 $1.36 計算，填滿 524K 每次請求約需 $0.71；填滿完整的 1M 則需 $1.43。兩者都是單次呼叫的輸入部分，尚未計入任何輸出。

廠商標示的數字不是謊言，實測數字也不是瑕疵。上下文視窗是架構本身具備的能力；特定推論服務配置實際上能接受的範圍——受限於其 KV 快取預算、張量平行化與批次大小——會更小，而這之間的落差在整個業界都是常態，只是鮮少與價格標示在同一行。

為什麼這件事在這裡比在其他地方更重要

針對此型號的三個理由。

這是一個兆級參數的 MoE。1.05 兆參數，每個 token 啟用 520 億，外加一個 16 億參數的視覺編碼器。在這類模型上，長上下文的 KV 快取是服務部署的硬性限制，而非設定檔的意圖。實測出來的數字，才是誠實的規劃數字。

它的計價方式是按 token，而不是按請求。 這張卡上的長上下文請求是一項計費明細，會隨你送出的內容呈線性增長。你買的不是「1M 視窗」；你買的是 token，而視窗只決定一次呼叫中能有多少 token 送達。

權重會隨設定檔一併提供。當你下載 1,060.6 GB 的 bf16 並讀取 code>config.json/code> 時，你會看到 1,048,576，並會忍不住以此作為規劃依據。vLLM 的配置建議要求張量並行度為 8，並搭配 FP8 KV 快取，而這正是實際服務視窗與設定視窗不再一致的那種配置。

如何在一個下午內測量自己的天花板

送出一個超出你以為上限的請求，然後讀取錯誤訊息——在多數情況下，供應商會回傳 token 數量訊息，而不是默默截斷。這會給你實際使用之主機上的服務上限，而這應該是你預算中唯一該納入的數字。

接著以該上限的 80% 送出請求，並觀察延遲。兆級參數模型在讀取長上下文時，首個 token 的產生時間會隨著提示長度增加；524K 這個數字是視窗大小，不是對速度的保證。

最後，請將得出的上限與你的第 95 百分位輸入長度比較，而不是與平均值比較。平均值永遠不會成為限制；真正的問題出現在尾端，也就是你沒有預留資源處理的分塊管線所在之處。

競爭對手的視窗看起來是什麼樣子

• DeepSeek V4 Pro — 100 萬上下文、38.4 萬輸出，離峰時段輸入 $0.66、輸出 $1.98。

• Grok 4.7 —500K 上下文、450K 輸出，一律 $2.00 與 $6.00。

• Qwen3-Max — 262K 上下文、65K 輸出，$0.36 與 $1.43。

• Mistral Large 4 —宣稱 1M、實測 524K，定價為 $1.36 與 $4.18。

在這一片競爭對手中，Mistral 實測的視窗落在 262K 與 1M 兩個宣稱之間——更靠近中間，而不是靠近上限。如果你看重的是上下文長度，那麼該放進比較表的是實測數字，而這要付出標題數字打對折的代價。

Mistral Large 4 不在 OrcaRouter 的型錄中，因此這不是我們能提供的路由；它可以透過 Mistral 自家的 API 與第三方主機呼叫。我們通常提供的是單一 OpenAI 相容端點，涵蓋 224 個模型，依供應商牌價計費且不加價——無論廠商的計費窗口最終為何，您就是按那個窗口計費。