Mistral Large 4 was released on October 6, 2026, in public preview via API. The company says the weights will be released by the end of October. That is why cloud evaluation of the model and the decision to deploy it on-premises should be handled separately right now: the first relies on the available service, while the second requires a published model package and usage terms. This follows from the Mistral announcement.
This analysis is intended for IT leaders, owners of enterprise AI systems, and automation teams. We review the release status as of October 8, the discrepancy in specifications across official sources, and criteria for the next step. We did not conduct our own tests of Large 4; this piece does not include measurements of Russian language quality, speed, costs, or instructions for deploying an unverified local package.
Prepared by the AIrassvet editorial team using public sources. Verification date: October 8, 2026. Release terms should be reviewed again after the weights are published or the model status changes; report an error through the contact information on the site.
Contents
- What Mistral actually released
- Why specifications need a date
- How preview affects integration stability
- What evidence is needed for a local launch
- What to check in corporate data processing
- How to evaluate the model on your own task
- Example decision for a procurement team
- Answers to common questions
- How AIrassvet helps prepare implementation
- Conclusion
What Mistral actually released
Public Preview is a public pre-release version of a model that may still change before a stable launch. Mistral Large 4, also called ML4 or Le Chonk, is presented as a multimodal model: it is designed to work with different types of input data. In the announcement, the company highlights programming, agentic tasks, and image understanding. This is the vendor’s description, not the result of editorial testing. Source: model announcement.
In the current Large 4 model card , Public Preview, version v26.10, and support for structured outputs, function calling, and Document QnA are listed. Structured outputs means output in a specified structure, while function calling means generating a tool call. The presence of these features is useful for integration design, but it does not yet confirm the correctness of a specific call or field value.
Open weights are parameter files that let you run the model outside the developer’s service, subject to the license. The open-weight label in the announcement describes the direction of the release; the promise to publish the files later does not prove that local deployment is available today. The practical decision is still two-stage: acceptable cloud evaluation first, then separate acceptance of the local package once it becomes available.
Why specifications need a date
There is a discrepancy in the official sources. The October 6 announcement states 1T total and 49B active parameters; the documentation verified on October 8 states 1.05T total and 52B active. The card also lists a 1M-token context window. The announcement and the versioned documentationwere compared; the reason for the difference in these sources has not been established.
| Verification item | October 6 announcement | Card verified on October 8 | How to use the information |
|---|---|---|---|
| Total parameters | 1T | 1.05T | Keep both records with sources |
| Active parameters | 49B | 52B | Request clarification for the selected version |
| Status | Public preview | Public Preview, v26.10 | Agree separately on update risk |
| Weights | Promised by the end of the month | The open-weight name by itself does not confirm download availability | Check artifacts before local procurement |
MoE, or mixture of experts, is an architecture with multiple groups of parameters, of which only part is activated to process a token. The active count is not equal to the full model size and by itself does not determine the required memory. So sizing a server based only on the 49B or 52B figure would be insufficient: you also need the weight format, runtime configuration, request length, and concurrent load.
The table is an editorial comparison of documents, not our model test. For a technical specification, it is more useful to attach a dated card and a list of unresolved questions than to choose the most convenient figure from the headline. The hardware requirements in this analysis remain unknown until a specific package is verified.
How preview affects integration stability
Mistral lifecycle policy allows silent updates in Public Preview: the provider may change the model without separately changing its public designation. A move to General Availability is not guaranteed; the preview status includes a one-month notice period for end of support. For GA, the documentation describes a stable model without silent updates and a six-month deprecation notice.
The policy has another layer: model aliases can point to new versions. A specific identifier reduces version-selection uncertainty, but preview status still allows behavior changes. That means recording a single model ID in configuration does not replace a repeat quality check after a service update.
The editorial recommendation is to save the run date, model identifier, prompt settings, and reference responses. If the same task starts producing a different format, an incorrect citation, or a disallowed call, the team should have a way to detect it and revert to the previous path. A critical process needs an owner for disabling the integration and an available fallback procedure.
What evidence is needed for a local launch
Before investing in infrastructure, it is worth separating four questions: can you get the files, can you use them for the intended purpose, can you run them on the target configuration, and can the entire service handle production load. An answer to one question does not close the others. This sequence is the editorial verification order, which we have not validated on Large 4.
- Model package. Check the official download source, file versions, their integrity, and alignment with the stated release.
- Usage terms. Read the license for these exact weights: whether commercial use, modification, and redistribution are allowed. Do not apply the terms of another model in the family.
- Execution. Find a supported runtime engine, multimodal input settings, formats, and limitations. Document dependencies that require an external network.
- Operations. Check memory, queuing, response time, and recovery on your own hardware and sample documents.
In the official materials reviewed, a complete ready-to-run package for self-hosting Large 4 with final terms has not been established. The announcement includes a promise of future weights release; there is no basis for replacing that with a claim that a local product is available today. Source of the promise: Mistral.
For budget comparisons, use a separate analysis of cloud vs. local LLM TCO. TCO — total cost of ownership, including service and team maintenance costs. A preview check provides information about the cloud configuration; its speed and cost cannot be automatically transferred to another infrastructure.
What to Check in Corporate Data Processing
In a cloud pilot, it is useful to map the data flow: the application, the selected endpoint, files, history, logs, tools, and the recipient systems for the output. The difference between a single request and a service that retains state is especially important. Permissions and settings should match the route actually used, not the model’s general name.
In Mistral’s documentation on zero data retention ZDR is described for supported stateless APIs on paid plans. Stateless means the endpoint does not need to preserve user state after the request is completed. Agents, Conversations, Libraries, Files, and batch processing files are excluded; ZDR and opting out of data use for training are different settings. A ZDR request is reviewed by the provider and may be rejected.
This leads to a specific pilot question: where does a document go if the application uses both chat and a file service at the same time? An enabled setting for a supported request does not confirm deletion of the file in another product. Before transferring corporate materials, you need to check the organization’s terms, access rights, and selected endpoints; the availability of the service for a specific Russian company was not verified in this study.
In the local setup, a map is also necessary: telemetry, logs, and connected tools can extend beyond the server boundary. Model placement is only one part of it. The article suggests technical questions for verification and does not confirm the legal compliance of the selected architecture.
How to Evaluate a Model on Your Own Task
Large context and a set of functions define the test’s capabilities, but not its success criteria. For document workflows, it is more useful to define in advance what answer an employee can accept and verify: exact fields, the source in the document, and a proper refusal when information is missing. The quality threshold should be approved by the process owner based on the consequences of errors.
Suggested pilot workflow:
- Choose one process and the current solution to compare against.
- Prepare an approved set of normal, ambiguous, and intentionally incomplete tasks; separate it from prompt setup examples.
- Record the model, endpoint, parameters, date, and evaluation rules.
- Check the response content, structure, and tool-call permissions separately.
- Save accepted and rejected results together with the reasons for the decision.
Mistral has an evaluation SDK: a run links the dataset, executable task, and evaluators; separate runs make it possible to compare results over time. This is a description of the tool, which we did not use in this article. An organization can choose its own way of recording results while keeping the same verifiability.
Response time should be measured to a result that is usable for work, including queues, calls, and corrections. Costs should be tracked together with repeat requests and manual review. If the new model is better only on rare complex tasks, it may make sense to use a separate path for those cases; any conclusion about a broad replacement requires your own results.
Example Solution for a Procurement Team
Imagine a fictional company where an employee checks part numbers and specifications against a description and a drawing. A multimodal model could prepare a draft table with links to document excerpts. Ordering and changing the reference catalog would remain the employee’s responsibility. This example does not describe an AIrassvet client or a completed project.
Different solutions are possible for the team. If a cloud route for anonymized samples is allowed, you can check extraction quality through preview. If work without external transfer is required, you first need a confirmed local package. If the task context changes because of a silent model update, the control set should be repeated before continuing the pilot.
An error in a unit of measurement and a missing part number can have different consequences, so the overall share of correct answers hides important differences. It is more useful to track error types separately, their detectability, and the time needed for human review. Such a results table would help with the decision, but the editorial team does not have actual Large 4 data for it.
Answers to Common Questions
Can Mistral Large 4 already be deployed locally?
As of October 8, 2026, a public API preview is confirmed; the announcement promises weights by the end of the month. A ready-to-deploy self-hosted package verified in this analysis is not available. A decision to run it locally requires actually published files, terms of use, and execution verification.
How many parameters does Mistral Large 4 have?
The announcement lists 1 trillion total and 49 billion active parameters, while the verified documentation says 1.05 trillion and 52 billion. The reason for the discrepancy has not been established. For a technical specification, you should keep the source and date of the numbers, then clarify the configuration of the selected release.
Does a specific model ID guarantee that the preview will not change?
No. Mistral’s policy allows silent updates to Public Preview. A specific identifier helps control version selection, but it does not change the preview status. Saved control tasks, repeat checks, and a rollback plan are needed.
Can the result of an API pilot be transferred to a local model?
It is useful for an initial task assessment, but it does not prove the quality and speed of the future local service. After the weights are released, you need to separately check the version, format, engine, hardware, settings, and load. The results from both configurations should be stored separately.
How AIrassvet Helps Prepare for Implementation
This section describes the publisher’s services. AIrassvet can connect evaluation of a new LLM with a specific business process: conduct a task audit and data preparation, develop integration with a corporate system, and organize testing against agreed criteria. These directions correspond to services on the website; no special ready-made integration specifically with Large 4 is being claimed here.
The first step is to choose one process and describe the current result, data sources, constraints, and acceptance condition. Then it will become clear whether a cloud experiment is needed now or whether it is better to wait for a verifiable local release. Discuss the Task.
Conclusion
Mistral Large 4 gives a reason to evaluate a new model through the public preview if the selected cloud route is acceptable for the task. For a decision about local deployment, more evidence is still needed: released artifacts, terms of use, and your own operational results. The parameter discrepancies and the possibility of silent updates should be documented in the project materials.
The practical next step is to define one verifiable process and the criterion for an accepted result. After the weights or a stable release appear, repeat the evaluation on the appropriate configuration. This way, the implementation decision will rely on an available product and observable results, not on the promise of a future release.