AMD MI355X推理Kimi K3：吞吐量超NVIDIA，首字优化显著

近期，有技术团队在AMD MI355X加速卡上完成了Kimi K3大模型的部署，这一测试结果引发了行业对AI加速硬件选型的重新思考。原本需要16张NVIDIA B200、横跨两台服务器才能稳定运行的模型，如今仅需一台搭载8张MI355X的AMD服务器即可完成部署。

在输入1024 Token、输出400 Token的标准测试中，MI355X实现了952 Token/s的总吞吐量，单用户生成速度达到118 Token/s。按单节点计算，其吞吐量约为16卡B200方案的3.8倍，综合性价比也超过了B200和B300两款热门加速卡。更值得关注的是，本次ROCm的适配过程出乎意料地顺畅，没有出现以往常见的大量繁琐适配工作。

万亿参数模型时代，显存优先级超越算力

Kimi K3拥有2.8万亿参数，仅模型权重本身就需要超过1.5TB的显存空间，还未计算百万Token上下文所需的KV Cache缓存。8卡B200服务器单卡配备192GB显存，总容量约为1.5TB，仅能勉强放下模型权重，根本无法预留KV Cache所需的空间，因此必须使用两台服务器、16张GPU才能完成部署。

B300单卡配备288GB显存，可以在单节点内完整部署模型，巧合的是，AMD MI355X同样拥有288GB单卡显存，8张MI355X合计总显存约2.3TB，仅需一台服务器即可完成Kimi K3的部署。

跨节点运行的额外成本不容忽视：模型在多台服务器间部署时，每生成一个Token都需要通过网络同步数据，即使使用195Gb/s的RoCE v2高速网络，跨节点通信依然会拖慢解码速度。MI355X凭借更大的单卡显存，将整个模型留在了单节点内，彻底避免了这类通信开销。

从最终测试数据来看，8张MI355X的峰值总吞吐量达到952 Token/s，单路生成速度为118 Token/s。作为对比，16张B200的双节点部署总吞吐量为498 Token/s，换算到单节点约为249 Token/s，也就是说MI355X的单节点吞吐量约为B200双节点平均单节点吞吐量的3.8倍。单用户生成速度方面，MI355X的118 Token/s也高于B200的90 Token/s。

B300依然是绝对性能最高的方案：8张B300的节点总吞吐量达到1568 Token/s，单路生成速度为172 Token/s，整体吞吐量大约是MI355X的1.65倍。但价格因素改变了最终的选型结论：按照测试团队的假设，MI355X每卡每小时2.5美元、B200为4.25美元、B300为6美元，那么MI355X每美元可以提供约48 Token/s的峰值吞吐量，B200约为7 Token/s，B300约为33 Token/s。虽然B300的性能更强，但MI355X的单位成本效率更高，对于需要大规模运行开放模型的数据中心来说，这可能比单纯争夺性能冠军更加重要。

首Token等待优化：简单补零解决大问题

当然，推理服务的性能指标并不只有吞吐量，TTFT（首Token生成时间）也是直接影响用户体验的关键指标。在这一项上，MI355X最初的表现并不理想：面对一段约17.2万Token的冷启动预填充任务，MI355X需要约51秒才能完成，而B300仅需约23秒。

在支持百万Token上下文的大模型中，长上下文的预填充任务体量往往非常庞大，如果用户每次发起请求都需要等待数十秒才能看到第一个生成的Token，再高的解码速度也很难弥补用户体验上的缺陷。

测试团队最终发现，性能差距几乎全部来自一个注意力内核：Kimi K3在8路张量并行配置下，每张GPU会分到12个注意力头，而AMD AITER中速度较快的MLA预填充内核，仅支持4、8或16的倍数的头数形状。由于12个头无法匹配现有高速内核的要求，系统只能回退到速度较慢的通用Triton实现。

解决办法非常朴素：将12个注意力头补零到16个，调用现有的高速内核，计算完成后再取回真正需要的12个头。整个过程没有修改模型结构，也没有编写新的汇编内核，仅通过补四个零就完成了优化。

优化后，AITER MLA内核的稳定预填充速度达到约1.3万Token/s，而原来的Triton回退路径仅能达到4000~7000 Token/s，冷预填充时间因此缩短了约两到三倍。这项优化不会改变最终的解码吞吐量，但会显著减少用户等待第一个Token出现的时间。这也说明，AMD和NVIDIA之间看起来很大的软件差距，很多时候并不是底层能力不足，只是现有高速内核暂时没有覆盖某种新的模型形状。

ROCm适配迎来突破，软件壁垒不再高不可攀

长期以来，AMD数据中心GPU最大的问题往往不在于硬件性能，而在于软件生态。同样的模型在CUDA环境下可以直接运行，但迁移到ROCm时，通常需要修改框架、补充算子，甚至重写底层内核代码，这成为了不少用户选择AMD加速卡的阻碍。

但本次Kimi K3的适配情况出现了明显改观：AMD为该模型提供了接近首发同步的技术支持，测试团队表示，模型基本可以直接在MI355X上运行，后续仅需处理少量兼容性问题和针对性的性能优化工作。

本次适配中遇到的一个小问题出现在推测解码环节：Kimi K3本身没有提供MTP或EAGLE所需的草稿模型参数，测试团队因此使用了一个外部的块扩散草稿模型。这套方案在CUDA环境下可以直接运行，但在ROCm环境中，首次真实请求就触发了调度器报错，原因是ROCm分支中缺少一个名为`top_k_renorm_prob`的函数。该函数的功能并不复杂：从概率分布中选出最高的k个值，将其余概率归零后，再对保留下来的概率进行重新归一化。

测试团队最终使用一个普通的PyTorch函数补上了这段逻辑，无需手写GPU内核，也不需要重新设计整个推测解码系统。修复完成后，推测解码功能让单路性能提升约2.2倍，中等并发下的单流性能提升约1.7倍，峰值总吞吐量则提升了约18%，更重要的是，系统能够在更高并发负载下稳定达到峰值吞吐量。

CUDA护城河仍在，但AMD已找到突破点

单次测试当然不能证明AMD已经全面追上NVIDIA。B200因为显存不足被迫跨节点运行，B300的绝对性能依然领先，ROCm的工具链、框架支持和开发者生态，也仍然不如CUDA完善。

但开放模型正在快速进入万亿参数时代，当模型大到单台服务器无法容纳时，显存容量就不再只是参数表上的数字，而会直接影响通信成本、部署复杂度和最终的推理吞吐量。AMD为单卡配置更大容量HBM的策略，正在转化为实际的系统级优势。

如果AMD能够继续提升ROCm的稳定性、扩大高速内核支持的形状范围，并为新模型提供更及时的首日适配，那么数据中心就必须认真考虑这类GPU：价格更亲民、显存更大、性能满足业务需求，同时软件适配不再需要耗费数月时间。

对于AI加速硬件的未来选型，你有怎样的看法呢？