从零开始：PPO 微调大模型实战（基于 PyTorch）

开篇：PPO 真正难的，不是算法本身

如果你已经看过一些 PPO 的原理文章，大概率会有过这种感觉：

 

好像每个字都认识，但真让我自己写代码，脑子还是一片空白。

 

这其实挺正常的。

至少我第一次准备动手写 PPO 的时候，也是这种状态。

 

问题不在你，而在 PPO 本身。

 

在论文里，PPO 看起来是一个干净利落的算法；

但一旦落到工程里，它立刻变成了一整条系统链路：

• 模型自己生成内容

• 用 reward model 打分

• 再算 KL 约束

• 再算 advantage

• 然后还要小心翼翼地更新多轮

 

任何一个地方写错，都不一定会立刻报错，但后果可能很严重：

• loss 看起来很正常，但模型能力在悄悄退化

• reward 一路往上走，输出却越来越奇怪

• 训练能跑、日志也漂亮，但结果完全不可复现

 

所以这篇文章我只想做一件事：

 

不用任何黑盒框架，从零用 PyTorch 跑通一版不容易翻车的 PPO 微调。

 

它不追求最优，也不炫技。

目标只有一个：工程上尽量安全。

 

 

PPO 微调整体数据流图

 

开始之前：你需要准备什么（以及别对第一版抱太大幻想）

在真正写 PPO 代码之前，我建议你先确认三件事。

 

第一，你的 base model 已经做过 SFT

PPO 并不是用来教模型“怎么回答问题”的，它更像是在微调模型的行为边界。

 

第二，你手里有一个能打分的 Reward Model

它不需要特别聪明，只要稳定、一致、别太极端，就已经够用了。

 

第三，也是最重要的一点

你得接受一个现实：

 

第一版 PPO 的目标不是效果炸裂，而是模型没被你训坏。

 

很多失败的 PPO 项目，问题并不出在算法上，而是工程师一开始就太着急，想“一步调到最优”。

 

PPO 微调的整体工程结构（先把全局图放在脑子里）

在写任何代码之前，先在脑子里有一张全局图，会让你少踩很多坑。

 

在大模型场景下，一次完整的 PPO iteration，通常包括这些步骤：

• 用当前 policy 生成 response

• 用 reward model 给 response 打分

• 计算当前 policy 和 reference policy 之间的 KL

• 把 reward 和 KL 合成一个总 reward

• 根据总 reward 估计 advantage

• 用 PPO loss 小步更新模型参数

 

如果一定要打个比方，我更愿意这样理解 PPO：

 

它就像给策略梯度拴了一根安全绳。

你可以往上爬，但不允许一步跨得太狠。

 

Policy / Reward / Reference / Value 关系图

 

第一步：准备模型与 tokenizer（为什么一定要保留 ref model）

 

from transformers import AutoModelForCausalLM, AutoTokenizer

 

model = AutoModelForCausalLM.from_pretrained("your_sft_model")

ref_model = AutoModelForCausalLM.from_pretrained("your_sft_model")

tokenizer = AutoTokenizer.from_pretrained("your_sft_model")

 

ref_model.eval()

for p in ref_model.parameters():

    p.requires_grad = False

 

这里有一个我必须强调的工程原则：

 

reference model 是 PPO 的“底线”。

 

没有 ref model，你会遇到很多非常隐蔽的问题：

• reward model 再强，也迟早会被模型钻空子

• 模型输出会慢慢偏离正常语言分布

• 原本 SFT 学到的能力，会在不知不觉中被破坏

 

说实话，我见过的不少 PPO 事故，追根溯源，几乎都能回到这一点：

ref model 被弱化了，甚至被“顺手一起训了”。

 

第二步：生成 response（PPO 不稳定的第一个源头）

和 supervised learning 不一样，PPO 的训练样本并不是现成的数据集，而是模型自己生成的。

 

def generate_response(model, prompt_ids, max_new_tokens=128):

    with torch.no_grad():

        output = model.generate(

            input_ids=prompt_ids,

            max_new_tokens=max_new_tokens,

            do_sample=True,

            top_p=0.9,

            temperature=1.0

        )

    return output

 

这里有几个非常现实、但经常被忽略的点：

• sampling 的随机性，本质上就是 PPO 的探索噪声

• temperature 太低，模型几乎学不到新东西

• temperature 太高，reward 的方差会直接炸掉

 

如果是第一次跑 PPO，我的建议很保守：

• temperature 设成 1.0

• top_p 用 0.9

• 先别碰 beam search

 

第三步：Reward + KL（最容易“看起来对，其实用错”的地方）

Reward Model 到底要多“准”？

很多人一上来就会纠结：

 

Reward Model 一定要非常准吧？

 

但在 PPO 里，一个更现实的结论是：

 

reward 的排序性，远比绝对值重要。

 

工程上我更关心的是：

• reward 分布别太尖

• 不要大量 0 / 1 极值

• reward 有没有无意中偏向长度或格式

 

KL 的作用，说白了就是“别把模型性格改没了”

KL penalty 在 PPO 中真的不是装饰品。

 

它更像是一根保险丝，用来防止模型在 reward 的驱动下“性格突变”。

 

def compute_kl(logits, ref_logits):

    log_probs = torch.log_softmax(logits, dim=-1)

    ref_log_probs = torch.log_softmax(ref_logits, dim=-1)

    kl = torch.sum(

        torch.exp(log_probs) * (log_probs - ref_log_probs),

        dim=-1

    )

    return kl.mean()

 

几个很实在的工程经验：

• KL 通常只算 response 部分

• KL 的数值尺度会随着词表大小变化

• KL 一定要进监控，不然你根本不知道模型在不在“飘”

 

KL 曲线随训练步数变化

 

第四步：为什么不能直接用 reward？（Advantage 的直觉解释）

在 PPO 里，reward 更像“结果”，而 advantage 更像“方向”。

 

最简单、但在工程上能用的 advantage 写法是：

 

advantage = total_reward - total_reward.mean()

 

它看起来确实有点粗糙，但解决了一个很关键的问题：

• 不让所有样本一起无脑推模型

• 强调“相对更好”的行为

 

这里有个重要认知：

 

第一版 PPO，真的不需要一个很完美的 value model。

 

第五步：PPO loss（别被 loss 曲线骗了）

 

ratio = torch.exp(new_logprob - old_logprob)

 

clipped_ratio = torch.clamp(ratio, 1-eps, 1+eps)

 

loss = -torch.mean(

    torch.min(ratio * advantage, clipped_ratio * advantage)

)

 

在工程里你一定要知道：

• loss 降得慢，不等于训练失败

• loss 很平，也不代表模型没在学

• PPO 的 loss 曲线，不能用 supervised learning 的思路去看

 

真正有价值的信号，其实是：

• KL 有没有失控

• reward 是不是稳步提升

 

第六步：完整 PPO 更新循环（贴近真实 GPU 训练）

 

for batch in prompts:

    response = generate_response(model, batch)

   

    reward = reward_model(response)

    kl = compute_kl(

        model_logits(response),

        ref_model_logits(response)

    )

   

    total_reward = reward - beta * kl

    advantage = total_reward - total_reward.mean()

   

    for _ in range(ppo_epochs):

        loss = ppo_loss(...)

        loss.backward()

        optimizer.step()

        optimizer.zero_grad()

 

一些很“工程”的建议：

• PPO epoch 别太多，4 已经很激进了

• gradient clipping 基本是必选项

• advantage 最好 batch 内单独算

 

如果你不想一开始就手写所有 PPO 细节，LLaMA-Factory online 已经把 PPO + KL + Reward 的完整流程封装好，用它先跑一条“参考答案”，再回头对照自己的 PyTorch 实现，会省很多时间。

 

训练中我最关心的几个监控信号

真正成熟的 PPO 训练，看的从来不只是一个 loss。

 

至少要包括这些：

• KL divergence

• reward 的均值和方差

• response 的平均长度

• logprob 的分布变化

• 固定 prompt 下的输出变化

• 人工抽样的主观质量

 

如果只能选一个重点盯：

 

盯 KL。

 

 

一些常见翻车现场（基本都是真实踩过的坑）

• reward 涨得很快，但模型开始胡说

  通常是 KL 太小，加上 reward 太单一

• 模型输出越来越短

  先看看 reward 有没有无意中惩罚长度

• 模型开始反复输出模板句

  很可能是 reward model 偏向了某种模式

• 模型几乎不动

  要么 KL 太大，要么学习率被你压得太死

 

进阶但仍然安全的改进方向

当你已经能稳定跑通 PPO 之后，可以再考虑这些事情：

• KL 的自适应调节

• response length normalization

• reward clipping

• 加 value head（但一定要非常谨慎）

 

顺序真的很重要：

 

永远先稳，再谈强。

 

写在最后：我现在怎么看 PPO

如果只总结三点经验，那会是这样：

 

第一，PPO 的核心不是把 reward 拉到多高，而是控制变化幅度

 

第二，KL 是 PPO 的灵魂，而不是可选项

 

第三，一版 PPO 是否成功，最现实的标准只有一个：

模型还像不像一个正常模型

 

在真实工程里，很多团队都会选择这样的路径：

先用 LLaMA-Factory online 跑通一版稳定的 PPO，对齐整体流程，再把关键模块逐步迁移到自研的 PyTorch 实现中。这条路不一定最优，但通常最稳。