vLLM v0.27.0：561 次提交，一个版本内为 Kimi K3 落齐整条推理栈

一个版本内落齐一条模型支持路径

这一版最值得看的不是数量，而是 Kimi K3 的支持是一次性落全的：核心模型文件与内核、Python 前端、Rust 前端、AttnRes 内核、DeepGEMM 支持、compressed-tensors 量化检查点、DSpark AR 融合，以及一个把共享专家分片而不是复制的选项。

对照本站《模型与推理引擎的支持路径》的四级判据，这不是「能加载」，而是直接落到有性能路径那一级。Kimi K3 是 07-16 在本站发布过的信号，当时的悬念正是开放权重到位之后、自托管栈多久能真正跑起来——答案是不到一个月。

破坏性变更要单独看

PyTorch 升到 2.13.0（配 torchvision 0.28.0、Triton 3.7.1），发布说明自己标注这是破坏性环境变更，XPU 与 CPU 路径随后跟上。升级窗口需要单独排期，不能当作普通小版本。

消除首个请求的编译停顿

FlashAttention 4 在 SM100 上加深集成：FP8 KV 缓存、headdim-256。配套的是新的 JIT 预热基础设施与 runner 自己持有的 Triton 内核预热——目的很具体：把首个请求的编译停顿去掉。

这是容量规划里经常被忽略的一段：冷启动那一次的首字延迟，和稳态吞吐是两个数。

性能改动写成了可核对的数字

DeepSeek-V4 这一路的优化没有笼统说「更快了」，而是逐项列出：

• 跳过空的 c128 启动带来约 2 倍内核提升
• 跳过不必要的 topk / router，端到端首字延迟 3.4%
• 工作区复用，端到端首字延迟 3.9%
• 移除一个冗余的完整内核，1.88 倍内核提升
• PP 缓冲区省下 448 MiB 显存

每一项都写明了是内核层还是端到端——这正是判断一个性能数字能不能横比的关键。

服务形态也在变

• Model Runner V2 扩到非生成式负载：仅编码器注意力、用于嵌入与分类的序列池化、编码器 token 分类与嵌入、CPU 上的多模态。输出是标签而不是句子的那一半负载，现在走同一个运行器。
• 面向大规模服务的韧性：为 DP+EP 外部负载均衡部署提供了（简化的）容错框架，以及弹性 EP 扩缩容的异步准备。
• Rust 前端长出了 gRPC 控制面：引擎健康上报、中止控制、服务与模型发现、KV 事件源发现。

硬件在提前铺路

sm_107 目标（NVIDIA Rubin）与 SM107 上的 NVLink all-reduce 路径已经进来，ROCm 的 gfx1250 架构也已启用。下一代硬件的支持通常比硬件本身早半年出现在推理栈里，这是判断厂商路线图的一个便宜信号。