事件：vLLM v0.31.0 发布，DeepSeek-V4.1-Flash 默认内核切换
10 月 5 日 14:44，开源推理引擎 vLLM 放出 v0.31.0，距上一版间隔 13 天。这一版合入 717 次提交、来自 307 位贡献者，规模在 vLLM 的版本节奏里偏大。真正要记住的是两件直接影响部署的事。
第一件是内核默认值变了。DeepSeek-V4.1-Flash 的 FlashMLA mega attention 配合 V4.1 的 NVFP4 压缩 KV 缓存，被正式设为 SM100（英伟达 Blackwell 架构）上的默认路径，不再需要手工打开实验开关。之前针对这组模型调过的推理参数，也要重新看一眼。
第二件是新增的 vllm preload 命令，它拉起一个权重缓存守护进程，把量化后的权重常驻显存。完整 release notes 见 vLLM GitHub Release 页面，PyPI 上的 wheel 与源码包在同一天下午陆续上传。若你正用 vLLM 托管 DeepSeek、GLM 或 Qwen，这一版值得排进本周的升级窗口。
权重预加载：vllm preload 怎么砍掉重启等待
传统上重启 vLLM 引擎要付两笔固定成本。把上百 GB 的权重从磁盘或对象存储读进来，以及把 BF16 权重转成 FP8 之类的在线量化重跑一遍。这两步串起来通常是分钟级的灰度窗口，新命令针对的就是这段。它启动一个守护进程持有量化后的权重，让引擎重启时直接复用。
0.31.0 为此补齐了数据并行支持、MTP 草稿模型支持和一个 /health 健康检查端点。还有启动时的就绪等待逻辑，客户端不会再在守护进程尚未就绪时把请求打进来。更进一步的是实验性的 vllm snapshot create/restore，用 CRIU 把一个已初始化的 TP1 引擎整体快照再恢复，但它只覆盖单卡张量并行。
验证方法是先跑一次冷启动记下耗时，再用 preload 守护进程重启一次。比较的是服务真正 ready 的时间戳，而不是进程拉起的时间。这个差值对按请求唤醒 GPU 的场景尤其明显。
Model Runner V2 与投机解码：草稿模型进了 V2 主路径
Model Runner V2 是 vLLM 新一代执行内核，这次是它第一次拿到完整功能补齐。核心一项是草稿模型投机解码落地（#43091），自定义 logits processor 也转移到了 V2（#56497）。投机解码的逻辑是用小模型先猜答案、再由主模型批量验证，用少量算力换更高有效吞吐。
这一版同时加入新的 LiLiCorr 草稿模型（#57934）。DFlash 走异步调度（#58065），Gemma4 有 DSpark 自适应验证，Kimi-K3 支持变长解码验证。异构词表之间的 CPU-GPU 同步被移除。
还有一个容易被忽略的实在修复。MoE 显存现在会在 MRV2 的 profiling 阶段一并计入，避免 WideEP 部署时 OOM，这类问题过去常表现为同一份配置换个机器就起不来。压测时先用 vllm bench serve 跑基线再对比吞吐。
大规模部署：MoonEP、上下文并行与 EPLB 各管什么
大规模服务方向塞进了不少新后端。MoonEP 平衡 all2all 后端通过 --all2all-backend moonep 启用（#52101），它冲着的是 MoE 模型在多卡之间反复交换 token 时通信先于计算成为瓶颈这一段。prefill 上下文并行现在可与数据并行、专家并行和 MTP 同时使用（#57075）。
DeepEPv2 加入序列并行（#57210），EPLB 负载均衡支持共享专家重叠（#57236），KV 卸载增加了背压检测（#50045）。若此前卡在多卡扩展效率上，这里是排查入口。编辑判断：只用单卡跑中小模型的团队，这一节基本可以跳过。
调度参数变了：活跃请求数与长预填充阈值
调度侧有一个很实用的新参数。--max-num-active-seqs 可以独立于 max_num_seqs 限制 RUNNING 状态的准入数量（#56758）。过去这两个值绑在一起，想压低并发只能整体改 max_num_seqs，连带影响批处理规模。现在可以只收紧活跃请求数，对做多租户隔离的团队比想象中更有用。
另一个变化是 --long-prefill-token-threshold 现在会根据等待中的预填充请求数量自适应（#57951）。等待队列也重做了，已经持有 KV block 的请求会被优先调度（#58947）。KV 压力下 KV connector 与 MTP 之间的死锁同样被修复。
还有一个吞吐悬崖的修复。max_num_seqs 不是 8 的整数倍时会出现吞吐显著下滑（#57355），此前为迁就硬件做过奇怪并发设置的团队，升级后值得重扫一遍。压测要看 P99 延迟与总吞吐两条曲线。
升级前必须改的参数和两个新默认值
这一版的破坏性变更不算少。按请求的多模态参数 mm_processor_kwargs 与 media_io_kwargs 现在默认报错，需要显式加 --trust-request-mm-kwargs 才放行（#58830）。tokenizer_mode="slow" 已被移除，在 Transformers v5 下它本来就等同于 hf。
改名方面，--enable-mamba-fine-grained-prefix-cache 变为 --enable-mamba-shared-prefix-checkpoint。VLLM_PLE_CPU_OFFLOAD 被移除而应改用 --engram-config，AllSpark INT8 W8A16 GEMM 后端整体删除。在线量化通过 quantization="fp8" 现在会转到 fp8_per_tensor 简写。
两个默认值变化要单独提醒。--enforce-eager 现在同时关闭 JIT 内核预热，首 token 延迟上升但稳态吞吐不变，别误判为性能回退。XPU graphs 改为默认开启。
谁该现在升级，谁该再等一轮
建议立刻排期的有三类人。跑 DeepSeek-V4.1-Flash 且用 Blackwell 卡的团队，能直接吃到默认内核切换的性能变化。做自动扩缩容或按请求唤醒 GPU 的团队，preload 砍掉的是每次冷启动的分钟级等待。被 WideEP 部署 OOM 折磨过的 MoE 运维，显存估算口径这次统一了。
建议观望的也有三类。单卡跑 7B 以下模型的开发者，重头戏基本用不上，而排查破坏性变更的成本是实打实的。重度依赖自定义在线量化脚本的团队，要先把 Quark 静默量化路径迁移完再说。
值得一提的是，这一次没有任何模型厂商配合发布，全靠 vLLM 社区 307 位贡献者推进。开源推理引擎正在从跟上模型发布节奏，变成决定模型什么时候真正可用。接下来值得盯两件事：Model Runner V2 何时成为默认路径，以及 Kimi-K3 的变长解码验证收益能否在其他模型上复现。
来源与说明
本文由 AI 潮汐编辑部基于官方公告与公开资料整理，补充了行业影响、适用场景和行动建议，帮助你在阅读原文前先理解这条信息为什么重要。
原始来源：https://github.com/vllm-project/vllm/releases/tag/v0.31.0
如发现事实、价格或链接有误，可通过 联系我们 提交更正。
常见问题
vLLM v0.31.0 适合什么样的团队立刻升级？
跑 DeepSeek-V4.1-Flash 且用 Blackwell 卡的团队收益最直接。做自动扩缩容、按请求唤醒 GPU 的团队能靠 vllm preload 省掉每次冷启动的分钟级等待。被 WideEP 部署 OOM 困扰的 MoE 运维也可以升级，因为 MoE 显存现在会在 profiling 阶段一并计入。单卡跑中小模型的话，收益有限。
多模态模型升级后报错说 mm_processor_kwargs 被拒绝怎么办？
这是本版的破坏性变更。按请求传入的多模态参数默认改为拒绝，服务端需要显式加 --trust-request-mm-kwargs 才会放行。服务端级别的 --mm-processor-kwargs 和离线 LLM 接口不受影响。如果部署面向不受信任的调用方，不要急着打开这个开关。
用了 --enforce-eager 之后感觉变慢了，是回退吗？
不是性能回退。0.31.0 起 --enforce-eager 会同时关闭 JIT 内核预热，首次请求需要现场编译内核，因此首 token 延迟上升，稳态吞吐不受影响。如果你依赖低首延迟场景，考虑去掉这个参数，让内核在启动阶段预热完成。
vllm preload 到底能省多少时间，怎么自己量？
先在没有 preload 的情况下冷启动一次，记录服务真正 ready 的时间而不是进程拉起的时间。再启动 vllm preload 守护进程后重启一次，比较两个 ready 时间戳。0.31.0 补上了 /health 端点和就绪等待逻辑，可以据此准确判断。注意 snapshot create/restore 目前是实验性功能，且只覆盖 TP1 单卡张量并行配置。
在线量化从 quantization="fp8" 迁移需要注意什么？
通过 quantization="fp8" 做在线量化现在会重定向到 fp8_per_tensor 这个在线简写写法。Quark 专属的静默在线 MXFP4 量化已被移除，官方建议改用在线量化 API。如果流程依赖 Quark 特定的量化行为，升级前需要先完成迁移并做一次精度对比。