vLLM v0.18.0 更新，KV Cache 迎来大升级

上周刚写完 vLLM v0.17.1 紧急补丁，修了一个让 Qwen3.5 越跑越蠢的隐形 Bug，v0.18.0 就来了。

兄弟们总是问这个图哪来的，就是 vllm 官网 vllm.ai

兄弟们总是问这个图哪来的，就是 vllm 官网 vllm.ai

不只是功能堆叠，这次有几个变化会直接影响你的部署配置。

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

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

5. 弹性专家并行 Milestone 2：NIXL-EP 集成

这一版是弹性专家并行（Elastic EP）的第二个里程碑，核心变化是引入了 NIXL-EP 集成

对于跑 MoE 大模型（DeepSeek、Qwen3.5 MoE、Mixtral 等）的用户，这意味着什么？

之前：EP（Expert Parallelism）的 GPU 数量在启动时就固定了，扩缩容需要重启服务。

现在：通过 NIXL（NVIDIA Interconnect eXtension Library）做专家权重的动态调度，GPU 可以动态加入/移出集群，不需要完全重启。

另外新增 --enable-ep-weight-filter flag，启动时只加载本地 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 不再被预处理任务占用
• 有助于降低整体服务成本

8. Responses API 支持流式工具调用

OpenAI Responses API 现在支持流式（streaming）的工具/函数调用了！

这对 Agent 类应用很关键——工具调用的结果不再需要等整个响应生成完才返回，可以在生成过程中实时 stream 出来，大幅降低 Agent 的感知延迟。

模型支持更新

另外修了一批国内常用模型的 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，升级无坏处

#vLLM #大模型推理 #gRPC #DeepSeek #KVCache #投机解码 #弹性并行

制作不易，如果这篇文章觉得对你有用，可否点个关注。给我个三连击：点赞、转发和在看。若可以再给我加个🌟，谢谢你看我的文章，我们下篇再见！