【强化学习】Hands-on Modern RL项目实践|OPD 算法完整解析-北京尧图网络

关键词On-Policy Distillation、OPD、Reverse KL、Mode-Seeking、GRPO、RLVR、Tinker、蒸馏写在前面前面几篇文章分别讲了 DPO(用偏好对训练)、GRPO(用组内相对优势训练)、RLVR(用规则验证器给奖励)。这些方法都在回答同一个问题:当我们不想完整跑传统 RLHF 那一整套(训练 RM、跑 PPO)时,训练信号还能从哪里来?DPO 的答案是偏好对,RLVR 的答案是验证器,而这篇文章要讲的OPD(On-Policy Distillation,在线策略蒸馏)给出了第三种答案:用一个更强的 Teacher 模型,在 Student 自己生成的轨迹上,逐 token 给出密集反馈。这个方法最早由 Agarwal 等人在 GKD(Generalized Knowledge Distillation)工作中系统化,2025 年因为 Thinking Machines Lab(Kevin Lu 等)的工程化博客和 Qwen3 的复现结果而被广泛关注,现在已经成为在 GRPO/RLVR 之外训练小模型、特别是训练专才模型的重要选项。一、OPD 要解决什么问题1.1 三种训练范式的对比在讲 OPD 具体怎么做之前,先把它放在三种范式的对比里看清楚它的位置:范式训练轨迹从哪来反馈密度典型问题SFT / 离线蒸馏(SeqKD)Teacher 写好的答案密集(每个 token 都有监督)分布偏移:训练时看 Teacher 的轨迹,推理时却要接着自己生成的内容往下写RL(GRPO/RLVR)Student 自己探索稀疏(通常只有结果级的 0/1 奖励)样本效率低:一个 2000 token 的解题过程,可能只有最后一个 token 才带来学习信号OPDStudent 自己生成密集(Teacher 对每个 token 都能给出反馈)需要一个可靠的、思维模式相近的 Teacher传统监督微调的问题在于训练时和推理时看到的分布不一样:训练时,模型看到的都是 Teacher 写好的标准答案前缀;但推理时,它必须接着自己刚刚生成的内容继续写下去。一旦某一步生成得不够好,后续的生成就会在一个训练时从未见过的分布区域里越走越偏,这就是经典的分布偏移(也叫 exposure bias)问题。标准 RL(比如 GRPO)恰好解决了分布偏移——因为训练轨迹本来就是 Student 自己生成的,训练分布和推理分布是一致的。但 RL 的代价是奖励太稀疏:不管生成了多少个 token,一整条轨迹通常只换来一个标量奖励(答对给 1 分、答错给 0 分),模型很难知道这上千个 token 里究竟哪几步是关键。OPD 的思路是把这两者的优点结合起来:让 Student 按自己的策略生成轨迹(保留 on-policy 的优势),同时让一个更强的 Teacher 沿着这条轨迹逐 token 给出密集反馈(保留监督信号的密度优势)。用一句话概括就是:OPD 同时拿到了 RL 的 on-policy 分布和蒸馏的密集监督。1.2 核心三步流程OPD 的核心流程只有三步:Student 自主 rollout:Student 模型按照自己当前的策略,对给定 prompt 生成一段完整回复。这个过程完全由 Student 独立完成,不受任何外部干预——它就是在做正常的推理;Teacher 逐 token 给出反馈:Teacher 不重写答案,而是沿着 Student 走出来的这条轨迹,在每一步前缀上计算如果是我,这个位置的下一个 token 概率分布应该长什么样,并据此判断 Student 实际选出的这个 token 合不合理;反馈作为密集信号回传:Teacher 对每个 token 的判断被转化成密集的、逐 token 的训练信号,回传给 Student 用于更新参数。把这套流程映射回强化学习的语言:Student 模型就是策略(policy);每一个被选中输出的 token 是一次动作(action);Teacher 对该 token 给出的 log-prob(或者由此计算出的 KL)就是反馈信号。可以把这套体系理解成一种特殊的 RL——奖励函数不是训练出来的 RM,也不是规则验证器,而是一个已经训练好的更强模型。二、为什么选择 Reverse KL2.1 目标函数OPD 可以使用多种散度作为损失函数来给 Student 的轨迹打分,但 Thinking Machines Lab 的工程实践选择了最简单也最有效的一种:逐 token 的反向 KL 散度(per-token reverse KL)——衡量在给定相同历史前缀的条件下,Student 分布πθ\pi_\thetaπθ和 Teacher 分布πteacher\pi_{teacher}πteacher之间的差异:DKL(πθ(⋅∣st) ∥ πteacher(⋅∣st))∑aπθ(a∣st)log⁡πθ(a∣st)πteacher(a∣st) D_{KL}\big(\pi_\theta(\cdot|s_t) \,\|\, \pi_{teacher}(\cdot|s_t)\big) \sum_{a} \pi_\theta(a|s_t) \log\frac{\pi_\theta(a|s_t)}{\pi_{teacher}(a|s_t)}DKL(πθ(⋅∣st)∥πteacher(⋅∣st))a∑πθ(a∣st)logπteacher(a∣st)πθ(a∣st)这里的下标顺序很关键:是DKL(πθ∥πteacher)D_{KL}(\pi_\theta \| \pi_{teacher})DKL(πθ∥πteacher),而不是DKL(πteacher∥πθ)D_{KL}(\pi_{teacher} \| \pi_\theta)DKL(πteacher∥πθ)——期望是相对于Student 自己的采样分布来算的,这也是为什么它被称为reverse(相对于传统蒸馏里更常用的 forward KL 而言)。训练目标是让这个散度最小化,促使 Student 在每一个它自己真实走到的状态上,都去逼近 Teacher 在同样状态下的行为。2.2 Reverse KL 的两个关键性质选择 reverse KL 而不是 forward KL,是因为它有两个非常契合 OPD 场景的性质:性质一:不可被投机取巧(unhackable)。和大多数实践中的奖励模型不同,reverse KL 作为奖励很难被作弊——因为从 Teacher 的视角看,低 KL 永远对应着 Student 表现出了 Teacher 认可的高概率行为,不存在钻空子拿高分但实际没做对的空间。这一点和前面提到的 verifier 抗作弊原则是一致的:目标函数本身的结构决定了它不容易被绕过。性质二:“模式寻找”(mode-seeking)。当 Teacher 分布是多峰的(比如同一个问题有多种合理解法)时,forward KL 具有模式覆盖(mass-covering)“倾向——为了不遗漏任何一个峰,Student 会把概率质量分散到所有峰之间,甚至包括峰与峰之间那些实际上没有意义的幻觉区域”;而 reverse KL 具有模式寻找(mode-seeking / zero-forcing)倾向——Student 会集中学习某一个具体的峰(通常是 Teacher 更确信的那个),完全放弃其他备选模式。对于语言生成这种需要给出一个具体、连贯输出的任务,mode-seeking 通常是更合适的选择——半个模式加半个另一个模式拼起来的输出,在离散的 token 序列里往往是没有意义的乱码。2.3 一个额外的工程红利:不需要跑完整条轨迹因为 reverse KL 是逐 token 定义的,不需要等一整条轨迹采样完成才能计算奖励,所以可以直接用更短的、甚至是不完整的轨迹片段来训练——这在工程上能省下不少计算资源。而且查询 Teacher 的 log 概率只需要 Teacher 做一次前向传播,真正负责生成轨迹的是更小、更便宜的 Student 模型;整个流程也不再需要单独训练一个奖励模型或标注模型。2.4 一个信息论视角:为什么密集反馈更高效Thinking Machines Lab 给出了一个很直观的信息论解释:标准 RL 每一条轨迹(episode)大约只能传递O(1)O(1)O(1)bit 的信息量——不管这条轨迹生成了多少 token,最终能用来更新模型的本质上就是这条轨迹好不好这一个比特左右的判断。而蒸馏(distillation)每条轨迹能传递大约O(N)O(N)O(N)bit 的信息量,其中NNN是 token 数——因为 Teacher 对轨迹中的每一个 token 都给出了一次独立的判断。这个数量级上的差异,直接解释了为什么在样本效率上,OPD 常常能用远少于纯 RL 的训练量,达到相近甚至更好的效果。可视化地看,如果把 Teacher 给每个 token 的 reverse KL 惩罚大小用颜色深浅标注出来,会发现惩罚并不是均匀分布的——大多数 token 上 Teacher 和 Student 的分布高度一致(惩罚接近零),真正被显著惩罚的往往是那些关键转折点:引出错误推理方向的起始短语、开启一条错误分支的连接词等,直觉上正对应着推理链条里的分叉 token(forking token)。反而最终答案 token 本身即便是错的,也常常不会被显著惩罚——因为给定前面已经写错的全部推理过程,那个错误答案在条件概率上其实是完全可预测的,真正需要纠正的是更早的分叉点。三、OPD 与 GRPO / RLVR 的关键区别理解 OPD 最好的方式是把它放进前几篇文章已经建立的坐标系里对比。区别集中在两个维度:第一个维度:训练轨迹由谁生成。SFT / SeqKD 用的是 Teacher 写好的答案;GRPO 用的是 Student 自己的探索;OPD 同样用 Student 自己的轨迹——这一点上 OPD 和 GRPO 是一致的,都规避了传统蒸馏的分布偏移问题。第二个维度:反馈有多密。GRPO / RLVR 通常是结果级奖励——一个 2000 token 的解题过程,只有最后一个 token 附带的那个 0 或 1;OPD 则几乎每个 token 都有反馈信号,因为 Teacher 对每一步都能给出 log 概率。这也是为什么 OPD 常被形容为把 Teacher 变成一个密集奖励函数。从蒸馏方法自身的演化脉络看,也能看到同样的模式:早期方法(SFT 阶段的蒸馏)里 Teacher 是纯粹的数据生产者,Student 只是模仿 Teacher 走过的轨迹;而 OPD 里 Teacher 的角色变成了奖励提供者,Student 在自己真正会走到的状态上被纠偏。OPD 的动机正是要消除分布偏移:既然 Student 推理时看到的永远是自己生成的上下文,那么训练时也应该直接在这些区域给出信号,而不是只在 Teacher 走过的路径上铺设数据。一个常见的进一步问题是:OPD 是否可以和 GRPO/RLVR同时使用?答案是肯定的,而且这是当前工程实践中很主流的做法。因为 OPD 本质上是在给策略梯度目标加一个 KL 正则项,所以它天然可以叠加在任何优势估计器之上——不管底层用的是 GRPO、PPO 还是别的 estimator,都可以在优势计算里额外减去一个由 Teacher 给出的 token 级 reverse KL 惩罚:A^tAt−λopd⋅DKL(πteacher ∥ πθ)t \hat{A}_t A_t - \lambda_{opd} \cdot D_{KL}\big(\pi_{teacher} \,\|\, \pi_\theta\big)_tA^tAt−λopd⋅DKL(πteacher∥πθ)t其中AtA_tAt是底层 estimator(比如 GRPO 的组内归一化优势)算出的原始优势,λopd\lambda_{opd}λopd是 OPD 惩罚项的权重系数。这意味着 OPD 并不是一个和 GRPO 互斥的独立算法,而更像是一个可以叠加在任意策略优化方法之上的正交模块——工程上通常实现为对已有的 RL 训练脚本做一处很小的改动:把原本用于 KL 正则的参考模型,换成一个能力更强的 Teacher 模型即可。四、工程实现4.1 最小实现骨架一个最简 OPD 训练步骤的核心逻辑大致如下:importtorchimporttorch.nn.functionalasFdefopd_training_step(student_model,teacher_model,tokenizer,prompts,max_new_tokens512,temperature0.8):一个 OPD 训练步student 生成 - teacher 逐token评分 - reverse KL loss# 阶段 1Student 自主 rollout不受外部干预withtorch.no_grad():input_idstokenizer(prompts,return_tensorspt,paddingTrue).input_ids output_idsstudent_model.generate(input_ids,max_new_tokensmax_new_tokens,temperaturetemperature,do_sampleTrue,)# 阶段 2在 student 生成的完整序列上分别计算 student 和 teacher 的逐 token 分布student_logitsstudent_model(output_ids).logits[:,:-1,:]withtorch.no_grad():teacher_logitsteacher_model(output_ids).logits[:,:-1,:]student_logprobsF.log_softmax(student_logits,dim-1)teacher_logprobsF.log_softmax(teacher_logits,dim-1)# 阶段 3逐 token 的 reverse KL —— D_KL(student || teacher)# 只在 student 实际选出的 token 上生效的简化实现token级奖励近似student_probsstudent_logprobs.exp()reverse_kl(student_probs*(student_logprobs-teacher_logprobs)).sum(dim-1)# reverse KL 越小越好转化为 loss 直接最小化lossreverse_kl.mean()loss.backward()return{loss:loss.item(),mean_kl:reverse_kl.mean().item()}真实的工程实现(比如 Tinker 的 cookbook)通常在 RL 训练脚本的基础上做很小的改动——因为标准 RL 实现里本来就有用参考模型算 KL 正则这一步,OPD 只是把这个参考模型换成了一个能力更强的 Teacher,再把这个 reverse KL 当作(或叠加成)奖励信号本身,而不仅仅是一个正则项。4.2 与 GRPO 训练框架整合的配置示例在已经支持 GRPO 的训练框架里接入 OPD,一般只需要在训练配置里新增一个蒸馏相关的模块,声明 Teacher 模型路径、损失函数形式,以及是否与策略梯度损失联合训练:distillation:enabled:Trueteacher_models:teacher_model:model_path:Qwen/Qwen3-32B# HF 路径或本地路径distillation_loss:loss_mode:k3# 可选 k1 / k3 / forward_kl_topk 等不同 KL 估计方式use_policy_gradient:True# 是否与 GRPO 的策略梯度 loss 联合训练topk:64# teacher 只传 top-k logits节省显存与通信开销其中topk参数值得一提:完整传输 Teacher 在整个词表上的 logits 通信开销很大,工程上通常只传输概率质量最集中的 top-k 个 token 的 logits,用截断后的分布近似完整的 KL 计算,这是一个精度和效率之间的常见权衡。4.3 实测效果Thinking Machines Lab 使用 Tinker 训练 API 复现了 Qwen3 报告中的结果:在数学推理这类基准上,先用 SFT 在公开推理数据集(如 OpenThoughts)上冷启动,再叠加 OPD 从一个更强的 Teacher 蒸馏,能够达到和完整走一遍 RL 流程相当甚至更好的效果,而所需的计算成本只是完整 RL 的一小部分。这也是 Qwen3 系列在训练 hybrid reasoning 模型和专才模型(specialist distillation)时采用的关键技术之一。五、局限性与前沿动态5.1 Teacher-Student 的思维模式一致性一个反直觉但被反复验证的现象是:换一个参数量更大、benchmark 分数更高的 Teacher,蒸馏效果不一定更好,甚至可能直接把训练训崩。研究发现 OPD 能否成功,很大程度上取决于 Teacher 和 Student 之间的思维模式一致性(Thinking-Pattern Consistency)——如果两者初始状态下的 token 重叠率(在同一个 prefix 下两者高概率候选 token 的重合程度)过低,蒸馏就容易失效。举例来说,一个 base 模型 Student 向经过 GRPO 强化训练后的同源 base 模型学习,通常比向一个推理风格完全不同的模型学习效果更好——因为前者的推理模式和 Student 天然更接近,Teacher 给出的密集监督信号更容易被 Student “消化”。这也是为什么很多实践中会选择用 RL 先训出一个强 Teacher,再用这个 Teacher 对同源的小模型做 OPD这种两阶段流程,而不是随便挑一个市面上最强的模型当 Teacher。5.2 长序列上的稳定性问题把 OPD 直接应用到长思维链推理任务时,还会遇到一些工程层面的挑战:序列越长,逐 token 的 KL 累积误差就越容易放大;不同任务难度下,固定的散度形式和固定的惩罚系数不一定都合适。近期的一些研究方向包括:根据 Teacher 的置信度动态在 forward KL 和 reverse KL 之间切换(熵感知 OPD)、只在局部可教的位置提供密集监督而在教师置信度崩塌的区域及时截断(动态释放规则)、以及把密集的 token 级 KL 监督和验证器给出的稀疏结果级奖励结合起来联合训练,取两者之长。5.3 与自蒸馏的结合除了依赖外部更强 Teacher 的经典设定,OPD 的思想也被扩展到了无需外部 Teacher 的自蒸馏(self-distillation)场景——比如让同一个模型在不同上下文条件下扮演 Teacher 和 Student 两个角色,或者利用同一组内(GRPO 意义上的组)其他成功的 rollout 作为隐式 Teacher,为失败的 rollout 提供密集纠偏信号。这类方法进一步降低了 OPD 对外部强模型的依赖,让蒸馏式的密集监督也能在没有更强 Teacher 可用的场景下发挥作用。六、全文脉络回顾把 OPD 放回本系列的整体版图里看:OPD 解决的核心问题是标准 RL 反馈过于稀疏、传统离线蒸馏又存在训练-推理分布偏移这两个问题的交集——它让 Student 按自己的策略生成轨迹(保留 on-policy 特性),同时让 Teacher 逐 token 给出密集反馈(保留监督密度);核心机制可以概括为三步:Student 自主 rollout,Teacher 沿轨迹逐 token 评分,评分转化为密集信号回传;损失函数上,选择per-token reverse KL是因为它具有不可被投机利用、以及在语言生成任务上更合适的模式寻找这两个关键性质;信息论的视角说明了为什么 OPD 通常比纯 RL 样本效率更高:标准 RL 每条轨迹只传递大约O(1)O(1)O(1)bit 信息,而密集 token 级监督能传递大约O(N)O(N)O(N)bit;工程上,OPD 并不是 GRPO/RLVR 的替代品,而是一个可以叠加在任意优势估计器之上的正交模块——只需把优势计算里额外加入一个由 Teacher 给出的 reverse KL 惩罚项,就可以让 GRPO、PPO 等任意策略优化方法同时获得密集监督的收益;OPD 的效果高度依赖Teacher 与 Student 的思维模式一致性,盲目换用更强但风格迥异的 Teacher 反而可能让训练崩溃,这也是当前研究和工程实践共同关注的核心变量。从 DPO 到 GRPO/RLVR 再到 OPD,这条脉络反映了同一个大方向:LLM 后训练正在从完整走一遍传统 RLHF 流水线逐渐演化成针对具体场景挑选最合适的训练信号来源——偏好对、规则验证器、更强的 Teacher 模型,乃至它们的组合,共同构成了当前后训练工具箱里越来越丰富的选项。参考:Agarwal R, Vieillard N, Zhou Y, et al. “On-Policy Distillation of Language Models: Learning from Self-Generated Mistakes”(GKD), ICLR 2024;Lu K, Thinking Machines Lab. “On-Policy Distillation”, Thinking Machines Lab: Connectionism, 2025;Gu et al. “MiniLLM: Knowledge Distillation of Large Language Models”, 2023;Li Y, Zuo Y, He B, et al. “Rethinking On-Policy Distillation of Large Language Models: Phenomenology, Mechanism, and Recipe”, arXiv 2026

【强化学习】Hands-on Modern RL项目实践|OPD 算法完整解析

相关推荐

15 天 3 连发：DeepSeek 的「机枪」节奏，到底在下什么棋？

正式评优怎么选投票工具？人人微投票审计级防刷能力实测

SQL 调优 [ 2 ]

更多资讯

Open Code Review：CLI+Git+本地LLM驱动的可审计代码评审范式

2025 AI大模型开发技术栈地图：从RAG到Agent的实操指南

基于GL3224的USB3.0 TF读卡器硬件设计：原理图与PCB实战解析

异构固定翼无人机集群协同搜索的Matlab实现与避障设计

Java SE蓝牙开发实战：SPP通信全链路实现与跨平台适配

Laya项目发布自动化：用Bat脚本实现打包、解压与同步

今日更新

悟空开源无代码平台实战：从实体建模到应用设计避坑指南

基于.NET9的多租户权限系统：数据权限与动态API落地实践

场地预约小程序毕设实战：SSM+微信小程序+MySQL数据库设计到避坑

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？