语言模型服务工具 vLLM 在 0.33.0 中更换了 GPU 默认部署基础，并扩展了先生成候选答案、再验证输出的推测解码。提供语言模型服务的开发者需要在升级时更新安装基础，也能更广泛地选择草稿生成和验证方式。

1. CUDA 发行包统一为 13.0

据开发团队的发布说明，CUDA 的 wheel 包（用于安装 Python 的软件包文件）和镜像仅提供 CUDA 13.0 版本。CUDA 12.9 的发行包不再发布，因此此前使用它的开发者在升级到此版本时，需要迁移到新的默认发行包。

基础组件也升级到了 PyTorch 2.14.0 和 Triton 3.8.0。这次更新不仅更换运行基础，也调整了相关组件的版本。

CUDA 的默认安装命令如下，原样摘自发布说明。

pip install vllm

AMD 发行包默认采用 ROCm 10.0。ROCm 7.2 仍以独立镜像和 wheel 包的形式提供，用户可以选择旧版基础。与 CUDA 发行包统一为一种不同，AMD 仍保留两条分发路径。

2. 增加草稿优化与验证路径

推测解码由草稿模型先提出后续候选词元，再由主模型验证。本次新增的 XPress 负责优化这些草稿，适用对象包括 DFlash、DSpark 等采用块扩散、一次生成多个词元的草稿模型。

负责模型执行的 Transformers 建模后端也支持采用 MTP 多词元预测方式的草稿模型。这意味着该模型执行路径也能使用预测多个词元的草稿方案。

EAGLE 和 MTP 默认启用了一项改进：复用相同前缀请求的计算结果时，保留最后一个块。此次调整不仅涉及草稿生成方式，也涵盖了复用已有计算的路径。

3. 取消草稿预算预留以提高吞吐量

DFlash 和 DSpark 不再从词元预算中预先划出草稿槽位，即预分配的生成空间。这项变更取消了先将请求处理预算预留给草稿的行为。

发布说明引用的相关基准测试显示，在 GB300 上搭配使用 DeepSeek-V4.1-Flash 和 DSpark 时，输出吞吐量（单位时间内的处理量）从每秒 1373 个词元增至 3390 个词元。这表明，除了增加草稿模型，调整预算分配也是提升性能的手段。

此次还新增了草稿模型输出层量化功能，即用更少的比特表示数值。开发团队在发布说明中表示，这项以更低精度处理数值的功能，在并发请求数为 1 时将解码性能提高了 18%。同一草稿生成路径由此获得了预算管理与计算方式两方面的改进。

4. 新增面向特定 GPU 和模型的解码优化

GB300 可选用专门降低响应延迟的解码方式。开发团队给出的 Kimi-K3 结果显示，将模型计算分配到 8 个或 16 个 GPU 时，性能达到 1.5~2 倍。DeepSeek-V4.1-Flash 则报告在批大小为 1 时，解码阶段加快了 18.3%。

Humming 将 DeepSeek-V4/V4.1 的 MXFP4 低精度格式专家（根据输入选择的模型组件），以块级 FP8（8 位浮点格式）运行。据发布说明，在使用四张 H200 的配置中，解码性能提高了 9~21%。这一方案以不同数值格式执行模型内部的专家计算。

这些性能数据分别来自特定硬件、模型和设置，因此难以直接比较不同配置下的提升幅度。

5. 需同时评估提速代价与已移除的配置

FLy 是一种可选策略，以部分验证严谨性换取速度。开发团队在发布说明中给出的解码吞吐量，在 MI355X 和 B300 上为 1.04~1.31 倍。该策略作为可选项提供，便于用户同时权衡吞吐量收益与改变验证方式的代价。

原有草稿生成方式 Medusa 和 MLP speculator 已被移除。新草稿路径增加的同时，使用这些旧方式的服务需要选择并应用替代配置。

原有的 Ray 编译图执行器（一种预先组合运算后执行的工具）也已移除。使用该执行器的环境必须迁移到保留的执行路径，因此升级计划除了调整部署基础，还应包括替换现有执行配置。

vLLM 0.33.0 将部署基础统一到 CUDA 13，并拓宽了推测解码的改进范围，因此现有用户在此次升级中需同时准备安装与执行配置的迁移，以及性能路径的选择。