从硬件市场的整体趋势来看，AMD 的性价比优势正在变得愈发显著。一个直观的案例是：在 GLM5.2 模型推理场景中，Wafer 团队在 AMD MI355X 上实现了单节点 2626 tok/s 的聚合吞吐量以及 213 tok/s 的单流性能，而部署成本仅为 Blackwell 方案的三分之一以下。
推理需求正以肉眼可见的速度爆发式增长，而供给端完全跟不上节奏。前沿模型几乎每隔一两周就会涌现一个新版本——Claude Fable、GLM5.2、Minimax M3，随便数一数就能列出一长串。Token 热潮只会愈演愈烈，但 Blackwell 的产能根本不足以支撑这一局面。于是 NVIDIA 显卡价格一路飙升，token 成本也随之水涨船高。
就在此时，AMD 强势入局。其单颗 GPU 的平均价格仅为 B300 的约 2.75 分之一，硬件规格却不相上下。低成本推理的答案其实早已摆在台面上——这也是 Wafer 团队数月来反复强调的核心观点。不过，尽管 AMD Instinct MI350 系列在芯片层面能与 Blackwell 相抗衡，NVIDIA 凭借其软件生态和当天上线的支持能力，使得供应商通常能在其硬件上更快、更顺畅地完成推理部署。
反过来看，在 MI355X / ROCm 栈上，这些前沿模型的 SOTA 性能很少能实现开箱即用——当然偶尔也有例外。事实上，能找到一张能跑这些模型的镜像就算相当幸运了。缺乏这种当日支持，为新模型构建和优化环境可能耗费数周的工程与算力。等一切就绪，最新模型又已发布，结果 AMD 总是处于追赶状态。
但随着智能体在内核与模型优化方面持续进步，这一差距正在被实时拉近。Wafer 团队已经反复用实际成果证明了这一点。
本次同样如此：在一个 20k 输入 / 1k 输出、60% 缓存命中率的工作负载下，团队实现了单节点 2626 tok/s 的聚合吞吐量，每秒请求数 2.4，TTFT 的 knee 定义在 ≤5 秒——性能仅比 B200 低 20%，但成本却不到后者的一半。
| 持续请求速率 (RPS) | 单节点聚合吞吐量 (tok/s) | TTFT p50 / p95 | 成功率 |
|---|---|---|---|
| 0.5 | 449 | 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.25 | 2089 | 0.63s / 1.23s | 100% |
| 2.4（饱和点） | 2626 | 0.81s / 2.22s | 100% |
同时，在单流场景下，按照 Artificial Analysis 标准测试，GLM5.2 在 10k 输入 / 1.5k 输出 token 时，跑出了 213 tok/s 的成绩，部署在 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 宏平均 | 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 ，但没有加 ROCm 保护。修复方法很简单：加一条 #ifdef USE_ROCM 的条件编译指令。
两个微小但必要的修改，让推测解码得以充分利用。推测解码正常工作后，再配合一些配置优化（比如 --kv-cache-dtype fp8_e4m3 和 --enable-aiter-allreduce-fusion），单流解码速度就达到了 213 tok/s。
但对于聚合吞吐量，尤其是在所定义的工作负载下，解码优化是必要但不充分的。在 20k 输入且 60% 缓存命中率的情况下，工作负载主要还是受预填充阶段限制。
在 TP8 配置下（这是为单流解码优化的配置），MI355X 运行 GLM5.2-MXFP4 能达到 1461 tok/s/节点。切换到 TP4×DP2 后，该工作负载的性能有了巨大提升，在 2.0 RPS 下达到了 1944 tok/s/节点——但与测得的 Blackwell 性能（3.0 RPS 下 3192 tok/s/节点）相比还是偏慢。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/节点。这一进步相当明显。
这为什么重要
虽然过程中遇到了一些摩擦，但在 MI355X 上实现最佳性价比其实并不特别困难——尽管有框架层面的 bug。但和之前对 Qwen3.5 397B 的工作不同，你会发现这次团队并没有编写任何自定义内核。本次研究虽然没有考虑多节点性能，但单节点部署在实际应用中仍然非常普遍。
AMD 的 SOTA 性能正在更多地取决于支持能力，而不仅仅是软件本身。CUDA 的护城河，正在被一点点侵蚀掉。