Devstral Small 1.1 24B VRAM: 16GB, 24GB, 32GB or 48GB?

Short answer: Mistral’s official Devstral Small 1.1 24B GGUF repository lists 14.3GB Q4_K_M, 16.8GB Q5_K_M, 25.1GB Q8_0 and 47.2GB BF16. That makes 16GB a constrained Q4 target, 24GB the practical Q4/Q5 tier, 32GB the Q8_0 tier, and 48GB too tight for BF16 as a complete workload. Plan 64GB+ for practical BF16 working room.

Official Devstral Small 1.1 GGUF sizes

Official artifact	Displayed size	Practical memory tier
Q4_K_M	14.3GB	16GB is constrained; 24GB gives useful working room
Q5_K_M	16.8GB	Does not fit wholly on 16GB; target 24GB+
Q8_0	25.1GB	Does not fit wholly on 24GB; target 32GB+
BF16	47.2GB	Too tight on 48GB after cache/runtime allocations; target 64GB+

16GB, 24GB, 32GB or 48GB?

• 16GB: the 14.3GB Q4_K_M file leaves only about 1.7GB before cache, buffers, kernels and display use. Treat it as a tightly tested option, not a comfortable promise.
• 24GB: the practical Q4/Q5 tier, leaving about 9.7GB beyond Q4 or 7.2GB beyond Q5 before the rest of the model workload.
• 32GB: the first common tier above the 25.1GB Q8_0 file, with about 6.9GB before cache and runtime state.
• 48GB: the 47.2GB BF16 file is a file-size trap. About 0.8GB remains before cache, buffers and other allocations.
• 64GB+: the practical BF16 starting tier, subject to runtime and platform support.

Compare those choices in the 24GB/32GB/48GB guide and use the VRAM calculator for context, concurrency and working margin.

Exact model identity matters

This page covers Devstral Small 1.1, the official July 2025 Devstral-Small-2507_gguf release. It is a 24B text-only agentic coding model with a 128K context window and Tekken tokenizer. Do not silently transfer these sizes to the earlier 2505 release, Devstral Small 2, or a community quantization.

128K context is not a fit promise

The published context limit tells you what the model architecture accepts, not what fits on every listed memory tier. Repository prompts, tool output, edit history and agent traces can grow quickly. KV cache, runtime buffers and concurrent sequences sit alongside the weights. Test the longest representative coding task rather than relying on a successful model load.

Text-only model, tool-using workflow

Mistral describes this release as text only and states that the vision encoder was removed. The model supports Mistral function-calling formatting, but an integration must still implement tools, permissions, sandboxing, error handling and result validation. Function-call support does not certify that an agent will edit the right file or complete a coding task correctly.

Budget the agent scaffold separately

Mistral recommends Devstral with OpenHands. That is an integration recommendation, not a statement that the whole stack fits inside the model’s GPU-memory margin. A useful capacity record has two columns:

• Accelerator memory: weights, KV cache, runtime buffers, graph workspaces, display use and any other device allocations.
• Host resources: operating system, agent process, repository index, containers, compilers, tests, browser or terminal tools, system RAM and storage.

On unified-memory systems, the model and host processes may draw from one physical pool. That still does not make every byte available to the model; measure the complete system under the intended task.

Quantization changes fit, not just file size

The official repository supplies four useful capacity points, not a universal quality ranking. A smaller artifact may create the only workable context margin on a given card, while a larger artifact may preserve behavior on some tasks. Compare task success, edit correctness, latency and peak memory together. The quantization guide explains format names without treating bits alone as a quality score.

A reproducible coding-agent fit test

1. Record the exact Mistral repository snapshot, GGUF filename, displayed size and checksum.
2. Record the inference runtime and commit or release.
3. Record the agent scaffold and version, plus enabled tools, permissions, container image and repository state.
4. Record accelerator model/capacity, system RAM, CPU, storage, OS, driver and device placement.
5. Record prompt/context length, output target, concurrency, cache precision and offload settings.
6. Run a representative repository task that exercises search, edits, commands and tests—not only a chat prompt.
7. Measure time to first token, throughput, peak accelerator memory, peak system RAM and storage growth.
8. Record fallback, out-of-memory and tool errors separately.
9. Inspect the patch and test results; a completed trace is not proof of a correct change.

Use the repeatable workload test and share a measured result.

Official sources and limits

• Mistral official Devstral Small 1.1 GGUF model card
• Mistral official GGUF files
• Mistral official model repository
• HighVRAM methodology

Reviewed October 25, 2026. File sizes, identity and capability statements are from Mistral’s official repositories on that date. HighVRAM has not independently benchmarked every artifact, runtime or agent scaffold. Fit does not establish speed, task success or output correctness.

General-purpose multimodal alternative: the Mistral Small 3.2 24B VRAM guide separates its vision-capable official checkpoint from community GGUF packaging.

Compare adjacent Mistral releases: the Mistral 24B hub contrasts Devstral with Small 3.2 and Magistral by workload, modality and deployment requirements.

Hardware shortlist: map these exact files to 16GB through 64GB+ hardware paths for a 24B LLM.