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

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

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

先看全貌：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 升級(jí)至 0.6.6

?? 依賴升級(jí)

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

新功能

ASR 在線 Beam Search

新功能

FA4 用于 MLA Prefill

（DeepSeek V3）

? 性能提升

新架構(gòu)

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

模型支持

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

這是最需要注意的一條。

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

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


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

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

什么情況下你還需要 Ray？

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

• 用 Ray Data Pipeline 做批量推理

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

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

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

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

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

3. KV Cache 智能 CPU 卸載 + FlexKV

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

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

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

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

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

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

3.2 FlexKV：新的卸載后端

FlexKV 作為全新的 KV Cache 卸載后端引入，支持更靈活的存儲(chǔ)策略（不只是 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），對(duì) PD 分離架構(gòu)的部署有直接幫助。

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

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

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

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

適合用 NGram 的場(chǎng)景：代碼補(bǔ)全、文檔續(xù)寫、固定模板生成——這些場(chǎng)景里 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 集成。

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

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

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

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

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

大模型加載速度會(huì)有明顯提升，尤其是 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)化

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

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

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

# 啟動(dòng)一個(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)用了。

這對(duì) 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

量化

另外修了一批國(guó)內(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)集群的：升級(jí)前先確認(rèn)pip install ray已在你的部署腳本里，否則啟動(dòng)會(huì)報(bào)找不到 Ray。

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

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

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