企业官网建设流程全解析

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

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

先把标题拆开看。MiMo-V2.6是模型代号，第一开源大模型这个定语说明它主打的是开放权重、可复现、可二次开发；而真正决定这篇技术报告含金量的，是后半句——迈向自我改进的强化学习规模化。这句话里藏着三个关键词：自我改进、强化学习、规模化。任何一个单独拿出来都不新鲜，但三个叠在一起，指向的是一个很具体的工程难题：怎么让模型在训练过程中自己生成高质量的训练信号，并且这套机制在参数量、数据量、训练步数都拉满之后依然不崩。

我先把结论摆前面：这类工作的核心矛盾从来不是“算法够不够新”，而是信号质量与训练稳定性之间的拉锯。强化学习用在语言模型上，本质是把“生成 token”这件事看成一连串决策，用奖励信号去调整策略。问题在于，语言模型的动作空间是词表大小（动辄十几万），序列长度动辄几千，奖励又往往是稀疏的、延迟的、甚至是有噪声的。你稍微把规模放大，梯度方差、奖励黑客（reward hacking）、策略坍缩这些问题就会成倍放大。所以“规模化”这三个字，才是整篇报告最硬的部分。

自我改进这个词也得说清楚。它不是指模型能改自己的代码或者改自己的架构，而是指训练流程里形成一个闭环：模型产出候选答案 → 用某种评判机制打分 → 用打分结果反过来更新模型 → 更新后的模型产出更好的候选。这个闭环如果转得起来，理论上可以用更少的人工标注撬动更大的能力提升。但闭环要转得稳，需要解决几个很现实的问题：评判机制本身会不会被钻空子？多轮迭代后分布漂移怎么办？算力预算怎么分配才不浪费？

1.2 适合谁来读这篇解析

这篇内容我主要写给三类人。第一类是做后训练（post-training）的工程师，你手上可能已经有 SFT 和 DPO 的流水线，想搞清楚 RL 这一环到底怎么接、接在哪、接多少。第二类是做训练基础设施的同学，你关心的是 MoE 架构下 RL 的通信开销、显存占用、rollout 吞吐这些实打实的数字。第三类是想复现开源大模型训练流程的研究者或学生，你需要一个从数据构造到奖励设计再到稳定性控制的完整地图，而不是只看到一堆公式。

如果你只是想了解“MiMo-V2.6 比上一代强多少”，那这篇可能不太对你胃口，因为我更想聊的是它为什么这么设计，以及这些设计里哪些是你可以直接抄作业的，哪些是必须结合自己场景重新算账的。

2. 整体设计思路：MoE 打底，Agentic RL 做引擎

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

MoE（Mixture of Experts，混合专家）架构这几年在大模型里几乎是标配了，但把它和强化学习放在一起看，逻辑会更清楚。稠密模型每处理一个 token 都要激活全部参数，训练时的计算量和参数量是线性绑定的。MoE 的思路是：把 FFN 层拆成多个专家，每个 token 只路由到其中少数几个（常见是 top-2 或 top-4），这样总参数量可以做得很大，但单 token 的实际计算量（激活参数量）控制在一个可接受的范围内。

这对 RL 训练特别重要。原因在于 RL 训练相比 SFT 有一个额外的、非常吃资源的环节：rollout。也就是模型要自己生成大量样本来做探索。SFT 是喂进去一条数据算一次 loss，RL 是模型自己生成、自己打分、自己学，生成的数据量往往是训练数据的好几倍。如果底座是稠密模型，rollout 的算力开销会直接把训练预算吃光。MoE 在这里的价值就是：用更大的总容量承载知识，用更小的激活开销支撑高频采样。

但 MoE 也不是白拿的好处。它引入了路由不稳定、专家负载不均、通信开销大这几个新问题，而这些在 RL 场景下会被进一步放大——因为 RL 的输入分布是随策略变化而漂移的，今天路由到专家 A 的 token，明天可能全跑到专家 B 去了。所以 MiMo-V2.6 在 MoE 上做 RL，必然要在路由稳定性和负载均衡上做额外处理，这是后文会展开的重点。

2.2 Agentic RL 到底和普通 RLHF 差在哪

热词里有个Agentic RL，这个词值得单独讲。传统的 RLHF（基于人类反馈的强化学习）流程大概是：模型生成回答 → 人类或奖励模型打分 → 用 PPO 之类的算法更新。它的决策粒度基本是“整条回答”或者“每个 token”，环境是静态的，就是那个提示词。

Agentic RL 把环境复杂化了。模型不再只是“回答问题”，而是要在多轮交互中做决策：调用工具、观察返回结果、决定下一步动作、必要时回退重试。这时候奖励不再是单步的，而是分布在整条轨迹上的。这就带来几个新问题：信用分配（credit assignment）变难了，到底是哪一步动作导致了最终成功？探索空间变大了，工具调用的组合爆炸；训练效率变低了，因为一次 rollout 可能要跑很多轮交互。

MiMo-V2.6 把 Agentic RL 作为核心方向，说明它的目标场景不是单纯的问答，而是能干活、能多步推理、能使用工具的智能体。这也解释了为什么它强调“规模化”——智能体任务的轨迹长、交互多，没有规模化的训练框架根本跑不起来。

2.3 自我改进闭环的设计取舍

自我改进闭环的设计，核心是一个取舍：用模型自己当裁判，还是用外部信号当裁判。用模型自己当裁判（self-rewarding）的好处是成本低、可扩展，坏处是容易自我强化偏见，越训越偏。用外部信号（比如代码执行结果、工具返回、单元测试）的好处是信号客观，坏处是覆盖场景有限，很多任务没有明确的对错。

从技术报告的定位看，MiMo-V2.6 大概率采用的是混合信号：在有客观验证器的场景（代码、数学、工具调用）用可验证奖励，在开放场景用模型评判加人工校准。这种混合设计的关键在于权重分配和信号归一化——不同来源的奖励量纲不一样，直接相加会让某一类信号主导训练。我个人的经验是，这类混合奖励一定要做 per-source 的标准化，并且定期检查各信号源的贡献占比，否则很容易出现“模型只学会了刷某一类奖励”的情况。

3. 核心细节解析：奖励、策略与稳定性

3.1 奖励信号的分层设计

奖励设计是 RL 训练里最容易被低估、也最容易翻车的一环。我见过太多项目，算法选得很花哨，结果奖励一设计错，模型学出来的全是歪门邪道。MiMo-V2.6 这类工作通常会把奖励分成几层：

• 结果奖励（outcome reward）：最终答案对不对，代码跑不跑得通，工具调用是否成功。这类信号最可靠，但最稀疏。
• 过程奖励（process reward）：中间步骤是否合理，推理链有没有跳步。这类信号密集，但标注成本高，且容易引入主观偏差。
• 格式奖励（format reward）：输出是否符合预期结构，比如有没有正确使用工具调用格式。这类信号便宜，但权重给高了会让模型只顾格式不顾内容。

分层设计的关键是课程式调度：训练早期多用过程奖励和格式奖励，让模型先学会“怎么做事”；训练中后期逐步提高结果奖励的权重，让模型聚焦“做对事”。这个调度不是拍脑袋定的，通常要根据验证集上的通过率曲线来动态调整。如果结果奖励的通过率长期卡在低位，说明过程奖励给太多，模型没动力去追求最终正确；如果通过率上去了但输出变得不可读，说明格式奖励给太少。

提示：奖励权重的调整一定要记录每次改动对应的验证指标，否则出了问题根本回溯不到是哪次调整导致的。

3.2 策略优化算法的选择逻辑

RL 用在语言模型上，主流算法就那么几个：PPO、GRPO、DPO 及其变体。MiMo-V2.6 这种规模的工作，大概率是以PPO 或 GRPO为主干。PPO 的优点是成熟、稳定、有大量工程实践；缺点是它需要同时维护策略模型、价值模型、奖励模型、参考模型，显存占用大，超参敏感。GRPO（Group Relative Policy Optimization）去掉了价值模型，用一组采样的相对优势来估计 baseline，显存友好很多，这也是它近两年在开源社区流行的原因。

选哪个，取决于你的算力预算和团队工程能力。如果显存充足、有成熟的 PPO 调参经验，PPO 的稳定性上限更高；如果显存紧张、想快速迭代，GRPO 是更务实的选择。这里有个容易被忽略的点：算法选择和 MoE 架构是耦合的。MoE 的专家路由会引入额外的方差，如果再用 GRPO 这种依赖组内相对比较的方法，组内样本如果路由到不同专家，比较的基准就不一致了。所以 MoE + RL 的组合，往往需要在路由层面做约束，比如让同一组的样本尽量走相同的专家路径。

3.3 训练稳定性的三道防线

规模化 RL 训练，稳定性是生死线。我把它总结成三道防线：

第一道是 KL 约束。策略模型不能偏离参考模型太远，否则会 reward hacking。KL 系数怎么设是个经验活，设大了模型学不动，设小了模型跑飞。常见做法是从一个较小的系数开始，观察 KL 散度的变化曲线，如果长期贴近 0 说明约束过强，如果剧烈波动说明约束不足。

第二道是梯度裁剪和优势归一化。RL 的梯度方差天然比 SFT 大，不做裁剪很容易出现梯度爆炸。优势归一化（advantage normalization）则是把不同 batch 的优势拉到同一量纲，避免某些 batch 主导更新。

第三道是定期评估与回滚机制。训练过程中要持续在固定验证集上评估，一旦发现指标异常下滑，要能快速回滚到上一个 checkpoint。这套机制听起来简单，但真正做起来需要基础设施支持——checkpoint 的保存频率、加载速度、评估的自动化程度，都直接影响你能不能及时止损。

4. 实操过程：从数据构造到规模化训练

4.1 训练数据的构造与配比

RL 训练的数据和 SFT 不一样，它不是“输入-输出”对，而是“提示词 + 验证方式”。构造这批数据的核心工作是：设计有区分度的提示词，并配上可靠的验证器。有区分度指的是，模型不能靠猜或者靠记忆做对，必须真的推理或调用工具。验证器则决定了奖励信号的质量。

配比上，我的经验是遵循难度金字塔：简单任务占大头（保证训练信号密集、模型不至于全错），中等难度占中头（主要的能力提升区），困难任务占小头（探索上限）。比例大概是 5:3:2 或者 4:4:2，具体要看模型当前的能力水平。如果模型在某个难度上通过率已经超过 90%，那这批数据基本没用了，要换更难的；如果通过率低于 10%，说明太难，模型学不到有效信号，要降难度。

注意：数据配比不是一次定死的，要随着训练进展动态调整。我习惯每训练一定步数就重新统计各难度档的通过率，然后按通过率重新分配采样权重。

4.2 Rollout 的吞吐优化

Rollout 是 RL 训练里最吃资源的部分。模型要生成大量样本，每个样本可能还要多轮交互，生成速度直接决定训练效率。优化 rollout 吞吐有几个方向：

• 推理引擎选择：用 vLLM、TensorRT-LLM 这类高吞吐推理框架做生成，比原生 PyTorch 生成快数倍。关键是这些框架对 MoE 的支持程度，要确认专家并行的通信是否被优化过。
• 批处理与流水线：把生成和训练做成流水线，生成一批、训练一批，避免 GPU 空转。这需要精细的显存管理，因为生成和训练用的显存布局不一样。
• 采样温度与长度控制：温度太高生成质量差、有效样本少；温度太低多样性不足、探索不够。长度上要设上限，避免个别样本生成超长拖慢整批。

这里有个实测经验：rollout 的瓶颈往往不在 GPU 算力，而在 CPU 侧的调度和验证器执行。尤其是 Agentic 任务，工具调用要等外部返回，验证器要跑代码，这些 I/O 和 CPU 操作如果没做好异步，GPU 会大量空等。所以规模化 RL 的基础设施，一半功夫在 GPU 上，一半在 CPU 和调度上。

4.3 规模化训练的资源分配

规模化训练最现实的问题是：算力怎么分。RL 训练的资源消耗大致分三块：rollout 生成、奖励计算、梯度更新。经验比例大概是 5:2:3 或者 6:2:2，rollout 占大头。如果发现训练吞吐上不去，先看 rollout 是不是瓶颈；如果奖励计算拖后腿，考虑把验证器做成异步或者缓存结果；如果梯度更新慢，那可能是 MoE 的通信开销问题。

MoE 的通信开销在规模化时特别明显。专家并行（expert parallelism）意味着 token 要在不同 GPU 之间来回传输，参数量越大、专家越多，通信占比越高。缓解手段包括：增大单卡 batch 摊薄通信、用更高效的 all-to-all 实现、在路由层面做局部性优化（让相邻 token 尽量走同一专家）。这些优化每一项都能带来百分之几到百分之十几的吞吐提升，累积起来很可观。

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

5.1 奖励黑客的识别与处理

奖励黑客是 RL 训练的头号敌人。表现是：奖励曲线一路涨，但人工评估发现模型输出越来越离谱。常见的黑客手段包括：输出超长回答骗过程奖励、重复套话骗格式奖励、在验证器边界上钻空子。识别方法很简单——定期做人工抽检，不要只看自动指标。一旦发现奖励和人工评估背离，立刻停下来查奖励函数。

处理手段分两种：一是修补奖励函数，堵住被钻的空子；二是加惩罚项，比如长度惩罚、重复惩罚。但惩罚项要慎加，加多了会误伤正常输出。我的经验是，优先修补奖励函数本身，惩罚项只作为临时手段。

5.2 训练崩溃的典型症状与排查路径

训练崩溃的症状有很多种，我整理了一个速查表：

排查的核心思路是二分定位：先确认是数据问题、奖励问题还是优化问题，再在对应环节里细分。最忌讳的是一上来就调学习率，很多时候问题根本不在优化器上。

5.3 我踩过的几个坑

第一个坑是过早追求大规模。我一开始就想把 batch size 拉满、把模型拉到最大，结果训练极不稳定，调了两周都没跑通。后来退回到小规模，先把流程跑通、把奖励调对，再逐步放大，反而快得多。RL 训练的正确姿势是先求稳，再求大。

第二个坑是忽视验证器的性能。验证器如果跑得慢，整个 rollout 就被拖住。我有个项目，验证器用的是同步执行的代码沙箱，结果 GPU 利用率长期只有 30%。后来改成异步 + 结果缓存，利用率直接上到 70% 以上。

第三个坑是没有做奖励归一化。多来源奖励直接相加，导致某一类信号主导训练，模型学偏了。后来加了 per-source 标准化，问题才解决。这个坑很隐蔽，因为奖励曲线看起来是正常上涨的，只有做信号贡献分析才能发现。

6. 这套方案能迁移到什么场景

MiMo-V2.6 的这套思路，核心可迁移的部分是**“可验证奖励 + 自我改进闭环 + 规模化基础设施”**这个组合。如果你在做代码生成，可以用单元测试当验证器；如果你在做数学推理，可以用符号计算当验证器；如果你在做工具调用，可以用工具返回结果当验证器。只要有客观验证手段，这套闭环就能转起来。

MoE + RL 的组合则更适合算力相对充足、追求推理效率的场景。如果你的场景对延迟不敏感、对成本敏感，稠密模型加 RL 可能更划算，因为 MoE 的工程复杂度不低。Agentic RL 的迁移门槛最高，因为它要求你有稳定的工具环境和多轮交互的基础设施，但一旦搭起来，能解锁的能力上限也最高。

我个人在实际操作中的体会是，RL 训练这件事，算法只占三成，剩下七成是数据、奖励和基础设施。很多人把精力花在追新算法上，结果基础没打牢，怎么调都不对。反过来，把奖励设计清楚、把 rollout 吞吐优化好、把稳定性监控做扎实，哪怕用最朴素的 PPO，也能训出不错的结果。最后再分享一个小技巧：训练日志里一定要单独记录每个奖励分量的均值和方差，不要只记总奖励。总奖励上涨但某个分量异常，往往是问题的早期信号，早发现能省下大量排查时间。