vLLM v0.19.0 來了，適配 HuggingFace v5，多模態優化，CPU KV 緩存卸載

3 月份我連寫了 和 ，假期發現 vllm v0.19.0 發了

我之所以一直追 vLLM 的每個版本，因為它確實是目前生產環境里用得最多的大模型推理引擎。

你在用 vLLM 部署模型，你必須知道新版本改了什么、哪些坑填了、哪些新坑挖了。

這次 v0.19.0 的更新量很大，我先把最重要的拎出來聊，然后再補充 vLLM 官方最近發的兩篇技術博客，這兩個都值得單獨展開說。

先看全貌：v0.19.0 改了什么

關鍵更新

類型

一句話

Gemma 4 首日支持

模型

Google 最強開源模型，發布當天就能在 vLLM 上跑

零氣泡異步調度 + 推測解碼

引擎

兩大優化終于不打架了

Model Runner V2 成熟

引擎

從實驗性到生產級，補齊了一大堆能力

ViT 全量 CUDA 圖

性能

多模態模型的視覺編碼器也有 CUDA 圖加速了

通用 CPU KV 緩存卸載

顯存

顯存不夠 CPU 來湊，支持自定義卸載策略

DBO 通用化

性能

微批次重疊優化，所有模型都能用了

NVIDIA B300/GB300

硬件

新一代硬件首日適配

Transformers v5 兼容

生態

大面積適配 HuggingFace v5

下面挨個拆

一、零氣泡異步調度 × 推測解碼：終于合體了

上次寫 Model Runner V2 的時候我就提過，vLLM V1 有個很蛋疼的問題——異步調度和推測解碼這兩個最重要的優化，分別能跑，放一起就打架。

為什么打架？因為推測解碼的拒絕采樣（rejection sampling）結果需要從 GPU 同步回 CPU，CPU 拿到結果后才能準備下一步的輸入。這個同步點一卡，異步調度"CPU 和 GPU 并行干活"的優勢就被吃掉了。

v0.19.0 的解法：把輸入準備也搬到 GPU 端。拒絕采樣的結果直接在 GPU 上被下一步消費，CPU 和 GPU 之間的同步點徹底消除——所謂"零氣泡"，就是兩邊的流水線中間沒有空轉等待。

實際意義是什么？你現在可以同時享受異步調度的高吞吐和推測解碼的低延遲。在此之前，這兩個優化你只能二選一，或者忍受明顯的性能折扣。

二、Model Runner V2：從實驗品到生產級

上次 v0.18.0 里 MRV2 還打著"實驗性"的標簽，我也說過"LoRA、線性注意力、Eagle 之外的推測方法暫不支持"

這次大量短板被補齊了：

新增能力

Pipeline Parallelism CUDA 圖

流水線并行場景支持分段 CUDA 圖捕獲，多卡部署不再掉速

推測解碼拒絕采樣器

Greedy 解碼和 Logprobs 輸出都支持了

多模態 + 推測解碼

以前多模態模型沒法用推測解碼加速，現在可以了

Streaming Inputs

輸入流式處理，降低首 token 延遲

EPLB

專家級并行負載均衡，跑 MoE 模型必備

FP32 draft logits + FP64 Gumbel 噪聲

精度提升，減少推測解碼時的數值漂移

對于純推理場景（不掛 LoRA），MRV2 已經可以認真考慮在生產環境上了。啟用方式還是一樣：

export VLLM_USE_V2_MODEL_RUNNER=1
# 然后正常跑 vLLM，不用改任何代碼

MRV2 的推進速度超出預期

上次還在說"暫不支持推測解碼的完整流程"，這次就基本補齊了。異步調度 + 推測解碼 + CUDA 圖，這三板斧全到位之后，MRV2 的性能上限會比 V1 高一截

三、ViT 全量 CUDA 圖捕獲

這個更新對跑多模態模型的同學來說很實在

之前 vLLM 處理圖片/視頻請求時，視覺編碼器（ViT）部分是"裸跑"的——每次都要重新 launch 一堆 CUDA kernel，小 batch 場景下這個開銷特別明顯

v0.19.0 讓 ViT 也支持了 CUDA 圖捕獲。簡單說就是把 ViT 的計算圖"錄像"下來，之后每次推理直接"回放"，省掉了反復 launch kernel 的開銷

如果你經常用 Gemma 4、Qwen-VL 這類多模態模型處理圖片問答，這個優化帶來的延遲降低是體感可知的

四、CPU KV 緩存卸載：顯存不夠 CPU 來湊

這是個很實用的功能

跑長序列時最頭疼的就是 KV 緩存吃顯存——一個 8K 上下文的請求，KV 緩存可能就要吃掉好幾個 GB。之前顯存滿了，vLLM 只能丟棄請求或者降級處理

v0.19.0 引入了通用 CPU KV 緩存卸載機制：

• 可插拔的緩存策略（CachePolicy）：自定義哪些 block 優先卸載到 CPU 內存

• Block 級別的搶占處理：細粒度控制，該卸哪塊卸哪塊

• 混合模型支持：SSM + Transformer 混合架構（比如 Mamba 系列）也能用

你可以理解為——KV 緩存有了"虛擬內存"，顯存放不下的部分自動溢出到 CPU 內存

五、DBO 通用化：所有模型都能享受微批次重疊

DBO（Dual-Batch Overlap）是 vLLM 之前引入的一個優化——把預填充和解碼放在不同的微批次里交替執行，讓 GPU 的計算和內存訪問更好地重疊起來。

問題是之前只有特定模型架構能用，限制不少。這次通用化了——不管你跑什么模型，DBO 都能給你帶來吞吐提升。

六、硬件支持更新

NVIDIA B300/GB300（SM 10.3）：

• AllReduce 融合默認開啟，調優過的 all-reduce 通信器

• Blackwell 架構的 CUTLASS FP8 GEMM 優化

• 修復了桌面級 Blackwell 上 NVFP4 的 NaN 問題

AMD ROCm：

• 升級到 ROCm 7.2.1 + PyTorch 2.10 + Triton 3.6

• DeepEP 作為 all2all 后端——EP 場景的 AMD 用戶終于有像樣的方案了

• AITER 的持久化 MLA kernel 和 FP8×FP8 注意力

• Nightly Docker 鏡像和 wheel 發布，CI 終于跟上了

Intel XPU：MLA 模型支持 + W4A8 量化

CPU：tcmalloc 默認啟用，池化模型吞吐提升 **48.9%**——純 CPU 部署的用戶別錯過

七、API 和其他值得關注的更新

新端點：/v1/chat/completions/batch——批量推理終于有專門的 API 了，不用再自己寫循環

thinking tokens 硬限制：推理模型（如 Qwen3-Coder）的思考長度現在可以設上限了，防止模型在簡單問題上瘋狂"內心戲"

-sc簡寫：--speculative-config太長了，現在用-sc就行

量化更新：

• 在線 MXFP8 量化，MoE 和 Dense 模型都支持

• QeRL：在線量化 + 量化重加載，專為 RLHF 訓練場景設計

Transformers v5 兼容：大面積適配了 HuggingFace Transformers v5，升級后不用再擔心各種奇怪的兼容性報錯

到這里，v0.19.0 的核心更新就聊完了。

接下來補充兩篇 vLLM 官方博客的內容——這兩篇在 v0.18 和 v0.19 之間發布，跟這次版本更新緊密相關。

【博客一】隱藏狀態提?。航o推測解碼的訓練管道打通了

這篇博客詳細介紹了一個從 v0.18.0 開始引入的新系統

標題聽著學術，但實際解決的問題非常落地

痛點在哪？

推測解碼大家應該不陌生了——上次三月四連發里我詳細聊過 P-EAGLE

核心思路就是用一個小的草稿模型快速猜 token，再用大模型并行驗證

關鍵在于，目前最好的推測解碼方法（Eagle-3、P-EAGLE、DFlash），草稿模型需要大模型的中間層隱藏狀態作為輸入。你要訓練這種草稿模型，就得先生成海量的隱藏狀態數據

以前要做這件事，兩條路都很痛苦：

路線一：用 transformers 跑。能跑，但慢得要死——vLLM 的所有性能優化（分布式推理、前綴緩存、自動批處理、分塊預填充）全丟了。而且 transformers 和 vLLM 的隱藏狀態可能有微妙差異，訓出來的草稿頭到 vLLM 上一跑就不對。

路線二：魔改 vLLM 內部。直接調內部 API，手動組裝各種組件。能跑，但維護成本爆炸——vLLM 一升級你的 patch 就廢了。之前 Speculators 庫 v0.5.0 之前就是這么干的。

vLLM 的解法：在現有管道上做文章

vLLM 團隊想到了一個很巧妙的方案。他們注意到三件事：

1. vLLM 跑 Eagle-3 推測解碼時，已經有從大模型向草稿模型傳遞隱藏狀態的管道

2. vLLM 有KV Connector API，本來用于 Prefill/Decode 分離場景的數據傳輸，支持寫磁盤、共享內存、Nixl 傳輸等多種方式

3. 隱藏狀態和 KV 緩存的內存管理方式本質上是一樣的——每個 token 對應一個值，可以復用分頁內存管理

把這三個現有能力一組合：創建一個"假的"草稿模型，它不做推理，只負責接收大模型傳過來的隱藏狀態，存到自己的 KV 緩存里，再通過 KV Connector 導出。

下圖是這套系統的整體設計——通過復用 Eagle-3 的隱藏狀態管道和 KV Connector API，實現了零侵入的隱藏狀態提?。?/p>

隱藏狀態提取系統設計

這套設計的好處很明顯：

• 零侵入：不改 vLLM 核心代碼，復用現有管道

• 全功能：前綴緩存、分塊預填充、自動批處理全能用

• 靈活：通過 KV Connector API 擴展導出方式（寫磁盤、GPU 直傳、跨節點傳輸）

啟動方式一條命令搞定：

vllm serve Qwen/Qwen3-8B --speculative_config '{
  "method": "extract_hidden_states",
  "num_speculative_tokens": 1,
  "draft_model_config": {
    "hf_config": {
      "eagle_aux_hidden_state_layer_ids": [3, 18, 33, 36]
    }
  }
}' --kv_transfer_config '{
  "kv_connector": "ExampleHiddenStatesConnector",
  "kv_role": "kv_producer",
  "kv_connector_extra_config": {
    "shared_storage_path": "/tmp/hidden_states"
  }
}'

eagle_aux_hidden_state_layer_ids指定要提取哪幾層的隱藏狀態，shared_storage_path指定輸出目錄。每個請求處理完后，你在指定目錄下能找到 safetensors 文件：

# /tmp/hidden_states/{req_id}.safetensors
{
    "token_ids": [prompt_seq_len],                          # prompt 的 token id
    "hidden_states": [prompt_seq_len, num_layers, hidden_size]  # 對應的多層隱藏狀態
}

幾個注意事項：

• 支持--tensor-parallel-size和--data-parallel-size多卡部署

• 只提取 prompt token 的隱藏狀態，建議調v1/completions接口并設max_tokens=1

• 目前只有寫磁盤的ExampleHiddenStatesConnector，后續會加 GPU 直傳等更高效的方式

這套系統已經和 vLLM 的 Speculators 庫整合（PR ），speculators v0.5.0 將支持草稿模型的在線訓練——邊推理邊生成訓練數據邊訓練，整個流程閉環了。

這個功能看起來是給研究者用的，但它解決的問題很根本。推測解碼是公認的最有效推理加速手段，但"怎么訓一個好的草稿模型"一直是個高門檻的事。以前你要么用 transformers 慢慢跑數據（還可能跑出來的數據跟 vLLM 不一致），要么大改 vLLM 源碼。現在一條命令搞定。推測解碼從"通用方案"走向"為你的模型定制專屬草稿頭"，這條路被打通了。

【博客二】Gemma 4 落地 vLLM：Day 0 四平臺支持

之前寫過 ，這次 vLLM 官方博客詳細介紹了 Gemma 4 在 vLLM 上的支持情況，有些細節值得補充。

Day 0 全平臺，這個含金量不低

vLLM 對 Gemma 4 做到了發布當天四個硬件平臺同時可用：

• NVIDIA GPU：A100、H100、B200 都能跑

• Google TPU：Trillium 和 Ironwood 都有適配

• AMD GPU：ROCm 平臺支持

• Intel XPU：也加入了首日陣營

TPU 支持是這次的亮點

之前開源推理引擎在 TPU 上的支持普遍很弱，vLLM 這次算是補上了這塊短板。對于用 Google Cloud 的團隊來說，終于不用在 TPU 和開源模型之間二選一了。

下圖是 Gemma 4 在 Arena.ai 聊天排名上的性能對比——同等模型尺寸下，參數效率遙遙領先：

Gemma 4 性能對比 Gemma 4 在 vLLM 上能做什么

Gemma 4 家族有四個尺寸：E2B、E4B、26B MoE、31B Dense。在 vLLM 上的核心能力：

• 多模態：圖片和視頻原生處理，邊緣模型（E2B/E4B）還支持語音輸入

• 工具調用：原生 function-calling + 結構化 JSON 輸出，vLLM 專門做了 Gemma 4 tool parser

• 長上下文：邊緣模型 128K，大模型 256K

• 推理能力：復雜多步推理，數學和邏輯任務有顯著突破

• 140+ 語言原生支持

• Apache 2.0 協議：商用零障礙

快速上手，官方推薦用預構建 Docker 鏡像省心省力：

# 最省事的方式
docker run --gpus all vllm/vllm-openai:gemma4

或者手動啟動（需要transformers>=5.5.0）：

pip install vllm==0.19.0
vllm serve google/gemma-4-31b-it \
  --tensor-parallel-size 2 \
  --trust-remote-code

更多部署細節可以參考官方 recipes：https://docs.vllm.ai/projects/recipes/en/latest/Google/Gemma4.html

Gemma 4 對 vLLM 的意義，不只是"又多支持一個模型"。Day 0 覆蓋四大硬件平臺，說明 vLLM 的多后端抽象層已經足夠成熟——加一個新模型不再需要每個硬件后端各搞一套適配了。Google 把 Gemma 4 全系列換成 Apache 2.0，再加上 vLLM 的生產級推理性能，對于想在自有基礎設施上跑開源模型的團隊來說，這個組合很有吸引力。

總結

把 v0.19.0 的版本更新和兩篇博客放在一起看，vLLM 最近這一波動作的主線很清晰：

從推理引擎到推理平臺。

• 底層引擎：MRV2 成熟 + 零氣泡異步調度，推理性能的天花板在抬高

• 加速方向：隱藏狀態提取打通訓練管道，推測解碼從"拿來就用"進化到"定制優化"

• 模型生態：Gemma 4 首日四平臺支持，新模型接入速度肉眼可見地在加快

• 硬件覆蓋：B300/GB300 首日適配、ROCm 持續完善、TPU/XPU 補強

對于我們用 vLLM 的人來說，最直接的建議：

1. 如果你在用推測解碼，v0.19.0 必升——零氣泡異步調度合體后，吞吐提升是白撿的

2. 如果你在跑多模態模型，ViT CUDA 圖 + MRV2 多模態推測解碼，延遲會有可感知的改善

3. 如果你被顯存困擾，試試 CPU KV 緩存卸載——長上下文場景下這是個救命功能

4. MRV2 該提上日程了，雖然 LoRA 還沒支持，但純推理場景已經生產就緒

制作不易，如果這篇文章覺得對你有用，可否點個關注。給我個三連擊：點贊、轉發和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！