vLLM v0.27.0深度解读：Kimi K3全栈支持与DeepSeek-V4性能优化

vLLM 作为当前最主流的大模型推理引擎之一，其每一次重要版本更新都牵动着整个 AI 基础设施领域的神经。近日，vLLM 正式发布 v0.27.0 版本。据官方发布说明，本次更新汇集了来自 242 位贡献者的 561 次提交，其中包括 64 位新贡献者。这一数据不仅体现了 vLLM 社区的活跃度，也预示着这是一次分量十足的迭代。

本文将从模型支持、引擎核心、硬件性能、大规模服务等维度，深入解读这次更新的关键看点。

Kimi K3全栈支持：一次版本完整落地

本次版本最引人注目的亮点，是对 Kimi K3 模型的完整全栈支持——所有相关组件在同一个版本中一次性落地。这在推理引擎的模型适配中并不常见，往往需要跨越多个版本才能逐步完善。

具体来看，Kimi K3 的支持涵盖了从底层到上层的完整链路：

• 核心层：模型文件与算子（kernels）实现，以及 AttnRes 专用算子；
• 前端层：同时提供 Python 与 Rust 两套前端支持；
• 量化与优化：接入 DeepGEMM 支持、compressed-tensors 量化检查点，以及 DSpark AR 融合；
• 架构优化：提供了一个可选项，允许对共享专家（shared expert）进行分片（sharding）而非简单复制，从而节省显存开销。

这种"一站式"的支持方式，意味着用户在版本升级后即可无缝部署 Kimi K3，无需等待后续补丁，显示出 vLLM 团队在模型适配工程化上的成熟度。

新增模型支持一览

除了 Kimi K3，本次还新增了对多个模型的支持，覆盖文本、多模态与嵌入等多种场景：

• Qwen3.5 系列，包括纯文本的 dense 模型与 MoE 模型，并支持 EVS 视频 token 剪枝；
• K-EXAONE-2.0-750B-A37B 大规模 MoE 模型；
• 通过 Transformers 建模后端支持 VaultGemma；
• 嵌入模型 jina-embeddings-v5-text-nano，采用 EuroBERT 编码器骨干。

引擎核心升级：彻底解决首请求编译卡顿

对于生产环境部署而言，推理引擎的"冷启动"体验至关重要。此前，vLLM 在处理第一个请求时常常会因即时编译（JIT）而出现明显的卡顿延迟。

v0.27.0 针对这一痛点引入了全新的 JIT warmup 基础设施，并让 runner 拥有的 Triton 算子在首个请求到来之前就完成预热，从而消除首请求的编译停顿。此外，渲染器（renderer）预热也得到了完善。这些改进将显著提升服务上线初期的响应体验。

Model Runner V2扩展至非生成式工作负载

一个重要的架构演进是 Model Runner V2（MRV2） 的能力边界大幅扩展，不再局限于传统的文本生成任务，而是覆盖了更广泛的场景：

• 支持仅编码器（encoder-only）的注意力机制；
• 支持用于嵌入（embedding）与分类（classification）的序列池化（sequence pooling）；
• 支持编码器 token 分类与 token 嵌入；
• 支持 BGE-M3 池化；
• 支持在 CPU 上运行多模态；
• 引入多层 MTP 推测器（multi-layer MTP speculator）。

这意味着 vLLM 正从一个纯粹的生成式推理引擎，逐步演进为一个能够统一处理生成、嵌入、分类等多类工作负载的通用推理平台。

KV缓存卸载体系全面升级

在 KV offloading 方面，本次更新构建了更完善的分层缓存体系，包括通用的 P2P 二级存储层、按请求的分层过滤（TierFilter/TierMatcher）、可插拔的淘汰策略（CachePolicyFactory），以及针对 MLA KV 的去重与单副本布局优化。这些改进对于长上下文、高并发场景下的显存与内存效率提升具有实际意义。

JIT（Just-In-Time）编译是指在程序运行时才将代码编译为机器码，而非提前完成编译。vLLM 大量依赖 Triton——一种专为 GPU 算子编写设计的领域特定语言——其算子在首次被调用时才会触发编译，耗时可能长达数十秒。这对在线服务场景影响尤为明显：第一个真实用户请求往往会遭遇异常长的响应时间，严重时会触发客户端超时。Warmup（预热）机制的核心思路是在服务启动阶段、正式接受流量之前，用虚拟输入主动触发一遍所有算子的编译与缓存，使后续真实请求直接命中已编译的内核，从而消除延迟抖动。

KV（Key-Value）缓存是 Transformer 注意力机制中的核心数据结构，用于存储每个 token 在各层生成的键向量和值向量，避免自回归解码时的重复计算。KV offloading 指将 GPU 显存中暂时不活跃的 KV 缓存迁移到 CPU 内存甚至 NVMe 存储，以支持更长的上下文或更高的并发数。分层缓存（Tiered Cache）体系则进一步将这一思路系统化：通过 P2P 二级存储层、可插拔淘汰策略等机制，在 GPU 显存、CPU 内存、外部存储之间动态调度缓存数据，兼顾访问速度与容量。MLA（Multi-head Latent Attention）是 DeepSeek 系列模型采用的低秩 KV 压缩注意力变体，其 KV 结构与标准 MHA 不同，因此需要专门的去重与布局优化。

DeepSeek-V4深度性能优化与硬件适配

性能优化历来是 vLLM 版本更新的重头戏，而本次的焦点之一是 DeepSeek-V4 的一系列性能突破。官方发布说明中列举了大量具体的性能数据：

• 序列并行（sequence parallelism）支持；
• 通过跳过空的 c128 启动，实现约 2 倍的算子提升；
• 在解码阶段跳过不必要的 topk/router，带来 3.4% 的端到端 TTFT（首 token 时延）改善；
• 工作空间复用带来 3.9% 的端到端 TTFT 提升；
• 移除冗余的完整算子，实现 1.88 倍算子提升；
• 自适应 topk 宽度带来 1.0% 的端到端提升；
• 在 PP 缓冲区节省 448 MiB 显存。

这些看似零散的微优化，累积起来将为大规模部署 DeepSeek-V4 的用户带来可观的成本与延迟收益。

FlashAttention 4集成与下一代硬件布局

FlashAttention 4 在 SM100 上的集成进一步加深，新增了 FP8 KV 缓存支持与 headdim-256 支持。同时，vLLM 也在积极布局下一代硬件：

• 为 NVIDIA Rubin 架构启用 sm_107 目标，并在 SM107 上提供 NVLink all-reduce 路径；
• 启用 ROCm gfx1250 架构，持续加强对 AMD 生态的支持。

此外，CPU 端也有诸多进展，包括为 Arm CPU 提供 INT8 融合 MoE 算子、s390x 平台的 oneDNN INT8 GEMM 优化等，进一步拓宽了 vLLM 的部署边界。

FlashAttention 是一种以 IO 感知（IO-Aware）方式重写注意力计算的算法，通过分块（tiling）技术减少 HBM 显存读写次数，在保持数学等价的前提下大幅降低注意力计算的内存带宽瓶颈。FlashAttention 4 是其最新迭代，针对 NVIDIA Hopper（SM90）及以上架构的 Tensor Core 与异步流水线特性进行了深度适配，并引入 FP8 精度支持以进一步提升吞吐。NVIDIA Rubin 是 Hopper 之后的下一代 GPU 微架构，对应 SM107 架构标识；SM100 则对应 Blackwell 架构。提前为新架构启用编译目标（sm_107）意味着 vLLM 用户在 Rubin GPU 上线时可以立即获得原生性能，而无需等待引擎层面的额外适配工作。

大规模服务能力与Rust前端持续演进

面向企业级大规模部署，v0.27.0 引入了一个（简化版的）容错框架，专为 DP+EP 外部负载均衡器部署场景设计，同时为弹性 EP 扩展提供了异步准备能力。这标志着 vLLM 在服务韧性（resilience）方面迈出了重要一步。

在分离式（disaggregation）部署方面，本次针对混合模型（如 MLA+SSM）提供了 NIXL P/D 支持，以及异构 P/D 块大小、MoRIIO 异构 TP↔DP 预填充/解码读取路由等能力。

值得关注的是 Rust 前端的持续壮大。本次为其增加了完整的 gRPC 控制平面，包括引擎感知的健康上报、中止控制、服务与模型发现、KV 事件源发现等。同时，vllm-bench 被整合进了 vllm CLI，用户可以选择性地将 vllm bench serve 委托给 Rust 实现执行。这一系列举措显示出 vLLM 正在用 Rust 重构其性能敏感的服务层组件。

DP+EP 是大规模 MoE 模型部署中的并行策略组合：DP（Data Parallelism，数据并行）将不同请求分配到不同的模型副本，EP（Expert Parallelism，专家并行）则将 MoE 层中的不同专家分布在不同 GPU 上，两者结合可在超大集群上高效利用算力。P/D 分离（Prefill/Decode Disaggregation）是一种将首次填充阶段（处理输入 prompt）与逐 token 解码阶段分配到不同硬件节点的部署架构，目的是针对两个阶段截然不同的计算特征进行独立优化，从而同时提升吞吐量与延迟表现。NIXL 是 NVIDIA 推出的跨节点张量传输库，专为 P/D 分离场景中高效传递 KV 缓存而设计。

依赖升级注意事项：PyTorch 2.13破坏性变更

最后需要特别提醒开发者注意的是，本次版本进行了 PyTorch 2.13.0 升级，同时搭配 torchvision 0.28.0 与 Triton 3.7.1。官方明确指出，这是一次破坏性的环境变更。XPU 与 CPU 平台也同步跟进至 torch 2.13。

此外，Transformers 升级至 5.14.1，FlashInfer 更新至 0.6.16.post3，NCCL 升级至 2.30.7（从而在官方镜像中启用 DeepEPv2）。计划升级的团队应仔细评估依赖变化对现有环境的影响，做好兼容性测试。

总结

vLLM v0.27.0 是一次内容极其丰富的更新。从 Kimi K3 的全栈一次性落地，到 Model Runner V2 向非生成式任务的扩展；从 DeepSeek-V4 的深度性能打磨，到面向 Rubin 等下一代硬件的前瞻布局；再到 Rust 前端的持续演进——这些方向共同勾勒出 vLLM 从"高性能推理引擎"向"通用、韧性、跨硬件的推理基础设施"演进的清晰轨迹。对于依赖 vLLM 构建 AI 服务的团队而言，这是一个值得认真评估并规划升级的版本。