---
url: /vllm/0.31.0.md
description: >-
  vLLM 0.31.0 发布解析（2026-10-05，717 commits / 307 contributors）：vllm preload
  权重常驻显存实现秒级重启、DeepSeek-V4.1-Flash 在 Blackwell 上的一套算子融合、Model Runner V2 投机解码与
  LiLiCorr、调度控制新开关、前缀缓存 LoRA 碰撞修复，附完整 Breaking Changes 清单与上手命令。
---

# 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](/vllm/introduction)。这篇只聊 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](https://github.com/vllm-project/vllm/releases/tag/v0.31.0) 读完整条目（尤其 Breaking Changes 那节），再去 docs 里读 [Preload](https://github.com/vllm-project/vllm/blob/main/docs/features/preload.md) 这一页，最后再动手升级。升级这件事上，保守永远比激进便宜。

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