版本差异概览：vLLM主要版本的功能演进与性能改进

vLLM自2023年推出以来，版本迭代速度极快，几乎每个大版本都伴随着核心机制的革新与性能的跃升。理解版本差异，不能只看Release Note中的条目罗列，而应抓住三条主线：调度与内存管理策略、执行后端与算子优化、服务化与多模态扩展能力。下面以v0.4.x、v0.5.x、v0.6.x、v0.7.x及v0.8.x为关键里程碑，梳理其演进脉络。

核心原理：从PagedAttention到自动化动态调度

vLLM早期版本的核心卖点是PagedAttention，它通过将KV Cache划分为固定大小的物理块，以非连续方式存储，解决了显存碎片化问题。这一机制在v0.4.x中已趋于成熟，但调度器仍以静态批处理为主——请求到达后等待攒批，批大小固定，无法在推理过程中动态增减请求。

v0.5.x引入了连续批处理（Continuous Batching）的完善实现，允许请求在迭代级完成插入与退出。这意味着当某个序列生成结束符时，其占用的GPU资源可立即释放给新请求，无需等待整个批次结束。这一改动直接提升了吞吐，但也对调度器提出了更高要求——需要实时跟踪每个序列的token生成状态。

v0.6.x进一步将调度粒度细化，支持preemption模式的可配置化（swap或recompute），并引入了基于chunked prefill的机制，将长提示的预填充阶段切分为多个块，与decode阶段的token交错执行，避免prefill阶段长时间独占GPU导致decode延迟飙升。这一版本还统一了VllmRunner与LLMEngine的接口，为后续的异步化奠定基础。

v0.7.x开始将注意力转向多模态与异构硬件适配，同时优化了speculative decoding的默认策略。v0.8.x则在调度器中引入了基于负载感知的动态批处理，能够根据当前队列长度、显存余量以及各请求的预估长度，自动调整最大批大小与KV Cache预留比例，减少了人工调参成本。

方法流程：各版本关键差异对比

下表从调度、显存、执行、服务化四个维度，对比了主要版本的核心差异。实际项目升级时，应依据自身负载特征（长提示占比、并发模式、是否多模态）选择目标版本。

从v0.5.x升级到v0.6.x时，最值得关注的是--enable-chunked-prefill参数。该参数默认关闭，开启后会将prefill阶段的计算分解为多个chunk，每个chunk的token数量由--max-num-batched-tokens控制。例如，一个包含2048个token的提示，在未开启时可能独占整个batch，导致其他decode请求等待；开启后，该提示被拆分为4个512-token的chunk，与其他decode请求交错执行，GPU利用率显著提升。

# v0.6.x 推荐启动参数示例
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3-8B-Instruct \
    --enable-chunked-prefill \
    --max-num-batched-tokens 4096 \
    --max-num-seqs 64 \
    --gpu-memory-utilization 0.92

v0.7.x之后，--enable-prefix-caching成为默认开启项。该功能对共享前缀的请求（如多轮对话、系统提示词相同的批量请求）效果显著，它通过哈希匹配将相同的KV块在显存中共享，避免重复计算。实测在RAG场景下，当多个请求携带相同的检索文档前缀时，首token延迟可降低40%以上。

案例/场景：一次从v0.4.2到v0.6.1的升级实测

某内部知识库问答服务，模型为Qwen-14B-Chat，单卡A100-80G，日均请求量约20万，平均提示长度约1200 token，输出长度约200 token。原部署版本为v0.4.2，吞吐约850 tokens/s，P99延迟约2.8s。

升级至v0.6.1后，仅开启--enable-chunked-prefill与--enable-prefix-caching，未改动模型与硬件，实测结果如下：

• 吞吐提升至1420 tokens/s，增幅约67%。主要贡献来自chunked prefill消除了prefill阶段的GPU空闲窗口。
• P99延迟降至1.9s，因为decode请求不再被长prefill阻塞，调度器可以更均匀地分配计算资源。
• 显存峰值下降约12%，得益于prefix caching对重复系统提示词的KV复用。

值得注意的是，升级过程中需要同步调整--max-num-seqs。v0.4.x中该值通常设为32，但v0.6.x的连续批处理允许更高的并发度，我们将其提升至64后，吞吐进一步增加，但显存占用也随之上升。最终通过--gpu-memory-utilization 0.90限制显存上限，避免OOM。

误区/复盘：版本升级中的常见认知偏差

误区一：认为新版本一定更快。实际上，v0.7.x在某些场景下（如小batch、短序列）吞吐可能低于v0.6.x，因为新版本引入了更复杂的调度逻辑，增加了CPU开销。若负载以短请求为主，建议关闭--enable-chunked-prefill，或回退至v0.6.x。

误区二：忽略--max-num-batched-tokens的联动调整。该参数不仅影响chunked prefill的切分粒度，还限制了单次迭代处理的token总数。若设置过小（如512），会导致batch频繁切换，降低GPU利用率；若设置过大（如8192），则可能因显存不足触发preemption。建议根据模型大小与显存容量，通过vllm benchmark脚本进行网格搜索。

误区三：混淆“吞吐提升”与“延迟降低”。v0.8.x的动态批处理优化的是系统吞吐，即单位时间处理的请求数。对于单条请求的延迟，尤其是首token延迟，可能因批处理排队而略有上升。若业务对延迟敏感，应设置--max-num-seqs较低值，或使用--priority参数为高优请求预留通道。

复盘一次失败升级：某团队将v0.5.3直接升级至v0.7.2，未修改任何参数，结果吞吐反而下降15%。排查发现，v0.7.2默认启用了--enforce-eager（即关闭CUDA Graph），而v0.5.3中CUDA Graph是默认开启的。CUDA Graph在v0.7.x中改为可选，需显式添加--use-cuda-graph参数。这一案例说明，版本升级必须逐项核对默认参数变更，不能依赖“升级即提升”的直觉。

最后，建议在升级后使用vllm.engine.arg_utils中的EngineArgs打印完整配置，与旧版本配置做diff，确保所有关键参数符合预期。吞吐测试应使用与生产一致的提示长度分布与并发模型，避免使用固定长度合成数据导致结论失真。