vLLM V1¶
vLLM V0 成功支持了广泛的模型和硬件，但随着新功能的独立开发，系统变得越来越复杂。这种复杂性使得集成新功能更加困难，并引入了技术债务，凸显了对更精简、统一设计的需求。
在 V0 的成功基础上，vLLM V1 保留了 V0 中稳定且经过验证的组件（如模型、GPU 核和实用程序）。同时，它显著地重构了核心系统，包括调度器、KV Cache 管理器、Worker、Sampler 和 API Server，以提供一个凝聚、可维护的框架，更好地适应持续的增长和创新。
具体来说，V1 旨在
- 提供一个简单、模块化且易于修改的代码库。
- 确保高性能，CPU 开销接近零。
- 整合关键优化到一个统一的架构中。
- 通过默认启用功能/优化来实现零配置。
升级到 V1 核心引擎后，我们看到了显著的性能提升，尤其是在长上下文场景下。请参阅性能基准测试（待添加）。
有关更多详细信息，请查看 vLLM V1 博客文章 vLLM V1：vLLM 核心架构重大升级（发布于 2025 年 1 月 27 日）。
这份活的用户指南概述了 vLLM V1 引入的一些已知重要变更和限制。团队一直在积极努力将 V1 作为默认引擎，因此随着更多功能在 vLLM V1 上得到支持，本指南将不断更新。
与 V0 的区别¶
本节列出 V0 和 V1 之间的一些行为差异。
分块预填充（Chunked Prefill）¶
分块预填充在可能的情况下默认启用，这与 V0 不同，V0 中它基于模型特性进行条件启用。
CUDA 图（CUDA Graphs）¶
在 V1 中，CUDA 图捕获比 V0 占用更多内存。
Logprobs 的语义变更¶
Logprobs 计算¶
默认情况下，V1 中的 logprobs 现在一旦从模型的原始输出计算出来就会立即返回（即在应用任何 logits 后处理，如温度缩放或惩罚调整之前）。因此，返回的 logprobs 不反映采样过程中使用的最终调整后的概率。
您可以通过设置 --logprobs-mode 标志来调整此行为。支持四种模式：raw_logprobs（默认）、processed_logprobs、raw_logits、processed_logits。Raw 表示在应用任何 logit 处理器（如停用词）之前的值。Processed 表示在应用所有处理器（包括温度和 top_k/top_p）之后的值。
带前缀缓存的 Prompt Logprobs¶
虽然 V1 支持在启用前缀缓存的情况下传递 prompt logprobs，但它不再缓存 logprobs。对于需要 prompt logprobs 的请求，引擎将忽略前缀缓存并重新计算完整 prompt 的预填充以生成 logprobs。
功能支持¶
对于每一项，其在 vLLM V1 中的支持状态属于以下之一
- 🟢 功能齐全：完全运行，优化与 V0 相当或更好。
- 🟡 进行中：计划包含在 vLLM V1 中，有开放的 PR/RFC。
- 🔴 已移除：已从 vLLM V1 中删除。只有在有强烈需求时才会考虑重新引入。
注意
vLLM V1 的统一调度器通过使用一个简单的字典（例如 {request_id: num_tokens}）为每个请求动态分配固定的 token 预算，从而以相同的方式处理 prompt 和输出 token，支持分块预填充、前缀缓存和推测解码等功能，而无需严格区分预填充和解码阶段。
V1 调度器支持多种调度策略，包括先到先服务（FCFS）和基于优先级的调度（请求根据分配的优先级处理，FCFS 作为平局打破者），可通过 --scheduling-policy 参数进行配置。
硬件¶
| 硬件 | 状态 |
|---|---|
| NVIDIA | |
| AMD | |
| INTEL GPU | |
| TPU | |
| CPU |
模型¶
| 模型类型 | 状态 |
|---|---|
| 仅解码器模型 | |
| Encoder-Decoder 模型 | |
| 池化模型 | |
| Mamba 模型 | |
| 多模态模型 |
有关尚未完全支持或 V1 中计划添加更多功能的模型，请参阅下文。
池化模型¶
现已完全支持，并且为 last-pooling 模型新增了前缀缓存和分块预填充功能。
我们正在努力为更多类别的 pooling 模型启用前缀缓存和分块预填充。
Mamba 模型¶
支持使用选择性状态空间机制而非标准 Transformer 注意力的模型。支持使用 Mamba-2 和 Mamba-1 层的模型（例如 Mamba2ForCausalLM、MambaForCausalLM、FalconMambaForCausalLM）。
还支持将 Mamba-2 和 Mamba-1 层与标准注意力层结合使用的混合模型（例如 BambaForCausalLM、Zamba2ForCausalLM、NemotronHForCausalLM、FalconH1ForCausalLM 和 GraniteMoeHybridForCausalLM、JambaForCausalLM、Plamo2ForCausalLM）。
还支持具有不同于 Mamba 的机制的混合模型（例如 MiniMaxText01ForCausalLM、MiniMaxM1ForCausalLM、Lfm2ForCausalLM）。
请注意，上述任何模型目前均不支持前缀缓存。
Encoder-Decoder 模型¶
Whisper 已支持。其他需要独立编码器和解码器之间交叉注意力的模型（例如 BartForConditionalGeneration、MllamaForConditionalGeneration）不再受支持。
功能特性¶
| 功能 | 状态 |
|---|---|
| 前缀缓存 | |
| 分块预填充 | |
| LoRA | |
| Logprobs 计算 | |
| FP8 KV Cache | |
| 推测解码 | |
| 带前缀缓存的 Prompt Logprobs | |
| 结构化输出替代后端 | |
| 并发部分预填充 | |
| best_of | |
| 每请求 logits 处理器 | |
| GPU <> CPU KV Cache 交换 | |
| 请求级别结构化输出后端 |
注意
vLLM V1 的统一调度器通过使用一个简单的字典（例如 {request_id: num_tokens}）为每个请求动态分配固定的 token 预算，从而以相同的方式处理 prompt 和输出 token，支持分块预填充、前缀缓存和推测解码等功能，而无需严格区分预填充和解码阶段。
已移除的功能¶
作为 vLLM V1 主要架构重构的一部分，一些旧功能已被移除。
采样功能¶
- best_of：由于使用率不高，此功能已被移除。详情请参阅 RFC #13361。
- 每请求 logits 处理器：在 V0 中，用户可以传递自定义处理函数来调整每个请求的 logits。在 vLLM V1 中，此功能已被移除。取而代之的是，我们现在支持全局 logits 处理器，这些处理器在启动时设置，请参阅 RFC #17799。
KV Cache 功能¶
- GPU <> CPU KV Cache 交换：随着新的简化核心架构，vLLM V1 不再需要 KV Cache 交换来处理请求抢占。
结构化输出功能¶
- 请求级别结构化输出后端：已移除；现在支持带有回退机制的替代后端（outlines、guidance）。