vLLM 是咱们公众号的老熟人了，老章隔三差五就要来拆一遍它的版本更新
大模型本地部署最强引擎，vLLM 又发大版本了，v0.23.0
现在0.24来了，我把整份更新日志翻了个底朝天，挑几个我觉得值得说道的点跟大家聊聊
简介
先给不太熟的朋友补一句：vLLM 是一个专门做大模型推理和部署的引擎，核心卖点就是快和省显存
vLLM 赢完了：登顶开源推理引擎No1
它最出名的技术是 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 首发适配
这次最抢眼的是把 MiniMax-M3 给接上了
而且是一整套组合拳：BF16/FP8 indexer 走 MSA、MXFP4 量化支持、FP8 稀疏 GQA，连 AMD 显卡上的适配都安排得明明白白（gfx950 上的 mxfp8 MoE 调优、MI300X 上 bf16 权重跑 fp8 逐通道量化）
我一直觉得，一个模型能不能第一时间被 vLLM 支持，某种程度上是它江湖地位的体现，国产模型能吃上这种待遇，挺好
顺带还修了 MiniMax-M2 之前的一个性能回退问题，用 M2 的朋友记得升一下
二、DeepSeek-V4 持续被喂饱
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 续集：Unsloth 把它压到 18GB，单卡飙到 2000+ Token/s
前面我单独写过 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 反馈也可以
一个开源项目能保持这种更新密度和质量，还愿意持续做减法保持整洁，这本身就很了不起