MiMo Pro on Eight Sparks: Scheduling, Rates and Regression Scores

43908/187.18 s vs 43900/143.16 s. Whole-wave wall includes prefill; this is not a 128K test.

The eight-Spark MiMo-V2.6-Pro-RL deployment provides more than a fast decode headline. Its most interpretable comparison preserves a scheduler failure, cold-cache request bodies, completion totals, complete-wave wall time and answer checks across builds a13 and a14. That makes it useful for understanding concurrency behavior. It also shows why a workload called “long extraction” should not automatically be filed as a huge-input context test. Run AI Here has not run these model benchmarks or rented additional hardware.

What the eight-node recipe requires

The publisher identifies XiaomiMiMo/MiMo-V2.6-Pro-RL, described as a 1.02T-total, 42B-active MoE, at checkpoint revision 73875d00b30a89ef8cc353a0b60b0e9f9561952d. Eight GB10 nodes use TP8 with EP1, two switched 200G RoCEv2 subnets and MTU 9,000. Each node has a full local weight copy; rank-local weight fit and total disk size are separate from peak runtime unified memory. The source's roughly 66–69 GB weights per rank is not a measured peak.

The runtime is a patched SGLang with packed MXFP4 experts on Marlin W4A16, FA4 prefill/verify and DFlash8 with adaptive verification width. Optional FP8 output projections and draft components are part of the measured profile. These details mean “MXFP4 deployment” does not imply all arithmetic is 4-bit, and “eight Sparks” alone does not describe the communication topology. A two-node machine or an Ethernet setup without the stated fabric is another recipe.

The version lock records base SGLang 06008c170dae333e22caceb51f36224071f9b5b3 and the model revision. A base commit does not fully identify a patched executable tree. The a14 local image ID is retained separately from the base-image digest; a portable distribution digest and a13 executed image ID are not reported. Those nulls are more useful than attaching a14's image to older measurements simply because it is the current serving build.

The short table and the paired extraction use different rates

The September 24 a13 table reports coding decode at 91.1 tokens/s for C1 and 42.3 per stream at C8. Its all-eight-category C8 aggregate is 190.8 tokens/s. The arithmetic mean across category rates and aggregate tokens divided by group wall time have different denominators. Multiplying a published mean by eight is not a reconstruction of the aggregate. Output length, acceptance behavior and task category also change which rate a user experiences.

The source warns that individual short requests can move substantially between builds. That is a variability warning, not an estimated confidence interval or proof that every apparent gain is statistically established. The cold structured-extraction comparison is a more inspectable scheduling case because its original logs retain actual output counts and wave timings.

The eighth request was queued by slot accounting

Build a13 counts a request finishing its final prefill chunk against a request slot that it already holds. In the affected batch, seven streams run while the eighth waits until another finishes. Build a14 changes that scheduler accounting. The report's explanation is bounded to this path; it is not proof that all queueing in SGLang or all long-context failures have been fixed.

These values come from the a13 raw waves and a14 raw waves. The output totals are close but not identical, and both arms meet the fixture's answer check. The improved aggregate accompanies a lower arithmetic per-stream mean. That is possible because the long queued tail changes the complete-wave denominator, while averaging individual stream rates weights the requests differently.

Do not multiply the arithmetic mean by eight or combine separate denominator definitions.

The worst retained first-token observation falls from 46.39 seconds to 8.17 seconds. This explains the source's rounded 46-to-eight-second description without inventing p95 latency or a distribution of production traffic. Three waves are finite repeated fixtures, not a sustained unattended service test.

Long extraction is principally a long-output task here

The C8 harness duplicates four CSV-to-JSON tasks per wave, uses temperature zero, seed 20260922, thinking off and a 4,096-token output cap. It supplies a unique cache salt, flushes prefix cache before each wave, consumes completion usage and requires both normal stop and an exact parsed-JSON oracle match. This is stronger evidence than HTTP success alone, while still covering only those fixtures.

The C1 raw log records 1,498 input tokens on every request, with about 1,829 output tokens. Twelve requests pass, with 21,952 completion tokens over 209.86 seconds and 104.6 end-to-end tokens/s. The C1 method explicitly obtains the final tuple field from usage.prompt_tokens. C8 logs omit prompt counts, so those stay unknown even though they use the related fixtures. Neither table is a 128K-plus concurrent-input experiment.

Separate a13 cold-prefill medians use source labels 5K, 20K, 81K and 163K, three repeats and a unique prefix. Selected rates are 1,880 tokens/s at nominal 5K and 1,499 at nominal 163K. Exact per-cell input counts are not supplied in the selected summary. These prefill screens should not be mixed with decode-only rates or used as a missing peak-memory trace.

Keep the score's build, prompting and wrong answers

The a13 GSM8K result has 196 correct of the first 200 fixed-order test questions: 98.0 percent on that subset. Failed IDs are 93, 119, 162 and 187. The scoring method uses zero-shot brief-working prompts, greedy generation with thinking off, a 1,024-token output cap and a custom numeric extractor with a last-number fallback. Its default concurrency is eight, but the saved result does not establish the executed command's concurrency.

Needle results at 127,803 and 244,168 tokens belong to older a5/a6 builds, not a13/a14.

This is a regression check between kernel/backend choices. It is not a full GSM8K leaderboard score, nor comparable to an eight-shot thinking-enabled subset without a matched protocol. There is no a14 GSM8K rerun in the selected evidence. The scheduler fix's 24 correct extraction answers do not fill that missing task rerun.

Older needle checks do not automatically follow the current image

Three-fact needle results at 127,803 input tokens belong to a5/a6, while 244,168 belongs to a5. Mixed-workload success is also documented on older builds. Current a14 finite smoke checks include text, reasoning split, tool use and a simple image task; audio and video are not validated. These are useful capabilities and gaps, not permission to move an older long-context result onto every subsequent build.

Image ID, base image digest and the actual patched engine revision are separate provenance fields.

For deployment planning, the missing next evidence is clear: a14 long-input concurrent tests with actual per-request token counts, synchronized correctness, GPU/unified and host-memory telemetry, and a rerun of the task panel. Retaining the initial scheduling defect and its exact retest makes that next test concrete. A static evidence page can then show what changed, what passed and what remains unmeasured without building an elaborate serving backend or inventing a universal model score.