Mistral Large 4: 52B Active Does Not Mean 52B to Store

Mistral released the improved Mistral Large 4 weights on October 29, 2026, following its earlier public preview. For developers planning a self-hosted trial, the useful next question is which checkpoint and serving configuration their hardware must hold.

Mistral’s open-weight release announcement

Keep active parameters separate from stored weights

Mistral’s model card describes roughly one trillion total parameters and 49 billion active per token, or 52 billion when embeddings and output layers are included. These are different architectural counts. The active count is not a statement that the distributed checkpoint contains only 52 billion parameters.

Mistral’s model card: total and active parameters

The official FP8 repository’s file listing showed a total size of 1.06 TB when checked on October 31 IST. That is a repository-size observation, not a prediction of exact GPU memory use. Keep the checkpoint identifier and revision beside any size copied into a planning sheet.

Official FP8 repository file listing

Choose a recipe before comparing capacity

The vLLM recipe distinguishes FP8, NVFP4 and AMD MXFP4 variants, with different weight footprints and validated hardware. It also specifies a dedicated Mistral Large 4 container image and says ordinary release or nightly wheels do not yet include support. Follow the current recipe for the selected hardware and checkpoint rather than treating a generic installation example as complete.

vLLM’s checkpoint, hardware and installation recipe

The recipe distinguishes the advertised context limit from the range it validated. That makes context and concurrency part of the trial specification, alongside weight format and hardware topology. A checkpoint download size alone cannot establish that a chosen workload will run.

A fictional capacity worksheet

For arithmetic practice only, imagine an invented deployment requiring 600 GB for weights and another 120 GB for all other resident data. Assume the entire 720 GB must be resident on eight fictional devices, each with 80 GB available. Their combined capacity is 8 × 80 = 640 GB, leaving an 80 GB shortfall under those assumptions.

Those numbers are not Mistral requirements or measured overhead. The exercise shows why a capacity worksheet needs both a complete requirement and an available-capacity figure. It does not model placement, communication, offloading or runtime behavior; passing its arithmetic would still leave those questions open.

Make the trial evidence reproducible

Before reserving hardware, write down the checkpoint revision, format, serving image, device model and count, context target and concurrent-request target. Ask the operator to identify the exact documented configuration being followed. Keep unknown compatibility or capacity questions visible instead of resolving them from the active-parameter headline.

During an isolated trial, preserve the effective configuration, startup result and observed memory use with representative requests. Record unsuccessful runs too. No model download, deployment, memory measurement or benchmark was performed for this guide. Its purpose is to help a team assemble the evidence needed for its own capacity decision.

For the performance stage of a serving trial, include both cold requests and reused context; the Supermicro KV-cache example shows why cache state changes first-token comparisons.

Once capacity is understood, evaluate completed-request latency and streaming correctness too; this Cerebras example explains those separate measurements.