大模型本地部署最强引擎，vLLM 大版本更新，v0.24.0

vLLM 是咱们公众号的老熟人了，老章隔三差五就要来拆一遍它的版本更新

昨天0.24来了，我把整份更新日志翻了个底朝天，挑几个我觉得值得说道的点跟大家聊聊

简介

先给不太熟的朋友补一句：vLLM 是一个专门做大模型推理和部署的引擎，核心卖点就是快和省显存

它最出名的技术是 PagedAttention，把操作系统里虚拟内存分页那套思路搬到了 KV Cache 上，同样的显卡能塞下更多并发请求，吞吐量比 HuggingFace Transformers 原生方案高出一大截

现在国内外几乎所有搞大模型私有化部署的团队，绕不开它

先上一张图，把这版最值得关注的一次看全：
省流版：

• MiniMax-M3 成为新主角 ：新增 MiniMax-M3 支持，同时跟进 BF16/FP8 indexer、MXFP4、FP8 sparse GQA 和 ROCm 调优

• DeepSeek-V4 继续成熟 ：2-4% TTFT 优化、4% 端到端吞吐优化、低延迟 topK、连续 KV 分配、SM120、XPU、ROCm 支持都在推进

• Model Runner V2 继续铺开 ：量化模型默认支持、GraniteMoE 默认启用，Qwen 和 DeepSeek-V2 MoE 迁移，DFlash 投机解码也跟上

• Streaming Parser Engine 上线 ：把工具调用和 reasoning 解析统一起来，Qwen3、MiniMax-M2、GLM、Nemotron V3 都有对应 parser

• Diffusion LLM 进入 vLLM 主线 ：DiffusionGemma 加入，CPU 路径和结构化输出保护也有了

• Rust frontend 更像生产服务了 ：API key、CORS、tokenize、pause、resume、abort、thinking token budget 都在补齐

• 多卡设备选择逻辑有变化 ：vLLM 不再内部设置 CUDA_VISIBLE_DEVICES ，新加 device_ids 参数

这次最抢眼的是把 MiniMax-M3 给接上了

而且是一整套组合拳：BF16/FP8 indexer 走 MSA、MXFP4 量化支持、FP8 稀疏 GQA，连 AMD 显卡上的适配都安排得明明白白（gfx950 上的 mxfp8 MoE 调优、MI300X 上 bf16 权重跑 fp8 逐通道量化）

我一直觉得，一个模型能不能第一时间被 vLLM 支持，某种程度上是它江湖地位的体现，国产模型能吃上这种待遇，挺好

顺带还修了 MiniMax-M2 之前的一个性能回退问题，用 M2 的朋友记得升一下

二、DeepSeek-V4 持续被喂饱

DeepSeek-V4 上个版本刚首发，这次直接来了一波大规模优化，我数了数至少六七个 PR 是专门伺候它的：

• FlashInfer 稀疏索引缓存，TTFT（首 token 延迟）改善 2%~4%

• prefill 分块规划优化，端到端吞吐提升 4%

• 给低延迟场景加了 cluster-cooperative topK kernel

• KV cache 改成按块连续分配

• 修了个 OOM（显存溢出）的坑

更关键的是覆盖面：现在 DeepSeek-V4 在 SM120 上能跑了（和 GLM-5.1 一起），Intel XPU、AMD ROCm 的注意力和 MoE 路径也都补齐了

• FlashInfer sparse index cache，TTFT 提升 2-4%

• prefill chunk planning 优化，端到端吞吐提升 4%

• 低延迟场景的 cluster-cooperative topK kernel

• DeepSeek-V4 的 KV cache 做连续 per-block 分配

• 支持 block-FP8 shared expert 的 TEP=16

• SM100 上的 native DSA indexer decode

• DeepSeek-V4 和 GLM-5.1 已启用 SM120

• XPU 和 ROCm 路径继续补齐

这些数字看起来都不夸张，2%、4% 这种优化，在外行眼里可能没啥感觉

但做推理服务的人都知道，这种改动才是真金白银

当模型已经大到 1T 级别，单点 4% 吞吐提升意味着同样机器多扛一部分流量，也意味着在长上下文、多请求、MoE 调度下少一点崩溃边缘

大模型推理引擎拼到后面，很多时候拼的就是这种细碎到有点枯燥的工程活

DiffusionGemma 进主线了

DiffusionGemma 这次也正式进 v0.24.0

前面我单独写过 DiffusionGemma，它最大的特点是生成方式和传统自回归模型不同，低并发场景下速度非常夸张

这次 release notes 里提到：

• 新增 DiffusionGemma 支持

• 包含 CPU 路径

• 对 diffusion decoder 的结构化输出加了保护

这说明 vLLM 对新型生成范式的支持在继续往主线合并

这件事很有意思

过去推理框架基本围绕自回归模型设计，后面如果扩散式语言模型、多 token 并行生成、投机解码、MTP 都继续发展，推理引擎的抽象会越来越复杂

vLLM 这次把 DiffusionGemma 往主线里收，是一个很清晰的信号

Model Runner V2 越来越能打

这次它新增了量化模型默认支持、GraniteMoE 默认启用，还继续迁移 Qwen 和 DeepSeek-V2 MoE 模型，同时加了 DFlash 投机解码和更准确的 FP32 Gumbel sampling

我的理解是，vLLM 现在已经进入“核心路径换代”的阶段

过去大家更关心某个模型能不能跑起来，现在更要关心它跑在哪条 engine path 上

因为同一个模型，走老路径和走新路径，吞吐、显存、调度、兼容性都会不一样

这次 MRv2 继续扩张，说明 vLLM 的重心还在往新架构迁移

对用户来说，好处是以后大量新优化会优先沉淀到 MRv2 里

坏处也很现实：升级版本时更要跑自己的回归测试，尤其是量化、LoRA、投机解码、多模态这种组合场景

全新的 Streaming Parser Engine 是给 Agent 时代补课

这次新增的 Streaming Parser Engine，我觉得很值得单独拎出来

它要解决的是一个越来越常见的问题：模型输出不只是普通文本，还有工具调用、reasoning、结构化片段、流式增量

不同模型的格式又不一样，Qwen3 一套，MiniMax-M2 一套，GLM 一套，Nemotron 又一套

如果每个模型都写一份零散 parser，后面会越来越难维护

v0.24.0 做的事情，是把这些解析逻辑往统一引擎里收

这对 Agent 开发很重要

因为 Agent 真正上线后，很多失败都卡在细节里：流式输出里的工具调用有没有被正确识别，reasoning 有没有被误吞，JSON 有没有被强行修坏

这些东西很脏，很工程，但很真实

一个容易踩坑的破坏性改动

vLLM 不再在内部自己设置 CUDA_VISIBLE_DEVICES 了，改成提供一个 device_ids 参数让你显式指定

如果你的部署脚本以前依赖 vLLM 在内部处理设备可见性，这次要认真检查多卡启动方式

尤其是这些场景：

• 一台机器上多个服务共用 GPU

• Kubernetes 里靠环境变量控制 GPU 分配

• Ray 或多进程启动时每个 worker 看到的设备不同

• ROCm 环境里还在沿用 CUDA 风格的设备变量

如果你只是想新建环境试一下，官方 quickstart 推荐用 uv 建 Python 3.12 环境，再安装 vLLM：

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

如果你要明确锁到这次的版本，可以这样做：

uv pip install "vllm==0.24.0" --torch-backend=auto

生产环境升级，我建议别直接原地替换

更稳的方式是新建环境、固定版本、用自己的真实请求集跑一遍，再看多模态、工具调用、reasoning、量化模型、LoRA、长上下文这些场景有没有变化

总结

vLLM v0.24.0 这一版，我给的评价是该升，但要看菜下饭

• 如果你要跑 MiniMax-M3、DeepSeek-V4、DiffusionGemma、Qwen 多模态，这版值得第一时间测试

• 如果你在用 Rust frontend 或 OpenAI 兼容服务做网关，这版的服务能力补齐很有价值

• 如果你的业务很依赖稳定输出格式，重点测 Streaming Parser Engine 相关模型

• 如果你是多卡部署，先看 CUDA_VISIBLE_DEVICES 和 device_ids 的影响

• 如果你只是单机跑普通模型，没必要着急，等一周看 issue 反馈也可以

一个开源项目能保持这种更新密度和质量，还愿意持续做减法保持整洁，这本身就很了不起