Mistral AI models 2026: VRAM and hardware guide

Mistral AI has reorganized the 2026 model family: Edge models with Ministral 3, a 24B workstation class with Small 3.2 and Devstral Small 2, the memory-hungry MoE model Small 4, and server and API models with Devstral 2 and Medium 3.5.

Ministral 8B, Ministral 14B and the 24B models are realistic for consumer hardware. Small 4 is exciting, but requires a lot of memory. Devstral 2, Medium 3.5 and Large 3 belong in server, multi-GPU or API setups. This article is therefore not a list of the best, but rather a hardware decision-making aid.

The Mistral AI model family 2026 at a glance

Mistral covers four classes in 2026: edge, workstation, storage-rich local systems and server/API. The table shows the rough model map.

Regarding the license situation: Ministral, Small 3.2, Small 4 and Large 3 are under Apache 2.0. Devstral 2 and Medium 3.5 use a modified MIT license with commercial restrictions. The distinction between open weights, open source and proprietary models is comparative Open source vs. proprietary AI models classified in more detail.

Edge Tier: Ministral 3 (3B, 8B, 14B)

The Ministral 3 series is Mistral’s Edge line: dense Transformer, Apache 2.0, 256k context, image processing and sizes from 3B to 14B.

Ministerial 3B occupies around 2 GB in Q4_K_M and runs on almost all current consumer or Apple silicon hardware. Useful uses: language pre-classification, on-device translation, sensor event tagging and embedded routing. It is too small for generative long form.

Ministerial 8B (Q4_K_M: around 5 GB) is the simple local standard for chat, summarization and light tool workflows. RTX 3060, RTX 4070 and Mac mini 16 GB are enough.

Ministry 14B (Q4_K_M: around 9 GB) brings more quality, but needs buffers for KV cache. Mac mini M4 with 32 GB, Mac mini M4 Pro 48/64 GB or RTX 4090 make more sense than a scarce RTX 3060.

All three variants are available via Ollama.

Workstation Tier: Mistral Small 3.2 and Mistral Small 4

Mistral Small 3.2

Mistral Small 3.2 is a 24B dense model for general instruction following. In Q4_K_M it occupies around 14 GB.

Small 3.2 fits well on RTX 4090/5090 and Apple Silicon systems from Mac mini M4 Pro 48/64 GB. A 32GB Mac mini M4 is in short supply because the operating system, model weight, and KV cache share the same storage pool. The reason for Small 3.2 today is primarily hardware: Small 4 can do more, but requires significantly more memory.

Mistral Small 4

Mistral Small 4 bundles instruction, reasoning, multimodality and coding in one MoE checkpoint: 119 billion total parameters, 6 billion active per token, 256k context, Apache 2.0.

Important for local deployments: Small 4’s MoE design reduces compute requirements, not storage requirements. All 119 billion weights must be available in memory so that the router can activate the four correct experts on each token. A 119B MoE model therefore has the same memory footprint as a 119B Dense model with the same quantization. In the Q4_K_M format, the model weight is around 60 GB; There is also operating system overhead and KV cache.

The lever is reasoning_effort: none for quick chat replies, high for more complex reasoning or coding tasks. With this, Small 4 consolidates previously separate lines for Reasoning, Vision and Coding; Devstral 2 and Medium 3.5 remain stronger for large production setups.

Small 4 is available via llama.cpp, vLLM and SGLang.

Coding focus: Devstral Small 2 and Devstral 2

Benchmark note: The SWE bench Verified values ​​mentioned come from manufacturer or third-party sources, not from AISyndicate’s own measurements. They are only roughly comparable because of runtime, quantization, hardware and agent harness.

Devstral Small 2

Devstral Small 2 has the same parameter range as Mistral Small 3.2 (24B dense), but is trained specifically for code agent workflows. SWE bench Verified: 68.0 percent. 256k context window, Apache 2.0 license.

The difference from Small 3.2 is the purpose: Devstral Small 2 is optimized for codebase navigation, multi-file changes and agentic coding loops. For local coding agents, it is the more direct choice. The hardware requirements remain similar (Q4_K_M: around 14 GB).

Devstral 2

Devstral 2 is the 123B Dense flagship of the coding line and was released in December 2025. SWE-bench Verified: 72.2 percent. Modified MIT License. 256k context.

At around 74 GB in Q4_K_M format, Devstral 2 is not a consumer hardware candidate. It requires at least 80GB of addressable memory, which in practice amounts to Mac Studio Ultra (128GB), multi-GPU setups or data center hardware. Note: With the release of Mistral Medium 3.5, Devstral 2 in Mistral’s own Vibe CLI has been replaced by Medium 3.5, which performs better on all coding benchmarks.

Enterprise Tier: Mistral Medium 3.5

Mistral Medium 3.5 is a 128B dense model and Mistral’s current flagship for generalist enterprise applications. It combines instruction following, configurable reasoning and code agent capabilities in one checkpoint: SWE-bench Verified 77.6 percent (see benchmark introduction in the coding section). Mistral’s separate reasoning line Magistral is largely absorbed with Medium 3.5; the reasoning_effortmechanism replaces them.

Medium 3.5 is not practical for consumer hardware. In Q4_K_M format it occupies around 77 GB. Mistral’s own recommendation for server deployments: 4x H100, 2x H200 or 1x DGX B200 as a minimum. If you need the performance of Medium 3.5, use the Mistral API. Mistral Large 3 with 675B MoE is one level above, but is irrelevant for local setups.

Hosting yourself: What do I really need?

The most important question is not which Mistral model is strongest on paper, but which model runs sensibly on the existing hardware. The following table follows the same principle as that Qwen Guide: Model, memory requirements, typical hardware. GGUF sizes are based on Q4_K_M quantization unless otherwise stated.

Apple Silicon Note: Unified Memory is a shared RAM/VRAM pool, not dedicated GPU VRAM.

Note on the column VRAM BF16 (theoretisch): This is a top storage anchor, not a meaningful local target configuration. In practice, local deployments run quantized, usually Q4_K_M or comparable.

Short read: Ministral 8B/14B and the 24B models are realistic up to 32 GB. Small 4 starts just barely at 64 GB and becomes useful at 128 GB. Devstral 2, Medium 3.5 and Large 3 belong in server, multi-GPU or API setups.

Runtime options: Ollama, llama.cpp, LM Studio, vLLM

Ollama is the easiest entry point for the Ministral 3 series and the 24B models (Small 3.2, Devstral Small 2). Ready-made tags are immediately available. If you primarily classify Apple silicon hardware, see the article Ollama on Mac mini the broader RAM and model perspective. There is no stable official Ollama tag for Mistral Small 4 at the time of this article; here llama.cpp with Hugging Face’s GGUF checkpoint is the recommended way.

llama.cpp is the flexible local route for quantization and CPU/GPU offload. LM Studio is the graphic version of it. vLLM and SGLang belong more in server deployments, high-throughput inference and optimized MoE setups.

Recommendation

Ministral 8B or 14B are sufficient for simple local assistance and word processing. For workstation setups with RTX 4090/5090 or Mac mini M4 Pro 48/64 GB, Small 3.2 and Devstral Small 2 are the clean 24B class; Devstral is a better choice if coding agents are the primary purpose.

Small 4 is the interesting high-end step, but only with a lot of memory: 64 GB is tight, 128 GB makes sense. Devstral 2 and Medium 3.5 remain server or API models.

Which model for which use case?

Short version:

• Ministry 3B: Edge classification, translation, sensor/event tagging.
• Ministry 8B: local all-round assistant for chat, light RAG and tool tasks.
• Ministry 14B: Better quality note-taking, translation and summarization on more powerful consumer hardware.
• Small 3.2: general 24B workstation model for chat, drafting and RAG.
• Devstral Small 2: 24B model for local coding agents and repository work.
• Small 4: High-end checkpoint for chat, reasoning, vision and coding with a lot of memory.
• Devstral 2 / Medium 3.5: Server or API class.

Medium-term consequences

Two consequences remain.

First, the 100+ billion weight MoE class moves local deployments toward memory-rich workstations. 64 GB of unified memory is tight, 128 GB becomes the sensible lower limit for Q4. Teams must therefore decide earlier between local high-end budget and API dependency.

Second, the runtime choice becomes an architectural decision. llama.cpp, vLLM and SGLang are not just tools, but also determine deployment pipelines, monitoring, scaling, hardware utilization and team know-how. This is similar to the container runtime decision of previous infrastructure generations.