义父，想问下为啥train_ppo代码中有五个模型？

[ciaoyizhen]

我看标准的PPO训练中
只有actor_model, actor_ref_model, reward_model, critic_model
然后我看代码有 actor_model, actor_old_model, actor_ref_model, reward_model, critic_model
多了一个actor_old_model

此外还有一个东西
kl_ref是啥 为啥我在公式里都没看到 只有kl呀？

一个题外话
我看代码的ratio 是先计算了sum 然后再除的？
是不是应该先除再求和？
这里是不是因为对数的原因，结果是一样的？

actor_logp = (logp_tokens * final_mask).sum(dim=1)
ratio = torch.exp(actor_logp - old_logp)

太菜了。。。 求义父救救

[jingyaogong]

标准PPO也需要旧策略算 ratio。actor_old_model 就是每隔几步把当前 actor_model 的权重拷过去，专门用来提供 old_logp。

kl_ref 当前策略和参考模型 ref_model 的 KL，别离最初的参考策略太远”的额外约束。

只是用 log 域计算更稳不会爆数，所以看起来是先 sum 再除，数学等价。

[ciaoyizhen]

太菜了 我以为ratio是用actor/ref的呢 然后KL(actor,ref)的 原来是 ratio actor/old_actor KL(actor, ref)这样的

[ciaoyizhen]

义父你太好了！！！

[ciaoyizhen]

不对啊 义父 我看trl的PPOTrainer内部 这个old就是用ref解决的呀 然后我看论文公式 也是用同一个 不需要单独拉一个呀 @jingyaogong

[jingyaogong]

"old就是用ref解决的"

no！
具体看

Line 725-726、759-761、以及
https://github.com/huggingface/trl/blob/c04fdc044dde5e73200f086fbe8737a842754793/trl/experimental/ppo/ppo_trainer.py#L802
https://github.com/huggingface/trl/blob/c04fdc044dde5e73200f086fbe8737a842754793/trl/experimental/ppo/ppo_trainer.py#L809
https://github.com/huggingface/trl/blob/c04fdc044dde5e73200f086fbe8737a842754793/trl/experimental/ppo/ppo_trainer.py#L827
https://github.com/huggingface/trl/blob/c04fdc044dde5e73200f086fbe8737a842754793/trl/experimental/ppo/ppo_trainer.py#L828

mb_logprobs = logprobs[micro_batch_inds]
new_logprobs = selective_log_softmax(logits, mb_responses)
logprobs_diff = new_logprobs - mb_logprobs
ratio = torch.exp(logprobs_diff)

这可不是ref算出来的ratio

---

两种方式本质上完全一样，只不过

• trl缓存 logprobs，用缓存值计算 ratio → 省显存占内存
• 这里维护 actor_old_model 快照，重算 old_logp → 占显存省内存

单纯实现的权衡不同，本质都是同一个等价的旧策略，但绝不是ref。此外只是对于一个26M的模型，所谓显存的占用可以忽略，代价就是重算一次forward

贴近trl的实现，4个模型反而代码会臃肿、可读性和可理解性会降低...例如：

responses = []
logprobs = []
ref_logprobs = []
values = []
# 管理多个列表...
# 处理 padding...
padding_mask = response_idxs > sequence_lengths.unsqueeze(1)
logprobs = torch.masked_fill(logprobs, padding_mask, INVALID_LOGPROB)
# mini-batch 索引...
mb_logprobs = logprobs[micro_batch_inds]
# 需要确保索引对应关系正确...
# 清理...
del logprob, ref_logprob, ...
empty_cache()

[ciaoyizhen]

太感谢了，果然是我的水平不足，确实两边都用了old

但是这就引发了我一个新的问题 果然还是太菜了。。。

在trl中 KL 是通过
logr = ref_logprobs - logprobs 得到的 即ref - old (看过来是这样的)

在minimind中

kl = (actor_logp - old_logp).mean()  # scalar
kl_ref = (actor_logp - ref_logp).mean()  # scalar

得到的，我们用的是kl_ref而不是kl 即 new - ref

然后我去问了下cluade和gpt 他们给的回复都是

kl = (actor_logp - old_logp).mean()
if kl > target_kl:  # 例如 target_kl = 0.01
    break  # 提前停止这个epoch

是说这个kl是用来早停的？

那这个我就不是很理解了 那不就是说trl中的实现有问题？？？
@jingyaogong可以再占用一点点时间 解答一下吗？

[jingyaogong]

都对，KL 用的地方不同：

trl：kl = -(ref - current)，加到 reward 里（rewards = -kl_coef * kl + scores）是经典 PPO-penalty 做法（reward最大化意味着current - ref最小化）

minimind：kl_ref = current - ref，加到 loss 里（loss = policy_loss + kl_coef * kl_ref）更直接的正则化（一样追求current - ref最小化）

至于 kl = (actor_logp - old_logp).mean() 不难看出单纯用来打日志（train_ppo.py#206,214），看每步策略变化多大，不参与训练，也没所谓早停，所谓"用于早停"是另一种实现方式（adaptive KL），但 minimind 和 trl 没用过。

最原始标准 (PPO-Clip) 压根没有 KL，纯靠 Clip 卡更新
KL 塞进 Reward是比较标准的做法，代价是 Reward 混合地更复杂，因为 Critic 要额外拟合预测一个复杂的 KL，很不稳定
KL 挪到Loss算变体，也是后面 GRPO 的做法，只要把 KL 拿出 Reward，Critic 就不是必需的了，解耦=简单稳定

[ciaoyizhen]

我靠 醍醐灌顶！！！
我终于懂了 太强了！！！！