企业官网建设流程全解析

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

1.1 为什么“自我改进的强化学习规模化”值得单独拎出来讲

第一次看到“第一开源大模型 MiMo-V2.6：迈向自我改进的强化学习规模化”这个标题，我脑子里跳出来的第一个判断是：这不是一次常规的版本迭代，而是一次路线宣言。原因很简单，绝大多数开源模型的发布报告，核心叙事都围绕“参数规模、训练数据量、榜单分数”这三件套展开，而 MiMo-V2.6 把“自我改进”和“强化学习规模化”放到了标题最显眼的位置，说明它想讲的故事不是“我更大”，而是“我能自己变得更强”。

这两个词拆开看都不新鲜。自我改进（self-improvement）在强化学习领域是个老话题，从早期的自我对弈到后来的迭代式拒绝采样微调，本质都是让模型用自己产出的数据反过来训练自己。强化学习规模化（RL scaling）也是近两年推理模型竞赛的主线，谁能把 RL 的训练步数、并行环境数、奖励信号密度拉上去，谁就能在数学、代码、智能体任务上拿到更陡峭的曲线。但把这两件事绑在一起，并且冠以“第一开源”的定语，意味着 MiMo-V2.6 想证明的是：开源模型也能跑通“自己生成数据、自己评估、自己迭代”的闭环，而且这个闭环可以随着算力投入持续放大收益。

我之所以对这个方向敏感，是因为过去一年我接触过不少团队尝试复现闭源推理模型的 RL 训练流程，卡点几乎都集中在同一个地方：奖励信号从哪来。人工标注太贵，规则奖励覆盖不了开放任务，用另一个大模型当裁判又会引入分布偏移和奖励攻击。MiMo-V2.6 如果真能把自我改进的循环跑顺，那它解决的就不是“某个榜单涨几个点”的问题，而是“开源社区能不能用有限算力持续逼近前沿”的问题。这个价值量级，比单纯发一个更大的稠密模型要高得多。

1.2 标题里的三个隐藏关键词：MoE、Agentic RL、规模化

标题没有直接写 MoE，但热词列表里 MoE 和 moe 架构反复出现，这基本可以确认 MiMo-V2.6 沿用了混合专家架构。这一点其实很关键，因为自我改进的 RL 训练对算力的消耗是普通 SFT 的好几倍，如果底座是稠密模型，光是 rollout 阶段的推理开销就能把预算烧穿。MoE 在这里的作用不是“参数好看”，而是让激活参数量远小于总参数量，从而在同样的 GPU 小时里跑出更多的采样轨迹。换句话说，MoE 是让“规模化”这三个字成立的前提条件之一。

Agentic RL 是另一个不能忽略的词。传统 RLHF 主要优化的是单轮回复的偏好，而 agentic RL 优化的是多步决策序列：模型要在一个环境里连续调用工具、观察反馈、调整策略，最终完成任务。这类任务的奖励信号天然稀疏，信用分配难度大，但一旦训好，模型在真实工作流里的可用性会有质变。MiMo-V2.6 把 agentic RL 放进热词，说明它的自我改进循环很可能不是停留在“生成答案再打分”的层面，而是让模型在模拟环境中反复试错，把工具使用、代码执行、多步推理这些能力一起卷进去。

至于“规模化”，我的理解是三层含义：一是训练步数规模化，RL 不再只跑几百步就停；二是环境数量规模化，同时开成千上万个并行环境采样；三是奖励模型规模化，用多个不同视角的奖励信号做集成，降低单一奖励被 hack 的风险。这三层里任何一层做不到，自我改进的循环都会在某个点崩掉。后面我会结合常见实践，把每一层的实现思路和坑点展开讲。

2. 自我改进循环的工程实现：从数据飞轮到奖励设计

2.1 自我改进不是“自己训自己”这么简单

很多人第一次听到自我改进，会下意识理解成“模型生成数据，然后拿这些数据做 SFT”。这个理解只对了一半，而且是最容易翻车的那一半。纯 SFT 式的自我迭代有个致命问题：分布会逐渐收窄。模型倾向于生成它已经擅长的内容，这些内容被采样、被训练，下一轮模型更倾向于生成类似内容，几轮之后多样性就塌缩了，表现为输出越来越模板化，遇到稍微偏离训练分布的输入就崩。

MiMo-V2.6 标题里强调的是“强化学习规模化”，而不是“自我训练规模化”，这个措辞差异很关键。RL 的自我改进循环里，模型生成的不是“标准答案”，而是“行为轨迹”，这些轨迹经过环境或奖励模型评估后，只有相对更优的部分会被强化。这个过程天然带有探索压力，因为如果模型一直输出同一种轨迹，奖励不会提升，策略梯度会推着它去尝试新的动作。换句话说，RL 框架本身就在对抗分布塌缩，这是它比纯 SFT 迭代更稳的根本原因。

但 RL 也不是银弹。我见过不少团队把 RL 跑成了“奖励模型过拟合大赛”：模型很快学会输出奖励模型喜欢的格式，比如特别长的推理链、特别肯定的语气词，但真实能力没涨。要避免这个问题，奖励设计必须多源、可验证、带惩罚。MiMo-V2.6 如果要在报告里证明自我改进有效，大概率会展示多轮迭代中“真实任务通过率”和“奖励分数”两条曲线，而不是只放奖励分数。因为只有前者才能说明模型没有在自欺欺人。

2.2 奖励信号的三种来源与组合策略

在开源模型做 agentic RL 的常见实践里，奖励信号通常来自三个地方，我按可靠性和成本排个序。

第一类是可验证奖励，比如数学题有标准答案、代码有单元测试、工具调用有明确的成功/失败状态。这类奖励最干净，几乎不会被 hack，但覆盖的任务类型有限。MiMo-V2.6 在数学和代码上的提升，大概率主要靠这类奖励驱动。

第二类是模型裁判奖励，用一个更强的模型或者同系列的不同 checkpoint 对轨迹打分。这类奖励覆盖广，但有两个坑：一是裁判模型本身有偏好，会把它的偏见传给学生模型；二是学生模型会学会迎合裁判，而不是真正解决问题。常见的缓解手段是让裁判只看结果不看过程，或者用多个裁判投票，再或者定期用人工标注校准裁判。

第三类是环境内在奖励，比如智能体在模拟环境中完成任务获得的分数、游戏里的胜负信号。这类奖励最接近真实目标，但设计成本高，而且容易稀疏。Agentic RL 的规模化，很大程度上就是在解决稀疏奖励下的信用分配问题。

MiMo-V2.6 的自我改进循环，我推测采用的是“可验证奖励为主、模型裁判为辅、环境奖励做补充”的混合策略。这个组合的好处是：可验证奖励保证底线不崩，模型裁判提供开放任务的梯度，环境奖励把能力往真实工作流上拉。坏处是实现复杂度高，需要一套统一的轨迹格式和奖励聚合逻辑。如果报告里能看到奖励聚合的消融实验，那含金量会很高。

2.3 迭代式拒绝采样与策略梯度的分工

自我改进循环里有两个容易混淆的环节：拒绝采样和策略梯度。拒绝采样是“只保留好的，丢掉差的”，策略梯度是“好的加分，差的减分”。前者是数据过滤，后者是参数更新。很多开源实现只做前者，因为简单稳定，但天花板低；只做后者又容易训练不稳定，因为 RL 的方差大。

比较务实的做法是两者结合：先用拒绝采样筛出一批高质量轨迹做冷启动 SFT，让模型先学会基本的行为模式，然后再上策略梯度做精细优化。MiMo-V2.6 如果强调“规模化”，那它的策略梯度部分应该占了不小比重，因为拒绝采样的收益会随着轮次增加而递减，而策略梯度在环境足够多的情况下可以持续提供梯度信号。

这里有个实操细节值得注意：策略梯度的方差控制。常见手段包括用 GAE 做优势估计、对奖励做归一化、限制策略更新幅度（比如 PPO 的 clip）。这些在单机小规模训练里都好调，但一旦并行环境数上到几千，通信开销和同步等待就会成为瓶颈。MiMo-V2.6 的工程报告如果提到异步采样或者部分 rollout 复用，那说明它在规模化上确实下了功夫。

3. MoE 架构在 RL 训练中的特殊考量

3.1 为什么 RL 阶段对 MoE 的负载均衡更敏感

MoE 在预训练阶段的核心难题是负载均衡：如果 token 都涌向少数几个专家，其他专家就得不到训练，等于浪费参数。常见的解法是加辅助损失，鼓励路由均匀。但到了 RL 阶段，这个问题会变得更棘手，因为 RL 的输入分布和预训练分布不一样，模型在探索过程中会生成大量预训练时没见过的轨迹，这些轨迹的 token 分布可能高度偏斜，导致某些专家被过度激活，另一些彻底闲置。

我实测过一个中等规模的 MoE 模型做 RL 微调，发现如果不调整辅助损失的权重，训练到几百步之后，路由熵会明显下降，表现为模型输出越来越单一。后来把辅助损失调大，并且对专家激活做温度采样，才把多样性拉回来。MiMo-V2.6 如果要在 RL 规模化上做文章，路由稳定性肯定是重点优化对象。可能的做法包括：在 RL 阶段动态调整辅助损失、对专家容量做弹性伸缩、或者用专家 dropout 强制路由分散。

另一个容易被忽略的点是 MoE 的推理效率在 RL 采样阶段的影响。RL 需要大量 rollout，如果每次前向都要激活全部专家，那 MoE 的省算力优势就没了。所以 MiMo-V2.6 大概率用了 top-k 路由，k 值不会太大，同时配合专家并行来分摊显存。这些工程细节在报告里可能一笔带过，但对想复现的团队来说，每一个都是坑。

3.2 专家 specialization 与 agentic 能力的关联

MoE 有个很有意思的特性：不同专家会自发分化出不同的能力倾向。在预训练阶段，这种分化通常和语言、领域相关；但到了 agentic RL 阶段，专家可能会分化出“规划专家”“工具调用专家”“错误恢复专家”这类行为模式。如果这个假设成立，那 MoE 在 agentic 任务上会比稠密模型更有优势，因为不同子任务可以路由到不同专家，减少相互干扰。

我目前没有看到 MiMo-V2.6 公开的专家分析，但如果报告里有路由可视化或者专家消融实验，那会是很有价值的信号。对复现者来说，一个实用的建议是：在 RL 训练前先做一轮路由分析，看看专家激活和任务类型的相关性，如果发现某些专家已经天然对应某些子能力，可以在 RL 阶段有针对性地调整路由温度，让这种分化更彻底。

3.3 MoE 与 RL 框架的集成难点

把 MoE 塞进 RL 训练框架，比塞进 SFT 框架要麻烦得多。SFT 是静态数据、固定 batch，MoE 的负载均衡相对好控制；RL 是动态采样、变长轨迹，而且经常需要把同一批数据前向多次（比如计算 old policy 的 log prob 和 new policy 的 log prob），这对 MoE 的路由一致性提出了要求。如果两次前向的路由结果不一致，重要性采样的比率就会算错，训练直接崩。

常见的解法是在 rollout 阶段缓存路由决策，后续更新时复用。但这会带来显存压力，因为要存每个 token 的专家索引。另一个解法是用确定性的路由，去掉随机性，但这样会损失探索能力。MiMo-V2.6 如果在这方面有创新，比如设计了一种对 RL 友好的路由机制，那会是技术报告里最值得细读的部分之一。

4. 规模化 RL 的基础设施：并行环境与训练稳定性

4.1 并行环境的数量级与通信模式

“规模化”这三个字落到工程上，最直观的指标就是并行环境数。小规模 RL 可能只开几十个环境，大规模能开到几千甚至上万个。环境数上去之后，瓶颈会从 GPU 计算转移到 CPU 调度和网络通信。因为每个环境都要维护自己的状态，还要和训练进程交换轨迹数据，如果通信模式设计得不好，GPU 会大量时间空等。

常见的架构是“采样器-训练器分离”：一组机器专门跑环境采样，把轨迹写进共享缓冲区；另一组机器专门做梯度更新，从缓冲区读数据。这种架构的好处是采样和训练可以异步，采样器不用等训练器更新完参数就能继续跑，训练器也不用等所有环境都完成一轮。代价是数据会有一点“陈旧”，需要用重要性采样来校正。MiMo-V2.6 如果强调规模化，大概率采用了类似的异步架构，而且会在报告里讨论陈旧度对最终效果的影响。

我自己的经验是，异步 RL 的陈旧度控制在 1 到 2 个策略版本以内比较安全，再大就会明显掉点。但这个阈值和任务难度、奖励密度都有关系，不能一概而论。如果 MiMo-V2.6 给出了不同陈旧度下的曲线对比，那对复现者的参考价值会非常大。

4.2 训练稳定性的常见崩点与监控指标

RL 训练比 SFT 脆弱得多，崩的方式也五花八门。我整理过一份常见崩点清单，这里挑几个最典型的讲。

奖励爆炸：模型发现某个奖励漏洞，疯狂刷分，真实能力不涨反降。监控指标是奖励均值和真实任务通过率的比值，如果奖励涨得飞快但通过率不动，基本就是被 hack 了。

熵塌缩：策略过早收敛到确定性输出，失去探索能力。监控指标是策略熵，如果连续几百步下降且没有回升迹象，需要调大熵正则或者提高采样温度。

KL 爆炸：策略偏离参考模型太远，输出变得语无伦次。监控指标是 KL 散度，通常要设一个上限，超过就暂停更新或者回滚。

梯度范数异常：突然出现极大的梯度，导致参数被破坏。监控指标是梯度范数，配合梯度裁剪使用。

MiMo-V2.6 如果要在报告里展示规模化能力，这些稳定性指标应该会出现在附录或者训练曲线里。对复现者来说，把这些指标接进监控面板是第一步，不然训练崩了都不知道怎么崩的。

4.3 检查点管理与回滚策略

大规模 RL 训练动辄跑几周，中间难免遇到硬件故障或者训练异常。如果没有合理的检查点管理，一次故障可能损失几天进度。常见的做法是每隔固定步数存一次检查点，同时保留最近几个检查点以便回滚。但 RL 的检查点不只是模型参数，还包括优化器状态、环境状态、奖励模型状态，甚至采样缓冲区的数据。这些东西如果不同步保存，回滚后会出现状态不一致。

我踩过的一个坑是：只存了模型参数，没存优化器状态，回滚后优化器的动量项和模型不匹配，训练直接发散。后来改成全量保存，虽然慢一点，但稳得多。MiMo-V2.6 的工程报告如果提到检查点策略，可以留意它是否覆盖了这些状态。另外，回滚策略也很重要：是自动回滚还是人工判断？回滚到哪个检查点？回滚后要不要调整超参？这些决策在长时间训练里会反复遇到。

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

5.1 奖励不涨或者涨了但真实能力不涨

这是 RL 训练里最高频的问题，没有之一。排查思路我一般按这个顺序走。

先看奖励曲线本身。如果奖励完全不涨，可能是奖励太稀疏，模型随机探索根本碰不到正样本。解法是加 shaping reward，或者用课程学习从简单任务开始。如果奖励在涨但真实通过率不动，那基本是奖励被 hack 了。这时候要检查奖励模型是不是对某些表面特征过拟合，比如长度、格式、特定词汇。解法是加惩罚项，或者换一批奖励模型的训练数据。

还有一个隐蔽的情况是：奖励和真实能力都在涨，但涨到某个点就停了。这通常是探索不足，策略陷入了局部最优。解法是提高采样温度、加熵正则、或者引入新的任务类型打破平衡。

5.2 MoE 路由崩溃的识别与恢复

路由崩溃的表现是：训练 loss 突然跳变，模型输出变得重复或者混乱。排查时先看路由熵，如果骤降，基本可以确认。恢复手段有几个：一是回滚到崩溃前的检查点，调大辅助损失再继续；二是临时冻结路由网络，只训练专家；三是注入随机性，强制路由探索。

预防比恢复更重要。我的经验是在 RL 训练前先跑一段纯推理，观察路由分布在真实任务上的表现，如果发现某些专家激活率极低，提前调整辅助损失或者初始化方式。另外，路由温度不要设得太低，留一点随机性对探索有好处。

5.3 并行环境下的数据一致性问题

异步采样时，不同环境返回的轨迹可能对应不同版本的策略，如果混在一起训练，重要性采样的比率会算错。常见解法是给每条轨迹打上策略版本号，训练时只采样版本号在阈值内的数据。另一个问题是环境状态的序列化，如果环境是有状态的，保存和恢复时容易出错。建议在环境设计阶段就把状态设计成可序列化的，避免用全局变量或者文件句柄。

5.4 常见问题速查表

6. 对想复现的团队的一些实在建议

如果你看完技术报告，想在自己的集群上复现 MiMo-V2.6 的自我改进循环，我建议不要一上来就冲大规模。先从小规模跑通闭环，把奖励设计、路由稳定性、检查点管理这些基础打牢，再逐步加环境数。我见过太多团队直接上几千个环境，结果奖励没设计好，跑了一周发现模型在刷分，算力全浪费了。

另一个建议是重视评估。RL 训练容易让人沉迷于奖励曲线，但奖励曲线好看不等于模型好用。一定要有一套独立的、不参与训练的评估集，定期跑一遍，用真实通过率来判断模型有没有真的变强。这套评估集最好覆盖多个任务类型，避免模型在单一任务上过拟合。

最后，MoE 的 RL 训练对工程能力要求很高，如果团队里没有熟悉分布式训练和路由机制的人，建议先从稠密模型的小规模 RL 入手，把算法层面的东西摸清楚，再迁移到 MoE。算法和工程是两回事，但缺了哪个都跑不通。