TechCompare LogoTechCompare

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

MiMo-V2.5-Pro 1.02T at Q4_K_M is a 687 GB resident deployment for 1M context, or about 85 GB with active-expert offload.

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 flagship MoE activates 42B parameters per token from a 1.02 trillion total pool. Active-expert offload drops the resident footprint to roughly 85 GB. The asymmetric QK and V attention dims plus sliding-window attention keep the key-value cache manageable even at full context.

By TechCompare · Updated

Total VRAM required
687 GB
MiMo-V2.5-Pro 1.02T (MoE) at Q4_K_M
Weights
571 GB
1020B params
KV cache
53.7 GB
1024K tokens, FP16 KV

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.

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. In active-only mode the resident weights shrink to 24 GB, which drops total usage to 85 GB.

Verdict

The 687 GB resident total sums from 571 GB of Q4 weights, 54 GB of FP16 KV cache at the full 1M context (8 KV heads with asymmetric QK/V dims averaging to head_dim 160 across 70 layers), and 62 GB of overhead. Hardware-wise that's nine 80 GB datacenter cards or five 141 GB H200 cards, both with NVLink. Active-only loading shrinks the weights to about 24 GB by routing cold experts through system RAM, dropping the total to roughly 85 GB while the cache stays at 54 GB. The 60-of-70-layer sliding-window attention is why active-only stays runnable: capping 60 layers at a 128-token window keeps the cache near-constant regardless of context length, so active-offload works on a single 96 GB pro card or a 128 GB unified-memory workstation. Context capping at 128K drops active-only further to about 60 GB.

More MiMo scenarios

DeepSeek V4 Pro 1.6T (MoE) at Q4_K_M
DeepSeek V4 Pro 1.6T at Q4_K_M with the full 1M-token context needs about 1012 GB of VRAM with every expert resident - this is the real shape of the model and the number to plan a deployment against.
View details ➜
Llama 4 Scout (17B/109B) at Q4_K_M
At Q4_K_M and 10,485,760 tokens, this model estimates 2335 GB with all 109B parameters resident.
View details ➜
gpt-oss 20B (MoE) at Q4_K_M
gpt-oss 20B at Q4_K_M with native 128K context needs about 19.4 GB of VRAM with all experts resident, dropping to roughly 9.3 GB with active-only weight loading.
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?
Only in active-only mode. The 687 GB resident total needs multi-GPU datacenter hardware. Active-only at 85 GB fits on a 96 GB pro card or a high-memory unified workstation, but cold-expert PCIe streaming limits throughput. Capping context to 128K drops active-only to about 60 GB.
Can I run MiMo-V2.5-Pro 1.02T locally?
Only in active-only mode on datacenter hardware. The 1.02T parameter pool at Q4 is 571 GB just for weights. Active-only keeps the resident expert subset under 30 GB, but the per-token bandwidth penalty of fetching cold experts through system RAM or NVMe makes throughput slow. For most workloads, hosted MiMo-V2.5-Pro via OpenRouter is dramatically cheaper than self-hosting at this scale.
How do MoE throughput and latency change when experts live in system RAM?
Throughput falls off a cliff for token-diverse prompts because the PCIe or DRAM path to a cold expert is orders of magnitude slower than VRAM. Batched workloads where experts cluster stay acceptable because the fetched expert gets reused for many tokens before eviction. The practical outcome: CPU-resident MoE works for offline batch jobs, not for interactive latency.