AI技术

vLLM 0.28 一口气改了584次：新一代模型正在逼推理框架重写底层

, , , , ,

摘要：2026年8月26日，vLLM 0.28.0 发布。单从版本号看，它像一次常规升级；翻开 release notes，规模却很不寻常：584 个提交、270 名贡献者，其中 76 名是首次参与。更值得关注的是这些提交集中在什么地方。K...

vLLM 0.28 发布总览与多 GPU 推理基础设施示意图

2026年8月26日，vLLM 0.28.0 发布。单从版本号看，它像一次常规升级；翻开 release notes，规模却很不寻常：584 个提交、270 名贡献者，其中 76 名是首次参与。更值得关注的是这些提交集中在什么地方。Kimi-K3、DeepSeek V4、投机解码、分层 KV Cache、E/P/D 解耦、ROCm、Rust 前端、在线量化几乎同时出现在一份发布说明里。vLLM 已经很难再被理解为一个“把大模型跑起来”的 Python 服务框架，它正在长成一套针对新模型结构不断修改调度器、内存层、通信层和执行内核的推理操作系统。

早期 vLLM 最出名的是 PagedAttention。大模型在线服务时，KV Cache 会随着请求长度不断增长，如果像普通 Tensor 那样要求连续显存，长期运行后很容易出现碎片，大量显存明明空着却无法满足一个较大的连续分配。PagedAttention 借用了操作系统分页思路，把 KV Cache 拆成固定大小的 block，并通过页表式映射管理请求。再配合 continuous batching，请求不必等整个 batch 完成才加入或退出，GPU 利用率由此得到明显提高。这套机制解决了 Transformer 推理时代最突出的两个工程问题：KV Cache 碎片和动态并发调度。

问题在于，2026年的前沿模型已经不再遵守“标准 Transformer + 全量 Attention + 普通 MoE”这套稳定假设。Kimi-K3 引入 KDA、MegaMoE 和新的上下文并行策略，DeepSeek V4 把 sparse MLA、MTP 和投机解码绑在一起，Mamba、线性注意力和混合架构继续增加。推理框架如果还把模型当成“加载权重—跑 forward—做采样”这样一个黑盒，很快会失去性能。vLLM 0.28 的意义，恰好可以从这一点理解：模型架构和推理基础设施的边界正在变薄。

Kimi-K3 为什么会逼出一轮“全栈性能攻坚”

vLLM 官方把本次 Kimi-K3 优化直接称为 “performance push”。其中最容易看懂的是 Decode Context Parallel，也就是 DCP。长上下文模型的 Decode 阶段常常受 KV Cache 和 Attention 访存限制，如果上下文很长，仅做 Tensor Parallel 并不能理想地分担上下文访问压力。DCP 把上下文维度也纳入并行，把一个请求的历史状态分散到多个设备上处理，让长上下文解码能够同时利用更多 GPU 的带宽和计算资源。

Kimi-K3 的另一个重点是融合 FlashKDA 的 Prefill 与 Decode kernel。新模型不断引入更复杂的注意力或状态更新结构，通用 kernel 很容易在 kernel launch、读写中间 Tensor、同步等环节付出额外开销。融合 kernel 的做法，是尽量把连续操作压进一次 GPU 执行路径里，减少中间结果落回显存。vLLM release notes 还披露 combined all-gathers 在特定 kernel 级场景里取得 1.5～3 倍加速。这里需要保持边界：这不是“整个 Kimi-K3 推理快了三倍”，而是某些通信/内核路径的局部优化数据，但它很能说明今天的推理优化已经深入到算子和集合通信层。

更有产业价值的是 shared-expert sharding。MoE 模型通常同时存在路由专家和共享专家；共享专家如果在每张 GPU 上完整复制，会产生相当可观的显存占用。vLLM 0.28 提供可选共享专家分片，官方称特定 Kimi-K3 配置可为每张 GPU 节省约 17GiB 显存。对于几十甚至几百张 GPU 的线上服务，这类数字往往比某个 benchmark 多几分更有经济意义。每张卡少占 17GiB，可能意味着能放更大的 KV Cache、更高并发，或者减少一部分硬件。

投机解码已经从“附加功能”变成核心调度能力

0.28 对 speculative decoding 的更新也非常密集：DFlash2、DSpark confidence-scheduled verification、draft model 自动启用异步调度，以及针对 speculative scheduled input tokens 的自适应预算。Kimi-K3 的 adaptive speculative token budget 在官方测试中让 DSpark 的 TTFT 改善约 60%。同样，这个百分比对应特定配置，并不代表所有请求都能降低 60%，但它反映出推理框架已经开始动态决定“让 draft model 猜多少个 token 才划算”。

投机解码过去常被介绍成一个算法技巧：小模型先猜，大模型一次验证多个 token。进入大规模服务以后，问题远不止算法本身。Draft model 也需要 GPU 时间；猜得太少收益有限，猜得太多又会因为接受率下降而浪费计算；不同请求的 prompt、任务类型、温度、模型置信度都不同，最优 speculative budget 也不同。于是“猜几个 token”逐渐变成调度器的实时决策，而不是部署时写死的参数。

这会让推理系统越来越像数据库查询优化器。数据库不会为所有 SQL 使用同一条执行计划，而会根据表大小、索引、统计信息和资源选择 join 顺序。下一代推理框架也会根据上下文长度、模型置信度、KV Cache 命中、batch 状态、硬件拓扑和延迟目标选择执行路径。vLLM 0.28 的一些变化已经很接近这种方向。

vLLM 0.28 推理栈：调度器、Paged KV Cache、Sparse MLA 与投机解码关系示意

DeepSeek V4 的 sparse MLA 为什么需要框架“端到端支持”

DeepSeek V4 相关更新里最重要的一句，是 sparse MLA 已经可以贯穿普通 Decode、MTP 和 DSpark speculative decoding。MLA 通过压缩 Key/Value 表示降低 KV Cache 成本，Sparse MLA 又进一步减少需要参与 Attention 的历史位置。理论设计听起来很漂亮，但只优化一个 Attention kernel 没有用。模型进入投机解码以后，draft token、验证 token、MTP 状态和缓存布局都要理解同一种稀疏结构，否则一到复杂执行模式就退回通用路径。

“端到端支持”因此比“支持这个模型”更有含金量。一个模型能加载、能生成文本，只说明功能兼容；能够在普通解码、MTP、speculative decoding、ROCm、量化和分布式场景中都保持优化路径，才说明它进入了生产级支持阶段。现在模型发布速度非常快，推理框架的工作越来越像为一系列不断变化的 ISA 做编译器后端。

KV Cache 已经从显存对象变成分层存储系统

0.28 还加入磁盘 offloading、可外置 secondary tier manager、partial secondary-tier load results，以及统一 CPU layout。这部分很容易被模型新闻盖住，却可能是未来大规模长上下文服务最重要的基础设施方向之一。

100万 token 上下文、智能体长任务、代码仓库和多轮企业会话都会迅速放大 KV Cache。HBM 是最快也最贵的一层，CPU 内存便宜得多，NVMe 又更便宜但更慢。如果所有 KV 都留在 HBM，容量成本难以承受；全部扔掉又会让 Prefix Cache 和长会话复用失去意义。合理架构自然会走向 HBM—Host Memory—NVMe 甚至远端 KV Store 的多级缓存。

一旦进入分层存储，问题就和数据库 buffer pool、CPU cache hierarchy 很像：哪些块留在快层，哪些块被淘汰，远端加载能否和计算重叠，跨不同并行拓扑如何保持布局兼容，都要进入调度器。vLLM 已经不只是管理 GPU Tensor，它开始管理一个面向模型状态的数据层。

E/P/D 解耦说明推理集群开始分工

Model Runner V2 在0.28中继续推进 E/P/D disaggregation。这里的 E、P、D 可以理解为 Encoder、Prefill、Decode。多模态模型的图像编码、长文本 Prefill 和逐 token Decode 对硬件的最优利用方式差异很大，把它们永远绑定在同一进程、同一节点上未必经济。大规模部署开始尝试把阶段拆开，用不同资源池服务，再通过高速互联传递中间状态。

这种架构并非没有代价。KV Cache 和多模态 embedding 需要跨节点搬运，调度系统复杂度上升，负载比例还会动态变化。vLLM 为此补充 connector、NIXL compatibility hash、Mooncake store group semantics 等一系列看起来很“基础设施”的能力。它们共同说明一件事：推理服务正在从“几张卡跑一个模型”变成“一个分布式系统协同完成一次生成”。

对企业部署者来说，0.28最大的提醒是不要只看tokens/s

如果企业正在部署 Kimi-K3、DeepSeek V4 或类似新架构模型，升级到新推理框架很可能获得明显收益，但不能因为 release notes 里出现“3x”“60%”“17GiB”就直接套到自己的生产环境。真实收益取决于上下文长度、并发量、模型量化方式、硬件平台、Batch、Prefix Cache 命中率以及请求分布。最可靠的方法仍然是用自己的 workload 做端到端基准，包括 TTFT、TPOT、单用户速度、吞吐、显存利用率和单位请求成本。

另一方面，这一版本已经足以说明推理基础设施的竞争方式发生了变化。过去框架的卖点是兼容更多模型、提供更简单API；现在真正拉开差距的是能不能快速理解新架构，并把模型结构映射到内存、通信、kernel、缓存和调度。模型团队每推出一种新的 Attention 或 MoE 结构，推理框架就要决定它在十万级并发、百万 token 上下文和多机集群里如何活下来。

从这个角度看，vLLM 0.28 的584次提交并不显得夸张。前沿大模型正在高速变化，推理框架被迫一起高速变化。未来几年，能否持续跟上模型架构演进，可能比最初的 PagedAttention 创新更考验一个开源项目的工程能力。

参考资料

分享到