How much VRAM does MiMo-V2.5-Pro 1.02T (MoE) need at Q4_K_M? Xiaomi 1M SWA frontier

By TechCompare · Updated · How we check

MiMo-V2.5-Pro 1.02T at Q4_K_M is a 687 GB resident deployment for 1M context, and 571 GB of that is weights.

Calculator

Estimated VRAM required

687 GB

1020B params at Q4_K_M, 1,048,576 token context, batch 1, inference.

Weights
571 GB
KV cache
53.7 GB
Overhead
62.5 GB

Estimate accuracy: Weights within ~2%. KV cache within ~5% for standard GQA models, ~10% for MLA or hybrid state estimates. Real VRAM may vary with framework (vLLM vs llama.cpp vs Transformers), Flash Attention, and driver overhead.

Sliding-window attention applied: This model caps 6 of every 7 layers at a 128-token window. KV cache estimate is 86% smaller than naive full-attention math at this context length.

Hardware that fits

Apple entries show installed unified memory separately from a model budget based on an 8 GB reserve. That budget is a planning heuristic, not a fixed hardware limit.

No single GPU in our catalog has enough memory. Multi-GPU or CPU offload required.

MiMo-V2.5-Pro 1.02T at Q4_K_M with native 1M context needs about 687 GB of VRAM with all experts resident. Xiaomi's MoE model activates 42B parameters per token from a 1.02 trillion total pool. That doesn't shrink what has to stay loaded, because different tokens pick different experts. The asymmetric QK and V attention dims plus sliding-window attention keep the key-value cache to 54 GB at full context.

How this is calculated

MiMo-V2.5-Pro's 1.02T parameter pool requires 571 GB of weights at Q4_K_M. The 70-layer architecture uses group-query attention with 8 KV heads and asymmetric key and value dims: keys use 192, values use 128, averaged to an effective head_dim of 160 in the cache math.

Sliding-window attention caps 60 of 70 layers at a 128-token window with 10 layers doing full global attention. The result is a 54 GB key-value cache at the full 1M context. Activation and software overhead adds about 62 GB.

Verdict

Plan for datacenter hardware: 9 cards of 80 GB or 5 H200 cards of 141 GB, both with NVLink, for the 687 GB resident total. The sliding-window attention on 60 of 70 layers is what keeps the cache small: capping those layers at a 128-token window leaves only the 10 global layers growing with context, so the cache is 54 GB even at 1M tokens.

More MiMo scenarios

Kimi K3.1 Pro at Q4_K_M
A 2.78T expert pool with 24 latent attention layers and fixed state in the other 69.
View details
Mistral Large 4 at Q4_K_M
A 1T expert pool with 63 latent cache owners and 44 layers that also store an index key.
View details
Muse Spark Open at Q4_K_M
Only 16 of its 62 layers grow with context, and the other 46 hold a 2,048 token window.
View details

Frequently asked questions

Why does MiMo-V2.5-Pro use asymmetric QK and V dimensions?
Xiaomi splits the key and value projection dims. Keys use 192, values use 128. This trades a slightly larger key projection for a smaller value cache. The effective head_dim in the cache formula is the average of the two, 160. The result is a cache smaller than a symmetric 192-dim model but larger than a symmetric 128-dim model.
Can I run MiMo-V2.5-Pro locally?
Not on a normal desktop. The 687 GB resident total needs multi-GPU datacenter hardware. The 42B active count doesn't shrink that, because different tokens pick different experts. Moving expert weights to system RAM cuts VRAM, but the host then has to hold most of the 571 GB of weights and every token gets slower.
Can I run MiMo-V2.5-Pro 1.02T locally?
Only on datacenter hardware. The 1.02T parameter pool at Q4 is 571 GB just for weights, and every expert has to be loaded somewhere, since each token can pick different ones. For most workloads, hosted MiMo-V2.5-Pro via OpenRouter is usually cheaper than self-hosting at this scale.
How do MoE throughput and latency change when experts live in system RAM?
Every token slows down. llama.cpp's --cpu-moe and --n-cpu-moe keep whole layers' expert weights in system RAM, which is much slower than VRAM, and every token passes through those layers. The practical outcome: CPU-resident MoE works for offline batch jobs, not for interactive latency.