背景

在基于强化学习的大模型训练中，推理引擎负责生成rollout并返回token对数概率（logprobs），而训练器则利用这些logprobs计算策略比率、KL散度、裁剪率和奖励。任何logprob计算方式的差异都会改变训练动态。这种“训练-推理不一致”是大规模RL系统迁移时常见的隐患。

ServiceNow的PipelineRL使用vLLM作为推理引擎。当他们从vLLM V0（0.8.5）升级到全面重写的V1版本（0.18.1）时，训练指标出现了显著偏离。这促使他们进行了一次系统性的调试，最终形成了一篇宝贵的实践报告。

核心内容分析

文章清晰记录了问题的发现与解决过程。最初，V1版本在裁剪率、KL、熵和奖励等训练器侧指标上明显偏离V0参考轨迹。团队将可能的失败原因分为三层：语义不匹配（后端返回的logprob含义与训练器预期不同）、推理路径不匹配（缓存、调度等运行时默认值差异）、以及实现细节差异（如权重更新路径）。

通过逐一排查，他们最终发现了四个关键修复点：

1. 处理过的rollout对数概率：V1可能对logprob进行了额外处理（如归一化），需要与V0对齐。
2. V1特定的运行时默认值：例如缓存策略或调度行为改变了token顺序，影响logprob计算。
3. 飞行中权重更新路径：在batch内更新权重时，V1的更新粒度或顺序与V0不同。
4. fp32 lm_head：最终投影层使用了单精度，而V0可能使用半精度或混合精度，导致数值差异。

修复后，V1的运行轨迹与V0几乎重合，验证了只有在后端行为完全匹配后，才能安全地评估目标函数本身的改进。

行业影响与专业点评

这篇文章虽然针对特定迁移场景，但揭示了一个普遍问题：在复杂RL管线上，推理引擎和训练器之间的无声不一致可能导致错误的科学结论。许多团队在尝试新目标函数时，如果未首先确保后端logprob的数值一致性，就可能将系统偏差误认为是算法改进。

ServiceNow团队采取的“先校正后创新”原则——先让V1在行为上匹配V0，再评估目标级变化——是一个值得推广的最佳实践。这也提醒开源社区：引擎的重大重构（如vLLM V1）必须提供明确的数值兼容性测试，甚至提供参考logprob数据集，以帮助下游用户平稳过渡。

对于其他使用vLLM进行RL训练的研究者，这篇文章提供了具体的排查路径。未来，随着在线RL在LLM训练中越来越主流，训练-推理一致性将成为基础设施设计的基本要求。

---

来源