MiMo-V2.6: Scaling Reinforcement Learning from Scratch
Building Xiaomi's MiMo-V2.6 RL recipe from the ground up — the importance-sampled GRPO objective, group-relative advantages and dynamic sampling, hack zeroing, Groupwise Reward Synthesis, Groupwise Advantage Redistribution, the group-relative length penalty, mass-conserving segment penalties, top-p candidate replay, router freezing, and the Little's-law Sample Mixer — all derived step by step on one four-rollout coding group.
Xiaomi’s MiMo-V2.6 report (LLM-Core Xiaomi, 2026) is about one idea: spend much more compute on reinforcement learning, and do it without the run falling apart. The flagship MiMo-V2.6-Pro, a 1.02T-parameter Mixture-of-Experts model with 42B active parameters, spends $2.6M on RL alone. Each training step consumes 25,088 trajectories and up to 3.7 billion tokens, at context lengths of up to 1M. Its DeepSWE v1.1 score rises from 58.4 to 72.6 over the run.
Scaling like this breaks things that work fine at small scale. A binary “tests passed” reward cannot tell a clean patch from a sloppy one. Agents learn to download the upstream fix instead of writing it. Responses grow longer every step. The MoE router drifts until a few experts handle all the traffic. A token sampled with top- at inference gets a different probability at training time, even with identical weights. The report fixes each of these with a small, precise mechanism, and most of them are a few lines of algebra on the advantage vector.
This post re-derives each of those mechanisms. We use one running example: a single coding prompt with a group of four rollouts. We put every mechanism through that group and check every number by hand.
The Running Example
The prompt is a repository-repair task: “Fix the KeyError raised by parse_config when the timeout field is missing.” The policy generates a group of candidate solutions. A rollout (or trajectory) is one complete attempt: every model turn, tool call, and tool result from start to submitted patch. Our four rollouts are:
| Rollout | What it did | Tests | Length (tokens) |
|---|---|---|---|
Adds a default timeout=30 in the right place; runs the tests | pass | 10 | |
Wraps the whole function in try/except KeyError: pass; tests pass by accident | pass | 20 | |
Runs curl on the upstream file, copies the published fix | pass | 12 | |
| Edits the wrong function | fail | 16 |
The real MiMo run uses and trajectories of roughly 110K–150K tokens. We shrink both so every sum fits on one line. The lengths are toy numbers, but the relationships between them are what matter.
The binary test reward is if the tests pass and otherwise, so
Look at what this vector hides. Rollout is the solution we want. Rollout is a patch a maintainer would reject. Rollout cheated. The binary reward gives all three the same score. Most of the MiMo-V2.6 RL recipe is about pulling these three apart.
1. Mathematical Setup
Earlier posts in this series built most of the tools we need from scratch. We link to them and recall only what we use:
- Expected value, the sigmoid with its derivative , and the log trick are derived in Mathematical Prerequisites for Reinforcement Learning.
- The policy gradient theorem and REINFORCE are derived in Reinforcement Learning from Scratch.
- Top- routing, expert load, and expert collapse in Mixture-of-Experts are built in MoE Load Balancing from Scratch.
We need one tool those posts do not derive: the importance sampling form of the policy gradient. MiMo generates rollouts with an older copy of the policy and trains a newer one. The gradient must correct for that mismatch.
The importance-sampled policy gradient
Let be the policy we are training and the behavior policy that actually generated the data. The two differ because rollouts were sampled a few updates ago, and because the inference engine and training engine compute slightly different numbers. We want the gradient of
where is a fixed score for outcome (the advantage, defined in Section 4). The advantage does not depend on , so by linearity of differentiation:
We cannot sample from , because our samples come from . So we multiply and divide each term by , which is allowed wherever :
Now apply the log trick, :
The last step reads the -weighted sum as an expectation under . The factor
is the importance sampling ratio. This is the importance sampling identity: an expectation under one distribution equals a reweighted expectation under another.
Numerical check. Shrink our group to two outcomes, “pass” and “fail”. Let the current policy pass with probability at , so . Let the stale behavior policy pass with . Take and .
Direct gradient. , so .
Importance-sampled gradient. For “pass”: , and the ratio is . The term is . For “fail”: , and the ratio is . The term is . The two minus signs cancel. The sum is .
Both sides give . Sampling from the wrong policy is fine as long as we multiply by .
2. The Foundation RL Starts From
RL can only reinforce behavior the model sometimes produces. MiMo-V2.6 spends its pre-RL budget making that exploration space large and making long rollouts cheap.
Backbone. MiMo-V2.6 is a sparse MoE Transformer. It stacks hybrid blocks, each made of Sliding Window Attention (SWA) blocks followed by one Global Attention (GA) block. In SWA, a token attends only to the previous tokens. In GA, it attends to the whole prefix. The very first block uses GA with a dense feed-forward network to stabilize early representations. Every other block uses a sparse MoE FFN without shared experts. The two models are configured as follows:
| MiMo-V2.6-Flash | MiMo-V2.6-Pro | |
|---|---|---|
| Layers (total / SWA / GA) | 48 / 39 / 9 | 70 / 60 / 10 |
| Hidden size | 4096 | 6144 |
| SWA heads (Q / KV) | 64 / 8 | 128 / 8 |
| GA heads (Q / KV) | 64 / 4 | 128 / 8 |
| Head dims (QK / V) | 192 / 128 | 192 / 128 |
| Experts (total / active) | 256 / 8 | 384 / 8 |
| Parameters (total / active) | 310B / 15B | 1.02T / 42B |
(The report’s Table 1 prints Pro’s active count as “42T”; the text and abstract give 42B.)
Why the hybrid matters for RL: a KV-cache derivation. The KV cache stores each layer’s keys and values for every past token, so decoding does not recompute them. For one token in one layer it holds (number of KV heads) (key dim + value dim) numbers. For Flash:
A GA layer keeps this for all tokens. An SWA layer keeps it for at most tokens, because older tokens are never attended again. At :
A hypothetical all-GA Flash with 48 layers would need . The ratio is , so the hybrid cache is about smaller. The SWA layers contribute only 0.1% of the total. This is what lets thousands of long agent rollouts fit in GPU memory (HBM) at once. The same window bound makes context parallelism cheap: an SWA layer only needs to exchange the 128 keys its queries can reach, whatever the sequence length.
Encoders and drafter. A 681M-parameter MiMo-ViT uses sink-augmented SWA. It alternates row-major and column-major token order so information spreads along both image axes, and inserts a GA layer periodically. It was pre-trained on over 4T image tokens by pairing it with a small trainable LLM under a plain cross-entropy loss. Audio goes through a tokenizer that produces 25 frames per second, each frame being 20 discrete residual vector quantizer (RVQ) codes. A patch encoder then sums the 20 code embeddings per frame and merges every 4 frames into one backbone position, so positions per second. A 5-layer SWA DFlash block-diffusion drafter predicts 7 tokens per forward pass for speculative decoding.
Pre-training and mid-training. Flash sees 48T tokens (26T text-only, then 22T omni-modal). Pro sees 30T (27T + 3T). Context grows from 32K to 256K. An agent-centric mid-training phase then trains on realistic agent trajectories in coding, general, visual, and research tasks, first at 256K and finally at 1M context. Three choices in this phase are aimed directly at RL:
- Optimizer switch. AdamW adapts each parameter separately. Muon instead orthogonalizes the update of each weight matrix and stays data-efficient beyond the batch size where AdamW’s gains flatten out. MiMo switches the hidden matrices to Muown, a Muon variant with explicit row-norm control. Embeddings, the LM head, and the router stay on AdamW. Prior work warned that moving an Adam-trained model to Muon causes mismatch. MiMo reports no loss spike.
- MXFP4 quantization-aware training, so the experts can later be served in 4-bit during rollout.
- Anti-hacking data: early trajectories that reward-hacked are rewritten so the model notices the faulty reasoning, fixes that turn, and continues honestly. We return to this in Section 6.
3. The RL Objective, Term by Term
MiMo-V2.6 trains with Group Relative Policy Optimization (GRPO). For each prompt drawn from the union of task datasets , the rollout policy samples a group . The loss is
Each symbol is something we have already met or can pin down on our group.
The token-level ratio . Section 1 used a ratio over whole outcomes. MiMo computes it per token, with a stop-gradient :
The stop-gradient treats as a constant during backpropagation. The gradient of one term is then
which is exactly the importance-sampled term from Section 1, applied token by token. The numerator comes from the training engine. The denominator is the probability the inference engine reported when the token was generated. For partial rollouts (Section 5) it is not recomputed.
The mask . PPO clips the ratio. MiMo instead drops tokens whose ratio is out of range, using four separate bounds:
Both intervals start at . Suppose a token in (which will have ) had and . Then and : the token trains. Had the policy drifted to against , then and : the token contributes nothing. The bounds are then tuned while training runs, based on policy entropy. If entropy is too low, the positive interval widens and the negative one narrows, which lets more positive updates through. If entropy is too high, the opposite happens.
The normalizer: prompt-mean aggregation. The averages over the tokens of one group. The outer expectation then averages over prompts. Each prompt gets equal total weight whatever its length. Compare token-mean aggregation, which divides every token by the total token count of the whole batch. There a prompt’s share of the gradient is , which grows as its rollouts get longer. For our group, . Under prompt-mean, each of its 58 tokens is weighted and the prompt’s share is fixed. Under token-mean, doubling every rollout would double this prompt’s share of the update. The report adopts prompt-mean because it “prevents response length from growing too quickly.”
That leaves , the only place where the reward enters. Everything in Sections 4–10 is about computing it.
4. Group-Relative Advantages and Dynamic Sampling
The advantage tells the update how much better a rollout did than the others. GRPO needs no value network: it uses the other members of the same group as the baseline. MiMo takes the plain difference from the group mean, without dividing by the standard deviation:
Advantages sum to zero. Summing over the group,
The in front cancels the inside the mean. We will rely on this property repeatedly.
Numerical check with raw test rewards. , so and
This is already a problem. The cheater gets the same as the clean , so every update makes copying upstream fixes more likely. Sections 6–8 fix this.
Why all-pass and all-fail groups are discarded. Suppose the prompt were easy and all four rollouts passed: . Then and every . Every term in the loss has the factor , so the group contributes exactly zero gradient. The same happens with . Such groups still cost rollout compute and take batch slots while teaching nothing. MiMo’s dynamic sampler (from DAPO) filters them out and keeps sampling until the batch is filled with mixed-outcome groups. This filter comes back in Section 14: it makes each data source’s acceptance rate unpredictable, which the Sample Mixer has to handle.
5. Scaling Training Compute
The report scales RL along three axes: training compute, environments, and grader compute. First, the raw numbers for training compute.
Batch arithmetic. Each step samples 1,568 prompts with :
At 2.7B–3.7B training tokens per step, the mean trajectory is
which matches the report’s “roughly 110K–150K tokens per sequence.”
Where the money goes. RL post-training cost $2.6M for Pro and $0.9M for Flash. For Pro, rollout takes 43.8%, training 43.5%, and the grader 12.7%. For Flash the shares are 44.9%, 40.9%, and 14.2%. Over the run, DeepSWE v1.1 average@3 rises from 58.4 to 72.6 (Pro) and from 48.7 to 65.7 (Flash). Pro finished 30 steps in 123.1 hours of wall-clock time and Flash in 81.8.
Why a large batch. Rollouts parallelize over sequences, and training shards the batch across data-parallel ranks, so throughput grows with GPU count. With HBM full of running sequences, decode batches are large and each weight read is used for many tokens. This ratio of compute to memory traffic is called high arithmetic intensity, and it keeps GPUs busy.
Partial rollout and staleness. Agent rollouts have a long tail: a few take far longer than the rest. Waiting for the slowest would idle the cluster. With partial rollout, once enough groups are collected the step proceeds, and in-flight rollouts pause and resume after the update. The resumed rollout then mixes tokens from several policy versions. This is why in Section 3 differs from , and why the importance ratio is essential. MiMo allows a staleness of 4, meaning a token may come from a policy up to 4 updates old. There is a cost: after each update, a resumed rollout must rebuild its KV cache under the new weights (re-prefill). A large batch spreads that cost over more useful work, so batch size and partial rollout are tuned together.
6. Environments and the Multi-Layer Defense Against Reward Hacking
RL tasks span agentic and competitive coding (68%), aesthetic design (13%), general tool use (12%), cybersecurity (4%), and context following (3%). Each domain has its own verifier:
- Code. Tasks come from GitHub pull requests and issues, internal “vibe coding” requests, specification-driven tasks, CodeMidas synthesis from existing codebases, long-horizon tasks, and filtered public and vendor data. Supervision is checked two ways. For accuracy, a coding agent attempts each task 4 times and an auditing agent compares its own judgment of each patch with the observed reward, flagging false positives and false negatives. For robustness, fail-to-pass (F2P) tests must fail before the reference patch and pass after it, pass-to-pass (P2P) tests must pass both times, and both must hold across 8 reruns.
- General. Planning agents build resettable sandboxes from real files and locally mocked software. Tasks are graded by atomic binary rubric items: code checks for deterministic facts, LLM checks for open-ended content. Negative checks catch edits to unrelated files, and adversarial fake solutions test the rubrics. A self-hosted MiMo-V2.6-SFT model is the grader.
- Visual. Open-ended design uses pointwise rubrics plus groupwise comparison of rendered artifacts. Visual replication uses pixel-level similarity plus LLM judging.
- Cyber. The agent must produce an input that triggers a specific OSS-Fuzz vulnerability. A proof of concept is accepted exactly when its sanitizer report matches the ground truth on two strings: the vulnerability type (e.g.,
heap-buffer-overflow) and the topmost project-level stack frame. The check is deterministic and essentially free. The agent gets the compiled harness binary as well as the source.
Reward hacking is earning reward without solving the task. In repository repair, the dominant form is solution leakage: the agent finds the published fix. The report quotes five real patterns: pip install a newer release and read its source, curl the upstream file, git clone the upstream repository, read the issue tracker’s changeset, and pip index versions to probe for newer releases. Our is the second pattern.
MiMo defends in four layers:
- Mid-training alignment data (Section 2) makes the model less inclined to hack in the first place.
- Environment preparation removes build logs, verifier outputs, leftover patches, binaries, and caches, truncates Git history at the base commit, and isolates the container from the network.
- A hack agent attacks each prepared environment, guided by known exploits. Whatever new leak it finds is patched, and the process repeats until it finds nothing in any environment.
- Training-time auditing and hack zeroing. Offline audits keep watching trajectories. Online, the groupwise grader (Section 8) sets a confirmed hack’s reward to zero before the group mean is computed.
What hack zeroing does to our group. The grader confirms fetched the upstream file, so :
The order matters. Had we zeroed ‘s advantage after computing the mean, the mean would still be . Rollout would keep and the group would sum to . Zeroing the reward first makes an ordinary failure: it is pushed down with , and the group still sums to zero. With this correction, the logged share of confirmed hacks stays below 2% for the whole run for both models.
7. Groupwise Reward Synthesis (GRS): Grading Quality Offline
After hack zeroing, and still have equal advantages, each. The binary test cannot see that swallows every KeyError. MiMo adds grader compute to separate them, and does it in two ways, each used on a different subset of code tasks.
Groupwise Reward Synthesis is used on a subset of tasks with high pass rates. Offline, an agent studies several rollouts of the task, together with the specification and repository, and writes two task-specific rubrics:
- Solution rubrics judge the implementation: requirements met, edge cases handled, consistent with the codebase.
- Behavior rubrics judge the process: did the agent gather evidence and check the effect of its changes?
During training, a grader agent enters each rollout’s environment and scores it against these rubrics, producing and . The reward is a product:
Why a product. If , then whatever the rubric scores are. A failing patch can never earn reward by looking tidy. Among passing patches, the rubric scores rank quality.
Numerical check. Say the grader scores as and (clean fix, ran the tests). It scores as and (blanket except, no investigation). With zeroed as a hack and failing:
Check: . The sloppy now lands exactly on the group mean and gets zero advantage. It is neither reinforced nor punished. The clean takes all the positive credit.
GRS rescues all-pass groups. Take only the two passing rollouts as their own group. Under binary rewards this is an all-pass group, and Section 4 showed it gives zero gradient and would be discarded. Under GRS the rewards are , the mean is , and the advantages are . A group that used to teach nothing now carries a signal. This is why GRS targets high-pass-rate tasks: most of their groups would otherwise be filtered out.
8. Groupwise Advantage Redistribution (GAR): Grading Quality Online
All remaining code tasks use Groupwise Advantage Redistribution. For each mixed-outcome group, an SFT-trained agentic grader sees every trajectory at once in a shared workspace: the task, the repository, all patches, and all test outputs. It can read code and run targeted tests. It contrasts passing with failing attempts and ranks the passing patches on five dimensions: suitability of the approach, precision (no omissions, no unnecessary fallbacks), minimality, avoiding unintended effects, and craftsmanship consistent with the codebase. It also confirms hacks, which is where our came from.
GAR keeps the binary reward and rewrites the advantages. Let be the passing set after hack correction and . The grader assigns each passing rollout a quality factor , with for the best. Then:
Deriving the conservation property
We claim the redistribution leaves the total positive mass unchanged. Sum over the passing set, pulling out the common :
The factor in the denominator of cancels the identical sum it multiplies. Failed rollouts are untouched, so the total over the whole group is also unchanged. It was zero before (Section 4), so it is still zero. The ratio of two passing advantages is , so the relative weights set by the grader survive the rescaling.
Numerical check. The grader ranks above : , . From Section 6, and .
Positive mass: . Whole group: . The clean patch now gets twice the credit of the sloppy one, and the failures are exactly as before.
Why not just downweight?
This is the step most readers skip, and the whole design depends on it. The obvious alternative is to multiply passing advantages by and stop. That gives . The positive mass is now while the negative mass is still , so the group sums to . The update is net negative.
Why does net negative pressure matter? A negative advantage lowers the probability of the tokens that were sampled. That probability has to go somewhere, and it spreads over all the tokens that were not sampled, which flattens the distribution. A flatter distribution has higher entropy. Positive advantages do the opposite: they concentrate probability on sampled tokens. When negative mass exceeds positive mass step after step, entropy keeps rising. The report names “excess negative optimization pressure” as a driver of “uncontrolled entropy growth”. The factor restores the balance, and Section 10’s segment penalties are built on the same principle.
The cap and the final re-centering
When the are very uneven, can get large and blow up one rollout’s advantage. MiMo therefore caps (the report does not publish the cap). A capped no longer conserves mass, so MiMo re-centers the group afterwards: subtract the group mean from every advantage, passing and failing alike.
Numerical check with a cap. Take an illustrative cap in place of :
The sum is , so the mean is . Subtracting it:
In the uncapped case the mean is already zero and re-centering changes nothing. The sequence-level is copied to every model-generated token of rollout . Grading runs asynchronously, and if the grader’s output is unusable, the original advantages are used.
Evidence. In code-only RL on Flash (batch 128, token-mean aggregation), runs without GAR saw turns and token counts balloon. More rollouts hit the length limit, and the pass rate stopped improving. With GAR, the pass rate kept rising through step 52 while turn counts stayed roughly flat. Maintainers auditing the no-GAR policy found exactly -style habits: speculative compatibility branches, broad exports, swallowed exceptions, relaxed validation, and evaluation-specific config changes. The GAR policy wrote smaller patches that stayed within scope.
9. The Group-Relative Length Penalty
Longer rollouts cost more and, the report finds, generalize worse. MiMo subtracts a length penalty from successful rollouts that run long relative to other successes on the same prompt. For prompt , let be the successful rollouts. If the group pass rate exceeds a threshold, (a hyperparameter, not the advantage), compute a reference length from a percentile of the successful lengths:
and adjust the reward:
Here is the maximum deduction and the tolerated excess. The penalty saturates once the relative excess reaches . The exponent shapes the ramp, and .
Reading the formula piece by piece.
- is the relative excess. It is for a rollout 25% longer than the reference.
- Subtracting and dividing by maps the excess range onto : no penalty up to , full penalty from on.
- The indicator restricts the penalty to successes. A failure is already at , and making it shorter or longer says nothing about quality.
- The pass-rate gate skips hard prompts, where the model still needs room to explore with long attempts.
Numerical check. The report does not publish , so we pick illustrative values: , (median), , , , . After hack zeroing, and . The pass rate , so the gate is open. The median of under linear interpolation is .
For : . Then , which clips to . No penalty, and .
For : . Then
which lies inside . The deduction is , so .
The adjusted rewards are . The mean is , and the advantages are
The penalty is a reward-side edit, so centering on the group mean still gives a zero-sum group. The padded loses about 10% of its positive credit to .
10. Segment-Level Behavioral Penalties
Outcome rewards credit every token in a rollout equally. Suppose a passing rollout contains a malformed tool call that happened to be harmless. The outcome reward reinforces the malformed call along with everything else. MiMo flags individual tokens: marks tokens in a format violation or tool-call error (malformed markup, invalid tool names, malformed arguments), and otherwise. Across the whole training batch, let be the flagged tokens and the clean tokens (with loss mask ), split by the sign of the owning rollout’s advantage. The token advantage becomes
Each sum runs over tokens, so a rollout with 18 clean tokens contributes its eighteen times.
What each case does.
- Positive rollout. Flagged tokens get , so they are masked: a success never reinforces its mistakes. Clean tokens are scaled up by .
- Negative rollout. Flagged tokens get , a stronger push down. Clean tokens get with , a weaker one.
Deriving conservation for each sign
Positive side. Before the penalty, the positive mass is . After it, the flagged tokens give zero and the clean tokens give . Without clipping, , so
The cancels in the second term. The mass taken from flagged tokens moves to clean ones.
Negative side. For write . Before the penalty, the negative mass is . After it:
Distribute the second bracket. The cancels against the denominator:
Because , this is exactly the original negative mass.
When or is clipped, or a denominator is zero (in which case the scale is set to ), conservation no longer holds exactly, and the report says so.
Numerical check. Use the hack-corrected advantages and treat our group as the whole batch. Say has 2 flagged tokens (a malformed tool call) and has 4 (an invalid tool name). Take , , and (illustrative).
Positive side. : 2 tokens of , so . : 10 tokens of plus 18 of , so 28 tokens and . Then . Mass before: . Mass after: .
Negative side. : 4 tokens of , so . : 12 tokens of plus 12 clean tokens of , so . Then . Flagged tokens get each, for . Clean tokens get each, for . Total , equal to the original .
The invalid tool call in is pushed down twice as hard as before, and the malformed call in is no longer reinforced. The totals on each side are unchanged, so the update is no more negative than before.
Where this lives in the system. These penalties run inside a Penalty Module, which separates detection from effect. A Rule judges a segment, context, or sequence (by hand-written logic or a model judge). It can flag infrastructure failures, garbled tokens, calls to unavailable tools, or repetition. A Strategy decides what to do: mask, shape advantages, or just log. Penalties escalate. A context with no surviving model turns is dropped, a sequence with no surviving context gets zero advantage, and a prompt with no surviving sequence is rejected. An early stop strategy halts a rollout the moment its rule fires and zeroes the outcome reward. Infrastructure failures are masked instead of punished, so the model is never blamed for a crashed container.
11. One Framework: Every Mechanism Edits the Advantage Vector
Sections 4–10 introduced six mechanisms. They are all edits to one vector, the group’s advantages. Each is either a reward-side edit, which changes before centering, or an advantage-side edit, which changes after it:
| Mechanism | Side | Edit | Keeps positive/negative balance by |
|---|---|---|---|
| Group-relative baseline | — | construction: | |
| Hack zeroing | reward | centering after the edit | |
| GRS | reward | centering after the edit | |
| Length penalty | reward | centering after the edit | |
| GAR | advantage | on | the common factor , then re-centering |
| Segment penalties | advantage (per token) | scaling | and conserve each sign’s mass |
Every row keeps the total advantage mass in balance, and none makes the update net negative. Reward-side edits get this for free from mean-centering. Advantage-side edits have to build it in. That is why GAR has and the segment penalty has and . MiMo’s recipe is one rule applied six times: change where the credit goes, never how much credit there is.
12. Training–Inference Consistency: Same Weights, Different Probabilities
The ratio is only meaningful if and differ because the policy changed, not because the two engines compute differently. MiMo runs rollout in SGLang and training in Megatron-LM, and closes three gaps between them.
Top- candidate-set replay
This is the gap that surprises almost everyone: identical weights, identical logits, and still a ratio that is not 1.
Top- (nucleus) sampling keeps the smallest set of most-likely tokens whose total probability reaches , renormalizes over that set, and samples. Suppose that at one step of both engines produce the same full-vocabulary distribution over four tokens:
With : holds , and holds . So the candidate set is . The sampler draws with probability
That is the probability the inference engine records. The training engine, computing a normal softmax over the full vocabulary, reports . The ratio is
even though nothing has been trained yet. Every token sampled under top- carries this systematic bias. The fix is to record each token’s candidate set during rollout and renormalize the training log-probability over the same set:
Moving these sets around is cheap. Only the GPU-to-CPU transfer is dense: a full-vocabulary bitmap of fixed shape, which avoids a GPU–CPU synchronization. Everything after that is sparse, because at MiMo’s typical a candidate set has fewer than five tokens on average.
Rollout Routing Replay (R3)
In an MoE layer, each token picks its top-8 experts by router score. If two experts score and in the inference engine, a tiny numerical difference in the training engine can swap them. The token then runs through a different expert, and is computed on a different network path from the one that produced . R3 records the expert indices chosen during rollout and forces training to use them.
Quantize–dequantize (QDQ)
Rollout runs the experts in MXFP4 with the Humming GEMM kernels. After every parameter update, the training side quantizes and immediately dequantizes the expert weights under the same numeric constraints, so both engines see bit-identical expert weights.
All three records (candidate sets, expert indices, visual inputs) travel with the Context Cache. It persists each dialogue’s KV cache across turns within one policy version, so a new turn only prefills its new suffix. During tool calls it offloads idle state to pinned host memory on side CUDA streams, and it returns the records only when the rollout is collected. RL-adapted block-6 DFlash speculative decoding raises the average accepted length by 31.3% over the inherited MTP-3 drafter. In FP8 it adds about 10.3% per-node throughput.
13. Router Freezing: Stopping Load Collapse
From MoE Load Balancing from Scratch: expert load is the number of tokens routed to an expert, and expert collapse is when a few experts take most of the load. MiMo tracks three statistics of per-step loads with mean :
- Coefficient of variation (CV): , the spread relative to the mean.
- Peak load factor: , how overloaded the busiest expert is.
- Cold fraction: the share of experts with .
Numerical check. Route our group’s tokens through a toy 4-expert layer. A healthy split has . The deviations are , their squares are , the squares sum to , the variance is , and the standard deviation is . So
A collapsed split has the same mean. The deviations are , the squares sum to , the variance is , and the standard deviation is . So
What happened in MiMo-V2.6-Pro. With a trainable router, at decoder layer 9 (384 experts), all three statistics rose steadily over the first 20 RL steps. CV went from 0.78 to 2.0, peak load from to , and the cold fraction from 0.5% to 22%. To find the cause, the team took the step-20 checkpoint and reset only the router to its pre-RL values. Load balance returned to near its starting level, and benchmark scores did not change. So the collapse came from the router drifting, not from the experts degrading. The fix is to freeze the router during RL. The frozen run stays flat (CV , peak , cold ) while scores improve normally.
Even with a frozen router, a single micro-batch can be badly unbalanced. One expert-parallel rank received over the mean token load at one layer and ran out of GPU memory, which forced a parallelism change.
14. The Sample Mixer: Keeping the Task Mix Stable
A mixed-task batch should contain each source in a fixed proportion, say accepted groups per step from source . Sources differ enormously. Across 25 profiled sources, mean generated tokens vary and rollout durations vary . Dynamic sampling (Section 4) discards a source-dependent fraction of groups. If every source got the same number of concurrent rollouts, fast sources would fill their quota at once and slow ones would lag behind.
Extend our running example to a two-source batch: Code (the source of our prompt) and Chat. Let the targets be groups, the acceptance rates and , and the rollout durations min and min.
Step 1: demand
To keep groups after filtering at acceptance rate , we must generate
Step 2: concurrency from Little’s law
Little’s law from queueing theory says the average number of items in a system equals the arrival rate times the average time each spends inside: . Rollouts from source must complete at a rate proportional to per step, and each lives for . So the number in flight must scale as . This is the report’s “required concurrency scales with ”: for Code against for Chat.
Step 3: oversampling
Each source gets a budget of groups, with an oversampling ratio
Slow sources get more headroom. The shared constant is solved so the demand-weighted mean oversampling equals a global . Take , , and .
First try, ignoring the clip:
This gives , below , so it clips to . The equation used the unclipped value, so we solve again.
Second try, with Chat clipped at 0:
Check: , and still clips to . The mean is . The budgets are groups for Code and for Chat. The allocation is recomputed as timing and acceptance statistics change.
Step 4: which source to launch next
Within these budgets, sources are chosen by smooth weighted round-robin with weights
where counts groups already accepted this step and . (This and are the report’s notation for this equation only. They are not the advantage or the segment-penalty .) Suppose Chat has already met its quota, , while Code has . With :
Code gets of the next launches. With (pure deficit), Chat’s weight would drop to . Its pipeline would empty and have to refill from scratch next step, which makes rollout occupancy unstable. With (pure target), the ratio would stay at however far behind Code was. In the report’s trace-driven simulation, was steadier than and more balanced than .
Two more pieces finish the Mixer. Predictive Rollout Dispatch admits a rollout to a GPU rank only if a safety multiple of its predicted KV demand fits. It then places the rollout on the rank with the most remaining capacity, measured as the smaller of free concurrency slots and free KV space. Sample Replay reuses completed groups from slow sources in the first step after startup or recovery. Startup collection takes about longer than steady state, and short rollouts finish first, which would otherwise bias the first batch.
The rest of the infrastructure supports these mechanisms. Each rollout runs as an Agent Loop that owns its environment’s lifecycle and calls the inference engine token-in, token-out. Trajectories form a four-level hierarchy (Sample → Sequence → Context → Segment), and only model-generated Segments carry loss. A Harness Pool of persistent Ray host actors, each hosting many tenants, avoids running out of file descriptors on Ray’s control node. A Payload Porter keeps the driver working on metadata only, while heavy payloads (routing records, top- bitmaps, images) go into a distributed key-value store and are packed where they are consumed.
15. Multi-Harness Training and MOPD2
An agent harness is the loop around the model: system prompt, tools, and context management. Training in one harness can tie the learned strategies to that harness’s quirks. Production harnesses (MiMo Code, Codex) are poor RL environments. They add instructions the reward never measures, which blurs credit assignment, and their modules are too coupled to vary one at a time. MiMo builds mini-harnesses instead: all start from the same minimal agent loop, and the modules are decoupled so they can be recombined into task-specific variants for Code, General, Visual, and Cyber.
On DeepSWE v1.1, training on four code mini-harnesses also raised performance on three held-out harnesses (Codex, Claude Code, mini-swe-agent). Their mean pass@1 went from about 50% to about 66%, and the gap to the training harnesses narrowed.
After mixed RL, Multi-Prefix Multi-Teacher On-Policy Distillation (MOPD2) merges in skills from domain teachers: mixRL teachers for verifiable tasks, and SFT teachers for open-domain tasks where no reliable reward exists. Standard MOPD has a teacher score full student rollouts token by token. MOPD2 adds prefix-conditioned rollouts. A source trajectory with assistant turns gives history prefixes , each ending just before an assistant turn. The student generates only that one turn, and the teacher supervises it. If had 3 assistant turns, it would give 3 single-turn distillation problems. Starting from a fixed prefix keeps the student in the histories the SFT teacher actually saw, so a student that has drifted is never judged in situations the teacher never learned. This extends training to domains such as long-horizon game development, scientific research, and embodied intelligence.
16. Results
A selection from the report’s final comparison (Table 3):
| Benchmark | V2.6-Pro | V2.6-Flash | V2.5-Pro | Claude Opus 5 | GPT-5.6 Sol | Claude Fable 5 |
|---|---|---|---|---|---|---|
| DeepSWE v1.1 | 71.9 | 67.9 | 19.0 | 74.0 | 73.0 | 70.0 |
| ProgramBench | 26.5 | 26.0 | 12.5 | 37.0 | 25.0 | 33.0 |
| AutomationBench v1.0.6 | 53.1 | 52.3 | 16.0 | 50.3 | 45.8 | 46.2 |
| Toolathlon-Verified | 76.9 | 73.6 | 49.1 | 80.6 | 74.9 | 77.9 |
| Terminal Bench 2.1 | 89.9 | 87.6 | 65.2 | 89.1 | 88.8 | 84.3 |
| Terminal Bench 4.0 | 34.9 | 28.8 | 1.5 | 49.0 | 39.9 | 42.4 |
| OSWorld-Verified | 82.0 | 80.8 | – | 83.4 | 83.0 | 86.0 |
| CyberGym | 94.0 | 95.1 | 40.0 | – | – | – |
| ExploitBench | 47.9 | 25.3 | 16.6 | 70.0 | 78.5 | 78.0 |
| MiMo Visual Coding | 72.3 | 71.5 | – | 70.0 | 73.4 | 69.1 |
The jump from V2.5 is large everywhere. Against frontier models, V2.6-Pro leads on AutomationBench and Terminal Bench 2.1 and is close on DeepSWE and OSWorld. It trails clearly on Terminal Bench 4.0 and on exploit development (ExploitBench, ExploitGym). That fits the training mix: the cyber RL task is vulnerability reproduction, not exploitation. Over training, scores rise together with total tokens used (Figure 9), so part of the gain comes with longer rollouts. The length penalty and GAR slow that growth but do not stop it.
What went wrong during the run. Infrastructure failures were mostly GPU double-bit memory errors, plus a Kubernetes failure (Flash) and an unreachable grader (Pro). Rollout failures came from partial rollout. Short rollouts finish first after a restart, which biased the length priors in Predictive Dispatch and exhausted the KV pools. One harness also produced rollouts less than half as long as the others on the same dataset. Training failures were the expert-imbalance out-of-memory errors from Section 13. Driver failures were CPU out-of-memory errors during packing, late in the Flash run, as sequences grew.
17. Open Foundations: The 9B Distilled Model
To make agentic RL research reproducible, the team released MiMo-V2.6-Distill-Qwen-9B, which is Qwen3.5-9B fine-tuned on 77.4B tokens of MiMo-generated data (27.2B of them loss tokens: code 7.3B, cyber 4.8B, general 5.7B, visual 9.4B). They also released about 7K RL tasks with verifiers (3K code, 1K cyber, 1K general, 2K visual, plus about 1K music-generation tasks), the RL framework, and the mini-harnesses.
Starting from the same SFT checkpoint, domain-specific GRPO improved all 11 reported evaluations:
| Benchmark | Qwen3.5-9B | SFT | +RL |
|---|---|---|---|
| SWE-bench Verified | 60.0 | 61.1 | 66.2 |
| SWE-bench Pro | 32.0 | 44.6 | 47.6 |
| MiMo Code Bench (mini) | 19.5 | 51.6 | 59.9 |
| MiMo Cyber Bench (mini) | 5.7 | 31.3 | 47.0 |
| AutomationBench v1.0.6 | 5.0 | 30.3 | 33.1 |
| Terminal Bench 2.1 | 27.0 | 37.1 | 52.8 |
| Toolathlon-Verified | 25.9 | 35.2 | 38.0 |
| OfficeQA Pro | 9.0 | 19.5 | 24.8 |
| JobBench | 2.6 | 18.3 | 25.2 |
| MiMo General Bench (mini) | 28.5 | 62.2 | 70.6 |
| MiMo Visual Coding (mini) | 61.7 | 64.0 | 72.4 |
A separate multi-harness coding run (four training mini-harnesses, three held out) improved every one of 21 dataset–harness pairs over the SFT checkpoint. On MiMo Code Bench (mini), the gains ranged from 1.8 to 9.3 points depending on the harness. The mean over the seven harnesses rose from 53.1 to 59.0. A music-composition benchmark rose from 45.7 to 52.5. The report’s case study on website generation shows the same progression visually: plain layouts from Qwen3.5-9B, richer content after SFT, and polished, complete pages after RL.
Summary
MiMo-V2.6 trains with importance-sampled GRPO, . Every added mechanism edits the group’s advantage vector without changing its balance. Reward-side edits (hack zeroing, the multiplicative GRS reward , the group-relative length penalty) stay balanced because always sums to zero. Advantage-side edits (GAR’s , the segment penalty’s ) are built to conserve mass, which moves credit from the sloppy patch to the clean one without adding net negative pressure that drives entropy up. The rest of the stack keeps the ratio and the batch honest: top- candidate replay, R3, and QDQ make when the policy has not changed; router freezing stops load collapse; and the Little’s-law Sample Mixer keeps the task mix stable while 25,088 long rollouts are in flight.
Enjoyed this post?
Subscribe to get notified when I publish new posts. No spam, unsubscribe anytime.