Open weights gives an organisation something a hosted API does not: the ability to obtain model parameters and run them under its own infrastructure and policy. It does not provide the original training data, a complete training recipe, a managed serving layer, hardware capacity, monitoring or a legal right broader than the model’s actual licence.
Mistral’s current portfolio makes the distinction concrete. Most of its open models use Apache 2.0, while some use a modified MIT licence that requires companies above US$20 million in monthly revenue to obtain a commercial licence or use Mistral Studio. The word “open” therefore does not identify one uniform permission set.[1]
What open weights gives—and what it does not
| Layer | Usually available | Still required from the deployer or provider |
|---|---|---|
| Model parameters | Downloadable weights under the model card’s licence | Storage, conversion, quantisation and integrity checksSource 1 |
| Inference code | Reference or community serving integrations may be available | A production server, scaling, security patches and observabilitySource 2 |
| Training information | Architecture and selected methodology may be published | The full dataset, data rights, filtering pipeline and reproducible training run |
| Safety behaviour | The released checkpoint contains its post-training state | Deployment policy, moderation, monitoring and incident handling |
| Commercial rights | Defined by the specific licence | Compliance with revenue thresholds, attribution and model-card termsSource 1 |
The weights may not exist on launch day
Mistral opened the Mistral Large 4 API preview on 6 October and said the weights would arrive at the end of the month. As of the source check for this article, the release is therefore an open-weight commitment and hosted preview rather than a downloadable deployment artifact. Mistral also says architecture, benchmark and post-training details will be expanded with the weight release.[3]
As checked on 14 October, both the launch announcement and model documentation state 52 billion active parameters. The documentation gives 1.05 trillion total parameters. Active parameters describe the portion used in computation; they do not replace the full weight-storage requirement when planning a deployment.[3][4]
Local deployment is a hardware and software project
Mistral’s offline guidance recommends an H100 or A100 for FP8 inference around a 128,000-token context for Devstral Small 2. A 24 GB RTX 4090-class GPU can use four-bit precision at a shorter 32,000-token context. CPU offload can work with enough RAM but is described as significantly slower. Mistral Small 4 requires at least one H100 80 GB at FP8, with more memory for long context.[2]
These figures are not universal model requirements. They are examples showing how precision and context length trade against memory and speed. The same weights can produce very different throughput, latency and tool behaviour under vLLM, llama.cpp, Ollama or another stack. “Runs locally” can mean an interactive single-user test or a reliable multi-user service; those are different achievements.
Published offline deployment examples
| Measure | Value | Context |
|---|---|---|
| Devstral Small 2 | 24B dense | Mistral describes it as the lighter local coding and agentic option.Source 2 |
| H100 or A100 example | FP8 with around 128k context | Recommended for decent long-context performance on Devstral Small 2.Source 2 |
| 24 GB GPU example | Four-bit with around 32k context | Lower precision and shorter context reduce the footprint.Source 2 |
| CPU offload | Works with enough RAM | Mistral warns that it is significantly slower.Source 2 |
| Mistral Small 4 | At least one H100 80 GB at FP8 | More memory is needed for longer contexts.Source 2 |
| Serving layer | vLLM recommended for the documented CLI route | Parser, tool-choice and model-length flags remain part of configuration.Source 2 |
Control creates responsibilities as well as freedom
Self-deployment can keep prompts inside a chosen environment and reduce dependence on a hosted endpoint. It also transfers model loading, capacity planning, patching, abuse controls, data logging, access management and service continuity to the operator. A hosted provider may handle those layers badly or well; an open checkpoint simply makes them the deployer’s problem.
Procurement should therefore separate three decisions: whether the licence permits the intended use, whether the checkpoint performs acceptably on real tasks and whether the organisation can operate the required serving stack. A positive answer to only one of those questions is not a deployment plan.
Mistral’s open-model strategy offers genuine autonomy and a meaningful alternative to provider-only access. Its limitation is not a defect in the weights. It is the distance between possessing a checkpoint and operating a dependable product. The strongest evaluation measures that full distance instead of treating downloadability as completion.
Sources & further reading
- Under which license are Mistral’s open models available? Mistral Help Center · 12 Aug 2026 · Accessed 10 Oct 2026
- Using offline models Mistral Docs · Accessed 10 Oct 2026
- Introducing Mistral Large 4 Mistral · 6 Oct 2026 · Accessed 10 Oct 2026
- Mistral Large 4 model documentation Mistral Docs · 6 Oct 2026 · Accessed 10 Oct 2026