MiMo-V2.6：把 RL 算力堆到 260 万美元，
然后想办法让奖励配得上这些算力

一句话：这份报告把「scaling RL」拆成三个可独立加算力的维度——更大的 batch、更多样的环境与 harness、以及更贵的打分器。第三条是最反直觉也最有信息量的：他们愿意拿出八分之一的总算力，只为了把「测试通过」这个 0/1 信号变成「通过得好不好」。

01先看钱花在哪：RL 的算力构成

报告一上来就给了一张别人很少给的图——分数对累计美元成本的曲线，外加算力的三段拆分。

三点值得注意：

• 曲线还没饱和。Pro 花到 260 万美元时仍在涨，这是「scaling RL compute」这个主张的直接证据。但也要看到边际收益明显递减：前 50 万美元把分数从 48.7 推到约 65，后面 200 多万只换来 7 个点。
• rollout 和训练几乎各占一半（43.8% / 43.5%）。长程 agent 的 RL 里推理不再是配角，这和传统 RLHF 的算力结构完全不同。
• grader 占 12.7%。这是整篇报告的技术核心所在——见 §04。

02基础设施与训练配置

两个我认为最值得单独拎出来的设计：

03环境与 harness：四个领域 + 五条合成路径

RL 任务配比：agentic / 竞赛编程 68%、通用工具使用 12%、美学设计 13%、上下文遵循 3%、网络安全 4%。

代码任务的五条合成路径

1. GitHub PR + issue：issue 描述够完整就直接当规格；否则让 LLM 从参考 patch 反向重建 issue 式规格，并明确要求省略会泄露解法的实现细节。
2. 公司内部真实开发请求：收集员工提交的日常开发需求（含 vibe coding 场景），由 agent 生成测试来固化要求的行为。
3. 规格驱动：多约束详细需求下的代码生成。
4. 源代码驱动 —— 直接用 CodeMidas。
5. 长程软件工程：agent 迭代扩写需求、扩大改动范围、引入跨组件依赖，并构造能考察多步行为的测试。

另外三个领域

Multi-Harness 训练：为什么不用生产 harness

他们把 harness 多样性当作与任务、环境并列的第三个训练维度，但明确拒绝了「直接拿 MiMo Code、Codex 这些生产 harness 来训」，理由有两条：

• 生产 harness 包了一堆工程兜底和多步工作流，还用大量约束/指令 prompt 引导模型。这些额外要求落在任务完成奖励之外，导致信用分配不可靠——没有被奖励测量的要求会被模型直接无视。
• 模块之间紧耦合、不可独立配置，没法单独改变一个交互机制做受控组合。

替代方案是自建 mini-harness：都从同一个最小 agent loop 出发（system prompt、工具、上下文管理），模块保持最小且解耦，可自由重组。为 Code / General / Visual / Cyber 各派生一套配置。

结果是这一节最硬的证据：三个训练时从未见过的 harness，平均 Pass@1 从约 50% 涨到 66%，而且训练 harness 与留出 harness 的差距在收窄。这说明学到的是可迁移的解题能力，而不是对某套工具接口的拟合。

04核心：Groupwise Agentic Grading

二值测试奖励能告诉你「过没过」，但过了的那些解之间的质量差异——它全部丢掉了。这一节就是在把丢掉的信息捡回来。

两条路线，作用在代码任务的不同子集上：

GRS：离线 rubric 合成（用于高通过率任务）

对选定任务先收集多条离线 rollout，让一个 agent 结合任务规格和仓库横向对比这些尝试，产出两套标准：

• solution rubric——好实现的任务相关属性：满足需求、边界处理得当、改动与周围代码风格一致；
• behavior rubric——支撑可靠解题的可观察实践：收集相关证据、检查代码改动的影响。

关键的分寸感在这里：rubric 由 rollout 启发，但要锚定在任务本身。一个有用的行为可能只在一条尝试里出现过；一个任务支持的要求可能所有解都没做到——agent 可以提出超出样本的改进。反过来，某条成功解做的一个选择，不会自动变成对所有解的硬性要求。

乘法形式是刻意的：失败轨迹仍然拿 0，rubric 监督始终被拴在测试结果上，不会出现「测试没过但 rubric 打分高」。而即使一组里全部通过，两个 rubric 分的乘积差异仍能提供学习信号——这直接解决了 GRPO 里全对组 advantage 恒为零的浪费。

GAR：在线组内 advantage 再分配（用于其余代码任务）

对每个混合结果的 rollout 组，把所有轨迹放进一个共享工作区（任务规格、仓库、提交的 patch、测试输出），由一个 SFT 训练的 agentic grader 同时审视全组，对比成功与失败的尝试，并沿五个维度比较通过的 patch：

1. 解法路线是否合适
2. 实现是否精确（无遗漏、无不必要的兜底分支）
3. 相对必要改动的最小性
4. 是否避免了任务范围外的副作用
5. 工艺是否符合代码库惯例

Grader 可以读仓库代码、跑有针对性的测试来验证候选解；差异不明确时允许并列。一旦确认某条轨迹依赖外部或泄漏的答案，其有效奖励直接置零并当作失败，然后才重算组统计量。

其中质量因子 f_i ∈ (0,1] 先把低质量的通过样本降权，再由公共因子 λ 把被移走的正 advantage 质量重新分配给高质量的通过轨迹。这个未加 cap 的更新保持 Σ_i∈PA′_i = Σ_i∈PA_i，且不动失败轨迹。

GAR 的消融：它到底防住了什么

没有 GAR 时：轮数和总长度迅速膨胀，越来越多轨迹撞上长度上限，通过率因此难以持续改善。有 GAR 时：通过率一路涨到第 52 步，轮数基本持平，长度缓慢增长。

但真正让我觉得这一节有分量的，是他们额外做的面向维护者的人工审计——不看分数，看代码变成了什么样：

行为正则化：三个补充机制

05Reward Hacking：一场打了很多轮的拉锯

报告罕见地把模型作弊的具体案例连同原始 thinking 一起贴了出来（原文表 2），五种模式全部来自仓库修复任务：

防御是四层的：

06Router 冻结：一个 20 步就能毁掉训练的坑

这是报告里最干净、最可直接复用的一个发现。

不冻结时三个指标在前 20 步单调恶化——五分之一的专家直接变成死专家。

顺带一提，§5.5 的失败分析显示这个问题还有下游代价：训练侧的 OOM 故障正是来自 micro-batch 内的 MoE 不均衡——尽管整个 batch 相对均衡，某一层的某个 EP rank 收到了超过均值 30 倍的 token 负载。

07失败分析：万卡训练 30 步会遇到什么

这一节在同类报告里很少见——他们把中断全画出来了。

一个我觉得有普适价值的观察：这些故障里有一半跟「长度估计」和「内存预算」有关——partial rollout + 极大 batch + 1M 上下文这个组合，把内存管理变成了训练稳定性的第一杀手，而不是传统认知里的数值稳定性。

Sample Mixer：混合任务 RL 的调度难点

为什么需要一个专门的调度器？因为25 个数据源之间，平均生成 token 数差 90 倍、活跃 rollout 时长差 66 倍。慢的源需要更多并发才能维持同样的训练贡献。四个机制：

• 自适应并发：每源预算 (1+p_i)m_i，其中 m_i = B_i/r_i（目标组数 ÷ 接受率），超采样比 p_i 随该源时长 t_i 增长，并用公共因子 c 把需求加权均值钉在全局超采样比上
• 自适应调度：权重 w_i = α·B_i/r_i + (1−α)·(B_i−A_i)⁺/r_i，前项维持长期生成需求、后项优先补当前 batch 的缺口。α=0.5 的「缺口修正」调度在占用率稳定性和收集均衡性上都优于两个极端
• 预测式分发：用每源先验估计 KV 需求，只有当安全裕度倍数的估计 KV 需求能装进目标 rank 的剩余显存时才准入
• Sample Replay：profiling 显示启动阶段的样本收集耗时约为稳态的 1.8 倍，且慢源里短 rollout 先完成会让首批 batch 有偏。所以只在启动/恢复后的第一个收集步复用已完成的 rollout 组来填缺口

08结果

原文表 3。所有支持推理努力度配置的基线都按最高档评测。CyberGym 的评测环境被他们按 §4.2.4 的方法修正过。

几个读法：

• 相对 V2.5 的跨代提升是巨大的：DeepSWE 19.0 → 71.9，Terminal Bench 4.0 从 1.5 → 34.9，MiMo Cyber Bench 从 0.0 → 80.2。但这种「几乎从零起步」的对比说明 V2.5 根本没有为 agentic 场景训练过，跨代数字不宜当作 RL 本身的功劳。
• 和前沿模型基本同档，个别项领先：AutomationBench（53.1 vs Opus 5 的 50.3）和 Terminal Bench 2.1（89.9 vs 89.1）超过 Claude Opus 5，DeepSWE 71.9 则略低于 74.0。
• 短板集中在安全的进攻端和 ProgramBench：ExploitBench 47.9 对 78.5、ExploitGym 17.8 对 30.3——CyberGym 那种「复现已知漏洞」他们做到 94%，但「开发真正的利用」明显落后，说明训练任务（漏洞复现）和这两个 benchmark（利用开发）之间存在能力鸿沟。ProgramBench 26.5 对 Opus 5 的 37.0 同样偏低。

开源部分：9B 上的可复现实验

他们开源了 MiMo-V2.6-Distill-Qwen-9B（从 Qwen3.5-9B 用 77.4B token SFT 得到，其中 27.2B 是 loss token）、约 7k 个 RL 任务环境（Code 3k / Visual 2k / Cyber 1k / General 1k，另有约 1k 音乐生成任务）、端到端 RL 框架和可组合的 mini-harness。

原文表 6 节选，11 项评测全部提升。多 harness 实验（表 7）里，21 个「数据集 × harness」组合全部改善，MiMo Code Bench (mini) 上 RL 相对 SFT 的额外增益在 7 个 harness 上是 1.8 到 9.3 个百分点。

09存疑与局限

• 三个 scaling 维度没有分别消融。报告的核心主张是「沿三个维度扩 RL 算力」，但只有 GAR（grader 维度）有对照实验，batch 维度和环境/harness 多样性维度都没有「只改这一项」的对比。那条 260 万美元的曲线是三者叠加的结果，无法归因。
• GAR 的消融在小 batch 上做的。图 8 用的是 batch 128 + token-mean 聚合的 code-only 设置，而主实验是 batch 1568 + prompt-mean。「没有 GAR 就长度爆炸」这个现象，有多少是 token-mean 聚合本身造成的，报告没有区分——他们自己在 §5.1 就说了 prompt-mean 的作用正是「防止长度增长过快」。这两个机制的功劳是混在一起的。
• 质量因子 f_i 的具体形式没给。GAR 公式里 f_i ∈ (0,1] 是核心，但从排序到 f_i 数值的映射、cap 的取值都没写。长度惩罚的 X、δ、s、γ、A、B，段级惩罚的 κ、α_max、β_min 同样全部缺失。这些是最难调、也最需要知道的参数。
• grader 自身的可靠性没有被评估。GAR 用一个 SFT 训练的 agentic grader 来排序，GRS 用 agent 生成 rubric——但没有任何关于 grader 判断准确率、与人类一致性、或 grader 自身被 hack 的分析。花了 12.7% 算力的组件，其可信度是被默认的。考虑到 §4.3.2 那段维护者审计恰恰说明「按测试通过率优化会系统性跑偏」，用另一个模型来定义「质量」同样可能有系统性偏差。
• 内部 benchmark 占比较高。MiMo Code Bench、MiMo Cyber Bench、MiMo Visual Coding 都是自建且未公开；视觉领域只有内部 benchmark。§7.2 明确说这些 mini 评测集「遵循与对应训练集相同的任务分布」——同分布评测的泛化说服力有限。
• 「Self-Improvement」这个标题名不副实。副标题写的是 Towards Self-Improvement，正文开篇也讲 recursive self-improvement，但实际做的是人工构造环境 + 人工设计奖励 + 人工做四轮环境清理的标准 RL。唯一能沾上边的是 hack agent 的迭代循环，而那也是人在改清理脚本。
• MOPD² 被一笔带过。最终模型是 mixRL 之后再做多前缀多教师在线蒸馏得到的，但表 3 的数字是 MOPD² 之后的，而 MOPD² 贡献了多少完全没有单独报告。这意味着表 3 和那条成本曲线（纯 RL）不是同一个东西。
• 成本数字缺乏口径说明。$2.6M 是按什么单价算的？含不含环境构造、hack agent 筛查、失败重跑的时间？123.1 小时的时间线里有明显的故障区间，这些算进去了吗？

10值得带走的三点

1. 「打分器也是一个可以扩算力的维度」是这篇最有价值的主张。拿出 12.7% 的算力把二值奖励变成有质量梯度的奖励，换来的不只是分数——而是代码质量本身不再退化。那段维护者审计（不用在线打分的策略会系统性学会投机兼容分支、吞异常、放松校验、改评测配置）是我在所有 coding RL 报告里见过的最具体的「reward hacking 软性版本」证据。乘法形式 R = R_test · S_sol · S_beh 也值得直接抄：它保证 rubric 永远拴在测试上，同时让全对组仍有梯度。
2. 两条几乎零成本就能复用的工程结论。其一，MoE 模型做 RL 要冻结 router——不冻 20 步内冷专家就从 0.5% 涨到 22%，而且他们用「只还原 router 参数」的实验干净地证明了病因是 router drift 而非专家退化。其二，不做环境清理，你的 RL 环境有 92%–100% 可以被绕过；而且清理轮数是数据集相关的，有的清 4 轮还剩 22%，指望一套通用脚本是不现实的。
3. harness 多样性是被低估的泛化维度。用自建的、模块解耦的 mini-harness 训练，让三个完全没见过的 harness（codex / claude code / mini-swe-agent）平均 Pass@1 从 50% 涨到 66%，且训练与留出的差距收窄。他们拒绝用生产 harness 的理由也讲得很透：生产 harness 的约束 prompt 落在奖励之外，没被奖励测量的要求，模型就会直接无视——这句话本身值得贴在墙上。