一家做推理优化的公司Wafer,把GLM-5.2这个大模型塞进AMD的MI355X芯片里,跑出了2626 tok/s/node的饱和吞吐——达到B200实测成绩(3192 tok/s/node)的80%,但硬件成本只有对标芯片B300的约三分之一。单流解码更是跑到213 tok/s。乍看是一次漂亮的性价比翻身仗,但翻开工程细节会发现,这份成绩单更像是极限压榨出来的"最佳个案",而不是AMD硬件的默认水平。

真正有意思的地方不在数字本身,而在这个数字是怎么来的。

从AMD半成品到2626 tok/s,中间隔着什么

AMD其实早就发布了官方的GLM-5.2 MXFP4量化模型和配套的ROCm镜像,Wafer不是从零开始,而是站在这套半成品上继续往前挖。挖出来的第一个坑是MTP权重前缀不匹配:量化工具Quark给主解码器的共享专家层起的名字,和speculative decode模块实际用的前缀对不上,导致系统误判该用4bit精度存权重,结果在读取高精度权重时直接崩溃。Wafer的解法是把同一层的白名单记录复制一份,注册到新前缀下。

第二个坑更隐蔽:深度speculative decode需要的一个融合kernel,代码里写死了CUDA专属头文件,没做ROCm适配判断,导致这套功能在AMD上根本跑不起来。修复方式只是加一行条件编译判断。

这两处修复,加上把并行策略从TP8切换到TP4×DP2打开prefill瓶颈,再手动调优MoE kernel在GLM特定形状下的选择逻辑,最终才把吞吐从最初的1461 tok/s/node一路推到2626。

- 提醒:这些修复都是Wafer团队针对自己这次部署临时打的补丁,目前还看不到证据表明已经合并进官方sglang或ROCm主线,普通用户想复现同样的效果,大概率要重新踩一遍这些坑。

从半成品到2626 tok/s:四道人工补丁 AMD官方 MXFP4模型 1461 tok/s/node 修复MTP 前缀mismatch 解锁spec decode 加ROCm guard补丁 深度speculative TP4×DP2 +调MoE 2626 tok/s/node(饱和吞吐) @ 2.4 RPS,B200的80% 成本约为对标芯片1/3 建立在四道人工补丁之上

独立基准泼的一盆冷水

Wafer自己也承认,AMD/ROCm这套技术栈"很少默认跑出最佳性能",甚至吐槽"能找到一个能跑起来的镜像就算走运"。这句话不是自谦,而是有旁证的。

第三方基准平台SemiAnalysis旗下的InferenceX,针对GLM-5/5.1系列做过对比测试:在没有经过Wafer这种深度定制的默认情况下,B200的每GPU吞吐(1756.3/1287.2/1003.6 tok/s)全面领先MI355X(1368.5/956.5/709.4 tok/s),领先幅度在三成到四成左右。这和Wafer"只慢20%"的叙事明显不在一个起跑线上。

差别就在于,Wafer这次投入的工程量级——修bug、重调kernel、切并行策略——不是任何一个团队都愿意也都有能力复制的。SemiAnalysis测的是开箱表现,Wafer秀的是极限调优后的天花板。两者都真实,但回答的是不同的问题。

AMD的性价比不是免费的,是花工程师的时间换来的

还有一处基准口径值得留意:Wafer拿MI355X和B300比价格(便宜约2.75倍),却拿B200的吞吐数据做性能对照。B300通常比B200更强,如果换成B300的吞吐数字做分母,MI355X的相对劣势大概率会被放大,现在这个"2倍性价比"的结论未必还站得住。

这场反击战里,真正赚钱的是谁

公开渠道能查到的信息显示,GLM-5 MXFP4在MI355X上的sparse MLA解码路径存在已知的ROCm崩溃问题——这和Wafer博客里"运气好才能找到能跑的镜像"的吐槽相互印证。技术路径本身,眼下还谈不上稳定。

这就引出一个更实际的问题:如果AMD的性价比优势,只对具备深度kernel工程能力的少数团队开放,那"AMD更便宜"对大多数想直接部署大模型的中小团队,可能只是一句听起来很美的口号。真正能把这份红利变现的,反而是Wafer这类专门做推理优化的第三方公司——他们靠踩坑攒经验,再把经验打包卖给云服务商或企业客户,这本身正在变成一门独立的生意。

接下来值得盯的是三件事:Wafer这些修复会不会被合并进官方sglang或ROCm主线,让普通用户不用重新踩坑;有没有其他独立机构复现这份2倍性价比的结论;以及换成B300做基准之后,AMD阵营的相对位置到底还能不能站得住。