你有没有注意到我们喜欢AMD？推理的需求正在飞速增长，超出了供给。随着前沿模型几乎每两周发布一次——例如Claude Fable、GLM5.2和Minimax M3——令牌的疯狂只会变得更加疯狂，而Blackwell不足以支持这一切。因此，NVIDIA GPU的价格正在快速上涨，令牌变得非常昂贵。这时AMD出现了。按照平均来说每个GPU的价格便宜约2.75倍（MI355X与B300相比）并且硬件规格相似，便宜推理的解决方案显而易见——这是我们Wafer几个月来一直在宣扬的信息。但是，尽管AMD的Instinct MI350系列在硅层面上与Blackwell竞争，NVIDIA的软件优势和零时支持通常使得供应商能够在他们的硬件上以更少的摩擦更快地提供推理。相反，在MI355X/ROCm堆栈的SOTA性能对于这些前沿模型通常并不能直接达到（有时能！）。实际上，如果你能找到一张能运行它们的镜像，你就已经很幸运了。没有这一零时支持，为最新模型构建和优化可能需要几周的工程和计算能力。到那时，最新模型已经发布，使得AMD总是在追赶。但随着代理在内核和模型优化方面的改进，这一差距正实时缩小。我们Wafer一次又一次地证明了这一点，再次——在20k输入/1k输出、60%缓存命中率的工作负载下，我们在规定的TTFT（≤5秒）下以2626 tok/s/node @ 2.4 rps的总吞吐量，仅达到了B200所测得的性能的80%，尽管价格便宜超过2倍。我们在GLM5.2上单流达到了213 tok/s，输入10k令牌/输出1.5k令牌，遵循人工分析标准，由TensorWave在AMD MI355X上提供。尽管这个数字没有超越AA排行榜，但在每花费一美元的性能上仍然赢得了优势。我们是如何做到的，任何模型工作的第一步是选择量化和框架。我们将基础的bf16 GLM-5.2量化为MXFP4，并使用AMD Quark。与z-ai的官方FP8量化相比，我们的MXFP4是无损的（GPQA-Diamond、tau2、GSM8K）。评估FP8基线MXFP4 Δ（MXFP4−FP8）GSM8K（200q，5-shot，贪心）0.965±0.013 0.955±0.014 −0.010 GPQA-Diamond（198q × 2 seeds，温度1.0）0.9217±0.027 0.9026±0.029 −0.019 tau2宏0.819 0.834 +0.015 关于推理框架，我们有三个选项 - vLLM，ATOM和sglang。在这三个选项中，我们选择了sglang - vLLM没有可行的MXFP4 + GlmMoeDsa路径，因此MXFP4权重没有任何好处，同时ATOM的输出在长上下文中退化。Sglang是与原生支持兼容程度最低的推理引擎，能够利用量化并保持一致性。提高吞吐量的下一个自然步骤是在sglang上启用投机性解码。然而，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 tok/s的单流解码数据。但对于整体吞吐量，尤其是在我们定义的工作负载下，解码优化是必要但不够的。在20k输入时，工作负载主要受预填充限制。在TP8下，这是为单流解码优化的配置，MI355X可以以1461 tok/s/node运行GLM5.2-MXFP4。切换到TP4×DP2对于该工作负载产生了巨大的改善，使我们达到了1944。