vLLM v0.27.0：Kimi K3 全栈一次落地，PyTorch 升到 2.13，并为英伟达 Rubin 开出 sm_107 编译目标

发生了什么

8 月 10 日，开源推理引擎 vLLM 发布 v0.27.0。官方发布说明给出的规模是：561 次提交，来自 242 位贡献者，其中 64 位是新人。这是一次典型的「上游模型一动，推理层跟着重排」的版本。

这一版最值得看的几件事

1. Kimi K3 一次性全栈落地。 这不是常见的「先合模型定义、后面慢慢补算子」，而是核心模型文件与算子、Python 前端、Rust 前端、AttnRes 算子、DeepGEMM 支持、compressed-tensors 量化检查点、DSpark AR 融合，以及一个可选项——把共享专家做分片而不是复制——在同一个版本里全部合入。对 Moonshot 这套 2.8 万亿参数量级的 MoE 来说，能否被主流推理引擎当天跑起来，直接决定它的实际可用范围。

2. 新模型批量进场。 除 Kimi K3 外，本版还加入 Qwen3.5 纯文本稠密与 MoE 版本（并带 EVS 视频 token 剪枝）、K-EXAONE-2.0-750B-A37B、通过 Transformers 建模后端接入的 VaultGemma，以及 jina-embeddings-v5-text-nano。

3. PyTorch 2.13 升级，属破坏性环境变更。 同时升 torchvision 0.28.0、Triton 3.7.1；XPU 与 CPU 后端也一并跟到 torch 2.13。要升级的团队需要先算清楚依赖账。

4. FlashAttention 4 在 SM100 上继续加深。 新增 FP8 KV cache 支持与 headdim-256 支持，并配套一套新的 JIT 预热基础设施和 runner 自持的 Triton 算子预热，用来消掉首个请求的编译卡顿。

5. DeepSeek-V4 的性能优化被拆得很细。 官方列出的口径包括：序列并行；跳过空的 c128 kernel 启动带来约 2 倍算子提升；跳过不必要的 topk/router 带来 3.4% 端到端 TTFT 改善；工作区复用再带来 3.9% 端到端 TTFT；移除一个冗余的 full kernel 带来 1.88 倍算子提升；自适应 topk 宽度带来 1.0% 端到端提升；PP 缓冲区省下 448 MiB 显存。这些数字均为 vLLM 官方发布说明中的自测口径，未标注统一测试环境，横向比较需谨慎。

6. 面向下一代硬件的提前布局。 新增针对英伟达 Rubin 的 sm_107 编译目标，并在 SM107 上打通 NVLink all-reduce 路径；同时启用了 ROCm gfx1250 架构。

7. Rust 前端长出 gRPC 控制面。 包括引擎侧健康上报、中止控制、服务与模型发现、KV 事件源发现，并把 vllm-bench 并进 vllm CLI。

此外，Model Runner V2 从生成式扩展到非生成式负载（encoder-only 注意力、embedding/分类的序列池化、encoder token 分类与 token embedding、BGE-M3 池化、CPU 多模态、多层 MTP 投机解码），大规模服务侧则新增了面向 DP+EP 外部负载均衡部署的（简化版）容错框架，以及为弹性 EP 扩缩做的异步准备。

为什么重要

推理引擎的版本说明，往往比模型厂商的发布会更能反映真实的产业排序：谁的模型被优先做全栈支持、谁的芯片被提前开编译目标、哪一代 attention 内核在被认真优化。

这一版里同时出现了 Kimi K3 的全栈支持和 Rubin 的 sm_107 目标——一边是中国开权重模型进入主流推理栈的默认选项，一边是英伟达下一代硬件在软件侧提前落位。中间那层，是 FlashAttention 4、DeepSeek-V4 优化和 Model Runner V2 这些不太上头条、却决定每 token 成本的工程活。

---

信息来源：vLLM v0.27.0 官方 GitHub Release 说明（一手，2026-08-10 发布）。文中性能数字均为该发布说明列出的官方自测口径，未经第三方复现，不同硬件与负载下结果会有差异。