Mistral Large 4 weights are out. Check the license before hosting.
Mistral Large 4's modified MIT license, MaaS exceptions and GPU recipes explain what to check before moving from API access to self-hosting.
Mistral released the improved weights of Mistral Large 4 on October 29, following its earlier public preview. That makes self-hosting an option, but its modified MIT license sets conditions for commercial use by businesses operating Model as a Service, including affiliates, with explicit exceptions. There is a separate engineering check: the A52B name describes active parameters, not the memory needed to hold the model’s weights.
For a team deciding whether to move beyond a hosted API, those distinctions matter more than another leaderboard. Download access, permission to use the model in a particular business, and a deployment that fits the workload are three different questions.
October 29 released weights, not the first Large 4 preview
The Mistral Large 4 open-weight announcement distinguishes two events. Large 4 entered public preview earlier in October. On October 29, Mistral released the weights of an improved version, after further training and feedback from the preview.
The practical change is control over where the model runs and how it is adapted. An organization can consider deploying the weights on its own infrastructure rather than depending on Mistral to serve every request. That opens a different engineering path; it does not establish that the path is cheaper or suitable for every organization.
Consider a team evaluating an internal assistant and a customer-facing model endpoint. Both projects might start with the same checkpoint. They can still face different licensing questions, infrastructure requirements and operating costs. “The weights are available” is the beginning of that evaluation, not its conclusion.
The Large 4 license looks at the licensee and its affiliates
The Mistral Ecosystem Open-Weight License calls itself a modified version of MIT. The modification is consequential. Calling this standard MIT would leave out the very condition that a hosting business needs to read.
The opening grant permits broad activities, including use, copying, modification, distribution, deployment and further training, subject to the conditions that follow. “Licensee” means the person obtaining a copy; “Model” includes the weights, parameters, configuration files and associated documentation. Section 1 requires the copyright and permission notices in all copies or substantial portions of the Model.
Section 2 then states:
If the Licensee or any of its affiliates operates a Model as a Service business, the Licensee must enter into a separate commercial license with Mistral before using the Model or its derivative works for any commercial purpose.
Two details deserve attention. The condition includes affiliates, not just the team downloading the checkpoint. And it refers to any commercial purpose once that business condition applies—not merely revenue from selling access to a Large 4 endpoint.
It is therefore unsafe to compress the clause into “you only need another license if you resell Large 4 as an API.” The text asks about the licensee and its affiliates’ business activity as well as the proposed use of these weights.
Section 3 provides important exceptions to Section 2. It exempts internal use of the Model or derivatives, defined as use that does not make them available to third parties. It also exempts any use of the Model accessed through Mistral’s official products. These are explicit exceptions, not reasons to ignore Section 2; a private network address alone does not establish the internal-use definition, and an arbitrary third-party service is not automatically an official Mistral product.
This is a reading guide to the published text, not legal advice or a determination about a particular product. Where affiliate relationships or third-party access make the classification unclear, take the proposed arrangement to Mistral and legal counsel before committing to it.
Embedded features, MaaS and mere relay are different categories
The license defines Model as a Service as giving a third party access to the Model or derivatives for inference or post-training, by any means, in a way that gives that third party meaningful control over inputs, parameters or training data. APIs and hosted endpoints are examples, not the only possible delivery mechanisms.
That definition also contains two exclusions:
- End-user products whose model capabilities are solely embedded within specific features or harnesses.
- Mere relaying of requests to models hosted by others.
Those distinctions make the shape of a product relevant. For a hypothetical document application, the question is whether the model is solely embedded in specific end-user features. For a hypothetical inference service, it is whether third parties receive the access and meaningful control described in the definition. For a relay, it is who actually hosts the model and whether the activity is merely relaying requests.
Naming something an “agent,” a “feature” or a “gateway” does not answer those questions. The actual access and control matter. Nor does an exclusion from the MaaS definition grant permission to use an upstream hosted service on whatever terms a relay chooses.
Most importantly, these exclusions must be read alongside the licensee-and-affiliates condition. A proposed feature may fall outside the MaaS definition while the organization or an affiliate operates a MaaS business elsewhere. The exclusion alone does not settle that organization’s commercial use of the weights; Section 2 and the Section 3 exceptions still need to be considered together.
Before choosing a hosting architecture, check three things separately: the relevant legal entities and their businesses, the access your product gives third parties, and any explicit exception for the proposed use. Write down who obtains the weights, which affiliates operate relevant services, and what outside users can control. That is a more useful starting point than classifying the whole project from its marketing label.
A52B describes active parameters, not the full weights
The Mistral Large 4 model card describes approximately one trillion total parameters, with 49 billion active per token, or 52 billion including embeddings and output layers. These numbers describe different properties of the same model.
Large 4 is a mixture-of-experts model. Its routed expert structure selects four of 128 experts per token, alongside a shared expert. Sparse activation reduces the portion of the expert pool used for an individual token. It does not turn the checkpoint into a dense 52-billion-parameter model or mean the remaining experts can simply be omitted from deployment planning.
For capacity planning, distinguish the weights from the working memory needed to serve requests. Weight precision and placement matter. So do the KV cache—the attention state retained while generating text—context length and the number of requests served concurrently. The model card itself recommends reducing maximum context length or concurrency when GPU memory is insufficient.
That is why multiplying the active parameter count by a chosen number of bytes is not a reliable weight-memory budget. Start with the actual checkpoint and serving configuration. Treat A52B as an architectural description, not a shopping list for GPUs.
The published GPU recipes answer different deployment questions
The deployment ecosystem already offers concrete starting points. They should be read as configurations with conditions, not interchangeable claims about a universal minimum.
The vLLM day-0 support article — Usage provides separate FP8 and NVFP4 launch configurations. These names refer to different numerical formats, not GPU counts. Tensor parallelism divides model computation across GPUs; its size is one part of the serving configuration. The Hugging Face release guide — Inference Endpoints describes a managed endpoint recipe with a specific hardware and serving envelope.
| Published example | Checkpoint and hardware | What the example establishes |
|---|---|---|
| vLLM FP8 quick start | FP8 checkpoint; eight GPUs, tensor parallel size 8 | A published starting configuration, not a minimum-memory finding |
| vLLM NVFP4 quick start | NVFP4 checkpoint; four Blackwell GPUs, tensor parallel size 4 | A different precision and hardware path; not a promise for any four GPUs |
| Hugging Face Inference Endpoints | FP8 weights on eight NVIDIA H200 GPUs | A recipe configured for up to 131K context and up to 16 simultaneous requests |
There is no contradiction between the model card’s 1M-token context specification and an endpoint recipe configured for 131K. One describes the model’s supported context window; the other describes a particular serving configuration. Neither number, on its own, promises that every deployment will serve that context at a desired concurrency or latency.
The HF guide also has a separate NVFP4 launch example. Do not combine that command’s flags with the H200 endpoint description and treat the result as one validated configuration. Check the checkpoint, precision, GPU generation and serving settings together.
For an evaluation, record the hardware topology, exact weights and software versions, context limit, concurrency and workload before comparing results. Pin the versions used in the trial. This article’s model-card and license references are pinned to repository revision f12dabdc0c1e99e7f7924461a6f308859b05af4d, checked on October 30 against the initially retrieved documents.
The recipes above have not been run by this publication. They establish useful starting points, not an independently verified minimum VRAM requirement, throughput result or service-level guarantee. A smaller GPU count is only meaningful alongside the GPU model, memory capacity and workload it serves.
Use API prices as a reference, not a self-hosting verdict
Mistral’s October 29 announcement lists the following API prices in US dollars per million tokens:
| Token category | Listed price |
|---|---|
| Input | $0.70 |
| Cached input | $0.07 |
| Output | $2.10 |
These are current published rates, not a calculation of a price cut against an independently checked earlier schedule. The cached-input line is a separate rate category, not a promise that every input token in a workload will qualify for it.
A hosted API bill and a self-hosted deployment also measure costs differently. The former starts with token categories and usage. The latter requires accounting for the selected hardware, utilization, idle capacity and operating work, as well as any applicable commercial licensing arrangement. A GPU recipe alone cannot establish the break-even point between them.
For a team that has not established its workload, a hosted evaluation can separate “does this model do the job?” from “should this organization operate it?” A self-hosted evaluation becomes more informative once control requirements, traffic and the intended use are concrete enough to test.
The weights release makes that choice real. The next step is to document the licensee, affiliates, third-party access and applicable exceptions, then test a complete deployment configuration against the intended workload. Neither the word “open” nor the A52B label can make those decisions for the team.