1. 从标题拆解 MiMo-V2.6 的技术野心

1.1 这个标题到底在说什么

第一次看到《MiMo-V2.6：通过扩展强化学习实现模型自我提升》这个标题，我的直觉是：这不是一篇普通的模型发布公告，而是一份技术报告。标题里有两个关键词特别扎眼——扩展强化学习和模型自我提升。前者说的是方法路径，后者说的是目标状态。把这两个词放在一起，其实是在描述一个闭环：模型不再只是被动地吃数据、做下一词预测，而是通过强化学习这套机制，在训练过程中不断给自己"出题、打分、纠偏"，从而实现能力上的自我迭代。

MiMo-V2.6 这个命名方式，说明它是一个迭代版本，前面的 V2.x 系列应该已经积累了若干代经验。从公开的技术报告惯例来看，这类版本号通常意味着架构层面有延续性，但在训练范式上做了关键升级。结合热搜词里反复出现的MoE、RL、LLM，基本可以判断：MiMo-V2.6 是一个基于混合专家架构的大语言模型，核心卖点是把强化学习的规模推到了一个新的量级，并且这套 RL 流程是围绕"自我提升"设计的，而不是单纯做人类偏好对齐。

1.2 为什么"自我提升"这四个字值得单独拎出来

在大模型圈子里，"自我提升"不是一个新词，但真正把它做成工程闭环的团队并不多。早期的做法通常是：先用监督微调把模型拉到及格线，再用人类反馈强化学习做偏好对齐。这套流程的问题在于，人类标注是有上限的——成本高、速度慢、覆盖场景有限。当模型能力越来越强，人类能提供的有效信号反而越来越少。

MiMo-V2.6 技术报告里强调的"扩展强化学习"，我理解核心在于两点：一是把 RL 的训练信号来源从纯人类偏好，扩展到模型自身可验证的任务上；二是把 RL 的规模做大，让模型在大量可自动判定对错的任务上反复试错。这就像教一个学生，早期需要老师手把手批改作业，到了高年级，可以让他自己做题、自己对答案、自己总结错题本。老师的作用从"逐题批改"变成"设计题库和评分标准"。

这个转变的工程意义非常大。它意味着模型的提升不再线性依赖标注团队的人力，而是可以随着算力投入持续放大。这也是为什么标题里用的是"扩展"（scaling）这个词——它暗示这套 RL 方法是可扩展的，不是小打小闹的技巧。

1.3 适合谁来读这份技术报告

如果你是大模型训练方向的工程师，这份报告的价值在于它给出了 RL 扩展的具体工程细节：奖励怎么设计、训练怎么稳定、MoE 架构下 RL 有什么特殊坑。如果你是算法研究者，值得关注的是它如何定义"可验证任务"以及如何避免奖励黑客。如果你只是对大模型技术感兴趣的开发者，报告里关于 MoE 和 RL 结合的部分，能帮你理解当前开源模型和头部模型之间的差距到底在哪。

我个人的判断是，MiMo-V2.6 这份报告最值得反复读的，不是最终刷出来的 benchmark 数字，而是中间那些"我们试了什么、什么没work、最后怎么绕过去"的记录。这些才是真正能迁移到你自己项目里的东西。

2. 核心架构与训练范式的选型逻辑

2.1 为什么是 MoE 而不是稠密模型

MiMo-V2.6 选择 MoE（混合专家）架构，这个决策背后有很现实的算力账。稠密模型要提升能力，最直接的办法是加参数，但参数一加，每次前向传播的计算量就跟着涨，推理成本线性上升。MoE 的思路是：把模型拆成多个专家子网络，每次输入只激活其中一小部分。这样总参数量可以做得很大，但单次计算量控制在可接受范围。

用一个生活化的类比：稠密模型像一家所有菜都由一个全能厨师做的餐厅，厨师要会做川菜、粤菜、日料、甜点，培养成本极高，而且每道菜他都要亲自上手。MoE 像一家有多个专精厨师的餐厅，来了川菜订单就派川菜师傅，来了甜点就派甜点师傅，每个师傅只需要精通自己那一块，整体出品效率更高。

但 MoE 不是没有代价。它最大的挑战是负载均衡——如果所有输入都涌向同一个专家，其他专家就闲置了，等于白养。所以 MoE 训练里通常要加辅助损失来鼓励专家分流。MiMo-V2.6 在 RL 阶段还要额外考虑一个问题：RL 的梯度信号和 MoE 的路由机制会相互影响，路由不稳定会导致训练震荡。这一点在后面的实操部分我会展开讲。

2.2 强化学习在 LLM 训练里的位置

很多人容易把 RL 和 SFT（监督微调）混为一谈，其实两者解决的问题完全不同。SFT 是"模仿"——给模型看大量标准答案，让它学会在类似输入下输出类似结果。RL 是"试错"——模型自己生成多个候选答案，根据奖励信号调整生成策略，好的行为被强化，差的行为被抑制。

MiMo-V2.6 的技术路线，我推测是典型的三段式：预训练打底、SFT 对齐格式、RL 提升能力上限。RL 之所以关键，是因为它能让模型探索到 SFT 数据里没有的解法。SFT 的天花板是标注数据的质量，而 RL 的天花板是奖励函数的设计水平。只要奖励函数能准确判断"什么是好答案"，模型就有可能通过大量采样找到人类标注者都没想到的更优解。

这也是"自我提升"的技术基础：当任务本身可验证（比如数学题有唯一答案、代码能跑通测试用例），模型就可以自己生成大量候选、自己判定对错、自己更新策略，形成一个不依赖人工标注的正反馈循环。

2.3 扩展强化学习的三个扩展维度

标题里的"扩展"不是随便用的。结合当前 RL 训练的主流实践，扩展通常发生在三个维度上：

第一是数据扩展。可验证任务的规模要足够大，否则模型很快会过拟合到有限的任务集上。MiMo-V2.6 应该构建了一个覆盖面很广的任务池，涵盖数学、代码、逻辑推理等可自动判定的领域。

第二是采样扩展。RL 需要模型对同一个问题生成多个答案来估计策略梯度。采样数量越多，梯度估计越准，但计算成本也越高。扩展采样意味着在单位训练步内生成更多候选，这对推理引擎的吞吐提出了很高要求。

第三是训练步数扩展。RL 训练容易出现奖励饱和——模型很快学会拿高分的套路，然后停滞。要持续提升，需要不断调整任务难度分布，让模型始终处在"跳一跳够得着"的区域。这需要一套动态的课程机制。

这三个维度里，我认为最难的是第三个。数据扩展和采样扩展本质上是堆资源，而课程设计是真正的算法活。MiMo-V2.6 报告里如果有关于难度调度的细节，那是最值得细读的部分。

3. 强化学习流程的关键细节与实操要点

3.1 奖励函数设计：可验证任务是核心抓手

RL 训练成败的第一决定因素是奖励函数。MiMo-V2.6 走的是"可验证任务"路线，这意味着奖励不是来自一个训练好的奖励模型（reward model），而是来自确定性的验证器。数学题对答案、代码跑单元测试、逻辑题检查约束满足，这些都是可验证的。

这样做的好处非常明显：奖励信号没有噪声，不存在奖励模型被"忽悠"的问题。但坏处也很直接：可验证任务的覆盖面有限。写作、开放问答、创意生成这些任务没有唯一正确答案，很难用规则验证。所以 MiMo-V2.6 的能力提升，大概率集中在推理密集型任务上，而不是全面开花。

我在实际做 RL 训练时踩过的一个坑是：验证器写得太严格，导致模型大量输出被判错，奖励信号稀疏，训练几乎不动。后来改成部分给分——比如数学题答案格式对但计算错，给 0.3 分；格式和答案都对给 1 分——训练才跑起来。这个经验对做类似项目的人应该有用。

3.2 策略梯度估计与方差控制

LLM 的 RL 训练通常用策略梯度方法，最主流的是 PPO 及其变体。核心思想是：对每个问题采样多个答案，根据奖励高低调整每个答案的生成概率。奖励高于平均的答案，提高其概率；低于平均的，降低其概率。

这里有个技术细节很关键：优势估计。直接用原始奖励做梯度，方差会非常大，训练不稳定。常见做法是减去一个基线（baseline），通常是同一问题下所有采样答案的平均奖励。这样做的效果是，模型只关心"相对好坏"，不关心绝对分数，梯度方差大幅降低。

MiMo-V2.6 作为大规模 RL 训练，肯定在方差控制上做了不少工作。我推测它可能用了组内归一化（group normalization）之类的技巧，把同一 prompt 下的多个采样作为一个组，组内做标准化。这种做法在近期的开源 RL 实现里很常见，效果也确实稳。

3.3 MoE 架构下 RL 训练的特殊处理

MoE 和 RL 结合，有一个稠密模型没有的坑：路由漂移。RL 训练会改变模型的输出分布，而 MoE 的路由网络是根据输入特征决定激活哪些专家的。当输出分布变化时，路由决策也会跟着变，可能导致某些专家突然被大量激活，另一些被冷落。这种不均衡会进一步加剧训练震荡。

常见的应对手段有两个。一是冻结路由网络，只训练专家网络和注意力层。这样做的好处是路由稳定，坏处是模型失去了根据任务动态调整专家分配的能力。二是给路由加一个熵正则项，鼓励路由分布保持一定的多样性，避免坍缩到少数专家。

我个人的经验是，在 RL 训练早期，路由确实容易乱，这时候可以先用较小的学习率让模型适应，等奖励曲线稳定后再逐步放大学习率。MiMo-V2.6 报告里如果提到了路由相关的稳定性技巧，那对做 MoE+RL 的团队来说是刚需。

3.4 训练稳定性：KL 约束不能省

RL 训练最怕的是模型跑偏——为了拿高奖励，生成一些人类看起来莫名其妙但恰好能通过验证器的内容。这就是所谓的"奖励黑客"。防止这个问题的主要手段是加 KL 约束：在优化奖励的同时，惩罚当前策略偏离参考策略（通常是 SFT 后的模型）太远。

KL 系数的选择是个经验活。系数太大，模型不敢探索，能力提升有限；系数太小，模型放飞自我，输出质量崩坏。我试过的做法是动态调整：训练初期用较大的 KL 系数稳住，等模型适应了 RL 流程再逐步放松。MiMo-V2.6 作为大规模训练，应该有一套自适应的 KL 调度策略。

注意：KL 约束是参考策略和当前策略之间的散度，参考策略一旦选定就不要中途更换，否则约束会失效，训练容易崩。

4. 完整实操流程与关键环节复现

4.1 整体训练流水线拆解

如果要复现 MiMo-V2.6 这类"扩展强化学习"的训练流程，整体流水线大致分四个阶段：

阶段一：基础模型准备。拿一个预训练好的 MoE 基座，先做 SFT，让模型学会遵循指令、输出格式规范。这一步的产出是参考策略，后续 RL 的 KL 约束就锚定在它身上。

阶段二：任务池构建。收集或生成大量可验证任务，按难度分层。数学题可以从简单算术到竞赛级证明，代码题可以从单函数实现到多文件项目。每个任务都要配一个确定性验证器。

阶段三：RL 训练循环。对每个任务，用当前策略采样多个答案，验证器打分，计算优势，更新策略。同时监控 KL 散度、奖励均值、答案长度等指标。

阶段四：评估与迭代。在留出任务集上评估，看能力是否真的提升，而不是过拟合到训练任务。根据评估结果调整任务难度分布，进入下一轮。

这个流水线听起来直白，但每个阶段都有大量工程细节。下面我挑几个最关键的展开。

4.2 任务难度调度：让模型始终"跳一跳够得着"

RL 训练最理想的状态是模型成功率维持在 50% 左右。成功率太高，任务太简单，梯度信号弱；成功率太低，任务太难，模型几乎拿不到正奖励，也学不动。

实现难度调度的常见做法是维护一个任务难度估计。每轮训练后，统计每个任务的成功率，把成功率过高的任务标记为"太简单"，成功率过低标记为"太难"，然后从任务池里补充中等难度的新任务。MiMo-V2.6 作为大规模训练，任务池应该有自动生成和难度标注的机制。

我实操时的经验是：难度调度不要做得太激进。如果每轮都大幅调整任务分布，模型会一直在适应新分布，反而学不到稳定能力。比较稳的做法是每 N 轮调整一次，且每次只替换一小部分任务。

4.3 采样与推理的工程优化

RL 训练的计算开销大头在采样。每个训练步要对一批任务各生成多个答案，这本质上是一次大规模推理。如果推理引擎效率低，整个训练就被拖垮。

优化方向有几个。一是用连续批处理（continuous batching），把不同长度的生成请求动态打包，提高 GPU 利用率。二是用 KV 缓存复用，同一 prompt 的多个采样可以共享前缀的 KV 缓存，只对分叉后的部分重新计算。三是控制生成长度，RL 训练里模型容易生成越来越长的答案来"凑"正确性，需要设置长度惩罚。

MiMo-V2.6 报告里如果提到采样吞吐的具体数字，可以拿来估算它的训练规模。比如每步采样多少条、每秒生成多少 token，这些数字能反推出它用了多少卡、训练了多久。

4.4 奖励归一化与优势计算的具体实现

这一块是 RL 训练的数学核心，我用伪代码说明常见实现：

# 对每个 prompt 采样 G 个答案 rewards = [verifier(prompt, answer) for answer in answers] # 形状 [G] # 组内归一化，计算优势 mean_r = sum(rewards) / G std_r = sqrt(sum((r - mean_r)**2 for r in rewards) / G + eps) advantages = [(r - mean_r) / std_r for r in rewards] # 策略梯度损失（简化版） pg_loss = 0 for i, answer in enumerate(answers): ratio = exp(logprob_current(answer) - logprob_old(answer)) clipped_ratio = clip(ratio, 1 - eps_clip, 1 + eps_clip) pg_loss += -min(ratio * advantages[i], clipped_ratio * advantages[i]) / G # 加上 KL 惩罚 kl_penalty = kl_divergence(current_policy, reference_policy) total_loss = pg_loss + beta * kl_penalty

这段代码里，eps是防止除零的小量，eps_clip是 PPO 的裁剪系数，通常取 0.2，beta是 KL 惩罚系数。实际训练里这些超参都要调，而且不同任务可能需要不同的值。

提示：组内归一化要求每个 prompt 至少采样 4 个答案，否则均值和方差估计不准。采样数越多越稳，但成本也越高，一般 8 到 16 是常见区间。

5. 常见问题与排查技巧实录

5.1 奖励不涨或涨到一半停滞

这是 RL 训练最常见的问题。排查顺序我一般是这样：

先看奖励分布。如果所有答案奖励都差不多，说明任务太简单或太难，模型没有区分度。如果奖励方差很大但均值不涨，说明模型在探索但没找到正确方向，可能是奖励函数设计有问题。

再看 KL 散度。如果 KL 一直很小，说明模型不敢偏离参考策略，探索不足，需要调小 KL 系数。如果 KL 爆炸式增长，说明模型跑偏了，需要调大 KL 系数或降低学习率。

最后看答案长度。如果长度持续增长但奖励不涨，模型可能在"凑字数"，需要加长度惩罚。

5.2 训练过程中突然崩溃

RL 训练崩溃的表现通常是奖励断崖式下跌、KL 散度飙升、生成内容变得重复或无意义。原因可能是学习率过大、某个 batch 的奖励异常、或者 MoE 路由坍缩。

应急处理是回滚到上一个 checkpoint，降低学习率，检查最近的数据里有没有异常样本。预防措施是加梯度裁剪、监控每个 batch 的奖励分布、定期保存 checkpoint。

5.3 MoE 专家利用率严重不均

如果发现某些专家几乎不被激活，说明路由出了问题。可以检查路由 logits 的分布，如果某个专家的 logit 持续偏高，说明路由坍缩了。解决办法是加负载均衡损失，或者临时冻结路由网络，让专家先各自学好。

5.4 常见问题速查表

5.5 几个容易被忽略的实操心得

第一个心得：验证器要先自测。在正式训练前，拿一批已知正确答案的样本过一遍验证器，确保它不会误判。我见过验证器把正确答案判错的情况，导致模型学了一堆错误行为。

第二个心得：保留一部分任务不参与训练。这些留出任务用来评估模型是否真的泛化了，而不是记住了训练任务的答案。留出集的比例一般 5% 到 10%。

第三个心得：RL 训练不要一次跑太久。训练时间越长，模型越容易过拟合到奖励函数的漏洞上。比较稳的做法是训练一段时间就评估一次，发现评估指标不再提升就停，而不是死磕训练奖励。

第四个心得：记录每个任务的采样答案。出问题时可以回溯，看模型到底生成了什么。这些日志在调试奖励黑客问题时特别有用。

6. 从 MiMo-V2.6 看 RL 训练的未来走向

6.1 可验证任务的天花板在哪

MiMo-V2.6 走的可验证任务路线，能力上限取决于可验证任务的覆盖面。数学、代码、逻辑这些领域天然可验证，但写作、对话、创意这些领域很难。如果 RL 训练只在这些可验证领域做，模型可能变成"偏科生"——推理很强，但表达和交互能力没跟上。

我推测 MiMo-V2.6 的后续版本会往两个方向走：一是扩展可验证任务的边界，比如用形式化方法验证更多类型的推理；二是把 RL 和奖励模型结合，用奖励模型处理不可验证任务，同时用可验证任务校准奖励模型，减少奖励黑客。

6.2 自我提升的边界与风险

"模型自我提升"听起来很美好，但有个根本问题：模型能提升到超过它自己判断能力的水平吗？如果验证器是模型自己写的，那验证器的水平就是天花板。所以真正的自我提升，前提是有一个比模型当前能力更强的验证信号。这个信号可以来自形式化系统、可以来自人类专家、也可以来自多个模型的交叉验证。

另一个风险是能力退化和价值观漂移。RL 训练只优化奖励函数定义的目标，如果奖励函数没覆盖某些重要维度，模型可能在这些维度上退化。比如只优化数学正确率，模型可能变得只会输出答案，不会解释过程。所以 RL 训练必须配合全面的评估体系，不能只看单一指标。

6.3 对做 RL 训练的团队的建议

如果你正在或准备做 LLM 的 RL 训练，我的建议是：先把 SFT 做扎实，再碰 RL。SFT 没做好，RL 的参考策略就是歪的，KL 约束锚在一个差模型上，训练很难好。然后从小规模开始，用几百个任务跑通流程，确认奖励能涨、训练稳定，再逐步扩大任务池和采样规模。

工具选型上，推理引擎优先选支持连续批处理和 KV 缓存复用的，训练框架优先选支持 MoE 和分布式 RL 的。不要自己从零造轮子，除非你的团队有很强的系统能力。

最后，RL 训练是个需要耐心的活。奖励曲线不会一直涨，中间会有平台期、会有回退，关键是建立一套可靠的监控和回滚机制，让每次实验都能快速定位问题。MiMo-V2.6 这份报告最大的价值，就是把这些工程细节摊开给你看，让你少走一些弯路。