Kimi K3 在 AMD Instinct MI355X 上：vLLM 服务在 AgentX 上每 GPU 吞吐量媲美 NVIDIA HGX B300
一个搭载八块 AMD Instinct MI355X GPU 的系统，使用 vLLM 服务 Kimi K3，在 AgentX 基准测试中，以 50 tokens/s/user P90 交互性指标衡量，每 GPU 每秒总 token 数比 NVIDIA HGX B300 多 24.4%，并且在基准测试模拟的所有权成本假设下，每美元 token 数多 87.4%。这一结果之所以重要，是因为它是一个软件层面的故事：MI355X 公布的密集低精度矩阵峰值低于 B300，因此优势来自服务栈工程——缓存分区、MoE 集合通信重构、内核融合、AITER 汇编注意力路径、KDA 并行化和草稿深度调优——而非原始硬件吞吐量。
AgentX 上的关键数据
在 50 tokens/s/user P90 交互性下，AMD Instinct MI355X 每 GPU 可服务约 7,567 个总 token/s，而 NVIDIA HGX B300 为 6,083 个——吞吐量优势为 24.4%。使用 SemiAnalysis 模拟的 TCO（AMD 每 GPU 小时 $1.50，NVIDIA 每 GPU 小时 $2.26），这相当于每美元 TCO 可处理 1816 万 vs 969 万总 token，即每美元 token 数多 87.4%。在 50 token 交互性目标下，比较得出模拟每 token 成本低 46.6%。
此基准测试中的交互性是指 P90 响应 token 间延迟的倒数，不包括首 token 时间。总 token 数包括复用的输入和生成的输出。
| 公布的规格，每 GPU | AMD Instinct MI355X | NVIDIA B300 GPU |
|---|---|---|
| 密集低精度矩阵峰值 | 10.1 PFLOP/s MXFP4 | 13.5 PFLOP/s FP4 |
| GPU 内存 | 288 GB HBM3E | 288 GB HBM3E |
| 峰值内存带宽 | 8 TB/s | 8 TB/s |
这两款加速器公布的存储容量和带宽相同，但 B300 公布的密集低精度矩阵峰值更高。达到这种服务性能反映了 AMD 及其在 vLLM 社区中的合作者持续进行的软件工程努力。
AgentX 衡量什么
公开的 AgentX 基准测试使用合成 token 重放真实的编码代理会话轨迹，保留请求长度、时序和前缀共享模式。该工作负载提供超过 96% 的理论前缀复用率，且缓存无限制。推测性运行使用固定的合成接受参考。
由于代理轮次复用了大部分前缀，该基准测试奖励那些保持对话状态驻留并避免重新计算它的系统。公开曲线比较完整的服务栈；每个单独优化旁边报告的测量值来自各自声明配置下的独立测试。
Kimi K3 内部：MLA、KDA 和 MoE
Kimi K3 结合了两种注意力机制和一种稀疏 MoE。返回的代理轮次可以复用其大部分前缀，但处理一个短的续写仍然涉及三种数据。
- 24 个 MLA 层保留随对话增长的压缩 KV 历史。新的查询仍然会查阅该历史。
- 69 个 KDA 层携带固定维度的状态矩阵，随着新 token 的到来更新它们。
- MoE 层通过路由器将每个 token 路由到选定的专家网络。Kimi K3 每个 token 选择 896 个专家中的 16 个，并且专家权重在请求之间共享。
MLA 随着对话增长保留更多历史。KDA 更新固定维度的状态，因此保留更早的检查点意味着保留该状态的额外副本。优化工作分为三个范围：跨轮次（缓存复用和卸载）、模型步骤内（专家投影、内核交接、MLA/KDA 调度）以及选择草稿深度。
1. 缓存：保持对话状态可复用
解码上下文并行（DCP）减少 GPU 内存中的重复历史，CPU 卸载在 GPU 之外保留可复用状态。
在 TP8 下，每个 GPU 处理 Kimi K3 的 96 个 MLA 查询头中的 12 个，但存储整个压缩 KV 历史——张量并行划分头而不划分缓存。使用八路解码上下文并行（DCP8），每个 GPU 存储缓存位置的八分之一。在解码期间，GPU 交换查询，针对本地历史计算，并使用 softmax 权重合并部分答案。每个部分答案携带归一化信息，以便合并可以正确加权分片。PR #51705 将 ROCm AITER DCP 路径扩展到多 token 验证。
对于 142,000 token 的对话，估计的 MLA 负载为 24 层 × 142,000 位置 × 576 FP8 字节 ≈ 每 GPU 1.96 GB。DCP8 将其减少到约 245 MB，在分配开销之前。每个 GPU 处理八倍的头，但历史只有八分之一，领先的注意力算术大致不变。这种额外划分适用于 MLA 历史；KDA 状态保持其跨头的现有分区。
CPU 卸载保留不再适合 HBM 的状态
当状态不再适合 GPU 内存时，AMD 配方的原生 vLLM CPU 卸载将 MLA 历史和 KDA 检查点保留在主机 DRAM 中。
缓存命中需要匹配的恢复点。如果 MLA 历史达到 token 3,072，但最新的兼容 KDA 检查点在 2,048，则请求必须在 2,048 恢复并重新计算剩余前缀。将注意力块尾部与 KDA 检查点一起保存，使它们的恢复位置对齐（PR #54736）。恢复该状态需要将数据传输回 GPU，但避免了前缀重新计算。
2. MoE：消除跨 GPU 的重复工作
在单个 GPU 上，路由专家输出投影返回其消费者期望的完整向量。在原始 ROCm 路径中，早期的归约和归一化使所有八个 GPU 获得相同的潜在输入，并且每个 GPU 都持有完整权重——因此相同的投影运行了八次。
输出坐标可以在 GPU 之间划分，但每个 rank 仍然需要完整结果。Kimi K3 已经为其共享专家部分有一个 all-reduce。每个 GPU 只将其拥有的路由输出添加到其共享专家部分，现有的 all-reduce 组装完整结果，无需新的集合通信（PR #51253）。ROCm 实现基于相应的 CUDA 策略。每个输出坐标恰好接收一次其路由贡献，完整投影权重保持复制。
在 PR 的测试中，在八块 AMD Instinct MI355X GPU 上，TP8，并发 8–128，随机 8K 输入/1K 输出请求且禁用前缀缓存，输出吞吐量提高了 3.05–4.91%。
释放 GPU 内存以保留更多缓存状态
仅加载每个 rank 使用的行，在 TP8 下跨 92 个 MoE 层释放约 每 GPU 3.85 GiB（PR #59591）。融合路径的计算保持不变；额外的空间可以容纳 MLA 历史和 KDA 检查点。
此更改在用于主要公开结果的镜像之后落地。其单独的 AgentX 实验发现，在并发 32 和 48 时吞吐量提高不到 1%，但在 70 时提高 28.9%，报告的前缀缓存命中率从 74.8% 上升到 80.1%。高并发下的更大增益与缓存压力一致。测量使用八块 AMD Instinct MI355X GPU，TP8/DCP8，FP8 KV，30 分钟运行，无 CPU 卸载或推测解码；未报告重复运行的不确定性。
3. 内存流量：融合操作并消除不必要的复制
在每个 GPU 内部，下一个要检查的地方是内核之间传递的数据。
Kimi K3 的单 token KDA 路径运行了三个计算内核和两次输出复制。卷积在已经融合 Q/K 归一化、衰减和 beta 门以及循环更新的内核之前运行；输出归一化在其后运行。融合的 HIP 路径在一次启动中执行这些操作，并直接写入目标缓冲区（PR #50654）。中间交接保持在芯片上，而卷积历史和循环状态仍然为下一个 token 进入 GPU 内存。
AttnRes 将早期层块输出与运行残差混合。将该混合与 RMSNorm 结合，将临时混合保持在寄存器中（PR #50593）。为后续层保存的运行残差保留其 BF16 舍入；混合在归一化过程中保持 FP32。使用 AttnRes 融合，在八块 AMD Instinct MI355X GPU 上，TP8，100K 输入/1K 输出请求且禁用前缀缓存，输出吞吐量提高了 14.2%。长前缀预填充延迟基本不变。
仅为使用它们的内核复制输入
ROCm 矩阵乘法调度器在选择内核之前打包输入。当它选择回退时，该内核读取原始输入，复制未使用。将打包移入专用分支消除了这些复制（PR #58566）。
性能分析使浪费可见：每个解码步骤 69 次不必要的复制，每个 KDA 层一次。每次仅移动 1,792 字节，但耗时约 4.8 微秒——启动开销占主导，因此更快地移动这些字节几乎没有帮助。在 PR 的 TP8、并发一、六草稿、384K 上下文性能分析中，移除的复制占每步复制内核时间 0.339 毫秒。
4. MLA：使用 AMD AITER 汇编加速长上下文解码
在 TP8 下，Kimi K3 每 GPU 有十二个查询头。填充到十六个使 AMD AITER 的汇编解码路径可用。在报告的长上下文测试中，每个输出 token 的时间从 43.8 毫秒降至 23.6 毫秒。
比较使用 TP8 无 DCP，并发一。PR #50578 中的适配器复制四个查询头，将它们打包到十六头布局中，并丢弃其输出。DCP8 呈现不同的 96 头形状。这保持了模型的操作，因为每个查询头独立关注缓存位置——添加另一个头不会改变原始头的 softmax。在此解码路径中仅填充查询；存储的压缩 KV 历史大小保持不变。
| 输入 / 输出 token | 原始 Gluon 路径 | 填充汇编路径 |
|---|---|---|
| 1K / 1K | 22.9 毫秒/token | 22.8 毫秒/token |
| 32K / 1K | 43.8 毫秒/token | 23.6 毫秒/token |
这些是 PR 报告的每输出 token 平均时间，在八块 AMD Instinct MI355X GPU 上，TP8，并发一，MXFP4 模型权重，BF16 注意力和普通单 token 解码。短输入情况几乎不变；长输入情况每输出 token 时间几乎减半。
机制是调度。在检查的历史代码中，保守的调度提示将 Gluon 路径限制为每个请求一个工作组，该工作组仍然处理整个对话。填充使 AMD AITER 的汇编路径可用，其策略不同，将历史划分为并行片段并组合结果——检查的汇编策略选择十六个分区。历史分区是分配给单个 GPU 内工作组的任务；KV 存储不变。
5. KDA：并行化预填充和推测验证
MLA 可以在工作组之间拆分保留的历史。KDA 提出了更难的调度问题：每个 token 依赖于前一个状态。PR #54038 中的融合预填充在传入状态已知之前准备每个 token 组的组合变换。
KDA 通过矩阵变换实现这一点。对组摘要的有序扫描确定每个组的起始状态；然后组并行重放其 token。token 顺序保持不变，但每个组不再等待前一个组的重放。分组增加了第二次遍历，并将融合块路径从两次启动扩展到四次。当序列或头太少暴露的并行工作太少时，它有帮助；否则，额外的传递可能得不偿失。在每个组内，循环遍历在块之间将状态保持在矩阵累加器寄存器中，避免全局内存写入和重新加载。
在单独的三后端比较中，融合 KDA 在 4K 和 16K 输入长度下比 Triton 提供 5.3–5.6% 更多的输入吞吐量：八块 AMD Instinct MI355X GPU，TP8，并发 32，禁用前缀缓存和单 token 输出。这测量了完整后端。
更小的 tile 用于推测验证
短验证批次需要不同的拆分。在 TP8 下，每个 GPU 有 12 个 KDA 头，每个头有 128 个值列。将每个头拆分为四个 32 列 tile 仅启动 256 个计算单元上的 48 个工作组。PR #58045 切换到四列 tile，将数量提高到 384。每个 tile 拥有不同的值列，并按顺序遍历相同的 token 序列。
在单块 AMD Instinct MI355X GPU（TP8 维度，单序列，四个验证位置）上的单独图重放内核测试中，时间从每层 16.20 微秒降至 5.61 微秒（2.89×）。这包括更窄的 tile、单波工作组、均匀长度专门化和提升的 token 不变工作。不规则批次保留动态路径；测试比较输出和循环状态。
6. 推测解码：选择草稿 token 的数量
更快的验证可以改变值得检查的草稿 token 数量。有用速率是提交输出除以完整草稿–验证–提交周期时间。
在 AgentX 的固定接受参考下，三个草稿每个周期给出 3.00 个预期提交 token，四个草稿给出 3.36 个，包括恢复或奖励 token——每个周期提交输出多 12%。因此，四个草稿仅在完整周期比三个草稿耗时少 12% 时提高吞吐量。该 12% 阈值是成本预算；帖子中未测量完整周期增长。
公开的 AMD 配方使用三到七个草稿，DCP1，并在较大的 DCP8 并发设置下禁用推测。
技术说明：KDA 序言中的精度和片上内存
KDA 序言计算 64×64 块内依赖矩阵的逆，后续矩阵乘积使用此变换来解释 token 依赖。逆的中间值可能增长和抵消，因此过早舍入会丢失最终结果所需的信息。实现使用 AMD 原生的 FP32 矩阵指令，为敏感的逆保留 FP32 输入和累加，并且仅将完成的逆舍入为 BF16 用于后续乘积。
FP32 累加无法恢复在其开始之前丢失的信息。从 256.5 中减去 256 得到 0.5，当保留原始 FP32 输入时，但 0 当输入先舍入为 BF16 时（256.5 在该量级舍入为 256）。这些玩具值说明了为什么逆使用原生 16×16×4 FP32 矩阵指令，保留输入和累加精度。
序言还有本地内存预算。AMD 称其片上共享暂存为 LDS。Q 和 K tile 复用存储，因为它们在需要时不同，三角形输入仅存储其十个占用的 16×16 块。工作组请求 79.5 KiB，舍入为 80 KiB——AMD CDNA 4 计算单元 160 KiB LDS 预算的一半。分配舍入到 1,280 字节单位，因此两个 80 KiB 分配适合，而两个 81.25 KiB 分配不适合。这是容量计算；寄存器和其它资源可能施加额外限制。
在 MoE 方面，单独的技术说明涵盖精度：PR #53940 中的 A4W4 集成将激活从八位改为四位，而权重保持四位。总流量还包括 BF16 中间输出和专家 tile 填充，因为大型服务器批次仍可能每个专家留下很少的行。
基准配置和注意事项
比较目标处的服务配置：
| P90 交互性（tokens/s/user） | AMD Instinct MI355X | NVIDIA HGX B300 |
|---|---|---|
| 30 和 50 | SimpleCPU 卸载；DCP8 / 无草稿到 DCP1 / 三草稿 | Mooncake 卸载；DCP8 |
| 150 | 仅 GPU；DCP1；五到七草稿 | Mooncake 卸载；DCP8 |
两个系统使用八块 GPU，TP8，FP4 权重和 FP8 KV。值在匹配交互性的每个公布的卸载或仅 GPU 系列内插值；并发、DCP 和草稿深度可能在括号运行之间变化。
提交使用 vLLM 36768d1bf（AMD）和 5894fdf98（NVIDIA）。配置的主机缓存预算分别为每 GPU 224.875 和 281 GB。重放使用 cc-traces-weka-062126 数据集和固定的 AIPerf 框架，排除预热，并在固定合成接受曲线下进行一小时性能分析。下载的数据集修订版未记录，闭环重放可能产生不同的完成请求混合。
成本模型使用 SemiAnalysis 的大型超大规模所有者模型，公布的 GPU 成本常数为 AMD Instinct MI355X 每 GPU 小时 $1.50 和 NVIDIA HGX B300 每 GPU 小时 $2.26。总 token/$ = 总 token/s/GPU × 3,600 ÷ 模拟 $/GPU 小时。一些资本和利用率假设仍未公布。
快照是 SemiAnalysis InferenceX 数据，检索于 2026 年 10 月 9 日，提交日期为 2026 年 9 月 30 日（AMD）和 2026 年 8 月 16 日（NVIDIA）。PR 基准使用其声明的负载，PR #59591 是在主要图像之后运行的单独实验。
接下来优化什么
正在进行的预填充/解码分离工作增加了另一个检查点：工作负载平衡以及传输是否在其数据需要之前完成。
对于另一个模型或负载，帖子建议从部署的请求形状开始，并进行三项检查：
- 比较 rank。 在集体通信可以组装结果之前，是否有多个 GPU 计算相同的结果？
- 跟踪缓冲区。 每个临时张量在选定路径上是否有消费者？数据能否保持在芯片上？
- 计算独立工作。 实际的头、token 和 tile 是否产生足够的工作组来分散负载？
以您需要的响应速度测量完整请求，并检查输出和保存的状态。更快的内核在缩短阻碍下一个 token 的工作时很重要。
Kimi K3 工作涵盖超过 50 个合并的 AMD/ROCm 相关 vLLM PR，来自 AMD、Embedded LLM 和更广泛的社区，以及 AITER 开发、集成、审查和基准测试。贡献涵盖注意力、循环、MoE、量化、图执行、缓存支持和平台集成。