vLLM升级至V1实现RL训练后端一致性，四项修复恢复性能

背景

在大规模在线强化学习（RL）场景下，PipelineRL 依赖 vLLM 作为 rollout 推理引擎，实时生成 token 并返回 logprob。Trainer 进一步利用这些 logprob 计算策略比率、KL、clip rate、熵以及奖励。若后端返回的 logprob 与 Trainer 期望不一致，会导致训练动态偏移，出现 train‑inference mismatch。ServiceNow‑AI 围绕这一痛点，对 vLLM 进行从 V0（0.8.5）到 V1（0.18.1）的迁移实验。

关键问题

1. Logprob 语义不匹配：V1 默认在原始 logits 上直接输出 logprob，而 V0 在采样前已完成 temperature、penalty、top‑k/p 等后处理。导致 rollout logprob 均值出现明显偏移。
2. 运行时默认差异：V1 启用了前缀缓存、异步调度等新特性，这在在线 RL 环境中会产生缓存状态与权重更新不一致的问题。
3. 权重实时更新路径：V1 的 inflight weight‑update 机制在缓存未清空的情况下继续使用旧状态，导致 rollout 与最新策略产生滞后。
4. 最终投影精度：V0 使用 fp32 的 lm_head 进行 logits 投影，而 V1 默认使用 fp16，细微数值差异在 RL 中被放大。

四项修复措施

• 处理后的 logprob：在启动 V1 时显式设置 logprobs-mode=processed_logprobs，确保返回的概率与 V0 采样分布保持一致。
• 关闭 V1 特有默认：在配置文件中禁用前缀缓存和异步调度：

  vllm_config:
    use_v1: true
    vllm_kwargs:
      logprobs-mode: processed_logprobs
      enable-prefix-caching: false
      async-scheduling: false
  

• 同步权重更新：采用 V1 提供的 engine.pause_generation(mode="keep", clear_cache=False) 与 engine.resume_generation() 流程，保持缓存状态不被清除，模拟 V0 的更新方式。
• fp32 lm_head：强制在后端使用 fp32 进行最终投影，避免因数值精度导致的策略比率偏差。

实验结果

从图表可见，四项修复后，V1 在 clip rate、KL、熵、奖励 四条关键曲线均恢复到与 V0 几乎一致的水平，证明后端行为已实现完整 parity。

经验教训

1. 先修正后端一致性：在 RL 系统中，推理后端的细微实现差异会被训练目标放大。只有在保证后端返回的 logprob 与 Trainer 期待完全匹配后，才有意义去调优目标函数或加入 off‑policy 修正。
2. 显式声明运行时默认：默认配置的微小变化（如前缀缓存、异步调度）在在线学习场景下会产生不可预期的状态滞后，务必在迁移文档中明确列出并关闭。
3. 数值精度不可忽视：fp32 与 fp16 在 logits 级别的差异在 RL 中会导致策略比率偏移，尤其是大模型的长序列生成。

展望

vLLM 作为开源高性能 LLM 推理引擎，其 V1 版本在功能丰富、性能提升方面具有巨大潜力。ServiceNow‑AI 的这次迁移案例提供了一套 “后端先行、目标后修” 的实战路线，为后续在更大规模、更多模态的在线 RL 场景中使用 vLLM 打下了可靠基础。未来，随着更细粒度的权重热更新与多租户调度机制落地，业界有望进一步压缩训练‑推理时延，推动生成式 AI 在实时交互领域的落地。