Ministral 3 is Mistral AI’s family of dense models for edge and local use. The December 2025 release includes 3B, 8B, and 14B sizes; Mistral says each size has base, instruct, and reasoning variants, image understanding, and an Apache 2.0 license. Current Mistral documentation lists a 256K-token context limit across the three sizes. Those are model-level facts: they do not establish that a particular converted artifact runs on a phone, fits its memory, or exposes vision through a given runtime.
The family in plain terms
Mistral 3 is the umbrella release announced by Mistral AI on December 2, 2025. Within it, Ministral 3 names the compact dense family, with 3B, 8B, and 14B parameter sizes. The same announcement separately describes Mistral Large 3 as a sparse mixture-of-experts model. This distinction helps disambiguate search results: “Ministral 3 3B” is the exact small-family name, while “Mistral 3” can refer to the wider release.
Mistral’s announcement says each Ministral size is offered as base, instruct, and reasoning variants. Those labels refer to different model behaviors or tuning, not three guaranteed modes in one downloaded file. Select the variant that matches the workload and record its exact model identifier. The official model cards currently use API names ministral-3b-2512, ministral-8b-2512, and ministral-14b-2512; identifiers exposed by a local repository or conversion can differ and should be recorded separately.
The official Mistral 3 announcement is useful for release-family intent and the available variants. The individual 3B, 8B, and 14B model cards are better references for each size’s current official label, license, context, and advertised inputs.
Verified specifications and their limits
| Model card | Parameters | Officially described capability | Context listed by Mistral | License |
|---|---|---|---|---|
| Ministral 3 3B | 3B | Text and vision; image understanding | 256K tokens | Apache 2.0 |
| Ministral 3 8B | 8B | Text and vision; image understanding | 256K tokens | Apache 2.0 |
| Ministral 3 14B | 14B | Text and vision; image understanding | 256K tokens | Apache 2.0 |
The context values are listed on Mistral’s live model cards and in its known limitations reference. Treat 256K as the documented model/API ceiling, not as a promise for every exported checkpoint. A local inference engine can impose a smaller context setting; the available memory and runtime implementation also affect whether a long request can complete. Input tokens include the prompt and conversation history, while generated output also consumes the context budget.
Mistral’s release page says the three sizes provide image understanding. That is evidence of family-level vision capability, but an app still needs a compatible multimodal artifact and runtime path. Verify image preprocessing, accepted image formats, and the actual input API for the exact file before building a product flow around it. Mistral’s cited model cards do not establish Ministral 3 audio input; capability lists from other Mistral families should not be transferred to this one.
The Apache 2.0 label is also specific to the named Ministral 3 model cards. Keep the exact checkpoint’s license and notices with redistributed packages, including converted or quantized derivatives. “Open weights” does not by itself identify the license of every third-party conversion, runtime, tokenizer, or accompanying software.
What “edge model” does and does not prove
Mistral describes Ministral 3 as designed for edge deployment and local setups. Its release page mentions optimized deployments on NVIDIA DGX Spark, RTX PCs and laptops, and Jetson devices. Those examples demonstrate vendor-supported directions in Mistral’s announcement; they do not form a phone compatibility list and do not show that an arbitrary Android build is supported.
The official public cards do not provide a universal quantized file size, minimum phone RAM, supported Android version, iPhone compatibility matrix, or guaranteed tokens-per-second figure. A 3B parameter count is not a download size. Quantization, tokenizer and vision components, packaging, and runtime buffers all affect the bytes and memory needed by a specific deployment. Avoid turning parameter count into an estimate that reads like a confirmed requirement.
Likewise, an API model card does not prove that the downloadable weights use the same serving interface or that a mobile engine supports the model architecture. “Available by API,” “weights available,” “runs locally,” and “works on a named phone” are separate claims that require separate evidence. For Android projects, our model memory guide and runtime comparison outline the variables to measure without assigning unverified device support.
A practical scenario: private image-to-note triage
Suppose a field team wants an offline assistant to inspect a user-selected equipment label, extract visible text, and draft a short note for human confirmation. Ministral 3’s documented text and image understanding makes the family relevant for evaluation. It does not mean the app already has OCR-grade accuracy, that all local builds support image inputs, or that the output is safe to accept automatically. Keep image capture, model inference, and final user approval as separate parts of the design.
Before collecting real images, use synthetic or public test images and write the expected fields: asset identifier, warning text, and a short uncertainty statement. Include blur, glare, rotated labels, and cases where the image contains no relevant text. The evaluation should reward “cannot read” when appropriate rather than encouraging a confident guess. Do not upload private images to an external evaluator unless a separate privacy review permits it.
Reproducible selection and test steps
- Choose a family member and task. Start with 3B, 8B, or 14B and specify whether the candidate is base, instruct, or reasoning. Write the one task it must perform, such as extracting three named fields from a label. Do not assume the largest size is automatically best for the intended device.
- Pin the artifact. Record the source repository, immutable revision, exact filename, digest if supplied, quantization, tokenizer/template, license file, and any conversion steps. Preserve the source model identifier and the local runtime identifier as separate fields.
- Confirm the runtime path. Document the engine and version, operating system, device, backend requested, and backend actually initialized. Confirm whether the artifact and vision path are supported. A runtime’s generic image capability is not proof that it supports this architecture.
- Freeze a privacy-safe fixture set. Use labeled images with expected output and fixed prompts. Include normal, difficult, irrelevant, and unreadable images. Score required fields, hallucinated fields, uncertainty handling, and formatting using the same rubric for every candidate.
- Measure the complete run. Record download or installation separately from model load and inference. Capture process memory, first response and repeated response timing, errors, cancellation, and thermal state under a documented procedure. Avoid publishing one device run as a general model benchmark.
- Test local and offline behavior. After installation, disable networking and repeat the same task. Check whether the app fails clearly and whether any unexpected remote request occurs when connectivity returns. Local model inference alone does not prove the full application is offline.
- Make a narrow decision. Compare the results to thresholds set before testing. State the exact artifact, runtime, device, OS, inputs, and observed limits. If a key measurement is missing, record it as unknown rather than turning it into a pass.
Acceptance criteria to agree on first
- Field fidelity: every required label field matches the reviewed reference; invented identifiers count as failures, and the scoring rubric defines how unreadable examples are handled.
- Runtime integrity: the pinned artifact loads repeatedly on the named configuration, the actual backend is logged, and failures, cancellations, and malformed outputs are included in the results.
- Resource and privacy boundary: memory and timing are measured at stated boundaries, and the offline test completes without a hidden remote-inference dependency.
Choose numerical thresholds with the product team and the target task; there is no universal acceptance number supplied by the model card. Keep the fixture, rubric, and raw run manifest so another reviewer can repeat the test.
Choosing among the three sizes
The table below is a shortlist framework, not a performance ranking. Mistral publishes parameter counts and model descriptions, but those alone cannot predict quality or speed for your task.
| Candidate | A reasonable first question | Evidence still needed |
|---|---|---|
| Ministral 3 3B | Can the smallest family member meet the task rubric? | Exact artifact, memory, output quality, latency, and vision support in the selected runtime. |
| Ministral 3 8B | Does a larger parameter count fix measured quality gaps? | Same fixed task and device procedure; do not infer its memory cost from “8B” alone. |
| Ministral 3 14B | Does the larger candidate justify its deployment burden for this task? | Artifact availability, peak memory, runtime support, sustained behavior, and quality evidence. |
If all three miss a task-critical requirement, changing family may be more useful than tuning the comparison around a favored model. For broader choices, see our Qwen model overview and model leaderboard, while checking each candidate’s first-party model card. Our guides to model memory requirements and Android runtime choices explain other deployment variables.
Frequently asked questions
Is Ministral 3B the same thing as Mistral Small 3?
No. Ministral 3B is the smallest size in the Ministral 3 family. Mistral’s December 2025 announcement lists 3B, 8B, and 14B Ministral models, while its wider Mistral 3 release also includes Mistral Large 3. Names that contain “Mistral” are not interchangeable; use the full model-card name and version when documenting a deployment.
Does 256K context mean a phone can process 256K tokens?
No. It is the context ceiling documented by Mistral for the model/API. A local conversion, runtime configuration, device memory, and output budget may all make the usable window smaller. Test the exact local setup and measure whether the full request is accepted and completed without truncation or termination.
Is Ministral 3 a text-only model?
No. Mistral describes the family as having image understanding, and its model cards identify text and vision. That does not prove image input is available in every quantized artifact or local runtime. Confirm the model-specific vision path and test it with the exact packaging you intend to distribute.
Can I use Ministral 3 commercially under Apache 2.0?
The official 3B, 8B, and 14B model cards display Apache 2.0. For an actual product, retain the license and notices supplied with the precise checkpoint and review the terms of any conversion, runtime, or dependency as well. This overview cannot replace legal review.
Does Mistral publish an Android device list or minimum RAM?
The cited official pages do not publish a general Android compatibility matrix, minimum phone RAM, or universal quantized package size for Ministral 3. They describe the family as intended for edge/local use and mention selected NVIDIA deployment targets. An Android compatibility claim needs its own artifact, runtime, and device test evidence.
Editorial status: this page was refreshed against Mistral AI’s first-party announcement and live model documentation on 2026-09-26. It makes no claim that Cove ships or benchmarks Ministral. The Chinese edition is prepared for the site owner’s native-language review; that review is pending.