RL 与 OPD：从数学到代码

最近发生了什么

截至 2026 年 8 月 3 日，一场围绕 RL 与 OPD 的大模型训练讨论正在开发者社区升温。近日，研究者 John Olafenwa 在 Reddit 的 Machine Learning 社区发布了一份深度讲解，试图把预训练、监督微调、GRPO 式强化学习和 On-Policy Distillation 串进同一套数学与代码框架中；讨论指向的并不是某个新算法，而是 Kimi、DeepSeek、Qwen、GLM 等推理模型技术报告背后越来越清晰的后训练路线。

强化学习（Reinforcement Learning，RL）是一类通过环境奖励直接优化模型行为的训练方法。 在数学、代码和形式化证明任务中，答案校验器、单元测试与编译器可以提供相对可靠的奖励，因此 RL 能让模型探索监督数据里没有出现过的解题路径。

同策略蒸馏（On-Policy Distillation，OPD）是一类让学生模型先生成轨迹，再由教师模型在这些真实访问状态上提供密集监督的后训练方法。 它的关键不只是蒸馏，而是训练状态来自当前学生策略：教师不是拿一批固定答案让学生模仿，而是在学生自己走到的位置上告诉它下一步的概率分布应该是什么。

这轮讨论的核心结论很直接：RL 更擅长发现策略，OPD 更擅长复制和合并策略。 把 OPD 当作低成本 RL，或者把 RL 当作只有一个标量标签的蒸馏，都会掩盖二者在信号来源、泛化能力和工程风险上的实质差异。

先把预训练、SFT、RL 和 OPD 放在一张图里

大语言模型训练的主线可以概括为：先压缩世界知识，再学习交互格式，最后塑造任务策略。 预训练和 SFT 都在做下一 Token 预测，但数据来源不同；GRPO 与 OPD 都会让当前模型生成轨迹，但反馈信号不同。

| 训练阶段 | 状态或轨迹来源 | 监督信号 | 信号密度 | 主要解决的问题 | 典型风险 | |---|---|---|---|---|---| | 预训练 | 大规模自然语料 | 真实下一 Token | Token 级密集信号 | 学习语言、知识与代码模式 | 数据噪声、目标与产品需求错位 | | SFT | 固定人工或合成答案 | 目标 Token | Token 级密集信号 | 学习指令格式和标准回答方式 | 只能模仿已有轨迹，存在分布偏移 | | GRPO / RLVR | 当前或近似当前策略采样 | 校验器、测试或奖励模型 | 通常是序列级稀疏信号 | 探索更高回报的解题策略 | 奖励投机、梯度方差、模式坍缩 | | OPD | 当前学生策略采样 | 教师在每个状态上的概率分布 | Token 级密集信号 | 高效转移、合并教师策略 | 继承教师缺陷、教师推理成本高 |

预训练是对海量文本分布进行压缩的下一 Token 预测过程。 给定上下文 x 和目标序列 y，模型最小化负对数似然：

$$ L_{PT} = - Σ_t log p_θ(y_t | x, y_{<t}) $$

监督微调（Supervised Fine-Tuning，SFT）是使用精选指令—答案数据继续进行下一 Token 预测。 它与预训练的损失函数看起来相似，但数据从自然文本变成了助手式回答、工具格式和领域示范，因此改变的是模型行为分布，而不只是知识量。

SFT 的根本限制是训练轨迹与推理轨迹不一致。 训练时，模型始终看到专家写出的正确前缀；部署时，模型必须接着自己刚刚生成的 Token 往下写，一旦前面发生偏差，后续状态可能从未在 SFT 数据中出现。这就是典型的 exposure bias，也是 OPD 强调 on-policy 的原因。

GRPO 到底在优化什么

Group Relative Policy Optimization（GRPO）是一种用同一问题下多条候选回答构造相对优势的策略优化方法。 它不必为每个样本训练独立的价值网络，而是让一组回答互相充当基线，因此比经典 PPO 更适合长文本推理训练。

给定问题 x，旧策略为同一个问题采样 G 条回答：

$$ y_1, y_2, ..., y_G ∼ π_{old}(.|x) $$

每条回答经过答案校验器或代码测试后得到奖励 r_i，再计算组内标准化优势：

$$ A_i = (r_i - mean(r)) / (std(r) + ε) $$

训练时再使用裁剪后的概率比率更新模型，并通常加入参考模型 KL 惩罚，防止策略一步走得太远：

$$ ratio_{i,t} = π_θ(y_{i,t}|s_{i,t}) / π_{old}(y_{i,t}|s_{i,t}) $$

$$ L_{GRPO} = -E[min(ratio × A, clip(ratio, 1-ε, 1+ε) × A)] + β KL(π_θ || π_{ref}) $$

GRPO 的有效信息来自同组回答之间的奖励差异。 假设一次采样 8 条数学答案，其中 4 条正确、4 条错误，奖励分别为 1 和 0；此时均值为 0.5，按总体标准差计算得到 0.5，正确和错误轨迹的标准化优势分别约为 1 和 -1，模型就有了清晰的更新方向。

GRPO 的失效点也来自同组回答之间没有差异。 如果 8 条回答全部错误，组内标准差接近 0，多数实现会通过 ε 避免除零，但标准化优势仍接近 0，这个问题几乎不产生有效梯度；如果 8 条回答全部正确，同样缺少继续区分普通解法与优秀解法的信号。

序列奖励还会带来信用分配问题。 一条 1000 Token 的代码推理最终通过单元测试，GRPO 往往把同一个正优势作用到整条序列上，但真正起决定作用的可能只有其中 20 个 Token；格式套话、重复检查甚至偶然蒙对的步骤，也会一起受到奖励。

这并不意味着 GRPO 不好用。恰恰相反，在数学答案、编译结果、单元测试和形式化检查这类可验证任务上，环境反馈比教师模仿更接近最终目标，RL 因而更可能发现教师没有展示过的新策略。

OPD 为什么比普通蒸馏更像在线纠错

OPD 的 on-policy 指学生产生训练状态，而不是教师产生训练答案。 学生先对问题 x 生成轨迹 y，在每个前缀状态 s_t = (x, y_{<t}) 上，教师和学生分别计算下一 Token 分布，再通过 KL 散度或交叉熵拉近两者。

一个典型的正向 KL 目标是：

$$ L_{OPD}^{forward} = E_{s∼π_θ}[D_{KL}(p_T(.|s) || p_θ(.|s))] $$

正向 KL 更强调覆盖教师认为合理的多个候选。 当教师在一个位置上认为 A、B 两种写法都合理时，学生需要为两者保留概率质量，因此通常更偏向 mode-covering。

另一类实现使用反向 KL：

$$ L_{OPD}^{reverse} = E_{s∼π_θ}[D_{KL}(p_θ(.|s) || p_T(.|s))] $$

反向 KL 更倾向于集中到教师分布中的高概率模式。 它可能让输出更锐利，但也更容易忽略教师分布中概率较低、仍然合理的表达，因此具体选择要结合任务、温度和蒸馏稳定性判断。

OPD 的密集性体现在每个生成位置都可以获得监督。 对一条 1000 Token 的轨迹，GRPO 可能只有 1 个最终奖励，OPD 则能在最多 1000 个位置上比较师生分布；教师不仅能指出整道题做得不好，还能在学生刚开始偏离正确推理方式时就给出方向。

OPD 的最大误区是把教师分布当成环境真理。 教师只是某个任务映射的近似，不是任务本身；如果教师习惯冗长推理、错误自检或特定格式投机，学生会高效而稳定地把这些缺陷一起学走。社区已有实践者报告，在强教师与弱学生能力差距过大时，OPD 甚至可能让学生性能下降，因为学生无法在自身容量内复现教师的完整策略分布。

为什么 OPD 不是便宜版 RL

RL 与 OPD 的根本区别是优化目标分别来自环境和教师。 RL 问的是这条轨迹最终有没有解决问题，OPD 问的是学生在自己走过的状态上是否像教师。

| 维度 | GRPO / RLVR | OPD | |---|---|---| | 最终优化对象 | 环境回报或奖励模型分数 | 教师策略分布 | | 是否依赖教师模型 | 不一定 | 通常需要 | | 是否需要可验证环境 | 最好有 | 不强制 | | 监督粒度 | 多为序列级，也可扩展到步骤级 | Token 级或步骤级 | | 探索新策略能力 | 较强 | 受教师上限约束 | | 收敛稳定性 | 受奖励方差和采样质量影响较大 | 通常更平滑 | | 多任务合并 | 容易发生奖励尺度冲突 | 适合多教师分域蒸馏 | | 典型任务 | 数学、代码、工具执行、形式化证明 | 能力迁移、多专家合板、行为压缩 |

OPD 更适合解决多任务后训练中的专家合并问题。 数学团队可以先训练数学教师，代码团队可以独立训练代码教师，指令团队再维护通用教师；学生根据领域路由向不同教师学习，不必把所有奖励函数、采样器和执行环境塞进一次混合 RL 任务里。

多教师 OPD 可能缓解灾难性遗忘，但不会自动消除专家冲突。 如果数学教师偏好极长推理，代码教师偏好直接输出程序，而通用教师要求简短回答，训练系统仍需要明确的数据比例、任务路由、长度归一化和 KL 权重，否则学生只会向样本量最大或分布最尖锐的教师倾斜。

Agent 任务通常比纯数学任务更依赖真实环境反馈。 工具调用会改变外部状态，错误动作可能让后续观察完全不同，而教师在固定文本前缀上给出的 Token 分布无法完整表达环境动力学；因此长链工具任务更适合用执行成功率做 RL 主信号，再用 OPD 蒸馏格式、规划风格或已经验证成功的策略。

从公式落到训练循环

一个最小 OPD 训练循环只需要四步：学生采样、教师打分、计算散度、更新学生。 下面是训练伪代码而非 API 调用代码，重点在数据流而不是具体框架接口。

for prompts in dataloader:
    # 1. 当前学生生成，因此状态分布是 on-policy
    trajectories = student.generate(prompts)
    states = concat(prompts, trajectories)

    # 2. 教师只负责给学生访问过的状态提供分布
    teacher_logits = teacher.forward_no_grad(states)
    student_logits = student.forward(states)

    # 3. 只在学生回答区间计算损失，屏蔽 prompt 与 padding
    teacher_probs = softmax(teacher_logits / temperature)
    student_log_probs = log_softmax(student_logits / temperature)
    loss = masked_kl(teacher_probs, student_log_probs, response_mask)

    # 4. 只更新学生参数
    loss.backward()
    optimizer.step()
    optimizer.zero_grad()

真正昂贵的部分不是 KL 公式，而是教师前向和全词表 Logits。 如果词表大小为 150000，使用 BF16 保存每个位置的教师 Logits 约需 300000 字节；一条 4096 Token 序列对应约 1.23 GB 十进制容量，尚未计算 batch、学生 Logits、激活值和优化器状态。

工程上通常要避免完整物化整段全词表 Logits。 可行方案包括按序列分块计算 KL、教师与学生流水并行、只保留教师 top-k 概率并单独聚合尾部质量，或者在同一训练进程中即时计算并立即释放教师输出；但 top-k 会改变原始 KL 目标，不能在报告里假装与全词表监督完全等价。

直接进行全词表 OPD 通常要求师生共享 Tokenizer 和词表映射。 如果教师是只能返回文本的黑盒模型，学生拿不到逐 Token Logits，那么训练更接近在线合成数据 SFT、序列级蒸馏或偏好学习，而不是严格意义上的全词表 OPD。

一套更稳妥的数学与代码训练路线

最实用的方案不是在 RL 和 OPD 之间二选一，而是让二者承担不同阶段的工作。 对数学和代码模型，可以按下面的顺序组织训练。

第一步：先用 SFT 建立可用的起点

SFT 阶段要优先解决格式、基础推理和工具协议问题。 如果基础模型连答案边界、代码块格式或工具参数都不稳定，RL 采样会产生大量不可验证轨迹，OPD 也会把算力浪费在教师纠正低级格式错误上。

建议至少检查以下指标：

• 数学答案能否被规则稳定提取；
• 代码是否能编译、运行并在沙箱中终止；
• 最大生成长度触顶比例；
• 空回答、重复回答与无效工具调用比例；
• 通用指令集上的能力是否明显退化。

第二步：按领域分别训练 RL 专家

RL 专家阶段要让环境奖励负责发现有效策略。 数学模型使用最终答案校验，代码模型使用编译器和单元测试，工具模型使用真实执行结果；不要让一个含糊的通用奖励模型同时裁决所有领域。

一个可用于起步的采样设置是每个问题生成 8 或 16 条回答，但这不是通用最优值。候选越多，组内越容易形成奖励差异，生成成本也按候选数近似线性增长；如果正确率接近 0%，应先降低题目难度或加强 SFT，而不是盲目把组大小从 8 提到 64。

第三步：用多教师 OPD 做能力合板

多教师 OPD 阶段要按样本领域选择教师，而不是把教师 Logits 无条件平均。 对同一个问题平均数学教师和代码教师的分布，可能得到一个谁都不像的软标签；更合理的方式是显式领域路由，或者根据教师在验证器上的可信度动态分配权重。

混合目标可以写成：

$$ L = λ_{math}L_{OPD}^{math} + λ_{code}L_{OPD}^{code} + λ_{general}L_{SFT}^{general} $$

保留一部分高质量通用 SFT 数据是对抗遗忘的低成本保险。 OPD 虽然能比串行 RL 更平滑地合并专家，但如果所有采样都来自数学和代码提示，模型仍可能失去写作、问答与安全拒答能力。

第四步：再用小规模 RL 对最终模型验收

最终 RL 阶段应直接检查合板后的学生是否真的解决了任务。 OPD 优化的是教师相似度，不是下游正确率；一次短周期、低学习率的 RL 或离线验证，可以发现学生是否学会了教师的表面推理风格，却没有继承真正的解题能力。

五个最常见的排错信号

训练日志必须同时观察能力指标、分布指标和生成行为。 只看 KL loss 下降不足以证明模型变强，因为学生完全复现一个有缺陷的教师时，KL 同样可以很好看。

| 现象 | 更可能的原因 | 优先排查动作 | |---|---|---| | GRPO 奖励长期不动 | 同组样本全对或全错，优势接近 0 | 查看每组奖励方差，调整难度与采样温度 | | 奖励上升但真实测试下降 | 奖励投机或验证器漏洞 | 增加隐藏测试、格式扰动与人工抽检 | | OPD loss 下降但准确率下降 | 教师策略不适配学生，或教师本身有缺陷 | 换弱一些但更匹配的教师，按领域做消融 | | 输出越来越长 | 长度未进入奖励或蒸馏掩码包含噪声后缀 | 加长度约束，裁剪无效尾部，检查 EOS 学习 | | 多任务训练剧烈偏科 | 数据比例、教师熵或损失尺度不一致 | 分域记录 loss，做权重归一化与独立评测 |

回复后半段的低质量推理是 OPD 中经常被忽略的噪声源。 如果模型在得到正确答案后继续自言自语 500 Token，教师对这些位置给出的分布仍会进入损失；这类密集监督并非越多越好，按答案终止位置裁剪、只蒸馏有效步骤，往往比机械覆盖整段回复更合理。

教师温度会直接改变学生看到的知识密度。 温度过低时，教师分布接近 one-hot，OPD 退化得更像在线 SFT；温度过高时，大量低概率 Token 获得权重，容易引入噪声。正确做法是同时报告温度、KL 方向、是否使用 top-k，以及损失是否乘回温度平方，而不是只写一句使用了 OPD。

我们的判断：先让 RL 找路，再让 OPD 修路

RL 与 OPD 的最佳关系不是替代，而是分工。 RL 借助环境奖励探索未知策略，OPD 把已经验证有效的策略快速传给更小模型或合并进统一模型；前者像让模型在真实赛道上试车，后者像把优秀车手的每一次方向修正记录下来，教给下一位车手。

OPD 在 2026 年值得重视的原因是它击中了多团队后训练的工程瓶颈。 串行训练数学、代码和通用能力容易产生链式遗忘，混合 RL 又要同时处理奖励尺度、执行环境和采样方差；多教师 OPD 允许各领域团队独立维护专家，再通过密集信号合板，组织收益可能比单项跑分收益更大。

OPD 仍然不应被包装成没有缺点的新范式。 它需要教师前向、词表兼容和大量 Logits 计算，学生还会继承教师的偏见与捷径；在需要真实环境探索、长程信用分配和域外泛化的任务上，RL 通常仍是更直接的选择。

一套可信的后训练报告必须同时交代奖励、教师、轨迹和评测。 如果只公布最终分数，不说明轨迹是否来自当前学生、教师是否提供全词表分布、GRPO 组大小是多少、是否混入通用 SFT 数据，那么所谓 RL 或 OPD 增益很难被复现，也无法判断提升究竟来自算法还是数据。

参考来源

• Reddit：Deep Dive on RL and OPD for Training LLMs：近期引发讨论的 RL、GRPO、OPD 数学与训练代码深度讲解入口。
• 知乎：大模型后训练与强化学习——OPD：中文 OPD 原理、多任务后训练与专家冲突背景梳理。
• Hugging Face TRL：GRPO Trainer：GRPO 训练目标、参数与工程实现文档。
• Hugging Face TRL：GKD Trainer：广义知识蒸馏与学生生成轨迹训练的实现参考。
• GitHub：DeepSeek-R1：DeepSeek-R1 模型、技术说明及强化学习推理路线资料。