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這類開源模型能不能被更多雲廠商低成本採購，本身就決定了它能不能跟閉源模型搶使用者。
輝達沒有變弱，但已經改變了的，是追上它所需要的時間。 (量子位)