vLLM 0.29.0:大模型推理引擎正在从“能跑模型”走向统一执行底座

vLLM 0.29.0:大模型推理引擎正在从“能跑模型”走向统一执行底座

摘要:

vLLM 0.29.0 的核心意义,并不只在于又支持了一批新模型。Model Runner V2 成为默认执行路径,意味着这个广泛使用的开源推理引擎开始收拢过去分散的模型执行逻辑,并把显存规划、CUDA Graph、投机解码、前缀缓存和并行采样放入更统一的工程框架。对企业部署团队而言,这类底层重构往往比单项跑分更重要:它决定新模型接入速度、异构硬件适配成本,以及线上服务能否长期维护。

vLLM 0.29.0:大模型推理引擎正在从“能跑模型”走向统一执行底座

一、一次看似普通、实际影响很深的版本升级

9月9日发布的 vLLM 0.29.0 汇集了277位贡献者的594次提交,其中91位是首次参与。版本最重要的变化是 Model Runner V2,也就是 MRV2,成为绝大多数模型的默认执行路径。旧的 MRV1 仍服务于少数尚未迁移完成的 ROCm 模型和功能,但主干方向已经十分明确。

模型推理框架容易被理解为“把权重加载进显卡,再提供一个兼容 OpenAI 的接口”。实际生产环境远比这复杂。一次请求进入系统后,要经过排队、批处理、输入预处理、KV Cache 分配、模型前向计算、采样、流式返回和资源回收。多模态模型还要处理图像、音频与视频编码,MoE 模型需要安排专家并行,推理模型可能使用 MTP、EAGLE 等投机解码方案。每增加一类模型,如果都形成一条特例化执行路径,维护成本会快速失控。

MRV2 的价值正在这里。它不是某个单独算子的加速补丁,而是重新组织模型运行、缓存管理和采样的一层基础设施。vLLM 将其设为默认值,相当于宣布新一代执行管线已经越过试验阶段。

二、为什么统一执行路径比单次性能提升更重要

企业私有化部署经常遇到一个矛盾:模型更新以周计,基础设施生命周期却以年计。如果每换一个模型都要更换镜像、重写启动参数、调整显存策略,平台很难形成稳定服务。统一执行层的目标,是让不同模型架构尽量复用相同的调度、缓存和监控能力,把模型差异限制在较小范围。

0.29.0 中几项更新可以说明这种思路。第一,MRV2 增加 CUDA Graph 内存分析,用于更准确地自动规划 KV Cache。第二,批量分片采样让每一步 logits 所需内存下降到原来的约 1/TP;张量并行规模越大,节省越明显。第三,系统新增请求数和排队 token 数两类准入控制参数。它们不直接提高理论吞吐,却能防止请求洪峰把服务拖入长时间排队乃至显存失控。

这是推理基础设施成熟的一个标志:优化目标不再只是“每秒生成多少 token”,而是同时关注首 token 延迟、单 token 延迟、峰值显存、尾部延迟、故障隔离和请求可预测性。

三、新模型正在倒逼推理框架重新设计

这个版本新增或强化了 Hy4-preview、Qwen3.8-Flash-Next、GraniteSWA、NemotronH Omni Reasoning V3、Kimi K3 NVFP4 等模型支持。它们背后的共同趋势,是模型结构越来越异构:MoE、稀疏注意力、Mamba 类状态空间模块、多 token 预测和低精度权重往往同时出现。

传统稠密 Transformer 的推理优化相对直观,主要围绕矩阵乘法、注意力和 KV Cache 展开。混合架构则带来了新的状态管理问题。以 Mamba 前缀缓存为例,0.29.0 通过预填充阶段的内部检查点,使首 token 延迟改善约9%至25%。这不是简单保存一段 KV,而是要维护模型内部状态并判断哪些计算可以安全复用。

Kimi K3 和 DeepSeek V4 的相关优化也很有代表性。融合 MXFP4 top-k 收尾操作带来约5%的端到端延迟下降,单个 Triton launch 完成 Mamba 元数据准备,则在对应内核上获得数倍加速。单看每项优化并不惊人,叠加到高并发服务后,却可能直接改变一套集群所能承载的用户规模。

四、对国产算力和异构部署的启示

vLLM 0.29.0 同时发布 CUDA、ROCm、XPU 和 CPU 工件,并继续优化 AMD、Intel 与不同 NVIDIA 架构。这说明开源推理栈正在成为模型与硬件之间的“事实适配层”。硬件厂商只有提供算子还不够,还要进入主流推理框架的调度、量化、缓存和通信路径。

对国产算力生态而言,真正的门槛也正在变化。早期适配通常以“模型能够运行”为目标;进入规模化部署后,客户会进一步比较连续批处理效率、长上下文稳定性、LoRA 动态加载、投机解码、故障恢复和监控工具。如果只能完成单模型演示,却无法融入成熟推理框架,实际商业竞争力仍然有限。

因此,国产芯片和工业智能平台不宜把 vLLM 仅当作一个可以移植的软件包,更应把它视为接口标准和工程能力清单:支持哪些模型结构、能否稳定运行前缀缓存、是否具备跨节点 KV 传输能力、量化后精度和吞吐如何、升级时需要维护多少私有补丁。这些问题会逐渐取代单次 benchmark,成为客户验收的重要部分。

五、升级前要注意什么

这个版本包含明确的破坏性变更。十种弃用模型架构被移除,PyAV 视频解码后端被删除,部分模型迁移到 Transformers modeling backend,旧的 Python 模块启动方式也被弃用,官方建议改用 vllm serve。FlashInfer all-reduce 在 CUDA 张量并行组中默认开启,前缀缓存哈希行为也发生变化。

生产团队不应直接用新镜像覆盖旧环境。更稳妥的做法是建立一套包含真实请求分布的回归测试:同时观察输出一致性、首 token 延迟、吞吐、峰值显存、P95/P99 延迟和多模态输入正确性;对依赖旧架构或自定义插件的系统,还应检查模块入口、环境变量和内部 API。

结语

vLLM 0.29.0 展示的不是某个模型又快了几个百分点,而是推理引擎开始承担类似“模型操作系统”的角色。模型层创新越快,底层越需要稳定、统一、可观测的执行环境。未来企业大模型平台的差异,不只来自选用了什么模型,也来自是否拥有一套能够持续吸收新架构、控制成本并保持可靠性的推理底座。

参考资料:


分享到