Hyper Optimizing Kimi K3 in vLLM: Moving Fast and Responsibly

发表时间: 2026-10 · Blog post by Benjamin Chislett (NVIDIA) (vllm.ai)

原文: https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel

作者：Benjamin Chislett (NVIDIA)
来源：vLLM Blog (2026-10-16)

主要贡献

当前代码辅助智能体（Coding Agents）已能够分担模型优化中最艰难的工程环节，包括编写复杂的 GPU 算子（Kernel）、执行跨算子融合（Cross-operator Fusion）、实现计算与通信重叠（Overlap Computation with Communication），以及针对不同批大小（Batch Size）和 GPU 拓扑配置进行精细化执行调优。针对 Kimi K3 模型，作者团队通过智能体辅助开发流程，在 NVIDIA GB300 架构上构建了一条基于 CuTe DSL 的统一定制解码路径（Specialized Decode Path），全面覆盖了跨 8 卡或 16 卡 GPU 系统的注意力机制（Attention）、混合专家架构（MoE）以及跨卡通信。

该工作的主要贡献与创新成果概括如下：

1. 极致的解码推理吞吐与交互延迟提升：在 16 块 NVIDIA GB300 GPU 上配合 DSpark 投机解码（合成接受长度 $AL=6$）运行批大小为 1 的测试时，Kimi K3 的解码吞吐超过 840 tokens/s；在多个常规测试配置下实现了 $1.5\sim2\times$ 的解码吞吐提升；在模拟真实编程智能体负载的 AgentX 基准测试中，将系统的 P90 交互响应速率提升了最高 $1.8\times$。
2. 端到端深度定制的 CuTe DSL 解码路径：在 NVIDIA Blackwell 架构（GB300）的单 NVLink 多播（Multicast）域内，针对 $1\sim64$ 的解码批大小，实现了针对小矩阵与大批次自适应调优的投影算子、KDA（Kimi Delta Attention）定制算子、解码上下文并行（Decode Context Parallelism, DCP）、全无锁屏障（Fence-less）的计算与通信融合算子、分布式 Router 与专家调度重叠，以及通信窗口下的权重预取（Prefetching）机制。
3. 应对智能体代码膨胀的高速通道工程治理范式（Fast-track RFC）：针对智能体生成高性能优化代码速度远超人工代码审查与维护瓶颈的矛盾，提出了旨在管理风险、降低维护负担的快速通道规范，确立了变更隔离、边界清晰但保留核心功能、系统化双层正确性验证以及分布式算力验证的四大工程原则。

背景知识与设计原则

1. 现实矛盾：智能体辅助开发与代码审查/维护的失衡

• 智能体优化代码的产出速率已超越传统审查与维护流程：深入逐行理解定制 GPU 算子、梳理潜在并发与内存问题、并在所有支持配置下完成全面测试的人工审查流程极其耗时。然而，若直接跳过或简化审查环节，又会带来严重的生产环境故障风险。
• 重构性能工程组织方式的必要性：解决这一矛盾的关键在于重构性能优化工作的协作机制。在引入智能体优化工具的同时，必须构建能够自动化验证可靠性与性能的系统支撑，并在软件架构设计层面建立严格的隔离机制与风险最小化规范。

2. 快速通道优化（Fast-track RFC）的四大核心设计原则

作者团队依托 https://github.com/vllm-project/vllm/issues/59665 确立了四项指导原则，其核心宗旨是在严格控制系统性风险的前提下化解人工审查负担：

• 隔离变更（Isolate Changes）：必须将模型特定的优化实现完全限制在对应模型的代码目录内部。这种物理与逻辑隔离使得受影响的代码路径清晰可见，极大收敛了审查人员需要评估的风险半径（Blast-radius）。

  • 运行时隔离可追溯：在运行时层面必须保证隔离性，审查者能够明确追踪优化路径何时被激活、修改了哪些运行时状态，以及如何在异常或不支持时无缝退回（Fallback）到标准执行路径。
  • 关于全局组件的边界权衡：该约束明确排除了输入准备（Input Preparation）、采样计算（Sampling）以及 KV 缓存管理（KV Cache Management）等环节的侵入式改动。虽然这些组件可能引入额外开销，但由于其被 vLLM 大多数模型部署共享，若为单个模型负载修改它们，将破坏数十个稳定运行的部署环境。此类核心共享逻辑的优化必须由核心维护团队主导，而非走快速通道。

• 限定范围但保留核心功能（Bound the Scope, Preserve the User's Features）：单项优化无需覆盖所有部署场景，可以专门针对特定的 GPU 架构、并行度策略或批大小范围进行极致收敛。清晰的边界有助于精细化调优并明确验证矩阵。

  • 功能完整性底线：划定边界绝不意味着裁剪生产功能。全上下文推理、温度采样（Temperature Sampling）、结构化输出（Structured Output）等核心服务特性必须得到百分之百保留，不得被优化机制剥离或设置为可选放弃，必须作为一级生产需求纳入算子形状和数值精度的验证流程中。

• 系统性验证正确性（Validate Correctness Systematically）：必须结合算子级测试（Kernel Tests）与端到端模型评估（Model Evaluations）。

  • 算子级测试与端到端评测互补：算子测试关注各维度形状与输入分布下的局部数值计算正确性；模型端到端评估则检验整条优化路径是否会改变模型的生成表现。二者缺一不可。
  • 真实代码路径覆盖：测试用例必须实际触发被修改的代码分支。例如，小批次优化必须在真实小批次下验证，注意力机制改动必须在长上下文场景下检验，避免测试因静默回落到标准路径而产生虚假置信度。
  • 隐蔽缺陷的防范案例：在 K3 的开发审计中，团队发现编译器在同步等待指令（Synchronization Wait）之前提前搬运了激活值读取指令（Activation Read）。最终的修复方案是将该特定类型的预载操作严格限制为静态权重读取。此类指令调度缺陷无法被简单的功能测试捕捉，必须依赖严密的针对性分析。此外，在 MRCR 和 AIME25 等长上下文及长生成评估中，暴露出了注意力与通信算子在复杂时序下的隐蔽数值异常，这些问题在基于模拟输入或固定发射时序的单算子隔离测试中完全无法复现。

• 规模化验证能力（Scale Validation）：全面的验证需要耗费大量 GPU 算力。通过 https://github.com/vllm-project/vllm/issues/61698，社区提供了标准的评估容器镜像，使代码贡献者能够在自有硬件上运行标准评测套件，并将可复现的结果报告与 PR 关联绑定。分级评估体系与社区共享算力的引入，大幅减轻了核心项目托管 CI 的硬件压力。

方法细节

针对 Kimi K3，该方案引入了一条全新的专用解码路径，采用基于 CuTe DSL 的定制算子替换并融合了几乎所有关键子算子。该路径面向单 NVLink 多播域下的 8 卡或 16 卡 NVIDIA Blackwell 架构（GB300）GPU，支持 $1\sim64$ 的解码批大小，并支持针对超长上下文的解码上下文并行（DCP）。具体技术路径如下：

1. 针对工作负载调整张量形状（Tune shapes for the workload）

• 依据批大小自适应切换投影算子：不同的并发请求批大小对 GPU 算子的计算强度要求不同。针对注意力输入的投影矩阵运算（Input Projections），在批大小为 $1\sim2$ 的极低延迟负载下，系统调度专门优化的小矩阵算子（Specialized Small-matrix Kernels）；而在较大批大小下，系统自动切换为 Split-K 算子架构，将矩阵乘法的累加维度拆分到更多的 GPU 计算单元（Workers）并发执行。所有注意力投影均经过细致微调，生成规格匹配的算子块尺寸，以充分占满 GPU 计算资源，并在最大程度上实现显存读取、跨卡通信与张量计算的流水线重叠。
• KDA 算子的定制解码实现：对于 Kimi 专有的 KDA（Kimi Delta Attention）架构，实现方案构建了专用的 https://github.com/benchislett/vllm/blob/620c50482d15d092ad6086c106ce42916efc39cc/vllm/models/kimi_k3/nvidia/specialized_decode/cutedsl/kda/prepared.py，其内部计算线程与块调度根据批大小以及分配给单张 GPU 的注意力头数量进行了定制化排布。
• 面向长上下文的解码上下文并行（DCP）：在处理超长上下文生成时，解码上下文并行机制将 KV Cache 沿序列维度切分并分散到多个 GPU 显存中。每张 GPU 仅在其本地分片上并行计算局部注意力，随后通过定制的高效融合算子将局部注意力中间结果与 V 投影（v-proj）以及门控机制（Gating）直接进行就地融合汇总。

2. 计算与通信重叠（Overlap computation and communication）

• 输出投影、All-Reduce 与残差连接的深度融合：系统将注意力输出投影（Output Projection）直接与其后的 All-Reduce 通信以及注意力残差加法运算（Attention-residual）融合在同一执行流中。生产者 GPU 算子计算出局部部分和（Partial Results）后，直接通过 NVLink 零拷贝写入对端 GPU 的可访问缓冲区中；接收端算子直接从该缓冲区拉取数据进行规约聚合并紧接着执行后续计算。
• 无内存屏障通信（Fence-less Data Exchange）：针对部分小批大小配置，系统甚至将跨 GPU 数据的生产者算子与消费者算子直接融合成单个联合算子。节点间的数据交换采用无内存屏障（Fence-less）协议设计，消除了多余的同步握手开销，将跨卡数据交互开销降至最低。
• 大批大小下的两阶段规约机制（Two-stage Reduction）：当并发批大小增大时，单步直连通信会造成带宽争用。系统在 https://github.com/benchislett/vllm/blob/620c50482d15d092ad6086c106ce42916efc39cc/vllm/models/kimi_k3/nvidia/specialized_decode/cutedsl/oproj/prepared.py 中进行了策略切换：各 GPU 首先在其被分配的输出切片内部进行局部的第一阶段规约融合，随后再向其他 GPU 广播分发最终结果。这种两阶段规约大幅降低了大规模并发下 NVLink 链路上的原始数据搬移总量。

3. 优化 MoE 调度与重叠（Improve MoE scheduling and overlap）

• 消除全量 Router 计算与潜在投影的冗余重复：在张量并行（Tensor Parallelism, TP）配置下，基线系统通常在每张 GPU 上独立且冗余地执行全量路由打分（Router Scores）计算以及潜变量输入投影（Latent Input Projection）。优化方案将这些前置计算切分到各个 TP 秩（Ranks）上分布式计算，随后将每个 Rank 负责的部分聚合为单次矩阵乘法（GEMM）统一执行，最后通过 NVLink 交换结果。这一机制彻底消除了专家路由展开前在各卡间的重复计算、冗余权重加载以及不必要的算子发射开销。
• 共享专家与路由专家计算的双流重叠：根据 https://github.com/benchislett/vllm/blob/620c50482d15d092ad6086c106ce42916efc39cc/vllm/models/kimi_k3/nvidia/specialized_decode/cutedsl/moe/experts_runtime.py 中的精细调度设计，Kimi K3 的共享专家（Shared Expert）被部署在独立的 CUDA 流（Stream）上执行。依据具体的批次配置，共享专家的计算工作被精细重叠在路由计算阶段（Routing Phase）或路由专家执行阶段（Routed-expert Computation）。通过严格调控每个算子分配的 GPU 计算资源配额，避免不同执行流之间因 SM 占用不均产生争用（Resource Contention），实现高度均衡的并发流水线。

4. 权重预取至缓存（Prefetching upcoming weights into cache）

• 通信空闲窗口下的侧流权重预取：在小批次解码推理时，系统处于严重的显存带宽瓶颈（Memory-bound），整体吞吐主要受限于从 HBM 加载模型权重的速度。然而在跨卡通信等特定阶段，高带宽显存的读取通道并未被完全占满。针对这一特性，系统在侧流（Side Stream）上并行调度专门的预取算子，在主执行流等待通信完成的窗口期内，提前将后续计算所需的权重数据预载到 GPU 高速缓存中，显著提高了后续计算启动时的缓存命中率（Cache Hit Rate）。

实验环境

• 评估模型：Kimi K3，以及后续验证扩展的 DeepSeek-V4.1-Flash、Muse Spark Open (816B-A42B-NVFP4)、GLM5.3。

• 硬件配置：

  • 核心算力：NVIDIA Blackwell 架构 GB300 系统，测试采用 8 卡（TP8）与 16 卡（TP16）配置。
  • 网络拓扑：单 NVLink 多播（Multicast）域互联架构。

• 软件配置：

  • 基础框架：vLLM（集成快速通道 PR https://github.com/vllm-project/vllm/pull/61867 专用解码分支）。
  • 核心算子后端：基于 NVIDIA CuTe DSL 定制实现的低延迟融合算子，后端配置开关为 decode_backend: latency_specialized。

• 基准测试集与工作负载：

  • DSpark 投机解码测试：合成接受长度 $AL=6$，投机草稿长度 $DL=7$（即 $K=7$），输入序列长度 $ISL=1$，输出序列长度 $OSL=1,000$（1k），批大小为 1。
  • 无投机解码吞吐扫描：批大小（Batch Size）自适应扫描覆盖 1, 2, 4, 8, 16, 32, 64，对比 TP8 与 TP16 下的全组聚合吞吐（Tokens/s）。
  • AgentX 智能体长程基准：采用 https://inferencex.semianalysis.com/agentx 测试集，真实回放编码智能体（Coding-agent）在多轮对话交互、工具调用挂起等待（Tool Pauses）、多子智能体并行以及频繁 KV Cache 复用下的复杂流量模式，输入包含长上下文，以 P90 交互响应度（Interactivity, Tokens/s/user）与单 GPU 吞吐为核心衡量指标。
  • 长文本与长推理评测集：MRCR 与 AIME25，用于高压多轮长序列下的端到端数值精度校验。

实验结果

1. DSpark 投机解码吞吐加速

在配置为 TP16、采用 DSpark 投机架构（草稿长度 $DL=7$，合成接受长度 $AL=6$，$ISL=1$，$OSL=1\text{k}$）的极小批次（Batch Size = 1）极限测试下，专用的 CuTe DSL 解码路径实现了性能跃升：

• 核心数据指标：优化后的 Kimi K3 实现了 842 tokens/s 的端到端解码吞吐，而原生 stock vLLM 在完全一致的投机解码环境配置下吞吐为 488 tokens/s。
• 性能提升幅度：实现了 $1.73\times$ 的纯解码吞吐加速（指标排除 Prefill 阶段，反映整个 TP 组的纯聚合解码能力）。

2. 无投机解码下的批大小吞吐扩展性

在不启用投机解码的纯粹自回归解码负载下，针对 TP8 与 TP16 拓扑，全面测试了批大小从 1 到 64 的绝对吞吐与相对原生 vLLM 的加速比。测试数据如下表所示：

• 结果分析：
  • 在小批次极低时延场景（批大小 $1\sim4$），TP16 展现了最显著的收益，加速比稳定在 $1.81\times\sim1.92\times$。这得益于定制小矩阵算子、无锁通信融合以及显存权重预取的联合生效。
  • 在大批次饱和吞吐场景（批大小 $16\sim64$），TP16 依然维持了 $1.62\times\sim1.71\times$ 的加速比，TP8 维持了 $1.31\times\sim1.43\times$ 的加速比。这证明基于 Split-K 与两阶段通信规约的设计有效缓解了高算力高并发下的带宽与通信争用。

3. AgentX 真实智能体业务负载表现

在高度拟真的编码智能体基准测试 AgentX 中，系统在真实上下文交互场景下的交互指标得到大幅改善：

• P90 交互延迟指标：在并发度为 1 的测试条件下，优化后的 Kimi K3 专用解码路径实现了 403.2 tokens/s/user 的 P90 交互吞吐；而早期基于 8 块 GB300 GPU 运行原生 vLLM 的基准数据仅为 223.7 tokens/s/user。
• 整体收益：端到端 P90 交互能力实现了 $1.8\times$ 的大幅提升，同时在不同并发密度下的整体 GPU 吞吐帕累托前沿曲线显著优于基准实现。

补充细节与后续演进

1. 向 DeepSeek-V4.1-Flash 的架构迁移与扩展

该设计模式已成功复现并扩展至 DeepSeek-V4.1-Flash 模型（对应 PR https://github.com/vllm-project/vllm/pull/61868）。该实现统一继承了 decode_backend: latency_specialized 配置开关，支持最高 64 个并发请求、Prefill 与混合批次的透明回落机制，以及完备的投机解码：

• 算子与宿主端开销削减：取代针对单点热点的孤立优化，该方案执行了跨算子与主机端（Host）协同剪枝。在每个子层边界将 All-Reduce 通信与多头组合（mHC）算子就地融合；将大批次 MoE 与通用 GEMM 统一替换为面向超低延迟定制的 CuTe DSL 专用算子。
• 索引计算分片与 CUDA Graph 捕获：系统对 Indexer 的计算逻辑进行了去重与分布式分片（Sharding），并将原生 vLLM 在 CPU 端以 Eager 模式执行的逐步调度开销全部转化为 CUDA Graph 固化回放，彻底消除了主机端发射瓶颈。

2. 最新开源模型优化拓展进展

• Meta Muse Spark Open：在 Meta 发布 https://huggingface.co/meta-models/Muse-Spark-Open-816B-A42B-NVFP4 模型的 48 小时内，基于相同的工程调优路径，在配置 7 个草稿词（$K=7$）且合成接受长度为 6（$AL=6$）的设置下，初期评测解码速率已突破 950 tokens/s/user。
• GLM5.3 优化支持：团队正在针对低并发场景下的 GLM5.3 研发类似的低延迟专用解码优化机制，后续将独立发布优化技术架构细节与测试基准。

3. 致谢信息（Acknowledgements）

• 特别鸣谢 NVIDIA 的 Rohan Varma 与 Alex Steiner 在本项工作中的核心贡献。
• 特别鸣谢 Inferact 的 Woosuk Kwon，以及 Red Hat 的 Michael Goin 和 Lucas Wilkinson 在模型架构重构方面给予的关键反馈、支持与协作。

结论

本项研究展示了以智能体辅助工程（Agent-assisted Engineering）与系统级硬件共拓设计相结合的方式，能够在 Blackwell（GB300）架构上将超大规模前沿混合专家模型（Kimi K3）的推理延迟推向硬件极限。通过构建统一定制的 CuTe DSL 算子流水线，实现了细粒度矩阵调优、跨卡计算与通信深度融合、分布式 Router 去重以及多流权重预取，获得了最高 $1.92\times$ 的无投机吞吐提升与 $1.73\times$ 的投机解码性能跨越。

更为核心的系统性启示在于：面对智能体生成高性能优化代码带来的代码膨胀与维护危机，社区必须转向以“变更严格物理隔离、生产功能绝对保留、算子/模型双层确定性验证、社区算力自治评估”为支柱的快速通道（Fast-track）模式。未来，团队将继续坚持这一高标准演进路线，在保证生产环境确定性与可维护性的绝对前提下，持续推动更多前沿模型与硬件拓扑逼近物理极限速度。

方法细节引用汇总

在《方法细节》与技术演进章节中，原文明确引用的核心提案（RFC）、代码实现拉取请求（PR）及源代码模块汇总如下：