Xiaomi MiMo-V2.6 Pro and Flash: Open Weights, Million-Token Context, and Deployment Costs

A 309-billion-parameter model sounds like something that belongs in a rack. Xiaomi’s MiMo-V2.6 Flash complicates that picture. It has 309B total parameters, but only 15B are active for each token. MiMo-V2.6 Pro stretches the same idea to 1.02 trillion total parameters and 42B active.

The sparse architecture lowers compute per token. The rest of the experts still need somewhere to live. That becomes important as soon as you try to run the weights yourself.

Xiaomi released and open-sourced both models on September 22, 2026. They accept text, images, video, and audio, advertise a one-million-token context window, and are available on Hugging Face under the MIT license. The hosted prices are far below what the checkpoint sizes might suggest:

Model	Uncached input	Output
MiMo-V2.6 Flash	$0.14/M	$0.28/M
MiMo-V2.6 Pro	$0.435/M	$0.87/M

The practical result is unusual: the weights are open, while the hosted API may cost less than the hardware needed to serve them yourself.

Active parameters and storage

Flash contains 256 routed experts in each sparse MoE block and activates eight. Pro contains 384 and also selects eight. That is how a 309B model reaches a 15B active figure and a 1.02T model reaches 42B active. The Flash and Pro model cards describe both architectures as sparse Mixture-of-Experts models.

Every expert remains part of the deployment, even when a token does not select it. Another token can be routed through the inactive pool, so the server still needs that pool in memory, distributed across GPUs, or available through a slower offload mechanism.

The storage calculation is different from the “15B active” figure. Flash works out to roughly 618 GB at BF16, 309 GB at 8-bit, or 155 GB at a uniform 4-bit. Pro is about 2.04 TB, 1.02 TB, or 510 GB at the same precisions.

Weight precision	Flash	Pro
BF16	~618 GB	~2.04 TB
8-bit	~309 GB	~1.02 TB
Uniform 4-bit	~155 GB	~510 GB

These are arithmetic planning floors calculated as parameters × bits / 8. They are not official minimum-VRAM figures. A real deployment also needs KV cache, runtime buffers, quantization metadata, multimodal encoders, and speculative-decoder weights.

The published conversions show the gap. The ggml-org Flash GGUF has 167 GB of core model shards at MXFP4, with a more aggressive Q2_K build at 126 GB; the repository also publishes separate multimodal-projector and speculative-decoding sidecars. An MLX Pro conversion using native MXFP4 experts and 8-bit non-expert tensors occupies 516 GB even though it leaves out the vision and audio encoders and speculative decoder.

A large-memory workstation could hold a quantized Flash artifact, although that says nothing about usable speed. Pro is much closer to server territory.

Memory cost at one million tokens

Both models mix sliding-window attention with a smaller number of global-attention layers. Flash has 48 Transformer layers, including 39 sliding-window layers and nine global-attention layers. Pro has 70 layers, split into 60 sliding-window and ten global-attention layers. The local layers keep a 128-token sliding window, which keeps long-context KV-cache growth far below what full attention in every layer would require.

Using the published global-layer counts, KV head counts, and BF16 storage, the raw global-attention KV cache works out to about 22.5 GiB for one full 1,048,576-token Flash sequence and 50 GiB for Pro. The models use asymmetric K/V head dimensions—192 for K and 128 for V—so the calculation is global layers × KV heads × (192 + 128) × 2 bytes × 1,048,576 tokens. A 25% planning allowance brings those figures to roughly 28.1 GiB and 62.5 GiB. These are calculations from the architecture, not Xiaomi memory specifications, and they exclude the small sliding-window caches plus implementation details such as page tables and runtime overhead.

The models can accept enormous contexts, but I would still compact a repository or tool history when I can. A 1M limit says the request fits. It does not promise a short prefill or cheap concurrency.

The published SGLang commands use chunked prefill: 16K pieces for Flash and 32K for Pro. Long-context serving needs deliberate memory and scheduling work.

Deploying Flash and Pro

For Flash, the V2.6 vLLM recipe uses four-way tensor parallelism, while the model-card SGLang setup uses eight-way parallelism, data-parallel attention, and speculative decoding. The H200 example in the V2.6 Pro vLLM recipe uses eight GPUs; its model-card SGLang example uses 16-way tensor and expert parallelism across two nodes.

Those are published topology examples, not proof that smaller quantized deployments cannot work. They do show why the active-parameter figures should not be used as memory estimates.

A local path exists for Flash. The ggml-org repository publishes GGUF files with commands for llama.cpp and Ollama, including multimodal projector and speculative-decoding assets.

For those 126-167 GB core Flash builds, I would start with 192 GB of system memory and prefer 256 GB for long context or partial GPU offload. Xiaomi has not published a workstation minimum; this is my recommended headroom, not a model requirement.

Pro has a different deployment profile. The 516 GB MLX conversion targets two 512 GB machines. The model cards’ SGLang example also points toward a distributed server rather than a workstation.

The model cards use --trust-remote-code in their serving examples. In production, I would pin a specific Hugging Face revision, inspect the executable model code, and verify downloaded artifacts instead of fetching a mutable revision during every service startup. The license is permissive, but a deployment still includes software.

API costs and self-hosting

Xiaomi’s overseas prices, checked September 24, are:

API price per 1M tokens	Flash	Pro
Cache-hit input	$0.0028	$0.0036
Cache-miss input	$0.14	$0.435
Output	$0.28	$0.87
Batch input, cache miss	$0.07	$0.2175
Batch output	$0.14	$0.435

Xiaomi says Batch API requests cost 50% of the equivalent real-time requests. Cache-hit input is much cheaper than cache-miss input, which matters for agents that repeatedly send the same system prompt, tool definitions, repository context, or document prefix.

For a workload where three quarters of the tokens are uncached input and one quarter are output:

Flash: 0.75 × $0.14 + 0.25 × $0.28 = $0.175 per million total tokens
Pro:   0.75 × $0.435 + 0.25 × $0.87 = $0.54375 per million total tokens

Batch cuts those figures to about $0.0875 and $0.2719, respectively. For another common way of quoting costs, one million input tokens plus one million output tokens costs $0.42 on Flash and $1.305 on Pro before cache discounts.

A simple self-hosting comparison

The following chart is an accounting illustration, not a benchmark. It compares the hosted blended rate with GPU rental under the assumptions below.

%%{init: {"xyChart": {"showDataLabel": true, "showDataLabelOutsideBar": true}}}%%
xychart-beta
    title "Illustrative cost per million total tokens"
    x-axis ["Flash API", "Flash GPUs", "Pro API", "Pro GPUs"]
    y-axis "USD / M tokens" 0 --> 22
    bar [0.175, 3.25, 0.54375, 19.56]

For the self-managed comparison, I used Lambda’s public GPU prices. A four-H100 SXM instance is listed at $4.09 per GPU-hour, giving $16.36/hour for four H100s. Lambda lists a 16-H100 cluster at $6.16 per GPU-hour, or $98.56/hour.

The chart assumes 2,000 effective billed tokens per second while busy and 70% billable utilization. Under those assumptions:

self-host $/M = GPU $/hour ÷ (tokens/s × utilization × 3600) × 1,000,000

Flash comes to roughly $3.25/M tokens in GPU rental. Pro comes to about $19.56/M. Storage, networking, orchestration, engineering labor, replicas, and spare capacity are excluded. The 2,000-token throughput is an accounting assumption, not a measurement of MiMo-V2.6.

The break-even calculation shows how much throughput the assumptions require. Under the same 70% utilization assumption, the four-H100 Flash deployment would need roughly 37,100 effective tokens per second while busy to match the $0.175 hosted blended rate. Pro would need about 71,900 tokens per second on the 16-H100 cluster to match $0.54375. Those are mathematical break-even points, not expected throughput figures.

Self-hosting can still make sense: a company may already own underused hardware, electricity may be cheap, traffic may be predictable enough to keep the server full, or data-governance requirements may rule out the public API. It is still a poor default to assume that open weights are cheaper simply because you can run them yourself.

Benchmark gaps

Xiaomi reports the following results in its Pro model card:

Evaluation	Pro	Flash
DeepSWE v1.1	71.9	67.9
Terminal Bench 2.1	89.9	87.6
MiMo VisualCoding	72.3	71.5
SEC Bench Pro	66.3	47.5
ExploitBench	47.9	25.3

These are vendor-published results. They should guide which workloads deserve an A/B test, rather than replace an evaluation on your own tasks.

Independent launch-week data is limited. Xiaomi’s announcement reports 46.32 on the Artificial Analysis Intelligence Index, while Artificial Analysis currently rounds the score to 46. Its provider page, using a 10,000-input-token workload, currently reports 43.3 output tokens per second for Xiaomi, 334.5 for PrimaLabs, and 25.8 for DeepInfra.

The provider measurements are a dated snapshot and can change. Any throughput claim should include the provider, date, input length, and reasoning configuration. “Tokens per second for MiMo-V2.6 Pro” is incomplete without them.

Privacy and security

The MIT weights let you keep inference on your own infrastructure. For code repositories, customer records, internal documents, or media that cannot leave a controlled environment, that can be worth more than the token-price difference.

Self-hosting also means the security job becomes yours. You own model access control, dependency and artifact review, network isolation, logging policy, runtime patching, and the security boundary around agent tools. Agent deployments need the same attention around tool permissions and credentials that they would with any other model.

Xiaomi’s hosted API applies content moderation, and the Batch API keeps uploaded and result files for 30 days. I could not verify a public zero-retention or no-training guarantee for ordinary real-time API traffic from the English materials reviewed. I would settle those terms contractually before sending regulated or particularly sensitive data.

Which model would I use?

Flash first

Flash keeps the one-million-token context and the same four input modalities while costing about a third as much per uncached token as Pro. It also has a much friendlier local-inference story, with usable GGUF releases already available.

I would put Pro behind the same application and run a held-out evaluation. If it completes enough hard coding, agent, security, or multimodal tasks that Flash misses, the upgrade can be easy to justify. If both produce the same usable result, paying roughly 3.1 times the token rate accomplishes very little.

For self-hosting, a quantized Flash build can fit on a large-memory machine or a modest multi-GPU server, though actual throughput still needs testing. Pro starts around half a terabyte even in a practical mixed 4-bit conversion. Running it because the weights are available is an engineering project in its own right.

The MIT license makes both options available to self-host. The practical question is where operating the weights is worth the infrastructure cost. On raw token price, Xiaomi’s API leaves little room for a straightforward rental comparison.

Sources and methodology

Sources were checked September 24 to 25, 2026. Xiaomi’s model cards and announcement are the primary sources for architecture, licenses, deployment commands, and vendor benchmarks. Memory and cost figures are labeled estimates or direct calculations rather than official minimum requirements.