ServiceNow-AI 在 5 月 6 日发布的技术文章里，讲了一个很工程化的问题：PipelineRL 把推理后端从 vLLM V0 迁到 V1 后，在线 RL 训练曲线跑偏了。

参考 run 用的是 vLLM 0.8.5，V1 run 用的是 vLLM 0.18.1。初始 V1 run 在 clip rate、KL、entropy、reward，以及 trainer-side logprobs 上，都偏离了 V0 参考轨迹。

这件事有意思的地方不在于“V1 有没有问题”。原文也没有把它说成 vLLM V1 的通用正确性错误。

真正值得看的是：在线 RL 的目标函数太依赖 rollout 阶段返回的 logprobs。后端语义、缓存边界、权重更新路径、final projection 精度，只要有一点没对齐，就可能被放大到 policy ratio、KL 和 clipping 上。

迁移目标不是先改 objective，而是复现 V0 行为

PipelineRL 用 vLLM 生成 rollout。推理引擎采样 token，并返回 logprobs；训练器再用这些值计算 policy ratio、KL、clip rate、entropy 和 reward。

在 PPO、GRPO、GSPO 这类在线 RL 流程里，rollout logprobs 不是日志字段。它是优化链路的一部分。

所以 ServiceNow-AI 一开始看到 V1 曲线偏离时，一个自然想法是：是不是要在 RL objective 侧加校正？

后面的排查说明，这一步不能急。

如果后端返回的 logprobs 语义还没对齐，执行路径也没对齐，先改 objective 等于把两个问题搅在一起：到底是 RL 算法需要校正，还是后端没有返回训练器假设的数据？

这也是我更在意的判断：迁移 vLLM V1 的第一目标，不是证明 V1 更强，而是让 V1 先复现 V0 的训练行为。

关键排查项大致是这几类：

排查项初始 V1 差异修正动作结果边界
logprobs 语义默认返回 raw model outputs 的 logprobs设置 logprobs-mode=processed_logprobs消除了 rollout logprobs 的均值偏移，但没有单独修完训练偏差
V1 运行默认值prefix caching、async scheduling 按 vLLM 0.18.1 默认路径运行显式关闭 prefix caching 和 async scheduling减少 V1-only 执行路径差异
在线权重更新与 V0 行为不完全贴合使用 pause_generation(mode="keep", clear_cache=False)让更新与缓存边界更接近 V0
final projection 精度rollout 与 trainer 的 lm_head 精度路径不同匹配 trainer 的 fp32 lm_head降低小 logits 差异被 ratio、KL、clipping 放大的风险

这里最容易被误读的是 processed_logprobs。

它很关键，但不是唯一修复项。原文提到，打开这个设置后，policy ratio 的均值接近 1.0，说明 logprob 均值偏移被处理了。可训练曲线仍然有差距，问题还在运行路径和数值路径里。

对工程团队来说，动作很具体：如果正在把 vLLM V1 接进 PPO、GRPO、GSPO 训练，不要一边换后端，一边改 objective。先跑 parity run。先确认 V1 能不能贴近 V0。

真正麻烦的是“能跑，但假设变了”

vLLM V1 相比 V0 是一次较大的引擎重写。很多默认行为对普通推理服务是合理的，比如 prefix caching。

prefix caching 通常是正确性保持的优化。它复用前缀计算，减少重复工作。问题不在“缓存本身错了”。

问题出在这个特定在线 RL 场景。

在线 RL 里，模型权重会不断更新。actor 还可能处理重复前缀、并发请求、异步调度和 inflight weight updates。此时缓存生命周期如果没有和权重更新边界对齐，就会引入 V1 相对 V0 的额外变量。

ServiceNow-AI 的处理方式，是关闭 prefix caching 和 async scheduling，并用 pause_generation(mode="keep", clear_cache=False) 贴近 V0 的在线权重更新行为。

这不是说所有团队都该永久关闭这些能力。更准确的说法是：在做迁移对齐实验时，要先去掉会改变执行路径的变量。等 parity 过了，再决定哪些优化能打开。

fp32 lm_head 也是同一个逻辑。

在普通推理里，小 logits 差异可能不显眼。但在 RL 训练里，它会进入 policy ratio、KL 和 clipping。误差不一定大，却可能站在杠杆上。

这类问题并不只出现在这一次迁移里。MiniMax-M1 技术报告提到过训练/推理 token probability mismatch，并把问题追到 LM output head；ScaleRL 后来也把 fp32 logits/head computation 写进大规模 RL 配方。

这说明一个现实约束：当训练器和推理器不再共享同一条执行路径，系统正确性就不再只是“模型能生成”。还要问：生成时记录的概率，和训练时假设的概率，是不是同一种东西？

受影响最大的是在线 RL 团队，下一步看三件事

普通 vLLM 推理用户不用把这篇文章读成迁移警报。

原文没有给出吞吐、成本或最终 reward 的具体数值，也没有证明 vLLM V1 在一般推理场景下存在正确性问题。目前能成立的结论，只限于 ServiceNow-AI 的 PipelineRL 在线 RL 迁移语境。

真正需要调整动作的是两类人。

一类是做 PPO、GRPO、GSPO 的训练团队。V1 上线前，应该延后“直接切流”的冲动，先做 V0/V1 parity run。检查项至少包括 rollout-side logprobs、trainer-side logprobs、policy ratio、KL、clip rate、entropy、reward 和缓存生命周期。

另一类是维护训练基础设施的人。不要只看 vLLM 服务能否启动、样本能否生成、reward 是否上升。还要把后端默认值、权重更新边界、old-policy logprobs 保存方式、trainer 重算路径放进同一张迁移表。

接下来最该观察的也不是“V1 reward 能不能更高”。这个问题现在还太早。

更该看三件事：

  • 这些修正后，V1 run 是否稳定贴近 vLLM 0.8.5 的参考轨迹；
  • 行为策略 logprobs 是显式保存，还是在优化时重算；
  • 异步生成带来的 staleness，是否用 ESS 等指标监控。

只有后端正确性先修好，truncated importance sampling、importance-ratio reweighting 这类 objective-side correction 才有讨论价值。

否则，校正可能只是在补一个本不该存在的后端偏差。

回到开头那条偏离的训练曲线，它提醒的不是“V1 不能用”，而是“上线前要知道自己在比较什么”。如果 V0 和 V1 的 logprobs、缓存边界、权重更新和 lm_head 精度都没对齐，曲线再漂亮，也很难判断它奖励的是模型进步，还是系统误差。