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）。