这或许是 AMD 期待已久的重要时刻。
最近，Wafer AI 在 AMD MI355X 上成功部署了 Kimi K3，结果相当亮眼：原本需要 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.5 TB 显存，这还没有算上百万 Token 长上下文所需的 KV Cache。
一台 8 卡 B200 服务器中，每张卡配备 192 GB 显存，总显存容量约为 1.5 TB。仅装下模型权重都已经非常吃紧，更不用说为 KV Cache 预留空间。因此，B200 必须依赖两台服务器、16 张 GPU 才能完成部署并运行。
B300 每张卡拥有 288 GB 显存，因此可以在单节点中容纳整个模型。巧合的是，AMD MI355X 同样配备 288 GB 显存，8 张 MI355X 总计约 2.3 TB，一台服务器就足够承载这一大模型推理任务。
这不仅仅是少用一台服务器那么简单。模型一旦跨节点运行，每生成一个 Token，都可能需要通过网络进行同步。即便使用约 195 Gb/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 倍。
但当价格因素被纳入比较后，结论就完全不同了。Wafer 按照 MI355X 每卡每小时 2.5 美元、B200 为 4.25 美元、B300 为 6 美元进行测算。在这一价格假设下，MI355X 每美元可提供约 48 Token/s 的峰值吞吐量；B200 约为 7 Token/s；B300 约为 33 Token/s。
B300 的速度更快，但 MI355X 在单位成本上的推理效率明显更高。对于需要大规模部署开源大模型、追求数据中心推理成本优化的企业来说，这可能比单纯争夺性能第一更加重要。
更意外的是，ROCm 基本可以直接使用
长期以来，AMD 数据中心 GPU 面临的最大问题，往往不是硬件规格，而是软件生态。同一个模型在 CUDA 平台上可能可以直接运行，但迁移到 ROCm 后，往往需要修改框架、补齐算子，甚至重写底层 GPU 内核。
但 Kimi K3 这次的情况有所不同。AMD 为该模型提供了接近首发同步的支持。Wafer 表示，模型基本可以直接运行在 MI355X 上，后续工作主要集中在少量兼容性修复和性能优化方面。
其中一个问题出现在推测解码环节。由于 Kimi K3 本身没有提供 MTP 或 EAGLE 所需的草稿模型参数，因此 Wafer 采用了一个外部的块扩散草稿模型。这套方案在 CUDA 上可以直接运行，但在 ROCm 环境中，第一个真实请求就触发了调度器报错。根本原因是 ROCm 分支中缺少一个名为 top_k_renorm_prob 的函数定义。
这个函数本身逻辑并不复杂：从概率分布中挑选最高的 k 个值，将其余概率置零，再对保留下来的概率进行重新归一化。Wafer 最终使用一个普通的 PyTorch 函数补上了这段逻辑，不需要手写 GPU 内核，也不需要重新设计整套推测解码系统。
修复完成后，推测解码让单路性能提升了约 2.2 倍，中等并发场景下的单流性能提升了约 1.7 倍，峰值总吞吐量则提高了约 18%。
更重要的是，整个系统能够在更高并发条件下达到峰值吞吐量。
首字响应太慢，最后只补了四个零
当然，吞吐量并不是大模型推理服务的全部。对于真实用户体验来说，另一个非常关键的指标是 TTFT，也就是从发送请求到看到第一个 Token 之间的等待时间。
在这一指标上，MI355X 最初的表现并不理想。面对一段约 17.2 万 Token 的冷启动预填充任务时，MI355X 需要约 51 秒，而 B300 只需约 23 秒。
在支持百万 Token 上下文的大模型场景中，预填充任务可能极其庞大。如果处理长上下文时，用户每次都要先等待几十秒甚至更久，那么即使后续解码速度再高，也很难完全弥补实际体验上的不足。
Wafer 最终发现，这一性能差距几乎全部来自一个注意力内核。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，因此冷预填充时间缩短了约两到三倍。这项优化不会改变最终的解码吞吐量，但会显著缩短用户看到第一个字的等待时间。
这也说明，AMD 与 NVIDIA 之间看似很大的软件差距，有时并不完全是底层能力不足，而只是现有高速内核暂时还没有覆盖某些新模型形状。
CUDA 的护城河仍在，但缺口已经出现
一次测试当然还不能证明 AMD 已经全面追上 NVIDIA。B200 因为显存不足，不得不跨节点运行；B300 的绝对性能依旧领先；而 ROCm 的工具链、框架支持以及开发者生态，也仍然不如 CUDA 成熟。
但随着开源大模型快速迈入万亿参数时代，当模型大到单台服务器无法完整装下时，显存容量就不再只是规格表上的数字，而会直接影响通信成本、部署复杂度以及最终推理吞吐量。AMD 为单卡配置更多 HBM 显存的策略，正在逐渐转化为真正的系统级优势。
如果 AMD 能继续提升 ROCm 的稳定性，扩大高速内核的形状支持范围，并为新模型提供更及时的首日适配，那么数据中心在选择 AI GPU 时就必须认真考虑这些方案。价格更低、显存更大、性能足够，而且软件适配也不再需要折腾几个月。
对此你怎么看？
参考链接：
https://x.com/wafer_ai/status/2083628389903315406
https://x.com/ChiragAsarpota/status/2083864019870634151