vLLM 中的 Kimi K3：针对 NVIDIA GB300 的专用 CuTe DSL 解码，速度达到 842 tokens/s
vLLM 为 Kimi K3 发布了一条新的解码路径，该路径用针对 NVIDIA GB300 调优的定制 CuTe DSL 内核替换了模型几乎所有的解码操作，在 16 块 GB300 GPU 上、batch 1 时达到 每秒 842 个 token，并配合 DSpark 推测解码——比相同配置下的标准 vLLM 快 1.73 倍。这篇文章还介绍了这项工作背后的流程变更：一个提议的“快速通道模型优化 RFC”（vllm-project/vllm issue #59665），该 RFC 用隔离、有界范围、系统性正确性验证和可复现的性能证据取代了逐行人工审查。
该贡献针对 NVIDIA Blackwell GPU，支持 8 或 16 块 GPU，解码 batch 从 1 到 64，并支持长上下文的可选解码上下文并行。这些 GPU 共享一个支持多播的 NVLink 域。Kimi K3 的 pull request 是 vllm-project/vllm #61867。
Kimi K3 解码路径：每层 13 个内核，而不是 23 个
专用解码路径将 Kimi K3 解码步骤中的几乎所有操作融合并替换为定制的 CuTe DSL 内核。按层测量，标准 vLLM 使用 130 微秒和 23 个内核，而专用解码路径使用 69 微秒和 13 个内核。
这项优化工作由智能体辅助完成：编码智能体被用来编写复杂的 GPU 内核、执行跨算子融合、将计算与通信重叠，并跨 batch 大小和 GPU 配置调整执行。生成的路径覆盖了 8 或 16 块 GPU 上的注意力、MoE 和通信。
1. 针对工作负载调整内核形状
不同的解码 batch 大小需要不同的内核选择。对于注意力输入投影，Kimi K3 路径在 batch 大小为 1–2 时使用专用的小矩阵内核，在较大 batch 时使用 split-K 内核，后者将矩阵乘法分配到更多 GPU worker 上。这些投影经过调优，以启动大小合适的内核，充分利用 GPU 资源，并尽可能重叠内存读取、通信和计算。
KDA 也使用优化的 CuTe DSL 解码内核，其调度根据每个 GPU 上的 batch 大小和注意力头数量进行调整。
对于长上下文，解码上下文并行（DCP）将 KV 缓存拆分到多个 GPU 上。每个 GPU 计算其本地部分的注意力，一个调优的融合内核将部分结果与 v-proj 和门控组合起来。
2. 重叠计算和通信
Kimi K3 路径将注意力输出投影直接融合到其 all-reduce 和随后的注意力残差计算中。GPU 内核将部分结果发布到 NVLink 可访问的缓冲区，接收内核组合它们并继续计算。一些小型 batch 配置将生产者和消费者融合到单个内核中。数据交换使用无栅栏方法，开销最小。
在较大 batch 时，实现切换到两阶段归约：GPU 首先组合输出的指定部分，然后分发结果。这减少了 GPU 之间的数据移动。
3. 改进 MoE 调度和重叠
尽管专家已经使用张量并行，但基线在每个 GPU 上计算完整的路由器分数和潜在输入投影。Kimi K3 路径将这些计算拆分到 TP 秩上，并将每个秩的份额组合到一个矩阵乘法中。GPU 通过 NVLink 交换结果。这减少了重复计算、权重读取和专家执行前的内核启动。
共享专家在单独的流上运行。其工作与路由或路由专家计算重叠，具体取决于配置。调度控制每个操作使用多少 GPU 资源，并经过调优以平衡并行性而不产生争用。实现细节位于 experts_runtime.py 中。
4. 预取即将使用的权重到缓存中
小 batch 推理通常是内存受限的：受限于从内存加载权重的速度。某些阶段无法充分利用可用的内存带宽，例如通信。在通信运行时，侧流上的专用内核预取下一个操作的权重，这样当通信完成时，这些权重具有更高的缓存命中率。
为什么智能体优化的推理代码超越了人工审查
智能体优化的推理代码正在超越 vLLM 的审查和维护工作流程。手动理解每个内核的每一行、映射潜在问题并测试每个支持的配置非常耗时；跳过这项工作可能会发布有缺陷的软件，从而在生产中失败。
提议的快速通道 RFC 通过改变性能工作的组织方式来解决这个问题：除了智能体优化之外，vLLM 还希望有自动验证可靠性和性能的系统，以及通过设计强制隔离和风险最小化的软件结构。所述指导原则是在管理风险的同时减少审查负担。
我们的指导原则是在管理_风险_的同时减少审查负担。
该方法基于四个原则。
原则 1：隔离更改
特定于模型的优化保持在模型的代码内。这使得受影响的路径更容易识别，并减少了审查者必须考虑的爆炸半径。隔离还必须在运行时成立：审查者应该能够跟踪优化路径何时被选择、它改变了什么状态，以及执行如何返回到标准路径。
隔离有意排除了一些优化。输入准备、采样和 KV 缓存管理可能导致隔离排除的开销。这在很大程度上是有意的：这些组件在大多数 vLLM 部署中是共享的，为了优化特定工作负载而更改它们可能会破坏数十个其他稳定的 vLLM 配置。对这些组件的工作应该比快速通道允许的更密切地涉及核心维护者。
原则 2：限定范围，但保留用户的功能
优化不需要改进每个部署才有用。它可以针对特定的 GPU、并行设置或 batch 大小范围。清晰的边界使工作更容易调优，并定义了一组要验证的配置。
对于 Kimi K3，初始硬件验证涵盖 GB300 上的 TP8 和 TP16、最多 64 的解码 batch、各种草稿长度的推测解码，以及一个 NVLink 域内的解码上下文并行配置。
这些边界描述了优化的适用范围，但它们不会削减功能覆盖。生产部署需要使端点有用的基本功能。诸如全上下文服务、温度采样和结构化输出等功能不能被“优化掉”或“选择退出”；它们是一流的服务功能，属于验证计划的一部分，与内核形状和数值检查并列。
原则 3：验证正确性
内核测试和模型评估回答不同的问题。内核测试检查跨形状和输入值的数值结果。模型评估检查完整执行路径是否保留了模型的答案。两者都是必需的。
测试必须实际执行更改后的代码。小 batch 优化需要在小 batch 下进行评估。注意力内核更改需要长上下文覆盖。静默使用标准路径的测试对优化提供的证据很少，并被描述为一个常见陷阱。
Kimi K3 的开发说明了为什么这很重要。一次审计发现编译器将激活读取移到了同步等待之前；修复将该加载类型限制为静态权重。此类错误可能通过简单的功能检查而存活，需要有针对性的调查。
长上下文和长生成评估（如 MRCR 和 AIME25）也暴露了注意力和通信内核中的敏感数值问题，这些问题在使用模拟输入和/或一致的启动时序的独立内核测试中无法复现。
原则 4：广泛检查性能
一个头条加速是一个起点。验证必须显示更改在其影响的工作负载上的行为，这意味着扫描 batch 大小、上下文长度和支持的并行配置。MoE 测量应包括真实提示，因为专家选择会影响读取哪些权重以及可以重用多少工作。纯解码结果应与混合预填充和解码的工作负载区分开来。
可靠的验证需要 GPU 时间。相关的 Bring-Your-Own-GPU 评估 RFC（vllm-project/vllm issue #61698）提议了贡献者可以在自己的硬件上运行的标准评估镜像。可复现的结果包和与 GitHub PR 关联的提交将使证据更容易获取。不同的评估层级和共享的社区计算将扩大覆盖范围，同时管理 GPU 需求并减少对项目资助 CI 的压力。
性能结果
使用 DSpark 的解码性能
使用 DSpark，Kimi K3 在受控的 AL=6 基准测试中，在 16 块 NVIDIA GB300 GPU 上达到 每秒 842 个 token。这比相同推测解码设置下的标准 vLLM 快 1.73 倍，后者测得 488 tokens/s。
设置：TP16，DSpark 使用七个草稿 token，合成接受长度为 6，DL=7，ISL=1，OSL=1k，batch 大小为 1。TPS 衡量聚合解码吞吐量，不包括预填充。
无推测的解码性能
改进覆盖了测试的 batch 范围。TP16 在 batch 16–64 时保持 1.62–1.71 倍的增益，而 TP8 在相同范围内提供 1.31–1.43 倍。
| Batch 大小 | TP8 tokens/s | TP8 加速 | TP16 tokens/s | TP16 加速 |
|---|---|---|---|---|
| 1 | 193.3 | 1.58× | 256.4 | 1.88× |
| 2 | 317.8 | 1.50× | 436.7 | 1.92× |
| 4 | 540.6 | 1.55× | 702.5 | 1.81× |
| 8 | 820.1 | 1.45× | 1,157.9 | 1.79× |
| 16 | 1,274.8 | 1.43× | 1,758.3 | 1.71× |
| 32 | 1,702.6 | 1.33× | 2,550.9 | 1.64× |
| 64 | 2,375.9 | 1.31× | 3,606.1 | 1.62× |
这些数字没有推测解码。吞吐量是整个 TP 组的。
AgentX 上的改进
优化的 Kimi K3 实现在 AgentX 上、并发度为 1 时提供 1.8 倍更高的 P90 交互性：403.2 对比 223.7 tokens/s/user。这比较了 16 块 GB300 GPU 上的优化运行与早期 vLLM 在 8 块 GB300 GPU 上的结果。
AgentX 重放真实编码智能体会话的流量模式，包括长上下文、多轮对话、工具暂停、并行子智能体和 KV 缓存重用。它保留这些工作负载模式，同时用合成文本替换私有内容，在真实智能体流量下测试服务系统。
下一步
DeepSeek-V4.1-Flash
DeepSeek-V4.1-Flash（vllm-project/vllm PR #61868）遵循 Kimi K3 的设计模式。在相同的可选 decode_backend: latency_specialized 开关后面，该实现支持最多 64 个并发请求、预填充和混合 batch 的无缝回退，以及推测解码。该执行器不是追逐单个热点，而是削减内核和主机工作：它在每个子层边界融合 all-reduce + mHC，用为低延迟构建的 CuTe DSL 内核替换大 batch MoE 和 GEMM，对索引器的工作进行去重和分片，并将标准 vLLM 在 CPU 上急切运行的每步工作重放为 CUDA 图。DeepSeek AgentX 结果在四块 GB300 GPU 上报告。
Muse Spark Open
在 Meta 发布 Muse Spark Open 的两天内，vLLM 的早期结果已经超过 每秒 950 个 token 每用户，使用七个草稿 token（K=7）和接受长度为六（AL=6）。更多优化正在进行中。
GLM5.3
vLLM 还发布了类似机制，以优化 GLM5.3 在低并发场景下的解码延迟。优化细节和性能结果将在单独的文章中发布。
对于每项贡献，vLLM 表示将继续关注具体的性能提升、生产功能支持以及可复现的正确性和性能检查。
致谢
vLLM 感谢 Rohan Varma（NVIDIA）和 Alex Steiner（NVIDIA）对这项工作的贡献，以及 Woosuk Kwon（Inferact）、Michael Goin 和 Lucas Wilkinson（Red Hat）对模型重构以及他们的反馈和支持。