The MiMo recipes arrived.

The most interesting MiMo-V2.6 number this week doesn’t come from Xiaomi. On Wednesday this feed re-checked the download counters and closed with a watchlist: builds existed, receipts didn’t. What arrived since isn’t benchmark tables — it’s complete serving recipes, published one after another for almost every machine class that can hold this model, each with measured numbers and a public ledger.

The counters, quickly, as context rather than story (HuggingFace API, this evening): MiMo-V2.6-Flash-RL at 18,821 downloads, Pro-RL at 9,841, the 9B distill at 5,705, with bartowski’s 9B GGUF at 36,718 and the official Flash-RL GGUF at 4,746. What changed since Wednesday isn’t the counters — it’s that “watch, don’t set up” now has a measured counter-offer for nearly every shape of machine.

The anchor recipe: Flash-RL on two Sparks

tonyd2wild’s recipe (created late Monday, 43 stars) serves Flash-RL — a reported ~310B-total MoE with roughly 12–15B active per token depending whose figure you read, MXFP4 experts, fp8 attention, a 1M-token window — on two DGX Sparks with vLLM tensor-parallel-2 and the checkpoint’s bundled DFlash drafter. The repo’s own phrase is “nothing on this page is a projection,” and the tables back it: 53.3 tok/s on a single stream, 155.8 tok/s aggregate across six streams, first token in 0.37 s. The part most demos skip is measured too: prefill runs 1,947 tok/s on a 2K prompt and falls to 656 on a 248K prompt — six and a half minutes to read a quarter-million tokens before the answer starts. Needle-in-a-haystack at 100K and 250K tokens came back exact at three depths each.

For the model-card skeptics, the load-bearing line: text, images (sixteen per request), video and audio input are all verified end to end on GB10. That answers the engine-completeness question for one stack — the card’s multimodal claims are real, in vLLM, on this hardware, today.

Two findings are worth the price of the whole post. First, KV math: the fp8 KV cache pools 1.87M tokens in about 13.9 GiB — six simultaneous 300K-token requests on one pair — while bf16 KV runs the same bench within noise on speed but pools 560K tokens. fp8 KV buys 3.3× concurrency for free. Second, the drafter is category-dependent: DFlash accepts 6.85 of its 7 draft tokens on structured output but 0.83 on narrative prose — which is exactly why per-stream prose decodes around 26 tok/s while machine-checkable output hits 88. Speculative decoding isn’t one number.

And the fleet-shape lesson: on four Sparks the author runs two independent TP2 pairs, not one TP4 instance — the TP4 switch experiments sit in the repo, measured and rejected. Extra Sparks buy parallel instances, not width.

The re-quant that beat the checkpoint

r0b0tlab’s recipe (published 24 Sep) re-quantizes Flash-RL’s routed experts from MXFP4 to NVFP4 — calibrated export, zero runtime source patches, SGLang nightly on the same two-Spark shape — and benchmarks against the official checkpoint on identical hardware: median 69.1 vs 56.9 tok/s per request at batch 8 (+21% decode), at a perplexity delta of 0.0027 and GSM8K-200 with thinking off at 0.965 vs 0.970. A quant release that leads with fidelity numbers instead of tok/s is rare enough to note on its own.

Label it carefully: one rig, one day old, the weights mirrored to HuggingFace hours ago (the checkpoint’s counter reads zero — batch lag, not a demand verdict). Treat it as a public ledger awaiting replication, not a settled result. If it replicates, the default MiMo build for Blackwell-class unified-memory boxes changes.

The 1.02T flagship gets fleet recipes

Pro-RL — the reported 1.02T-total, 42B-active flagship — doesn’t fit a pair, and it got two routes this week. drowzeys’ four-Spark recipe (created 24 Sep) runs Jarrelscy’s ARVQ/NVFP4 hybrid quant: a small hot set of experts in NVFP4, the rest as residual-vector-quantization codebooks — which is what squeezes a 1.02T model across four 128 GB boxes at full tensor-parallel width with the entire 1,048,576-token context live (measured KV pool: 2.25M tokens). Speed is honest rather than flashy: 18.6 tok/s single-stream prose at a 33K prompt, 45.0 tok/s with four requests in flight. Hermes tool-calling is verified there, including an actual read_file round trip. Two flags from the same README: the quant’s author marks full-model quality as unqualified — nobody has measured what ARVQ costs — and the live serve is text-only; the vision endpoint was down at verification.

rhys101 took the other route: the checkpoint’s native shape on eight Sparks with a patched SGLang at TP8, measured 24 Sep — mean 69.1 tok/s per stream on a single batch across eight task categories, 190.8 aggregate at batch 8, and a repeatable long-extraction run at 306.7 tok/s end to end.

Arithmetic from their printed aggregates — different benches, so treat it as shape rather than gospel: Flash-RL delivered ~156 tok/s aggregate on two Sparks; Pro-RL ~191 on eight. Per Spark, roughly 78 vs 24 tok/s. The 310B model is the fleet-efficient MiMo by about three to one; the flagship is what you deploy when the job needs the full million-token window and you have the lanes to spare.

No fleet at all? SSHdotCodes serves Flash-RL on a single RTX PRO 6000 with about 96 GiB of pinned host RAM — the 4,096 hottest experts resident in VRAM, the rest fetched behind a GPU cache — at ~74 tok/s short-context coding, 71 tok/s at 131K context, and a 29-second cold prefill of 131K tokens; updated twice this week. Jarrelscy’s four-PRO-6000 build pushes the same model to 1M context on custom b12x kernels: 344 tok/s single-stream on code and a 13.5M-token KV pool.

Three traps, before you set up

The DeepGEMM landmine. DeepGEMM issue #417 (open since August) documents that on SM12x-class GPUs the pure-fp8 kernels were removed and fp8 calls silently alias to an fp4 dispatcher — corrupted math, no error. Every working recipe in this post turns DeepGEMM off and runs Marlin MoE kernels. If MiMo output looks subtly wrong on a Spark, this is suspect number one.

The sampling storm. Coding agents typically send requests with no sampling parameters, and vLLM’s near-greedy defaults push this model into repeating one tool call hundreds of times inside a single response — the recipe authors measured turns with 148 and 446 identical grep calls, and 44-minute turns. The fix is two flags: serve with the checkpoint’s own generation config (temperature 1.0, top_p 0.95) plus a 1.05 repetition penalty. A separate Spark-pair field report (r/LocalLLaMA, verified 23 Sep) matches: three fixable serving bugs, no core-model problem. Part of MiMo’s “terrible with tools” reputation appears to measure serving defaults, not intelligence.

The engine-completeness check. vLLM and SGLang are the only local engines serving Flash-RL’s full input set this week. The MLX packs are text-only or plain repo mirrors — the 9B OptiQ build ships with its vision config stripped outright. llama.cpp carries the vision and audio encoders in its mmproj but excluded the audio decoder from conversion, and MTP speculative loading still fails per its own conversion discussion. Card claims ≠ served features; this week the CUDA stacks are the complete ones.

The Mac question

On paper a 512 GB Mac is the natural Flash-RL host: the official MXFP4 GGUF is 155.87 GiB, its vision mmproj 1.46, and the recipe’s own pool math prices fp8 KV near 8 bytes per token — about 7.5 GiB for the full million-token window. Call it 165 GiB resident, over 330 GiB spare. Memory isn’t the obstacle; the missing piece is a measured Mac recipe. MLX can’t serve the vision path, and nobody has published long-context llama.cpp numbers at this size — every proven path this week runs vLLM or SGLang over RoCE, which is cluster hardware, not a desktop. Verdict: watch, don’t set up. The MiMo that actually runs on a 512 GB Mac today is the 9B distill — ggml-org’s Q8_0 GGUF is 8.87 GiB plus a 0.58 GiB vision mmproj.

The 9B also picked up its first independent deep-context study this week: Manglobite ran it at the native 262,144-token context on two CMP 50HX mining cards and a 2080 Ti — 2018-era Turing silicon — under llama.cpp. Prefill decays smoothly (1,226 → 287 tok/s as fill grows from 10% to 80%), decode from 42 to 22 tok/s: no cliff, no OOM — and, the useful negative, the known qwen35-hybrid deep-context collapse (llama.cpp #29172) did not reproduce on their build. KV ladder included: f16 cache was slightly faster than q4_0 or q8_0 but cost 8 GiB versus 2.3. Inference metrics only — no quality evals — but “no collapse at 262K on 2018 GPUs” is a real datapoint for anyone planning long agentic sessions on the small MiMo.

One more, for the image side

Viggle, building with Qwen, shipped v0.2.1 today of a few-step distilled LoRA for Qwen-Image-2.1: distribution-matching distillation down to six transformer passes instead of forty, no classifier-free guidance, a 1.3 GB rank-256 adapter (680 MB at rank 128), ComfyUI workflows included — 12,425 downloads in three days. The speed claim is concrete; the fidelity half isn’t: the repo publishes no before/after quality eval against the 40-step base, so this is try-the-demo, not swap-your-pipeline. It’s the step-distillation pattern arriving on an image stack — the thing that would make it news is the fidelity table, which doesn’t exist yet.

Harness, briefly

Hermes shipped v0.21.5 (v2026.9.24) today — a rollup tag of roughly 460 PRs since v0.21.4: the Desktop plugin SDK wave, a Connectors page replacing the MCP tab, Simple/Advanced interface mode; curated notes deferred to v0.22.0. llama.cpp has been quiet on MiMo since v0.5.0’s conversion support: tonight’s sweep of b11155–b11174 found nothing MiMo-relevant.

Download counts from the HuggingFace API this evening (batch-updated aggregates — likes tick live, downloads move in batches). All recipe performance numbers are the recipe authors’ own measurements from their public ledgers; the NVFP4-vs-MXFP4 comparison is single-rig and awaiting replication. Vendor and author claims labeled as such. No private infrastructure referenced — hardware classes only.