性能每美元成本：AMD 正在追赶，但仍有摩擦
你有没有发现，我们格外看好AMD？
当下推理需求呈爆炸式增长，供给早已跟不上节奏。前沿模型几乎隔周就有新品发布——比如Claude Fable、GLM5.2、Minimax M3等——令牌热潮愈演愈烈，但NVIDIA Blackwell系列GPU产能不足，根本无法支撑如此庞大的需求。这直接导致NVIDIA GPU价格飞涨，令牌成本也随之水涨船高。
这时AMD的价值就凸显出来了。以MI355X对比B300为例，AMD GPU平均单价仅为NVIDIA的约1/2.75，硬件规格却不相上下。低成本推理的解决方案其实就在眼前——这也是Wafer团队数月来一直倡导的观点。不过，尽管AMD Instinct MI350系列在芯片层面能与Blackwell抗衡，但凭借软件优势和「首日支持」能力，NVIDIA硬件通常能让服务商更快、更顺畅地部署推理任务。
相比之下，在MI355X搭配ROCm的架构上，前沿模型往往无法「开箱即用」地达到SOTA性能（偶尔也有例外！）。事实上，能找到一个能运行这些模型的镜像就已经算幸运了。没有首日支持，针对最新模型的构建与优化可能需要数周的工程投入和算力消耗，等完成时，新一代模型又已发布，导致AMD始终处于追赶状态。
不过，随着智能体在核函数与模型优化上的能力提升，这一差距正在实时缩小。Wafer团队已多次验证了这一点。
我们再用一组数据佐证：在输入20k令牌、输出1k令牌、缓存命中率60%的负载下，我们实现了单节点总吞吐量2626令牌/秒，请求速率2.4 rps，且拐点响应时间（TTFT）≤5秒。尽管性能仅为B200的80%，但MI355X的价格却不到B200的一半。
| 持续请求速率（RPS） | 单节点总吞吐量（令牌/秒） | 响应时间中位数/95分位（TTFT） | 成功率 |
|---|---|---|---|
| 0.5 | 449 | 0.59秒 / 0.60秒 | 100% |
| 1.0 | 974 | 0.60秒 / 0.81秒 | 100% |
| 1.5 | 1913 | 0.62秒 / 1.03秒 | 100% |
| 2.0 | 1944 | 0.62秒 / 1.05秒 | 100% |
| 2.25 | 2089 | 0.63秒 / 1.23秒 | 100% |
| 2.4（饱和状态） | 2626 | 0.81秒 / 2.22秒 | 100% |
我们还按照Artificial Analysis标准，在TensorWave提供的AMD MI355X算力上测试了GLM5.2：单流输入10k令牌、输出1.5k令牌的场景下，吞吐量达到213令牌/秒。这一数值虽未登上AA榜单榜首，但在「性价比」指标上胜出。
优化方法详解
处理任何模型的第一步，都是选择量化方案与框架。我们用AMD Quark工具，将bf16精度的基础版GLM-5.2量化为MXFP4格式。对比z-ai官方的FP8量化方案，我们的MXFP4实现了无损量化（测试数据集：GPQA-Diamond、tau2、GSM8K）。
| 评估任务 | FP8基准线 | MXFP4 | 差值（MXFP4 − FP8） |
|---|---|---|---|
| GSM8K（200题，5-shot，贪心解码） | 0.965 ± 0.013 | 0.955 ± 0.014 | −0.010 |
| GPQA-Diamond（198题×2随机种子，温度1.0） | 0.9217 ± 0.027 | 0.9026 ± 0.029 | −0.019 |
| tau2 macro | 0.819 | 0.834 | +0.015 |
推理框架方面，我们有三个选项：vLLM、ATOM和sglang。最终选择了sglang——vLLM没有可用的MXFP4 + GlmMoeDsa路径，MXFP4权重无法发挥作用；ATOM在长上下文场景下输出质量会下降；而sglang是原生支持门槛最低的推理引擎，既能利用量化优势，又能保证输出连贯性。
提升吞吐量的下一步自然是在sglang中启用 speculative decode（投机解码）。不过，sglang的ROCm镜像默认不支持该功能，需要两处修复才能让MTP（多令牌预测）正常工作。
第一处：MTP头层与其他层一样，将共享专家参数存储为bf16格式，而非MXFP4。但MTP头层的模块前缀与主解码器栈不一致——Quark将bf16共享专家命名为model.layers.78.mlp.shared_experts.*，而MTP层实际使用的前缀是model.decoder.*。由于前缀不匹配，sglang的量化查找失败，默认将该共享专家按MXFP4格式构建，加载时会尝试把全宽度的bf16权重读入半宽度的4位插槽，最终因形状不匹配导致初始化崩溃。Quark会将无需量化的权重记录为层名列表，因此我们将第78层的条目复制一份，改用sglang实际识别的解码器名称加入列表。修复后投机解码功能正常启用，单流吞吐量提升了近3倍。
第二处：深度投机解码（比如z-ai推荐的5/1/6配置）仍无法使用。因为当草稿深度≥4时所需的融合多步元数据核函数中，写有#include <cuda_runtime.h>语句，却没有添加ROCm条件编译保护。修复方法很简单：添加一行#ifdef USE_ROCM保护指令。
两处微小但关键的修改后，我们得以充分利用投机解码的优势。再配合若干配置优化（如--kv-cache-dtype fp8_e4m3和--enable-aiter-allreduce-fusion），最终实现了前文提到的213令牌/秒的单流解码吞吐量。
但要提升总吞吐量，尤其是在我们设定的负载场景下，仅靠解码优化还不够。在输入20k令牌、缓存命中率60%的场景中，性能瓶颈主要在于预填充阶段。
针对单流解码优化的TP8配置下，MI355X运行GLM5.2-MXFP4的单节点吞吐量为1461令牌/秒。切换为TP4×DP2配置后，该负载下的性能大幅提升，在2.0 RPS时达到1944令牌/秒——但与我们测试的Blackwell性能相比仍有差距：Blackwell在3.0 RPS时能达到3192令牌/秒。MI355X预填充性能不佳的重要原因是，在sglang镜像中，GLM-5.2的fp4 MoE（混合专家模型）默认使用了速度较慢的FlyDSL启发式 fallback（aiter仅针对a8w8/fp8路径提供了调优配置）。我们针对GLM的fp4参数形状（model_dim 6144, moe_inter 2048, E=256, topk=8）自行调优了MoE核函数选择逻辑，最终在2.4 RPS时实现了2626令牌/秒的单节点吞吐量，性能提升显著。
这项成果的意义
尽管过程中遇到了一些阻碍，但在MI355X上实现最优性价比并非难事——除了框架相关的bug，我们并未像优化Qwen3.5 397B时那样编写自定义核函数。虽然本研究未考虑多节点性能，但单节点部署在实际场景中仍极为普遍。
如今，要在AMD硬件上实现SOTA性能，核心已不在于软件开发，而在于生态支持。NVIDIA凭借CUDA构建的壁垒正在被实时打破。