背景

强化学习（RL）训练大型语言模型时，推理引擎扮演着关键角色：它负责生成rollout（采样轨迹）并返回token的logprobs，训练器再利用这些logprobs计算策略比率、KL散度、裁剪率、熵和奖励。任何logprobs计算上的微小差异都可能改变训练动态，导致模型收敛行为偏离预期。这种“训练-推理不匹配”（train-inference mismatch）正是ServiceNow AI团队在将推理引擎从vLLM V0迁移到V1时需要解决的核心问题。

vLLM V1是一次对V0引擎的重大重写，旨在提升性能和可扩展性。然而，直接替换引擎后，训练器端的指标（如clip rate、KL、熵、奖励）与V0参考运行出现了显著偏离。团队发现，问题并非源于RL目标函数的改变，而是vLLM V1后端在返回logprobs时存在语义、运行时默认值和路径上的差异。

核心内容分析

团队将迁移目标限定得非常明确：先确保V1返回的rollout logprobs符合训练器的期望，再在相同工作负载下与V0参考运行进行对比，只有在后端行为一致之后，才评估目标函数层面的变化。参考运行使用vLLM 0.8.5，V1运行使用vLLM 0.18.1。

初始V1运行很快暴露了问题：curret-policy logprobs和奖励曲线从训练早期就开始偏离V0参考轨迹。clip rate成为最易读的信号——它直接反映了rollout策略与训练器策略之间的差距，而熵和奖励则展示了这种差距如何传播到整个训练过程。

团队将可能的失败原因分为三个层次：

1. 语义不匹配（Semantic mismatch）：后端返回的logprobs对训练器而言含义不同；
2. 推理路径不匹配（Inference-path mismatch）：后端使用了不同的运行时默认值（如缓存、调度策略）；
3. 数值精度不匹配：例如最终投影层使用的浮点精度不同。

经过系统性排查，团队修复了四项关键问题：

• Processed rollout logprobs：确保V1返回的logprobs经过了与V0相同的后处理流程；
• V1-specific runtime defaults：调整了V1特有的运行时默认参数（例如缓存行为），使其与V0一致；
• Inflight weight-update path：修复了训练过程中权重更新路径在V1中的实现差异；
• fp32 lm_head：最终线性投影层在V0中使用fp32精度，而V1默认可能使用bfloat16，显式使用fp32 lm_head后数值匹配。

修复完成后，最终的V1运行（图中绿色曲线）在clip rate、KL、熵、奖励等指标上几乎与V0参考（蓝色曲线）完全重合，证明了后端行为的一致性。

行业影响/专业点评

这项工作虽然专注于vLLM V0到V1的迁移，但其揭示的问题具有普遍性：在基于策略梯度的RL算法（如PPO、GRPO、GSPO）中，rollout阶段的logprobs是训练信号的核心组成部分。任何推理引擎的改动——即使只是内部实现重写——都可能因微妙的数值或语义差异破坏训练稳定性。

ServiceNow团队采取的“先修复正确性，再优化目标”的方法论值得借鉴。在大型RL训练系统中，引擎替换的验证不能仅依赖最终指标（如奖励），而需要深入到logprobs、clip rate等内部信号，确保后端行为在数学上等价。

随着vLLM成为LLM推理的主流框架，其V1版本的广泛部署将影响大量RL训练工作流。本次迁移的经验也为其他推理引擎（如TensorRT-LLM、TGI）的升级提供了参考：在引入性能优化时，必须将数值一致性纳入CI/CD流程，避免训练动态的静默偏移。

---

来源