vLLM 0.28 不只是支持新模型，推理引擎正在变成分层存储系统

作者：林岚｜OC 开发者生态编辑

vLLM 0.28.0 合入 584 次提交，来自 270 位贡献者，其中 76 位是首次贡献。版本说明看起来像一张很长的模型支持清单，但真正改变部署方式的主线，是执行阶段拆分、权重卸载和分层 KV 缓存开始同时进入一套推理系统。

一句话结论：vLLM 正从“让 GPU 更高效地吐 token”的服务器，变成一套在计算、显存、主存、磁盘和网络之间安排模型状态的运行时。

新版本继续优化 Kimi K3 和 DeepSeek V4，包括解码上下文并行、融合内核以及面向序列并行的通信方案。Model Runner V2 则推进 E/P/D 分离，也就是把嵌入、预填充和解码阶段按资源特征拆开。预填充更吃计算，解码更受显存带宽和批处理调度影响；把它们分离后，服务商可以独立扩缩容，而不是为最坏情况整套复制实例。

另一个关键变化是权重卸载与多层 KV 缓存。大模型服务的显存不只放参数，还要保存每个会话已经计算过的注意力状态。长上下文和大量并发会让 KV Cache 很快吞掉容量。vLLM 0.28 增加把缓存卸载到磁盘的分层能力，意味着冷会话不必永久占据最昂贵的 GPU 显存，但恢复时会付出 I/O 延迟。

所以“支持磁盘缓存”不是免费的容量魔法。运营者要确定什么数据留在 GPU、什么下沉到主存或本地盘，以及何时预取回来。热度判断错误，会把省下的显存变成尾延迟；磁盘吞吐不足，也会让长会话恢复卡住。监控指标需要从 tokens/s 扩展到各层命中率、迁移字节数和恢复延迟。

0.28 还推进 speculative decoding，扩展 NVIDIA、AMD ROCm、Intel XPU 和 CPU 支持，并加入 Rust API 前端、gRPC 多模态推理与安全修复。广泛硬件支持很重要，但也增加测试矩阵：同一个模型在不同后端上能启动，不代表数值、吞吐和显存峰值完全一致。

对自建推理的团队，这个版本值得升级前做专项压测。至少要覆盖长短请求混跑、缓存下沉与恢复、prefill/decode 节点故障、模型热切换和多租户隔离。vLLM 的功能越像分布式数据库，运维方法也越不能停留在“进程起来、接口返回 200”。

关键事实

• 来源：vLLM GitHub 0.28.0 发布说明与官方文档
• 核心技术：E/P/D 分离、权重卸载、分层 KV Cache、推测解码
• 硬件范围：NVIDIA、AMD ROCm、Intel XPU、CPU
• 社区规模：584 次提交、270 位贡献者、76 位首次贡献者

OC 判断

推理优化的下一阶段不是再挤出一个漂亮的单卡数字，而是管理不同成本和速度的状态层。vLLM 0.28 把这条路线说得很清楚：模型服务正在获得数据库式的分层存储与调度问题。收益很真实，复杂度也很真实。

为什么重要

• 对开发者：新模型能更快进入统一服务层，但升级必须验证 API 与数值兼容。
• 对平台团队：容量规划要同时考虑显存、主存、磁盘和网络，而非只数 GPU。
• 对行业：开源推理引擎正在承担越来越多云厂商内部运行时才有的职责。

参考来源

• vLLM 0.28.0 发布说明
• vLLM 0.28.0 服务命令文档