vLLM V1¶
公告
我们已经开始逐步淘汰V0版本。更多详情请参阅 RFC #18571。
V1现已默认在所有支持的用例中启用，我们将逐步为计划支持的每个用例启用它。如有任何反馈，请在GitHub或vLLM Slack中分享。
要禁用V1版本，请设置环境变量为：VLLM_USE_V1=0，并在GitHub上提交问题告诉我们原因！
为什么选择vLLM V1？¶
vLLM V0 成功支持了广泛的模型和硬件，但随着新功能独立开发，系统变得越来越复杂。这种复杂性使得集成新功能更加困难，并引入了技术债务，揭示了对更精简统一设计的需求。
在V0版本成功的基础上，vLLM V1保留了V0中稳定且经过验证的组件（如模型、GPU内核和实用工具）。同时，它大幅重构了核心系统，涵盖调度器、KV缓存管理器、工作器、采样器和API服务器，以提供一个更具凝聚力、可维护性的框架，更好地适应持续增长和创新。
具体来说，V1的目标是：
- 提供一个简单、模块化且易于修改的代码库。
- 确保高性能，CPU开销近乎为零。
- 将关键优化技术整合到一个统一的架构中。
- 通过默认启用功能/优化，实现零配置需求。
升级到V1核心引擎后，我们观察到显著的性能提升，尤其是在长上下文场景中。具体性能基准测试请参阅（待补充）。
更多详情，请查看vLLM V1博客文章vLLM V1: A Major Upgrade to vLLM’s Core Architecture（发布于2025年1月27日）。
这份实时用户指南概述了vLLM V1引入的一些已知重要变更与限制。团队正在积极推动V1成为默认引擎，因此随着vLLM V1支持更多功能，本指南将持续更新。
当前状态¶
对于每个项目，我们对V1支持的工作进展处于以下状态之一：
- 🚀 优化: 已接近完全优化，目前暂无进一步优化计划。
- 🟢 功能完整: 完全可用，持续优化中。
- 🚧 开发中: 正在积极开发。
- 🟡 计划中: 已安排在未来版本实现（部分可能已有开放PR/RFC）。
- 🟠 延迟: 在V1版本中暂时移除，但计划后续重新引入。
- 🔴 已弃用: 除非有强烈需求，否则V1版本不会计划支持。
注意
vLLM V1的统一调度器通过使用一个简单的字典（例如{request_id: num_tokens}）以相同方式处理提示词和输出token，动态为每个请求分配固定的token预算，从而实现了分块预填充、前缀缓存和推测式解码等功能，而无需严格区分预填充和解码阶段。
V1调度器支持多种调度策略，包括先到先服务(FCFS)和基于优先级的调度（请求按分配的优先级处理，FCFS作为平局决胜条件），可通过--scheduling-policy参数进行配置。
硬件¶
| 硬件 | 状态 |
|---|---|
| NVIDIA | |
| AMD | |
| TPU | |
| CPU |
模型¶
| 模型类型 | 状态 |
|---|---|
| 仅解码器模型 | |
| 编码器-解码器模型 | |
| 嵌入模型 | |
| Mamba 模型 | |
| 多模态模型 |
vLLM V1 目前不支持采用 SupportsV0Only 协议的模型架构。
提示
这对应我们支持模型列表中的V1列。
查看下方尚未支持或计划在V1版本中增加更多功能的模型状态。
嵌入模型¶
初始基础支持现已可用。
后续，我们将考虑使用隐藏状态处理器，它基于全局logits处理器，以实现在V1版本中使用同一引擎实例同时进行生成和嵌入。
Mamba模型¶
部分支持使用选择性状态空间机制而非标准Transformer注意力的模型。支持使用Mamba-2层的模型(例如Mamba2ForCausalLM)，但尚不支持使用旧版Mamba-1层的模型(例如MambaForCausalLM, JambaForCausalLM)。请注意，这些模型目前需要在vllm中禁用前缀缓存。
同时支持将Mamba-2层与标准注意力层结合的模型（例如BambaForCausalLM、Zamba2ForCausalLM、NemotronHForCausalLM、FalconH1ForCausalLM和GraniteMoeHybridForCausalLM）。请注意，这些模型目前需要禁用前缀缓存并在V1中使用FlashInfer注意力后端。
编码器-解码器模型¶
尚不支持需要在独立编码器和解码器之间进行交叉注意力计算的模型（例如BartForConditionalGeneration、MllamaForConditionalGeneration）。
功能特性¶
| 功能特性 | 状态 |
|---|---|
| 前缀缓存 | |
| 分块预填充 | |
| LoRA | |
| Logprobs 计算 | |
| FP8键值缓存 | |
| 推测解码 | |
| 提示词对数概率与前缀缓存 | |
| 结构化输出替代后端 | |
| 请求级结构化输出后端 | |
| best_of | |
| 每请求Logits处理器 | |
| GPU与CPU键值缓存交换 |
注意
vLLM V1的统一调度器通过使用一个简单的字典（例如{request_id: num_tokens}）以相同方式处理提示词和输出token，动态为每个请求分配固定的token预算，从而实现了分块预填充、前缀缓存和推测式解码等功能，无需严格区分预填充和解码阶段。
Logprobs的语义变更¶
vLLM V1 支持 logprobs 和 prompt logprobs。但与 V0 相比存在一些重要的语义差异：
Logprobs 计算¶
V1版本中的Logprobs现在一旦从模型的原始输出计算完成就会立即返回（即在应用任何logits后处理之前，如温度缩放或惩罚调整）。因此，返回的logprobs并不反映采样过程中使用的最终调整概率。
支持带有采样后调整的logprobs功能正在开发中，将在未来更新中添加。
带前缀缓存的提示词对数概率¶
目前仅当通过--no-enable-prefix-caching禁用前缀缓存时，才支持提示词对数概率。在未来的版本中，提示词对数概率将与前缀缓存兼容，但即使命中前缀缓存，也会触发重新计算以恢复完整的提示词对数概率。详见 RFC #13414。
已弃用功能¶
作为vLLM V1版本重大架构重构的一部分，多项遗留功能已被弃用。
采样特性¶
- best_of: 该功能由于使用率较低已被弃用。详情请参阅 RFC #13361。
- 按请求的Logits处理器: 在V0版本中，用户可以传递自定义处理函数来按请求调整logits。在vLLM V1中，此功能已被弃用。相反，设计正在转向支持全局logits处理器，团队正在积极开发该功能以供未来版本发布。详情请参阅 RFC #13360。
KV缓存特性¶
- GPU与CPU KV缓存交换: 借助全新简化的核心架构，vLLM V1不再需要通过KV缓存交换来处理请求抢占问题。
结构化输出功能¶
- 请求级结构化输出后端: 已弃用，现在支持带有回退机制的替代后端(outlines, guidance)。
