Mistral Small 4 vs Small 3.2 24B: what the new generation changes

Small 4: a single model that unifies three families

The context: two models, two architectures

The two models are not the same size. Small 3.2 is a dense model with 24 billion parameters and a 128k-token context window. Small 4 is a Mixture of Experts (MoE) model with 119 billion parameters, of which only 6.5 billion are activated per token (128 experts, 4 active), and a 256k-token context window. It is therefore fast at inference, but far more demanding in GPU memory: all of its experts have to be loaded.

Mistral Small 3.2 (June 2025) is a targeted update of the 3 series: better instruction following, fewer repetitions, better function calling. Mistral Small 4 (March 2026) goes further: it unifies reasoning (Magistral), vision (Pixtral) and agentic coding (Devstral) in a single model, with a configurable reasoning effort.

Benchmark progression (Small series)

Score in %, higher is better

Comparison table

Criterion	Small 3.2 (24B)	Small 4 (119B MoE)
Parameters	24B (dense)	119B (MoE), 6.5B active per token
Context	128k	256k
GPU memory	~55 GB in BF16 (official model card)	~120 GB for the FP8 weights alone; 2 GPUs in the official vLLM setup
Vision / multimodal	Yes: text and images	Yes (Pixtral built in)
Reasoning	Standard	Configurable (Magistral)
Agentic coding	Good	Reinforced (Devstral)
Inference throughput	Baseline	−40% time, ×3 req/s vs Small 3
MMLU Pro level	Solid	Close to Medium 3.1 / Large 3

What it changes for a sovereign AI

Two gains really count in production:

• Throughput: Mistral announces −40% completion time and 3 times more requests per second compared with Small 3. These are Mistral's figures, on its own setup: since Small 4 needs more GPU memory than Small 3.2, the real gain in per-seat cost depends on your workload and has to be recalculated (see our VRAM calculator).
• Versatility: a single model for text, images and code simplifies operations (one model to host, not three) and opens up new document use cases (analysing plans, scans, tables).

Since our stack is model agnostic, moving from Small 3.2 to Small 4 changes neither the interface, nor the RAG, nor operations. The sizing does change: 119B parameters instead of 24B, so around 120 GB of weights in FP8, which the official vLLM command spreads across 2 GPUs. We evaluate Small 4 on our clients' real use cases before any deployment, because a public benchmark never replaces a test on your own documents.

Our recommendation

Small 3.2 already handles text and images. Compare it with Small 4 on the same documents: quality, reasoning, context, latency and total weight memory. Active parameters alone do not describe memory requirements.