机器之心编辑部

(资料图片)

这可能是 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 上，可能就要改框架、补算子，甚至重写底层内核。

但 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 的稳定性、扩大高速内核的形状支持，并为新模型提供更及时的首日适配，那么数据中心就必须认真考虑这些 GPU。价格更低，显存更大，性能够用，软件也不再需要折腾几个月。

对此你怎么看？

https://x.com/wafer_ai/status/2083628389903315406

https://x.com/ChiragAsarpota/status/2083864019870634151

关键词： amd gpu 服务器 多模态 kimi cuda nvidia