vLLM 解析 Kimi K3 在 AMD Instinct MI355X 上的推理优化，单 GPU 吞吐超 NVIDIA HGX B300 24.4%

Kimi K3 优化工作内幕：理解瓶颈以及让推理更快的决策

在本文中

• AgentX：工作负载与结果
• 深入 Kimi K3：专家、注意力与循环状态
• 1. 缓存：让对话状态可供复用
• 2. MoE：消除跨 GPU 的重复工作
• 3. 内存流量：融合操作并消除不必要的拷贝
• 4. MLA：借助 AMD AITER 汇编实现更快的长上下文解码
• 5. KDA：并行化预填充与投机验证
• 6. 投机解码：选择草拟多少 token
• 下一步优化什么
• 贡献与致谢

在 AgentX 上，一套八 GPU 的 AMD Instinct MI355X 系统使用 vLLM 服务 Kimi K3，在 50 tokens/s/用户 P90 交互性下，每 GPU 每秒总 token 数比 NVIDIA HGX B300 高出 24.4%。在该基准的拥有成本模型下，每美元 token 数高出 87.4%。

在本文中，我们将剖析 AMD Instinct MI355X 上 Kimi K3 背后的工程实现，将 vLLM 的服务决策与 GPU 内核及其底层硬件联系起来。我们将解释这些优化为何有效，并建立直觉，以便在你自己的推理栈中发现浪费的工作、识别瓶颈并找到下一个优化点。

已公布的稠密矩阵峰值为 AMD Instinct MI355X 的 10.1 PFLOP/s MXFP4 和 NVIDIA B300 的 13.5 PFLOP/s FP4。两者均配备 288 GB HBM3E 和 8 TB/s 峰值内存带宽。达到这一服务性能体现了 AMD 及其 vLLM 社区合作者持续不断的软件工程努力。

AgentX：工作负载与结果

公开的 AgentX 基准使用合成 token 回放真实编码智能体会话轨迹，保留请求长度、时序和前缀共享模式。在缓存无限的情况下，该工作负载提供超过 96% 的理论前缀复用率。投机运行使用固定的合成接受参考。

在 50 tokens/s/用户 P90 交互性下，AMD Instinct MI355X 服务约 7,567 总 tokens/s/GPU，而 NVIDIA HGX B300 为 6,083，吞吐量优势为 24.4%。使用 SemiAnalysis 建模的 TCO，分别为每 GPU 小时 1.50 美元对 2.26 美元，这转化为每美元 TCO 1,816 万对 969 万总 token：每美元 token 数多 87.4%。

公开曲线比较的是完整的服务栈。每项优化旁边的测量数据来自单独的测试，并在其所述配置下解释各自的机制。

深入 Kimi K3：专家、注意力与循环状态

一个返回的智能体轮次可以复用其大部分前缀，但处理一段很短的续写仍会触及三类数据。

Kimi K3 使用两种注意力。它的 24 个 MLA 层保留随对话增长的压缩 KV 历史。新的查询仍会查阅该历史。它的 69 个 KDA 层则携带固定维度的状态矩阵，并在新 token 到达时更新它们。模型配置。

在 MoE 层中，路由器选择专家网络来转换每个 token。它们的权重在各请求之间共享。

跨轮次：缓存复用与卸载（第 1 节）。
模型单步内：专家投影、内核交接以及 MLA/KDA 调度（第 2–5 节）。
选择草稿深度：已提交输出与完整周期成本（第 6 节）。

1. 缓存：保持对话状态可供复用

DCP 减少 GPU 内存中的重复历史；CPU 卸载将可复用状态保存在其之外。

在 TP8 下，每个 GPU 处理 Kimi K3 的 96 个 MLA 查询头中的 12 个，但存储整个压缩 KV 历史。张量并行划分了头，却没有划分缓存。

使用 八路解码上下文并行（DCP8）时，每个 GPU 存储八分之一的缓存位置。在解码期间，各 GPU 交换查询，针对其本地历史进行计算，并合并它们的部分答案。

每个部分答案都携带归一化信息，以便合并时能正确地对各分片加权。#51705 将 ROCm AITER DCP 路径扩展到多 token 验证。

对于一段 142,000 token 的对话，估计的 MLA 负载为 24 层 × 142,000 个位置 × 576 FP8 字节 ≈ 每 GPU 1.96 GB。DCP8 将其减少到约 245 MB，尚未计入分配开销。每个 GPU 针对八分之一的历史处理八倍数量的头，使主导的注意力算术大致保持不变。

CPU 卸载：保存不再能放入 HBM 的状态

当状态不再能放入 GPU 内存时，AMD recipe 的原生 vLLM CPU 卸载会将 MLA 历史和 KDA 检查点保存在主机 DRAM 中。

缓存命中需要匹配的恢复点。如果 MLA 历史到达 token 3,072，但最新的兼容 KDA 检查点在 2,048，则请求必须从 2,048 恢复并重新计算剩余前缀。

将 attention-block 尾部与 KDA checkpoint 一起保存，可使它们的恢复位置对齐（#54736）。恢复该状态需要将数据传回 GPU，但可避免前缀重计算。一旦请求恢复，其新 token 仍可能让多个 GPU 重复相同的计算。

2. MoE：消除跨 GPU 的重复工作

在单个 GPU 上，路由专家输出投影会返回其消费者所期望的完整向量。在原始 ROCm 路径中，先前的归约和归一化让全部八个 GPU 获得相同的 latent 输入，且每个 GPU 都持有完整权重。因此同一个投影运行了八次。

输出坐标可以在 GPU 之间划分，但每个 rank 仍然需要完整结果。Kimi K3 已经为其共享专家部分和提供了 all-reduce。

每个 GPU 只将自己拥有的路由输出加到其共享专家部分和中。现有的 all-reduce 会组装出完整结果，无需新的集合通信（#51253）。ROCm 实现基于相应的 CUDA 策略构建。

每个输出坐标恰好接收一次其路由贡献。完整的投影权重仍然保持复制。

在该 PR 于八块 AMD Instinct MI355X GPU 上以 TP8 进行的测试中，并发 8–128、随机 8K 输入/1K 输出请求且禁用前缀缓存时，输出吞吐量提升了 3.05–4.91%。

释放 GPU 内存以保留更多缓存状态

现在每个 rank 只计算分配给它的投影坐标，同时保留完整权重。

仅加载每个 rank 使用的行，在 TP8 下跨 92 个 MoE 层为每块 GPU 释放约 3.85 GiB（#59591）。融合路径的计算保持不变；额外空间可容纳 MLA 历史和 KDA checkpoint。

此更改在用于头条公开结果的镜像之后合入。其单独的 AgentX 实验发现，在并发 32 和 48 时吞吐量提升不到 1%，但在 70 时提升 28.9%，此时报告的前缀缓存命中率从 74.8% 升至 80.1%。

高并发下更大的增益与缓存压力一致。在相同缓存容量下比较两种实现，将有助于分离该效应。

更多关于 专家路由和四位激活。

3. 内存流量：融合操作并移除不必要的拷贝

在每个 GPU 内部，下一个值得关注的地方是内核之间传递的数据。

Kimi K3 的单 token KDA 路径运行了三个计算内核和两次输出拷贝。卷积运行在一个已经融合了 Q/K 归一化、decay 和 beta 门以及循环更新的内核之前；输出归一化在其后运行。融合的 HIP 路径在一次启动中执行这些操作，并直接写入目标缓冲区（#50654）。

中间交接留在芯片上。卷积历史和循环状态仍会写入 GPU 内存，供下一个 token 使用。

AttnRes 将较早的层块输出与运行中的残差混合。将该混合与 RMSNorm 结合，使临时混合值保留在寄存器中（#50593）。为后续层保存的运行残差保留其 BF16 舍入；混合值在归一化过程中保持 FP32。测试要求持久更新精确，并允许归一化输出存在数值容差。

使用 AttnRes 融合后，在 TP8 配置的八块 AMD Instinct MI355X GPU 上，输出吞吐量提升了 14.2%，测试使用 100K 输入/1K 输出请求，并禁用了前缀缓存。长预填充延迟基本没有变化。

仅对使用输入的核函数拷贝输入

ROCm 矩阵乘法调度器在选择内核之前会打包输入。当它选择回退内核时，该内核读取原始输入，使拷贝未被使用。将打包移入专用分支后，这些拷贝被移除（#58566）。

性能分析让这种浪费变得可见：每个解码步骤有 69 次不必要的拷贝，每个 KDA 层一次。每次仅移动 1,792 字节，但耗时约 4.8 微秒。更快地移动这些字节几乎无济于事；启动开销占主导。

4. MLA：使用 AMD AITER 汇编实现更快的长上下文解码

在 TP8 下，Kimi K3 每块 GPU 有十二个查询头。填充到十六个后，AMD AITER 的汇编解码路径变得可用。在报告的长上下文测试中，每个输出 token 的时间从 43.8 毫秒降至 23.6 毫秒。

该对比使用 TP8、无 DCP、并发为一。#50578 中的适配器拷贝四个查询头，将它们打包成十六头布局，并丢弃其输出。DCP8 呈现不同的 96 头形状。

这保留了模型的操作，因为每个查询头在缓存位置上独立进行注意力计算。增加另一个头不会改变原始头的 softmax。在此解码路径中仅对查询进行填充；存储的压缩 KV 历史保持相同大小。

长对话为注意力提供了大量工作，但这些工作需要在 GPU 上分散开来。在我们检查的历史代码中，一个保守的调度提示将 Gluon 路径限制为每个请求一个工作组。该工作组仍然处理整个对话。填充使 AMD AITER 的汇编路径变得可用，其采用不同的策略将历史划分为并行片段并合并结果。

PR 报告的平均每输出 token 时间：八块 AMD Instinct MI355X GPU，TP8，并发为一，MXFP4 模型权重，BF16 注意力与普通单 token 解码。

短输入场景几乎没有变化；长输入场景将每输出 token 时间几乎减半。这些服务测量包括查询准备和输出处理。

5. KDA：并行化预填充与推测验证

MLA 可以将保留的历史拆分到各工作组。KDA 提出了更难的调度问题：每个 token 都依赖于前一个状态。#54038 中的融合预填充会在每个 token 组的传入状态已知之前，准备好该组的组合变换。

例如，“将状态减半并加二”，然后“将其减半并加一”，合并为“取起始状态的四分之一并加二”。这条规则可以在起始状态到达之前计算出来。

逐步了解 KDA 依赖序列

KDA 通过矩阵变换实现这一点。对组摘要进行有序扫描可确定每组的起始状态；随后各组并行重放其 token。Token 顺序保持不变，但每组不再等待前一组重放完成。

分组增加了第二次遍历，并将融合分块路径从两次启动扩展到四次。当序列或头数较少、暴露出的并行工作太少时，这会有帮助；否则，额外的遍历可能得不偿失。

在每个组内，循环遍历将状态保存在分块之间的矩阵累加器寄存器中，避免全局内存的写入和重新加载。状态存储示意图。

在另一项三后端对比中，融合 KDA 在 4K 和 16K 输入长度下比 Triton 的输入吞吐量高 5.3–5.6%：八块 AMD Instinct MI355X GPU，TP8，并发 32，前缀缓存禁用，单 token 输出。这测量的是完整后端。基准测试结果。

对推测验证使用更小的分块

短验证批次需要不同的拆分方式。在 TP8 下，每块 GPU 有 12 个 KDA 头，每个头有 128 个值列。将每个头拆分为四个 32 列分块，在 256 个计算单元上仅启动 48 个工作组。#58045 改为四列分块，将数量提升到 384。

在一项单独的图重放内核测试中，使用一块 AMD Instinct MI355X GPU（TP8 维度，一个序列，四个验证位置），每层时间从 16.20 微秒降至 5.61 微秒（2.89 倍）。这包括更窄的分块、单波工作组、统一长度特化以及提升 token 不变的工作。不规则批次保留动态路径；测试会比较输出和循环状态。

6. 推测解码：选择草拟多少 token

更快的验证可以改变有多少草稿 token 值得检查。有效速率等于已提交输出除以完整的草稿—验证—提交周期时间。

例如，AgentX 的固定接受参考在三个草稿下给出每周期 3.00 个预期已提交 token，在四个草稿下为 3.36，包括恢复或奖励 token。这意味着每周期已提交输出多出 12%。只有当完整周期耗时比三个草稿时高出不到 12% 时，四个草稿才能提升吞吐量。

公开的 AMD 配方在 DCP1 下使用三到七个草稿，并在更大的 DCP8 并发设置下禁用推测。

接下来优化什么

正在进行的预填充/解码分离工作增加了另一个可关注点：工作节点平衡，以及传输是否在需要其数据之前完成。

对于另一个模型或工作负载，从已部署的请求形态入手，做三项检查：

比较 rank。是否有多个 GPU 在某个可以汇总结果的集合通信之前计算相同结果？

跟踪缓冲区。每个临时张量在所选路径上是否有消费者？数据能否留在片上？

统计独立工作。实际的 head、token 和 tile 是否产生足够的工作组来分散负载？

以你需要的响应速度测量完整请求，并同时检查输出和保存的状态。更快的 kernel 只有在缩短阻塞下一个 token 的工作时才有意义。

贡献与致谢

Kimi K3 的工作涵盖来自 AMD、Embedded LLM 和更广泛社区的超过 50 个已合并的 AMD/ROCm 相关 vLLM PR，以及 AITER 开发、集成、审查和基准测试。贡献涵盖注意力、循环、MoE、量化、图执行、缓存支持和平台集成。

特别感谢：Pin Siang Tan、Jun Kang Chow、Ye Hur Cheong、Hongxia Yang、Seungrok Jung、Bill He、Yichao Zhu、Hyukjoon Lee、Andy Luo、Mrinal Karvir、Richard Li、Sun Peng

Andy Friedrich, Ethan Yang, Tang Rui, Andreas Karatzas, Ankur Singh, Yihua Cheng, Badr Ba Sowid, Benjamin Chislett, Taoyu Zhu, Bill He, Bin Ding, Bowen Bao, Brandon Zhang, Chaemin Lim, Charles Wu, Chuan (Richard) Li, Felix Li, Cameron Quilici, Weishu Deng, Dewei Wang, Divakar Verma, Douglas Lehr, Edwin Lim, Yudong Pan, Elvir Crnčević, Fang Che, Fangzhou Ai, Xingran Fan, Fulu Li, Felix Marty, Canlin Guo, Summer Yang, Haichen Zhang, Yufeng He, He Liu, Hongxia Yang, Hyukjoon Lee, Yifan Qiao, James E T Smith, Jiahui Cao, Yanyuan Qin, Jonathan Chen, Juntian Liu, Shao-Chun Lee, Kedar Potdar, Kevin H. Luu, Kuan-Fu Liu, Kuntai Du, Kyle Sayers, @lalala-sh, @linnea-lin-00638949, Yinfeng Liu, Lucas Wilkinson, Gabriel Wu, Markus Hartikainen, Maithili Joshi, Jeff (Junze) Ma, Matthew Wong, Misha Goin, Micah Williamson, @minmengdie, Matvei Pashkovskii, Mathews Neha, Nicolò Lucchesi, Nick Hill, Nicholas Susanto, Oxana Korzh, Pei Zhang, @ppalanga, Peiran Qin, Qiuyang Yue, Rita Brugarolas, Rebecca Lee, Ryan Rock, Rohan Potdar, @Saddss, Samuel Shen, Sean Filimon, Seungrok Jung, Shantipriya Parida, Shanshan Shen, Shengnan Xu, Simon Danielsson, Siraj Shaikh, Stacy Roberts, Stefan Koncarevic, Asan Stefanski, Minghui Jiang, Tarık Saraç, Tun Jian Tan, Lingpeng Jin, Vansh Bhatia, Maksim Vedenev, Ye Hur Cheong, @wenwzhan, Wei Zhao, Xavier Aguilar, Xiaobing Zhang, Xiaohu Guo, Xin Li, Xudong Lyu, Yanxue Ren, Wentao Ye, Yongqin Wang, Riggins Chen, Chao Hong, Yuchen Shen, Matt Qin, Yichao Zhu, Roger Wang, Zheng Gong, Jiangyun Zhu, Zvi Grinberg, Yongye Zhu.

基准测试说明

对比目标处的服务配置

两个系统均使用八块 GPU、TP8、FP4 权重和 FP8 KV。数值在匹配交互性下于各自已发布的卸载或仅 GPU 系列内插值；并发、DCP 和草稿深度在括起的运行之间可能不同。固定的 AMD 配方（YAML） 和 NVIDIA 启动器 给出了镜像标签和完整设置。

回放使用 cc-traces-weka-062126 数据集和 固定的 AIPerf 测试框架，排除预热，并在 固定合成接受曲线 下进行一小时的性能分析。配方给出了种子、会话开始和预热设置。下载的数据集修订版本未记录。闭环回放可能产生不同的已完成请求组合。

软件与卸载。提交使用 vLLM 36768d1bf（AMD）和 5894fdf98（NVIDIA）。配置的主机缓存预算分别为每 GPU 224.875 和 281 GB；连接器和镜像设置在链接的配方中。

成本。SemiAnalysis 的 大型超大规模企业拥有模型 和 已发布的 GPU 成本常数 使用 AMD Instinct MI355X 每 GPU 小时 1.50 美元和 NVIDIA HGX B300 每 GPU 小时 2.26 美元。总 tokens/$ = 总 tokens/s/GPU × 3,600 ÷ 建模的 $/GPU 小时。一些资本和利用率假设仍未公布。在 50-token 交互性目标下，该比较得出每 token 建模成本低 46.6%。

快照。SemiAnalysis InferenceX 数据 检索于 2026 年 10 月 9 日；提交日期为 2026 年 9 月 30 日（AMD）和 2026 年 8 月 16 日（NVIDIA）。PR 基准使用其声明的工作负载；#59591 是标题镜像之后的单独实验。

来源：AMD Instinct MI355X、NVIDIA HGX B300、NVIDIA 内存规格。基准详情：AgentX 方法。

技术说明：专家路由与精度

Kimi K3 每个 token 从 896 个专家中选择 16 个，因此即使服务器批量很大，每个专家仍可能只有少数行。由此产生的专家 tile 可能包含填充。

A4W4 减少了流量的另一部分：#53940 中的集成将激活从八位改为四位，而权重保持四位。总流量还包括 BF16 中间输出和专家 tile 填充。

技术说明：KDA 精度与片上内存

每个 chunk 仍需解决其 token 之间的依赖关系。内核将它们合并为一个变换，后续矩阵乘积可以应用该变换。这产生了两个实际问题：哪种精度能保持答案，以及多少临时数据能放在片上？

一个小例子展示了这个想法。将较早的修正代入较晚的修正中，每个答案都可以直接用已知输入表示。得到的系数表已经考虑了依赖链：

真正的序言部分计算 64×64 块内依赖矩阵的逆。后续矩阵乘积使用这一变换来考虑这些依赖关系。

逆矩阵的中间值可能会增长并相互抵消。过早对其进行舍入会丢失最终结果所需的信息。该实现使用 AMD 原生的 FP32 矩阵指令，对敏感的求逆过程保留 FP32 输入和累加。只有完成后的逆矩阵才会舍入为 BF16 以供后续乘积使用。内核实现。

为什么 FP32 累加无法恢复已舍入的输入

考虑从 256.5 中减去 256。两个输入在 FP32 中都是精确的。在这个数量级下，将 256.5 转换为 BF16 会将其舍入为 256：

FP32 减法无法恢复在其开始之前就已丢失的信息。这些示例值说明了为什么求逆使用原生的 16×16×4 FP32 矩阵指令，同时保留输入和累加精度。

FP4 模型同样依赖于更高精度的运算。其性能取决于能否使这些数值路径高效运行。

序言部分还有本地内存预算。AMD 将其片上共享暂存区称为 LDS。Q 和 K 分块复用存储，因为它们在不同时间需要；三角输入只存储其十个被占用的 16×16 块。工作组请求 79.5 KiB，向上取整为 80 KiB，是 AMD CDNA 4 计算单元 160 KiB LDS 预算的一半。

通过预留足够多的未使用 LDS 以跨过该阈值，同时保持内核二进制不变，来测试这一阈值。如果运行时几乎不变，那么对于该形状而言，额外驻留的工作组贡献很小。

块之间的状态

返回 KDA 服务结果。

免责声明

本文档中提供的信息仅供参考，可能包含技术性错误、遗漏和排版错误。本文所含信息可能会发生变化，并可能因多种原因而变得不准确，包括但不限于产品和路线图变更、组件和主板版本变更、新机型及/或产品发布、不同制造商之间的产品差异、软件变更、BIOS 刷新、固件升级等。任何计算机系统都存在无法完全预防或缓解的安全漏洞风险。AMD 无义务更新或以其他方式更正或修订此信息。但是，AMD 保留修订此信息以及不时更改其内容的权利，且无义务将此类修订或更改通知任何人。此信息按“原样”提供。AMD 对其内容不作任何陈述或保证，并且对可能出现在此信息中的任何不准确、错误或遗漏不承担任何责任。AMD 明确否认任何关于不侵权、适销性或特定用途适用性的默示保证。在任何情况下，AMD 均不对任何人因依赖本文所含任何信息而导致的任何直接、间接、特殊或其他后果性损害承担责任，即使 AMD 已明确被告知此类损害的可能性。AMD、AMD Arrow 标识及其组合是 Advanced Micro Devices, Inc. 的商标。本出版物中使用的其他产品名称仅用于识别目的，可能是其各自公司的商标。© 2026 Advanced Micro Devices, Inc. 保留所有权利。