vLLM V1

公告

我们已完全弃用 V0 版本。请阅读 RFC #18571 获取更多详细信息。

如果您有在 V0 引擎上运行良好但在 V1 上无法运行的用例，请在 GitHub 或 vLLM Slack 上进行反馈。

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 支持更多功能，本指南将不断更新。

与 V0 的区别

本节列出 V0 和 V1 之间的一些行为差异。

分块预填充 (Chunked Prefill)

分块预填充（Chunked prefill）默认启用（只要条件允许），而在 V0 中，它是根据模型特性有条件地启用的。

CUDA Graphs

与 V0 相比，V1 中的 CUDA 图捕获会占用更多内存。

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}）将 prompt 和输出 token 同等对待，从而为每个请求动态分配固定的 token 配额。这使得在没有严格区分预填充和解码阶段的情况下，实现分块预填充、前缀缓存和推测解码等功能成为可能。

V1 调度器支持多种调度策略，包括先到先得（FCFS）和基于优先级的调度（根据分配的优先级处理请求，FCFS 作为平局决胜机制），可通过 --scheduling-policy 参数进行配置。

硬件

硬件	状态
NVIDIA	🟢
AMD	🟢
INTEL GPU	🟢
TPU	🟢
CPU	🟢

注意

更多硬件平台可通过插件支持，例如：

• vllm-ascend
• vllm-spyre
• vllm-gaudi
• vllm-openvino

请查看各自的仓库以了解详情。

模型

模型类型	状态
仅解码器（Decoder-only）模型	🟢
Encoder-Decoder 模型	🟢 (Whisper), 🔴 (其他)
池化模型	🟢
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。其他 Encoder-Decoder 模型通过插件系统支持：

• BART: BartForConditionalGeneration 通过官方 bart-plugin 支持。
• Florence-2: Florence2ForConditionalGeneration 通过官方 bart-plugin 支持。

对于其他 Encoder-Decoder 模型（例如 MllamaForConditionalGeneration），我们建议遵循类似的模式，通过 插件系统 实现支持。

功能特性

功能	状态
前缀缓存	🟢 可用
分块预填充	🟢 可用
LoRA	🟢 可用
Logprobs 计算	🟢 可用
FP8 KV 缓存	🟢 可用
推测解码	🟢 可用
启用前缀缓存时的 Prompt Logprobs	🟢 可用
结构化输出替代后端	🟢 可用
并发部分预填充（Concurrent Partial Prefills）	🟡 进行中
best_of	🔴 已移除
Per-Request Logits Processors	🔴 已移除
GPU <> CPU KV Cache Swapping	🔴 已移除
Request-level Structured Output Backend	🔴 已移除

注意

vLLM V1 的统一调度器通过简单的字典（例如 {request_id: num_tokens}）将 prompt 和输出 token 同等对待，从而为每个请求动态分配固定的 token 配额。这使得在没有严格区分预填充和解码阶段的情况下，实现分块预填充、前缀缓存和推测解码等功能成为可能。

已移除的功能

作为 vLLM V1 重大架构重构的一部分，一些旧功能已被移除。

采样功能

• best_of: 该功能因使用率较低已被移除。详情请参阅 RFC #13361。
• Per-Request Logits Processors: 在 V0 中，用户可以传入自定义的处理函数来按需调整每个请求的 logits。在 vLLM V1 中，该功能已被移除。取而代之的是，我们现在支持在启动时设置的全局 Logits 处理器，请参阅 RFC #17799。

KV Cache 功能

• GPU <> CPU KV Cache Swapping: 借助新的简化核心架构，vLLM V1 不再需要通过 KV 缓存交换来处理请求抢占。

结构化输出功能

• Request-level Structured Output Backend: 已移除；现在支持带有回退机制的替代后端（如 outlines, guidance）。