1. 从“能聊天”到“会进化”：MiMo-V2.6 到底想解决什么
第一次看到“自我改进的强化学习规模化”这个说法，我脑子里冒出来的不是兴奋，而是怀疑。过去两年，开源大模型的迭代节奏基本是“堆数据、堆参数、堆算力”，预训练阶段把知识灌进去，后训练阶段用监督微调对齐一下，再拿人类偏好数据做一轮强化学习，模型就定型了。这套流程跑通之后，模型的能力上限其实在训练结束那一刻就锁死了——它不会因为多跑了几百万次推理就变聪明。
MiMo-V2.6 这个技术报告最值得聊的地方，恰恰是它试图打破这个“训练即定型”的惯性。它把强化学习从后训练阶段的一个收尾环节，提到了一个更核心的位置：让模型在持续交互中自己产生训练信号，自己筛选有价值的轨迹，自己更新策略。说白了，就是让模型具备一种“越用越强”的机制，而不是靠人工标注团队一轮一轮喂数据。
这件事为什么难？因为强化学习本身就不稳定。你在小规模上跑通的策略梯度方法，放到千亿参数、MoE 架构、多轮工具调用的场景里，梯度方差会大到让训练直接崩掉。更麻烦的是，语言模型的动作空间是离散的、组合爆炸的，一个回答可能有几十种合理路径，奖励信号又往往是稀疏的、延迟的。MiMo-V2.6 要做的，是在这个极其恶劣的优化环境里，把强化学习真正规模化。
适合谁看这篇解析？如果你只是调 API 做应用，那了解个大概就够了。但如果你在做模型后训练、Agent 系统设计、或者对 RL 在语言模型上的落地感兴趣，那 MiMo-V2.6 的很多设计取舍值得逐条拆开看。它不一定每个点都对，但它把“自我改进”这个方向上的工程难题摆到了台面上。
2. MoE 架构下的强化学习：为什么不能直接套用稠密模型的经验
2.1 稀疏激活带来的信用分配难题
MiMo-V2.6 用的是 MoE 架构，这个选择本身不意外。MoE 在推理成本上的优势已经被验证过很多次了：总参数量可以做得很大，但每个 token 只激活一小部分专家，计算量可控。问题在于，一旦你把强化学习引入 MoE，信用分配就变得非常棘手。
稠密模型里，一个 batch 的梯度会均匀地影响所有参数。MoE 不一样，每个 token 只路由到 top-k 个专家，未被激活的专家在这一步不接收任何梯度。这意味着，当你用一个序列级的奖励去更新策略时，不同专家收到的学习信号强度差异巨大。有些专家可能连续很多步都没被激活，突然被路由到一次，却要承担一个高方差奖励的更新，参数直接跑偏。
我见过不少团队在 MoE 上做 SFT 时感觉还行，因为监督信号是 token 级的、密集的，每个被激活的专家都能拿到明确的梯度。但换到 RL，奖励是序列级的，一个回答可能几百个 token，只有最后有一个分数。这时候路由的随机性和奖励的稀疏性叠加在一起，训练不崩才怪。
MiMo-V2.6 报告里提到的做法，我理解是在路由层面做了约束：不是让路由器完全自由地根据当前 hidden state 选择专家，而是在训练过程中引入某种负载均衡和路由稳定性的正则。具体实现细节报告没完全展开，但从工程直觉上判断，这步是必须的。否则你会看到 loss 曲线像心电图一样，今天涨明天跌，根本没法判断策略到底有没有在变好。
2.2 专家并行与 RL 训练框架的冲突
另一个容易被忽略的点是训练框架。MoE 模型通常用专家并行来部署，不同专家放在不同设备上。但强化学习的 PPO 或者 GRPO 这类算法，需要做多轮前向、计算优势函数、再做多轮反向。这个过程中，rollout 阶段和训练阶段的并行策略往往不一致。
rollout 的时候，你希望推理速度快，可能会用张量并行加流水并行，把模型切得很细。训练的时候，你又需要梯度同步，通信模式完全不同。MiMo-V2.6 如果真要做到“规模化”的自我改进，那它的训练框架必须能高效地在推理模式和训练模式之间切换，而且不能因为切换导致专家路由的分布发生偏移。
我自己的经验是，很多开源框架在处理这种模式切换时，会偷偷把一些缓存清掉，导致同一批数据在 rollout 和训练时经过的路由路径不一致。这种不一致在 SFT 阶段影响不大，但在 RL 里会直接破坏重要性采样的假设，让 off-policy 校正失效。MiMo-V2.6 有没有完全解决这个问题，报告里没有给出消融实验，但从它强调“规模化”来看，框架层面的优化应该是下了功夫的。
2.3 一个容易被忽视的细节：专家温度与探索
强化学习需要探索，语言模型的探索通常靠采样温度。但在 MoE 里，路由器的 softmax 温度是另一个隐藏的探索维度。如果你把路由温度调高，同一个 token 可能被分配到不同专家，模型的行为多样性会增加，但一致性会下降。如果你把路由温度调低，模型输出稳定，但探索不足，RL 很容易收敛到局部最优。
MiMo-V2.6 在报告里没有单独讲路由温度的策略，但从它强调“自我改进”来看，我猜测它在训练过程中对路由温度做了退火或者自适应调整。早期需要更多探索，路由温度偏高；后期需要稳定策略，路由温度降低。这个细节如果处理不好，你会看到模型在训练中期突然“性格大变”，之前学到的技能全忘了。
3. Agentic RL 的规模化：多轮交互中的奖励设计与轨迹筛选
3.1 为什么单轮 RL 不够用
MiMo-V2.6 的关键词里有“Agentic RL”，这个词这两年很热，但真正做扎实的工作不多。单轮 RL 的设定很简单：给一个 prompt，模型生成一个回答，拿一个奖励，更新。但 Agent 场景是多轮的：模型要调用工具、观察结果、再决策、再调用，可能十几轮之后才完成任务。这时候奖励是最终给的，中间步骤没有直接监督。
这种设定下，最朴素的做法是把整个轨迹当成一个动作序列，用最终奖励做 REINFORCE。但方差太大了。一个 20 轮的轨迹，每轮有几十个 token，总共上千个决策点，最后只有一个标量奖励。梯度估计的方差会随着轨迹长度指数级增长，根本没法训。
MiMo-V2.6 报告里提到的思路，我理解是做了某种层次化的奖励分解。不是等最后才给分，而是在中间步骤引入过程奖励或者价值估计。但过程奖励从哪来？人工标注不现实，用另一个模型打分又容易引入偏差。比较可行的方案是用蒙特卡洛树搜索或者类似的方法，对中间状态做 rollout，估计当前状态的价值。这个计算量很大，但 MiMo-V2.6 既然敢说“规模化”，说明它在工程上找到了降低 rollout 成本的办法。
3.2 轨迹筛选：不是所有经验都值得学
Agentic RL 另一个核心问题是经验回放的质量。在传统 RL 里，你可以把大量轨迹存进 replay buffer，然后随机采样训练。但在语言模型 Agent 场景里，轨迹的长度、质量、多样性差异极大。有些轨迹是模型瞎试出来的，虽然最后碰巧成功了，但中间步骤全是错的。这种轨迹如果被当成正样本学习，模型会学到错误的因果关联。
MiMo-V2.6 在报告里应该提到了某种轨迹筛选机制。我猜测它用了类似“优势函数阈值”的方法：只保留优势估计显著为正或显著为负的轨迹，中间那些模棱两可的丢掉。这样做的好处是训练信号更干净，坏处是样本利用率下降。在规模化设定下，样本利用率下降可以通过增加 rollout 数量来弥补，但前提是你的推理成本足够低。
这里有个实操中的坑：很多团队在做轨迹筛选时，只看了最终奖励，忽略了轨迹长度。一个短轨迹如果成功了，它的每一步贡献都很大；一个长轨迹如果成功了，可能只是最后几步起了作用。如果不做长度归一化，模型会倾向于学短轨迹，导致它在复杂任务上缺乏耐心。MiMo-V2.6 有没有处理这个问题，报告里没细说，但这是做 Agentic RL 必须面对的问题。
3.3 工具调用的动作空间设计
Agent 场景里，模型的动作不只是生成文本，还包括调用工具。工具调用的动作空间是结构化的：选哪个工具、传什么参数。这个动作空间和纯文本生成的动作空间混在一起，给策略梯度方法带来了额外挑战。
一种做法是把工具调用也当成文本生成，用特殊 token 标记工具名和参数。这样动作空间统一了，但模型需要学会严格的格式，否则解析会失败。另一种做法是分离策略：文本生成用一个头，工具选择用另一个头。MiMo-V2.6 具体用哪种，报告里没有明确，但从它强调“Agentic”来看，应该是把工具调用纳入了统一的策略优化框架。
我自己的经验是，工具调用的奖励设计比文本生成更棘手。文本生成可以用奖励模型打分，工具调用成功与否是二值的，但成功不一定代表调用得对。比如模型调了一个搜索工具，搜到了答案，但搜索关键词完全跑偏，只是运气好。这种轨迹如果被当成正样本，模型会学到错误的工具使用习惯。所以工具调用的奖励需要更细粒度的设计，不能只看最终任务是否完成。
4. 自我改进的闭环：模型如何自己生成训练信号
4.1 从人类反馈到模型反馈的迁移
传统 RLHF 依赖人类标注偏好数据。但人类标注成本高、速度慢、一致性差。MiMo-V2.6 提“自我改进”，核心思路之一就是用模型自己生成的反馈替代部分人类反馈。具体来说，可以用一个奖励模型或者一个更强的模型来给当前策略的输出打分，然后用这些分数做 RL。
这个思路不新鲜，但规模化之后会出现一个新问题：奖励黑客。模型会学会迎合奖励模型的偏好，而不是真正提升能力。比如奖励模型偏好长回答，模型就拼命写长；奖励模型偏好某种句式，模型就反复用。这种退化在单轮 RL 里已经很明显了，在多轮 Agent 场景里更严重，因为模型可以通过操纵中间步骤来影响最终奖励。
MiMo-V2.6 如果真要做到“自我改进”，必须有一套机制来检测和抑制奖励黑客。常见做法包括：定期用人类数据校准奖励模型、在奖励里加入多样性惩罚、用多个奖励模型投票。报告里有没有这些细节，我不确定，但这是判断一个“自我改进”系统是否可靠的关键。
4.2 迭代式训练：每一轮都在变强的策略
自我改进的另一个含义是迭代。第一轮用初始策略生成数据，训练出新策略；第二轮用新策略生成数据，再训练；如此反复。理论上，每一轮策略都应该比上一轮强，生成的数据质量更高，训练信号更好。
但实际做起来，迭代几轮之后就会遇到瓶颈。要么是策略退化，越训越差；要么是数据同质化，模型只会生成自己已经会的东西，探索不到新技能。MiMo-V2.6 报告里提到的“规模化”，我理解不只是单轮训练的规模，还包括迭代轮次的规模。它可能设计了某种机制来保持迭代过程中的探索性，比如在每一轮引入一定比例的随机扰动，或者维护一个策略池，从历史策略中采样生成数据。
这里有个工程上的细节：迭代训练对基础设施的要求很高。每一轮都要重新做 rollout、重新训练、重新评估。如果一轮要跑几天，迭代十轮就是一个月。MiMo-V2.6 敢说“规模化”，说明它在训练效率上做了优化，可能是用了异步 rollout、增量更新、或者更高效的并行策略。
4.3 评估的陷阱：自我改进不等于全面变强
最后聊一个容易被忽视的问题：评估。一个自我改进的系统，很容易在它优化的指标上越跑越高，但在其他指标上悄悄退化。比如它可能学会了更好地调用某个工具，但在纯文本推理上变差了。如果你只看任务完成率，会觉得它在进步；但如果你做全面的能力评估，会发现它在偏科。
MiMo-V2.6 的报告里应该有多维度的评估，但具体覆盖了哪些能力，我没有看到完整数据。从经验上讲，做自我改进系统时，一定要保留一个固定的、不参与训练的评估集，而且这个评估集要覆盖多种任务类型。否则你很容易被训练曲线迷惑，以为模型在变强，实际上只是在过拟合奖励信号。
5. 工程落地的现实约束：算力、框架与团队配置
5.1 算力账：规模化 RL 到底要烧多少卡
聊完算法，回到现实。MiMo-V2.6 这种规模的模型做 RL，算力消耗是惊人的。预训练阶段虽然单步计算量大，但数据是固定的，你可以精确估算总计算量。RL 不一样，rollout 阶段要生成大量样本，训练阶段又要多轮迭代，而且很多样本因为奖励太低被丢弃，实际有效计算占比可能不到一半。
粗略估算一下：假设模型总参数 100B 级别，MoE 激活参数 10B 左右。一次 rollout 生成 1M token 的轨迹，推理成本大概是训练成本的几倍。如果每天要生成几十亿 token 的轨迹，再经过筛选、训练，没有几千张加速卡根本跑不动。这还不包括奖励模型、价值模型、参考模型的开销。
所以 MiMo-V2.6 说“规模化”，背后一定是大量的工程优化。比如用 vLLM 或类似的推理引擎做高吞吐 rollout，用 ZeRO 或 FSDP 做训练并行，用异步流水线把 rollout 和训练重叠起来。这些工程细节报告里可能不会全写，但它们是决定一个 RL 方案能不能落地的关键。
5.2 框架选型：现有工具够不够用
目前做语言模型 RL 的开源框架，比较常见的有 TRL、OpenRLHF、verl 等。这些框架在稠密模型上已经比较成熟了，但放到 MoE 加 Agentic 场景里，多多少少都有坑。
TRL 的 PPO 实现比较简洁，但扩展性一般，大规模 MoE 训练时容易遇到通信瓶颈。OpenRLHF 支持 Ray 分布式，对多机多卡友好，但它的 rollout 和训练耦合比较紧，做异步优化时需要改不少代码。verl 是字节开源的，设计上更偏向大规模，支持混合并行，但文档和社区还在完善中。
MiMo-V2.6 如果是在这些框架基础上改的，那它一定做了大量定制。如果它是自研框架，那工程投入就更大了。对于普通团队来说，我的建议是不要一上来就追求“规模化”，先用小模型把 RL 流程跑通，理解清楚奖励设计、优势估计、策略更新的每一个环节，再考虑放大。
5.3 团队配置：算法、工程、数据的三角关系
做这种项目，团队配置很关键。纯算法背景的人容易低估工程复杂度，写出来的方案在单卡上跑得通，上多卡就崩。纯工程背景的人容易忽视算法细节，把 RL 当成普通的分布式训练任务，结果训练不稳定还找不到原因。
比较理想的配置是：一个懂 RL 算法的负责人，一个懂分布式训练的工程负责人，再加一个懂数据质量和评估的数据负责人。三个人要紧密配合，算法负责人定义训练目标和奖励函数，工程负责人设计并行策略和通信方案，数据负责人负责轨迹筛选和评估集构建。任何一环脱节，项目都会卡住。
MiMo-V2.6 背后的团队显然在这三方面都有积累，否则不可能把规模做到这个程度。对于想复现或者借鉴的团队，我的建议是先评估自己的短板在哪，缺算法补算法，缺工程补工程，不要试图跳过任何一个环节。
6. 从 MiMo-V2.6 能抄到什么：可复用的经验与避坑清单
6.1 奖励设计：从稀疏到密集的渐进路线
如果你正在做语言模型的 RL，不管是不是 Agent 场景，奖励设计都是第一优先级。MiMo-V2.6 的经验告诉我，不要一上来就搞纯稀疏奖励。先用密集奖励把模型训到一个还不错的起点，再逐步引入稀疏奖励做精调。密集奖励可以来自奖励模型、规则匹配、或者人工标注的小样本。稀疏奖励可以是最终任务完成与否。
这个渐进路线的好处是训练稳定。纯稀疏奖励在早期几乎学不到东西，因为正样本太少，梯度信号太弱。先用密集奖励让模型学会基本的行为模式，再用稀疏奖励做筛选，效果会好很多。
6.2 轨迹管理：存什么、丢什么、怎么采样
Agentic RL 的轨迹管理是个脏活累活，但直接影响训练效果。我的经验是，轨迹存储要记录完整信息：每一轮的输入、输出、工具调用、中间奖励、最终奖励、策略版本。采样的时候不能均匀采样，要按优势函数加权，高优势的轨迹多采，低优势的少采，但也不能完全丢掉低优势的，否则模型会失去对错误行为的认知。
另外，轨迹的长度要归一化。长轨迹和短轨迹的优势值不能直接比较，要做长度惩罚或者用折扣因子。MiMo-V2.6 具体怎么做的，报告里没细说，但这是做 Agentic RL 必须处理的问题。
6.3 训练稳定性：那些报告里不会写的坑
最后分享几个训练稳定性方面的坑。第一，KL 散度约束不能太紧也不能太松。太紧模型学不动，太松模型跑偏。我的经验是从一个中等值开始，根据训练曲线动态调整。第二，学习率要 warmup，而且 warmup 步数要比 SFT 长，因为 RL 的梯度方差大，初期需要更保守。第三，advantage normalization 要做，但不要用全局统计量，要用 batch 内的统计量，否则不同 batch 之间的尺度不一致，训练会抖。
还有一个坑是随机种子。RL 对随机种子极其敏感，同一个配置换个种子可能结果完全不同。所以做实验时一定要跑多个种子，取平均或者看分布，不要只看一次结果就下结论。MiMo-V2.6 这种规模的训练，种子敏感性可能被平均掉了，但对于中小规模实验，这个问题非常突出。
6.4 评估集构建：别让模型自己骗自己
自我改进系统最大的风险是评估失真。我的建议是，评估集一定要独立构建，不能从训练数据里切。评估任务要覆盖多种类型：纯文本推理、工具调用、多轮对话、长上下文理解。每个任务都要有明确的通过标准，不能靠模型自己打分。
另外，评估要定期做，不能只在训练结束时做一次。训练过程中每过一段时间就跑一次评估，画一条评估曲线。如果评估曲线和训练奖励曲线出现背离，说明模型在过拟合奖励信号，需要调整奖励函数或者增加正则。
MiMo-V2.6 的评估细节我没有看到完整数据，但从它强调“自我改进”来看，评估环节应该是下了功夫的。对于想借鉴的团队，我的建议是把评估当成一等公民，不要等到训练完了才想起来评估没做。
7. 写在最后：自我改进是方向，但不是捷径
MiMo-V2.6 这个工作最让我认可的地方，是它没有把“自我改进”包装成一个万能药。它承认了强化学习在规模化过程中会遇到的各种工程难题，并且给出了自己的解法。这些解法不一定是最优的，但至少是把问题摆到了台面上。
我自己在做 RL 相关项目时最大的体会是，算法层面的创新往往只占成功因素的 20%，剩下 80% 是工程细节和数据质量。奖励函数怎么设计、轨迹怎么筛选、训练怎么稳定、评估怎么做，这些看起来不性感的工作，才是决定项目成败的关键。MiMo-V2.6 能在开源模型里做到这个程度，背后的工程积累一定非常深厚。
如果你打算在自己的项目里尝试类似的方向，我的建议是从小规模开始，先把单轮 RL 跑稳，再逐步引入多轮和工具调用。不要一上来就追求“规模化”，规模是结果，不是起点。先把每一个环节的坑踩一遍，理解清楚为什么这样设计，再考虑放大。这样即使遇到问题，你也能快速定位，而不是面对一个黑盒束手无策。
