Kimi K3 在 AMD MI355X 上的部署：性能与成本分析

AMD MI355X 在提供 2.8T 参数的 Kimi K3 模型服务时，展现出了卓越的单位美元性能比，每个节点可实现 952 tokens per second (tok/s)。虽然 NVIDIA 的 B300 在绝对总吞吐量方面保持领先，但 MI355X 较低的每 GPU-小时成本使其成为处理超出单个 B200 节点显存容量的前沿规模模型的更具成本效益的选择。

硬件对比与吞吐量

Kimi K3 模型的大小（2.8T 参数）在为 1M tokens 的上下文分配 KV cache 之前，需要超过 1.5TB 的 VRAM。这一显存需求使得 MI355X 和 B300 成为可行的选择，因为它们每块 GPU 拥有 288GB VRAM，而单个 B200 节点（8 GPUs）无法容纳模型权重和 KV pool，因此必须采用多节点 TP16 部署。

在 1,024-token 输入和 400-token 输出的工作负载下，性能基准测试显示了以下结果：

Metric	8× MI355X (TP8)	2×8 B200 (TP16)	B300 (TP8+DCP8)
Decode tok/s per stream	118 tok/s	90 tok/s	172 tok/s
Peak aggregate	952 tok/s	498 tok/s	1,568 tok/s
Peak aggregate per GPU	119 tok/s	31 tok/s	196 tok/s
Peak aggregate per $/GPU-hr	48 tok/s/$	7 tok/s/$	33 tok/s/$

定价基于 MI355X 为 $2.50/GPU-hr，B300 为 $6.00，B200 为 $4.25。

虽然 B300 在绝对性能方面领先（约为 MI355X 总吞吐量的 1.65 倍），但 MI355X 的单块 GPU 成本约为 B300 的 1/2.4，从而导致了显著更高的单位美元性能比。

ROCm 软件优化

在 AMD 硬件上部署 Kimi K3 需要进行两项主要的工程干预，以达到峰值吞吐量并降低延迟。

推测解码修复

为了使用 RadixArk 的 Kimi-K3-DSpark 实现推测解码，Wafer 在 sglang ROCm 构建版本中遇到了一个 NameError。该错误发生的原因是 ROCm 构建版本缺少 top_k_renorm_prob 的定义，而该函数用于 accept-sampling verifier 的密集路径中。

Wafer 通过实现一个 PyTorch 函数来处理 top-k 重新归一化（排序、掩码填充和重新缩放）解决了这个问题。这一修复使得推测解码成为可能，从而使单流性能提升了 2.2 倍，并使峰值总吞吐量增加了 18%。

Prefill 优化

MI355X 上的初始冷启动 prefill 性能明显慢于 B300（对于 172k-token 的 prefill，分别为 51s 对比 23s）。这是由于系统回退到了缓慢的通用 Triton attention kernel，因为快速的 AITER MLA prefill kernel 由于形状不匹配而无法加载（K3 在 TP8 下每 rank 提供 12 个 attention heads，而 AITER 预期 4、8 或 16 的倍数）。

通过将 head count 从 12 填充零至 16，并从输出中提取真实的 12 个 heads，Wafer 实现了 prefill 阶段 2-3 倍的加速，使 AITER MLA prefill ASM 达到约 13k tok/s 的稳态。

社区批评与反驳点

在这些结果公布后，技术社区就方法论和数据呈现方式提出了若干疑虑：

TCO 与定价： 批评者认为，使用每小时云端租赁价格并不反映拥有硬件的组织的 TCO（总拥有成本），也没有考虑到电力成本。
基准测试有效性： 一些用户质疑 1,024-token 输入长度对于现代前沿模型是否是一个相关的基准测试。
对比公平性： 评论者指出，B300 在每一项原始性能指标上都优于 MI355X，且 B200 的对比由于需要多节点设置而处于劣势，这会引入跨节点 all-reduce 开销销。
模型正确性： 有关于 prefill kernel 的零填充优化是否影响了模型的连贯性或正确性，也有一些疑问，尽管目前尚未提供性能下降的证据。

"B300 是单流速度快约 46%，总吞吐量快约 65%。AMD 胜出仅在 Wafer 将吞吐量除以选定的云端租赁价格后... 基准测试无法复现，电力成本缺失，ROCm 补丁已打上..."