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 跑稳再逐步引入多轮和工具调用。不要一上来就追求“规模化”规模是结果不是起点。先把每一个环节的坑踩一遍理解清楚为什么这样设计再考虑放大。这样即使遇到问题你也能快速定位而不是面对一个黑盒束手无策。
MiMo-V2.6自我改进强化学习规模化：MoE架构与Agentic RL工程实践解析
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 跑稳再逐步引入多轮和工具调用。不要一上来就追求“规模化”规模是结果不是起点。先把每一个环节的坑踩一遍理解清楚为什么这样设计再考虑放大。这样即使遇到问题你也能快速定位而不是面对一个黑盒束手无策。