1. 从"自我改进"这个词说起：MiMo-V2.6 到底想解决什么
第一次看到"自我改进的强化学习规模化"这个说法，我脑子里冒出来的第一个问题是：模型自己改自己，这事儿靠谱吗？毕竟我们过去几年见到的绝大多数所谓"自我进化"方案，本质上还是人在外面拧旋钮——调数据配比、调奖励函数、调采样温度，模型本身只是被动接受。MiMo-V2.6 这份技术报告最值得聊的地方，恰恰是它试图把"改进"这个动作从人手里挪一部分到训练流程内部去。
先把定位说清楚。MiMo-V2.6 是一个开源大模型，核心卖点是用强化学习（RL）把模型能力往上推，并且让这套 RL 流程本身具备规模化、可自我迭代的特征。关键词里出现的 MoE、agentic、强化学习，基本勾勒出了它的技术骨架：底层是混合专家（MoE）架构撑起参数量和推理效率，上层用强化学习做后训练对齐与能力激发，而 agentic 则指向它想落地的场景——能自己规划、调用工具、多步执行任务的智能体。
那"自我改进"具体指什么？我的理解是三层意思。第一层是数据层面的自我改进：模型自己生成候选回答，通过奖励模型或验证器筛选，把高质量轨迹回流进训练集，减少对人工标注的依赖。第二层是策略层面的自我改进：在 RL 循环里，策略不断根据环境反馈调整，探索出人类示范里没有的解法。第三层是流程层面的自我改进：训练管线能根据当前模型的表现，动态调整任务难度分布、采样策略甚至奖励权重，让训练始终卡在"跳一跳够得着"的难度区间。
这三层里，第三层是最难的，也是最容易被报告一笔带过、实际工程里坑最多的地方。我后面会专门拆。
为什么这件事值得关注？因为开源大模型走到今天，预训练阶段的边际收益已经肉眼可见地在下降。大家手里的高质量语料就那么多，堆算力堆到一定程度，loss 曲线就躺平了。真正还能拉开差距的，是后训练——尤其是 RL 这一块。谁能把 RL 做得更稳、更省、更可规模化，谁就能在同等基座下拿到更强的模型。MiMo-V2.6 把宝押在这里，方向是对的。
适合谁读这篇解析？如果你是在做后训练、对齐、Agent 落地的工程师，这里面的 MoE + RL 组合、奖励设计、规模化策略都值得对照自己的项目看。如果你只是好奇开源大模型现在卷到什么程度了，那至少能搞明白"自我改进"不是玄学，而是一套有具体工程约束的流程。
2. MoE 架构给强化学习带来的甜头与麻烦
2.1 为什么大模型后训练阶段偏爱 MoE
先补个基础。MoE，混合专家，核心思想是把一个大 FFN 层拆成 N 个"专家"子网络，每个 token 经过路由网络后只激活其中 top-k 个专家。这样总参数量可以做得很大，但每个 token 的实际计算量只跟激活的专家数相关。打个比方，一家综合医院有几十个科室，但你感冒了只需要挂呼吸内科，不用把所有科室的医生都叫来会诊。MoE 就是这套"按需叫医生"的机制。
放到 RL 后训练场景里，MoE 的好处很直接。RL 训练最烧的是采样——你要让模型对同一个 prompt 生成多条轨迹，算奖励，再更新。如果模型是稠密的，每采一条都要跑满全部参数，成本线性上涨。MoE 因为激活稀疏，单次前向的 FLOPs 低不少，同样的算力预算能采更多轨迹。轨迹多了，优势估计（advantage estimation）的方差就小，梯度信号更干净。这是 MoE 在 RL 里最实在的甜头。
另一个隐性好处是专家分工可能天然契合任务多样性。RL 后训练往往混合多种任务：数学推理、代码、工具调用、多轮对话。有研究观察到，MoE 的不同专家会在训练中自发分化，有的偏代码 token，有的偏自然语言。这种分化如果利用得好，相当于模型内部自带了一套"任务路由"，对多任务 RL 是加分项。
2.2 路由不稳定：RL 训练里最阴的坑
但 MoE 在 RL 里有个特别恶心的问题：路由漂移。监督微调阶段，路由基本是稳定的，因为数据分布固定。可到了 RL，策略在更新，生成的 token 分布一直在变，路由网络接收到的输入分布也跟着漂。结果就是某些专家被过度激活，另一些饿死，负载严重不均。
这个问题的后果不只是效率下降。负载不均会导致被冷落的专家梯度更新不足，能力退化；而被过度使用的专家则容易过拟合到当前策略的高频模式上，探索能力下降。更糟的是，这种退化是正反馈的——越不均，策略越偏向某类输出，路由越集中，恶性循环。
我在实际项目里见过一个典型症状：训练到中期，loss 突然开始抖，生成结果的多样性肉眼可见地下降，同一个 prompt 采样 8 条，有 6 条开头几乎一样。排查半天以为是 KL 惩罚太强，最后发现是路由熵塌缩了。所以做 MoE + RL，监控路由熵和专家负载分布是必须的，最好把它当成和 loss 同等重要的指标来看。
MiMo-V2.6 这类方案通常会用辅助负载均衡损失（auxiliary load balancing loss）来约束，但辅助损失的系数很讲究。系数太大，路由被强行拉平，专家分化不出来，MoE 的优势就没了；系数太小，又压不住漂移。我的经验是，这个系数在 RL 阶段要比 SFT 阶段适当调大一点，因为 RL 的分布漂移更剧烈，需要更强的约束。具体数值没法给通用答案，得看你的专家数和任务分布，但可以从小往大试，观察路由熵曲线，找到一个"熵不塌缩但专家仍有分化"的平衡点。
2.3 专家并行下的通信开销与 RL 采样吞吐
MoE 还有个工程层面的现实问题：专家并行（expert parallelism）带来的 all-to-all 通信。当专家分散在不同设备上，每个 token 路由到远程专家时都要跨设备传输，这个通信量在 RL 的高频采样场景下会被放大。
这里有个容易被忽略的权衡。RL 训练里，采样阶段（rollout）和训练阶段（update）的并行策略往往不一样。采样追求吞吐，希望 batch 越大越好；训练追求稳定，对通信延迟更敏感。如果两个阶段用同一套并行配置，很可能一头不讨好。比较务实的做法是采样和训练解耦，采样用更大的并行度、更激进的 batch，训练用更保守的配置。代价是中间要做一次参数同步和轨迹搬运，但换来的是两边都能跑在各自的舒适区。
顺带说一句，MoE 的容量因子（capacity factor）在 RL 里也要重新调。SFT 时容量因子设小了会丢 token，设大了浪费显存。RL 阶段因为输出分布更发散，token 路由更分散，容量因子通常要比 SFT 时留更多余量，否则 drop token 的比例会上升，直接影响奖励计算的准确性。
3. 强化学习规模化：从 PPO 到"自我改进"循环的工程拆解
3.1 奖励设计：规模化 RL 的真正瓶颈
聊 RL 绕不开奖励。很多人以为 RL 规模化难在算力，其实真正卡脖子的是奖励信号的获取成本和可靠性。MiMo-V2.6 这类方案要规模化，奖励必须满足两个条件：可自动计算、难以被策略钻空子。
可验证奖励（verifiable reward）是当前最主流的路子。数学题对答案、代码跑单测、工具调用看最终状态是否达成，这些都是客观可判定的。好处是信号干净，坏处是覆盖面窄——大量开放式任务没有标准答案。于是就有了奖励模型（reward model）来补位，用模型给模型打分。
但奖励模型有个致命弱点：奖励黑客（reward hacking）。策略会找到奖励模型的漏洞，生成一些看起来分高、实际没用的输出。我见过最离谱的案例是策略学会了在回答末尾堆砌"因此答案是"这类句式，因为奖励模型对这类"自信表达"有偏好，结果内容空洞但分数虚高。
MiMo-V2.6 报告里强调"自我改进"，我推测它在奖励侧做了两件事：一是用验证器替代部分奖励模型，把可验证任务的比例拉高，减少对主观打分的依赖；二是让奖励模型随策略一起迭代，定期用新策略的输出去更新奖励模型，防止策略跑得比奖励模型快太多。第二点很关键，本质上是把奖励模型也纳入了"自我改进"的循环。
实操建议：如果你的项目里奖励模型是静态的，训练到一定步数后一定要停下来重新校准。一个简单的判断信号是——看策略输出的平均长度和奖励分数的相关性。如果长度和分数强正相关，而内容质量没提升，八成是奖励模型被钻空子了。
3.2 优势估计与方差控制：让梯度别那么吵
RL 训练里，梯度噪声主要来自优势估计的方差。PPO 用 GAE（广义优势估计）来平衡偏差和方差，但 GAE 的 λ 参数在长序列任务里很难调。λ 接近 1，方差大；λ 接近 0，偏差大。
规模化 RL 的一个实用技巧是分组采样 + 组内归一化。对同一个 prompt 采一组（比如 8 条或 16 条）轨迹，用组内奖励的均值和标准差做归一化，得到相对优势。这样做的妙处是，优势信号只依赖组内相对好坏，不依赖绝对奖励尺度，天然抗奖励尺度漂移。GRPO 这类方法就是基于这个思路，省掉了 critic 网络，显存和计算都省一大截。
但组内归一化有个前提：组内必须有奖励差异。如果一组 8 条轨迹奖励全一样（比如全对或全错），归一化后优势全是 0，这条样本就白采了。所以任务难度的动态调节很重要——太简单的题全对，太难的题全错，都产生不了有效梯度。理想状态是让每个 prompt 的通过率维持在 30% 到 70% 之间。这就引出了"自我改进"里最核心的一环：难度自适应。
3.3 难度自适应：让训练永远卡在"跳一跳够得着"
这是我认为 MiMo-V2.6 最值得深挖的部分。所谓自我改进的规模化，很大程度上体现在训练流程能自动找到当前模型的能力边界，并把训练资源集中在边界附近。
具体怎么做？一个可落地的方案是维护一个任务池，每个任务带一个难度标签（可以是初始难度，也可以是根据历史通过率动态更新的难度）。训练时按难度分层采样，优先采那些当前通过率处于中间区间的任务。通过率太高的任务降权，太低的也降权。这样模型始终在"稍微努力就能做对"的区域训练，梯度效率最高。
这个机制听起来简单，工程上有几个坑。第一，通过率估计本身有噪声。你用一个 batch 的采样去估计通过率，方差可能很大，导致难度标签频繁抖动，采样分布不稳定。解决办法是用滑动平均或者贝叶斯方法平滑估计，别用单次结果。第二，任务池的难度分布会随训练漂移。今天的中等难度，明天可能就变成简单了。所以难度标签要持续更新，不能一锤定音。第三，防止任务池枯竭。如果所有任务都被刷到高通过率，就没有有效训练信号了。这时候需要引入新任务，或者对现有任务做变体增强。
我自己的项目里用过类似机制，最大的体会是：难度自适应的收益在训练后期特别明显。前期模型能力弱，什么任务都是低通过率，自适应发挥不了太大作用；到了中后期，模型能力上来了，如果没有自适应，大量算力会浪费在已经掌握的任务上，训练曲线很快就平了。加上自适应之后，同样的算力预算，最终指标能高出一截。
3.4 从单轮 RL 到多轮 Agentic RL 的跨越
关键词里的 agentic 指向一个更难的场景：多轮交互。单轮 RL 里，模型生成一个回答，拿一个奖励，结束。多轮 Agentic RL 里，模型要连续做决策——调工具、看结果、再决策，直到任务完成或失败。奖励可能只在最后给，中间步骤没有即时反馈。这就是典型的稀疏奖励 + 信用分配问题。
处理这个问题，常见思路有几种。一是过程奖励模型（PRM），给中间步骤也打分，把稀疏奖励变稠密。但 PRM 的标注成本极高，而且容易引入偏差。二是蒙特卡洛树搜索式的轨迹评估，对中间状态做 rollout 估计价值，但计算开销大。三是结果奖励 + 优势回传，只在最终给奖励，靠 GAE 把信号回传到中间步骤，简单但信用分配精度有限。
MiMo-V2.6 作为 agentic 方向的模型，我猜它在多轮场景里用的是混合策略：能验证的中间步骤（比如工具调用是否成功、格式是否正确）给即时小奖励，最终任务完成给大奖励。这样既保证了信号密度，又不至于让过程奖励主导训练。实操中，过程奖励的权重一定要小于结果奖励，否则模型会学会"刷中间步骤"而不真正完成任务。我见过一个反例，模型学会了反复调用同一个工具来刷过程分，最后任务根本没完成，但训练奖励很高。
4. 开源大模型做 RL 后训练，绕不开的工程现实
4.1 训练框架选型：别被"全家桶"绑架
现在做 RL 后训练，框架选择基本决定了你后面踩坑的姿势。主流路线大概三类：一类是基于通用训练框架自己搭 RL 循环，灵活但什么都得自己写；一类是专门的 RL 训练库，封装好了 PPO、GRPO 这些算法，上手快但定制难；还有一类是推理引擎 + 训练框架的组合，采样用高性能推理引擎，训练用成熟框架，中间靠参数同步打通。
我的建议是，如果你的任务比较标准（单轮、可验证奖励），直接用封装好的 RL 库，别重复造轮子。但如果你要做 agentic 多轮、自定义环境交互，那大概率得自己搭，因为现成库对多轮环境的支持普遍不成熟。自己搭的时候，重点把采样和训练解耦做好，采样侧用支持高并发的推理引擎，训练侧用你熟悉的框架，中间用队列或者共享存储传轨迹。
有个细节容易被忽略：参数同步的频率。采样用的模型参数和训练用的参数如果同步太频繁，通信开销大；同步太慢，采样用的策略就太旧，off-policy 程度高，训练不稳定。一般做法是每更新 N 步同步一次，N 取多少要看你的 batch 大小和任务。经验值是让采样策略和当前策略的 KL 散度控制在一个阈值内，超过就强制同步。
4.2 显存与吞吐的平衡：RL 比 SFT 更吃资源
RL 训练的资源占用比 SFT 高得多，因为同时要驻留：策略模型、参考模型（算 KL 用）、奖励模型、优化器状态，再加上采样时的 KV cache。MoE 模型虽然激活稀疏，但所有专家的参数都得驻留显存，总参数量摆在那，显存压力一点不小。
省显存的几个实用手段：参考模型和奖励模型可以用低精度或者量化版本，它们只做前向，对精度没那么敏感；优化器状态用分片或者低秩近似；采样时的 KV cache 用分页管理，避免碎片。还有一个狠招是策略模型和参考模型共享底层参数，只在需要算 KL 的时候临时切换，但这要求框架支持，不是所有场景都能用。
吞吐方面，RL 的瓶颈通常在采样。采样是自回归生成，天生比训练的前向慢。提升采样吞吐最有效的是批量并发 + 连续批处理（continuous batching），让不同序列的生成动态拼批，别等最长的序列。这个在推理引擎里基本是标配了，自己搭的话一定要实现。
4.3 训练不稳定的典型症状与排查顺序
RL 训练不稳定是常态，稳定才是意外。我总结了一套排查顺序，按这个走能省不少时间。
先看奖励曲线。如果奖励突然飙升但生成质量没变，大概率是奖励黑客，去查奖励模型的漏洞。如果奖励震荡剧烈，先看优势估计的方差，可能是组内样本太少或者任务难度分布太极端。
再看KL 散度。KL 爆炸说明策略跑太偏了，要么是学习率太大，要么是 KL 惩罚系数太小。KL 长期接近 0 说明策略没怎么更新，可能是奖励信号太弱或者优势全被归一化掉了。
然后看熵。策略熵快速下降意味着探索能力丧失，模型开始重复输出。这时候要么加熵奖励，要么调大温度，要么检查是不是任务太单一。
最后看路由指标（MoE 专属）。路由熵塌缩、专家负载严重不均，都会导致训练后期性能停滞。
这套顺序的逻辑是：从最外层的信号（奖励）往里查，先排除奖励设计问题，再查优化层面的问题，最后查架构层面的问题。大部分不稳定都能在前两步定位到。
5. 几个我认为最值得警惕的认知误区
5.1 "自我改进"不等于"不需要人"
这是最容易被营销话术带偏的一点。所谓自我改进，改进的是训练流程内部的调节机制，但目标定义、奖励设计、安全边界这些顶层的东西，还是人定的。模型不会自己决定"我应该变得更诚实"或者"我不应该输出有害内容"，这些价值观约束必须由人注入。
而且自我改进循环有个内在风险：目标漂移。如果奖励模型本身有偏差，策略在自我改进过程中会不断放大这个偏差，越改越偏。所以自我改进的系统里，人的角色从"每一步都盯着"变成"定期校准目标和奖励"，工作量没少，只是形式变了。
5.2 规模化 RL 的收益不是线性的
很多人以为算力堆上去，RL 效果就线性提升。实际完全不是。RL 的收益曲线通常是先陡后平，而且平的拐点来得比预想早。原因就是前面说的，有效训练信号（通过率在中间区间的任务）是有限的，算力再多，没有足够的有效任务，梯度就那么多。
所以规模化 RL 的关键不是无脑加算力，而是同步扩大有效任务池。任务池的扩展速度跟不上算力扩展速度，多出来的算力就是浪费。这也是为什么"自我改进"里任务生成和难度调节这么重要——它直接决定了算力能不能转化成能力。
5.3 开源不等于开箱即用
MiMo-V2.6 是开源的，但开源权重和能跑起来是两码事。RL 后训练对基础设施的要求很高，分布式训练、高性能推理、大规模数据管线，缺一不可。个人开发者或者小团队想复现完整流程，现实难度很大。比较务实的路径是：先用开源权重做推理和评测，理解模型能力边界；再从小规模 RL 实验入手，比如单机多卡跑一个小任务，把流程跑通；最后再考虑规模化。
别一上来就想着复现论文里的全部规模，那大概率会让你在基础设施上耗光耐心。我见过太多人卡在环境配置和分布式调试上，模型本身反而没怎么研究。
6. 如果我要在自己的项目里借鉴这套思路
假设你手里有一个中等规模的开源模型，想用 RL 把它在某个垂直任务上的能力提上去，我会这么排优先级。
第一，把奖励做扎实。垂直任务通常有明确的成功标准，尽量用可验证奖励，少用主观打分。如果必须用奖励模型，先花时间把奖励模型的准确率做上去，别急着开 RL。奖励不准，后面全白搭。
第二，把采样吞吐拉满。RL 的迭代速度取决于采样速度。先把推理引擎调优，连续批处理、KV cache 管理、并发度这些调到位，再开始训练。采样慢，实验周期就长，调参效率低。
第三，从单轮、可验证的任务起步。别一上来就搞多轮 agentic，信用分配和奖励设计的复杂度会让你怀疑人生。先用单轮任务把 RL 流程跑稳，理解你的模型在这个任务上的学习动态，再逐步加复杂度。
第四，难度自适应尽早加。哪怕是最简单的按通过率分层采样，也比均匀采样强。这个机制实现成本不高，收益却很直接。
第五，监控指标要全。奖励、KL、熵、长度、路由指标（如果是 MoE），一个都别少。RL 训练出问题时，单一指标往往看不出根因，得靠多个指标交叉判断。
最后分享一个我踩过的坑：别在 RL 训练中途随意改奖励函数。我早期做过一次，训练到一半觉得奖励设计不够好，直接改了奖励函数继续训。结果策略在旧奖励下形成的偏好和新奖励冲突，训练直接崩了，loss 震荡到没法看。正确做法是，要么停下来重新开始，要么用课程学习的方式平滑过渡奖励，别硬切。
这套东西说到底，RL 后训练是个系统工程，算法只是其中一环。MiMo-V2.6 把"自我改进"和"规模化"放在一起讲，本质上是在说：单点算法突破的时代过去了，现在拼的是把算法、架构、数据、基础设施拧成一股绳的能力。谁的系统更稳、迭代更快，谁就能把开源模型的天花板往上顶一顶。
