vLLM V1¶
公告
我們已開始棄用 V0 版本。請參閱 RFC #18571 獲取更多詳情。
V1 現已在所有受支援的用例中預設啟用，我們將逐步為計劃支援的每個用例啟用它。請在 GitHub 或 vLLM Slack 中分享您的任何反饋。
要停用 V1，請將環境變數設定為：VLLM_USE_V1=0，並透過 GitHub issue 告訴我們原因！
為何選擇 vLLM V1？¶
vLLM V0 成功支援了廣泛的模型和硬體，但隨著新功能獨立開發，系統變得日益複雜。這種複雜性使得整合新功能變得更加困難，並引入了技術債，揭示了對更精簡和統一設計的需求。
在 V0 成功的基礎上，vLLM V1 保留了 V0 中穩定且經過驗證的元件（例如模型、GPU 核心和實用程式）。同時，它顯著地重新架構了核心系統，包括排程器、KV 快取管理器、工作器、取樣器和 API 伺服器，以提供一個更具內聚性、可維護的框架，更好地適應持續的增長和創新。
具體而言，V1 旨在
- 提供一個**簡單、模組化且易於修改的程式碼庫**。
- 確保**高效能**，同時 CPU 開銷接近於零。
- 將**關鍵最佳化**整合到統一架構中。
- 透過預設啟用功能/最佳化，實現**零配置**。
我們看到升級到 V1 核心引擎帶來了顯著的效能提升，尤其是在長上下文場景中。請參閱效能基準（待新增）。
欲瞭解更多詳情，請查閱 vLLM V1 部落格文章 《vLLM V1：vLLM 核心架構的重大升級》（釋出於 2025 年 1 月 27 日）。
本使用者指南概述了 vLLM V1 引入的一些已知**重要變更和限制**。團隊一直在積極努力將 V1 作為預設引擎，因此本指南將隨著 vLLM V1 支援更多功能而不斷更新。
當前狀態¶
對於每個專案，我們對 V1 支援的進展狀態分為以下幾類：
- 🚀 **已最佳化**：接近完全最佳化，目前沒有進一步的工作計劃。
- 🟢 **功能完備**：完全可操作，並持續進行最佳化。
- 🚧 **WIP (開發中)**：正在積極開發中。
- 🟡 **已計劃**：計劃未來實施（部分可能有已開放的 PR/RFC）。
- 🟠 **已延遲**：在 V1 中暫時移除，但計劃稍後重新引入。
- 🔴 **已棄用**：未計劃在 V1 中支援，除非有強烈需求。
注意
vLLM V1 的統一排程器透過使用一個簡單的字典（例如 `{request_id: num_tokens}`）來動態分配每個請求的固定令牌預算，從而以相同的方式處理提示和輸出令牌，實現了分塊預填充、字首快取和推測解碼等功能，而無需嚴格區分預填充和解碼階段。
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）的模型尚未支援。請注意，這些模型目前在 V1 中需要停用字首快取。
結合了 Mamba-2 層和標準注意力層的模型也受支援（例如 BambaForCausalLM、Zamba2ForCausalLM、NemotronHForCausalLM、FalconH1ForCausalLM 和 GraniteMoeHybridForCausalLM）。請注意，這些模型目前在 V1 中需要停用字首快取並使用 FlashInfer 注意力後端。
編碼器-解碼器模型¶
需要獨立編碼器和解碼器之間交叉注意力的模型（例如 BartForConditionalGeneration、MllamaForConditionalGeneration）尚未支援。
功能¶
| 功能 | 狀態 |
|---|---|
| 字首快取 | |
| 分塊預填充 | |
| LoRA | |
| Logprobs 計算 | |
| FP8 KV 快取 | |
| 推測解碼 | |
| 帶字首快取的提示 Logprobs | |
| 結構化輸出備選後端 | |
| 請求級結構化輸出後端 | |
| best_of | |
| 按請求 Logits 處理器 | |
| GPU <> CPU KV 快取交換 |
注意
vLLM V1 的統一排程器透過使用一個簡單的字典（例如 `{request_id: num_tokens}`）來動態分配每個請求的固定令牌預算，從而以相同的方式處理提示和輸出令牌，實現了分塊預填充、字首快取和推測解碼等功能，而無需嚴格區分預填充和解碼階段。
Logprobs 的語義變更¶
vLLM V1 支援 logprobs 和提示 logprobs。然而，與 V0 相比，存在一些重要的語義差異：
Logprobs 計算
V1 中的 Logprobs 現在從模型原始輸出計算後立即返回（即在應用任何 logits 後處理，如溫度縮放或懲罰調整之前）。因此，返回的 logprobs 不反映取樣過程中使用的最終調整機率。
支援帶取樣後調整的 logprobs 正在開發中，並將在未來更新中新增。
帶字首快取的提示 Logprobs
目前，提示 logprobs 僅在透過 --no-enable-prefix-caching 關閉字首快取時才受支援。在未來的版本中，提示 logprobs 將與字首快取相容，但即使命中字首快取，也會觸發重新計算以恢復完整的提示 logprobs。詳情請參閱 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）。