MiMo-V2.6-Flash-RLbenchmark results

Measured speed and quality

Speed (single user)

Source: fleet-bench/2026-09-25-dgx1-best-model-eval.md, fleet-bench/2026-09-23-gb10-tp2-spark34-mimo-v26-flash.json, ai11/RESULTS-2026-10-13-model-sweep.md

Aggregate throughput

Source: fleet-bench/2026-09-25-dgx1-best-model-eval.md, fleet-bench/2026-09-23-gb10-tp2-spark34-mimo-v26-flash.json

Prefill and latency

Source: fleet-bench/2026-09-25-dgx1-best-model-eval.md

Context

Source: fleet-bench/2026-09-25-dgx1-best-model-eval.md

Other measurements

Source: fleet-bench/2026-09-25-dgx1-best-model-eval.md, ai11/RESULTS-2026-10-13-model-sweep.md

# MiMo-V2.6-Flash-RL

What it is

MiMo-V2.6-Flash-RL is Xiaomi's mixture-of-experts model, published under the XiaomiMiMo account with an MIT license and served as MiMo-V2.6-Flash-RL. It is an MoE architecture (MiMoV2ForCausalLM) that keeps a large total parameter count while activating a much smaller slice per token, which is why it can carry a very large verified context window on one GB300 while staying responsive for a single user. We measured it in three places on our own fleet: a two-node GB10 pair, one DGX Station GB300, and a Ryzen AI Max+ mini PC. It is the same checkpoint the fleet already runs in production on FP8 accelerators, so existing parsers, prompts and agent flows carry over unchanged.

The released weights are large on disk (the official copy we benched is large on disk, split across nodes when sharded), so the practical question for an IT lead is not whether the model is good, but which of your machines can actually hold it and what trade each configuration makes. The sections below walk through every configuration we measured, including where it is genuinely slow and where it failed outright.

Where it runs best

The clearest result in our data is the gap between one GB300 and everything else we ran it on. On dgx1, one GB300 with FP8 compute and an mxfp4 weight store served 212 tok/s to a single user and scaled to an aggregate of 4,941 tok/s at the very top of the ladder, with a verified context of 971,072 tokens passing three needle checks at three depths. Nothing else on our fleet comes close for this model. If you have one large-memory accelerated workstation or server, this is where MiMo belongs.

The two-node GB10 pair is the honest middle option. With tensor parallelism across two Spark units over the 200G RoCE fabric, a single stream reads about 26.6 tok/s aggregate at concurrency one, which is usable for one patient reader, and it peaks at 205.4 tok/s aggregate at 32 concurrent users. That is a team-level throughput, not a snappy desktop experience: per-stream speed falls from the high-twenties per stream at one user down to single digits at 32.

On Strix Halo it is the opposite story. The model is accurate on the 60-item battery (36 of 40 on MMLU-Pro and a perfect 20 of 20 on HumanEval), but it decodes at only 20 tok/s, and the MTP speculative variant ran the machine out of RAM and froze it. We do not recommend this model on that class of hardware except for batch work where the operator can wait.

Measured speed

On one GB300 (dgx1, vLLM, FP8 weights with mxfp4 storage, bf16 KV cache), a single user sees 212 tok/s of prose decoding. Aggregate throughput at 32 concurrent users is 1,995 tok/s, and the ceiling run reached 4,941 tok/s aggregate at the engine's max sequence cap, the highest of the five Flash-class candidates in that eval. Prefill is strong: 47,439 tok/s at an 8k prompt, 47,044 tok/s at 32k, and 30,726 tok/s at 128k, so long documents ingest fast even before generation starts. That prefill profile matters for the way this model is best used: a compliance or contract pipeline that ingests a hundred-page document pays only a couple of seconds of ingestion before the first token, and the speed at 128k still exceeds what most mini-PCs manage at a few hundred tokens. The context-verification runs (three needles inside prompts approaching the full window, each finishing in roughly two minutes) confirm that the long window is real under load, not a spec-sheet claim. One serving caveat from the same eval: the ceiling is set by the engine's max sequence cap, so raising concurrency beyond what we measured requires raising that cap and re-measuring, not assuming the ladder extrapolates.

On the two-node GB10 pair (spark3 and spark4, TP2 over RoCE, vLLM, FP8 w8a8, fp8 KV cache), the concurrency ladder starts at 26.6 tok/s aggregate with one user and climbs steadily with concurrency, peaking at 205.4 tok/s at 32 users. At 48 users throughput falls back as time to first token climbs past 40 seconds at the tail, so treat 32 users as the practical knee on that pair. In practice that means one pair can back a small team's shared assistant for summarization and drafting, as long as nobody expects interactive single-stream speed: at sixteen users each stream is already reading in the single digits per second, so batch-style workloads (classification, extraction, report generation) fit this configuration far better than live chat. The fp8 KV cache on this pair is generous for short prompts but worth checking if every request carries large documents. The engine ran with a 65k max model length and chunked prefill enabled, and the weight set occupies roughly 83 GiB on each node, so neither unit has much memory left to grow the KV allocation. This run had speculative decoding off; the dflash experiment on the same pair produced much worse aggregate numbers and a multi-second first-token wait, so we do not recommend it.

On four GB10 units (msi1 through msi4, TP4), the recorded numbers are a floor, not a real result. MiMo's NCCL RDMA initialization failed on all four nodes even though Qwen and GLM ran TP4 over the same fabric in the same session, so the measurement fell back to TCP and single-stream decoding collapsed to a small fraction of the working RDMA pair's speed. The four-node run proves the model fits and answers correctly at that width, but it must not be compared against the fabric-backed rows of other models. Separately, MiMo's FP8 block-scale layout keeps its 128-element scales aligned only at TP1 and TP2; TP4 and TP8 hit a CUTLASS invalid-status crash that needs the triton linear backend as a workaround.

On Strix Halo (ai11, llama.cpp Vulkan, MXFP4), expect 20 tok/s. That is slow enough that the model's excellent battery scores do not rescue the experience for interactive use. The weights are simply too large for this class of machine to decode quickly, and the MTP speculative variant, which would normally be the speed lever on this platform, made things worse rather than better: it consumed the unified memory until the box froze and had to be excluded from the data. An operator who already owns this hardware and needs the model's accuracy for an overnight batch job can tolerate the speed, but for anything interactive the right move on Strix Halo is a smaller model.

Quality and accuracy

Quality is the strongest reason to consider MiMo despite its quirks. On dgx1 with vendor sampling it scored a perfect 38 of 38 on the tool-calling set and 15 of 15 on the agent set, 9 of 10 on code, 3 of 3 on writing, and 22 of 26 on the long-context set, for an the top tool scorecard in its class with a nonzero hallucination rate on the multi-turn corpus on the multi-turn corpus. HumanEval pass@1 was 97.0% with vendor sampling and it went 20 of 20 on the Strix Halo battery, so code generation is dependable at both ends of the fleet.

The weakness is compliance knowledge. Closed-book, it answered 16 of 35 CMMC items with vendor sampling, and that number dropped to 12 of 35 at fixed temperature, so it should always retrieve from your own document set rather than answer from memory. The same eval scored its writing set at 3 of 3 with strong judge marks, so it is a capable writer when the facts are supplied. Its needle behavior has a specific failure mode worth knowing: in every one of its needle failures it refused to return an embedded fact, treating it as an injection. That prompt-injection reflex is defensible for security work but it also blocks legitimate retrieval, so test your own retrieval prompts before deploying. A separate quirk: the model writes with non-breaking hyphens, which our content pipeline now flags because publishing tools mishandle them; strip them in post-processing if you feed its output into a CMS.

How we ran it

On dgx1 we served the official XiaomiMiMo checkpoint under vLLM with FP8 compute and mxfp4 storage, bf16 KV cache, chunked prefill and prefix caching enabled, the mimo tool and reasoning parsers, and a single-rank setup on the 252-class HBM3e card. The concurrency ladder ran with distinct prompts per request so no prefix cache could flatter the numbers, and the ceiling run walked concurrency up to the engine's max sequence cap. Context verification used needle searches at three depths in prompts approaching the full window, and 3 of 3 passed at 971,072 tokens.

On the GB10 pair we used vLLM with tensor parallelism 2 across two Spark units over the 200G RoCE fabric with fp8 KV cache, the marlin MoE backend, chunked prefill and prefix caching, speculative decoding off, distinct prompts, and page caches dropped before launch. The TP4 attempt used the same stack on four nodes and recorded its TCP fallback plainly. On ai11 we ran llama.cpp Vulkan with the MXFP4 quant, thinking off, and the standard 60-item battery; the MTP variant of that run froze the machine and is excluded from the data.

When to pick it

Pick MiMo-V2.6-Flash-RL when you have one large-memory box (GB300 class) and your workload is agentic: heavy tool calling, long documents, multi-turn workflows. It has the best aggregate ceiling of the Flash-class candidates we measured, cleanest tool and agent scores, near-perfect code generation, and a verified context approaching a million tokens. Teams writing retrieval pipelines should prototype carefully because of the injection-refusal behavior, and compliance workloads should pair it with a RAG setup rather than trust closed-book answers.

Pick something else when the budget is GB10 units only and users need snappy single-stream responses: the TP2 pair is throughput-oriented, and TP4 is not usable in practice for this model. On Strix Halo, choose a faster model; the battery scores do not compensate for a 20 tok/s decode.

Operationally, plan around three facts from our runs. First, memory headroom is thin everywhere except the GB300: the pair splits the weight set roughly in half per node, and the four-node layout needs the triton linear backend workaround, so a GB10 deployment of this model is a fixed configuration, not something to resize casually. Second, the fabric matters more for this model than for the Qwen and GLM checkpoints we measured on the same nodes: MiMo's NCCL RDMA path failed at TP4 in our session while those models ran on the same links, so budget extra integration time if your layout is wider than two nodes. Third, treat the injection refusal as a behavior to engineer around rather than a defect: put your facts in tool results or clearly attributed document blocks instead of inline instructions, and the failure mode largely disappears.

Where to go next

• LLM benchmarks hub
• Leaderboards
• How we measure
• Model tier list
• Private AI solutions
• Private LLM guide
• CMMC compliance

FAQ