vLLM 0.31.0：717 次提交，一半给 DeepSeek-V4.1-Flash 擦枪，一半让你少等一次模型加载

先说我自己的一段受苦经历。

给一个 70B 的模型调服务参数——max_num_seqs 调大一点、gpu_memory_utilization 压一压、量化方案从 FP8 换成别的再换回来。每一次改动，都要重启一次引擎。而每一次重启，都要完整走一遍：读盘 → 反序列化 → 量化后处理 → 搬进显存。三分钟。

一个上午重启二十次，就是一个小时纯坐着等。你以为你在调参，其实你在给硬盘和 PCIe 打工。

2026 年 10 月 5 日发布的 vLLM v0.31.0，第一件事就是来治这个的：新增 vllm preload，一个常驻的权重缓存守护进程，把量化后的权重留在显存里，引擎重启时通过 CUDA IPC 零拷贝映射，不用再走一遍磁盘。官方原话是"把重启时间从几分钟压到几秒"。

而这次发布的体量是：717 次提交、307 位贡献者，其中 96 位是第一次提交。

一个版本里最贵的那批改动，是只有几百人看得懂的算子融合；最值钱的那批改动，往往是让所有人少等三分钟。vllm preload 属于后者。

先把 0.31.0 摆在什么位置说清楚

vLLM 是 UC Berkeley Sky Computing Lab 出身的大模型推理与服务引擎，Apache 2.0 协议，如今挂在 PyTorch Foundation 下。截至本文写作时，GitHub 上 93,213 Star、23,012 Fork。它是生产环境跑开源大模型的事实标准——Hugging Face 在 2025 年底把自己的 TGI 判了维护模式，明确推荐迁到 vLLM。

没读过基础篇的，建议先看认识 vLLM。这篇只聊 0.31.0 改了什么、以及升级前你必须知道哪些会炸。

0.31.0 六个真正值得关心的变化

方向	关键变化	谁受影响最大
Fast restart	`vllm preload` 权重常驻显存 + `--load-format ipc_cache`	频繁重启 / 频繁换模型的开发与运维
DeepSeek-V4.1-Flash	FlashMLA mega attention + NVFP4 KV cache 成 SM100 默认，Mega-Gate 等一批融合	Blackwell（B200/B300）用户
Model Runner V2	支持 draft-model 投机解码、自定义 logits processor，新增 LiLiCorr drafter	追低延迟的在线服务
调度控制	`--max-num-active-seq`、自适应 `--long-prefill-token-threshold`、等待队列重做	高并发混部场景
前缀缓存与安全	extra keys 按来源打标签、LoRA 路径进哈希、多模态请求参数默认拒绝	所有人（含安全）
大规模与硬件	MoonEP all2all 后端、PCP+DP、ROCm AITER v0.1.23、XPU graph 默认开	千卡级集群、国产与非 NVIDIA 硬件

一、Fast restart：这可能是今年最"接地气"的一个新功能

先看它到底做了什么。

vllm preload 会每张 GPU 起一个守护进程，把这个 rank 上量化后、按 TP 切分好的权重提前加载进显存，然后通过 Unix domain socket 把 CUDA IPC handle 交给后续的 vLLM 引擎。引擎重启时不再是"从磁盘读一遍再处理一遍"，而是直接映射已有的显存。

三个关键性质：

快：权重加载退化成一次显存映射，重启从"分钟级"变成"秒级"
不额外占显存：默认的 zero_copy 模式下，引擎直接共享守护进程的显存，重启不会多出一份 footprint
会安全兜底：守护进程不在、或者缓存的权重和引擎配置对不上，就自动回退到从磁盘加载

对不上是怎么判断的？引擎在开服前会跟守护进程比对一整套指纹：检查点内容（从 safetensors 元数据哈希而来，所以权重相同但目录不同也能命中）、模型架构、TP/DP 的 size 与 rank、dtype、量化方法与配置、模型 revision、vLLM 版本。任何一项不一致就回退。此外还会校验守护进程的 GPU UUID，避免一个残留的 socket 给错的卡供权重。

听起来很美，但有边界，别踩：

目前只支持 CUDA 和 ROCm
支持 TP / EP / DP（含跨节点），但起守护进程时流水线并行会被拒绝
多节点要每个节点各跑一个 vllm preload，并额外指定一个和引擎 --master-port 不冲突的 --weight-cache-master-port

另外还有一个更激进的实验品：vllm snapshot create/restore，用 CRIU 直接恢复一个完整初始化好的 TP1 引擎（#51360）。这个我建议先观望，CRIU + GPU 状态的组合从来不是省油的灯。

二、DeepSeek-V4.1-Flash：把 Blackwell 的每一滴都榨出来

如果你在 SM100（Blackwell）上跑 DeepSeek-V4.1-Flash，0.31.0 是一次相当实在的提速。挑几条最有代表性的：

FlashMLA mega attention + V4.1 NVFP4 压缩 KV cache 成为 SM100 默认（#56935）：KV cache 压着存，注意力照样跑得快
Mega-Gate：把 gate GEMM 和专家选择融合在一起（#56266）
DeepGEMM sparse MQA logits 用于 indexer（#56254）
解码边界融合：TP all-reduce、mHC 输入准备、MoE finalize 三件事被折进同一个边界（#57643、#58586）
小 batch 的 WO-A 融合，带 inverse RoPE 和 MXFP8 量化，覆盖 SM100/SM103（#58634）
Engram 表默认在同机 DP 副本间共享（#57651）：一张卡上跑多个 DP 副本时，这份内存不再重复占
视觉塔的 encoder CUDA graph（#56625）、SWA bounded replay（#56227，滑动窗口 KV 不进前缀缓存）

这一堆 PR 的共同点是：它们全都在砍kernel 边界。大模型推理在最新硬件上的瓶颈，早就不是"算力不够"，而是"每一层之间那些零碎的同步、搬运、重复量化"。0.31.0 干的就是把这些缝隙一个个焊死。

顺便说句实话：这类优化是有代价的。它们高度绑定具体架构（SM100/SM103、gfx950）和具体模型。你换一张卡、换一个模型，很可能一条都用不上。所以别看到"提速"就兴奋，先看你是不是那个硬件、那个模型。

三、Model Runner V2 与投机解码：LiLiCorr 来了

Model Runner V2 是 vLLM 正在推的新一代执行层。0.31.0 上它补齐了几块关键拼图：

draft-model 投机解码（#43091）和自定义 logits processor（#56497，且会在准入时校验）
新增 LiLiCorr drafter（#57934）
DFlash 异步调度（#58065），并把 context K/V 预计算直接捕获进 draft 的 CUDA graph（#57632）
DSpark 自适应验证用于 Gemma4（#57263），变长解码用于 Kimi-K3（#52988）
MRV2 profiling 阶段现在会把 MoE 内存算进去，避免 WideEP 部署下 profiling 时明明够、真跑起来 OOM（#57270、#58411）

最后那条特别值得单独记一笔。做过大规模 MoE 部署的人都懂：OOM 发生在 profiling 之后，是最难查的那种 OOM。

四、调度控制：终于能把"有多少条在跑"单独管住了

以前 max_num_seqs 一个参数干两件事：既限制并发总数，也间接决定了多少请求能进入 RUNNING。现在拆开了：

--max-num-active-seqs（#56758）：独立限制 RUNNING 的准入，不再和 max_num_seqs 绑死
--long-prefill-token-threshold 改成自适应：根据等待中的 prefill 数量决定，而不是对着一个孤立请求硬切 chunk（#57951、#58459）
等待队列重做：已经持有 KV block 的请求优先被调度（#58947）
修掉了 KV connector + MTP 在 KV 压力下的死锁（#57104），以及 max_num_seqs 不是 8 的倍数时的吞吐断崖（#57355）

这几条凑在一起，指向的是同一件事：长 prompt 和短 prompt 混部时，短请求不该被长请求的 prefill 堵死。

五、前缀缓存：一个真实存在的缓存投毒面被堵上了

这条我个人觉得是 0.31.0 里最值得单独拎出来讲的安全修复。

问题出在哈希。vLLM 的前缀缓存会给每个 block 算哈希，其中会混入一些"额外 key"（比如 LoRA 适配器名、cache_salt）。但这些 key 是不带来源标签地拼在一起的——于是一个 LoRA 的名字，有可能和另一个请求传的 cache_salt 撞成同一个哈希。

后果是什么？用 A 适配器缓存下来的 KV，可能被 B 请求命中并复用。这不是性能问题，这是正确性问题，往坏了说是缓存投毒。

0.31.0 的修法（#51899、#59335）：

额外 key 按来源打标签，LoRA 名和 cache_salt 不再可能互相冒充
LoRA 的路径本身也进哈希——同名但不同路径的适配器不会再复用彼此的缓存
附带修了多模态接收缓存里"旧条目覆盖新 payload"的问题（#57833）

同时，安全默认值收紧了：现在每个请求单独传 mm_processor_kwargs / media_io_kwargs 会被直接拒绝，除非服务端启动时显式加了 --trust-request-mm-kwargs（#58830）。服务端级别的 --mm-processor-kwargs 和离线 LLM 用法不受影响。

一句话总结这节：把"谁都能往哈希里塞东西"改成了"谁塞的都得署名"。看起来是小改动，堵的是大类漏洞。

六、大规模服务与硬件：MoonEP、ROCm、XPU、CPU 全面推进

MoonEP：新的均衡 EP all2all 后端，--all2all-backend moonep（#52101）
Prefill context parallelism 支持与 DP 组合（#57075）；DeepEPv2 支持序列并行（#57210），EPLB 支持 shared-expert overlap（#57236）
SM100/SM103 的低 SM 占用 multimem reduce-scatter（#55072）
ROCm：AITER v0.1.23、torch 2.13 + Triton 3.8、gfx950 上原生 32x32 scale 的 MXFP8 GEMM、Hy4 路径上 torch.compile 后解码延迟降到 1/13（#57526）
Intel XPU：PyTorch 2.14、XPU graph 默认开启（VLLM_XPU_ENABLE_XPU_GRAPH 被移除），融合 QK RMSNorm + RoPE + gate 让解码区快 55%（#56096）
CPU：Intel Diamond Rapids 的 FP8 W8A8、Arm 分页注意力最高快 25%、Zen DA8W4 int4、wheel 改到 Ubuntu 22.04 构建并带 AMX-FP8

CPU 和 XPU 这两块在国内环境其实挺关键——不是所有团队都摸得到 B300。

升级之前，先看这一节：会被打脸的地方

0.31.0 的 Breaking Changes 不算少，而且有几条是"静默改行为"型，容易踩：

变更	影响
每请求 `mm_processor_kwargs` / `media_io_kwargs` 默认报错	多模态服务必须加 `--trust-request-mm-kwargs` 才能恢复旧行为
`tokenizer_mode="slow"` 被移除	Transformers v5 下它本来就等于 `"hf"`
`--enable-mamba-fine-grained-prefix-cache` 改名	新名 `--enable-mamba-shared-prefix-checkpoint`
`quantization="fp8"` 的在线量化被重定向到 `fp8_per_tensor` 简写	Quark 的静默在线 MXFP4 量化被移除，改用在线量化 API
AllSpark INT8 W8A16 GEMM 后端被移除	用它的部署需要换后端
`--enforce-eager` 现在同时会关掉 JIT kernel warmup	除非开了 fault tolerance（#58197、#58593）
XPU graph 默认开启，`VLLM_XPU_ENABLE_XPU_GRAPH` 移除	XPU 用户行为变化
`VLLM_PLE_CPU_OFFLOAD` 移除	改用 `--engram-config`
`--collect-detailed-traces` 逗号分隔形式移除	改用 list 语法
`transformers` 现在在 requirements 里加了上界（#59614）	装依赖时可能被卡住
Model Runner V1 + PP>1 + 异步调度 + 结构化输出启动即拒绝（#56250）	组合使用的要先拆
`/render` 的 `return_assistant_tokens_mask` 与响应字段 `assistant_tokens_mask` 被移除	依赖该字段的客户端会报错

另外几个默认行为的改变，不看 release notes 根本发现不了：

VLLM_BATCH_INVARIANT=1 现在用可中断 CUDA graph 而不是 torch.compile，并且会关掉序列并行和异步 TP
FlashMLA mega attention 成为 DeepSeek-V4.1 在 SM100 的默认路径
Engram host 表默认在同机 DP 副本间共享
AITER w4a4 ASM GEMM 在 ROCm 上默认关闭

我的建议很朴素：先在预发环境完整跑一遍你的启动参数 + 你的多模态调用链路，再排上线。这次的变更里，有相当一部分只在"多模态"和"量化"这两条路径上才触发，冒烟测试很容易漏。

谁在真跑这些

vLLM 不是"发布会上热闹、生产里没人用"的项目。几个能查证的：

Amazon：购物助手 Rufus 用多节点 vLLM 跑在 Trainium 上，服务 2.5 亿客户
Roblox：主力 LLM 推理引擎，公开口径是延迟降 50%、每周 40 亿 token
LinkedIn：50+ 生成式 AI 场景（含 Hiring Assistant），接入 vLLM 后 TPOT 改善约 7%
IBM Research：RITS 平台以 vLLM 为核心 serving runtime，支撑 1300+ 研究员、同时托管 100+ 模型，配合 OpenShift AI + KServe，用 vLLM 导出的"Requests Waiting"指标做 1→n 的扩缩容（比按 RPS 扩靠谱得多）
Meta、Mistral AI、Cohere、Stripe：生产推理在用。IBM / Red Hat 把它作为 OpenShift AI 和 RHEL AI 里的推理引擎
商业侧：核心维护者（Simon Mo、Woosuk Kwon 等）在 2026 年 1 月成立了 Inferact 做商业化托管，种子轮 1.5 亿美元、估值 8 亿美元，a16z 与 Lightspeed 领投。开源协议与社区治理不变

一个推理引擎能被 AWS、NVIDIA、AMD、Google Cloud、Intel 同时当"自己硬件的适配对象"来贡献代码，说明它已经不是某个公司的项目，而是一层公共基础设施。基础设施的特点就是：你感觉不到它，但它一出问题，全线瘫痪。

初体验：10 分钟试一遍 fast restart

装最新版（CUDA 13.0 走 PyPI 默认）：

bash

pip install vllm
# 或者用 uv
uv pip install vllm --torch-backend=auto

# ROCm
pip install vllm --extra-index-url https://wheels.vllm.ai/rocm/0.31.0/rocm723

也可以直接拉镜像跑：

bash

docker pull vllm/vllm-openai:v0.31.0

然后体验 0.31.0 最香的那一条。第一步，先起守护进程，把权重常驻进显存：

bash

vllm preload --model meta-llama/Llama-3.1-8B-Instruct --tensor-parallel-size 4

每个 rank 会把自己的分片加载、做完量化后处理，然后通过 Unix socket 导出 CUDA IPC handle。注意是每个 rank 缓存完才绑定 socket，所以引擎在此之前连上来也只是回退到磁盘加载，不会出错。

第二步，用 ipc_cache 这个 load format 起引擎（也可以反复重启它）：

bash

vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --tensor-parallel-size 4 \
  --load-format ipc_cache

第一次你感受不到差别，因为守护进程自己还是要从磁盘读一遍。从第二次重启开始，差距就出来了——改参数、重启、几秒钟就回到可服务状态。

两个容易犯的错：

别给 vllm preload 传 --load-format ipc_cache，守护进程本身必须从磁盘加载，传了会直接报错
指纹对不上时会静默回退到磁盘加载，如果你发现"怎么还是这么慢"，先去日志里看是不是回退了——最常见的诱因是 vLLM 版本或量化配置变了

多节点 TP 的话，每个节点各起一个，共用 rendezvous 但换一个端口：

bash

# 节点 0（本地 8 卡）
vllm preload --model /path/to/model --tensor-parallel-size 16 \
  --nnodes 2 --node-rank 0 --master-addr 10.0.0.1 \
  --weight-cache-master-port 29600

--weight-cache-master-port 必须和引擎的 --master-port 不一样，别忘了这一条。

最后提醒一句：vllm preload 目前只支持 CUDA 和 ROCm，且起守护进程时不支持流水线并行。用 PP 的部署先别碰。

进阶

写到这里，0.31.0 真正让我在意的不是那 717 次提交，而是它透露出的两个方向。

第一个方向是"开发者体验开始被当回事"。过去 vLLM 的优化全部集中在吞吐和延迟上——那是给生产环境看的数字。vllm preload 不一样，它优化的是"你自己机器上改一次参数的等待时间"。当一个项目开始优化贡献者和使用者的日常体感，说明它的用户结构已经从"少数大厂"扩散到了"大量普通工程师"。

第二个方向是"推理引擎正在变成硬件抽象层"。这一版里，NVIDIA、AMD、Intel、CPU、还有华为昇腾、IBM Spyre、Rebellions NPU 的适配条目密密麻麻。模型层在快速迭代，硬件层也在快速分化，而夹在中间的推理引擎，正在成为那个唯一稳定的接口。

想继续往下挖的，我建议的顺序是：先去 vLLM 官方 Release Notes 读完整条目（尤其 Breaking Changes 那节），再去 docs 里读 Preload 这一页，最后再动手升级。升级这件事上，保守永远比激进便宜。

更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。