Can I fine-tune Mistral Large?

Yes — Mistral supports fine-tuning across the family on La Plateforme. Small is the more common tuning target because per-token economics stay favorable after tuning; tune Large only if a real reasoning gap survives extensive prompt work.

Do Large and Small share the same tool-calling schema?

Yes. The function-calling surface is identical, so you can swap models without touching your tool definitions or the parsing code that consumes tool_calls.

Is Mistral Small good enough for RAG?

For most RAG apps, yes — once retrieval quality is good, Small handles the synthesis step well at a fraction of the cost. Escalate to Large only when the retrieval passages disagree or the question genuinely requires multi-hop reasoning.

How much cheaper is Small vs Large?

The ratio has held between 5× and 10× per million output tokens since 2024. Check console.mistral.ai for the current rates on your tier.

Which model should I default to?

Default to Mistral Small. Add a cheap Small-based classifier that escalates hard turns to Mistral Large. This is the cheapest architecture that preserves flagship quality where it actually matters.

Do rate limits differ between Large and Small?

Yes. Per-key TPM and RPM ceilings are almost always higher on Small because its serving cost is lower. Check the exact numbers for your billing tier in console.mistral.ai — and if you are running an escalation architecture, size your Large quota against your projected escalation rate rather than total traffic.

When should I not escalate to Large?

When your eval shows Small ties or wins on a class of turns, or when the marginal quality gain does not change downstream behavior — for example, a summarization step whose output is only ever read by another model that would smooth the differences anyway. Escalation adds latency and cost; skip it whenever your grading process cannot tell the two apart.

Can I run Large and Small in an A/B test?

Yes, and you should. Split live traffic 90/10 or run a shadow-mode where every Small response is silently regenerated with Large and stored for later diffing. Grade a stratified sample by hand across two weeks, then move the routing threshold based on the actual quality-cost curve you observed rather than intuition.

Mistral Large vs Small: which model to pick in 2026

Mistral Large vs Small — the short answer

Mistral Large is the frontier tier — best reasoning, best long-context recall, best multilingual performance, and the highest price per million tokens. Mistral Small is 5–10× cheaper, decodes significantly faster, and is good enough for classification, extraction, routing, and most user-facing chat where a strong system prompt does the heavy lifting. Pick Large when the task is genuinely hard; pick Small everywhere else and escalate on demand.

Quality gap

On multi-step reasoning, long-context recall past 32k tokens, and non-trivial code generation, Mistral Large opens a real gap. On single-shot extraction, summarization, and structured JSON output at temperature 0 with a tight schema, Mistral Small is often indistinguishable from Large. If your evals show Small ties or wins on a class of turns, ship Small for that class.

Latency and time-to-first-token

Small decodes noticeably faster and hits first token sooner on the same hardware. For interactive UIs — chat, autocomplete, live copilots — TTFT dominates perceived speed more than depth of reasoning. Default to Small for the interactive surface, and reserve Large for background jobs, agent inner loops, and turns where confidence in Small's output is low.

Price: input, output, and the real bill

La Plateforme prices per million tokens, quoted separately for input and output. Output is more expensive because it is generated one token at a time. Check console.mistral.ai for current rates; the ratio between Mistral Large and Mistral Small has held roughly 5–10× since 2024. At scale, cost dominates — measure both models on your actual traffic before committing to a default.

How to pick in production: the small-first, escalate pattern

Route every incoming turn through a cheap Mistral Small classifier that decides whether the turn needs the flagship. If the classifier says 'easy', let Small answer. If it says 'complex', escalate to Mistral Large. This one pattern is how production LLM systems keep bills sane while preserving quality where it matters. Store both outputs during a bake-in period and grade a sample by hand — you'll usually find the escalation threshold sits higher than intuition suggests.

Fine-tuning: which one to tune

Mistral supports fine-tuning across the family on La Plateforme. Small is the more common target because per-token economics stay favorable after tuning and the base model is small enough to converge cheaply. Fine-tune Large only when a domain-specific reasoning gap survives extensive prompt-engineering — the training cost premium is real.

Context window and cache economics

Both models expose long context windows in the 32k+ range. Long prompts are cheap on the input side but every extra token is billed, so aggressive retrieval-context truncation (top-k = 5 or less) is one of the highest-leverage cost levers you can pull. Cache your system prompt server-side if your provider supports prompt caching for the tier.

Compare vs other providers

Mistral Large plays in the same tier as GPT-4-class and Claude Sonnet-class models on standard benchmarks. Small plays in the GPT-4o-mini / Claude Haiku tier. If you're already using OpenAI or Anthropic, swap the base URL to https://api.mistral.ai/v1 and rerun your own evals — the OpenAI-compatible surface means the switch takes minutes, not weeks.

Benchmark caveats you should not skip

Public leaderboards move fast and rarely reflect your workload. Contamination in eval sets is common, and single-number rankings hide the axes you actually care about — instruction-following on your prompt style, tool-call reliability on your schemas, refusal behavior on your edge cases. Treat MMLU or GSM8K numbers as a filter to shortlist candidates, not as a verdict. The verdict comes from replaying 200–1000 real production turns against Mistral Large and Small side-by-side and grading the diffs. That week of eval work is the highest-ROI engineering time you'll spend on model selection all year.

Multilingual and non-English performance

Mistral was built by a Paris-based team and non-English quality shows it. French, German, Spanish, and Italian are first-class citizens on both Large and Small, and the gap between Mistral and English-centric US providers widens noticeably on those languages. If your product ships in EU languages, this is a real reason to default to Mistral even before you look at pricing or data residency. Test your own multilingual prompts with domain vocabulary — legal, medical, or industry jargon — because generic benchmarks over-index on newswire text and understate specialist quality.

Availability, quotas, and rate limits per tier

La Plateforme enforces per-key TPM and RPM limits that scale with your billing tier. Small typically ships with higher per-minute ceilings than Large simply because its serving cost is lower. If you plan to run a Small-first, escalate-to-Large architecture, size your Large quota for the escalation rate, not for total traffic — a 5% escalation rate on 200 QPS is only 10 Large QPS. Request a quota bump in console.mistral.ai before launch rather than after your first 429 storm.

Latency and cost tradeoffs, quantified

The intuition 'Large is slow and expensive, Small is fast and cheap' is directionally right but hides the number you actually need to design against. On a typical 500-input, 250-output chat turn in an EU region, Mistral Small usually returns first token in 150–250ms and completes in under 1.5s; Mistral Large lands closer to 350–600ms TTFT and 2.5–4s total. Cost-wise, at published rates that same turn costs roughly 5–10× more on Large than on Small once you sum input and output. Multiply by your daily request volume and the annual delta is often a full engineering headcount. That is why the escalation pattern pays for itself the first month it ships: you keep flagship quality on the turns that need it and pocket the difference on the 80–95% that do not.

A decision flowchart for picking the model

Ask four questions in order. One: does the turn require multi-step reasoning, non-trivial code generation, or long-context recall past 32k tokens? If yes, Large. Two: is the turn user-facing chat where TTFT under 300ms matters more than depth? If yes, Small — and consider streaming to hide the rest of the latency. Three: is the turn a background job (nightly summaries, evals, embeddings refresh)? Batch it on Small and eat the 24h SLA. Four: is the turn a classification or routing decision that gates escalation? Always Small — this is the classifier tier. Any turn that does not clearly answer 'yes' to question one should default to Small; escalation is cheaper than starting on Large and trying to prove Small would have sufficed.