vLLM 是目前最流行的 LLM 推理引擎之一。它的核心价值很简单：让模型推理更快、更便宜。PagedAttention 连续批处理这些技术，基本上是所有现代推理系统的标配了。
但 ServiceNow AI 团队在把 vLLM 从 V0 迁移到 V1 的过程中，碰到了一个很多人不会注意到的问题：在强化学习（RL）场景下，推理引擎的"正确性"比"优化修正"重要得多。
V1 引入了一些新的异步优化，目的是进一步提升吞吐量。思路没问题——连续批处理本来就是靠异步调度来提升 GPU 利用率的。但问题出在细节：当异步调度改变了请求的执行顺序或者引入了微妙的时序依赖时，RL 训练中的 reward 计算就会出错。
RL 训练对执行顺序极其敏感。奖励信号需要在精确的时间点与对应的模型输出绑定。如果推理引擎因为异步优化导致输出和奖励的对应关系错位，整个训练就会学到错误的信号。速度再快，方向错了也是白搭。
ServiceNow 团队的标题起得很准："Correctness Before Corrections"。先把正确性保证住，再谈优化。
这个问题表面上是 vLLM 的工程问题，实际上揭示了 AI 基础设施里一个更大的矛盾：推理优化和训练正确性之间的张力。
推理引擎的目标是吞吐量和延迟。它假设每个请求是独立的，顺序不重要，晚一点返回没关系。但训练引擎（尤其是 RL 训练）需要确定性和精确的因果链——第 N 步的输出必须和第 N 步的奖励绑定，不能因为异步调度跑到第 N+1 步去了。
当同一个基础设施同时服务推理和训练两种场景时，这种张力就会暴露出来。
vLLM 团队显然意识到了这个问题。V1 的迁移文档和社区讨论里，可以看到他们在重新设计调度逻辑，确保 RL 场景下的执行顺序确定性。这不是一个小改动——它意味着部分放弃 V1 的异步优化收益，来换取正确性。
但这恰恰是做对了。
基础设施的正确性是不可妥协的。你可以容忍推理速度慢 20%，但你不能容忍训练结果不可复现。一个慢 20% 但正确的引擎，价值远大于一个快 20% 但输出不可靠的引擎——因为在后者上跑出来的"结果"根本不可信。
对使用 vLLM 做 RL 训练的团队来说，这个教训很具体：
- 升级推理引擎版本时，不要只看吞吐量 benchmark。在 RL 场景下跑一轮完整的训练循环，检查 reward 信号的一致性。
- 如果推理引擎的文档没有明确说明 RL 场景下的行为保证，不要假设它是对的。主动测试。
- 在 RL 训练和纯推理服务之间，考虑使用不同的推理引擎配置。它们对正确性和吞吐量的要求不同。
vLLM V1 的这次迁移，本质上是一次"基础设施成熟度"的体现。早期的推理系统只需要"跑得快"，现在需要"在多种场景下都跑对"。这是从工具到平台的必经之路。
主要来源：
- Hugging Face Blog: vLLM V0 to V1: Correctness Before Corrections in RL
- ServiceNow-AI 团队博客