vLLM 引入智能体辅助优化 Kimi K3，解码吞吐提升近两倍

Kimi K3 在 NVIDIA GB300 上的解码性能。

编码智能体（Coding Agents）现在能够协助解决模型优化中最棘手的部分：编写复杂的 GPU Kernel、执行跨算子融合、实现计算与通信的重叠，以及针对不同 Batch Size 和 GPU 配置进行执行调优。对于 Kimi K3，我们利用智能体辅助开发，在 NVIDIA GB300 上构建了一条统一的 CuTe DSL 解码路径，涵盖了注意力机制、MoE 以及跨 8 或 16 张 GPU 的通信。这些优化措施带来了显著的性能提升：在配备 DSpark（合成序列长度 AL=6）的 16 张 NVIDIA GB300 GPU 上，Batch Size 为 1 时的吞吐量超过 840 tokens/s；在多个测试配置中，解码吞吐量提升了 1.5–2 倍；在 AgentX 工作负载上，P90 交互延迟降低了最高达 1.8 倍。

经过智能体优化的推理代码生成速度已超过了我们的审查和维护流程。手动审查过程需要理解每个 Kernel 的每一行代码、梳理潜在问题并测试所有支持的配置，这是一项极其耗时的工作。另一方面，如果省略这些步骤，我们就面临发布存在缺陷的软件的风险，这可能导致生产环境中的故障。

要实现这两个目标，路径清晰可见：我们需要改变组织性能工作的方法。除了智能体优化之外，我们还需要设计能够自动验证可靠性和性能的系统，并通过架构设计来强制实施隔离和风险最小化。

提出的 快速通道模型优化 RFC 为此方法奠定了基础。我们的指导原则是在管理风险的同时减轻审查负担。为此，我们采取以下措施：

1. 隔离变更。 将优化限制在模型自身的代码范围内。
2. 界定范围，保留核心功能。 明确支持的硬件和工作负载，同时保留生产级 LLM 使用所必需的核心功能。
3. 系统化验证正确性。 运行既定的性能和正确性基准测试套件，以确保完整性和可靠性，并确保在所有支持的配置上性能均有严格提升。
4. 扩展验证规模。 允许贡献者在自己的 GPU 上运行标准评估，并在请求维护者关注之前分享可复现的结果。

Kimi K3 是我们基于该方法的首个贡献。本文将介绍我们如何优化 Kimi K3，如何建立信心以发布并维护这些优化，以及最终的性能结果。

目录

• 第一部分：优化 Kimi K3
• 第二部分：快速且负责任地推进
• 第三部分：性能深度解析
• 未来展望
• 致谢

第一部分：优化 Kimi K3

本次贡献为 Kimi K3 引入了一条新的解码路径，该路径通过定制化的 CuTe DSL 内核融合并替换了几乎所有操作，并针对特定子问题进行了调优。其目标硬件为配备 8 或 16 张 GPU 的 NVIDIA Blackwell 架构，支持 1 到 64 的解码批次大小，并为长上下文提供可选的解码上下文并行功能。这些 GPU 共享一个支持多播（multicast）的 NVLink 域。更多细节请参阅 PR。

Kimi K3 内核时间线：标准 vLLM 每层使用 130 微秒和 23 个内核；专用解码路径使用 69 微秒和 13 个内核。

1. 针对工作负载调整形状

不同的批次大小需要不同的内核选择。对于注意力输入投影，我们在批次大小为 1–2 时使用专门的小矩阵内核，而在较大批次时使用 split-K 内核，后者将矩阵乘法拆分到更多的 GPU 工作单元上执行。所有此类投影都经过精细调优，以确保启动合适大小的内核，从而充分利用 GPU 资源，并尽可能重叠内存读取/通信与计算工作。

KDA 同样使用了优化的 CuTe DSL 解码内核，其调度策略针对每张 GPU 上的批次大小和注意力头数进行了调优。

对于长上下文场景，解码上下文并行（DCP）将 KV 缓存拆分到多个 GPU 上。每个 GPU 计算其本地部分的注意力，并通过一个经过调优的融合内核将部分结果与 v-proj 和门控机制相结合。

2. 重叠计算与通信

我们将注意力输出投影直接与其 all-reduce 操作及随后的注意力残差计算进行融合。GPU 内核将部分结果发布到可通过 NVLink 访问的缓冲区中，接收端内核则合并这些结果并继续执行后续计算。在某些小批量配置下，生产者和消费者被融合进同一个内核中。数据交换采用无栅栏（fence-less）方式，以最小化开销。

在大批量场景下，实现方案切换为两阶段归约：GPU 首先合并各自负责的部分输出，然后分发最终结果。这种方式减少了 GPU 之间的数据传输量。

3. 优化 MoE 调度与重叠

尽管专家模块已经使用了张量并行（TP），但基线版本会在每个 GPU 上计算完整的路由器分数和潜在输入投影。我们将这些计算拆分到各个 TP rank 上，并将每个 rank 的结果合并为一次矩阵乘法。GPU 之间通过 NVLink 交换结果。这减少了专家执行开始前的重复计算、权重读取以及内核启动次数。

共享专家在独立的流（stream）上运行。根据配置不同，其工作负载会与路由计算或路由专家计算进行重叠。调度策略控制每个操作所使用的 GPU 资源数量，并经过精心调优，以确保并行度均衡且无资源争用。详细信息请参阅 experts_runtime。

4. 预取即将使用的权重至缓存

在小批量推理中，我们通常受限于内存带宽：即从内存加载权重的速度成为瓶颈。某些阶段无法充分利用可用的内存带宽，例如通信阶段：在此期间，我们可以在侧流上运行一个专用内核，以确保当通信完成时，下一个操作所需的权重具有更高的缓存命中率。

第二部分：快速且负责任地推进

Kimi K3 只是首批案例之一。我们相信社区可以共同构建这一生态，推动更多模型、GPU 和工作负载逼近“光速”性能极限。

不同的贡献者/智能体（agents）会发现不同的优化机会：可能是更优的通信调度策略，也可能是针对特定部署场景的算子融合。但如果每项贡献都基于不同的假设、不完整的测试以及难以复现的基准测试结果，那么验证和维护工作将迅速成为瓶颈，甚至可能导致我们发布存在缺陷的代码。我们需要一种通用的方法，将这些想法转化为用户可在长期生产环境中信赖的改进。

这改变了我们对智能体交付成果的要求。我们应当对智能体生成的代码在测试、验证和需求方面设定明确的预期。智能体需要构建测试用例、运行全面的评估与基准测试、调查失败原因，并记录优化生效的条件。人类审查员仍然负责评判设计思路和证据质量，但他们可以从更高层次的抽象视角入手，而不必逐行审查代码。

基于提议的 快速通道 RFC，我们将围绕以下四项原则组织这项工作。

1. 隔离变更

将模型特定的优化保留在该模型的代码内部。这使得受影响的路径更容易被识别，并缩小了审查员需要考虑的影响范围（blast-radius）。

这种隔离在运行时也必须成立。审查员应能够追踪优化路径何时被选中、它修改了哪些状态，以及执行流如何返回到标准路径。

此约束确实会排除某些优化方案：输入准备、采样和 KV 缓存管理可能会产生开销，而隔离机制排除了这些部分。这是设计上的必然结果，且在很大程度上是有意为之：这些组件在大多数 vLLM 部署中都是共享的，为了优化特定工作负载而修改它们，可能会破坏数十种其他稳定的 vLLM 配置。对这些组件的工作至关重要，且需要比快速通道所允许的更紧密地涉及核心维护人员。

2. 限定范围，但保留用户功能

一项优化无需在所有部署场景中都能带来提升才具有价值。它可以针对特定的 GPU、并行设置或批量大小范围。清晰的边界使调优工作更加容易，并为我们提供了一组明确定义的待验证配置。

对于 K3，初始硬件验证涵盖 GB300 上的 TP8 和 TP16、最大为 64 的解码批次、具有不同草稿长度的推测解码，以及单个 NVLink 域内的解码上下文并行配置。

这些边界描述了优化适用的范围，但并不意味着可以削减“功能覆盖”。生产部署需要那些使端点具备实用性的基础功能。诸如全上下文服务、温度采样和结构化输出等功能不能被“优化掉”或“选择退出”，它们是一流的服务功能，应与内核形状和数值检查一起纳入验证计划。

3. 验证正确性

内核测试和模型评估回答的是不同的问题。内核测试检查跨形状和输入值的数值结果。模型评估检查完整的执行路径是否保留了模型的输出答案。我们需要两者兼备。

测试必须实际执行被修改的代码。小批量优化需要在小批量下进行评估。注意力内核的更改需要长上下文的覆盖。那些静默使用标准路径的测试无法为优化提供多少证据，这是一个常见的陷阱。

K3 的开发过程说明了这一点的重要性。我们的审计发现编译器将激活读取移动到了同步等待之前。修复方案将该加载类型限制为静态权重。此类错误可能在简单的功能检查中幸存下来，需要针对性的调查才能发现。

此外，像 MRCR 和 AIME25 这样的长上下文和长生成评估揭示了注意力和通信内核中敏感的数值问题，这些问题在使用模拟输入和/或一致启动时间的独立内核测试中无法复现。

4. 广泛检查性能

头条加速比只是一个起点。我们还需要了解该变化在其影响的工作负载中的表现。这意味着要扫描批次大小、上下文长度和支持的并行配置。MoE 测量应包含真实提示，因为专家选择会影响读取哪些权重以及可重用多少工作。纯解码结果也应与混合预填充和解码的工作负载区分开来。

可靠的验证同样需要消耗 GPU 时间。相关的 Bring-Your-Own-GPU 评估 RFC 提议提供标准评估镜像，以便贡献者可以在自己的硬件上运行。可复现的结果包以及与 GitHub PR 关联的提交记录将使这些证据更加易于获取。不同的评估层级和共享的社区算力有助于扩大覆盖范围，同时管理 GPU 需求并减轻项目资助的 CI 压力。

第三部分：性能深度解析

使用 DSpark 的解码性能

在受控的 AL=6 基准测试中，借助 DSpark，Kimi K3 在 16 块 NVIDIA GB300 GPU 上达到了 每秒 842 个 token。这比采用相同推测解码（speculative decoding）配置的原生 vLLM 快 1.73 倍。完整结果表请参阅该 PR。

Kimi K3 在 batch size 为 1、TP16、DSpark DL7 以及合成接受长度（AL）为 6 的配置下：解码速度为 842 tokens/s，而原生 vLLM 为 488 tokens/s，实现了 1.73 倍的加速。

配置说明：TP16，DSpark 生成 7 个草稿 token，合成接受长度为 6，DL=7，ISL=1，OSL=1k，batch size 为 1。TPS 衡量的是聚合解码吞吐量，不包含预填充（prefill）。

无推测解码时的解码性能

改进效果覆盖了整个测试的 batch 范围。在 batch 16–64 范围内，TP16 保持了 1.62–1.71 倍的性能提升，而 TP8 在同一范围内实现了 1.31–1.43 倍的提升。

未使用推测解码。吞吐量为整个 TP 组的总和。

AgentX 上的改进

我们优化后的 Kimi K3 实现在 AgentX 上也带来了显著提升：在并发数为 1 时，P90 交互性提高了 1.8 倍：每用户 403.2 tokens/s，对比之前的 223.7 tokens/s。此数据比较了优化后在 16 块 GB300 GPU 上的运行结果与早期 vLLM 在 8 块 GB300 GPU 上的结果。

AgentX 会重放真实编码智能体（coding-agent）会话中的流量模式，包括长上下文、多轮对话、工具调用暂停、并行子智能体以及 KV-cache 复用。它在保留这些工作负载模式的同时，用合成文本替换私有内容，从而在真实的智能体流量下测试服务系统。AgentX 方法论。

Kimi K3 AgentX 结果：P90 交互性与每 GPU 总吞吐量对比，比较了早期的 GB300 vLLM 曲线与专用解码方案。

下一步计划

对于 DeepSeek-V4.1-Flash，#61868 遵循了 K3 的设计模式：在相同的 opt-in decode_backend: latency_specialized 开关背后，该实现同样支持最多 64 个并发请求、prefill 和混合批次的无缝回退，以及推测解码（speculative decoding）。该执行器不再单纯追逐单个热点，而是削减内核数量和主机端开销：它在每个子层边界融合 all-reduce + mHC，用专为低延迟构建的 CuTe DSL 内核替换大批量 MoE 和 GEMMs，对 indexer 的工作进行去重和分片，并将标准 vLLM 在 CPU 上 eager 执行的逐步工作改为通过 CUDA graph 重放。

DeepSeek 在四块 GB300 GPU 上的 AgentX 结果：有无优化解码时的 P90 交互性与每 GPU 总吞吐量对比。

在 Meta 发布 Muse Spark Open 后的两天内，我们的早期结果已经超过了 每用户每秒 950 tokens，使用了七个 draft tokens (K=7) 且接受长度为六 (AL=6)。更多优化正在进行中。

我们还将发布一种类似机制，以优化 GLM5.3 在低并发场景下的解码延迟。我们将在后续文章中分享其优化细节和性能结果。

对于每一项贡献，我们将继续专注于具体的性能提升、生产特性支持，以及可复现的正确性和性能检查。

致谢

我们感谢 Rohan Varma（NVIDIA）和 Alex Steiner（NVIDIA）对本工作的贡献。

同时，我们也感谢 Woosuk Kwon（Inferact）、Michael Goin 和 Lucas Wilkinson（Red Hat），他们为模型重构提供了宝贵的反馈与支持。