根據《The Chosun Daily》報導，企業 AI 市場過去主要由 OpenAI、Anthropic 和谷歌（Google）等美國領先模型主導。但分析師觀察到，中國開源 AI 模型因其價格競爭力，正日益受到美國企業基礎設施的青睞。
Coinbase 目前正實驗性地將北京智譜華章科技有限公司（Zhipu AI）的 GLM 5.2 與月之暗面（MoonShot AI）的 Kimi 2.7 等開放權重模型，設為內部 AI 工具的預設選項。雖然工程師仍可自行選擇其他模型，但改用較便宜的中國模型作為預設，能有效降低成本。數據顯示，Zhipu AI 的 GLM 5.2 每 100 萬個 Token 僅需 4.4 美元，約為 OpenAI 的 GPT-5.5 模型（15 美元）成本的 30%。
https://tw.stock.yahoo.com/news/coinbase-%E6%8E%A1%E4%B8%AD%E5%9C%8B-ai-%E6%A8%A1%E5%9E%8B%E7%82%BA%E9%A0%90%E8%A8%AD%E5%B7%A5%E5%85%B7-%E5%A4%A7%E5%B9%85%E9%99%8D%E4%BD%8E%E7%87%9F%E9%81%8B%E6%88%90%E6%9C%AC-034325860.html
個人積分：5148分
文章編號：93321486
個人積分：1001分
文章編號：93324492
Wafer.ai的工程師找到了如何在 @AMD MI355X 上運行 GLM 5.2 的方法，並跑出每節點 2626 tok/s 的吞吐量與 213 tok/s 的單串流速度，而成本比 Blackwell 低了 2 倍以上
這相當於用不到一半的成本（便宜 2 倍以上），就達到了 B200 約 80% 的吞吐量
~~~~~~~~~
https://www.wafer.ai/blog/glm52-amd
2026 年 7 月 3 日
作者：Ian Ye
性價比（Performance per dollar）正變得更快、更便宜
我們如何利用 AMD MI355X 以每節點 2626 tok/s 的吞吐量和 213 tok/s 的單串流速度運行 GLM5.2，且成本比 Blackwell 低了 2 倍以上。
你注意到我們喜歡 AMD 了嗎？
推論的需求正在呈爆炸式增長，並已遠遠超過供給。隨著前沿模型幾乎每隔一週就發布一次——例如 Claude Fable、GLM5.2 和 Minimax M3 等等——大眾對 Token 的狂熱只會愈演愈烈，而市面上根本沒有足夠的 Blackwell 晶片來支持這種需求。因此，NVIDIA GPU 的價格正在飛速上漲，導致 Token 的成本變得非常昂貴。
這時，AMD 登場了。在硬體規格相當的情況下，AMD 每顆 GPU 的平均價格比 NVIDIA 便宜了約 2.75 倍（MI355X 對比 B300），廉價推論的解決方案其實就擺在眼前——這正是我們 Wafer 團隊幾個月來一直在宣揚的觀點。然而，儘管 AMD 的 Instinct MI350 系列在晶片層面能與 Blackwell 匹敵，但 NVIDIA 的軟體優勢和「零日支持」（day-0 support，即模型發布當天即支援）通常能讓供應商在其硬體上以更少摩擦、更快的速度提供推論服務。
相反地，在 MI355X / ROCm 軟硬體棧（stack）上，這些前沿模型的頂尖（SOTA）性能很少能開箱即用（雖然有時可以！）。事實上，如果你能找到一個可以順利運行這些模型的鏡像（Image），就已經算很幸運了。在缺乏零日支持的情況下，針對最新模型進行建構和優化可能需要耗費數週的工程時間與算力。而到了那時候，更新的模型往往已經問世，這使得 AMD 總是處於苦苦追趕的狀態。
但隨著 AI 智慧體（agents）在核心（kernel）和模型優化方面的能力不斷提升，這一差距正在即時縮小。在 Wafer，我們已經一次又一次地證明了這一點。
這一次，在 20k 輸入 / 1k 輸出、60% 快取命中率（cache hit rate）的工作負載下，我們在 2.4 RPS（每秒請求數）時達到了 2626 tok/s/node 的總吞吐量，且定義的拐點（knee）TTFT（首字延遲）≤ 5 秒——儘管成本便宜了 2 倍以上，這仍達到了在 B200 上測得性能的 80%。
我們還遵循 Artificial Analysis（AA）的標準，在 TensorWave 的 AMD MI355X 算力上，於 10k 輸入 Token / 1.5k 輸出 Token 的單串流測試中，讓 GLM5.2 達到了 213 tok/s 的速度。雖然這個數字沒有名列 AA 排行榜榜首，但它在性價比上依然勝出。
我們是如何做到的
處理任何模型的第一步都是選擇量化方式和框架。我們使用 AMD Quark 將原始的 bf16 基礎版 GLM-5.2 量化為 MXFP4。與 z-ai 官方的 FP8 量化相比，我們的 MXFP4 達到了無損水平（在 GPQA-Diamond、tau2、GSM8K 測試中）。
至於推論框架，我們有三個選擇：vLLM、ATOM 和 sglang。在這三者之中，我們選擇了 sglang——因為 vLLM 沒有可運行的 MXFP4 + GlmMoeDsa 路徑，導致 MXFP4 權重無法發揮作用；而 ATOM 的輸出在長文本情境下會退化。Sglang 是能最無縫提供原生支持的推論引擎，既能利用量化優勢，又能保持模型的連貫性。
接下來提升吞吐量的自然步驟，就是在 sglang 上啟用推測解碼（speculative decode）。然而，sglang 的 ROCm 鏡像無法開箱即用支援此功能。在 MTP（多 Token 預測）正常工作之前，需要進行兩項修復。
第一，與其他層一樣，MTP 頭（MTP head）將其單個共享專家（shared expert）儲存為 bf16，而非 MXFP4。然而，MTP 頭註冊時使用的模組前綴與主解碼器棧不同（Quark 將其 bf16 共享專家命名為 model.layers.78.mlp.shared_experts.*，而 MTP 層的實際前綴是 model.decoder.*）。由於這種不匹配，sglang 的量化查找宣告失敗，並預設將該共享專家建構為 MXFP4。在載入時，它會嘗試將全寬（full-width）的 bf16 權重讀取到半寬（half-width）的 4 位元插槽中，導致初始化因形狀（shape）不匹配而崩潰。Quark 會將哪些權重需要保持未量化記錄在一個層名稱列表中，因此我們將第 78 層的條目複製了一份，並以 sglang 實際使用的解碼器名稱命名。這個修復解決了推測解碼的阻礙，使我們的單串流吞吐量提升了接近 3 倍。
第二，深度推測解碼（例如 z-ai 建議的 5/1/6 配置）仍然受阻。當草稿深度（draft depth）≥ 4 時，所需的融合多步元數據核心（fused multi-step metadata kernel）寫入了 #include <cuda_runtime.h>，卻沒有加入 ROCm 保護。修復方法很簡單：加上一個 #ifdef USE_ROCM 保護。
這兩個改動雖然微不足道，但對於充分利用推測解碼至關重要。在推測解碼正常工作，並配合一些配置優化（例如 --kv-cache-dtype fp8_e4m3 和 --enable-aiter-allreduce-fusion）後，我們達到了 213 tok/s 的單串流解碼亮眼成績。
但對於總吞吐量而言，特別是在我們定義的工作負載下，僅靠解碼優化是必要但不足夠的。在 20k 輸入且快取率為 60% 的情況下，工作負載主要受到預填（prefill）階段的限制。
在針對單串流解碼進行優化的 TP8（張量並行 8）配置下，MI355X 運行 GLM5.2-MXFP4 的速度為 1461 tok/s/node。而切換到 TP4×DP2（數據並行 2）後，在該工作負載上獲得了巨大的提升，使我們在 2.0 RPS 時達到了 1944 tok/s/node——不過與我們測得的 Blackwell 性能（在 3.0 RPS 時達到 3192 tok/s/node）相比，這依然相對較慢。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/node。表現好多了。
為什麼這很重要
儘管過程中遇到了一定程度的摩擦，但在 MI355X 上實現最佳的性價比其實並非特別困難——雖然存在一些與框架相關的 Bug，但與我們之前處理 Qwen3.5 397B 的工作不同，你會發現我們這次實際上沒有編寫任何自定義核心（custom kernels）。雖然這項研究沒有將多節點（multi-node）性能納入考量，但在實際應用中，單節點部署依然非常普遍。
在 AMD 上實現頂尖性能（SOTA）正逐漸變成一個「支援與否」的問題，而非「軟體實力」的問題。CUDA 的護城河正在實時瓦解。
</cuda_runtime.h>
個人積分：309分
文章編號：93324520
