vLLM 0.28.0发布：开源推理服务进入“运行时优化”阶段

vLLM 0.28.0近日正式发布。根据项目在 GitHub 上公布的版本说明，这一版本的重点集中在 Kimi-K3 模型优化、高级推测解码、Model Runner V2，以及GPU内存和多层操作效率改进 上。

这不是一次只增加几个模型名称的常规更新。vLLM正在把竞争重点从“能不能把模型跑起来”，推向“在真实生产流量下，能不能用更少的GPU稳定地跑更多请求”。对于已经使用vLLM部署大模型服务的开发者，0.28.0值得测试；对于仍停留在单请求、低并发本地验证阶段的用户，升级后是否立刻感受到明显差异，则取决于模型架构、上下文长度、并发规模和GPU配置。

这次更新到底发生了什么

**vLLM 0.28.0是面向大模型推理与服务场景的开源版本更新，核心目标是提高请求吞吐、降低单请求延迟，并改善GPU资源利用率。**它延续了vLLM以PagedAttention、连续批处理和OpenAI兼容服务接口为代表的技术路线，但把更多改动放到了运行时执行、模型专门适配和推测解码上。

从版本说明看，开发团队这次没有把所有宣传重点放在一个单独的“最高速度”数字上，而是同时处理了几个会直接影响线上服务成本的问题：

• 对 Kimi-K3 的推理路径进行针对性优化；
• 引入或完善更高级的推测解码能力；
• 更新 Model Runner V2，改善模型执行过程；
• 优化多层操作的效率，减少运行时开销；
• 改善GPU显存使用和内存管理；
• 继续扩大vLLM对新模型和新型服务工作负载的适配能力。

需要注意的是，参考资料没有给出一组可以跨硬件、跨模型直接复现的统一基准数字。因此，不能把“版本升级”直接等同于所有场景下固定的吞吐提升比例。推理服务的实际结果，往往比训练阶段更依赖具体配置：例如输入输出token比例、批大小、KV Cache命中率、量化方式、张量并行规模，以及请求是否集中在长上下文场景。

Kimi-K3优化，信号比数字更重要

**模型专用优化是指推理框架针对某个模型的结构、算子、缓存或并行方式进行适配，而不是改变模型权重本身。**vLLM 0.28.0将Kimi-K3列为重点优化对象，说明开源推理引擎的模型支持正在从“通用兼容”走向“架构级适配”。

过去，开发者通常会把模型权重下载下来，然后交给推理框架尝试加载。只要模型结构与Transformers或其他后端兼容，服务就能启动。但“能启动”只是第一道门槛。真正上线后，服务还要解决几个问题：

1. 某些算子是否有高效的CUDA实现；
2. 模型的注意力结构是否适合现有KV Cache布局；
3. MoE模型的专家路由是否造成GPU之间通信拥堵；
4. 长上下文请求是否会挤占其他请求的显存；
5. 多卡执行时，计算和通信能否尽量重叠；
6. 首个token延迟和持续生成速度是否满足业务要求。

所谓针对Kimi-K3的优化，价值通常不在于“模型突然变聪明”，而在于相同权重、相同精度和相同硬件下，推理路径更贴近该模型的真实结构。模型质量由训练数据、参数和对齐方式决定；推理框架主要影响速度、并发、显存占用和服务成本。把二者混为一谈，是评估这类版本更新时最容易犯的错误。

对部署Kimi系列模型的团队而言，0.28.0的正确打开方式不是直接替换线上版本，而是用固定的请求集做A/B测试，至少记录以下指标：

| 指标 | 含义 | 为什么重要 | |---|---|---| | TTFT | Time to First Token，首个token生成时间 | 直接影响聊天、搜索和代码助手的即时感 | | TPOT | Time Per Output Token，生成每个输出token的平均耗时 | 反映流式输出过程中的持续速度 | | 吞吐量 | 单位时间完成的输入或输出token数量 | 决定高并发服务的GPU利用率 | | P50/P95/P99延迟 | 不同分位数下的请求延迟 | 观察尾延迟和线上稳定性 | | 显存峰值 | 服务运行期间的最大GPU内存占用 | 决定能否提高并发或部署更大模型 | | OOM次数 | Out of Memory，显存不足错误次数 | 判断长上下文和突发流量下的可靠性 |

推测解码：用“小模型猜，大模型验”

**推测解码是一种让较小的草稿模型先预测多个token，再由目标大模型批量验证的推理加速方法。**它的核心思路很直观：大模型逐token生成通常很慢，但其中一部分结果可以先由更快的草稿模型猜出来；如果猜测正确，目标模型就能一次确认多个token，从而减少逐步等待。

普通自回归生成可以理解为“每次只走一步”：目标模型生成第一个token，再把它放回上下文，继续生成第二个token。推测解码则像是让一个轻量助手先写出一小段草稿，主模型一次检查这段草稿。草稿被接受的token越多，理论上的加速越明显；如果草稿质量差，主模型频繁拒绝预测，额外开销就可能抵消收益。

vLLM此前已经支持推测性解码，0.28.0进一步强调高级推测解码能力。这类改进的重点通常包括候选token生成、批量验证、接受率控制，以及在不同请求负载下的调度策略。对服务端来说，它不是简单地“多跑一个模型”，而是要在以下几个环节之间找到平衡：

• 草稿模型不能占用过多显存；
• 草稿生成必须明显快于目标模型验证；
• 验证过程要尽量复用已有计算；
• 多请求并发时，推测解码不能破坏连续批处理；
• 长输入和短输出场景不能被额外的草稿开销拖慢。

因此，推测解码并不保证所有任务都加速。输出高度不可预测、目标模型与草稿模型差异较大，或者请求本身很短时，收益可能有限。更适合它的场景通常是代码补全、结构化文本生成、对话回复和具有较高token预测一致性的任务。

开发者测试推测解码时，应同时观察“速度”和“接受率”。只看平均延迟，容易忽略某些请求实际上被草稿模型拖慢。更有价值的测试方式是分别测量短输出、长输出、低并发和高并发四组工作负载，再比较P95或P99延迟，而不是只看一次运行的峰值tokens/s。

Model Runner V2：推理框架的“执行层”升级

**Model Runner是推理服务中负责组织模型执行、批处理调度和运行时计算的核心组件，Model Runner V2则是vLLM对这层执行机制的进一步重构和优化。**如果把大模型服务比作机场，模型权重是飞机，GPU是跑道，那么Model Runner更像塔台和地勤系统：它决定哪些请求先起飞、如何合并批次，以及怎样减少等待和切换成本。

对于小规模本地调用，运行时优化可能不明显；但在生产服务中，GPU通常同时处理不同长度、不同优先级和不同生成阶段的请求。预填充（Prefill）阶段主要消耗计算资源，用来处理输入上下文；解码（Decode）阶段则更依赖显存访问和KV Cache。两者混在一起执行时，长输入请求可能挤压正在流式生成的短请求，造成尾延迟上升。

Model Runner V2的价值，正是试图让这些执行过程更可控、更高效。结合vLLM一贯的连续批处理机制，运行时需要持续回答几个问题：

• 哪些请求可以放进同一个批次；
• 哪些请求应该优先完成首token返回；
• 预填充和解码如何交错执行；
• CUDA Graph等执行优化在动态批次下如何复用；
• 请求取消、超时和显存回收如何降低额外成本。

这类改动通常不会带来一个对所有用户都相同的性能数字，但会影响服务在复杂流量下的表现。换句话说，0.28.0更像是在提升“交通系统的通行效率”，而不是单纯把某一辆车的最高时速提高。

显存优化仍然是推理服务的主战场

**KV Cache是大模型生成过程中保存历史注意力键和值的显存区域，它能避免每生成一个新token都重新计算完整上下文。**KV Cache提高了生成效率，但也会随着上下文长度、并发请求数和模型层数增长，成为推理服务最主要的显存占用来源之一。

vLLM最具代表性的PagedAttention，就是将KV Cache按类似操作系统分页的方式管理，减少连续显存分配带来的浪费。0.28.0继续强调GPU内存使用优化，说明显存管理依然是版本演进的重点。

在实际服务中，显存压力通常来自四类请求：

1. 输入上下文很长的检索增强生成请求；
2. 输出上限较高的代码或文档生成请求；
3. 同时在线的并发会话数量较多；
4. 多模态模型中图像、视频等输入带来的额外中间结果。

显存优化的意义并不只是让某个模型“勉强启动”。如果一次服务能在不增加GPU数量的情况下，把可承载并发从32路提高到40路，或者在同样并发下减少显存碎片和OOM风险，最终影响的是单位请求成本和服务稳定性。

不过，开发者不要把框架的显存优化理解为“显存占用一定下降固定比例”。不同模型的层数、隐藏维度、注意力头设计、量化精度以及并行配置都会改变结果。升级前后应记录GPU显存峰值、KV Cache使用率和实际可接受的最大并发，而不是只看服务启动时的显存占用。

与vLLM 0.27.x相比，应该怎样看这次升级

**vLLM 0.28.0的升级价值主要体现在运行时效率和新模型适配，而不是一个面向所有任务的统一性能倍增。**从使用者角度，可以把这次更新拆成三类收益：

| 更新方向 | 直接影响 | 更可能受益的场景 | 需要注意的问题 | |---|---|---|---| | Kimi-K3针对性优化 | 改善特定模型的执行效率和兼容性 | Kimi-K3在线服务、长上下文和高并发部署 | 其他模型未必获得同等收益 | | 高级推测解码 | 可能降低生成阶段延迟、提高输出速度 | 代码补全、对话、结构化生成 | 依赖草稿模型质量和token接受率 | | Model Runner V2 | 优化批处理、调度和运行时执行 | 多请求并发、复杂流量和生产服务 | 需要重新验证调度参数和稳定性 | | GPU内存与多层操作优化 | 提高显存利用率，减少运行时开销 | 长上下文、多卡和显存紧张部署 | 实际收益取决于模型结构与硬件 |

与TensorRT-LLM、SGLang等推理引擎相比，vLLM的优势仍然是生态兼容性、社区规模和较成熟的服务接口。TensorRT-LLM在NVIDIA硬件深度优化场景中依然有竞争力，SGLang则在结构化生成、前缀缓存和部分复杂工作流上受到开发者关注。vLLM 0.28.0没有试图用单一功能解决所有问题，而是继续强化通用部署底座。

这也意味着，选择推理引擎时不能只问“谁的tokens/s最高”。更应该看四件事：模型是否原生支持、目标硬件是否覆盖、线上调度是否稳定，以及团队是否有能力维护定制化内核。一个实验室基准中更快的引擎，如果在真实业务中频繁出现OOM、长尾延迟或模型兼容问题，未必能带来更低的总成本。

开发者要不要现在升级

**已经在生产环境运行vLLM的团队，建议先灰度验证0.28.0，而不是直接全量替换旧版本。**特别是以下用户，升级优先级相对更高：

• 正在部署Kimi-K3的团队；
• GPU利用率长期偏低，但请求延迟仍然较高的服务；
• 需要尝试推测解码来降低生成延迟的应用；
• 长上下文和高并发导致显存紧张的部署；
• 使用vLLM V1运行时，并希望测试Model Runner V2改进的团队。

建议按照下面的流程进行验证：

1. 固定软件和硬件环境

锁定CUDA、驱动、PyTorch、GPU型号、模型权重、量化方式和并行参数。否则即使性能变化，也很难判断究竟来自vLLM还是来自环境差异。

2. 准备真实请求集

不要只用随机短句。至少应包含短对话、长上下文、代码生成、结构化输出和高并发突发流量。请求输入长度和输出长度都要分桶统计。

3. 同时测试吞吐和尾延迟

在线服务不能只追求平均tokens/s。应重点关注P95、P99 TTFT、P95 TPOT、GPU显存峰值、请求失败率以及流式输出是否出现卡顿。

4. 单独验证推测解码

推测解码涉及草稿模型和目标模型的组合，应该单独测试接受率、额外显存、短输出表现和高并发表现。若接受率偏低，关闭该功能可能反而更快。

5. 先灰度，再切换

先把小比例流量导入0.28.0，观察至少一个完整业务高峰周期，再决定是否扩大流量。对于对延迟和稳定性敏感的服务，保留旧版本回滚路径仍然必要。

这次发布意味着什么

**vLLM 0.28.0释放出的最大信号，是开源推理框架正在从“模型运行器”变成完整的推理基础设施。**模型数量继续增加、上下文不断变长、MoE和多模态架构变得复杂之后，推理成本不再只由矩阵乘法决定，调度、缓存、通信、内存碎片和运行时执行同样重要。

从这个角度看，Kimi-K3优化、推测解码和Model Runner V2并不是彼此孤立的功能。它们共同指向一个目标：让GPU在更多时间里做有效计算，让请求在不同执行阶段之间更顺畅地流动，并把有限显存转化为更高的有效并发。

但也要保持冷静。vLLM 0.28.0不是所有模型、所有硬件、所有业务的“无条件升级”。版本发布说明没有提供一组适用于全场景的统一提升比例，开发者仍需要用自己的模型和流量做基准测试。对于追求生产可靠性的团队，兼容性、回滚能力和指标可观测性，和峰值性能同样重要。

总体来看，这是一版值得关注的工程型更新：它没有把注意力放在概念包装上，而是继续深入推理服务最难、也最影响成本的部分。对开源大模型生态来说，真正决定模型能否大规模落地的，往往不是权重文件能否下载，而是每个token需要多少GPU时间、多少显存，以及在高峰流量下能否稳定交付。vLLM 0.28.0正在解决的，正是这些问题。

参考来源

• vLLM v0.28.0 GitHub Release：项目官方版本说明，包含本次发布的功能和修复列表。
• vLLM GitHub 仓库：vLLM官方开源代码仓库，可查看提交记录、Issue、模型支持和开发进展。
• vLLM GitHub Releases：vLLM历次版本发布页面，适合对比不同版本的变更内容。