大模型推理最昂贵的部分，越来越不是“把模型装进GPU”这一瞬间，而是如何长期保存不断增长的会话状态。vLLM 0.28一次合入584次提交，来自270名贡献者，其中76人首次参与。版本的核心变化也从单个算子提速扩大到整套生产底座：KV缓存可以分层卸载到磁盘，模型执行器V2继续成熟，Rust前端与gRPC开始承接更大规模的服务入口。

磁盘成为第三层，不是为了让慢存储取代显存

长对话和Agent任务会持续生成KV缓存。只放GPU最快，却最昂贵；移到CPU内存能换取容量，但仍受单机内存限制。0.28在已有CPU卸载基础上加入磁盘层，并允许通过module_path挂载树外的二级存储管理器，同时补上部分加载结果、分层指标和统一CPU布局。这使企业可以把热点会话留在高层、冷会话下沉，再按请求恢复。

关键不是“磁盘无限大”，而是命中率与恢复成本。若Agent频繁唤醒已经下沉的长会话，磁盘读放大会拖高首Token延迟；若淘汰策略过于保守，又节省不了显存。生产团队需要把缓存命中率、下沉字节、恢复延迟、会话存活时间和磁盘写放大一起监控。vLLM提供了组件和指标，但不会替企业自动找到最佳分层策略。

Kimi与DeepSeek优化显示，通用引擎正在模型化

0.28为Kimi-K3加入解码上下文并行、FlashKDA融合内核、MegaMoE激活优化与自适应投机预算。项目给出的单项数据包括合并All-Gather带来1.5至3倍内核级提速、自适应预算让DSpark首Token时间改善约60%，以及共享专家切分每张GPU节省约17GiB内存。DeepSeek V4则让稀疏MLA覆盖普通解码、MTP和DSpark投机解码，并扩展ROCm支持。

这些数字来自特定内核和配置，不能直接当作整套业务吞吐提升。但方向很清楚：推理引擎不再只做通用批处理，而要理解不同模型的注意力、专家路由和投机解码结构。企业选择模型时，也必须同步验证引擎版本；同一权重在不同后端上的延迟、显存和稳定性可能相差很大。

Model Runner V2与Rust前端瞄准的是规模化服务

Model Runner V2新增编码、预填充与解码拆分、权重卸载、多层MTP缓存和编码器CUDA Graph等能力。Rust前端则加入独立渲染器、多模态图片gRPC、显式数据并行路由与强化学习生命周期控制。这些看似分散的功能共同指向一个问题：当推理服务跨节点、跨硬件并承载多模态请求时，Python入口与单体执行路径会成为新的控制面瓶颈。

但新架构仍在成熟期，0.28同时调整批处理Token默认值、Mamba前缀缓存和Blackwell图捕获上限。bitsandbytes迁出核心仓库，旧KV量化参数和部分输出字段被移除。FDE若直接滚动升级，最容易在镜像、解析器、量化和监控指标上踩坑。

编辑判断：先把它当成基础设施迁移，而非普通依赖更新

vLLM 0.28的价值在于把内存容量、模型特化和服务控制面同时向前推了一步。真正适合企业的升级方式，是复制线上流量做影子测试，分别比较首Token延迟、输出吞吐、KV命中率、磁盘恢复尾延迟、错误码和单位任务成本；再对CUDA、ROCm、CPU与XPU镜像逐项验收。只有这些指标稳定，磁盘分层才是容量杠杆，而不是新的延迟黑盒。

还要单独验证安全变化。新版修复了利用伪造采样率绕过音频时长限制的拒绝服务问题，并提醒API密钥并不能保护所有端点。暴露在企业网络中的推理网关应由反向代理完成统一认证、请求大小限制和速率控制，不能把引擎自带参数当成完整安全边界。