从MiMo-V2.6复盘看大规模RL扩展：MixRL与MOPD实战解析

1. 从 MiMo-V2.6 看大规模强化学习扩展的真实挑战小米 MiMo-V2.6 发布之后团队做了一次相当坦诚的复盘核心不是“我们又刷了多少榜”而是把大规模强化学习RL扩展这条路上踩过的坑、做过的取舍、以及那些在论文里通常不会写的工程细节摊开来讲。这件事在圈内引起的讨论其实比模型本身的参数更值得琢磨——因为 RL 扩展RL Scaling从去年开始就是大模型后训练阶段最烧钱、最不确定、也最容易翻车的环节。我自己在过去一年里围绕 Qwen 系列模型做过不少 LoRA 微调和 RL 实验从单卡 4090 到多机多卡集群都跑过对“RL 扩展”这四个字的体感是它不像预训练那样你堆卡、堆数据、调调学习率就能看到 loss 稳稳下降。RL 阶段的不稳定性是系统性的reward 会崩、KL 会炸、生成会退化、甚至训练到一半模型开始胡说八道。MiMo-V2.6 团队提到的 MixRL、MOPD 这些思路本质上都是在跟这种不稳定性做斗争。这篇文章我想做的事情很具体把 MiMo-V2.6 复盘里透露出来的大规模 RL 扩展思路拆开结合我自己在 Qwen 上做 LoRA 微调和 RL 实战的经验讲清楚几个问题——为什么 RL 扩展这么难、MixRL 这类混合策略到底在解决什么、MOPD 这种偏序数据构造方式的价值在哪、以及如果你手上只有几张卡怎么用 Qwen 做一套小规模但完整的 RL 流程来练手。适合正在做后训练、想从 SFT 往 RL 走、或者单纯想搞明白“RL 扩展”到底难在哪的读者。2. 大规模 RL 扩展到底难在哪先搞清楚问题再谈方案2.1 RL 阶段和 SFT 阶段的本质差异很多人从 SFT监督微调转到 RL 的时候第一反应是“不就是换个 loss 吗”然后就被现实教育了。SFT 的本质是模仿给定输入让模型输出尽量接近标注答案loss 是交叉熵梯度方向明确训练曲线基本单调下降。你可以把它理解成“照着菜谱做菜”菜谱上写多少盐就放多少盐错了就改改了就进步。RL 阶段完全不是这回事。以 PPO 为代表的策略梯度方法模型要自己生成回答然后根据 reward model 或规则打分来调整策略。这里有几个致命的不确定性第一reward 信号是稀疏且带噪的同一个问题模型生成两次可能一次得分高一次得分低梯度方向就飘了第二策略更新幅度稍微大一点模型就会“遗忘”之前学到的语言能力开始输出乱码或者重复第三KL 散度约束如果设得太松模型会 reward hacking专门钻 reward model 的空子生成一堆看起来得分高但实际没用的内容。MiMo-V2.6 团队在复盘里反复强调的一个点就是RL 扩展不是简单地把 SFT 的规模放大而是要重新设计整个训练范式和数据流。这个判断我完全认同。我在 Qwen 上做 LoRA 微调的时候SFT 阶段用 5 万条数据、3 个 epochloss 从 2.3 降到 0.8很稳但一旦切到 RL同样的数据量reward 曲线前 200 步基本是平的然后突然往上窜一下又掉下来非常折磨人。2.2 规模上去之后问题会被放大而不是被稀释小规模 RL 实验有个特点很多问题被随机性掩盖了。你跑 8 张卡、batch size 小、训练步数少可能刚好没触发那些致命的 instability。但一旦把规模拉到几十上百张卡、训练几天几夜所有小问题都会被放大成系统性故障。具体来说大规模 RL 扩展会遇到几类典型问题。第一类是生成吞吐和训练吞吐不匹配RL 需要模型不断生成样本来算 reward生成是自回归的、慢训练是并行的、快。如果生成跟不上GPU 利用率就会掉到 30% 以下钱白烧。第二类是reward 分布漂移随着策略更新模型生成的样本分布会偏离 reward model 的训练分布导致 reward 打分越来越不准这就是所谓的 out-of-distribution 问题。第三类是多机通信瓶颈PPO 需要多个 actor 并行生成、一个 learner 集中更新参数同步的开销在大规模下非常可观。MiMo-V2.6 提到的 MixRL我理解它的核心动机就是对付第一类和第二类问题——通过混合多种 RL 策略或多种数据来源让生成效率和 reward 稳定性同时得到改善。这个思路和我在 Qwen 上做 LoRA 微调实战时的一个观察吻合单一 reward 信号下模型很容易过拟合到某个特定模式但如果你混合规则 reward 和模型 reward或者混合不同难度的 prompt训练稳定性会明显提升。2.3 为什么 Qwen 生态在这波 RL 实践里被频繁提及热搜词里 Qwen 出现的频率极高从“lora微调实战教程qwen”到“qwen本地部署”再到“qwen code”这说明一件事Qwen 系列已经成为国内做后训练和本地化部署最主流的基座之一。原因很实际——Qwen 的模型尺寸覆盖全从 0.5B 到 72B 都有开源协议友好社区工具链成熟而且中英文能力均衡做 RL 实验时 reward model 好找、评测集好建。MiMo-V2.6 的复盘里虽然没有直接说用了 Qwen但整个 RL 扩展的方法论是通用的。你完全可以用 Qwen2.5-7B 或者 Qwen3 系列作为基座复现一套缩小版的 MixRL 流程。我自己就是用 Qwen2.5-7B-Instruct 做 LoRA 微调然后在上面接一个简单的规则 reward 做 RL 实验虽然规模小但该踩的坑一个没少对理解大规模 RL 的问题非常有帮助。3. MixRL 与 MOPD两个关键思路的拆解3.1 MixRL 到底在“混”什么MixRL 这个名字听起来抽象但拆开看其实很务实。从 MiMo-V2.6 复盘的语境推断它至少包含两个层面的混合策略混合和数据混合。策略混合指的是在 RL 训练中同时维护多个策略或多种更新方式。比如一部分 rollout 用当前策略生成一部分用稍微旧一点的策略生成类似 IMPALA 的 actor-learner 异步思路这样既能保证样本多样性又能缓解策略更新过快导致的崩溃。数据混合则是指训练数据不局限于单一来源而是把数学、代码、通用对话、指令遵循等不同任务的数据按比例混在一起做 RL避免模型在单一任务上过拟合。我在 Qwen 上做 LoRA 微调时试过一个简化版的“混合”SFT 阶段用通用指令数据打底RL 阶段用数学题和代码题混合做 reward。实测下来如果只用数学题做 RL模型在数学上确实涨点但通用对话能力会掉混入 30% 左右的代码和通用数据后数学涨幅略小但整体能力保持得更好。这个比例不是拍脑袋定的而是根据任务重要性和数据量做的权衡——数学数据质量高但量少通用数据量大但 reward 信号弱混合比例本质上是在平衡“专精”和“通用”。提示混合比例没有万能公式建议从 7:3 或 6:4 开始试观察不同任务上的评测曲线哪个任务掉得厉害就适当加它的数据。3.2 MOPD 与偏序数据的价值MOPD 这个词在公开资料里没有特别标准的定义但从 MiMo-V2.6 复盘的上下文看它大概率指的是一种基于偏序关系的数据构造或偏好优化方法Multi-Objective Preference Data 或类似的偏序数据组织方式。核心思想是与其让 reward model 给每个回答打一个绝对分数不如构造“A 比 B 好”这样的偏序对用相对比较来训练。这个思路的价值在于绝对打分很难校准——不同 prompt 之间的分数不可比同一个 prompt 下模型也可能给出边界模糊的分数。但偏序关系更稳定你让标注者判断“这两个回答哪个更好”比让他打 1 到 10 分要可靠得多。DPO 系列方法就是吃这碗饭的而 MOPD 如果是在多目标场景下做偏序那它解决的就是“既要数学好、又要代码好、还要不胡说”这种多目标权衡问题。我在 Qwen 上做 LoRA 微调实战时用过一个很土但有效的偏序构造方法对同一个问题用不同 temperature 生成 4 个回答然后用规则比如数学题看最终答案对不对、代码题看能不能跑通自动排序构造出偏好对。这样不需要人工标注就能得到大量偏序数据。实测下来用这种自动偏序数据做 DPO比直接用 SFT 数据做 RL 稳定得多reward 曲线平滑很多。3.3 两个思路的协同为什么大规模 RL 需要它们一起上单独看 MixRL 和 MOPD一个是训练策略层面的混合一个是数据层面的偏序优化。但放到大规模 RL 扩展的场景里它们是互补的。MixRL 解决的是“训练过程稳不稳”的问题MOPD 解决的是“reward 信号准不准”的问题。如果 reward 信号本身噪声大再好的混合策略也救不了如果训练过程本身容易崩再准的 reward 也传不进去。MiMo-V2.6 团队把这两个思路放在一起讲说明他们在工程上已经验证了这种组合的有效性。我的理解是大规模 RL 扩展的下一步竞争不是比谁的 reward model 更大而是比谁的数据构造更精细、训练流程更鲁棒。这跟 Qwen 生态里大家热衷讨论“lora微调实战教程”是同一个逻辑——大家发现与其盲目堆资源不如把数据和方法做扎实。4. 用 Qwen 复现一套小规模 RL 流程从 LoRA 微调到偏好优化4.1 环境准备与基座选择如果你手上只有单卡 24G 显存比如 4090或者 Jetson Orin Nano 这种边缘设备直接跑全参数 RL 是不现实的。合理的路径是先用 LoRA 做 SFT再在 LoRA 适配器上做轻量级 RL 或 DPO。Qwen2.5-7B-Instruct 在 4-bit 量化下LoRA 微调大概占 10-12G 显存单卡 4090 完全够用。如果显存更紧张Qwen2.5-3B 或者 Qwen3 的小尺寸版本也是不错的选择。环境方面我习惯用 conda 建一个干净的环境核心依赖是 transformers、peft、trl、accelerate 和 bitsandbytes。trl 里的 PPOTrainer 和 DPOTrainer 封装得比较好适合快速上手。如果你要用 vLLM 加速生成还需要额外装 vllm但注意 vLLM 和训练框架的版本兼容性有时候会打架建议先固定版本再装。conda create -n qwen-rl python3.10 conda activate qwen-rl pip install torch2.1.2 transformers4.40.0 peft0.10.0 trl0.8.6 accelerate0.29.0 bitsandbytes0.43.0注意bitsandbytes 在 Windows 上支持不好建议在 Linux 环境下做这套实验。如果只有 Mac可以用 MPS 后端跑小模型但 4-bit 量化支持有限速度会慢很多。4.2 LoRA 微调实战先把 SFT 做扎实RL 之前一定要先把 SFT 做扎实这是我在 Qwen 上踩过的最大的坑。很多人 SFT 还没收敛就急着上 RL结果 reward 怎么调都不涨最后发现是基座本身就没学会任务格式。SFT 的目标很简单让模型学会“在这个任务上该怎么回答”格式对、风格对、基本逻辑对。RL 是在这个基础上做精细优化不是从零教。LoRA 微调的关键参数我一般这样设r16 或 32lora_alpha32 或 64target_modules 覆盖 q_proj、k_proj、v_proj、o_proj 和 gate_proj、up_proj、down_proj。学习率用 2e-4 到 1e-4cosine schedulewarmup ratio 0.03。batch size 根据显存尽量大配合 gradient accumulation。数据量方面5000 到 20000 条高质量指令数据训练 2 到 3 个 epoch基本能看到明显效果。from peft import LoraConfig, get_peft_model lora_config LoraConfig( r32, lora_alpha64, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(base_model, lora_config)实测下来LoRA 微调在 Qwen2.5-7B 上单卡 4090 跑 1 万条数据、2 个 epoch大概需要 6 到 8 小时。训练完记得把 adapter 合并或者单独保存后面 RL 阶段可以直接加载。4.3 构造偏好数据自动偏序比人工标注更实际RL 或 DPO 需要偏好数据。人工标注成本太高我推荐用自动构造的方式。具体做法是对每个 prompt用 SFT 后的模型以不同 temperature比如 0.7 和 1.0各生成 2 个回答然后用规则或一个小的 reward model 打分排序。数学题看最终答案是否匹配代码题看能否通过单元测试通用题可以用一个小的 reward model 或者 GPT-4 级别的 API 做裁判如果条件允许。构造出来的数据格式是 (prompt, chosen, rejected) 三元组。chosen 是得分高的rejected 是得分低的。数据量不需要特别大5000 到 10000 对就能看到效果。关键是质量如果 chosen 和 rejected 差距不明显训练信号就很弱。我一般会过滤掉得分差距小于阈值的对保证偏好信号足够强。# 伪代码自动构造偏好对 for prompt in prompts: responses model.generate(prompt, num_return_sequences4, temperature0.8) scores [rule_reward(prompt, r) for r in responses] sorted_pairs sorted(zip(responses, scores), keylambda x: x[1], reverseTrue) chosen sorted_pairs[0][0] rejected sorted_pairs[-1][0] if sorted_pairs[0][1] - sorted_pairs[-1][1] threshold: preference_data.append({prompt: prompt, chosen: chosen, rejected: rejected})4.4 DPO 训练比 PPO 更稳的起点如果你刚开始做 RL我强烈建议从 DPO 入手而不是直接上 PPO。DPO 不需要单独的 reward model直接用偏好数据优化策略训练稳定性好很多。在 Qwen2.5-7B LoRA 的配置下DPO 训练大概占 14-16G 显存单卡 4090 可以跑 batch size 2 到 4配合 gradient accumulation。DPO 的关键参数是 beta控制偏离参考模型的程度。beta 太小比如 0.01会导致模型过度优化偏好数据语言能力退化beta 太大比如 0.5则偏好信号传不进去。我一般从 0.1 开始试观察训练 loss 和生成质量。学习率用 5e-5 到 1e-5比 SFT 小一个量级训练 1 到 2 个 epoch 就够。from trl import DPOTrainer, DPOConfig dpo_config DPOConfig( beta0.1, learning_rate5e-5, per_device_train_batch_size2, gradient_accumulation_steps8, num_train_epochs1, logging_steps10, save_steps200, output_dir./qwen-dpo ) trainer DPOTrainer( modelmodel, ref_modelref_model, argsdpo_config, train_datasetpreference_dataset, tokenizertokenizer ) trainer.train()提示DPO 训练时 ref_model 可以是 SFT 后的模型副本也可以直接用 base model。用 SFT 后的模型做 ref约束更强模型不容易跑偏用 base model 做 ref优化空间更大但风险也更高。5. 实操中遇到的典型问题与排查技巧5.1 reward 不涨或震荡先查数据再查超参RL 训练最让人崩溃的就是 reward 曲线不动或者来回震荡。我的排查顺序是第一检查 reward 信号本身是否有区分度——如果所有回答得分都差不多那 reward model 或规则就有问题第二检查 prompt 难度分布——如果全是超难题模型怎么生成都拿不到分梯度信号就没了第三检查学习率和 KL 系数——学习率太大或 KL 约束太松策略更新过猛reward 会震荡。在 Qwen 上做 LoRA 微调实战时我遇到过一次 reward 完全不涨的情况排查了半天发现是数据格式问题prompt 里没有加正确的 system prompt模型生成的回答格式和 reward 规则期望的不一致导致所有回答都被判低分。改掉格式后reward 立刻开始涨。这个坑很典型建议在 RL 之前先用一批样本手动验证 reward 函数的输出是否符合预期。5.2 模型输出退化KL 约束和 beta 是关键RL 或 DPO 训练到一定步数后模型可能开始输出重复、乱码或者过于简短的回答。这是典型的策略偏离参考模型太远导致的。DPO 里调大 betaPPO 里调大 KL 系数都能缓解。另外降低学习率、减少训练步数也是有效手段。我一般会在训练过程中定期用固定 prompt 集做生成测试一旦发现输出质量下降就回滚到上一个 checkpoint。还有一个容易被忽略的点LoRA 的 rank 和 alpha 也会影响退化速度。rank 太大比如 128时模型可调整的参数多更容易跑偏rank 小一点16 或 32反而更稳。这个和“模型容量越大越好”的直觉相反但在 RL 场景下约束比容量更重要。5.3 显存不够量化、梯度检查点和 offload 三件套单卡做 RL 实验显存永远是瓶颈。除了 4-bit 量化还可以开 gradient checkpointing 和 CPU offload。gradient checkpointing 用时间换显存大概能省 30% 到 40% 显存代价是训练速度慢 20% 左右。CPU offload 把优化器状态放到内存能省更多显存但速度更慢。如果这些还不够就只能减小 batch size 或换更小的模型。在 Jetson Orin Nano 这种边缘设备上部署 Qwen 做推理是可以的但做训练基本不现实。Orin Nano 的显存只有 8G 或 16G跑 4-bit 量化的 Qwen2.5-3B 推理没问题但训练 LoRA 都很勉强。如果你的目标是边缘部署建议在服务器上训练好、量化后导出再放到边缘设备上跑推理。问题现象可能原因排查方向解决手段reward 不涨reward 信号无区分度检查 reward 函数输出分布调整 reward 规则或换 reward modelreward 震荡学习率过大 / KL 太松观察策略更新幅度降学习率、增大 KL 系数输出重复策略偏离参考模型对比训练前后生成增大 beta、减少训练步数显存 OOMbatch 过大 / 未量化监控显存占用4-bit 量化、gradient checkpointing训练速度慢生成吞吐低检查 GPU 利用率用 vLLM 加速生成、异步 rollout5.4 评测怎么做别只看 reward要看真实能力RL 训练最容易自欺欺人的地方就是只看 reward 曲线。reward 涨了不代表模型真的变好了可能只是学会了钻 reward 的空子。我一般会准备三套评测第一套是训练任务上的 held-out 测试集看泛化第二套是通用能力评测比如 MMLU 或 C-Eval 的子集看有没有退化第三套是人工抽检看生成质量是否自然。在 Qwen 上做 LoRA 微调时我习惯每训练 200 步就做一次小规模评测记录三个维度的分数。如果训练任务涨了但通用能力掉得厉害就说明 RL 过度了需要调整数据混合比例或降低训练强度。这个习惯帮我避免了好几次“reward 很好看但模型已经废了”的情况。6. 从 MiMo-V2.6 复盘里能带走的方法论MiMo-V2.6 这次复盘最有价值的地方不是它公布了什么独家技术而是它把大规模 RL 扩展的工程现实讲清楚了这不是一个靠单点创新就能解决的问题而是需要在数据构造、训练策略、评测体系上同时做扎实。MixRL 和 MOPD 这两个思路本质上都是在“稳定性”和“信号质量”这两个维度上做文章。对于手上资源有限的团队或个人我的建议是不要一上来就追求大规模。先用 Qwen 这样成熟的基座在单卡上跑通一套完整的 SFT → 偏好数据构造 → DPO → 评测的流程把每个环节的坑都踩一遍。这个过程可能只需要一两周但收获比直接看论文大得多。等你对 RL 的不稳定性有了体感再考虑扩展到多卡、多机那时候你才知道该在什么地方加资源、什么地方省资源。最后分享一个我在 Qwen 上做 LoRA 微调实战时总结的小技巧每次 RL 实验前先用 SFT 模型在验证集上生成一批样本人工看 20 到 30 条确认格式、风格、逻辑都没问题。这个动作花不了半小时但能帮你排除掉大部分数据层面的低级问题。RL 本身已经够难了别让数据格式这种小事浪费你的 GPU 时间。