來源：內容編譯自semianalysis，謝謝。

　　最近，SemiAnalysis報道稱，花了五個月時間才弄清 MI300X 的真正原因。理論上，MI300X 在規格和總擁有成本 (TCO) 方面應該比 Nvidia 的 H100 和 H200 具有巨大優勢。然而，實際情況是，下面給出的紙面規格并不代表在實際環境中可以預期的性能。如果 AMD 能夠用這款內存實現低于市場預期的性能，它將成為市場上非常強大的競爭對手。

　　今天，我們將介紹我們與 NVIDIA 和 AMD 合作對 MI300X、H100 和 H200 進行獨立分析和以訓練為重點的基準測試的五個月歷程。我們將詳細概述我們運行的眾多低級基準測試，請參閱目錄以了解摘要。

　　此外，我們將比較 Nvidia 和 AMD GPU 的總擁有成本并考慮性能。最終，我們所做的大部分工作是公開向 AMD 提供全面的公開建議，告訴他們需要做些什么才能保持競爭力并在提交和消除錯誤五個月后修復他們的軟件問題。這不僅僅是因為它的軟件不成熟，他們需要改變他們的開發方式。

　　簡而言之，當將 Nvidia 的 GPU 與 AMD 的 MI300X 進行比較時，我們發現由于 AMD 公開發布的軟件堆棧缺乏以及 AMD 缺乏測試，MI300X 的潛在紙面優勢并未實現。

　　AMD 的軟件體驗充斥著錯誤，無法使用 AMD 進行開箱即用的訓練。我們希望 AMD 能夠成為 NVIDIA 在訓練工作負載方面的強大競爭對手，但不幸的是，截至今天，情況并非如此。由于 AMD 的軟件質量保證 (QA) 文化弱于預期，并且開箱即用的體驗具有挑戰性，因此 AMD 尚未跨越 CUDA 護城河。隨著 AMD 試圖填補 CUDA 護城河，NVIDIA 工程師正在加班加點地通過新功能、庫和性能更新來加深該護城河。

　　我們與 Nvidia 和 AMD 分享了 GEMM 基準測試和單節點訓練的基準測試源代碼和中間測試結果，并召開電話會議和進行討論以征求反饋意見并實施基準測試的改進，我們還與 AMD 合作實施了軟件堆棧的錯誤修復。

　　我們進行這種高度迭代的交互的目的是確保我們的測試能夠對真實用戶的體驗做出公正的評估。

　　我們最初計劃在幾個月前發布這篇文章，但想花更多時間與 AMD 團隊交流并探討可能的修復或開發工作。我們花了相當多的時間來識別和修復 AMD 軟件錯誤，以便讓 AMD 有機會展示不受 AMD 軟件堆棧錯誤阻礙的 MI300X，而不是只展示開箱即用的性能問題。為了給人留下一個公平的印象，我們還解釋了為實現這一目標所進行的大量調整和錯誤消除工作。我們認為這種方法為用戶提供了盡可能高的透明度。

　　我們希望盡一切可能為改善 AMD 生態系統做出貢獻。盡管由于我們的錯誤報告和不斷嘗試，AMD 軟件現在已大大改進，但其公共軟件堆棧仍然不足。我們已經開源了許多基準測試，并創建了簡單的單行命令來重現它們。

　　如果 Lisa Su 和 AMD 領導層加倍投資，專注于軟件和測試堆棧，他們就有機會在訓練方面與 Nvidia 競爭。我們認為 AMD 的工程師非常有能力，正在盡最大努力推進 AMD 生態系統——事實上，這些工程師以錯誤修復、配置幫助和自定義圖像的形式提供的支持改善了我們從 MI300X 獲得的結果。

　　為了將我們的基準測試流程推向尾聲，我們于 2024 年 11 月 15 日向Nvidia 和 AMD 發送了大部分主要 GEMM 和單節點基準測試代碼和結果的草稿，以供評論、驗證和微調。我們要求在 11 月 25 日之前提交任何最終評論、修復、反饋和任何性能改進。我們設定這個時間范圍是為了明確測試結果，以便有時間撰寫深入的分析和評論，并進行多輪內部和外部審查，所有這些步驟可能需要不定且通常無法預知的時間，通常需要 2-4 周。

　　幾天前，在我們通知他們已確認文章發布日期為 12 月 20 日之后， AMD 要求我們推遲發布，以包含基于 AMD 開發人員分支上的測試版 WIP 開發版本的結果。我們對 Nvidia 的所有基準測試都是在公開可用的穩定版本上進行的。本著透明和公平的精神，我們將這些結果以及更新的測試工具結果作為原始 11 月 25 日截止，圖像和最新的公開可用軟件包括在內。但是，我們認為解釋結果的正確方法是查看 AMD/Nvidia 軟件的公開穩定版本的性能。

　　以下是我們用于基準測試的軟件版本列表：

　　H100 公共穩定版本 – Nvidia H100 的開箱即用體驗。

　　H200 公共穩定版本 – Nvidia H200 的開箱即用體驗。

　　MI300X 11 月 25日 定制版本 - 這是一個手工制作的定制 VIP docker 鏡像，它從 AMD 首席工程師編寫的源代碼構建所有依賴項。

　　MI300X 穩定公開版本 PyTorch 2.5.1 – AMD MI300X 的開箱即用體驗。

　　MI300X 公開夜間版 12 月 19日 - 這可以表明到 2025 年 1 月 PyTorch 2.6 發布時，即推出一年多后，AMD 的性能會達到什么水平。

　　MI300X 12 月 21日 WIP 開發版本 – 這是 AMD 在我們同意推遲發布文章后提交給我們的圖像。這是一個實驗性的開發版本，尚未合并到 AMD 的內部主分支中，并且不使用原生 PyTorch 閃存注意 API。此圖像的性能可以表明 AMD 公共穩定版本的性能在 1-2 個季度后會達到什么水平。

　　我們非常感謝 AMD 和 Nvidia 在整個過程中提供的技術支持，但我們在發布結果時保持獨立性。我們要大聲感謝我們的 AMD 合作伙伴 Anush Elangovan（AMD 人工智能副總裁）、Hui Liu 以及數十位出色的 AMD 首席/高級工程師、AMD 工程副總裁、AMD 工程研究員、AMD 工程 CVP 和 AMD 工程總監、AMD 軟件庫負責人，感謝他們分類和修復了我們的各種錯誤報告。在 Nvidia 方面，我們感謝 Kedar Potdar、Ian Buck、Sylvain Jeaugey 和 NVIDIA 的 NCCL 團隊提供的出色支持。

　　感謝 Crusoe、 TensorWave （AMD Ventures Portco）、 Nebius、 Lambda、 Hot Aisle 和 Sustainable Metal Cloud (SMC) / Firmus 提供的計算和對開源基準測試的支持。Crusoe、Nebius、SMC / Firmus 和 Lambda 開箱即用地支持托管 SLURM 和共享主目錄。TensorWave 目前已在 Beta 版中提供托管 SLURM，該功能將于明年年初全面上市 (GA)。Sustainable Metal Cloud 是少數擁有 官方 MLPerf GPT-3 175B 訓練結果的 neoclouds 之一。

　　主要發現

　　1、紙面上比較 FLOP/s 和 HBM 帶寬/容量類似于僅通過檢查百萬像素數來比較相機。了解實際性能的唯一方法是運行基準測試。

　　2、Nvidia 的開箱即用性能和體驗令人驚嘆，我們在基準測試期間沒有遇到任何 Nvidia 特有的錯誤。Nvidia 派了一名工程師為我們提供技術支持，但我們沒有遇到任何 Nvidia 軟件錯誤，因此我們不需要太多支持。

　　3、AMD 的開箱即用體驗非常難以使用，需要相當大的耐心和努力才能達到可用狀態。在我們的大多數基準測試中，AMD PyTorch 的公共 AMD 穩定版本仍然有問題，我們需要解決方法。

　　4、如果沒有多個 AMD 工程師團隊的支持，對我們遇到的 AMD 軟件錯誤進行分類和修復，AMD 的結果將比 Nvidia 低得多。

　　5、我們與 Sustainable Metal Cloud 合作，在 256 H100 上運行了非官方 MLPerf Training GPT-3 175B，以測試不同 VBoost 設置的效果

　　6、對于 AMD 而言，其公開穩定發布軟件的實際性能遠不及紙面上宣傳的 TFLOP/s。Nvidia 的實際性能也低于其宣傳的 TFLOP/s，但差距并不大。

　　7、與 H100/H200 相比，MI300X 的總擁有成本 (TCO) 較低，但使用 AMD 軟件的公共穩定版本時，MI300X 的每 TCO 訓練性能更高。如果使用 AMD 軟件的定制開發版本，情況就會發生變化。

　　8、訓練性能較弱，正如MI300X的矩陣乘法微基準測試所證明的那樣，并且AMD公開發布的軟件在單節點訓練吞吐量上仍然落后于Nvidia的H100和H200。

　　9、MI300X 的性能受到 AMD 軟件的限制。BF16 開發分支上的 AMD MI300X 軟件具有更好的性能 ，但尚未合并到 AMD 內部存儲庫的主分支中。等到它合并到主分支和 PyTorch 穩定版本中時，Nvidia Blackwell 已經可供所有人使用了。

　　10、AMD 的訓練性能也受到限制，因為 MI300X 無法提供強大的擴展性能。這是由于其 ROCm 計算通信庫 (RCCL) 較弱，并且 AMD 與網絡和交換硬件的垂直整合程度較低，而 Nvidia 則對其 Nvidia 集體通信庫 (NCCL)、InfiniBand/Spectrum-X 網絡結構和交換機進行了強大的整合。

　　11、許多 AMD AI 庫都是 NVIDIA AI 庫的分支，導致結果不理想且存在兼容性問題。

　　AMD 客戶傾向于僅使用手工制作的內核進行推理，這意味著它們在非常狹窄且明確的用例之外的性能很差，并且它們對快速轉移工作負載的靈活性不存在。

　　向AMD提出的高管建議

　　我們真心希望看到 Nvidia 的另一個有效競爭對手，并希望幫助 AMD 達到這一位置，但不幸的是，在這方面仍有許多工作要做：

　　1、為 AMD 工程師提供更多計算和工程資源來修復和改進 AMD 生態系統，與 Nvidia 為其工程師提供的相比，他們的內部 GPU 盒非常少。最大的 AMD GPU 云 Tensorwave 為 AMD 的一個團隊免費提供了 GPU 時間來修復軟件問題，考慮到他們為 GPU 付費，這簡直太瘋狂了。

　　2、AMD 需要將數千臺 MI300X、MI325X 連接到 PyTorch CI/CD 進行自動化測試，以確保 AMD 性能不會下降和功能性 AMD 錯誤。Nvidia 為 PyTorch CI/CD 提供了數千臺 GPU，以確保出色的開箱即用體驗

　　3、AMD 高管團隊應該親自深入內部測試（即“dogfood”）即將上市的產品，而不是專注于測試內部版本。最好在直播期間（twitch.tv）進行dogfood測試，以展示真實的開箱體驗。這就像 geohotz 直播一樣

　　4、AMD 應該與 Meta 合作，讓生產 LLM 訓練工作負載盡快在 PyTorch ROCm（AMD 對 CUDA 的回應）上運行，因為通常情況下，Meta 未使用的 PyTorch 代碼路徑存在大量錯誤。

　　5、不要過度依賴正確設置大量環境標志（多達數十個）來使 AMD 部署可用。相反，將這些設置嵌入到默認配置中。讓開箱即用的體驗變得可用！

　　6、專注于提供良好的開箱即用體驗，而不是過度依賴從源代碼 main@specificcommit 構建所有依賴項并花費 5 個小時進行構建的自定義 VIP 映像。

　　7、不要再期望最終用戶使用 PYTORCH_TUNABLE_OPS，這是一個原型錯誤功能，并且不尊重最終用戶的時間，因為每次最終用戶想要對其代碼進行任何更改時，最終用戶都需要大約 1 小時進行調整。

　　8、AMD 應提交 MLPerf Training GPT-3 175B 結果。MLPerf 是一種同類基準測試方法，以收斂時間為北極星。

　　10、我們希望 AMD 具有競爭力，并愿意接受有關如何更好地修復 AMD 數據中心 GPU 生態系統的更詳細的反饋。

　　AMD 與 Nvidia 對比總結

　　在深入研究阻礙 AMD 發展的各個軟件堆棧方面之前，我們將討論 MI300X 的基本規格、其相對總擁有成本，以及大多數分析師和投資者如何評價其競爭力。

　　MI300X 于 2023 年底推出，具有一組令人興奮的紙面規格——具有 1,307 TFLOP/s 的 FP16 計算能力（比 H100 的 989 TFLOP/s 更強）、5.3 TB/s 的內存帶寬和 192GB 的 HBM3、3.35 TB/s 的內存帶寬和 80GB 的 HBM3。這些規格超過了 H200，而 H200 本身實際上是 H100 的內存規格升級版，可提供 4.8TB/s 的內存帶寬和 141GB 的 HBM3e。

　　從紙面上看，MI300X 部署的總擁有成本非常引人注目，這不僅是因為 MI300X 的 ASP 較低，還因為它通常使用更便宜的以太網網絡進行部署。將 16k H200 集群與 16k MI300X 以太網集群進行比較，可以發現僅網絡成本就節省了近 40%，其余的節省來自更低的加速器成本。與使用 Nvidia 的 Quantum-2 交換機相比，使用 Whitebox 以太網交換機可以節省大量成本，但真正的區別在于更便宜的收發器，因為 Nvidia 品牌收發器的成本是典型收發器 OEM 收費的 2-3 倍。

　　從表面上看，MI300X 似乎是兩全其美的：更高的性能和更低的總擁有成本。在推出時，人們可以合理地預期，這種引人注目的組合將為處于劣勢的 AMD 帶來市場份額的增長。下表顯示了前期集群資本支出總額——我們在文章底部附近的部分中提供了集群資本支出組件的更詳細分類以及詳細的網絡 BoM 分析。

　　隨著訂單的穩定，人們對 MI300X 潛力的興奮感與日俱增，這得益于 AMD 的樂觀評論和指導。憑借令人信服的規格優勢，很容易認為 AMD 的指導會進一步上調，大多數投資者認為管理層是在敷衍了事。理論上，AMD 實力雄厚。畢竟，到 2024 年，他們在數據中心 GPU 中的市場份額將達到中等個位數，從邏輯上講，到 2027 年，即使市場份額達到 10-12% 的下滑路徑也可能是保守的，同時為 AMD 帶來可觀的盈利增長空間。

　　然而，從 2023 年底到 2024 年的大部分時間，2024 年全年數據中心 GPU 銷售預期一再低于這些高預期。從 2024 年第一季度的收益到 2024 年第三季度的收益，AMD 僅將預期從 40 億美元上調至 50 億美元，遠低于基于 CoWoS 和 HBM 供應協議的60-80 億美元投資者預期。我們在加速器模型中的需求觀點 追蹤了 微軟今年年初的失望和缺乏后續訂單。

　　之前樂觀的推理就像從雜志上購買某種車型，而沒有試駕或征求該車型車主的反饋或閱讀任何評論。但不用擔心——SemiAnalysis 已經對 MI300X、H100 和 H200 進行了大規模測試，并且可以說明為什么 AMD 當前的軟件堆棧問題決定性地推翻了這種推理。

　　通用矩陣乘法 (GEMM) 性能

　　基于 Transformer 的架構（例如 ChatGPT、Llama 等）中的大多數 FLOPS 都用于矩陣乘法，也稱為 GEMM。因此， GEMM 性能可以很好地衡量前沿 Transformer（例如 ChatGPT、Llama、Claude、Grok 等）在硬件上的訓練效果。

　　GEMM 采用兩個輸入矩陣，矩陣 A 和矩陣 B，其中矩陣 A 的形狀為 (M, K)，有 M 行和 K 列，矩陣 B 的形狀為 (K,N)，以產生形狀為 (M,N) 的輸出矩陣。

　　從概念上講，結果矩陣的每個元素都是沿輸入的“K”維逐元素乘法的總和。就此而言，K 維也稱為縮減維。

　　下面，我們測試了以下真實世界的形狀，形式為 (M,N,K)——將維度為 (M,K) 和 (K,N) 的矩陣相乘的縮寫。

　　以下矩陣形狀實際上在 Meta 的 Llama 70B 生產訓練中使用：

　　（16384、8192、1280）– 融合 QKV 投影 GEMM 形狀

　　（16384、1024、8192）– 注意輸出投影形狀

　　（16384、8192、7168）– FFN GEMM 形狀

　　（16384、3584、8192）– FFN GEMM 形狀

　　（8192、8192、8192）– 用于基準測試的標準 GEMM 形狀

　　我們使用 OpenAI 的 do_bench 函數進行基準測試設置，這是對 PyTorch 進行基準測試的行業標準方法。do_bench 函數默認在運行之間清除緩存，并提供預熱和多次執行基準測試的方法，將中值結果作為給定的準確度。我們在這些測試中使用了 warmup=30 和 rep=200。輸入張量 A 和 B 都使用均值為 0、方差為 1 的正態分布隨機初始化。這是因為正態分布最接近現代神經網絡中權重和激活的實際分布。輸入張量的分布將影響 TFLOP/s 性能基準測試的結果。我們將在本文后面討論輸入分布影響 TFLOP/s 性能的原因。

　　對于 BF16，我們可以看到 H100 和 H200 實現了大約 720 TFLOP/s，而其市場宣傳為 989.5 TFLOP/s，而 MI300X 僅達到了 ~620 TFLOP/s，而其市場宣傳為 1,307 TFLOP/s。

　　這意味著，盡管 MI300X 的市場 BF16 TFLOP/s 更高，但它比 H100 和 H200 慢 14%。AMD 的這個結果使用了由 AMD 首席工程師手工制作的自定義 docker 鏡像，但性能仍然比 Nvidia 的 GPU 慢。對于我們對 MI300X 的開箱即用測試，TFLOP/s 吞吐量甚至比這還慢！除了自定義鏡像之外，AMD 還要求用戶設置許多默認情況下未設置的環境標志才能達到這些性能結果。

　　不幸的是，FP8 的情況更糟。H100/H200 實現了約 1,280 TFLOP/s，而市場宣傳的為 1979 TFLOP/s。相比之下，MI300X 僅達到約 990 TFLOP/s。因此，對于 FP8，MI300X 比 H100 慢 22%。這是因為兩個輸入都是 e4m3 FP8（即 4 個指數位和 3 個尾數位）數據類型。

　　值得注意的是，調用 GEMM 是一項簡單的任務，我們不應該期望遇到 AMD 軟件錯誤。不幸的是，我們遇到的一個 主要錯誤 是，torch.matmul 和 F.Linear API 在夏季的幾個月里在 AMD 上的表現不同。人們本來以為 torch.matmul 和 F.Linear API 具有相同的性能，但令人驚訝的是，F.Linear 的速度要慢得多！

　　這是一個奇怪的錯誤，因為 torch.matmul 和 F.Linear 都是硬件供應商 GEMM 庫的包裝器，因此它們應該達到相同的性能水平。F.Linear 尤其重要，因為這是 PyTorch 中大多數最終用戶啟動 GEMM 內核的方式。

　　當我們五個月前開始測試 AMD 時，公開的 AMD PyTorch 仍然存在此錯誤。根本原因是 AMD 實際上有兩個不同的底層 GEMM 庫，rocBLAS 和 hipBLASLt，其中 HipBLASLt 針對 MI300X 進行了更多優化。錯誤在于 torch.matmul 使用優化的 hipBLASLt，但 AMD 默認沒有更改 F.Linear，讓它使用未優化的 rocBLAS 庫。

　　幾個月前，在我們報告了這一重大錯誤后，AMD 終于修復了這一重大錯誤，我們希望它不會因為缺乏適當的回歸測試而再次出現。如果 AMD 加大測試力度，而不是等待用戶發現這些關鍵問題，其可用性可能會大大提高。

　　我們已將測試中使用的 GEMM 基準開源為簡單的三行代碼，任何人都可以輕松運行：

　　Stas 的 GEMM 基準是錯誤的

　　最近，互聯網上流傳著一個基準測試，聲稱在 GEMM 上，AMD MI300X 的性能接近 H100。我們喜歡 Stas Bekman，認為他為 ML 社區做了很多積極的工作，但不幸的是，他的基準測試存在一些缺陷。

　　Stas 的基準測試有兩個主要問題：它沒有正確執行 L2 緩存清除，并且只是采用最大性能，而不是特定形狀在迭代過程中的中位數/平均 TFLOP/s。如果在迭代之間沒有清除 L2 緩存，基準測試就無法準確反映真實的 GEMM 性能。此外，由于 TFLOP/s 會根據迭代而變化，因此您需要使用至少 100 次迭代的平均值/中位數作為準確 GEMM 基準測試的基礎。OpenAI 的 do_bench 默認提供開箱即用的 L2 緩存和平均值/中位數，因此我們建議工程師使用它進行微基準測試。下面，我們將 Stas 的基準測試簡化為偽代碼，并對上述問題進行了評論。

　　HBM 內存帶寬性能

　　眾所周知，AMD MI300X 的內存帶寬比 Nvidia H100 和 H200 更好，提供 5.3 TB/s 的帶寬，而 H200 為 4.8 TB/s，H100 為 3.35 TB/s。改進的 HBM 內存帶寬在推理中非常有用，有時在訓練中也很有用。在訓練中，如果用戶擁有更多的 HBM 內存容量和內存帶寬，則可以設置更大的批處理大小。盡管如果使用更大的全局批處理大小，但在達到一定大小之后，模型將需要更長的時間才能收斂。使用較大的全局批處理大小很容易快速運行，但在高水平上，這會影響收斂時間。

　　從我們的 HBM 內存帶寬基準測試中，我們發現 MI300X 的內存帶寬確實比 H200 和 H100 都要好得多。我們在 Pytorch 中使用 Tensor.copy_ 測試了內存帶寬，并使用行業標準 OpenAI do_bench 來確保準確性。

　　內存帶寬對于推理非常重要。

　　AMD手工制作的VIP定制版本

　　和WIP開發版本

　　我們之所以能夠將 AMD 性能提升至 H100/H200 性能的 25% 以內，唯一的原因是 AMD 的多個團隊支持我們修復了大量 AMD 軟件錯誤。為了讓 AMD 達到可用狀態且性能還算合理，AMD 首席工程師專門為我們提供了一個包含約 60 個命令的巨型 Dockerfile，用于從源代碼構建依賴項，因為 Pytorch Nightly 和公共 PyTorch AMD 鏡像功能不佳且存在版本差異。這個 docker 鏡像需要大約 5 個小時才能從源代碼構建并安裝依賴項和子依賴項（hipBLASLt、Triton、PyTorch、TransformerEngine），與 Nvidia 相比，這是一個巨大的差異，Nvidia 提供了預構建的開箱即用體驗，只需一行代碼。大多數用戶不會從源代碼構建 Pytorch 和 hipBLASLt，而是使用穩定版本。

　　使用公共 PyTorch 時，用戶可以選擇使用最新的穩定映像或夜間 PyTorch 上傳。因此，盡管夜間 PyTorch 上傳可能具有最新的提交，可能會帶來更好的性能或修復一些錯誤，但用戶必須接受上傳可能未經充分測試，并且可能包含 來自 Meta/AMD/Nvidia 或其他 PyTorch 貢獻者尚未發現的新錯誤。請注意，大多數最終用戶都在使用 PyTorch 的穩定版本。

　　令人欣喜的是，Nvidia 的 Docker 鏡像包含分析和調試所需的全套開發工具，如 Nsight Compute 和 Nsight Systems。相比之下，AMD 并未提供開箱即用的 OmniTrace 開發工具。

　　直到幾周前，AMD docker 鏡像還僅支持 8 個月前發布的 PyTorch 2.3。主線 PyTorch 2.4 和 PyTorch 2.5 也已發布，PyTorch 2.6 將于 2025 年第一季度推出。我們向 AMD 首席工程師和 AMD 人工智能副總裁建議，AMD 應該擁有最新的 AMD PyTorch 版本——AMD 此后已開始為其中一些 AMD PyTorch 版本發布容器。AMD PyTorch 2.5 的 Docker 鏡像仍然缺失。

　　12月21日AMD開發版本

　　以下是 AMD 12 月 21 日的開發構建 docker 鏡像。如您所見，它使用了許多不穩定的開發分支來安裝依賴項，例如 hipBLASLt、AOTriton、ROCm Attention，并從源代碼安裝包括 PyTorch 在內的所有內容，構建過程需要 5 個小時以上。這些版本的依賴項甚至還沒有合并到 AMD 自己的主分支中。99.9 % 的用戶不會從源代碼安裝 PyTorch 及其在開發分支上的源代碼中的所有依賴項，而是會使用公共穩定的 PyPi PyTorch。

　　此外， AMD 開發版本 沒有通過 PyTorch 原生用戶友好的 torch.scaled_dot_product_attention API 使用 Flash Attention，而是導入了另一個庫（也是開發分支）注意力實現。我們看到更多用戶通過PyTorch原生torch.scaled_dot_product_attention API 使用 Flash Attention，因為它更加用戶友好并且捆綁到開箱即用的 PyTorch 中。甚至 AMD 自己的公開文檔也建議通過 torch.scaled_dot_product_attention API 使用 Flash Attention。我們希望這些內核能夠合并到 PyTorch flash 注意力中，而不是讓最終用戶安裝單獨的庫，花費數小時的時間來構建。這不是一種用戶友好的體驗。此外，AMD 必須支持 FlexAttention，因為它已迅速成為業界的首選。

　　AMD 12 月 21 日的開發版本處于掛起的開發分支上。這意味著它是一個尚未完全 QA 的分支，僅在風險分支上使用。人們對使用開發版本和分支以及從源代碼構建的結果的有效性有很多擔憂，因為大多數用戶在現實生活中不會這樣做。大多數用戶將主要從 PyPI 穩定版本安裝 AMD/Nvidia PyTorch，因此我們建議讀者在分析這些結果時記住這一點。

　　話雖如此，我們還是將這些開發版本結果納入其中，因為它可以預示 AMD 公共穩定版本軟件在 1-2 個季度后的發展情況。然而，與此同時，在競爭中，從現在起 1-2 個季度后，Nvidia Blackwell 將得到廣泛部署，而 AMD MI355X 要到 2025 年下半年才會開始出貨。

　　訓練測試方法（GPT1.5B、Llama 8B、

　　Llama 70B、Mistral）

　　測試訓練性能的方法有很多。最準確的方法是采用中型 AI 初創模型的內部代碼庫，并在 512-1024 GPU 集群上運行它們。這樣，測試運行就具有典型用戶會擁有的所有優化。其他一切都只是這些訓練運行性能的代理。訓練性能考慮了 HBM 帶寬、HBM 容量、TFLOP/s、網絡和系統架構。在紙上比較 HBM 帶寬/容量就像在紙上比較相機百萬像素一樣。

　　MLPerf GPT3 175B Training 也是一個很好的指標，可以衡量訓練到特定收斂所需的時間。MLPerf 基準測試考慮了全局批量大小以及混合精度實現是否會導致收斂損失。不幸的是，由于缺乏用戶友好的文檔和說明，MLPerf 很難運行，并且性能通常通過專門為 MLPerf 設計的自定義調整配置進行最小化最大化，而普通用戶不會采用這種配置。請注意，Nvidia 已提交超過 11k H100 的 MLPerf Training 結果，而 AMD 在內部運行 MLPerf Training。AMD 的結果可能很弱，所以他們從未提交過任何 MLPerf Training，更不用說 MLPerf GPT3 175B 基準測試了。

　　在設計 SemiAnalysis 基準測試時，我們希望反映普通用戶的模型實現，因此選擇了 torch.scaled_dot_product_attention API（使用 flash 注意力后端）、PyTorch 分布式數據并行 (DDP) 和/或完全分片數據并行 (FSDP) 以及 torch.compile。另請注意，AMD 建議用戶在其自己的文檔中使用 torch.scaled_dot_product_attention。我們相信這是最能代表典型用戶工作負載的。此外，我們使用了這些模型的通用 PyTorch 本機實現，以使其接近典型的 ML Scientist 用戶并使其易于用一行代碼運行。與 MLPerf 相比，我們的基準測試的目標是盡可能簡單易運行，同時仍然是性能的良好代理。請注意，由于我們沒有考慮收斂時間，因此此基準測試對 AMD 略有偏見，因為我們在 AMD 上將微批次大小設置得比在 Nvidia 上更高。當考慮到收斂時間時，AMD 的結果將比所述的更差。

　　另外，許多 AI 從業者表示，他們不使用 Megatron、NeMo 或 3D Parallelism，因為這些庫的復雜性很高，而且缺乏靈活性，其僵化性和復雜性使得它們無法用于 ML 研究。請注意，就 3D Parallelism 而言，Nvidia 和 AMD 都將獲得更高的性能，前提是他們的軟件堆棧可以正常工作，這對 AMD 來說是一個很大的假設。AMD Megatron 是 Nvidia Megatron 的一個分支，評分不到 10 顆星，這意味著它可能沒有得到很好的測試。提交錯誤報告需要 額外幾個月的時間 才能讓 AMD Megatron 為簡單模型工作。

　　對于我們的 SemiAnalysis 模型訓練基準，我們將測試四個模型，第一個是簡單的 GPT 1.5B DDP，因為我們相信這代表了在擴展到更大的模型尺寸之前小規模實驗/消融的樣子。DDP 是一種更簡單且網絡密集程度更低的并行形式。接下來，我們測試了標準 Llama3 8B 和 Llama3 70B 4 層代理作為流行模型性能的基準。第三，我們測試了 Mistral 7B v0.1，它評估了硬件在增加一點復雜性時是否會表現良好，因為 Mistral 使用滑動窗口注意力而不是標準因果注意力。ChatGPT、Claude、Genimi、o1、o3 等現代模型不使用標準因果注意力，而是使用復雜的注意力機制。

　　現代 GPT/Llama/Transformer 模型是通過反復堆疊相同的 Transformer 層來構建的。因此，僅測量 4 層的性能就可以很好地衡量模型的整體性能。

　　此外，在針對所有前沿 LLM 模型的現代 LLM 訓練中，都使用流水線并行，這意味著每個 GPU 服務器中都放置了幾個轉換器層。在現代預訓練中，永遠不會將整個模型放置在單個節點上。

　　每個訓練的 token 的模型 FLOP 由以下公式定義：

　　6 * non_input_embedding_params + 12 * num_layers * num_heads * head_dim * max_seq_len * 密度

　　密度是指注意力相對于完整掩碼的稀疏程度。例如，因果注意力的稀疏度為 50%，而滑動窗口注意力的稀疏度甚至更低。

　　請注意，最初我們的測試工具使用的是 6 * params，而不是 6 * non_input_embedding_params，這是計算每個 token 的模型 FLOP 的錯誤方法。此外，我們使用 FSDP 的方式還存在另一個錯誤。此后，我們更新了測試工具，并追溯性地重新測試以及更新了所有版本軟件的所有基準測試結果，包括 H100、H200、MI300X、公共穩定版、公共夜間版、VIP 映像和 AMD 開發版本。下面列出的所有結果均使用更新后的測試工具。

　　單節點訓練性能

　　請注意，我們在本報告中展示的 H100/H200 性能反映了開箱即用的性能，無需 Nvidia 工程師進行任何手動調整，而 MI300X 的結果則是經過 AMD 工程師數月的調整和錯誤修復后得出的。與 AMD 訓練相比，我們沒有遇到任何 Nvidia 特有的錯誤，而 AMD 訓練則相對充滿了錯誤。五個月前，由于 AMD 軟件在注意力反向和 torch 編譯中存在錯誤，許多模型無法在 AMD MI300X 上以超過 150 TFLOP/s 的速度運行，這迫使用戶手動將模型的某個區域標記為不兼容，而不是進行完整的圖形編譯。

　　我們看到，對于所有模型，H100/H200 相對于 MI300X 公開發布/公開夜間發布/11 月 25 日源VIP 圖像版本都勝出。有趣的是，MI300X 在 GPT 1.5B 等較小模型或使用非因果注意層的任何模型（如 Mistral 7B v0.1）上表現不佳。這是因為 FlexAttention 在截止日期時尚未完全投入使用，而在 Nvidia GPU 上，它自 2024 年 8 月以來一直在運行。因此，就 MI300X 公開發布/公開夜間發布/11 月 25 日 VIP 版本而言，H100/H200 在 TFLOP/s 方面比 MI300X 勝出 2.5 倍以上。

　　對于 12 月 21 日MI300X 內部 WIP 開發分支版本，我們仍然發現它在 GPT 1.5B 上的表現不如 H100/H200。此外，它在 Mistral 7B 上的 H100 上的表現略差。對于 Llama3 8B 和 Llama3 70B Proxy，12 月 21 日MI300X WIP 開發版本的表現優于 H100/H200，但請注意，這是由于 MI300X WIP 開發使用了 AMD 工程師的開發分支，而該分支甚至尚未合并到 AMD 主分支。

　　三個月前，我們嘗試在 AMD 上進行 FP8 訓練導致段錯誤和硬錯誤。萬一成功了，實際上比使用 BF16 的相同運行速度慢。我們與 AMD 的 FP8 團隊合作解決了這個問題，還與 AMD hipBLASLt 團隊合作，他們創建了 調整 來修復 MI300X FP8 性能。FP8 訓練很重要，因為與 BF16 相比，它可以加快訓練速度，而且大多數前沿實驗室都使用 FP8 訓練。

　　經過多次修復后，我們可以看到 MI300X 11 月 25 日的 Llama3 8B 和 GPT 1.5B 吞吐量與 H100 相當。照例，H200 在這一類別中勝出。然而，對于 Llama3 70B 4 層代理，AMD 11 月 25 日的結果慘敗。

　　對于具有非因果注意層的 Mistral 7B，AMD 11 月 25 日的表現接近 H100 的一半。這表明，對于任何非簡單模型，即使經過數月的調整，AMD 仍然沒有競爭力，因為模型結構略有調整。許多前沿模型和 AI 訓練初創公司正在使用復雜的注意層來實現較長的上下文跨度和有效的注意，但 AMD 在這方面仍然遠遠落后。

　　不幸的是，AMD 上的 FP8 訓練僅適用于自定義映像，例如我們 11 月 25日的 VIP 映像和 12 月 21日的 WIP 開發分支映像。當我們第一次開始嘗試 AMD FP8 訓練時，它比公開版本上的 AMD BF16 訓練慢。

　　對于 AMD 的 WIP 開發版本，我們看到在 Llama3 8B 上，它戰勝了 H100，但仍然比 H200 的公開穩定軟件版本慢。即使在 12 月 21 日的WIP 開發分支上，H200 的性能也完全擊敗了 MI300X。

　　有趣的是，MI300X 在非因果注意力層上表現不佳，就像 Mistral 7B v0.1 一樣，即使是其內部版本也是如此。Mistral 使用滑動窗口注意力，一些前沿模型也使用這種注意力。似乎如果你想訓練一個不使用因果注意力的模型，AMD MI300X 就會自動失敗。

　　雖然許多人都對硬件進行了性能比較，但大多數人并沒有開源他們的測試代碼，而且他們也很難重現。我們采用了開源方法，并且開源了我們的單節點訓練基準，只需幾行代碼就可以輕松運行：

　　多節點訓練性能

　　對于多節點，我們對兩個節點的 H100 和兩個節點的 MI300X 進行了基準測試。遺憾的是，我們未能及時獲得多節點 H200 部署以供撰寫本文。

　　與 MI300X 相比，H100 再次在這項基準測試中以巨大優勢獲勝，H100 的速度提高了 10-25%。隨著您在單個訓練工作負載中添加更多協同工作的節點，這一差距會越來越大。這是一個已知問題，AMD 正試圖在明年通過部署其新的內部 400G AI 專用 NIC 來解決這個問題。

　　為了讓 AMD 訓練順利運行，用戶需要使用 PYTORCH_TUNABLE_OPS，這是一個 AMD 特定的原型標志，供最終用戶調整 GEMM。由于這是一個原型功能（即不穩定），過去該功能出現了很多錯誤，包括但不限于 段錯誤、HBM 內存泄漏，以及一大堆 其他 問題 ，例如許多 單元測試被禁用。這些已知的可調操作錯誤現已修復，但可能還有更多未知的 AMD 軟件錯誤。

　　此外，即使用戶沒有遇到任何錯誤，因此這個原型 AMD 標志的運行路徑很清晰，用戶仍然需要 1-2 小時來調整任何現代 LLM 模型。雖然這些 GEMM 可以由最終用戶緩存，但對最終用戶代碼的任何微小更改都會導致用戶需要再花 1-2 小時進行調整。可以想象，這會減慢 ML 科學家在嘗試進行模型研發和消融實驗時的迭代周期速度。

　　在 Nvidia 上，此標志是不需要的，因為他們的 GEMM 庫 (cuBLASLt) 開箱即用，并且 cuBLASLt 的啟發式模型開箱即用，為 H100/H200 上的大多數形狀選擇了正確的算法。相比之下，AMD hipBLASLt/rocBLAS 的啟發式模型開箱即用，為大多數形狀選擇了錯誤的算法，這就是為什么最終用戶需要進行如此耗時的調整的原因。

　　我們建議 AMD 修復其 GEMM 庫的啟發式模型，以便它能夠立即選擇正確的算法，而不是浪費最終用戶的時間進行調整。用戶在進行研究時通常會快速迭代，因此重新運行可調操作將大大降低研究速度。

　　擴展 NVLink/xGMI 拓撲

　　擴展結構對于 GPU 集群極其重要，因為它為前沿模型訓練中使用的張量和專家并行提供了極快的路徑。為此，我們進行了基準測試以衡量擴展結構的性能。

　　H100 和 H200 上的擴展結構稱為 NVLink，每個 GPU 提供 450GByte/s 的帶寬，并將 8 個 GPU 連接在一起。在 MI300X 上，擴展結構稱為 xGMI，理論上，它連接 8 個 GPU，每個 GPU 提供 448GByte/s 的帶寬。從表面上看，MI300X 的擴展網絡與 H100/H200 極其相似，性能也非常接近，理論上的帶寬僅少 0.5%。不幸的是，實際情況卻大相徑庭。

　　首先，MI300X 的 xGMI 是一種點對點結構，這意味著它 實際上并沒有 在 GPU 對之間提供 448GByte/s 的帶寬。相反，每個 GPU 只能以 64GByte/s 的速度相互通信。如果一個 GPU 同時處理所有其他 7 個 GPU，則 GPU 只能達到規定的 448GByte/s。這意味著，對于張量并行 TP=2，最大帶寬為 64GByte/s，對于 TP=4，最大帶寬為 189GByte/s。

　　相比之下，由于 Nvidia 的 NVLink 使用交換拓撲，因此一個 GPU 可以以 450GByte/s 的速度與另一個 GPU 通信。此外，H100/H200 中的四個 NVSwitches 支持網絡內縮減（稱為 NVLink SHARP (NVLS)，默認情況下啟用），這是一種通過在交換機內部執行集體/縮減來減少數據移動的技術。

　　全部 Reduce/全部到全部/Reduce Scatter/

　　全部 Gather Collectives 概述

　　我們將展示 Nvidia H100/H200 和 AMD MI300 的縱向擴展和橫向擴展網絡的基準測試。我們將測試的集合是 Frontier LLM 訓練中使用的主要集合：all_reduce、all_gather、reduce_scatter 和 all to all。All Reduce 用于數據并行和張量并行，All Gather 用于 ZeRO/FSDP 并行（以及張量并行），Reduce Scatter 用于 ZeRO/FSDP 并行。

　　由于計算通信重疊的工作方式，實際消息大小范圍從 16MiB 到 256MiB，默認的 PyTorch DDP 大小為 25MiB（NVIDIA 的 MLPerf 11,000 H100 GPT-3 175B 運行使用的 消息大小最大為 200MiB）。我們還測試了 8GiB 和 16GiB，只是為了看看峰值總線帶寬是多少，盡管這些消息大小在現實世界中并不使用。上面討論的所有這些集合都在 3D 并行和 FSDP/ZeRO 并行中使用，它們是訓練前沿模型的常用技術。

　　單節點 NCCL 集體

　　我們發現，在所有單個集合的實際消息中，Nvidia 的表現都比 AMD 好得多。這并不奇怪，因為與 MI300X 的 7x64GByte/s xGMI 點對點拓撲相比，H100/H200 具有出色的 450GByte/s NVLink 交換拓撲和網絡內縮減 (NVLS)。

　　多節點RCCL/NCCL集合和

　　橫向擴展網絡基準測試

　　在 Nvidia 的 H100/H200 和 MI300X 上，每個 GPU 都使用 400G 網絡接口卡 (NIC) 通過橫向擴展網絡連接到其他節點，每個 GPU 都直接連接。H100/H200 參考設計通常使用 ConnectX-7 NIC 實現 InfiniBand NDR 或使用 BlueField-3 實現 Spectrum-X 以太網。Spectrum-X 是 NVIDIA 專為 AI 工作負載打造的定制以太網解決方案。在 MI300X 上，參考設計建議使用帶有 Broadcom Thor-2 NIC 的 RoCEv2 以太網。

　　典型的 GPU 集群幾乎總是需要比單層網絡更多的層，因為單層網絡只能支持 128 個 GPU（對于 Broadcom 以太網或 Nvidia Spectrum X 以太網）和 64 個 GPU（對于 H100/H200 InfiniBand）。在這樣的多層網絡中，部署通常使用 8 軌優化的胖樹，其中 8 個 GPU 中的每一個都連接到單獨的交換機（這種連接稱為“軌”）。

　　正如 Nvidia 的 NVLink 為其擴展網絡提供 NVLS 一樣，Nvidia 的 H100/H200 InfiniBand 擴展網絡也提供 InfiniBand SHARP 網絡內縮減功能，這也是 Nvidia 獨有的功能。AMD 沒有針對 MI300X 的類似產品。InfiniBand SHARP 的工作原理與 NVLink SHARP 網絡內縮減類似，因為它們都提供了一種減少通過網絡的流量的方法，對于 InfiniBand SHARP，縮減是在 Quantum-2 InfiniBand 交換機內部進行的。

　　不幸的是，與默認啟用的 NVLink SHARP 不同，InfiniBand SHARP 在 UFM/IB 子網管理器中默認未啟用。我們與許多 Neoclouds、H100 集群運營商和 AI 前沿實驗室進行了交談，大多數人都表示，由于 NCCL_TIMEOUT 率增加以及安裝和配置網絡困難，他們沒有啟用 SHARP。我們詢問 NVIDIA 哪些 AI 客戶使用 InfiniBand SHARP，但他們拒絕具體回答。人們可以推測，如果 InfiniBand SHARP 在 AI 生產工作負載中很有用，NVIDIA 營銷人員會大聲宣傳其成功部署。鑒于目前 InfiniBand SHARP 的采用似乎有限，我們在此展示了 Nvidia 在啟用和未啟用 SHARP 時的總體性能。

　　對于某些基準測試，我們還在名為 Israel-1 的 Nvidia 內部集群上收集了 Nvidia Spectrum-X 以太網數據。Nvidia Spectrum-X 用于 xAI 的 200k H100/H200 集群，并且可以在 Spectrum-X 參考架構版本 1.2 中支持高達 100k GPU 的集群，但使用非參考定制設計可能最多支持 512k GPU。

　　我們還正在測試 Google Cloud (GCP) H100 的內部以太網，以及部署在 AWS 內部以太網上的 AWS H100 和 H200（稱為 EFAv2/EFAv3）。我們將在即將發布的“Collective Deep Dive”文章中分享結果，該文章將提供不同類型集體的可視化，解釋不同的 NCCL 協議（SIMPLE、LL、LL128）、不同的 NCCL 算法（NVLS、NVLSTREE、RING、TREE、COLNETDIRECT、COLNETCHAIN、PAT），以及集體如何在 GCP H100 以太網、AWS H100/H200 EFA、InfiniBand H100、Spectrum-X 等上運行。

　　下面我們展示了 32 GPU 全部減少的集體測試。您可以看到，與普通 InfiniBand H100 和啟用 SHARP 的 InfiniBand H100 相比，MI300X RoCEv2 排名墊底。簡而言之，全減少性能不佳會導致橫向擴展訓練不佳。

　　如果擴展（即增加）參與集體的 GPU 數量，MI300X 的性能會下降。可以想象，現代前沿訓練是在至少 100,000 個 GPU 的集群上進行的。與 InfiniBand Non-SHARP 的基線相比，MI300X RoCEv2 對于所有 16MiB 到 256MiB 的實際消息大小的運行速度只有后者的一半。如下圖所示，由于 Spectrum-X 與 NCCL 集體庫的垂直集成以及其良好的擁塞控制和自適應路由的使用，Nvidia Spectrum-X 以太網性能非常接近 InfiniBand Non-SHARP 的性能。AMD 正試圖在明年與即將推出的支持超級以太網的 Pollara 400G NIC 進行垂直整合，希望能夠與 Nvidia 競爭。與往常一樣，Nvidia 不會停滯不前，到明年年底，它將準備投入生產 800G ConnectX-8 NIC，該 NIC 的線路速率是 AMD Pollara NIC 的兩倍。

　　AMD RCCL 是 Nvidia NCCL 的一個分支。AMD 的 RCCL 團隊和 AMD 的許多其他團隊資源有限，沒有足夠的計算或人員來改善 AMD 生態系統。AMD 的 RCCL 團隊目前可以穩定地使用不到 32 臺 MI300X 進行研發，這很諷刺，因為改善集體運營的關鍵在于能夠使用許多 GPU。坦率地說，這很愚蠢，AMD 應該花更多錢讓他們的軟件團隊能夠使用更多的 GPU。

　　這與 Nvidia 的 NCCL 團隊形成了鮮明對比，該團隊可以使用 Nvidia 的 11,000 H100 內部 EOS 集群的研發資源。此外，Nvidia 還擁有 Sylvain Jeaugey，他是集體通信方面的主題專家。Nvidia 還有很多其他世界級的集體專家，不幸的是，由于薪酬和資源吸引力較小，AMD 在很大程度上未能吸引集體庫人才——而 Nvidia 的工程師則不同，由于 RSU 價值的升值，工程師年薪超過 100 萬美元的情況并不罕見。

　　為了緩解這些問題，TensorWave 和 SemiAnalysis 目前正在與 AMD RCCL 團隊合作，以提高整體性能。TensorWave 慷慨地贊助了 AMD 一個中型集群，以幫助 RCCL 團隊擁有更多資源來完成他們的工作。Tensorwave 在購買了許多 GPU 后，還必須向 AMD 提供 GPU 來修復他們的軟件，這真是太瘋狂了。

　　另一個值得注意的趨勢是，對于非 SHARP 網絡，隨著 GPU 數量增加一倍，所有 Reduce Collective 的速度將呈對數下降。相比之下，使用 SHARP，速度/完成時間保持不變。我們有多達 1,024 個 H100 的結果，表明 IB SHARP All Reduce 在 Collective 中任何數量的 GPU 上都是恒定時間。

　　對于所有收集、所有到所有和減少散射集合，MI300X 比 InfiniBand 慢 2-4 倍。不幸的是，我們無法訪問 Spectrum-X 或 InfiniBand SHARP 基準數據，用于所有收集或減少散射。

　　下面，我們提供了 nccl/rccl 基準測試腳本。遺憾的是，由于集群特定設置的性質，它并不像一行代碼那么簡單。它確實需要您遵循 nccl/rccl 和 nccl-tests/rccl-tests 的 README.md 才能正常運行。在 AWS 和 Google Cloud 上，可能還需要安裝自定義 nccl 適配器。

　　AMD 的用戶體驗不佳，

　　MI300X 無法開箱即用

　　由于內部測試不佳（即“內部測試”）以及 AMD 缺乏自動化測試，MI300 無法開箱即用，需要大量的工作和調整。2024 年 11 月，在 AMD 的“Advancing AI”上，AMD 的 AI 高級副總裁 表示，AMD 內部每晚都會運行超過 20 萬次測試。然而，這似乎并沒有改善我們遇到的許多 AMD 軟件錯誤，我們懷疑 AMD 是否進行了適當的 CI/CD 測試，包括適當的性能回歸或功能和收斂/數值測試。我們將在這里概述幾個示例，讓讀者了解我們遇到的 AMD 軟件錯誤的性質，以及我們為什么認為它們非常妨礙 AMD 的良好用戶體驗。

　　盡管 AMD 自己的文檔建議使用 PyTorch 原生 Flash Attention，但今年夏天的幾個月里，AMD 的 PyTorch 原生 Flash Attention 內核的運行速度不到 20 TFLOP/s，這意味著現代 CPU 計算注意后向層的 速度比 MI300X GPU 快。有一段時間，基本上所有在 MI300X 上使用 PyTorch 進行的 Transformer/GPT 模型訓練都以烏龜的速度運行。AMD 內部沒有人注意到這一點，直到在深度 PyTorch/Perfetto 分析之后提交了一份錯誤報告，該報告顯示后向傳遞（紫色/棕色內核）比前向傳遞（深綠色部分）花費的時間遠遠多。正常情況下，后向部分所花費的時間應該只是前向傳遞的約 2 倍（如果使用激活檢查點，則略多一些）。

　　我們遇到的另一個問題是，由于 longsumexp Tensor 的等級不正確，AMD PyTorch 注意層在與 torch.compile一起使用時會導致硬錯誤。令人沮喪的是，這個問題早在 5 月 30日就已經在 AMD PyTorch 的內部版本中得到修復，但直到 10 月有人向他們指出存在錯誤時，它才出現在任何 AMD PyTorch 發行版或任何 PyTorch 夜間版本中。這表明 AMD 向公眾發布的軟件包缺乏測試和內部測試。此問題的另一個核心原因是 PyTorch (Meta) 的主要維護者目前沒有在內部使用 MI300X 進行生產 LLM 培訓，導致 Meta 內部未使用的代碼路徑存在錯誤且未正確進行內部測試。我們認為 AMD 應該與 Meta 合作，讓他們的內部 LLM 培訓在 MI300X 上運行。

　　8 月8日，Horace He 和 Meta PyTorch 團隊發布了 FlexAttention，這是一個關鍵的 API，用于在不影響速度的情況下創建非因果注意層。以前，要使用文檔掩碼、滑動窗口注意、軟上限和 Alibi 等注意變體，用戶需要花費數周時間用 CUDA/HIP 語言手工制作自己的內核，然后將其綁定到 PyTorch。但是，使用 FlexAttention，用戶可以使用 API 快速生成所有注意變體。FlexAttention 通過使用塊稀疏性，僅在需要的地方計算掩碼塊，而忽略其余部分，從而實現了出色的性能。

　　借助滑動窗口注意力機制，FlexAttention 可以將性能提高 10-20 倍！這對于最終用戶來說非常棒，但不幸的是，直到幾天前，MI300X FlexAttention 的狀態很差，并且受到許多 AMD 軟件錯誤（包括收斂問題）的影響。雖然最新的 PyTorch Nightly 現已修復了收斂問題，但這與自 8 月以來就已推出的 Nvidia 上的 FlexAttention 形成了鮮明對比。這意味著這些出色的 Pytorch 功能在 Nvidia 和 AMD 平臺上的可用性之間存在約 6 個月的差距。對于前沿人工智能實驗室來說，六個月是一生的時間，OpenAI、Anthropic 和 Google 在如此短的時間內發布了許多模型。

　　探索提高AMD性能的思路

　　AMD 建議我們嘗試使用 PYTORCH_ TUNABLE_OPS 通過在運行時掃描 GEMM 算法來提高 GEMM 性能。但是，正如我們前面提到的，此 API 效果不佳，因為應該在編譯 hipBLASLt/RoCBLAS/cuBLASLt 時調整 GEMM，而不是在用戶運行時調整。Nvidia H100s 的用戶不需要對大多數形狀使用 PYTORCH_ TUNABLE_OPS，因為 cuBLAS 啟發式模型會選擇正確的算法。這與 AMD 的啟發式模型形成鮮明對比，后者似乎從未為大多數形狀選擇正確的算法。我們建議 AMD 停止建議用戶嘗試可調操作，而是專注于在內部正確調整其 GEMM 庫。

　　當我們在 AMD 上嘗試 PYTORCH_ TUNABLE_OPS 時，它導致 HBM 內存泄漏超過 25 GByte，而 MI300X 的總容量為 192 GBytes，這基本上抹去了 MI300 相對于 H100 的 HBM 容量優勢。解決此問題的方法是設置默認 hipBLASLt 和 rocBLAS 工作區以防止內存泄漏。

　　正如我們在本文前面提到的，我們遇到的另一個問題是，MI300X 需要大量的環境標志才能真正使用。我們建議 AMD 不要讓用戶自己設置這些環境標志，而是設置默認標志，以形成可用的環境。這不僅僅是因為它們的數量，還因為標志之間的復雜交互，使得故障排除變得困難。從 AMD MI300X 中獲得合理的訓練性能是一個 NP-Hard 問題。

　　另一個問題是，由于 AMD 軟件 CMake 錯誤導致硬錯誤，某些 AMD ROCm 庫無法安裝在 Docker 中。此問題現已修復。在 AMD GPU 上，您需要傳入一組復雜的標志才能使 GPU 能夠在容器內工作，而使用 docker，讓 GPU 工作就像傳入“—gpus=all”一樣簡單。我們建議 AMD 與 Docker 合作，并確保 Docker 也可以自動檢測 AMD 的 GPU，使工作流程像使用 Nvidia GPU 時一樣精簡。

　　AMD的分支庫

　　AMD 的許多庫都是從 Nvidia 的開源或生態系統庫中分叉出來的。AMD 使用一種名為 Hipify 的工具來執行 Nvidia CUDA 到 AMD HIP 的源到源轉換。雖然動機可以理解，但 他們是在競爭對手的平臺上構建的 ，不能指望通過這種軟件開發策略來匹配或超越 Nvidia 的用戶體驗。他們需要將他們的軟件貢獻給 AMD 生態系統。例如，他們不應該通過分叉 Nvidia/TransformerEngine 和源到源轉換來支持 FP8 訓練，而應該嘗試 PyTorch 原生 FP8 訓練，以便在自己的硬件上很好地運行。目前，AMD PyTorch 原生 FP8 訓練配方在 AMD 上不起作用，單元測試甚至還沒有通過，AMD PyTorch 原生 FP8 訓練沒有 CI/CD。

　　向AMD提供修復其軟件的詳細建議

　　首先，AMD 需要專注于吸引更多軟件工程資源并提高現有工程師的薪酬。AMD 和 Nvidia 之間的當前薪酬差距意味著，頂尖人才被 Nvidia 而不是 AMD 所吸引。這些頂尖人才也被 Nvidia 所吸引，因為它為工程師提供了更多的計算/資源。AMD 應該為其內部開發工作采購更多 GPU，并盡快提交 MLPerf GPT3 175B 結果。即使結果現在無法與 Nvidia 競爭，提交這樣的基準測試也將啟動迭代改進的過程。

　　我們還注意到 AMD 經常向客戶提供自定義映像，事實上，AMD 開發人員自己也經常在這些定制映像的基礎上工作。這不是最佳實踐，因為這意味著 AMD 工程師的體驗與公眾可用的映像不同。AMD 應該通過在內部和客戶中使用這些映像來提高公共映像的標準，AMD 高管團隊應該親自在內部測試（即“狗糧”）公開發布的內容。

　　我們建議 AMD 創建一個每晚運行的公共儀表板，顯示其硬件在 MLPerf 或 TorchBench 等基準測試中的表現。該儀表板還應包括 H100/H200 性能作為基準。

　　最后，AMD 需要徹底改變其環境標志方法。它不應設置大量標志來開箱即用，而應將其設置為推薦的默認值，以便用戶快速上手。

　　AMD 應該與 Meta 合作，讓生產訓練工作負載在 ROCm 上運行，因為 PyTorch 用戶都知道，除非 Meta 在內部使用 PyTorch 代碼路徑，否則它往往會有大量錯誤。Meta 目前為其生產 MI300X 推理手動編寫 HIP 內核，但不使用 MI300X 進行實際訓練。如果下一代 Llama 的較小版本在 AMD 上進行訓練，這將是 AMD 生態系統的一次巨大改進，也是一次營銷勝利。更不用說這將為 AMD 與 Meta 一起逐步轉向更大的模型/集群打開大門。Meta 使用 AMD GPU 進行實際模型訓練對兩家公司來說都是雙贏的，因為 Meta 也在尋找 Nvidia 的替代訓練芯片。

　　目前，Nvidia 為 Pytorch 的持續改進和開發提供了 1,000 多個 GPU，在外部提供，在內部提供更多 GPU。AMD 沒有。AMD 需要與專注于 AMD 的 GPU Neocloud 合作，為內部開發和 Pytorch 提供每代約 10,000 個 GPU。這仍然是 Nvidia 即將推出的大型 Blackwell 集群的 1/8 ， 但這只是一個開始。這些可以專用于 Pytorch 的內部開發和 CICD。

　　https://semianalysis.com/2024/12/22/mi300x-vs-h100-vs-h200-benchmark-part-1-training/

　　*免責聲明：本文由作者原創。文章內容系作者個人觀點，半導體行業觀察轉載僅為了傳達一種不同的觀點，不代表半導體行業觀察對該觀點贊同或支持，如果有任何異議，歡迎聯系半導體行業觀察。