2026 年 8 月 26 日，开源大模型推理框架 vLLM 发布 0.28.0 版本。此次更新包含 584 次提交，涉及 270 名贡献者，其中 76 名为首次参与者。最受关注的变化，是面向 Kimi-K3 推理链路加入自适应投机 Token 预算。官方称，该优化可使 DSpark 场景下的首 Token 延迟指标改善约 60%。需要特别说明的是，这一数字来自特定模型、投机解码方案和测试条件，并不代表所有模型部署升级后都能获得同等收益。[1] citeturn1view1turn1search7
为什么首 Token 延迟比平均吞吐量更直观
首 Token 延迟通常写作 TTFT，即从请求进入推理服务，到用户收到第一个输出 Token 所经历的时间。对于聊天机器人、代码助手和智能客服，用户首先感受到的往往不是整段文本每秒能生成多少 Token，而是点击发送后界面要等待多久才开始响应。因此，一个系统即使平均吞吐量很高，如果请求排队、预填充或投机调度耗时过长，交互体验仍会显得迟钝。
vLLM 0.28.0 所称的“约 60% 改善”，准确范围是 Kimi-K3 的 DSpark TTFT，由自适应投机 Token 预算带来。投机解码会先让草稿路径提出候选 Token，再由主模型验证。候选数量过少，难以充分减少主模型解码次数；候选数量过多，又会增加调度、计算和验证成本。自适应预算的重点，就是根据运行状态调整每轮允许处理的投机 Token 数量，而不是长期采用固定预算。对应实现可在官方合并记录中核验。[2] citeturn1view1
约 60% 改善不是单点加速的全部
如果只把此次更新理解成修改一个调度参数，就会低估 0.28.0 的优化范围。面向 Kimi-K3，vLLM 同时加入了解码上下文并行 DCP、融合式 FlashKDA 解码与预填充内核、MegaMoE 的 SiTU 激活支持，以及服务于序列并行的 GEMM-RS。其总体思路是同时压缩计算、通信、显存占用和调度等待，让首 Token 更早出现，并避免后续生成阶段被新的瓶颈抵消。官方发布说明 citeturn1view1
在多 GPU 推理中，集合通信经常成为大模型扩展效率的限制因素。0.28.0 对组合 all-gather 操作进行了优化，官方给出的数字是内核级速度提升 1.5 至 3 倍。这里同样不能直接换算为端到端推理速度，因为服务整体还受到模型结构、请求长度、批处理规模、网络拓扑和 GPU 利用率影响。不过，它说明优化路径已经从单纯追求算子计算速度，延伸到跨卡数据交换和并行执行效率。相关优化记录 citeturn1view1
显存和缓存优化同样影响响应时间
官方还表示，可选的 shared-expert 分片方案可在其目标配置中为每张 GPU 节省约 17 GiB 显存。对大型 MoE 模型而言，显存余量不仅决定模型能否加载，也会影响 KV Cache 容量、可容纳的并发请求数以及上下文长度。显存压力降低后，部署者可能获得更大的批处理空间，但实际收益仍需结合并行策略和模型配置测量。shared-expert 分片记录 citeturn1view1
0.28.0 还扩展了分层 KV Cache 卸载能力，包括磁盘卸载、可从树外加载的二级存储管理器、部分加载结果和分层指标。磁盘显然慢于 GPU 显存，因此它并不是无条件的低延迟方案，但在长上下文或显存紧张的服务中，可以用容量换取可运行性。合理做法是让高频数据保留在高速层，把低频缓存放入较慢层，并持续观察命中率和尾延迟。磁盘卸载实现 citeturn1view1
升级前应重点验证哪些指标
- 区分 TTFT 与生成吞吐：分别记录首 Token 延迟、每输出 Token 延迟、端到端完成时间及每秒 Token 数，避免单一平均值掩盖问题。
- 观察延迟分位数：除平均值外，至少比较 P50、P95 和 P99。线上用户更容易受到排队和长提示词造成的尾延迟影响。
- 固定测试条件：保持模型权重、量化方式、输入长度、输出长度、并发量和 GPU 拓扑一致，再进行新旧版本对照。
- 单独测试投机解码：分别关闭和启用 DSpark，判断收益究竟来自版本升级、投机策略，还是批处理与缓存变化。
- 检查显存及通信：记录峰值显存、KV Cache 使用量、跨卡通信时间和失败请求，确认低延迟并非以稳定性下降为代价。
不能忽视的兼容性变化
此次版本还调整了多项默认值和依赖关系。例如，max_num_batched_tokens 默认值由 8192 提高到 16384，Mamba 模型默认启用前缀缓存，Blackwell 平台的 CUDA Graph 捕获默认上限提高到 1024。更大的批处理 Token 上限可能提升吞吐，但也可能改变排队、显存和尾延迟表现，因此不宜在生产环境直接沿用新默认值而不复测。版本变更清单 citeturn1view1
破坏性变化方面，bitsandbytes 支持已迁移到树外插件，Transformers 升级至 5.15.0，旧的 calculate_kv_scales 运行时 KV 缩放计算与 override_attention_dtype 均被移除。依赖这些能力的部署脚本、镜像和配置文件，应先在预发布环境完成兼容性检查。PyPI 页面已经将当前正式版本标记为 0.28.0，可用于交叉核验发布包，但性能结论仍应以官方发布说明和对应代码记录为准。PyPI 发布包 citeturn1search7
总结
vLLM 0.28.0 展示了一条较完整的推理优化路径：通过自适应投机预算减少无效调度和验证开销，通过融合内核提高计算效率，通过 DCP、GEMM-RS 与 all-gather 优化改善多卡并行，再通过 shared-expert 分片和分层 KV Cache 缓解显存压力。标题中的“首字延迟降低约 60%”应理解为官方针对 Kimi-K3 DSpark TTFT 给出的特定结果，而非通用性能承诺。对部署团队而言，最有价值的行动不是立即用这一数字估算容量，而是在自身模型、硬件和真实流量下建立可重复的基准测试，确认 TTFT、吞吐、尾延迟与资源成本是否同时改善。
事件或资料日期：vLLM 0.28.0 于 2026 年 8 月 26 日发布；本文资料核验日期为 2026 年 8 月 31 日。版本存在性与发布日期参考 PyPI 0.28.0 页面，性能数据、功能变化及兼容性说明参考 vLLM 官方 GitHub Release 和 自适应投机 Token 预算合并记录。约 60%、1.5 至 3 倍及约 17 GiB 均为项目方在对应场景中披露的数据，实际部署结果可能因软硬件配置而异。citeturn1view1turn1search7
