AI 推理服务商 Wafer 于 8 月 2 日公布了在 AMD MI355X 上运行 Kimi K3 的完整 benchmark 数据。在 1,024 token 输入、400 token 输出的测试条件下，单节点 8×MI355X（TP8）达到 952 tok/s 聚合吞吐和 118 tok/s 单流解码，每 GPU 小时的每美元性能为 48 tok/s/$——是 B300（33 tok/s/$）的 1.45 倍，B200（7 tok/s/$）的 6.9 倍。
这一结果的核心驱动力并非算力，而是 HBM 容量。Kimi K3 是月之暗面发布的开源 MoE 模型，总参数 2.8 万亿，激活约 1,030 亿参数/Token。模型权重约 1.56 TB，加上 1M Token 上下文的 KV cache 等运行时状态，单 GPU 内存需求远超 B200 的 192GB HBM——B200 必须跨两台节点以 TP16 部署，在 decode 关键路径上支付跨节点 all-reduce 的延迟代价。而 MI355X 的 288GB HBM3e 允许 K3 在单个 8 GPU 节点内完成推理，省去了跨节点通信瓶颈。
这是 Wafer 继 6 月在 MI355X 上运行 GLM5.2（753B 参数，2,626 tok/s/node）之后，第二次用 AMD 硬件挑战 NVIDIA 的推理性价比优势。但与 GLM5.2 那次不同，K3 的规模使 HBM 容量从「锦上添花」升级为「部署刚需」——它不是在比谁跑得更快，而是在比谁能跑。
三组数据中的容量逻辑
Wafer 公布的三组配置对比，每个数字背后都指向同一个约束：
| 指标 | 8×MI355X TP8 | 2×8 B200 TP16 | B300 TP8+DCP8 |
|---|---|---|---|
| 单流 decode (tok/s) | 118 | 90 | 172 |
| 峰值聚合 (tok/s) | 952 | 498 | 1,568 |
| 每 GPU 聚合 (tok/s) | 119 | 31 | 196 |
| 每美元性能 (tok/s/$) | 48 | 7 | 33 |
价格假设：MI355X $2.50/GPU-hr，B300 $6.00/GPU-hr，B200 $4.25/GPU-hr。数据来自 Wafer 引用 GPUs.io 的实时定价。
B200 的惨淡数字——每 GPU 仅 31 tok/s——不是因为硅本身慢，而是因为模型放不进单节点。跨节点 TP16 意味着 decode 每一步都要走 RoCE v2 网络做 all-reduce，实际可用带宽约 195 Gb/s，远低于 NVLink 域内的 GPU 间通信。B200 承担了它设计时未曾预料的负载。
B300 的情况更值得琢磨。NVIDIA 将 B300 的 HBM 从 B200 的 192GB 提升到 288GB——与 MI355X 持平——这本身就说明 NVIDIA 清楚容量是关键瓶颈。B300 在绝对吞吐上仍领先 MI355X 约 65%（1,568 vs 952 tok/s），但价格差距更大：按 Wafer 引用的价格，B300 每 GPU 小时约 $6.00，是 MI355X $2.50 的 2.4 倍。这个价差使 MI355X 在每美元吞吐上反超。
需要指出的是，价格数据存在波动。GPUs.io 在 8 月初显示 MI355X 最低约 $2.95/GPU-hr（TensorWave），B300 最低约 $5.63/GPU-hr（Vast.ai 等）。按这些更保守的市场价格计算，MI355X 的每美元优势会缩窄但仍成立。Wafer 使用的是自身能拿到的合约价格，不代表所有采购方都能复现同一性价比。
软件适配：从崩溃到可用只改了两行逻辑
Wafer 的工程叙事同样值得关注。与半年前在 MI355X 上跑 Qwen3.5 397B 时需要从零编写自定义内核不同，这次适配 K3 的问题出在软件栈的边际——不是缺能力，而是缺覆盖。
Speculative decode 修复：K3 本身不提供原生的推测解码（无 MTP、无 EAGLE），Wafer 使用 RadixArk 的开源草稿模型 Kimi-K3-DSpark。在 ROCm（AMD 的 GPU 编程平台）上首次请求即崩溃——sglang 的 accept-sampling 验证器找不到 top_k_renorm_prob 函数，因为 ROCm 构建中只提供了 top-p 重归一化核，遗漏了 top-k 版本。修复不涉及编写新内核：用 PyTorch 原语（sort → masked_fill → divide）实现了等价计算直接嵌入 sglang 的 ROCm 采样分支。
修复后，推测解码带来约 2.2 倍单流吞吐提升、1.7 倍中等负载吞吐提升，峰值聚合吞吐增加 18%。
MLA prefill 加速：K3 的 Gated Multi-head Latent Attention（MLA）层在冷启动 prefill 时是性能瓶颈。MI355X 上 172K token 冷 prefill 需 51 秒，而 B300 仅需 23 秒——差距超过 2 倍。问题出在 AMD AITER 快速 MLA prefill 内核的形状不匹配：K3 在 TP8 下每 rank 分配 12 个 attention head，但该内核只支持 4、8 或 16 的倍数。修复方式是用零填充把 12 补齐到 16，运行快速内核后再提取真实的 12 个 head。
修复后，MLA prefill 的内核吞吐从 4–7K tok/s 提升到约 13K tok/s，prefill 加速约 2–3 倍。
两个修复都不到十行代码。这与 AMD 社区过去一年在 ROCm 栈上的投入直接相关：sglang 和 vLLM 对 AMD GPU 的支持已从「能跑」进化到「接近开箱即用」，剩余问题集中在测试覆盖边界而非架构缺失。AMD 为 K3 提供了 day-0 部署支持（通过 ATOM 框架和 Docker 镜像），进一步降低了适配门槛。
51 秒 prefill：容量优势的另一面
尽管 288GB HBM 帮助 MI355X 在每美元吞吐上领先，但 51 秒的冷启动 TTFT（Time to First Token）是一个不能忽略的 trade-off。对于需要大段 prefill 的场景——比如长文档摘要、代码库级问答、RAG 中的全量库检索——用户感知的等待时间可能严重影响体验。Wafer 的 prefill 优化将差距从更差的基线缩小到约 2 倍，但未完全抹平。
在 B300 上，相同 172K token 冷 prefill 仅需 23 秒。这个差距部分来自 AMD 的 prefill 内核成熟度，部分来自 NVIDIA 在 attention 计算的硬件-软件协同优化上多年的积累。对于 prefill-heavy 的工作负载，B300 的绝对延迟优势可能压倒 MI355X 的性价比优势——具体取决于延迟 SLA 和用户对价格的敏感度。
意味什么，不意味什么
Wafer 的数据点首先是一个工程信号：对于 2T+ 参数的超大规模 MoE 模型，HBM 容量已经取代 FLOPS 成为推理部署的第一约束。在这个约束下，MI355X 的单节点部署能力是一个真实的架构优势，而不是营销话术。
但它不是 AMD 已经「赢了」推理市场的证据。原因有三：
第一，数据来源单一。Wafer 自己是 MI355X 推理服务商，benchmark 条件（1,024/400 token）是受控的合成负载，非真实生产流量。没有独立第三方在相同硬件上用相同模型做过 head-to-head 验证。
第二，绝对性能仍落后。B300 在聚合吞吐上领先 MI355X 约 65%，在 prefill 延迟上领先约 2 倍。对于追求绝对响应速度、而非极致性价比的客户，NVIDIA 仍然是没有替代选项的选择。
第三，供应量不透明。AMD 的 MI355X 实际出货量和云上可获得容量远不及 NVIDIA Blackwell 系列。价格优势如果无法伴随可扩展的供给，就只是纸面优势。
NVIDIA 已经在用 B300 的 288GB HBM 做出回应，预计 2026 年下半年 Rubin 平台将进一步推高容量门槛。AMD 的窗口期取决于它在 MI400 系列上能多快把容量优势与 prefill 延迟和软件生态的剩余差距一起关闭。
下一项关键变量
最值得观察的不是 Wafer 的 48 tok/s/$ 数字本身，而是接下来几个月中，是否会出现使用 MI355X 运行 K3 或同规模模型的第三方生产级 benchmark。如果独立数据能复现 Wafer 的性价比优势，且 prefill 延迟差距能在 AITER、sglang 和 vLLM 的后续版本中继续压缩，那么超大模型推理的硬件选型逻辑确实会从「默认 NVIDIA」转向需要实际算账的多供应商评估。在那之前，这个数据点说明可能性，但还不构成论据。