1. 从标题拆解MiMo-V2.6到底想解决什么问题第一次看到《MiMo-V2.6通过扩展强化学习实现模型自我提升》这个标题我的直觉是这又是一篇讲“用RL把LLM再往前推一步”的技术报告。但仔细琢磨“自我提升”这四个字它和普通的“用RLHF对齐一下模型”完全不是一个量级的事情。对齐解决的是“让模型听话”而自我提升解决的是“让模型在没有更多人类标注的前提下自己变得更强”。这两件事的难度差了一个数量级。先把核心关键词摆出来MiMo-V2.6、强化学习RL、LLM、MoE。四个词组合在一起基本可以勾勒出这个技术报告的主线——一个基于MoE架构的大语言模型通过扩展强化学习的规模和深度实现模型能力的自我迭代。这里面的“扩展”不是简单地把batch size调大而是涉及RL训练流程的重构、奖励信号的获取方式、以及MoE架构下RL训练的工程挑战。为什么这件事值得关注因为当前LLM的能力提升主要靠两条路一是堆预训练数据二是堆人类反馈标注。第一条路的数据墙已经肉眼可见互联网上高质量的文本快被榨干了第二条路的成本极高而且人类标注的天花板就是人类水平模型不可能通过模仿人类标注超越人类。强化学习提供了一条理论上限更高的路径——模型可以通过与环境交互、与自身博弈来发现人类没想到的解法。DeepMind在AlphaGo上验证过这条路David Silver后来的一系列工作也在反复强调RL是通往超级智能的关键拼图。但把RL用在LLM上难点在于“环境”是什么。围棋的环境是确定的、可模拟的、奖励信号清晰的。LLM的环境是开放的、模糊的、奖励信号稀疏且噪声极大的。MiMo-V2.6这篇报告的核心贡献我理解就是在解决“如何为LLM构建一个可扩展的RL训练环境”这个问题。它可能涉及几个关键设计怎么定义奖励函数、怎么生成多样化的训练信号、怎么在MoE架构下高效地做RL采样和更新。适合谁来读这篇报告如果你只是调API做应用的开发者这篇报告可能偏底层但了解它的思路对理解“下一代模型是怎么炼出来的”很有帮助。如果你是做模型训练、RL算法、或者MoE工程优化的那这篇报告里的细节值得逐段抠。我自己在RL和LLM交叉领域踩过不少坑下面把从标题和关键词里拆出来的技术脉络结合我自己的实践经验展开聊一聊。2. 核心思路拆解为什么是“扩展强化学习”而不是“更多标注”2.1 从RLHF到RLVR奖励信号的来源变了早期LLM的RL训练基本是RLHFReinforcement Learning from Human Feedback的天下。流程很固定收集人类偏好数据训一个奖励模型然后用PPO或者类似算法优化策略模型。这套方法在GPT-3.5到GPT-4的迭代中立了大功但它的瓶颈也很明显——奖励模型的上限就是人类标注者的水平而且奖励模型本身会被策略模型“钻空子”出现reward hacking。MiMo-V2.6标题里的“扩展强化学习”我判断它大概率走的是**RLVRReinforcement Learning with Verifiable Rewards**或者类似的可验证奖励路线。什么叫可验证奖励就是奖励信号不是来自人类偏好模型而是来自一个可以自动判断对错的程序。比如数学题有标准答案代码有单元测试逻辑推理有形式化验证器。这种奖励信号是“硬”的不会因为策略模型的输出分布变化而漂移。这个转变的意义在于奖励信号可以无限扩展。人类标注一天只能标几千条但程序验证可以每秒跑几万次。只要你能把任务转化成可验证的形式RL的训练规模就能指数级放大。这也是为什么最近一年数学和代码领域的RL训练效果特别显著——因为这两个领域的奖励最容易自动化验证。2.2 MoE架构下的RL训练稀疏激活带来的新问题MiMo-V2.6用了MoEMixture of Experts架构这在当前的大模型圈子里几乎是标配。MoE的核心思想是模型总参数量可以很大但每次前向传播只激活其中一小部分专家。比如总参数100B每次只激活10B这样推理成本接近10B的稠密模型但模型容量接近100B。但MoE给RL训练带来了几个稠密模型没有的麻烦。第一个是专家负载不均衡。RL训练过程中策略模型会探索各种奇怪的输出某些专家可能被过度激活另一些则几乎不被用到。如果不管训练会退化——被冷落的专家梯度更新不足逐渐变成“死专家”。第二个是采样效率问题。RL需要大量采样来估计策略梯度MoE的稀疏激活让每次采样的计算图变得不规则batch内的不同样本可能走不同的专家路径这给并行训练和显存管理带来挑战。我推测MiMo-V2.6在工程上做了几件事来应对一是引入辅助的负载均衡损失在RL目标里加一项惩罚项鼓励专家激活分布均匀二是在采样阶段做专家亲和性调度把走同一组专家的样本尽量放在同一个设备上减少通信开销三可能是用了某种异步RL的架构让采样和训练解耦采样端持续产出轨迹训练端按自己的节奏消费。2.3 “自我提升”的闭环模型怎么给自己出题“自我提升”最核心的机制是自博弈self-play或者自生成训练数据。模型自己生成问题、自己尝试解答、自己验证答案然后把成功的轨迹作为正样本失败的作为负样本更新策略。这个闭环一旦跑通模型就不需要外部数据了理论上可以无限迭代。但这里有个关键风险模式坍塌。如果模型自己出题它倾向于出自己已经会做的题训练信号会越来越同质化模型的能力边界不会扩展。解决这个问题的常见做法是引入难度自适应机制——模型出的题要刚好在“当前能力边缘”太难了全是负样本没法学太简单了全是正样本也没法学。具体实现可能是维护一个题目难度估计器根据历史通过率动态调整出题策略。另一个风险是验证器的不完备。如果验证器本身有漏洞模型会学会钻空子生成看起来对但实际错的答案。这在代码任务里特别常见——模型生成的代码能通过测试用例但逻辑是错的。所以MiMo-V2.6可能用了多重验证机制比如同时用单元测试、形式化验证、和另一个模型做交叉检查。3. 核心细节解析RL训练流程里的关键环节3.1 奖励函数的设计从稀疏到稠密RL训练最怕奖励稀疏。如果模型生成一整段推理最后只有一个“对/错”的信号那中间的每一步都不知道好不好学习效率极低。MiMo-V2.6要扩展RL必须解决奖励稠密化的问题。常见的做法是过程奖励模型Process Reward Model, PRM。不只看最终答案而是对推理的每一步打分。比如数学题每一步推导是否正确都可以验证。这样奖励信号从1个变成N个学习效率大幅提升。但PRM的训练本身需要标注成本不低。另一种做法是自动过程验证比如用符号计算引擎逐步检查代数变换或者用代码解释器逐行执行。我猜测MiMo-V2.6可能结合了这两种思路对于有明确形式化规则的任务用自动验证器给过程奖励对于规则不明确的任务用模型自己估计中间步骤的价值。后者类似于Actor-Critic架构里的Critic网络Critic估计当前状态的价值Actor根据价值梯度更新策略。注意奖励稠密化不是越密越好。如果每一步都给奖励模型可能学会“刷步数”——故意把推理拉长来获取更多奖励。所以奖励函数里通常要加长度惩罚或者效率约束。3.2 策略优化算法PPO之外的选择PPOProximal Policy Optimization是RLHF的默认算法但它有几个问题对超参数敏感、需要同时维护策略模型、价值模型、奖励模型四个模型显存开销大。MiMo-V2.6要扩展RL规模可能用了更高效的算法。GRPOGroup Relative Policy Optimization是最近比较火的选择。它去掉了价值模型用一组采样的平均奖励作为基线大幅降低了显存需求。DeepSeek在R1系列里用了这个算法效果不错。另一个方向是DPODirect Preference Optimization及其变体直接把偏好数据转化成策略梯度跳过奖励模型。但DPO对在线采样的支持不如PPO/GRPO更适合离线场景。如果MiMo-V2.6强调“扩展”我倾向于认为它用了GRPO或者类似的轻量级算法因为扩展RL规模的第一约束就是显存和计算效率。PPO的四模型架构在千亿参数级别很难scale。3.3 MoE路由的RL友好化改造前面提到MoE的负载均衡问题这里展开说具体怎么做。标准的MoE路由是Top-K门控每个token算一个专家得分选得分最高的K个专家。这个机制在预训练时没问题但在RL训练时策略模型的输出分布变化剧烈路由决策也跟着剧烈变化导致专家激活极不稳定。一种改造思路是路由平滑在门控得分上加噪声或者温度系数让路由决策更随机避免过早收敛到少数专家。另一种是专家 dropout训练时随机屏蔽一些专家强迫模型学会用不同的专家组合。还有一种更激进的方案是共享专家路由专家混合一部分专家对所有token都激活共享专家另一部分走路由路由专家。这样即使路由部分不稳定共享专家也能提供稳定的基础能力。我实测过类似的设计在RL微调阶段共享专家的比例不宜太高否则路由专家学不到东西也不宜太低否则训练波动太大。经验值大概在20%到30%之间。4. 实操过程如果我要复现MiMo-V2.6的RL训练流程4.1 环境准备与基础模型选择假设我要在一个中等规模上复现MiMo-V2.6的核心思路第一步是选基础模型。MoE架构的话我可能会选一个开源的MoE模型作为起点比如Mixtral 8x7B或者Qwen的MoE版本。稠密模型的话7B到13B参数级别比较适合单机多卡实验。环境方面需要PyTorch 2.x、CUDA 12.x、以及一个支持MoE并行的训练框架。DeepSpeed-MoE或者Megatron-LM的MoE分支都可以。如果显存有限可以用FSDPFully Sharded Data Parallel做参数分片。# 基础环境示例 conda create -n mimo_rl python3.10 conda activate mimo_rl pip install torch2.1.0 --index-url https://download.pytorch.org/whl/cu121 pip install transformers4.36.0 pip install deepspeed0.12.0 pip install flash-attn2.3.0提示MoE模型的显存占用和稠密模型不一样。虽然激活参数少但所有专家参数都要加载到显存里。8x7B的MoE实际显存占用接近56B稠密模型单卡80G可能不够需要多卡或者CPU offload。4.2 奖励函数的具体实现奖励函数是RL训练的灵魂。我以数学推理任务为例设计一个可验证的奖励函数import re from sympy import simplify, sympify def math_reward(response, ground_truth): 数学题奖励函数提取最终答案与标准答案比对 # 提取答案假设格式是 答案是XXX match re.search(r答案是[:]\s*(.), response) if not match: return -0.5 # 格式错误给负奖励 pred match.group(1).strip() try: # 符号化比对处理等价形式 pred_expr sympify(pred) gt_expr sympify(ground_truth) if simplify(pred_expr - gt_expr) 0: return 1.0 else: return -0.5 except: # 无法解析可能是文本答案 if pred ground_truth: return 1.0 return -0.5这个奖励函数只给了最终答案的奖励属于稀疏奖励。如果要稠密化可以在推理步骤上加中间奖励。比如用正则提取每一步的等式逐步验证。4.3 GRPO训练循环的核心代码GRPO的核心是对每个问题采样一组回答算每个回答的奖励然后用组内平均奖励作为基线计算优势函数。def grpo_step(policy_model, ref_model, prompts, reward_fn, group_size8): GRPO单步训练 prompts: 一批问题 group_size: 每个问题采样几个回答 all_responses [] all_rewards [] # 采样阶段 for prompt in prompts: responses [] rewards [] for _ in range(group_size): response policy_model.generate(prompt, temperature0.8) reward reward_fn(response) responses.append(response) rewards.append(reward) # 组内归一化得到优势 mean_reward sum(rewards) / len(rewards) std_reward (sum((r - mean_reward)**2 for r in rewards) / len(rewards)) ** 0.5 1e-8 advantages [(r - mean_reward) / std_reward for r in rewards] all_responses.append(responses) all_rewards.append(advantages) # 计算策略梯度损失 loss 0 for prompt, responses, advantages in zip(prompts, all_responses, all_rewards): for response, adv in zip(responses, advantages): # 计算当前策略和参考策略的log概率比 log_prob policy_model.log_prob(prompt, response) with torch.no_grad(): ref_log_prob ref_model.log_prob(prompt, response) ratio torch.exp(log_prob - ref_log_prob) # PPO式的裁剪 clipped_ratio torch.clamp(ratio, 0.8, 1.2) loss -torch.min(ratio * adv, clipped_ratio * adv) loss / (len(prompts) * group_size) return loss这段代码是简化版实际训练还要考虑KL散度约束、梯度累积、混合精度等。但核心逻辑就是组内比较代替绝对奖励降低对奖励模型绝对准确性的依赖。4.4 MoE负载均衡的辅助损失在MoE模型上做RL必须在损失里加负载均衡项。否则训练几百步后大部分token都会路由到少数几个专家。def load_balance_loss(gate_logits, num_experts): gate_logits: [batch_size, seq_len, num_experts] 计算专家负载均衡损失 # 每个专家的平均激活概率 expert_probs torch.softmax(gate_logits, dim-1) mean_probs expert_probs.mean(dim[0, 1]) # [num_experts] # 每个专家被选中的频率 top_k_indices torch.topk(gate_logits, k2, dim-1).indices expert_counts torch.zeros(num_experts, devicegate_logits.device) for i in range(num_experts): expert_counts[i] (top_k_indices i).float().sum() expert_freq expert_counts / expert_counts.sum() # 负载均衡损失概率和频率的协方差 balance_loss num_experts * (mean_probs * expert_freq).sum() return balance_loss这个损失加到总损失里权重一般设0.01到0.1之间。权重太大影响主任务学习太小起不到均衡作用。5. 常见问题与排查技巧实录5.1 训练不收敛或者奖励突然崩塌这是RL训练最常见的问题。表现是训练初期奖励上升然后突然断崖式下跌再也回不去。原因通常是策略更新步子太大模型跑到了一个陌生的分布区域参考模型的KL约束拉不住。排查思路先看KL散度曲线。如果KL突然飙升说明策略偏离参考模型太远。解决办法是调大KL惩罚系数或者调小学习率。另一个可能是奖励函数被hack了模型找到了某种刷奖励的捷径。这时候要检查奖励函数的实现看看有没有漏洞。我踩过的一个坑是奖励函数里用了正则匹配模型学会了在答案里塞一堆无关内容来触发匹配。后来改成严格格式校验才解决。5.2 MoE专家坍塌表现是训练一段时间后大部分token都路由到同一个专家其他专家几乎不被激活。这时候模型的表达能力急剧下降因为相当于退化成了稠密模型但参数利用率极低。排查方法打印每个专家的激活频率。如果某个专家激活频率超过50%基本就是坍塌了。解决办法一是加大负载均衡损失的权重二是在路由门控里加噪声增加探索三是用专家dropout训练时随机屏蔽热门专家。注意负载均衡损失不能只在预训练时加RL微调阶段也要持续加。因为RL会改变输出分布预训练时均衡的专家在RL时可能变得不均衡。5.3 采样效率太低训练速度慢RL训练比监督学习慢一个数量级因为要在线采样。MoE模型更是雪上加霜因为每次采样的计算图不规则batch内不同样本走不同专家GPU利用率上不去。优化方向一是用vLLM或者TensorRT-LLM做推理加速采样阶段用推理引擎训练阶段用训练框架两者解耦二是做样本复用同一批采样数据做多次梯度更新PPO的epoch机制三是用异步RL采样和训练在不同设备上并行采样端持续产出训练端按需消费。我实测下来vLLM做采样能比HuggingFace generate快3到5倍对于RL训练这种采样密集型任务提升非常明显。5.4 奖励函数设计速查表问题类型奖励信号来源优点缺点数学题标准答案比对准确、可自动化只适用于有唯一答案的任务代码生成单元测试接近真实场景测试用例覆盖不全时会被hack逻辑推理形式化验证器严谨构建验证器成本高开放问答奖励模型通用奖励模型本身有偏差多步推理过程奖励模型信号稠密需要步骤级标注5.5 几个反直觉的实操经验第一个经验RL训练的学习率要比监督学习小一到两个数量级。监督学习常用1e-5到5e-5RL训练我一般从1e-6开始试。因为RL的梯度方差大学习率大了直接飞。第二个经验参考模型不要频繁更新。GRPO和PPO都需要一个参考模型来算KL这个参考模型通常是SFT后的模型在整个RL训练过程中保持冻结。如果参考模型也更新KL约束就失效了训练容易崩。第三个经验采样温度很关键。温度太低采样多样性不够组内奖励都差不多优势函数全是零没有梯度。温度太高采样质量太差全是负样本也学不到东西。我一般从0.7到1.0之间调具体看任务。6. 这套思路能迁移到哪些场景MiMo-V2.6的“扩展RL实现自我提升”不只是一个模型训练技巧它代表了一种范式用可验证的奖励信号驱动模型在特定领域内自我迭代。这个范式可以迁移到很多场景。代码生成是最直接的场景。模型生成代码单元测试给奖励模型根据测试结果自我修正。这个闭环已经在一些产品里落地了效果比单纯的监督微调好很多。数学推理是另一个成熟场景。从小学算术到大学数学只要有标准答案或者形式化验证器就能构建RL训练环境。而且数学推理的能力可以迁移到逻辑推理、科学推理等更广泛的领域。Agent任务也很有潜力。比如让模型操作一个模拟环境完成多步任务环境的状态变化就是天然的奖励信号。这种场景下RL比监督学习更合适因为多步任务的中间状态很难标注但环境反馈是自动的。甚至内容创作也可以部分应用。比如让模型生成多个版本用另一个模型或者规则系统打分选最好的作为正样本。虽然奖励信号不如数学题那么“硬”但也能提供一定的训练信号。我在实际项目里试过用RL做代码补全的微调奖励函数是“生成的代码能否通过已有的单元测试”。效果比纯SFT好尤其是在处理边界条件的时候。但训练成本确实高需要大量的采样和验证。最后分享一个小技巧如果你的计算资源有限做不了全参数的RL训练可以考虑LoRA RL的组合。只训练低秩适配器冻结基础模型。这样显存需求大幅降低训练速度也快很多。虽然效果可能不如全参数RL但在资源受限的情况下是一个很实用的折中方案。