vLLM v0.28.0：内核提速3倍是真的，但别当成整机提速来用

vLLM v0.28.0 这次合并了584次提交，来自270名贡献者，其中76人是第一次给这个项目提交代码。数字不是重点，方向才是——这一版把Kimi-K3、DeepSeek V4的推理优化做成了官方内置能力，同时把E/P/D解耦、分层KV缓存这些原本只在论文里讨论的服务化功能，一次性铺进了主库。

对做大模型推理的人来说，这版更新里最容易被误读的，恰恰是官方给出的那几个性能数字。1.5到3倍的内核提速、约60%的首字延迟改善、约17GiB的显存节省，听起来像整机提速，但每一个都挂着具体的模型、模式和配置前提。套错场景，数字就是空的。

Kimi-K3三个数字，三个前提

这一版围绕Kimi-K3做了一整套优化：解码上下文并行、融合FlashKDA解码/预填充内核、GEMM-RS序列并行，还上了ROCm的V2模型运行时适配。官方给出的三个数字，都值得记，但更值得记的是前提。

DeepSeek V4在同一批更新里，稀疏MLA跑通了普通解码、MTP、DSpark投机解码三条路径。AMD Quark NVFP4支持、ROCm gfx11/gfx950适配也一起进来了。vLLM正在把这两家模型的推理特化，一步步做成官方内置能力，而不是靠外部插件缝合。

服务化能力铺开：从单卡推理到分布式调度

Model Runner V2加了E/P/D（Encode/Prefill/Decode）解耦、权重卸载、多层MTP KV缓存支持。分层KV缓存进一步支持磁盘卸载，还开放了module_path接口，让第三方接入自己的二级缓存管理器。

Rust前端和gRPC能力也在扩：多模态图片推理走gRPC、显式数据并行路由、protobuf schema发到Buf公开托管。这些都不是模型层面的优化，是服务编排层的功能。说明vLLM要解决的问题，已经从"单卡怎么推理更快"，变成"一整套分布式服务怎么调度"。

硬件适配也在同步铺开：NVIDIA、AMD ROCm、Intel XPU、CPU都有专属内核，CPU端第一次能跑起DeepSeek-V2/V3。但适配进度并不齐——NVIDIA这条线的优化密度明显高于AMD和CPU，"多硬件部署"目前更像是起步，而不是齐头并进。

默认变更vs破坏性变更：升级前先看这张表

顺手改的几处默认值，多半是升级完自动变快；但有几处依赖调整，升级完要先改代码。

两类人，各自要做什么

如果你是推理工程师，服务跑在Kimi-K3或DeepSeek V4上，这波优化是实打实的红利。但先做一件事：对照release note里具体的内核名字和投机解码配置，确认自己的部署命中了那几个前提。看到"3倍"就直接搬去生产，是最容易踩的坑。

如果你是平台团队，负责升级和硬件选型，升级前先过一遍依赖清单。bitsandbytes迁出主库，意味着要单独装插件包；Transformers升到5.15.0，可能和现有其他依赖打架。用了E/P/D解耦或分层KV缓存这类新拓扑的团队，故障链路变长，建议先在灰度环境跑一轮完整推理链路测试，再决定是否全量升级。

我的判断

这版真正的信号，不是内核跑得多快，是vLLM自己的角色在变。E/P/D解耦、跨层KV缓存、Rust/gRPC前端，加起来说明vLLM想覆盖的范围，已经从单卡推理引擎，扩到一整套分布式服务的调度层。

但270个贡献者里76个是新人，扩张速度快，不等于治理成熟度高。几百个提交堆出来的版本，和"稳定可信赖"之间，还有一段没写进release note的距离。《论语》讲"欲速则不达"，放在这版更新上也合适：功能堆得快，适配和维护的债务也堆得快。

接下来该盯的，是bitsandbytes的外部插件生态能不能接得住，以及AMD、Intel、CPU这几条硬件线的内核适配速度能不能追上NVIDIA。如果只有NVIDIA这条线跑得快，"多硬件部署"现在还只是半句话。