先说结论：AMD芯片现已能高效运行GLM 5.2模型，性能表现不俗，且部署成本仅为英伟达方案的一半。

本周，推理优化初创公司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。

进一步排查发现，镜像中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%。在单流场景下，按照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这类开源模型能否被更多云厂商低成本采购，本身就决定了它能否与闭源模型争夺用户。

英伟达并未变弱，但真正改变的是，追上它所需要的时间。