先说结论：DPO 和 PPO 不是“新旧替代关系”

DPO 和 PPO 都是在 SFT 之后继续做偏好对齐，让模型不只“能回答”，还更倾向于给出人类认为有帮助、真实、安全、符合场景的回答。它们最大的差别，不是名字里有没有“强化学习”，而是训练信号如何产生。

一句话记忆
PPO 是“先训练裁判，再让选手在训练中不断比赛、拿分、改动作”；DPO 是“直接拿成对比赛录像，告诉选手哪段表现更好”。

PPO 会用当前策略生成新回答，再由奖励模型或可验证环境打分，属于在线策略优化；DPO 直接读取已经准备好的 chosen / rejected 偏好对，属于离线偏好优化。前者更能探索，后者更容易训练和复现。

SFT 与偏好对齐解决的是两个不同问题

SFT 之后，为什么还需要 DPO 或 PPO？

预训练让模型学会语言和知识，SFT 让模型学会按照指令组织回答。但是 SFT 的主要训练信号仍然是“模仿这份答案”，它并不会自动获得稳定的质量排序能力。

例如，同一个问题可以有多份都能用的答案：一份很短，一份很完整；一份直接给代码，一份先说明风险；一份承认不确定性，一份语气自信但事实错误。SFT 可以把某种写法教给模型，却很难只靠单一标准答案表达“哪一份更受用户欢迎”。

DPO 与 PPO 都属于大模型 Post-Training 的偏好对齐阶段

偏好对齐真正学的是什么？
不是给所有回答贴上绝对分数，而是让模型逐渐掌握相对判断：同一个问题下，哪个回答更有帮助、更可靠、更安全、更符合产品规则。

PPO：先培养“裁判”，再训练“选手”

PPO 最初是一类通用的在线策略梯度算法。用到大模型 RLHF 时，通常先把人类偏好变成一个可以自动打分的奖励模型，然后让主模型不断生成回答、获得奖励、计算优势并更新参数。

先把人类排序训练成奖励模型

标注员看到同一个问题的多个候选回答，只需要排序或成对选择。奖励模型把这种“谁更好”的信息学成一个可比较的分数。后续 PPO 训练就可以批量调用它，不必让人类实时参与每一次梯度更新。

再让主模型进入在线学习闭环

训练开始后，Policy 根据一批 prompt 生成回答；Reward Model 或环境给回答打分；Value Function 估计基线，帮助判断这次回答“比预期好多少”；最后 PPO 用受限制的小步更新修改 Policy。新的 Policy 再生成下一批回答，数据分布也随之变化。

PPO 为什么经常被说成“四模型架构”？

常见 RLHF 实现会出现 Policy、Reference、Reward 和 Value 四类职责。Policy 是正在训练的语言模型；Reference 通常是冻结的 SFT 模型，用来约束整体漂移；Reward 给完整回答打分；Value 估计状态价值，降低策略梯度方差。

别把“四模型”理解得太死
很多实现会让 Value Head 与 Policy 共享 Transformer 主干，也可能把 Reward Model 做成同一基座上的适配器。因此，四类功能不等于永远要在显存里放四份完整的大模型权重。

Clip 和 KL 是同一件事吗？

不是。PPO-Clip 比较“新策略”和“采样这批数据时的旧策略”，限制一次更新别迈得太大；RLHF 中常见的 KL 惩罚则比较当前 Policy 与冻结的 Reference，防止模型为了追逐奖励而远离原来的语言能力与行为边界。

PPO 的优势是训练中可以继续探索：当前策略会生成偏好数据里没有出现过的新回答，只要奖励模型或环境能正确评价，就可能把这些新行为强化下来。但它的难点也来自这里：采样、打分、优势估计、策略更新彼此耦合，一处不稳定就会传导到整个链路。

DPO：绕过显式裁判，直接学习偏好差距

DPO 使用的仍然是人类偏好数据，但它不先训练一个独立奖励模型，也不在训练循环里运行 PPO。它把标准的带 KL 约束偏好优化目标重新参数化，得到一个可以直接在偏好对上优化的分类式损失。

DPO 数据长什么样？

一条典型样本由 prompt、chosen 和 rejected 组成。chosen 是同一问题下更受偏好的回答，rejected 是较差回答。它们最好来自同一生成分布，并且差异应当能对应清晰的产品偏好，而不是随机挑一长一短。

DPO 训练时做了什么？

Policy 和冻结的 Reference 分别计算 chosen 与 rejected 的序列对数概率。DPO 不只看 Policy 更喜欢谁，还看 Policy 相比 Reference 对两份回答分别改变了多少。只要 chosen 的“相对提升”比 rejected 更大，训练方向就是正确的。

一个容易忽略的细节
DPO 直接优化的是 chosen 与 rejected 的相对优势。某些训练阶段里，chosen 的绝对概率未必明显上升，也可能是 rejected 下降得更多。因此监控时不能只盯 chosen loss。

Reference Model 为什么不能随便去掉？

Reference 提供了一个稳定基准。没有它，模型只需要机械地拉大 chosen 和 rejected 的概率差，容易把训练变成普通的“奖励赢家、惩罚输家”，却失去对原始模型分布的约束。Reference 让 DPO 学的是“相对于起点，偏好方向应该怎样改变”。

beta 怎么理解？

在 Hugging Face TRL 当前的 DPO 配置中，beta 默认是 0.1。更大的 beta 通常意味着更强的参考约束、更少偏离；更小的 beta 会让偏好信号推动得更激进。实际项目不能只靠经验值，要结合验证集胜率、reward margin、生成质量和通用能力回归共同选择。

PPO 与 DPO 的本质差别：在线与离线

PPO 的训练样本由当前 Policy 在训练过程中持续生成，因此模型行为改变后，后续数据也会改变；DPO 读取固定的偏好数据集，训练期间不会自动扩展新的回答空间。这个差异直接决定了两者的能力边界。

在线探索让 PPO 更适合数学、代码、工具调用等可以自动验证奖励的场景，也适合需要主动寻找新策略的任务；离线训练让 DPO 更容易复现，更适合已有高质量偏好对、GPU 资源受限、需要快速迭代的团队。

资源开销不能简单说“DPO 只有 PPO 的一半”

PPO 通常多出 rollout 生成、Reward 打分、Value 训练和多轮 PPO epoch；DPO 主要做两路序列概率计算与普通反向传播，链路更短。但实际显存还会受到 LoRA、量化、梯度检查点、ZeRO/FSDP、上下文长度以及是否预计算 Reference LogProb 的影响。

DPO 的一个实用省显存手段
TRL 支持预先计算 Reference 对训练集的 log probabilities。这样正式训练时不必一直把 Reference Model 留在显存中，但会增加一次预处理时间和磁盘存储。

工程实践：先把偏好数据做对，再谈训练器

偏好数据最小格式

preference_example = {
"prompt": "为什么微服务重试要设置指数退避？",
"chosen": "指数退避可以降低瞬时重试压力，并配合抖动、最大次数和超时上限，避免重试风暴。",
"rejected": "失败了就多重试几次，次数越多越容易成功。",
}

优质偏好对应该满足三个条件：回答针对同一个 prompt；chosen 与 rejected 的差异能对应明确偏好；两者长度、格式、语气不要成为无意的捷径，否则模型可能只学会“长答案更好”或“带列表更好”。

使用 TRL 训练一个最小 DPO 模型

from datasets import load_dataset
from trl import DPOConfig, DPOTrainer

train_dataset = load_dataset(
"trl-lib/ultrafeedback_binarized",
split="train",
)

training_args = DPOConfig(
output_dir="outputs/qwen3-dpo",
per_device_train_batch_size=2,
gradient_accumulation_steps=8,
learning_rate=1e-6,
num_train_epochs=1,
max_length=1024,
beta=0.1,
logging_steps=10,
bf16=True,
)

trainer = DPOTrainer(
model="Qwen/Qwen3-0.6B",
args=training_args,
train_dataset=train_dataset,
)

trainer.train()
trainer.save_model()

这段代码适合作为最小起点。真实项目还要补充验证集、聊天模板、长度分桶、数据去重、LoRA 配置、断点恢复、分布式训练和安全评测。TRL 文档也支持通过 PEFT 只训练适配器。

PPO 训练循环的核心伪代码

for prompts in prompt_loader:
responses = policy.generate(prompts) # 当前策略在线采样
task_scores = reward_model(prompts, responses)

ref_logprobs = reference.logprobs(prompts, responses)
old_logprobs = policy.logprobs(prompts, responses).detach()
values = value_model(prompts, responses)

rewards = task_scores - kl_coef * kl_penalty(
old_logprobs, ref_logprobs
)
advantages, returns = compute_gae(rewards, values)

for _ in range(num_ppo_epochs):
new_logprobs = policy.logprobs(prompts, responses)
ratio = (new_logprobs - old_logprobs).exp()
policy_loss = clipped_ppo_loss(ratio, advantages)
value_loss = regression_loss(values, returns)
optimize(policy_loss + value_coef * value_loss)

伪代码刻意隐藏了分布式采样、长度掩码、token 级 KL、奖励白化、GAE、micro-batch 和梯度同步等细节。真正难的并不是写出 loss，而是保证每个中间量的尺度、掩码和分布都正确。

训练时重点看哪些指标？

DPO：rewards/accuracies 是否稳定高于随机水平，rewards/margins 是否扩大，chosen 与 rejected 的 log probability 是否异常塌缩。

PPO：RLHF reward 是否上升，objective/kl 是否失控，policy ratio 是否围绕 1，clip fraction 是否长期过高，Value loss 是否发散。

两者都要看：独立验证集偏好胜率、事实正确率、安全拒答、领域任务、长度分布、重复率和基础能力回归。

不要只相信训练 loss
偏好 loss 下降只能说明模型更会拟合训练排序，不代表真实用户更喜欢，也不代表事实性、安全性和通用能力没有退化。

四个常见误区

DPO 论文证明的是：在特定偏好模型和带 KL 约束的奖励最大化设定下，可以用 Policy 与 Reference 的概率比重新参数化奖励并直接优化偏好数据。这比“DPO 就是把任何 PPO 都变成监督学习”要严格得多。

同样，PPO 也不是天然“效果一定更好”。奖励模型如果有系统性偏差，在线探索反而会更快找到它的漏洞，产生 reward hacking。DPO 虽然少了显式奖励模型，却仍然可能过拟合噪声偏好或让某些表达模式被过度放大。

项目里到底怎么选？

优先选择 DPO 的情况

已经有数量可观、规则明确、覆盖真实用户分布的偏好对。

团队以普通微调和 LoRA 为主，缺少成熟的在线 RL 基础设施。

需要快速做多轮数据迭代，强调稳定、可复现和低成本。

目标主要是风格、安全边界、客服语气、拒答规则等“校准型”能力。

考虑 PPO 或其他在线 RL 的情况

任务奖励可以自动验证，例如数学答案、代码测试、工具调用成功率。

需要模型主动探索偏好数据里没有覆盖的新解法。

有能力维护 rollout、奖励服务、分布式训练、KL 控制和在线评测。

愿意承担更高训练成本，并能持续检查奖励模型是否被利用。

成熟方案往往是组合，而不是二选一

实际的大模型训练流水线可以先用 SFT 建立能力，再用 DPO 快速完成偏好校准；对于可验证推理、工具使用或需要探索的任务，再引入 PPO、GRPO 或其他在线策略优化。最后必须通过独立评测、红队测试和灰度发布确认收益。

最后总结

PPO 的核心价值是在线探索。它让模型用当前策略不断生成新轨迹，通过奖励和优势函数学习，但也带来更复杂的采样、价值估计、KL 控制和稳定性问题。

DPO 的核心价值是把偏好对齐压缩成一条更短、更稳定的训练链路。它无需显式奖励模型和 Value Model，容易接入现有微调框架，但学习边界更受离线偏好数据覆盖与质量限制。

真正的选择标准
不是“哪个算法更先进”，而是：你的奖励能否可靠计算、偏好数据是否覆盖真实分布、是否需要在线探索、团队能否承担训练与评测复杂度。