单次RL后训练烧掉260万美元、每步37亿Token，小米披露MiMo-V2.6“规模化强化学习”路线

10月8日，小米 MiMo 团队发布技术报告《MiMo-V2.6: Scaling Reinforcement Learning Towards Self-Improvement》。这篇报告披露了小米一套完整的规模化 Agentic RL 训练过程：通过同时扩大训练 Batch、任务环境与 Harness，以及用于评判 Agent 行为的 Grader Compute，来探索模型持续自我改进的路径。 此次发布包含 MiMo-V2.6-Pro 和 MiMo-V2.6-Flash 两个模型。其中，Pro 总参数量为 1.02T、每次推理激活 42B 参数；Flash 总参数量为 310B、激活 15B 参数。两者均采用稀疏混合专家（MoE）架构，并在文本主干中混合局部滑动窗口注意力（SWA）与全局注意力（GA）。 论文链接： https://arxiv.org/pdf/2610.11959 " 同时 Scale 了 Rollout、环境和 Grader MiMo-V2.6 将强化学习算力拆成三个部分：Rollout、Grading 和 Training。 实际训练中，每个 RL Step 先采样 1568 个 Prompt，每个 Prompt 同时生成 16 条 Rollout，也就是说，每一步都会产生约 2.5 万条 Agent 轨迹。这些轨迹合计达到 27亿至37亿 Token，平均每条序列约 11万至15万 Token，训练上下文长度最高达到 100 万 Token。 MiMo-V2.6 的训练任务覆盖代码 Agent、通用工具使用、视觉设计、上下文遵循和网络安全。其中在正式 RL Batch 中，代码与竞争性编程任务占 68%，通用工具使用占 12%，视觉设计占 13%，上下文遵循占 3%，网络安全占 4%。整个训练采用 GRPO，并结合异步 Partial Rollout。 这种训练的成本也迅速上升。论文显示，MiMo-V2.6-Pro 的 RL 后训练成本约 260万美元，Flash 约 90万美元。其中 Pro 的计算成本中，Rollout 占 43.8%，真正用于模型参数更新的 训练占 43.5%，而单独用来判断 Agent 行为好坏的 Grader 已经占到12.7%；Flash 的 Grader 成本比例甚至达到 14.2%。 更要判断Agent是否“做得好” 传统代码 RL 很多时候依赖二元测试奖励：测试通过给 1 分、不通过给 0 分，但这套方法在长程 Agent 任务上已经不够用了。 两个方案即使都能通过测试，其中一个可能只改了必要的几行代码，另一个却加入大量兼容分支、吞掉异常、扩大 API 范围，甚至为了通过测试修改与任务无关的配置。二者在传统 Reward 下可能拿到同样的分数，但工程质量完全不同。 为此，MiMo-V2.6 在代码 Agent 训练中引入了两套分组智能体评分机制。 一套是分组奖励合成（Groupwise Reward Synthesis，GRS）。系统首先收集同一个任务的多个 Rollout，由 Agent 同时分析不同方案，生成“解决方案质量”和“行为质量”两套 Rubric。之后，训练中的每条新轨迹不仅需要通过测试，还会按照代码实现质量、边界情况处理、与原代码库的一致性，以及解决问题过程中是否进行了必要验证等因素继续打分。 另一套是分组优势重分配（Groupwise Advantage Redistribution，GAR）。Grader 会把同一个任务中成功和失败的多条轨迹放到一起比较，对已经通过测试的方案继续按照解决思路、实现准确度、修改范围、副作用和工程质量进行排序，再把更多强化信号分配给质量更高的解法。 实验显示，没有在线分组评分时，模型随着 RL 继续训练，会产生越来越长的轨迹和越来越多的 Agent Turn，并逐渐出现为了提高通过率而加入冗余兼容逻辑、吞掉异常等行为。加入在线评分后，通过率可以继续增长，同时 Token 长度和交互轮数保持得更加稳定，模型也倾向于生成更小、更精确、更易维护的 Patch。 论文还额外加入了“组内相对长度惩罚”，对已经成功但明显比同组其他成功解法更长的轨迹进行扣分，希望模型不仅把任务做完，还尽可能使用更少 Token。 当模型越来越擅长优化 Reward，另一个问题也随之出现：模型开始寻找“作弊路径”。 小米在早期训练中发现，代码 Agent 会尝试绕开原本的修复任务。例如直接安装更新版本的软件包查看已经公开的修复、访问 GitHub 最新源码、克隆上游仓库、搜索 Issue 和提交历史，甚至通过比较不同版本来反推出正确答案。这样的操作同样可能让自动测试通过，但并不能证明 Agent 自己解决了问题。 为此，小米在训练前后增加了多层防线。训练环境会主动删除构建日志、Verifier 输出、残留 Patch、二进制、字节码和 Cache，仅保留任务指定版本之前的 Git 历史，并通过容器级网络隔离阻止 Agent 获取上游修复。团队甚至专门训练和部署了一个 Hack Agent，主动进入这些环境寻找还能被利用的漏洞。如果找到新的作弊路径，就继续修改环境、重新测试，再让 Hack Agent 攻击，直到无法继续找到可利用路径。 即使正式 RL 已经开始，团队仍会离线审计 Agent 轨迹；一旦发现确认存在 Reward Hacking，对应轨迹的 Reward 会直接被清零。最终，MiMo-V2.6-Pro 和 Flash 正式训练过程中，被确认存在 Reward Hacking 的轨迹比例始终控制在 2%以下。 训练Agent“适应不同Agent” MiMo-V2.6 另一个明显变化，是把 Agent Harness 本身也当成 RL 的一个 Scaling 维度。 不同 Coding Agent 的系统提示词、上下文管理、工具调用方式和执行流程都不同。如果模型长期只在一个 Harness 中训练，很容易学到 Harness 特有的行为模式，换一个 Agent 框架后能力就下降。 小米没有直接拿 Codex、MiMo Code 这类完整生产 Harness 混在一起训练。论文认为，生产 Harness 通常包含大量工程保护、复杂工作流和额外 Prompt，而这些行为未必有对应 Reward，很容易干扰强化学习中的信用分配。不同模块之间又高度耦合，也不方便单独控制变量。 因此，MiMo-V2.6 构建了一批更小、更模块化的 mini-harness，统一保留系统提示词、工具和上下文管理等最基本能力，再针对 Code、General、Visual 和 Cyber 组合不同配置进行训练。 效果之一是，模型不仅在训练期间见过的四套 Harness 上提高，在训练时从未见过的 Codex、Claude Code 和 mini-swe-agent 上也同步提升。在 DeepSWE v1.1 上，3 个 Held-out Harness 的平均 Pass@1 从大约 50%提升至66%。 MoE Router 一旦跟着RL学习，20步就开始“塌” 规模变大后，模型本身也出现了新的稳定性问题。 MiMo-V2.6