性价比不断提升，成本不断降低

# 每美元性能越来越快且更便宜 | Wafer 来源：https://www.wafer.ai/blog/glm52-amd 你注意到我们喜欢 AMD 吗？推理需求正在飙升，且供应持续吃紧。前沿模型几乎每隔一周就发布一次——Claude Fable、GLM5.2 和 Minimax M3 只是其中几个——令牌热潮只会愈演愈烈，而 Blackwell 的产量根本不足以支撑。因此，NVIDIA GPU 价格飞速上涨，令牌变得极其昂贵。此时 AMD 登场了。每块 GPU 平均便宜约 2.75 倍（MI355X 对比 B300），硬件规格旗鼓相当，廉价推理的解决方案其实就藏在眼前——这一信息 Wafer 已经宣扬了数月。然而，尽管 AMD 的 Instinct MI350 系列在芯片层面与 Blackwell 竞争，NVIDIA 的软件优势与 day-0 支持通常让提供商能在其硬件上以更快的速度、更低的摩擦提供服务。相反，在 MI355X / ROCm 栈上，这些前沿模型要达到 SOTA 性能几乎不可能开箱即用（有时确实可以！）。事实上，能找到一份能运行它们的镜像就算幸运了。没有这种 day-0 支持，针对最新模型进行构建和优化可能需要数周的工程和计算时间。到那时，最新模型早已发布，导致 AMD 总是处于追赶状态。但随着智能体在内核与模型优化方面的进步，这一差距正在实时缩小。在 Wafer，我们一次又一次地证明了这一点。再次——在一个 20k 输入 / 1k 输出、60% 缓存命中率的工作负载上，我们实现了 2626 tok/s/node @ 2.4 rps 的聚合吞吐量，定义的拐点 ≤5s TTFT——仅为 B200 测量性能的 80%，但成本却便宜超过 2 倍。 | 持续 RPS | 聚合 tok/s/node | TTFT p50 / p95 | 成功率 | |-----------|------------------|----------------|--------| | 0.5 | 490 | 0.59s / 0.60s | 100% | | 1.0 | 974 | 0.60s / 0.81s | 100% | | 1.5 | 1913 | 0.62s / 1.03s | 100% | | 2.0 | 1944 | 0.62s / 1.05s | 100% | | 2.2 | 2089 | 0.63s / 1.23s | 100% | | **2.4（饱和）** | **2626** | **0.81s / 2.22s** | **100%** | 我们还以 10k 输入令牌 / 1.5k 输出令牌的单流方式，在 GLM5.2 上达到了 213 tok/s，遵循 Artificial Analysis 标准（https://artificialanalysis.ai/methodology/performance-benchmarking），并由 TensorWave 的 AMD MI355X 容量提供服务。虽然这个数字没有登上 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 上启用推测解码。然而，sglang ROCm 镜像并不原生支持该功能。在 MTP 正常工作前需要两个修复。首先，MTP 头与其他每一层一样，将其单一共享专家以 bf16 存储，而非 MXFP4。但 MTP 头注册在了与主解码器栈不同的模块前缀下（Quark 将其 bf16 共享专家命名为 `model.layers.78.mlp.shared_experts.*`，而 MTP 层的实际前缀是 `model.decoder.*`）。由于不匹配，sglang 的量化查找失败，并默认将该共享专家构建为 MXFP4。加载时随后尝试将全宽 bf16 权重读入半宽 4-bit 槽位，初始因形状不匹配崩溃。Quark 将未量化的权重记录为一个层名列表，因此我们将第 78 层条目以 sglang 实际使用的解码器名称再次复制到该列表中。这一修复解除了推测解码的阻塞，使单流吞吐量获得了接近 3 倍的提升。 其次，深度推测解码（例如 z-ai 建议的 5/1/6 配置）仍然受阻。用于草稿深度 ≥4 的融合多步元数据内核写入了 `#include ` 而没有 ROCm 防护。修复：添加一个 `#ifdef USE_ROCM` 防护。两个微不足道但必要的更改，以充分利用推测解码。 在推测解码正常工作的基础上，加上一些配置优化（例如 `--kv-cache-dtype fp8_e4m3` 和 `--enable-aiter-allreduce-fusion`），我们达到了标题中的单流解码数字：213 tok/s。 但对于聚合吞吐量，特别是在我们定义的工作负载下，解码优化是必要但不充分的。在 20k 输入 @ 60% 缓存的情况下，工作负载主要受预填充限制。在 TP8（为单流解码优化的配置）下，MI355X 能以 1461 tok/s/node 运行 GLM5.2-MXFP4。切换到 TP4×DP2 后，这一工作负载获得了巨大提升，达到 2.0 RPS 时 1944 tok/s/node——与我们在 Blackwell 上测量的性能（3.0 RPS 时 3192 tok/s/node）相比仍然相对较慢。MI355X 上预填充性能不佳的一个重要原因是，在 sglang 镜像上，GLM-5.2 的 fp4 MoE 默默运行在慢速的 FlyDSL 启发式回退上（aiter 只为 a8w8/fp8 路径提供了调优的配置）。我们自行针对 GLM 的 fp4 形状（`model_dim 6144, moe_inter 2048, E=256, topk=8`）调优了 MoE 内核选择，从而在 2.4 RPS 时达到了 2626 tok/s/node。好得多了。 ## 为什么这很重要 尽管存在一定程度的摩擦，但在 MI355X 上实现最佳每美元性能比并不特别困难——虽然存在一些框架相关的 bug，但与我们在 Qwen3.5 397B 上的工作不同，你会注意到这次我们实际上没有编写任何自定义内核。尽管本研究未考虑多节点性能，但单节点部署在实践中仍然非常普遍。AMD 上的 SOTA 越来越是支持问题，而非软件问题。CUDA 护城河正在实时侵蚀。