Mistral Large 3: December 2025 Open-Weight MoE, Not Large 4 Preview. This reference distinguishes the original release from hosted endpoints, downloadable weights and subsequent version changes. It is written for people deciding whether an exact model or checkpoint is suitable for a real application, not for leaderboard marketing.
What the sources actually establish
Mistral introduced Large 3 on December 2, 2025 as part of the broader Mistral 3 open-model generation. It describes a sparse mixture-of-experts model with 675 billion total and 41 billion active parameters, released under Apache 2.0 alongside smaller Ministral 3 models. Large 3 is a separately versioned open-weight release, not a static synonym for the subsequent October 2026 Large 4 public preview.
A useful application and evaluation scenario
For a self-hosted enterprise RAG application, assess whether the data sensitivity warrants running an open checkpoint rather than transmitting requests to a remote endpoint. If so, design GPU capacity around total weights, cache and concurrency, not only the 41B active path. Pin the exact artifact hash and tokenizer and compare document-grounded answers across at least two languages and one long file.
Limits, risks and uncertainties
The Large 3 documentation lists a 256K context for the managed model and supports structured output and tool calling at documented routes. In practice, a local backend may implement those affordances differently. No tool or license claim should be transported to the later Large 4 preview without fresh evidence. Supplier benchmark comparisons remain supplier evidence.
Alternatives and the decision rule
Choose the Apache-2.0 Large 3 weights when there is a proven need for customization and a suitable serving budget. Compare smaller Mistral 3 variants when the workload favors latency and simplicity. If a pilot uses Large 4 preview, keep that project as a separate model/version track and do not overwrite Large 3’s identifier.
A reproducible test before adoption
Prepare a small held-out set from data the organization is authorized to process. Include simple, ambiguous and deliberately unanswerable requests; specify the expected answer or evidence and a human-reviewed scoring rule. Record model identifier, endpoint and region, tokenizer or SDK version, prompt, tool settings, output budget and whether external retrieval was allowed. Do not present a provider-supplied benchmark as an independently measured result. Separate model mistakes from retrieval, OCR and application validation failures.
Operational checklist and dated evidence
A production transition must test 429 responses, timeouts, refusals, invalid structured output and model-unavailable errors. Keep a reversible rollout or safe fallback instead of silently substituting a model behind an old identifier. Measure latency and usage on the actual workload before planning budgets; join dated token quantities to the AI 10 price ledger. Verify enterprise residency, region, support entitlement and data retention with the actual contract, not a public release story.
Sources & Further Reading
- mistral.ai — documentation/reference (supplier-provided reference; not independently checked in this pass)
- docs.mistral.ai — documentation/reference (supplier-provided reference; not independently checked in this pass)
Source documentation establishes vendor-published facts, not independently measured model quality, tenant access, contractual rights or current prices. Use a dated pricing ledger and an account-specific entitlement check for deployment decisions.