vLLM v0.18.0 更新，KV Cache 迎來大升級

上周剛寫完 v0.17.1 的補(bǔ)丁，vLLM v0.17.1 緊急補(bǔ)丁，修了一個(gè)讓 Qwen3.5 越跑越蠢的隱形 Bug，v0.18.0 就來了。

兄弟們總是問這個(gè)圖哪來的，就是 vllm 官網(wǎng) vllm.ai

不只是功能堆疊，這次有幾個(gè)變化會直接影響你的部署配置。

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

變更

類型

Ray 從默認(rèn)依賴中移除

?? 破壞性變更

gRPC 服務(wù)支持

（--grpc標(biāo)志）

新功能

GPU-less 渲染服務(wù)

（vllm launch render）

新功能

NGram 投機(jī)解碼遷移至 GPU

? 性能提升

KV Cache 智能 CPU 卸載

? 性能提升

FlexKV 卸載后端

新功能

彈性專家并行 Milestone 2

（NIXL-EP）

新功能

FlashInfer 升級至 0.6.6

?? 依賴升級

Responses API 流式工具調(diào)用

新功能

ASR 在線 Beam Search

新功能

FA4 用于 MLA Prefill

（DeepSeek V3）

? 性能提升

新架構(gòu)

：Sarvam MoE、OLMo Hybrid、Kimi-Audio-7B 等

模型支持

1. Ray 被請出默認(rèn)依賴

這是最需要注意的一條。

從 v0.18.0 開始，Ray 不再作為默認(rèn)依賴安裝。

# 以前安裝 vLLM，Ray 會自動裝進(jìn)來
pip install vllm


 # 現(xiàn)在如果你需要 Ray（多節(jié)點(diǎn)/Ray Cluster），需要顯式安裝
pip install vllm ray

為什么移除？Ray 是個(gè)重型依賴，安裝慢、體積大，但絕大多數(shù)單機(jī)部署場景根本用不到它。拆開之后，單機(jī)部署的安裝速度和鏡像體積都會明顯改善。

什么情況下你還需要 Ray？

• 使用 Ray Cluster 做多節(jié)點(diǎn)分布式推理

• 用 Ray Data Pipeline 做批量推理

• 依賴ray serve做服務(wù)編排

如果你只是在單機(jī)跑 vLLM，這個(gè)變化對你透明，什么都不用改。

2. gRPC 服務(wù)支持

一行 flag 開啟 gRPC：

vllm serve meta-llama/Llama-3.1-8B-Instruct --grpc

同時(shí)開啟 HTTP 和 gRPC：兩個(gè)接口獨(dú)立運(yùn)行，互不干擾。

為什么 gRPC 比 HTTP/REST 更快？

HTTP/REST 每次請求需要解析文本格式的 JSON，頭部字段冗余多，長連接復(fù)用效率低。gRPC 基于 HTTP/2，用 Protocol Buffers 做二進(jìn)制序列化，同一連接可以多路復(fù)用，延遲和吞吐都有明顯優(yōu)勢。

在高并發(fā)、低延遲的場景（比如內(nèi)部微服務(wù)互調(diào)、Agent Pipeline）里，gRPC 的優(yōu)勢會被明顯放大。

目前 gRPC 端口默認(rèn)是8001，HTTP 保持8000不變。

3. KV Cache 智能 CPU 卸載 + FlexKV

這一版對 KV Cache 的卸載邏輯做了兩個(gè)升級。

3.1 只卸載"值得卸載"的 block

之前的 CPU offloading 是無差別的——只要顯存緊張就往 CPU 搬。

現(xiàn)在加了一個(gè)復(fù)用頻率門控（reuse-frequency-gated）：只有被多次復(fù)用的 block才會寫入 CPU。

邏輯很直接：一個(gè) block 如果只被用了一次，把它寫到 CPU 再讀回來，開銷比收益大。只有那些在 prefix cache 里高頻命中的 block，才值得花帶寬卸載到 CPU 保留。

這對長對話、系統(tǒng) prompt 固定的場景幫助很大——那些高頻復(fù)用的 prefix 塊會被優(yōu)先保留，冷塊直接丟棄，減少無效 CPU?GPU 傳輸。

3.2 FlexKV：新的卸載后端

FlexKV 作為全新的 KV Cache 卸載后端引入，支持更靈活的存儲策略（不只是 CPU 內(nèi)存，還可以擴(kuò)展到 SSD 等介質(zhì)）。

目前是實(shí)驗(yàn)性功能，通過--kv-transfer-config指定：

vllm serve your-model \
  --kv-transfer-config '{"kv_connector":"FlexKVConnector","kv_role":"kv_both"}'

配合多 KV group 支持（--kv-groups），對 PD 分離架構(gòu)的部署有直接幫助。

4. NGram 投機(jī)解碼遷移至 GPU

NGram 是一種不依賴草稿模型的投機(jī)解碼方法——直接從輸入 prompt 里找 n-gram 模式來預(yù)測后續(xù) token。

以前這個(gè)匹配邏輯在 CPU 上跑，每一步都需要 CPU→GPU 數(shù)據(jù)傳輸，開銷抵消了不少收益。

現(xiàn)在整個(gè) NGram 匹配遷移到 GPU 上，同時(shí)兼容 async scheduler，spec decode 的額外開銷大幅下降。

適合用 NGram 的場景：代碼補(bǔ)全、文檔續(xù)寫、固定模板生成——這些場景里 prompt 和輸出之間有大量重復(fù) n-gram，投機(jī)命中率高。不需要單獨(dú)加載一個(gè)草稿模型，只要加一個(gè) flag：

vllm serve your-model \
  --speculative-model "[ngram]" \
  --num-speculative-tokens 5 \
  --ngram-prompt-lookup-max 4

這一版是彈性專家并行（Elastic EP）的第二個(gè)里程碑，核心變化是引入了NIXL-EP 集成。

對于跑 MoE 大模型（DeepSeek、Qwen3.5 MoE、Mixtral 等）的用戶，這意味著什么？

之前：EP（Expert Parallelism）的 GPU 數(shù)量在啟動時(shí)就固定了，擴(kuò)縮容需要重啟服務(wù)。

現(xiàn)在：通過 NIXL（NVIDIA Interconnect eXtension Library）做專家權(quán)重的動態(tài)調(diào)度，GPU 可以動態(tài)加入/移出集群，不需要完全重啟。

另外新增--enable-ep-weight-filterflag，啟動時(shí)只加載本地 GPU 負(fù)責(zé)的專家權(quán)重，跳過不需要的參數(shù)：

vllm serve deepseek-ai/DeepSeek-V3 \
  --tensor-parallel-size 8 \
  --enable-ep-weight-filter

大模型加載速度會有明顯提升，尤其是 EP 節(jié)點(diǎn)數(shù)多的時(shí)候。

6. FA4 用于 MLA Prefill

DeepSeek 系列用了MLA（Multi-head Latent Attention）架構(gòu)——把 KV cache 壓縮到低秩空間，顯存占用大幅下降，但也帶來了額外的矩陣運(yùn)算。

這一版為 MLA 的 prefill 階段引入了FlashAttention 4（FA4）內(nèi)核，同時(shí)還有：

• Triton MLA decode 的 FP8 KV cache 支持

• DeepSeek-V3.2 向量化 MLA query concat kernel

• context parallel 下 FP8 KV cache gather 優(yōu)化

對于在生產(chǎn)環(huán)境跑 DeepSeek V3/V3.2 的用戶，這些內(nèi)核優(yōu)化疊加下來，prefill 吞吐會有可觀的提升。

7. GPU-less 渲染服務(wù)

這是一個(gè)架構(gòu)解耦的新玩法。

# 啟動一個(gè)純 CPU 的預(yù)處理節(jié)點(diǎn)，不需要 GPU
vllm launch render --model your-model

背后的邏輯：多模態(tài)推理（圖像/音頻/視頻）的預(yù)處理（圖像解碼、resize、特征提?。┖?GPU 推理之間其實(shí)是解耦的。

把預(yù)處理從 GPU 節(jié)點(diǎn)拆出來，單獨(dú)用 CPU 節(jié)點(diǎn)跑，GPU 只專注計(jì)算：

• CPU 節(jié)點(diǎn)可以水平擴(kuò)展，處理高并發(fā)的媒體上傳

• GPU 不再被預(yù)處理任務(wù)占用

• 有助于降低整體服務(wù)成本

OpenAI Responses API 現(xiàn)在支持流式（streaming）的工具/函數(shù)調(diào)用了。

這對 Agent 類應(yīng)用很關(guān)鍵——工具調(diào)用的結(jié)果不再需要等整個(gè)響應(yīng)生成完才返回，可以在生成過程中實(shí)時(shí) stream 出來，大幅降低 Agent 的感知延遲。

模型支持更新

新增支持

類型

Sarvam MoE

新架構(gòu)

OLMo Hybrid

新架構(gòu)

HyperCLOVAX-SEED-Think-32B VLM

新架構(gòu)

Kimi-Audio-7B-Instruct

音頻模型

ColPali 延遲交互檢索

RAG 檢索

Eagle3 for Qwen3.5

投機(jī)解碼

Eagle3 for Kimi K2.5 MLA

投機(jī)解碼

Whisper LoRA

LoRA

FP8 LoRA dense kernel

量化

另外修了一批國內(nèi)常用模型的 bug：DeepSeek-V3.2 tokenizer 空格截?cái)?、Qwen3.5 工具調(diào)用、Qwen3-VL 時(shí)間戳不一致、MiniCPM-V 音頻推理等。

該不該升？

跑 MoE 大模型（DeepSeek、Qwen3.5 MoE）+ 多 GPU：建議升。FA4 MLA 內(nèi)核 + Elastic EP Milestone 2 是實(shí)實(shí)在在的提升。

用 NGram 投機(jī)解碼的：必須升。GPU 化之后性能質(zhì)變。

用 Ray 管多節(jié)點(diǎn)集群的：升級前先確認(rèn)pip install ray已在你的部署腳本里，否則啟動會報(bào)找不到 Ray。

用 KV Cache CPU offloading 的：升級可以順手用上智能門控，省掉無效的 CPU 寫入。

單機(jī)小模型部署：穩(wěn)定性修復(fù) + FlashInfer 0.6.6，升級無壞處。

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