3 月份我連寫了 和 ，假期發(fā)現(xiàn) vllm v0.19.0 發(fā)了

我之所以一直追 vLLM 的每個(gè)版本，因?yàn)樗_實(shí)是目前生產(chǎn)環(huán)境里用得最多的大模型推理引擎。

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

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

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

關(guān)鍵更新

類型

一句話

Gemma 4 首日支持

模型

Google 最強(qiáng)開源模型，發(fā)布當(dāng)天就能在 vLLM 上跑

零氣泡異步調(diào)度 + 推測(cè)解碼

引擎

兩大優(yōu)化終于不打架了

Model Runner V2 成熟

引擎

從實(shí)驗(yàn)性到生產(chǎn)級(jí)，補(bǔ)齊了一大堆能力

ViT 全量 CUDA 圖

性能

多模態(tài)模型的視覺編碼器也有 CUDA 圖加速了

通用 CPU KV 緩存卸載

顯存

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

DBO 通用化

性能

微批次重疊優(yōu)化，所有模型都能用了

NVIDIA B300/GB300

硬件

新一代硬件首日適配

Transformers v5 兼容

生態(tài)

大面積適配 HuggingFace v5

下面挨個(gè)拆

一、零氣泡異步調(diào)度 × 推測(cè)解碼：終于合體了

上次寫 Model Runner V2 的時(shí)候我就提過，vLLM V1 有個(gè)很蛋疼的問題——異步調(diào)度和推測(cè)解碼這兩個(gè)最重要的優(yōu)化，分別能跑，放一起就打架。

為什么打架？因?yàn)橥茰y(cè)解碼的拒絕采樣（rejection sampling）結(jié)果需要從 GPU 同步回 CPU，CPU 拿到結(jié)果后才能準(zhǔn)備下一步的輸入。這個(gè)同步點(diǎn)一卡，異步調(diào)度"CPU 和 GPU 并行干活"的優(yōu)勢(shì)就被吃掉了。

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

實(shí)際意義是什么？你現(xiàn)在可以同時(shí)享受異步調(diào)度的高吞吐和推測(cè)解碼的低延遲。在此之前，這兩個(gè)優(yōu)化你只能二選一，或者忍受明顯的性能折扣。

二、Model Runner V2：從實(shí)驗(yàn)品到生產(chǎn)級(jí)

上次 v0.18.0 里 MRV2 還打著"實(shí)驗(yàn)性"的標(biāo)簽，我也說過"LoRA、線性注意力、Eagle 之外的推測(cè)方法暫不支持"

這次大量短板被補(bǔ)齊了：

新增能力

Pipeline Parallelism CUDA 圖

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

推測(cè)解碼拒絕采樣器

Greedy 解碼和 Logprobs 輸出都支持了

多模態(tài) + 推測(cè)解碼

以前多模態(tài)模型沒法用推測(cè)解碼加速，現(xiàn)在可以了

Streaming Inputs

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

EPLB

專家級(jí)并行負(fù)載均衡，跑 MoE 模型必備

FP32 draft logits + FP64 Gumbel 噪聲

精度提升，減少推測(cè)解碼時(shí)的數(shù)值漂移

對(duì)于純推理場(chǎng)景（不掛 LoRA），MRV2 已經(jīng)可以認(rèn)真考慮在生產(chǎn)環(huán)境上了。啟用方式還是一樣：

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

MRV2 的推進(jìn)速度超出預(yù)期

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

三、ViT 全量 CUDA 圖捕獲

這個(gè)更新對(duì)跑多模態(tài)模型的同學(xué)來說很實(shí)在

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

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

如果你經(jīng)常用 Gemma 4、Qwen-VL 這類多模態(tài)模型處理圖片問答，這個(gè)優(yōu)化帶來的延遲降低是體感可知的

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

這是個(gè)很實(shí)用的功能

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

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

• 可插拔的緩存策略（CachePolicy）：自定義哪些 block 優(yōu)先卸載到 CPU 內(nèi)存

• Block 級(jí)別的搶占處理：細(xì)粒度控制，該卸哪塊卸哪塊

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

你可以理解為——KV 緩存有了"虛擬內(nèi)存"，顯存放不下的部分自動(dòng)溢出到 CPU 內(nèi)存

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

DBO（Dual-Batch Overlap）是 vLLM 之前引入的一個(gè)優(yōu)化——把預(yù)填充和解碼放在不同的微批次里交替執(zhí)行，讓 GPU 的計(jì)算和內(nèi)存訪問更好地重疊起來。

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

六、硬件支持更新

NVIDIA B300/GB300（SM 10.3）：

• AllReduce 融合默認(rèn)開啟，調(diào)優(yōu)過的 all-reduce 通信器

• Blackwell 架構(gòu)的 CUTLASS FP8 GEMM 優(yōu)化

• 修復(fù)了桌面級(jí) Blackwell 上 NVFP4 的 NaN 問題

AMD ROCm：

• 升級(jí)到 ROCm 7.2.1 + PyTorch 2.10 + Triton 3.6

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

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

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

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

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

七、API 和其他值得關(guān)注的更新

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

thinking tokens 硬限制：推理模型（如 Qwen3-Coder）的思考長(zhǎng)度現(xiàn)在可以設(shè)上限了，防止模型在簡(jiǎn)單問題上瘋狂"內(nèi)心戲"

-sc簡(jiǎn)寫：--speculative-config太長(zhǎng)了，現(xiàn)在用-sc就行

量化更新：

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

• QeRL：在線量化 + 量化重加載，專為 RLHF 訓(xùn)練場(chǎng)景設(shè)計(jì)

Transformers v5 兼容：大面積適配了 HuggingFace Transformers v5，升級(jí)后不用再擔(dān)心各種奇怪的兼容性報(bào)錯(cuò)

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

接下來補(bǔ)充兩篇 vLLM 官方博客的內(nèi)容——這兩篇在 v0.18 和 v0.19 之間發(fā)布，跟這次版本更新緊密相關(guān)。

【博客一】隱藏狀態(tài)提?。航o推測(cè)解碼的訓(xùn)練管道打通了

這篇博客詳細(xì)介紹了一個(gè)從 v0.18.0 開始引入的新系統(tǒng)

標(biāo)題聽著學(xué)術(shù)，但實(shí)際解決的問題非常落地

痛點(diǎn)在哪？

推測(cè)解碼大家應(yīng)該不陌生了——上次三月四連發(fā)里我詳細(xì)聊過 P-EAGLE

核心思路就是用一個(gè)小的草稿模型快速猜 token，再用大模型并行驗(yàn)證

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

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

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

路線二：魔改 vLLM 內(nèi)部。直接調(diào)內(nèi)部 API，手動(dòng)組裝各種組件。能跑，但維護(hù)成本爆炸——vLLM 一升級(jí)你的 patch 就廢了。之前 Speculators 庫 v0.5.0 之前就是這么干的。

vLLM 的解法：在現(xiàn)有管道上做文章

vLLM 團(tuán)隊(duì)想到了一個(gè)很巧妙的方案。他們注意到三件事：

1. vLLM 跑 Eagle-3 推測(cè)解碼時(shí)，已經(jīng)有從大模型向草稿模型傳遞隱藏狀態(tài)的管道

2. vLLM 有KV Connector API，本來用于 Prefill/Decode 分離場(chǎng)景的數(shù)據(jù)傳輸，支持寫磁盤、共享內(nèi)存、Nixl 傳輸?shù)榷喾N方式

3. 隱藏狀態(tài)和 KV 緩存的內(nèi)存管理方式本質(zhì)上是一樣的——每個(gè) token 對(duì)應(yīng)一個(gè)值，可以復(fù)用分頁內(nèi)存管理

把這三個(gè)現(xiàn)有能力一組合：創(chuàng)建一個(gè)"假的"草稿模型，它不做推理，只負(fù)責(zé)接收大模型傳過來的隱藏狀態(tài)，存到自己的 KV 緩存里，再通過 KV Connector 導(dǎo)出。

下圖是這套系統(tǒng)的整體設(shè)計(jì)——通過復(fù)用 Eagle-3 的隱藏狀態(tài)管道和 KV Connector API，實(shí)現(xiàn)了零侵入的隱藏狀態(tài)提?。?/p>

隱藏狀態(tài)提取系統(tǒng)設(shè)計(jì)

這套設(shè)計(jì)的好處很明顯：

• 零侵入：不改 vLLM 核心代碼，復(fù)用現(xiàn)有管道

• 全功能：前綴緩存、分塊預(yù)填充、自動(dòng)批處理全能用

• 靈活：通過 KV Connector API 擴(kuò)展導(dǎo)出方式（寫磁盤、GPU 直傳、跨節(jié)點(diǎn)傳輸）

啟動(dòng)方式一條命令搞定：

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指定要提取哪幾層的隱藏狀態(tài)，shared_storage_path指定輸出目錄。每個(gè)請(qǐng)求處理完后，你在指定目錄下能找到 safetensors 文件：

# /tmp/hidden_states/{req_id}.safetensors
{
    "token_ids": [prompt_seq_len],                          # prompt 的 token id
    "hidden_states": [prompt_seq_len, num_layers, hidden_size]  # 對(duì)應(yīng)的多層隱藏狀態(tài)
}

幾個(gè)注意事項(xiàng)：

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

• 只提取 prompt token 的隱藏狀態(tài)，建議調(diào)v1/completions接口并設(shè)max_tokens=1

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

這套系統(tǒng)已經(jīng)和 vLLM 的 Speculators 庫整合（PR ），speculators v0.5.0 將支持草稿模型的在線訓(xùn)練——邊推理邊生成訓(xùn)練數(shù)據(jù)邊訓(xùn)練，整個(gè)流程閉環(huán)了。

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

【博客二】Gemma 4 落地 vLLM：Day 0 四平臺(tái)支持

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

Day 0 全平臺(tái)，這個(gè)含金量不低

vLLM 對(duì) Gemma 4 做到了發(fā)布當(dāng)天四個(gè)硬件平臺(tái)同時(shí)可用：

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

• Google TPU：Trillium 和 Ironwood 都有適配

• AMD GPU：ROCm 平臺(tái)支持

• Intel XPU：也加入了首日陣營(yíng)

TPU 支持是這次的亮點(diǎn)

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

下圖是 Gemma 4 在 Arena.ai 聊天排名上的性能對(duì)比——同等模型尺寸下，參數(shù)效率遙遙領(lǐng)先：

Gemma 4 性能對(duì)比 Gemma 4 在 vLLM 上能做什么

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

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

• 工具調(diào)用：原生 function-calling + 結(jié)構(gòu)化 JSON 輸出，vLLM 專門做了 Gemma 4 tool parser

• 長(zhǎng)上下文：邊緣模型 128K，大模型 256K

• 推理能力：復(fù)雜多步推理，數(shù)學(xué)和邏輯任務(wù)有顯著突破

• 140+ 語言原生支持

• Apache 2.0 協(xié)議：商用零障礙

快速上手，官方推薦用預(yù)構(gòu)建 Docker 鏡像省心省力：

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

或者手動(dòng)啟動(dòng)（需要transformers>=5.5.0）：

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

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

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

總結(jié)

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

從推理引擎到推理平臺(tái)。

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

• 加速方向：隱藏狀態(tài)提取打通訓(xùn)練管道，推測(cè)解碼從"拿來就用"進(jìn)化到"定制優(yōu)化"

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

• 硬件覆蓋：B300/GB300 首日適配、ROCm 持續(xù)完善、TPU/XPU 補(bǔ)強(qiáng)

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

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

2. 如果你在跑多模態(tài)模型，ViT CUDA 圖 + MRV2 多模態(tài)推測(cè)解碼，延遲會(huì)有可感知的改善

3. 如果你被顯存困擾，試試 CPU KV 緩存卸載——長(zhǎng)上下文場(chǎng)景下這是個(gè)救命功能

4. MRV2 該提上日程了，雖然 LoRA 還沒支持，但純推理場(chǎng)景已經(jīng)生產(chǎn)就緒

制作不易，如果這篇文章覺得對(duì)你有用，可否點(diǎn)個(gè)關(guān)注。給我個(gè)三連擊：點(diǎn)贊、轉(zhuǎn)發(fā)和在看。若可以再給我加個(gè)，謝謝你看我的文章，我們下篇再見！