在MI355X上运行Kimi K3：每美元性能优于B300
过去几个月，开源大模型的能力突飞猛进。DeepSeek V4-Pro与GLM5.2的智能水平已接近Opus级，开源模型正成为闭源模型的可靠替代方案，兼具性能与成本优势。
但Kimi K3的出现刷新了认知：它有望达到Fable/Sol级的智能水平，标志着开源大模型迈入全新纪元。
不过，模型越智能，体量就越大——大模型的参数规模与能力几乎同步扩张。GLM5.2拥有7530亿参数，DeepSeek V4-Pro达1.6万亿，而Kimi K3更是高达2.8万亿（！！）。仅加载模型权重就需超过1.5TB显存，还未算上支持100万token上下文所需的KV缓存。即便是配备8块GPU的B200节点，也无法容纳Kimi K3。用户只剩两种选择：要么用单GPU显存达288GB的B300节点部署，要么动用两台B200节点（张量并行TP16）。
但你知道还有哪款非NVIDIA GPU拥有288GB显存吗？AMD的MI355X。我们对这款芯片青睐有加：其单GPU平均价格约为B300的1/2.4、B200的1/1.7，硬件规格却与Blackwell系列不相上下，是极具性价比的替代方案。AMD的唯一短板在于软件支持：推理框架的内核速度较慢，且新模型的适配滞后，导致部署前沿大模型需要投入大量工程资源。Wafer团队认为，智能体技术正加速内核与模型优化，不断缩小这一差距。而AMD已为Kimi K3提供了首日适配支持，帮我们省去了大部分工作。
测试结果亮眼：在输入1024token、输出400token的基准测试中，单台MI355X节点的总吞吐量达952token/秒，单流解码速度为118token/秒——总吞吐量是TP16配置双B200节点（两台16GPU节点总吞吐量498token/秒，单节点约249token/秒）的3.8倍以上，单流解码速度是其1.3倍以上。B300节点的总吞吐量仍比MI355X高约1.65倍，但考虑到2.4倍的价格差，MI355X的性价比完胜B300。
| 8× MI355X（TP8） | 2×8 B200（TP16） | B300（TP8+DCP8） | |
|---|---|---|---|
| 单流解码速度 | 118 token/秒 | 90 token/秒 | 172 token/秒 |
| 峰值总吞吐量 | 952 token/秒 | 498 token/秒 | 1568 token/秒 |
| 单GPU峰值吞吐量 | 119 token/秒 | 31 token/秒 | 196 token/秒 |
| 每美元GPU小时峰值吞吐量 | 48 token/秒/美元 | 7 token/秒/美元 | 33 token/秒/美元 |
性价比计算基于以下单价：MI355X 2.50美元/GPU小时，B300 6.00美元/GPU小时，B200 4.25美元/GPU小时。
为B200说句公道话：它的性能数据受跨节点通信拖累——解码关键路径需通过RoCE v2（约195Gb/s）进行全归约操作，是唯一需要跨两台节点部署的配置，因为单台8×192GB节点无法同时容纳Kimi K3的权重与100万token的KV缓存池。但这恰恰印证了核心观点：Kimi K3这类超大规模模型，让MI355X凭借高HBM显存容量，在实用性与性能上首次实现了对B200的反超。
优化过程
Kimi K3虽能直接部署，但要达到当前的吞吐量，仍需一系列优化。
核心手段是 speculative decode（投机解码）。K3自带零草稿张量，无MTP或EAGLE机制，因此只能采用外部块扩散草稿模型：RadixArk的Kimi-K3-DSpark。该模型在CUDA环境下可直接运行，但在ROCm环境中，首次请求就触发调度器报错：
NameError: name 'top_k_renorm_prob' is not defined. Did you mean: 'top_p_renorm_prob'?
sglang的接受采样验证器有两种构建目标分布的方式：一种是调用top_k_renorm_prob的密集路径，另一种是直接调用torch.topk的稀疏快速路径。CUDA版本从sgl_kernel导入top_k_renorm_prob，而ROCm版本仅适配了Triton的top-p内核，未定义top_k_renorm_prob——gfx950架构没有可适配的top-k归一化内核。因此，当请求走密集路径时，验证器就会触发上述NameError，导致调度器崩溃。
修复方案仅需添加一个PyTorch函数。Top-k归一化是个简单操作：提取模型概率向量中前k个最大值，将其余值置零，再将剩余值重新缩放至总和为1。我们通过sort、masked_fill和除法操作实现该逻辑，直接嵌入sglang的ROCm采样分支，实现与CUDA版本sgl_kernel相同的计算效果。无需自定义内核——ROCm环境下人们常默认需要定制内核，但此次问题仅源于缺失定义，而非内核本身。
修复并加固投机解码后，单流性能提升约2.2倍，中等负载下每流性能提升约1.7倍，峰值总吞吐量提升18%。更重要的是，峰值总吞吐量能在更高并发量下达成（开启投机解码后支持c64并发，未开启时仅支持c24）。
预填充优化
人们讨论模型性能时，往往聚焦于解码token速度，但很多时候这只是"虚假繁荣"——解码被过度关注，而用户感知最强烈的"首token生成时间（TTFT）"却常被忽略。
MI355X在这方面存在短板：同样是17.2万token的冷预填充，MI355X耗时约51秒，而B300仅需约23秒。对于支持100万上下文的模型，很多场景会涉及大规模预填充（有时是冷启动），GPU长时间卡在预填充阶段会导致整个节点集群陷入闲置。
性能差距几乎完全源于一个内核。ROCm环境下的K3因无法加载快速AITER MLA预填充内核，只能退而使用较慢的通用Triton注意力内核。问题并非缺少内核，而是形状不匹配：TP8配置的K3每个进程有12个注意力头，而AITER的MLA路径仅支持4、8或16的倍数。修复方案非常简单：将注意力头数从12补零至16，运行快速内核后，再从输出中提取真实的12个注意力头即可。
优化效果显著：同样的17.2万token冷预填充，AITER MLA预填充汇编内核的稳态速度约为13000token/秒，而Triton fallback仅为4000-7000token/秒，预填充速度提升了2-3倍。这一优化针对的是首token生成时间，而非总吞吐量——解码速度不受影响，因此不会改变前文的吞吐量数据，但能大幅缩短用户等待首token的时间。
结论
在MI355X上实现最优性价比的过程相对顺畅。虽遇到一些框架层面的bug，但数量比GLM5.2少，且完全无需自定义内核。
AMD即将追上SOTA（ state-of-the-art，当前最优水平）。CUDA的护城河是否已不复存在？