Mistral Large 4：1T 總參數、每 token 約 49B 活躍參數，開放權重實際改變了甚麼？

總計一萬億個參數、每個 token 啟用 490 億個參數、128 個路由專家但每個 token 只會調用 4 個、一百萬 token 的上下文視窗，以及 Artificial Analysis Coding Agent Index 的得分為 48%，而每項任務消耗的 token 比得分與它並列的模型少 47%。這五個數字來自 Mistral Large 4 的發佈説明，比任何關於權重「開放」的標題，都更能説明開放權重模型市場的情況。權重可以下載，只是故事中最簡單的部分。真正值得關注的是，架構、授權條款和推理服務的成本計算，會如何影響實際下載模型的團隊。

本文以基礎設施決策應有的角度解讀這次發佈：不是把它視為排行榜上的一場較量，而是看作一系列你即將與 GPU 預算、法務團隊及 Agent 執行框架訂下的約定。

架構就是定價模式

Mistral Large 4 是一個採用精細化混合專家架構的模型：有 128 個路由專家，每個 token 啟用 4 個，另加一個共享專家；總參數約一萬億個，每個 token 約啟用 490 億個參數，若計入嵌入層和輸出層則為 520 億個。模型從零開始訓練，使用 3,800 部 NVIDIA Grace Blackwell GPU，部署於 Mistral 自家的歐洲數據中心；它接受文字和圖像輸入，並輸出文字。

關注專家分配的原因在於經濟效益，而非學術考量。你生成的每個 token，都要支付啟用路徑的計算成本——約 490 億個參數；而模型的知識容量則由完整的一萬億個參數決定。每個 token 的成本與模型所掌握的知識之間的差距，正是這種規模下 MoE 的全部價值所在；也正因如此，拿它與前沿稠密模型作 headline 式比較，無論哪個方向都會造成誤導。總參數少得多的稠密模型，每個 token 的推理服務成本可能更高；品質相若的稠密模型通常也是如此。

模型檢查點亦內置 DSpark 投機解碼草稿頭，這點值得留意，因為投機解碼通常是需要自行調校的額外營運項目。草稿頭與模型一同訓練，省去了推理服務流程中一項最繁瑣的決策。

仔細解讀 token 效率方面的主張

Mistral 的説法精確而值得原文引用：在 Artificial Analysis Coding Agent Index 上，Mistral Large 4 得分為 48%，與領先的開放權重模型 GLM-5.3 基本並列，平均每項任務使用的 token 則少 47%。在 Terminal-Bench 4.0 上，候選發佈版本較公開預覽版提升 13 個百分點，達到 41%，同時輸出 token 減少 30%。

請留意這項主張的內容。它並不是籠統地説「編碼能力最佳」，而是説「在開放權重模型中並列領先，但 token 開支大約只有一半」。在 Agent 式編碼任務中，單一任務在規劃、工具呼叫及自我修正過程中，可能消耗數十萬個輸出 token；因此，每項已完成任務的 token 數量，才是最終會出現在帳單上的數字。某個模型即使表現好 5%，但輸出冗長一倍，在正式環境中往往反而成本更高。

這項主張亦可以在你作出承諾前自行驗證。固定一組你自己的 Agent 式任務，計算每項已完成任務的輸入和輸出 token 總數——而不是每個提示詞的 token 數——再與你目前使用的模型比較。綜合基準測試分數未必能套用到你的工作負載；每項已完成任務的 token 數據則可以。

三種推理模式就像預算調節旋鈕

Mistral Large 4 提供低、中、高三種推理強度，預設為高，並可按每次請求設定。配合建議的取樣設定——temperature 1.0 和 top-p 0.95——這實際上是在 API 介面內建了成本效能調節旋鈕，而不是另設一個模型 SKU。

由此衍生的操作模式是路由，而非升級。需要即時回覆的聊天請求使用低推理強度；日常程式碼修改使用中等推理強度；涉及工具呼叫的多步驟 Agent 執行流程則使用高推理強度。已經在小型模型和大型模型之間路由的團隊，現在可以改為在同一模型的不同推理強度之間路由——把兩種服務部署規模合而為一，也消除不同級別之間的品質落差。

from openai import OpenAI

client = OpenAI(
    api_key="EMPTY",
    base_url="http://localhost:8000/v1",
)
model = client.models.list().data[0].id

def ask(prompt: str, effort: str) -> str:
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        temperature=1.0,
        top_p=0.95,
        extra_body={"reasoning_effort": effort},  # low | medium | high
    )
    return response.choices[0].message.content

quick_answer = ask("What port does Postgres listen on?", "low")
deep_answer = ask("Design the migration plan for this schema.", "high")

要注意：max_completion_tokens會把推理 token 和可見輸出一併計算。高推理強度的請求若設定的 token 上限過低，回傳內容可能大多是不可見的推理，答案則很少。設定上限時，應按推理強度預留 token，而非只按預期的可見答覆計算。

自行託管的計算，直白説明

萬億參數這個標題在此就不再只是宣傳字眼。權重記憶體的計算很直接，而且結果不容忽視。以 BF16 格式計算，1 萬億個參數約佔兩太位元組；以 FP8 格式計算，約佔一太位元組。Mistral 亦發布了針對 Blackwell GPU 的 NVFP4 量化檢查點，在計入 KV 快取和激活值之前，佔用約半太位元組。

官方建議的服務部署方式是使用 vLLM 映像檔並採用八路張量平行，這反映了 Mistral 認為的標準部署單位：一台配備八個 GPU 的完整節點。

docker pull vllm/vllm-openai:mistral-large-4

docker run --runtime nvidia --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  --ipc=host \
  vllm/vllm-openai:mistral-large-4 \
  --model mistralai/Mistral-Large-4-1T-A52B \
  --tensor-parallel-size 8 \
  --tool-call-parser mistral \
  --reasoning-parser mistral \
  --enable-auto-tool-choice \
  --gpu-memory-utilization 0.85

這個指令中有兩個容易忽略、但日後發現缺少時會造成麻煩的旗標：--tool-call-parser mistral和--reasoning-parser mistral。它們是功能呼叫，以及把推理內容和可見內容分開所必需的。若省略它們，模型仍會回應，但你的 Agent 執行框架會在不知不覺間失去這款模型的兩項核心功能。

如果記憶體不足，文件建議先降低--max-model-len和--max-num-seqs——即上下文長度和並行數——再調整量化。若要採用較小的部署規模，社羣已有適用於 llama.cpp 的 GGUF 版本，而 Axolotl、Unsloth 和 TRL 均有文件記載的微調流程。不過，必須清楚瞭解最低門檻：這不是一款可在工作站上執行來「試用」的模型。試用方式是使用託管 API；下載模型則是容量規劃上的決定。

CFO 閲讀之前，先看清這項授權條款

Mistral Large 4 採用 Mistral Ecosystem Open-Weight License，這是一份修改版 MIT 授權條款。使用、修改、微調和商業部署均獲準，只有一項例外：若使用這些權重營運 Model-as-a-Service 服務，必須向 Mistral 另行取得商業授權。

對大多數團隊而言，這不會帶來任何改變——只要你在自家產品內執行模型，就沒有問題。但這項例外正是針對轉售商和託管服務供應商，若沒有人及早閲讀，這類條款往往會在採購流程後期才浮現。實際做法是：如果客戶向你提交提示詞，而你再向他們回傳 token，就應仔細閲讀授權條款兩次，並聯絡 Mistral 一次。其他人都可把這些權重視作實際上採用 MIT 授權。

API 價格如何劃定損益平衡線

託管 API 的價格為每百萬個輸入 token 0.70 USD、每百萬個快取輸入 token 0.07 USD，以及每百萬個輸出 token 2.10 USD。這份價格表就是自行託管試算表必須勝過的基準，而且這個基準比表面看來更難達到，因為快取輸入的價格級別正默默發揮作用：Agent 工作負載每一輪都會重新傳送長前綴——系統提示詞、工具定義、程式碼庫背景資料——而這些 token 的價格打了一折，在長時間的 Agent 執行過程中，節省的成本會不斷累積。

可靠的比較應以實際測得的流量計算，而非約數：

PRICE_INPUT = 0.70        # USD per million tokens
PRICE_CACHED = 0.07       # USD per million cached input tokens
PRICE_OUTPUT = 2.10       # USD per million tokens

def monthly_api_cost(tasks: int, fresh_in: int, cached_in: int, out: int) -> float:
    """Cost for `tasks` agentic runs with measured per-task token counts."""
    per_task = (
        fresh_in * PRICE_INPUT
        + cached_in * PRICE_CACHED
        + out * PRICE_OUTPUT
    ) / 1_000_000
    return tasks * per_task

# Example: 200k tasks, each with 20k fresh input, 300k cached prefix, 15k output
estimate = monthly_api_cost(200_000, 20_000, 300_000, 15_000)
print(f"estimated monthly API spend: {estimate:,.2f} USD")

當持續利用率高得足以攤分八 GPU 節點的成本、數據駐留規則本來就禁止使用 API，或實際目標是以專有數據進行微調時，自行託管才有優勢。若使用量波動大、偏低或仍屬實驗階段，自行託管就會明顯處於下風。這次發布並沒有改變這套邏輯；它只是提供了一個強得多的模型，讓你運用這套邏輯。

這次發布實際帶來的改變

撇開數字來看，這次發布傳達了一個訊號，顯示開放權重模型前沿的競爭焦點所在。競爭軸線已不再是原始能力——Intelligence Index 得分 26，只在西方開放權重模型中領先，Mistral 自己也如此表述。競爭焦點在於每項已解決任務的成本、部署自主權，以及 Agent 的可靠性；這就是為何公告用了這麼多篇幅談 token 效率、B3 Agent Security Benchmark 的 97.1% 攻擊抵抗率，以及歐洲訓練來源。

如果你大規模運行編碼 Agent，切實可行的做法是進行對照測試，以每項已解決任務所耗用的 token 數衡量，而不是比較基準測試分數。如果你身處受監管的歐洲行業，切實可行的做法是細閲授權條款和主權方面的論述；這次發布的相關內容正是為你而設。如果你只是想試用，切實可行的做法是使用 API 或託管示範——等到流量足以支持八 GPU 節點時，模型權重仍會在那裏；在此之前則不必急於部署。

原刊於 Dispatch。