AMD跑GLM 5.2，成本只要英伟达一半

GLM 5.2，用AMD芯片也能跑出来了，而且成本只要英伟达的一半。

这是推理优化公司Wafer这周公布的一组数据。

Wafer用AMD的MI355X芯片跑最新开源模型GLM 5.2，单节点吞吐做到2626 tok/s，单流吞吐也跑到了213 tok/s。

MI355X这次跑出的吞吐，是同代英伟达旗舰B200的约八成，成本却不到它的一半。

消息发布后，这条推文冲上了Hacker News榜单第二名，评论区里挤满了追问技术细节的同行。

而做出这组数据的公司，只拿到过400万美元的种子轮融资。

两行代码，成本砍到英伟达一半

Wafer是一家专门做推理性能优化的公司。

这周他们在自己的博客里，把GLM 5.2部署到AMD芯片上的整个过程写了下来。

第一步是给模型瘦身，再给瘦身之后的模型挑一个跑得动它的引擎。

瘦身用的方法是量化，Wafer把模型权重从BF16这种精度更高但更占算力的格式，压缩成更省资源的MXFP4格式，用的是AMD自己的Quark工具。

跟z-ai官方的量化方案对比，三项基准测试的精度几乎没有损失，GSM8K从96.5%降到95.5%，GPQA-Diamond从92.2%降到90.3%，tau2反而从81.9%涨到了83.4%。

至于引擎，Wafer在vLLM、ATOM、sglang三个选项里挑，前两个要么让瘦身白做，要么在长文本场景下输出会走样，只有sglang能在保持输出连贯的同时维持量化效果。

量化和引擎都定下来后，下一步是把推理速度再往上提，其中最关键的一步是投机解码，但sglang的ROCm镜像默认不支持，Wafer在这上面卡了两个问题。

第一个问题出在MTP头的权重命名上。

Quark把共享专家层的名字记成了一个固定前缀，但MTP层在sglang里真正用的前缀不一样，量化查找找不到对应的层，就默认把这个本该保留高精度的共享专家也建成了低精度格式，加载时因为形状对不上直接崩溃。

Wafer的解法是把这层的名字，在sglang实际使用的命名下再登记一遍，这一个改动让单流吞吐跳了将近3倍。

第二个问题更小。更深的投机解码配置需要一个融合kernel，这段代码里直接引用了CUDA的头文件，没给ROCm留判断分支，编译就会失败。

解法是加一行编译保护。

两个问题解决后，配合几项配置调整，单流吞吐拉到了213 tok/s。

聚合吞吐是另一套账，20k输入的负载主要卡在prefill阶段，只优化decode不够用。

单流最优的配置在这个负载下只能跑到1461 tok/s/node，Wafer把TP8换成TP4×DP2这种并行方式，进一步把吞吐提到了1944。

Wafer再往下查，发现镜像里GLM 5.2的低精度专家层默认走的是一条没人调过的慢速兜底路径。

AMD自己的kernel库只给fp8路径调过配置，没管fp4。

Wafer按GLM 5.2专家层的实际形状手动指定了对应的kernel，才最终拉到2626 tok/s/node。

这个速度对应的场景贴近真实生产环境，20k输入、1k输出、缓存命中率60%，饱和点在每秒2.4次请求，首token延迟全程压在2.22秒以内，成功率达到100%。

单流场景下，Wafer按ArtificialAnalysis的标准方法，把吞吐做到了213 tok/s。

一家400万美元的公司，凭什么干这活

做出这组数据的Wafer，拿到的种子轮融资只有400万美元，由Fifty Years领投，YC和Liquid2跟投。

天使投资人名单里有Google首席科学家Jeff Dean、OpenAI联合创始人Wojciech Zaremba、Dropbox联合创始人Arash Ferdowsi，这几个名字给这家小公司做了背书。

这个规模的团队，撑死了几十号人，跟英伟达、AMD这种芯片巨头完全不是一个体量。

公司自己的定位是用AI优化AI基础设施，他们在博客里提到，自己能这么快追上模型发布的节奏，靠的是agent在kernel和模型优化上的能力越来越强。

这次帮GLM 5.2排查命名冲突、调kernel选择的工作，相当一部分是靠AI辅助工程完成的。

他们此前在Qwen3.5 397B这个模型上做过类似的适配工作，那次为了追性能自己写了定制kernel。

那次的对手是官方现成的推理引擎，AMD的工具本身没把这个模型的计算模式吃透，逐token解码时同一批GEMM要重复拆成六次kernel调用，每次都要多绕一趟显存。

Wafer的做法是自己写一个融合kernel，把六次调用并成一次，中间不再绕显存，硬是把单次计算效率提到了1.84倍，最终单卡吞吐做到310 tok/s，冲到了ArtificialAnalysis榜单第一。

这次在GLM 5.2上，他们连定制kernel都不需要写了，靠的是在AMD官方生态里排查、修复几处细节。

这个变化本身也是个信号，AMD的软件生态，正在从“每次都要重新造轮子”，往“官方工具链基本能用，只是有几个坑没填”这个方向走。

这也是种子轮公司敢接这种活的原因，如果每次适配都要从零写kernel，几十号人的团队根本追不上模型发布的节奏。

只有当大部分基础设施已经由官方或开源社区搭好，剩下的只是排查具体的兼容性问题，小团队才有机会靠速度取胜。

Wafer干的事，却是英伟达和AMD官方本该抢在模型发布时就干完、却还没干完的适配工作，这中间的时间差，正是Wafer这类公司存在的理由。

英伟达的护城河，正在实时被侵蚀

Wafer在博客里自己写下的判断是，SOTA性能能不能在AMD上跑出来，现在越来越取决于官方支不支持。

用他们原话说，CUDA的护城河正在实时被侵蚀。

这不是Wafer一家的孤例。

独立测试机构SemiAnalysis今年5月的测试里也记录过类似节奏，AMD团队在上一代模型GLM-5上，用了14周时间补齐了同样量级的软件差距，把原本落后的成本曲线拉到反超英伟达。

那次测试里，AMD的MI355X在每用户每秒18个token的交互速度下，跑出了每百万token 0.22美元的成本，同等速度下英伟达B200要0.30美元，差距超过四成。

支撑这个反超的，是AMD单卡每小时1.48美元的整体拥有成本，本来就比英伟达B200的1.95美元低了一截，只是过去这个硬件层面的便宜，一直卡在软件适配没跟上，兑现不出来。

但这次测试只覆盖单节点部署，多节点、大规模集群场景下英伟达仍然占优，Wafer自己在博客里也承认了这一点。

SemiAnalysis也提到，AMD在GLM-5这条线上，还没有跑通多机分布式部署和跨机专家并行这类更复杂的方案，而英伟达靠这类机架级方案，在其他模型上已经跑出过接近三倍的单卡效率提升。

这个差距对普通用户来说不直接可见，但会体现在账单上。

云厂商如果能把Wafer这类适配工作复制到更多开源模型上，推理价格大概率会继续往下探，而GLM这类开源模型能不能被更多云厂商低成本采购，本身就决定了它能不能跟闭源模型抢用户。

英伟达没有变弱，但已经改变了的，是追上它所需要的时间。

参考链接：

[1]https://x.com/wafer_ai/status/2073504623374295099?s=20

[2]https://www.wafer.ai/blog/glm52-amd

[3]https://www.wafer.ai/blog/kernels-are-still-the-moat

文章来自于微信公众号 “量子位”，作者 “量子位”