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

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

兄弟們總是問這個圖哪來的，就是 vllm 官網 vllm.ai

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

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

變更

類型

Ray 從默認依賴中移除

?? 破壞性變更

gRPC 服務支持

（--grpc標志）

新功能

GPU-less 渲染服務

（vllm launch render）

新功能

NGram 投機解碼遷移至 GPU

? 性能提升

KV Cache 智能 CPU 卸載

? 性能提升

FlexKV 卸載后端

新功能

彈性專家并行 Milestone 2

（NIXL-EP）

新功能

FlashInfer 升級至 0.6.6

?? 依賴升級

Responses API 流式工具調用

新功能

ASR 在線 Beam Search

新功能

FA4 用于 MLA Prefill

（DeepSeek V3）

? 性能提升

新架構

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

模型支持

1. Ray 被請出默認依賴

這是最需要注意的一條。

從 v0.18.0 開始，Ray 不再作為默認依賴安裝。

# 以前安裝 vLLM，Ray 會自動裝進來
pip install vllm


 # 現在如果你需要 Ray（多節點/Ray Cluster），需要顯式安裝
pip install vllm ray

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

什么情況下你還需要 Ray？

• 使用 Ray Cluster 做多節點分布式推理

• 用 Ray Data Pipeline 做批量推理

• 依賴ray serve做服務編排

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

2. gRPC 服務支持

一行 flag 開啟 gRPC：

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

同時開啟 HTTP 和 gRPC：兩個接口獨立運行，互不干擾。

為什么 gRPC 比 HTTP/REST 更快？

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

在高并發、低延遲的場景（比如內部微服務互調、Agent Pipeline）里，gRPC 的優勢會被明顯放大。

目前 gRPC 端口默認是8001，HTTP 保持8000不變。

3. KV Cache 智能 CPU 卸載 + FlexKV

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

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

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

現在加了一個復用頻率門控（reuse-frequency-gated）：只有被多次復用的 block才會寫入 CPU。

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

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

3.2 FlexKV：新的卸載后端

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

目前是實驗性功能，通過--kv-transfer-config指定：

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

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

4. NGram 投機解碼遷移至 GPU

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

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

現在整個 NGram 匹配遷移到 GPU 上，同時兼容 async scheduler，spec decode 的額外開銷大幅下降。

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

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

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

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

之前：EP（Expert Parallelism）的 GPU 數量在啟動時就固定了，擴縮容需要重啟服務。

現在：通過 NIXL（NVIDIA Interconnect eXtension Library）做專家權重的動態調度，GPU 可以動態加入/移出集群，不需要完全重啟。

另外新增--enable-ep-weight-filterflag，啟動時只加載本地 GPU 負責的專家權重，跳過不需要的參數：

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

大模型加載速度會有明顯提升，尤其是 EP 節點數多的時候。

6. FA4 用于 MLA Prefill

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

這一版為 MLA 的 prefill 階段引入了FlashAttention 4（FA4）內核，同時還有：

• Triton MLA decode 的 FP8 KV cache 支持

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

• context parallel 下 FP8 KV cache gather 優化

對于在生產環境跑 DeepSeek V3/V3.2 的用戶，這些內核優化疊加下來，prefill 吞吐會有可觀的提升。

7. GPU-less 渲染服務

這是一個架構解耦的新玩法。

# 啟動一個純 CPU 的預處理節點，不需要 GPU
vllm launch render --model your-model

背后的邏輯：多模態推理（圖像/音頻/視頻）的預處理（圖像解碼、resize、特征提取）和 GPU 推理之間其實是解耦的。

把預處理從 GPU 節點拆出來，單獨用 CPU 節點跑，GPU 只專注計算：

• CPU 節點可以水平擴展，處理高并發的媒體上傳

• GPU 不再被預處理任務占用

• 有助于降低整體服務成本

OpenAI Responses API 現在支持流式（streaming）的工具/函數調用了。

這對 Agent 類應用很關鍵——工具調用的結果不再需要等整個響應生成完才返回，可以在生成過程中實時 stream 出來，大幅降低 Agent 的感知延遲。

模型支持更新

新增支持

類型

Sarvam MoE

新架構

OLMo Hybrid

新架構

HyperCLOVAX-SEED-Think-32B VLM

新架構

Kimi-Audio-7B-Instruct

音頻模型

ColPali 延遲交互檢索

RAG 檢索

Eagle3 for Qwen3.5

投機解碼

Eagle3 for Kimi K2.5 MLA

投機解碼

Whisper LoRA

LoRA

FP8 LoRA dense kernel

量化

另外修了一批國內常用模型的 bug：DeepSeek-V3.2 tokenizer 空格截斷、Qwen3.5 工具調用、Qwen3-VL 時間戳不一致、MiniCPM-V 音頻推理等。

該不該升？

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

用 NGram 投機解碼的：必須升。GPU 化之后性能質變。

用 Ray 管多節點集群的：升級前先確認pip install ray已在你的部署腳本里，否則啟動會報找不到 Ray。

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

單機小模型部署：穩定性修復 + FlashInfer 0.6.6，升級無壞處。

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