TL;DR — Mistral Small 3.2 24B is a dense, vision-capable model with a 131,072-token context window that's small enough to run on a single 24GB GPU or a 32GB Mac. Probes show solid coding and multi-step reasoning at roughly 25-27 tokens/sec, though one structured-output probe hit an upstream rate limit rather than a model failure. It's a strong pick for offline coding help, local document Q&A, and privacy-bound drafting — but it's not a substitute for a big MoE when you need long, multi-document synthesis or frontier-level reasoning depth.
Most open-weight model releases ask you to either rent a rack or accept a toy. Mistral Small 3.2 24B is aimed squarely at the gap in between: a dense 24-billion-parameter model with a 131,072-token context window and vision input, sized to live on a single workstation GPU instead of a cluster. That's the pitch. Let's see what actually holds up.
What's actually in the box
Per its metadata, Mistral Small 3.2 24B (Hugging Face ID mistralai/Mistral-Small-3.2-24B-Instruct-2506) ships with a 131,072-token context length — that's the full 128K class, not a marketing rounding-up from something smaller. On OpenRouter it's priced at $0.075 per million prompt tokens and $0.20 per million completion tokens, which is cheap enough that cost stops being the reason you'd avoid it for a long-document job. The "2506" in the HF ID marks it as a mid-2025 refresh of the Small line, and it carries vision input, so it's not text-only — screenshots, diagrams, and scanned documents are in scope, not just prose.
Being dense (not a mixture-of-experts) matters here: every one of those 24B parameters is active on every token, which is exactly why this is the model that fits a 24GB GPU or a 32GB Mac at a reasonable quantization, while the giant MoEs need far more VRAM just to hold their (mostly idle) expert banks in memory.
Where this model actually earns its keep
The interesting question for a 24B dense model isn't "is it smart" — it's "what job is it the right size for." Three cases stand out:
Offline coding help on a single machine. A dense 24B that fits on one GPU means a developer can run a real coding assistant on a laptop or workstation with no API calls, no data leaving the building, and no per-token bill creeping up as the codebase grows. In the code probe, asked to write a Python
merge_intervalsfunction and state its complexity, the model produced a correct sort-then-merge implementation and correctly identified it as O(n log n) — the kind of small, self-contained task this size class handles cleanly, in 6.1 seconds at 27 tokens/sec.Local document Q&A over the full context window. With 131,072 tokens of context and vision support, you can hand this model a stack of contracts, a scanned invoice, or a long design doc without chunking it into pieces first — a real advantage over smaller context models when the whole point is "answer this from the document, not from memory."
Privacy-bound drafting. Legal teams, clinical-adjacent workflows (drafting only, not diagnosis), and internal HR or compliance writing all share a constraint: the text can't leave the network. A model that runs entirely on-prem on hardware a single team already owns removes the vendor-data-handling question from the conversation entirely, which is often worth more than a few points of benchmark score.
The common thread: these are jobs where "good enough, private, and cheap to run all day" beats "best in class, but it's someone else's server."
What the probes actually showed
The reasoning probe is the more revealing one. Given a tank-filling word problem — 2,400 liters, a fill pump and a drain pump running together for 20 minutes, then the drain pump switching off — the model correctly computed the net fill rate (30 L/min), the volume after 20 minutes (600 liters), the remaining volume (1,800 liters), and the additional time needed at 90 L/min (20 minutes). Every arithmetic step is right. The completion was cut off mid-sentence at 353 tokens before it stated the final boxed answer, running at 24.8 tokens/sec over 14.2 seconds — the reasoning itself checks out, even though the response got clipped before delivering the closing line.
The structured-output probe, asking the model to extract vendor, date, and total from an invoice into strict JSON, didn't return usable output at all — it hit a 429 upstream rate-limit error from the API provider before generating a single token. That's an infrastructure hiccup, not a verdict on the model's JSON-extraction ability, and it's worth flagging honestly rather than papering over: sometimes the probe tells you about the day's traffic, not the model.
Where a 24B honestly runs out of road
Being sized for one GPU is a feature until the job outgrows the size. A dense 24B has a fixed capacity ceiling — there's no expert routing to lean on for a sudden burst of domain-specific reasoning the way a large MoE can. Practically, that shows up in a few places:
Multi-document synthesis across dozens of long files, where the model has to hold and reconcile far more competing facts than a single-document Q&A task — this is where the larger MoEs, with vastly more total parameters to draw on, tend to pull ahead.
Long agentic chains with many tool calls and long-horizon planning, where accumulated context and compounding reasoning steps benefit from more raw capacity than a 24B dense model carries.
Tasks demanding frontier-tier nuance — subtle ambiguity resolution, adversarial prompts, highly technical domain reasoning at the edge of the model's training — where a dense mid-size model will do fine most of the time and quietly stumble at the margins.
None of that is a knock on the model — it's just the honest boundary of what "fits on one GPU" buys you. For the workloads it's built for — local coding help, document Q&A within a single context window, and drafting that can't leave the building — Mistral Small 3.2 24B does the job at a price and hardware footprint that a big MoE simply can't match, because the MoE was never trying to fit on your desk in the first place.
This is Day 3 of 30 — tomorrow we look at Unsloth AI and its desktop app, and what it actually takes to fine-tune a model like this one yourself.
The numbers (measured, not quoted)
I ran three quick probes against Mistral Small 3.2 24B via a hosted API today before writing this. Small sample, one snapshot in time, routed hardware I don't control — treat these as a smell test, not a benchmark:
| Probe | Wall-clock | Output tokens | Tokens/sec (effective) | Result |
|---|---|---|---|---|
| Code | 6.1s | 165 | 27 | completed |
| Reasoning | 14.2s | 353 | 24.8 | completed |
| Structured output | — | — | — | failed: OpenRouter chat 429: {"error":{"message":"Provider returned |
Effective tokens/sec includes queueing and time-to-first-token — it's what you actually experience, not peak decode speed.
Model card: context window 131,072 tokens · hosted pricing $0.075/M input · $0.2/M output · weights: mistralai/Mistral-Small-3.2-24B-Instruct-2506 on Hugging Face
Credits — where it's due
- Mistral AI — for training Mistral Small 3.2 24B and releasing the weights openly: mistralai/Mistral-Small-3.2-24B-Instruct-2506. Open releases like this are why a series like this can exist at all.
- OpenRouter — the hosted API used for today's live probes and the pricing/context figures.
- The quantizers and runtime maintainers — the mostly-unpaid people who turn every open release into something that runs on real hardware within days.
Top comments (0)