這可能是 AMD 等了很久的時刻。
最近，Wafer AI 在 AMD MI355X 上部署了 Kimi K3。結果是，原本需要 16 張 NVIDIA B200、橫跨兩台伺服器運行的模型，在一台配備 8 張 MI355X 的 AMD 伺服器中就能完成部署。
更重要的是，它不只是把模型裝進去了。
在輸入 1024 Token、輸出 400 Token 的測試中，MI355X 達到了 952 Token/s 的總吞吐量，單用戶生成速度達 118 Token/s。
以單節點計算，其吞吐量約為 16 張 B200 方案的 3.8 倍，性價比亦超越 B200 和 B300。
而最讓人意外的是，ROCm 這次居然沒有特別折騰。
模型太大，顯存開始比算力更重要
Kimi K3 擁有 2.8 萬億參數，僅模型權重就需要超過 1.5 TB 顯存，還沒算百萬 Token 上下文所需的 KV Cache。
一臺 8 卡 B200 伺服器，每張卡有 192 GB 顯存，總容量約為 1.5 TB。也就是說，模型權重都難以完整存放，更不用說為 KV Cache 留出空間。因此，B200 必須使用兩臺伺服器、16 張 GPU。
B300 每張卡擁有 288 GB 顯存，可在單節點內容納模型。巧的是，AMD MI355X 同樣擁有 288 GB 顯存，8 張 MI355X 總計約 2.3 TB，一台伺服器就足夠了。
這不只是少用一台機器。模型跨節點運行後，每生成一個 Token，都可能需要通過網絡同步數據。即使使用約 195 Gb/s 的 RoCE v2 網絡，跨節點通信仍然會拖慢解碼。
MI355X 憑藉更大的顯存，將整個模型保留在單一節點中。
從最終結果來看，8 張 MI355X 的峰值總吞吐量達到 952 Token/s，單路生成速度為 118 Token/s。
作為對比，16 張 B200 的雙節點部署總吞吐量為 498 Token/s，換算到單節點約為 249 Token/s。
也就是說，MI355X 的單節點吞吐量約為 B200 雙節點部署平均單節點吞吐量的 3.8 倍。在單用戶生成速度方面，MI355X 的 118 Token/s 也高於 B200 的 90 Token/s。
B300 依然是絕對性能最高的方案。8 張 B300 的節點總吞吐量達到 1568 Token/s，單路生成速度為 172 Token/s，整體吞吐量大約是 MI355X 的 1.65 倍。
但價格改變了結論。Wafer 按照 MI355X 每卡每小時 2.5 美元、B200 為 4.25 美元、B300 為 6 美元進行計算。
在這一價格假設下，MI355X 每美元可以提供約 48 Token/s 的峰值吞吐量；B200 約為 7 Token/s；B300 約為 33 Token/s。
B300 更快，但 MI355X 的單位成本效率更高。對於需要大規模運行開放模型的數據中心來說，這可能比單純爭奪性能冠軍更加重要。
更意外的是，ROCm 幾乎可以直接使用
長期以來，AMD 數據中心 GPU 最大的問題往往不是硬體，而是軟體。
同一個模型在 CUDA 上可直接運行，但在 ROCm 上可能需要修改框架、補充運算子，甚至重寫底層核心。
但 Kimi The situation with K3 is different.
AMD 為其提供了近似於發售同步的支持。Wafer 表示，模型基本上可直接在 MI355X 上運行，後續工作主要集中在少量兼容性問題和性能優化上。
其中一個問題出現在推測解碼環節。 Kimi K3 本身未提供 MTP 或 EAGLE 所需的草稿模型參數，因此 Wafer 使用了一個外部的塊擴散草稿模型。
這套方案在 CUDA 上可直接運行，但在 ROCm 環境中，第一個真實請求便導致調度器報錯。原因是 ROCm 分支中缺少一個名為 top_k_renorm_prob 的函數。
這個函數所做的並不複雜：從概率分佈中選出最高的 k 個值，將其他概率設為零，再將保留下來的概率重新歸一化。
Wafer 最終使用了一個普通的 PyTorch 函數補上了這段邏輯，不需要手寫 GPU 核心，也不需要重新設計推測解碼系統。
修復後，推測解碼使單路性能提升約 2.2 倍，中等併發下的單流性能提升約 1.7 倍，峰值總吞吐量則提升約 18%。
更重要的是，系統能在更高並發下達到峰值吞吐量。
首字太慢，最後只補了四個零
當然，吞吐量並不是推理服務的全部。對於真實用戶來說，另一個直接影響體驗的指標是 TTFT，也就是從發送請求到看到第一個 Token 之間的等待時間。
在這項任務上，MI355X 最初的表現並不理想。面對約 17.2 萬 Token 的冷啟動預填充任務，MI355X 需要約 51 秒，而 B300 僅需約 23 秒。
在支援百萬 Token 上下文的模型中，預填充任務可能非常龐大。如果在處理長上下文時，用戶每次都要等待數十秒甚至更久，再高的解碼速度也難以彌補體驗上的問題。
Wafer 最終發現，性能差距幾乎全部來自一個注意力核心。 Kimi K3 在 8 路張量並行配置下，每張 GPU 會分到 12 個注意力頭。而 AMD AITER 中速度較快的 MLA 預填充核心，只支援 4、8 或 16 的倍數等形狀。
12 個頭無法匹配，系統已回退至較慢的通用 Triton 實現。
解決方法很樸素：將 12 個注意力頭補零至 16 個，調用現有的高速內核，計算完成後再取回真正需要的 12 個頭。沒有修改模型架構，也沒有編寫新的彙編內核，只是補了四個零。
優化後，AITER MLA 核心的穩定預填充速度達到約 1.3 萬 Token/s，而原來的 Triton 回退路徑大約僅為 4000～7000 Token/s，冷預填充時間因此縮短了約兩到三倍。
This optimization will not change the final decoding throughput, but will significantly reduce the time users wait for the first character to appear.
這也說明，AMD 和 NVIDIA 之間看似巨大的軟體差距，有時並非底層能力不足，只是現有的高速核心暫時未覆蓋某種新模型形狀。
CUDA 的護城河仍在，但缺口已出現
一次測試當然不能證明 AMD 已經全面追上 NVIDIA。
B200 因顯存不足，被迫跨節點運行；B300 的絕對性能依然領先；ROCm 的工具鏈、框架支援和開發者生態，也仍然不如 CUDA。
但開放模型正快速邁入萬億參數時代。當模型大到單台伺服器無法容納時，顯存容量便不再只是參數表上的數字，而會直接影響通信成本、部署複雜度和最終吞吐量。
AMD 將更多 HBM 配置給單卡的策略，正成為一種實際的系統優勢。
如果 AMD 能持續提升 ROCm 的穩定性、擴大對高速核心形狀的支持，並為新模型提供更及時的當日適配，那麼數據中心就必須認真考慮這些 GPU。價格更低、顯存更大、性能足夠，軟件也不再需要花費數月時間調整。
你對此怎麼看？
參考連結：
https://x.com/wafer_ai/status/2083628389903315406
https://x.com/ChiragAsarpota/status/2083864019870634151
本文來自微信公眾號「機器之心」（ID：almosthuman2014），作者：關注LLM的