8張H200跑131K上下文：Mistral Large 4開放權重後，本地部署與API的帳要分三欄算
Mistral Large 4 開放權重後，本文從硬體、推論工具鏈與維運三欄，拆解本地部署與 API 的總成本比較框架。
刊登 閱讀約 5 分鐘
2026年10月29日，Hugging Face 發布 Mistral Large 4（代號 Le Chonk）的 Inference Endpoints 部署配方，配置為 8 張 NVIDIA H200、FP8 權重，平臺報告可開放最多 131K 上下文、同時處理 16 個請求。同一日另列出 vLLM 的 H200 NVFP4 配方。這兩份是平臺端點配方與測試結果，距通用硬體採購清單還有一段距離，但足以作為企業比較「自架 vs. API」的起點數字。
開放權重的第一個陷阱：規格口徑還沒對齊
Mistral 在 10 月 6 日的 preview 模型文件列出 1.05 兆總參數、52B active parameters、1.6B 視覺編碼器；10 月 29 日 Hugging Face 的釋出說明則描述每 token 約啟用 49B 參數。兩份文件口徑不同，現有資料無法認定差異來自哪些層的計算方式。對做部署預算的人而言，這提醒了一件事：活躍參數決定每 token 的計算量，但記憶體需求由總權重決定，兩欄必須分開估。
MoE 架構讓每個 token 只經過部分專家，推理算力帳因此比稠密模型好看；但部署端仍須載入或分散儲存全部專家權重，VRAM 容量門檻沒有跟著打折。這也是為什麼「權重可下載」不等於「一般工作站可承載」。
三個已公開的部署案例，數字落差本身就是資訊
目前可查證的實測輪廓有三組：
Hugging Face 的 FP8 端點測試報告列出：1K 輸入、單請求首 token 約 0.6 秒；1,000 段 ShareGPT 負載下總生成約 480 token／秒。llama.cpp 團隊則在 512GB 統一記憶體的 M3 Ultra 上測 Q2_K 量化版，輸入約 90 token／秒、生成約 15 token／秒。兩者相差一個數量級以上，且分別代表服務級與單機級的取向：Q2_K 的結果不能直接推斷可用於長上下文或多使用者服務，量化本身就是以精度與相容性換記憶體的取捨。Dell B300 配方目前只有執行命令，沒有實測吞吐數據，不能由配方倒推成本。
值得注意的是規格與端點的落差：模型文件標示 1M context window，H200 FP8 端點實際只開放 131K。企業若以為下載權重就能拿到百萬級上下文的服務水準，長對話場景還須另外驗證檢索品質、延遲與 KV cache 記憶體。
總成本要拆三欄：硬體、工具鏈、維運
APPI News 的分析把部署預算拆成硬體、工具鏈與維運三部分，這個框架比單純比較 GPU 價格與 API 帳單務實。
硬體欄不只是 GPU：權重與 KV cache 的記憶體、儲存、網路、供電都計入，而長上下文與同時請求數會直接放大 KV cache 需求，實際容量須以特定模型版本、精度與上下文長度實測。工具鏈欄，vLLM 與 SGLang 的相容性會隨模型、硬體與版本變動，Hugging Face 的 FP8 配方用了張量與專家平行化加上投機解碼，這類調校本身就是工程投入。維運欄最容易被低估：監控、資安與故障恢復的人力，是 API 路線已包含在單價內、自架路線須自付的部分。
影響推演：誰該自架，誰該付 API
傳導邏輯大致可這樣記帳。低用量、需求波動大的使用者，API 把固定成本轉為變動成本，且平臺配方（如 8 張 H200 端點）隨開即用，工具鏈與維運由平臺吸收。高且穩定的吞吐需求，自架的單位成本才有機會壓過 API 帳單，但前提是工作負載已實測到可預測的吞吐與延遲。卡在中間的，託管端點是折衷：拿開放權重的客製彈性，把硬體維運外包。
受壓的一端是「以為開放權重等於便宜」的評估流程：若只看模型授權免費、不估 KV cache 與平行化工程，自架預算會在 PoC 之後才爆開。受惠的一端是 H200 與 B300 等高階推理卡的租賃與託管市場，開放權重模型每次釋出，都把推理算力的需求從 API 帳單搬到硬體租用那一欄。
這與我們先前拆解FLUX.3 Image Klein 的部署成本帳時的結論同構：標榜低門檻的開放權重模型，真正的帳都在部署後的驗證階段。而對主權與治理優先的歐洲企業，Kolibri 的主權 AI 帳顯示，自架的成本溢價有時買的是資料治理，不只是 token 單價。
收束：先鎖工作負載，再談部署路線
Mistral Large 4 的三個公開案例（H200 FP8、B300 NVFP4、M3 Ultra Q2_K）覆蓋了服務級到單機級的頻譜，但沒有一個可以替代企業自身的負載實測。現有的可核實數字支持一個保守結論：比較本地部署與 API，應先確認工作負載型態與服務目標（吞吐、延遲、上下文長度、同時請求數），再套硬體與維運數字。至於 1M 上下文在自架環境的真實成本，目前公開資料尚未提供實測，這一欄只能留白，不宜預先填數。
（事實數據來源：Hugging Face 2026年10月29日部署配方與測試報告、Mistral AI 10月6日模型文件、APPI News 分析文章）