MiMo V2.6 Requirements: VRAM & GPU for Pro, Flash, 9B

The short answer for running Xiaomi's MiMo-V2.6 series, released by the MiMo team on September 22, 2026, locally: required memory varies hugely by model. MiMo-V2.6-Flash (309B total, 15B active) needs an estimated ~170-190GB at 4-bit or ~320-350GB at FP8. MiMo-V2.6-Pro (1.02T total, 42B active) needs an estimated ~550-600GB even at 4-bit. The 9B MiMo-V2.6-Distill-Qwen-9B, by contrast, fits into an estimated ~6-7GB at 4-bit, making a single consumer GPU realistic.

All figures below are estimates. The formula is "total parameters × bytes/param + KV-cache/overhead margin (roughly 5-15%)," using bytes/param of BF16=2, FP8=1, and 4-bit (INT4/GGUF Q4-style)=0.5. Both Pro and Flash are MoE (Mixture of Experts) models, so the active parameters used per token (42B for Pro, 15B for Flash) are far smaller than the totals — but since which experts get selected depends on the input, memory sizing should be based on total parameters, not active ones. Using the full 1M-token context also adds a separate KV-cache cost on top of the weight footprint.

If you want to quickly check whether your own GPU or Mac can run it, we also offer a free, no-signup VRAM calculator that estimates required VRAM once you pick a model, quantization, and context length. MiMo-V2.6's Flash, Pro, and 9B distilled variants are all selectable from the model list.

MiMo-V2.6 is a large language model series released by Xiaomi's MiMo team on September 22, 2026, with three models released at once: MiMo-V2.6-Pro, a large MoE (Mixture of Experts) model with 1.02T total parameters and 42B active; MiMo-V2.6-Flash, a lighter MoE model with 309B total parameters and 15B active; and MiMo-V2.6-Distill-Qwen-9B, a 9B distilled model based on Qwen3.5-9B. All three are released under the MIT license, and alongside the weights, Xiaomi also open-sourced a technical report, more than 7,000 RL task environments, an end-to-end RL framework, and mini-harnesses. The Hugging Face repositories are XiaomiMiMo/MiMo-V2.6-Pro-RL, XiaomiMiMo/MiMo-V2.6-Flash-RL, and XiaomiMiMo/MiMo-V2.6-Distill-Qwen-9B, respectively.

Both Pro and Flash are natively multimodal, handling text, image, video, and audio, sharing a 681M-parameter MiMo ViT vision encoder plus a 308M-parameter AudioTokenizer and a 127M-parameter audio patch encoder. Both support up to 1M-token context and up to 128K output tokens. Weights are distributed in both BF16 and FP8 (F8_E4M3 format), with official deployment examples showing SGLang with a multi-node --tp 16 --dp 2 --ep 16 configuration and vLLM with --tensor-parallel-size 8.

The figures below are self-reported (vendor-reported) benchmarks from Xiaomi's MiMo team, not independently verified by a third party.

Agentic benchmark figures are also published for the 9B Distill-Qwen-9B model.

On third-party evaluator Artificial Analysis's Intelligence Index, MiMo-V2.6-Pro scored 46, reportedly the top score among open-weight models, tying Grok 4.7. For comparison, DeepSeek V4.1 Flash scored 39 and DeepSeek V4.1 Pro scored 36 (both from the same third-party evaluation).

Cache hits are cheaper still. The self-host-vs-API break-even comes down to three things: (1) fixed costs such as GPU procurement, power, and operational staffing; (2) monthly token volume; and (3) data-sovereignty or latency requirements. Since Pro needs over 1TB of memory even at FP8, API usage tends to win on total cost unless sustained, high-volume usage is guaranteed. Flash, on the other hand, fits within a few H100-class GPUs or a single large-memory workstation at 4-bit, so self-hosting can pay off when monthly volume is high and usage is ongoing. Because the 9B distilled model fits on a single consumer GPU, a realistic split is local execution during development/evaluation, with the API considered for production.

Despite having 309B total parameters, MiMo-V2.6-Flash's active parameter count is only 15B, so depending on quantization it may run on realistically sized individual or small-team setups. At FP8 (an estimated ~320-350GB), the math works out to roughly 4-5 H100 80GB GPUs, or 4 H200 141GB GPUs (--tensor-parallel-size 4 --gpu-memory-utilization 0.95), close to the official vLLM example. The official SGLang example also shows a tp=8/dp=2 configuration, leaving room to tune for throughput versus latency.

Dropping to 4-bit quantization (an estimated ~170-190GB) brings a Mac Studio-class workstation with 256GB or 512GB of unified memory into range (estimated; not verified in practice). Hugging Face already lists roughly 19 community-quantized variants, mostly in GGUF format usable with llama.cpp, Ollama, or LM Studio. Compressing further to 2-3-bit brings the estimate down to roughly 110-130GB, putting 128GB-class unified-memory machines — Macs, DGX Spark, or Ryzen AI Max systems — within reach as well. That said, 2-3-bit quantization unavoidably degrades response quality, so in practice it's worth first establishing a quality baseline at FP8 or 4-bit before weighing the tradeoff against further compression. Because the active parameter count is a modest 15B, token-generation speed on unified-memory machines is plausibly reasonable, though no concrete numbers are confirmed.

Using the full 1M-token context adds a separate KV-cache cost on top of the weight footprint above. MiMo-V2.6 dedicates most of its 70 layers (Pro) or 48 layers (Flash) to sliding-window attention (SWA), which keeps KV-cache growth lower than a model with full attention throughout — but genuinely using a context near 1M tokens still adds a non-trivial amount of memory that's worth planning for.

MiMo-V2.6-Distill-Qwen-9B is built by applying SFT (supervised fine-tuning) to the base Qwen3.5-9B model using 77.4B tokens of trajectories generated by MiMo-V2.6. Released as a research starting point for agentic RL, it posts agentic benchmark scores that are high for a 9B-class model: SWE-bench Verified 61.1, SWE-bench Pro 44.6, Terminal Bench 2.1 37.1, and AutomationBench 30.3. At BF16 it's an estimated ~18-20GB, fitting a single RTX 4090 24GB, and at 4-bit quantization it shrinks further to an estimated ~6-7GB, putting it within reach of an RTX 4060 Ti 16GB, an RTX 3060 12GB, or even a 16GB-class Mac. Without the hardware to run Pro or Flash at full scale, this model is a reasonable entry point for experimenting with agentic task behavior or an RL pipeline locally.

Placing MiMo-V2.6 alongside other large open-weight MoE models generating buzz around the same time helps put it in context. Figures below are limited to those confirmed via each model's official sources or this site's existing articles; unconfirmed items are marked accordingly.

By total parameters, MiMo-V2.6-Pro's 1.02T is among the largest here, and its 42B active-parameter design is also on the larger side compared with DeepSeek V4.1-Flash's 16B decode-time active count or Atria Dawn Preview's scale. MiMo-V2.6-Flash, by contrast, leans lighter at 15B active, and its estimated memory footprint comes in lower than the similarly sized Atria Dawn Preview (744B total). Kimi K3 stands out at 2.8T total parameters, but since its official distribution is MXFP4, its footprint isn't directly comparable to the other models' "4-bit" figures. On the benchmark side, MiMo-V2.6-Pro's Artificial Analysis Intelligence Index score of 46 reportedly beats DeepSeek V4.1 Flash's 39 and DeepSeek V4.1 Pro's 36.

- Getting OOM errors: first shorten the context length to cut KV-cache usage, then isolate whether the weights themselves fit
- FP8 just barely doesn't fit: lowering --gpu-memory-utilization below the official vLLM example's 0.95 makes it easier to launch, but at the cost of effective context length or batch size
- Errors on multi-node setups (SGLang tp16/dp2, etc.): inter-node bandwidth (NVLink/InfiniBand, etc.) is often the bottleneck, so verify things work on a single node first
- Memory spikes suddenly at near-1M-token context: even an SWA-heavy design has a finite ceiling, so estimate the context length you'll actually use and budget KV-cache headroom separately from weight capacity
- Community quantizations (GGUF, etc.) behave unpredictably: multimodal support often lags behind or is missing entirely, so verify text-only operation first

- Vendor-reported benchmarks: the Pro/Flash performance comparisons cited here are self-reported by Xiaomi's MiMo team, not independently verified by a third party
- All memory figures are estimates: they come from a simplified "total parameters × bytes/param + overhead" formula; actual usage varies with the inference engine, batch size, and context length
- Community quantization quality: low-bit quantizations such as GGUF can degrade response quality relative to the official checkpoints, especially at 2-3-bit, so practicality should be verified beforehand
- Multimodal support may lag: community runtimes like llama.cpp may support the official vision/audio encoders later, or only offer text-only support
- Distill-Qwen-9B's role: released as a research/experimentation starting point, it shouldn't be expected to match Pro or Flash's overall capability level

MiMo-V2.6 is a three-tier open-weight series from Xiaomi's MiMo team, released September 22, 2026: the 1.02T MoE model MiMo-V2.6-Pro, the 309B MiMo-V2.6-Flash, and the 9B MiMo-V2.6-Distill-Qwen-9B. Running it locally takes roughly 170-190GB at 4-bit or 320-350GB at FP8 for Flash, roughly 550-600GB even at 4-bit for Pro, and roughly 6-7GB at 4-bit for the 9B distilled model — all estimates, but spanning wildly different scales of compute depending on the model. Benchmarks are mostly vendor-reported, though it's worth noting that on the third-party Artificial Analysis Intelligence Index, Pro scored 46, reportedly the top score among open-weight models. For comparison with other large open-weight MoE models released around the same time, see this site's articles on DeepSeek V4.1-Flash, Kimi K3, and Atria Dawn Preview.