1.05 Trillion Parameters, Ranked 32nd of 44: What Mistral Large 4 Tells You About Self-Hosting

On October 6, 2026, Mistral opened a public preview of Mistral Large 4, nicknamed Le Chonk. A 1.05-trillion-parameter mixture of experts with 49 billion active parameters, a 1M-token context, text and image input, and open weights scheduled for October 27. It is the largest model Mistral has built, trained from scratch on 3,800 Nvidia Grace Blackwell GPUs in the company's own European data centres. Mistral's line is that it is the strongest open-weight model built outside China. The interesting material is not that sentence, though. It is the relationship between the numbers: first of 18 on CyberGym-E2E at 82%, sixth of 75 on Harvey's legal benchmark, and 32nd of 44 on the Vals Index, while the tallest bar on Mistral's own DeepSWE chart belongs to somebody else. Open weights answer the question of who controls the deployment, not the question of whose score is higher, and blurring the two leads to bad architecture decisions.

Open weights do not make a trillion-parameter model cheap. They make it yours.

Separate open weights from light weights

The easiest mistake to make with an open-weight release is reading it as something you can just run. ML4 is sparse, so each token passes through a small subset of experts and inference compute tracks the active parameters, which puts it closer to a roughly 50B dense model. But all 1.05 trillion parameters still have to sit in memory somewhere: about 1TB in FP8, about 500GB in NVFP4, before you add KV cache. Mistral has not published hardware requirements, and that omission usually means few teams outside large enterprises and governments will serve the full model in-house. So the value of open weights here is not savings, it is control. A bank runs it on its own servers and never sends customer data to an outside API. A government agency owns the deployment environment. A security team can adjust behaviour without waiting on a provider's moderation policy. Model quality and deployment shape are separate questions, and architecture decisions go wrong when you answer them together.

# "Open weights" is not "light weights". Start with what has to sit in memory.
PRECISIONS = {"fp16": 2.0, "bf16": 2.0, "fp8": 1.0, "nvfp4": 0.5}

def weight_memory(total_params_b, precision):
    bytes_per_param = PRECISIONS[precision]
    gib = total_params_b * 1e9 * bytes_per_param / (1024 ** 3)
    return gib

for p in ("fp16", "fp8", "nvfp4"):
    for label, total in (("1.0T", 1000.0), ("1.05T", 1050.0)):
        print(f"{label:6} {p:6} -> {weight_memory(total, p):7.0f} GiB of weights alone")

# Context memory is the part people forget. Then add KV cache.
def kv_cache_gib(layers, kv_heads, head_dim, tokens, batch, bytes_per_value=2):
    per_token = 2 * layers * kv_heads * head_dim * bytes_per_value
    return per_token * tokens * batch / (1024 ** 3)

print("KV cache, 80 layers, 8 kv heads, head_dim 128, batch 8:")
for tokens in (32_768, 131_072, 1_048_576):
    print(f"  {tokens:>9,} tokens -> {kv_cache_gib(80, 8, 128, tokens, 8):7.1f} GiB")

# A 1M-token context is a product claim. This is the bill that comes with it.

Put every benchmark through a comparability check first

The habit worth taking from this launch is asking who ran a number, in which harness, and whether it is public, before looking at the value. Mistral's evidence splits three ways. Independently reproduced: the Artificial Analysis Cyber Index, including its CyberGym-E2E component, and five vals.ai evaluations including Terminal-Bench 4.0. Run by Artificial Analysis but not yet published: the DeepSWE, Terminal-Bench and SWE-Atlas scores carry a footnote saying they use numbers evaluated privately by AA ahead of the harness's public launch. Mistral-only: everything else. A harness is the scaffolding wrapped around a model during an agentic benchmark, meaning the tools, the prompts and how many attempts it gets. On the same benchmark, Mistral reports Terminal-Bench 4.0 at 28.3% while vals.ai's independent run produced 22.73%. Nobody is necessarily inflating anything, but one number from one setup is not a ranking. The comparison that does hold up is Datacurve's live DeepSWE leaderboard, where everything runs in the same harness: GLM-5.3 and Kimi K3 both reach 69%, DeepSeek V4 Pro reaches 63%, and ML4 is not listed yet.

# Before you compare two benchmark numbers, check they came from the same harness.
import json

VENDOR_CLAIMS = [
    {"model": "Mistral Large 4", "bench": "DeepSWE v1.1", "score": 61.7, "run_by": "artificial_analysis_private", "harness": "AA-internal", "public": False},
    {"model": "Kimi K3",       "bench": "DeepSWE v1.1", "score": 69.0, "run_by": "vendor",   "harness": "self", "public": True},
    {"model": "GLM-5.3",       "bench": "DeepSWE v1.1", "score": 69.0, "run_by": "datacurve", "harness": "deepswe-live", "public": True},
    {"model": "Mistral Large 4", "bench": "Terminal-Bench 4.0", "score": 28.3, "run_by": "vendor",  "harness": "self", "public": True},
    {"model": "Mistral Large 4", "bench": "Terminal-Bench 4.0", "score": 22.7, "run_by": "vals.ai", "harness": "vals", "public": True},
]

def spread_by_bench(rows):
    out = {}
    for r in rows:
        out.setdefault(r["bench"], {}).setdefault(r["model"], []).append((r["score"], r["run_by"], r["harness"]))
    return out

for bench, models in spread_by_bench(VENDOR_CLAIMS).items():
    print(bench)
    for model, runs in models.items():
        for score, who, harness in runs:
            delta = ""
            if len(runs) > 1 and score == min(x[0] for x in runs):
                delta = "  <-- lower independent run"
            print(f"  {model:18} {score:6.1f}  run_by={who:26} harness={harness}{delta}")

# The same model on the same benchmark differed by 5.6 points across two setups.
# One number from one harness is not a ranking.

Serving a sparse model is a memory bandwidth problem long before it is a compute problem.

On the cyber chart, read the refusals

This is Mistral's boldest claim and the one with independent evidence behind it. On Artificial Analysis's Cyber Index, which measures how well models find, reproduce and patch real vulnerabilities, ML4 scores 50% and places in the top five of 18. Only Grok 4.7, MiMo-V2.6-Pro and GPT-6 Luna score higher, with GLM-5.3 Flash tying it. It ranks first of 18 on CyberGym-E2E at 82%. The number worth as much attention is the refusal data on the same chart: Claude Opus 5.5 is blocked on safety grounds for roughly 96% of CyberGym-E2E tasks and GPT-6 Astra for 100%, which is why their scores sit near zero. For a security team that reproduces CVEs in volume, scanning large codebases and triaging hundreds of findings, proving a flaw exists is the first step of defensive work, and a model that declines most of that workload is a liability in that workflow. Mistral's argument is that running ML4 on your own infrastructure puts its behaviour under your control. The counterweight is equally clear: once the weights are public, attackers get the same capability. AA's index is deliberately defensive, working from source code and never asked to build a working exploit, so 82% is not 82% offensive capability. It is also not infinitely far from it.

# Cyber scores need the refusal rate next to them, or they mean nothing.
CASES = [
    {"model": "Mistral Large 4", "score": 82.0, "blocked_pct": 0.0,  "origin": "open-weight", "vendor": "Mistral"},
    {"model": "MiMo-V2.6-Pro",   "score": 79.0, "blocked_pct": 0.0,  "origin": "open-weight", "vendor": "Xiaomi"},
    {"model": "GPT-6 Luna",      "score": 78.0, "blocked_pct": 0.0,  "origin": "closed", "vendor": "OpenAI"},
    {"model": "Claude Opus 5.5", "score": 2.0,  "blocked_pct": 96.0, "origin": "closed", "vendor": "Anthropic"},
    {"model": "GPT-6 Astra",     "score": 1.0,  "blocked_pct": 100.0, "origin": "closed", "vendor": "OpenAI"},
]

def explain(rows):
    print(f"{'model':18} {'score':>6} {'blocked':>8}  reading")
    for r in sorted(rows, key=lambda x: -x["score"]):
        if r["blocked_pct"] >= 90:
            reading = "score reflects policy, not capability"
        elif r["blocked_pct"] > 0:
            reading = "partially usable for defensive work"
        else:
            reading = "ran the task"
        print(f"{r['model']:18} {r['score']:6.1f} {r['blocked_pct']:7.1f}%  {reading}")

explain(CASES)

# A near-zero score on a defensive benchmark can mean the model refused, not that it failed.
# If your security team reproduces CVEs in volume, that distinction is the whole decision.

The hardware arithmetic behind a sparse model

The intuition with a mixture of experts is that activating 49B means paying for 50B, and that intuition is only half right. Decode really is memory-bandwidth bound, with weight reads set by the active parameter count, so generation speed lands near a 50B dense model. Prefill is compute bound, and the attention component scales with the square of query length, which is the form a 1M-token context claim takes on your bill. Meanwhile every parameter has to be resident: at NVFP4, 1.05T needs roughly 500GB just for weights, which leaves little comfortable headroom on an eight-GPU node of about 1,128GiB usable before you add KV cache and batch space. If you are buying multi-GPU hardware purely to run this model, work the arithmetic first. If your motivation is residency and compliance, the arithmetic is a different calculation entirely.

# Sparse models: pick the gate before you decide anything else.
import math

def serving_profile(total_b, active_b, tokens_per_sec, precision="fp8"):
    weight_gib = total_b * 1e9 * {"fp16": 2, "fp8": 1, "nvfp4": 0.5}[precision] / (1024 ** 3)
    flops_per_token = 2 * active_b * 1e9
    # Dense-equivalent throughput is usually memory bound at batch 1, so report both.
    return {
        "weight_gib": round(weight_gib),
        "flops_per_token": round(flops_per_token / 1e9, 1),
        "tflops_required": round(flops_per_token * tokens_per_sec / 1e12, 1),
        "prefill_note": "compute bound: scales with query length squared at attention",
        "decode_note": "memory bound: weight reads dominate, hence the active-parameter count",
    }

for label, total, active in (("ML4 preview", 1000.0, 49.0), ("ML4 docs", 1050.0, 52.0)):
    print(label, serving_profile(total, active, 30))

print()
print("hypothetical 8x GPU node, 141 GiB usable each:", 8 * 141, "GiB")
print("ML4 in nvfp4 needs roughly", round(1050 * 1e9 * 0.5 / 1024 ** 3), "GiB for weights")

# The active-parameter count sets decode compute, but all the weights still have to
# be resident somewhere. That is why "cheap to run" and "1T parameters" rarely coexist.

The cyber pitch is real, and so is the fact that the same weights become available to everyone.

Beyond the scores: licences and roadmaps

The things that actually decide whether you can ship on this model are the ones still undefined. The licence terms are not published, which is a slightly awkward gap for a model whose pitch is control, so commercial use, fine-tuning rights and redistribution all remain open. Pricing disagrees between the announcement and the documentation page, and preview rates may not carry forward. The context window is 1M tokens in Mistral's docs and 512K on vals.ai, unresolved. Full architecture, hardware requirements and final safety evaluation are all promised for October 27 with the weights. And the reinforcement learning run is still going, reportedly on about 3,000 GPUs producing roughly 33 billion tokens a day, which means there are two models to evaluate: the API version today and the checkpoint released at the end of the month. Keeping vendor-reported, independently reproduced and privately run scores in separate columns saves a lot of rework later.

# Vendor-reported, independently run, and unverifiable are three different things. Track them.
from dataclasses import dataclass, field, asdict

@dataclass
class Score:
    bench: str
    value: float
    source: str          # vendor | independent | private
    public: bool
    notes: str = ""

@dataclass
class ModelLedger:
    name: str
    scores: list = field(default_factory=list)

    def add(self, **kw):
        self.scores.append(Score(**kw))

    def decision_readiness(self):
        ind = [s for s in self.scores if s.source == "independent"]
        priv = [s for s in self.scores if s.source == "private"]
        return {
            "total_scores": len(self.scores),
            "independently_reproduced": len(ind),
            "private_and_unverifiable": len(priv),
            "verdict": "usable" if ind else "wait for weights",
        }

ml4 = ModelLedger("Mistral Large 4")
ml4.add(bench="AA Cyber Index", value=50.0, source="independent", public=True)
ml4.add(bench="CyberGym-E2E", value=82.0, source="independent", public=True)
ml4.add(bench="DeepSWE v1.1", value=61.7, source="private", public=False, notes="run by AA, not yet published")
ml4.add(bench="Coding Agent Index", value=49.8, source="private", public=False)
ml4.add(bench="Cybench", value=93.0, source="vendor", public=True)
ml4.add(bench="Vals Index", value=48.05, source="independent", public=True, notes="32nd of 44")

print(ml4.decision_readiness())
for s in ml4.scores:
    print(f"  {s.bench:22} {s.value:7.2f} {s.source:12} public={s.public}")

# Weights are scheduled for October 27. After that date, 'private' scores become checkable.
# Before it, treat them as claims about a checkpoint that is still training.

The real bet is sovereignty, not the leaderboard

Put ML4 back in its context and Mistral is not selling a first place. President Macron has described the approach as a third way in AI: the first two being US closed models, capable but subject to American law and vendor policy, and Chinese open models, often capable but a data residency and geopolitical worry for European institutions. The third is open weights, European infrastructure and European law. There is money behind that positioning: Mistral calls ML4 the first milestone on a roadmap funded by a €3 billion Series D led by Samsung at a €21 billion valuation, which the company describes as the largest equity round ever raised by a European technology company, with most of it going into European data centre capacity. So the question is not whether ML4 is the strongest model available. It is whether Europe can produce frontier-class capability while giving organisations more control over where it runs. On control, this release is a strong data point. On the frontier, 32nd of 44 says not yet.