Mistral Large 4:1T 總參數、每 token 約 49B 活躍參數,開放權重實際改變了甚麼?
A 1T Model With a 52B Bill: What Mistral Large 4's Open Weights Actually Change
Mistral Large 4 開放權重帶來的實際變化,取決於每項完成任務的 token 成本、自行部署門檻與授權條款,而不只是權重可下載。
文章以每項已完成任務的 token 用量取代單看基準分數,説明這種衡量方式如何對應智能體編碼的實際成本。
One trillion parameters total, 49 billion active per token, 128 routed experts with only four consulted per token, a one-million-token context window, and an Artificial Analysis Coding Agent Index score of 48 percent while burning 47 percent fewer tokens per task than the model it ties with. Those five numbers from Mistral's release notes for Mistral Large 4 tell you more about the open-weight model market than any headline about the weights being "open" does. The weights being downloadable is the easy part of the story. The interesting part is what the architecture, the license, and the serving math do to the teams that actually download them.
This article reads the release the way an infrastructure decision deserves: not as a leaderboard event, but as a set of contracts you are about to sign with your GPU budget, your legal team, and your agent harness.
The architecture is the pricing model
Mistral Large 4 is a granular mixture-of-experts model: 128 routed experts, four active per token, plus one shared expert, for roughly one trillion total parameters with about 49 billion active per token, or 52 billion once embeddings and output layers are counted. It was trained from scratch on 3,800 NVIDIA Grace Blackwell GPUs in Mistral's own European datacenters, and it accepts text and image input with text output.
The reason to care about the expert split is economic, not academic. Every token you generate pays the compute cost of the active path — roughly 49 billion parameters — while the model's knowledge capacity is set by the full trillion. That gap between what you pay per token and what the model knows is the entire value proposition of MoE at this scale, and it is why the headline comparisons to dense frontier models are misleading in both directions. Dense models with far fewer total parameters can cost more per token to serve; dense models with comparable quality usually do.
The checkpoint also ships with an embedded DSpark speculative decoding draft head, which matters because speculative decoding is normally an operational add-on you tune yourself. Having a draft head trained alongside the model removes one of the fiddliest serving decisions from the critical path.
Read the token-efficiency claim carefully
Mistral's own framing is precise and worth quoting precisely: on the Artificial Analysis Coding Agent Index, Mistral Large 4 scores 48 percent, effectively tied with GLM-5.3 as the leading open-weight model, while using 47 percent fewer tokens per task on average. On Terminal-Bench 4.0, the release candidate improved 13 percentage points over the public preview to reach 41 percent, while reducing output tokens by 30 percent.
Notice what is being claimed. It is not "best at coding" in the abstract. It is "tied at the front of the open-weight field, at roughly half the token bill." For agentic coding, where a single task can consume hundreds of thousands of output tokens across planning, tool calls, and self-correction, token count per solved task is the number that shows up on your invoice. A model that is five percent better but twice as verbose is often the more expensive model in production.
This is also the claim you can verify yourself before committing. Run a fixed set of your own agentic tasks, count total input and output tokens per solved task — not per prompt — and compare that against whatever you serve today. Aggregate benchmark scores will not transfer to your workload; token-per-solved-task measurements will.
Three reasoning modes are a budget dial
Mistral Large 4 exposes three reasoning efforts — low, medium, and high, with high as the default — configurable per request. Combined with the recommended sampling settings of temperature 1.0 and top-p 0.95, this is effectively a cost-performance dial built into the API surface rather than a separate model SKU.
The operational pattern that falls out of this is routing, not upgrading. A chat reply that needs to feel instant goes to low. A routine code edit goes to medium. A multi-step agentic run with tool calls goes to high. Teams that already route between a small model and a large model can, with this release, route between effort levels of one model instead — which collapses two serving footprints into one and removes the quality cliff between tiers.
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")
One caution: max_completion_tokens counts reasoning tokens as well as visible output. A high-effort request with a tight token cap can return mostly invisible reasoning and little answer. Budget the cap for the effort level, not for the visible reply you expect.
The self-hosting math, stated plainly
Here is where the trillion-parameter headline stops being marketing. Weight memory is arithmetic, and the arithmetic is stern. At BF16, one trillion parameters occupy roughly two terabytes. At FP8, roughly one terabyte. Mistral also publishes an NVFP4 quantized checkpoint targeting Blackwell GPUs, which lands near half a terabyte before KV cache and activations.
The official serving path is a vLLM image with eight-way tensor parallelism, which tells you what Mistral considers the normal deployment unit: a full eight-GPU node.
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
Two flags in that command are easy to overlook and painful to discover later: --tool-call-parser mistral and --reasoning-parser mistral are required for function calling and for separating reasoning from visible content. Skip them and the model still responds, but your agent harness silently loses the two features this model is built around.
If memory runs short, the documented levers are lowering --max-model-len and --max-num-seqs — context length and concurrency — before touching quantization. For smaller footprints, community GGUF builds for llama.cpp exist, and Axolotl, Unsloth, and TRL all have documented fine-tuning paths. But be honest about the floor: this is not a model you run on a workstation to "try it out." The try-it-out path is the hosted API; the download path is a capacity decision.
The license clause to read before your CFO does
Mistral Large 4 ships under the Mistral Ecosystem Open-Weight License, a modified MIT license. Use, modification, fine-tuning, and commercial deployment are all permitted, with exactly one carve-out: operating a Model-as-a-Service offering with these weights requires a separate commercial license from Mistral.
For most teams this changes nothing — if you run the model inside your own product, you are fine. But the carve-out is aimed precisely at resellers and hosted-provider businesses, and it is the kind of clause that surfaces late in procurement if nobody reads it early. The practical rule: if your customers send you prompts and you send back tokens, read the license twice and talk to Mistral once. Everyone else can treat the weights as effectively MIT.
Where the API price sets the break-even line
The hosted API is priced at 0.70 USD per million input tokens, 0.07 USD per million cached input tokens, and 2.10 USD per million output tokens. That price list is the benchmark your self-hosting spreadsheet has to beat, and it is a harder benchmark than it looks, because the cached-input tier is doing quiet work: agentic workloads resend long prefixes — system prompts, tool definitions, repository context — on every turn, and a tenfold discount on those tokens compounds across a long agent run.
A defensible comparison multiplies real measured traffic, not round numbers:
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")
Self-hosting wins when sustained utilization is high enough to amortize an eight-GPU node, when data-residency rules forbid the API anyway, or when fine-tuning on proprietary data is the actual goal. It loses — decisively — at spiky, low, or experimental volume. The release does not change that logic; it gives the logic a much stronger model to apply to.
What this release actually changes
Step back from the numbers and the release is a signal about where the open-weight frontier is being contested. The competitive axis is no longer raw capability — the Intelligence Index score of 26 leads only among western open-weight models, and Mistral says so itself. The axis is cost per solved task, deployment sovereignty, and agentic reliability, which is why the announcement spends so much of its length on token efficiency, on the B3 Agent Security Benchmark result of 97.1 percent attack resistance, and on European training provenance.
If you run coding agents at scale, the actionable move is a bake-off measured in tokens per solved task, not benchmark points. If you are in a regulated European industry, the actionable move is reading the license and the sovereignty story, which are the parts of this release built for you. And if you just want to try it, the actionable move is the API or the hosted demos — the weights will still be there when your traffic justifies an eight-GPU node, and not a day before.
Originally published on Dispatch.
來源:DEV Community · dev.to