MiMo-V2.6 shipped with downloadable Pro and Flash checkpoints on Hugging Face, and a small active-parameter count next to the words “open weights” makes in-house serving look cheap. The release details don’t support that reading. This post uses the MiMo-V2.6 overview published on CometAPI’s blog on September 24, 2026, which cites Xiaomi’s model cards and pricing. Its point for platform teams: active parameters tell you the compute per token. They don’t tell you what hardware you have to stand up.
Active parameters vs. what you have to serve
Architecture figures as reported from Xiaomi’s model cards:
| MiMo-V2.6-Pro | MiMo-V2.6-Flash | |
|---|---|---|
| Total parameters | 1.02T | 309B |
| Active per token | ~42B | ~15B |
| Transformer layers | 70 | 48 |
| Hidden size | 6,144 | 4,096 |
| Routed experts | 384 | 256 |
| Experts activated | 8 | 8 |
| Maximum context | 1M | 1M |
The active share is roughly 4% of total parameters for Pro and about 5% for Flash. The source says it directly: “headline parameter count and per-token compute are very different quantities.” Sparse routing lets Xiaomi keep a large expert pool without running dense inference across every weight for every token.
That covers compute. Memory works differently. The router selects experts per token, so a serving deployment has to keep the whole expert pool loaded and reachable, not just the ~42B that one token touches. The source’s FAQ says the same: the full checkpoint “still has a very large memory and distributed-serving footprint.”
The source doesn’t state the checkpoint’s storage precision, so there is no official weight-size figure to quote. The arithmetic is still simple. Each byte per parameter comes to about 1.02 TB of weights for Pro and about 0.31 TB for Flash. That is before KV cache, activations or any replicas. Whether that fits on one node or several depends on precision and on your accelerators, and that is exactly the planning work the source says to expect.
What the source says Pro self-hosting involves
The source is explicit about Pro. “Self-hosting the full Pro checkpoint is also an infrastructure-heavy task. Open weights do not mean easy workstation deployment.” Its FAQ adds that production deployment “may require multi-node inference, expert parallelism, specialized kernels, and careful capacity planning.” Its comparison table sums up self-hosting as “Yes, with substantial infrastructure.”
For a platform team, that becomes a short list of questions to answer before downloading anything:
- Expert parallelism. Does your serving stack already shard experts across devices and nodes? Has it done so for a pool of this size (384 routed experts, 8 active)?
- Kernels for this architecture. The model mixes sliding-window and global-attention layers. It also ships a five-layer multi-token-prediction speculative decoder. To get the benefit of that decoder, your inference engine has to support it. The source doesn’t say which engines do.
- The multimodal path. Both checkpoints include a 681M-parameter MiMo ViT, a 308M-parameter AudioTokenizer and a 127M-parameter audio patch encoder. If you need image, video or audio input, those components must be served too, not just the text decoder.
- Long-context capacity. Both models support a 1M-token context. The source doesn’t give the split between sliding-window and global layers, so it can’t tell you how much KV-cache memory a very long request needs. The source also notes that a 1M window doesn’t replace retrieval or context pruning, because unnecessary history raises latency and cost. On hardware you pay for, that cost is capacity you have to provision.
Flash: smaller, not small
The source says less about Flash. It gives the architecture above. Its access guidance describes downloading either the Pro or the Flash checkpoint as “subject to substantial serving requirements.” The explicit multi-node and expert-parallelism language is attached to Pro.
So the source supports neither of the tempting readings: that Flash needs multi-node serving, or that it fits on a workstation. At the same precision, Flash’s weights are about 30% of Pro’s (309B vs. 1.02T). That is an input to your sizing, not a deployment verdict.
What the managed path looks like
For comparison, Xiaomi’s managed API, as described in the source:
- It is OpenAI-compatible and documents Anthropic-protocol compatibility.
- Model IDs are
mimo-v2.6-pro,mimo-v2.6-flashandmimo-v2.6-pro-ultraspeed. - Documented features: tool calling, structured output, streaming, reasoning controls, context caching and web search.
- Deep thinking is on by default through
thinking.type. - Output is up to 128K tokens.
Official prices per 1M tokens, as reported in the September 24, 2026 article (prices change, so re-check before budgeting):
| Tier | Cached input | Uncached input | Output |
|---|---|---|---|
| Pro | $0.0036 | $0.435 | $0.87 |
| Flash | $0.0028 | $0.14 | $0.28 |
| Pro UltraSpeed | $0.036 | $4.35 | $8.70 |
The source says V2.6 API pricing stays at the same broad level as V2.5. One point matters for a self-hosting decision. UltraSpeed is described as “a serving tier rather than a different capability model,” advertised at up to 20× the output speed of standard Pro. Faster output on the same weights is work a serving team would otherwise have to engineer, and here it is sold as a priced tier.
The source gives no hardware or operating cost to set against these rates. Any break-even estimate needs your own accelerator pricing and utilization numbers. At least the API side of the comparison is published.
The 9B distill is a research artifact
The source describes the release as more than weights. It includes full RL code, more than 7,000 RL task environments, a training framework and infrastructure, and lightweight harnesses. The environments span software engineering, vulnerability reproduction, knowledge-intensive work and web design and development. The release also includes MiMo-V2.6-Distill-Qwen-9B. The source’s stated reason for it is “so researchers can study the RL pipeline at a much smaller scale.”
That is the right way to think about the 9B checkpoint. The source gives no benchmark results for it and doesn’t present it as a substitute for Pro or Flash. If the goal is “a MiMo we can run locally for production traffic,” nothing in the release material suggests the 9B distill reproduces the larger models’ reported agent results. If the goal is to study or adapt the RL recipe, the distill together with the released code and environments is the practical entry point.
What the source does not tell you
Before any capacity plan, check these gaps against the Hugging Face model cards and Xiaomi’s documentation:
- GPU counts or node topology for either checkpoint
- Checkpoint precision, format, total weight size, or any quantized variants
- License terms for the weights. The source’s own comparison table notes that open-weight models vary “by license, size, and deployment stack.”
- Which serving engines support the architecture, including the speculative decoder and the audio and vision components
- Self-hosted throughput or latency figures
- The ratio of sliding-window to global-attention layers
This post doesn’t assume the answers to any of these.
A defensible default
- No existing distributed MoE serving in production: start with a managed API. The source’s own requirement list (multi-node inference, expert parallelism, specialized kernels, capacity planning) describes a platform capability you already need to have. You can’t pick it up just to trial one model.
- You already run distributed MoE serving: build the case from your own numbers. Utilization, accelerator cost and data-handling requirements decide it, and the source quantifies none of them. Flash’s smaller footprint makes it the lower-risk checkpoint to size first.
- Either way, evaluate a system, not a model. The source notes that several headline demonstrations depend on external tools and agent harnesses. It recommends measuring task completion, tool-call accuracy, recovery from failed actions, latency, token consumption, context management and permission boundaries. For a self-hosting plan, run that evaluation against the managed API first. It gives you a quality baseline, so serving-stack problems in your own deployment show up as regressions rather than going unnoticed.
- Treat the 9B distill as a research artifact. It is not a local stand-in for Pro or Flash.
All figures and prices above come from the September 24, 2026 source article and the Xiaomi material it cites. They are not independent measurements.