MI300X vs H100 & H200 基准测试对比

---

点击下方 卡片 ，关注“ 慢慢学AIGC ”

第一部分：训练 - CUDA 的护城河依然存在

简介

SemiAnalysis 经过五个月的探索，试图揭示 MI300X 的真实情况。 从理论上看，MI300X 在规格参数和总拥有成本(TCO)方面应该比 NVIDIA 的 H100 和 H200 具有巨大优势 。然而，实际情况是，下面给出的纸面规格并不能代表在真实环境中所能达到的性能表现。

如果 AMD 能够实现其宣传的性能和内存指标，那它确实将成为市场上一个强有力的竞争者 。

今天我们将分享我们历时五个月、针对 MI300X、H100 和 H200 进行的独立分析和训练基准测试的历程，期间我们与 NVIDIA 和 AMD 都有交流。我们将详细概述我们运行的众多底层基准测试，具体内容请参见目录。此外，我们还将比较 NVIDIA 和 AMD GPU 的总拥有成本并将性能因素纳入考量。最终，在经过五个月提交和修复漏洞后，我们实际上是在公开向 AMD 提供全面的建议，指出他们需要做什么才能具有竞争力并解决软件问题。这不仅仅是软件不成熟的问题，他们需要改变他们的开发方式。

简而言之，在比较 NVIDIA 的 GPU 与 AMD 的 MI300X 时，我们发现由于 AMD 公开发布的软件栈存在不足以及 AMD 测试不足，MI300X 在理论上的优势并未能实现。

AMD 的软件体验充满漏洞，导致无法直接使用 AMD 进行训练

。我们本希望 AMD 能在训练工作负载方面成为 NVIDIA 的强劲竞争对手，但截至今日，情况却并非如此。由于 AMD 软件质量保证(QA)文化相对薄弱以及其开箱即用体验的挑战性，AMD 尚未跨过 CUDA 的护城河 。尽管 AMD 试图快速填平这道护城河，但 NVIDIA 的工程师们也在加班加点地通过新功能、库和性能更新来加深这道护城河 。

我们与 NVIDIA 和 AMD 都分享了 GEMM 基准测试和单节点训练的基准测试源代码和中间测试结果，并进行了电话会议和讨论，以征求反馈并改进基准测试，同时我们与 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日定制版本 - 这是由 AMD 首席工程师手工制作的定制 VIP docker 镜像，从源代码构建所有依赖项。
• MI300X 稳定公开发布 PyTorch 2.5.1 - AMD MI300X 的开箱即用体验。
• MI300X 公开每日构建版本 12月19日 - 这可以表明到 2025 年 1 月 PyTorch 2.6 发布时（发布后超过一年）AMD 的性能可能达到的水平。
• MI300X 12月21日 WIP 开发版本 - 这是 AMD 在我们同意推迟文章发布后提交给我们的镜像。这是一个实验性的开发版本，尚未合并到 AMD 的内部主分支，也没有使用原生 PyTorch flash attention API。使用这个镜像的性能可以表明 AMD 公开稳定版本在 1-2 个季度后的性能水平。

我们非常感谢 AMD 和 NVIDIA 在整个过程中提供的技术支持，但我们在发布结果时保持独立性。我们要特别感谢我们的 AMD 对接方，包括 Anush Elangovan（AMD AI 副总裁）、Hui Liu 以及数十位杰出的 AMD 首席/高级工程师、AMD 工程副总裁、AMD 工程院士、AMD 工程高级副总裁和 AMD 工程总监、AMD 软件库负责人，感谢他们对我们各种漏洞报告的分类和修复。在 NVIDIA 方面，我们感谢 Kedar Potdar、Ian Buck、Sylvain Jeaugey 和来自 NVIDIA 的 NCCL 团队提供的出色支持。

感谢 Crusoe、TensorWave（AMD 风投投资公司）、Nebius、Lambda、Hot Aisle 和 Sustainable Metal Cloud (SMC) / Firmus 提供计算资源，并支持开源基准测试。Crusoe、Nebius、SMC / Firmus 和 Lambda 支持开箱即用的托管 SLURM 和共享主目录。TensorWave 目前的托管 SLURM 处于测试阶段，该功能将在明年初正式发布。Sustainable Metal Cloud 是少数几个拥有官方 MLPerf GPT-3 175B 训练结果的新兴云平台之一。

我们将发布一篇关于 H100、H200 和 MI300X 推理性能 的后续文章。我们可能还会在几个月后发布另一篇后续文章，跟进 AMD 训练性能的情况，看看开箱即用体验是否有所改善，并测试其他模型，如 LlaVa 和 Mamba。

主要发现

• 1. 仅比较 理论上的 FLOP/s 和 HBM 带宽/容量 ，就像仅通过查看像素数来比较相机一样。 判断实际性能的唯一方法是进行基准测试 。
• 2. NVIDIA 的开箱即用性能和体验非常出色 ，在我们的基准测试过程中没有遇到任何 NVIDIA 特有的漏洞。 NVIDIA 只为我们分配了一名工程师提供技术支持 ，但由于我们没有遇到任何 NVIDIA 软件漏洞，因此并不需要太多支持。
• 3. AMD 的开箱即用体验非常难以使用 ，需要相当的耐心和努力才能达到可用状态。在我们的大多数基准测试中， AMD PyTorch 的公开稳定版本仍然存在问题，我们需要使用临时解决方案 。
• 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. MI300X 相比 H100/H200 具有更低的总拥有成本(TCO)，但在 AMD 软件的公开稳定版本上，每单位 TCO 的训练性能反而更高 。如果使用 AMD 软件的自定义开发版本，这种情况会有所改变。
• 8. 训练性能较弱 ，这从 MI300X 的矩阵乘法微基准测试中可以看出，AMD 公开发布软件在单节点训练吞吐量方面仍然落后于 NVIDIA 的 H100 和 H200。
• 9. MI300X 的性能受到 AMD 软件的限制。 AMD MI300X 软件在 BF16 开发分支上性能更好，但尚未合并到 AMD 内部代码库的主分支中 。等到它合并到主分支并进入 PyTorch 稳定版本时，NVIDIA Blackwell 已经向所有人开放了。
• 10. AMD 的训练性能也受到限制，因为 MI300X 无法提供强大的扩展性能 。这是由于其 较弱的 ROCm 计算通信库(RCCL) ，以及与 NVIDIA 的 NVIDIA 集合通信库(NCCL)、InfiniBand/Spectrum-X 网络结构和交换机的强大集成相比， AMD 在网络和交换硬件方面的垂直集成程度较低 。
• 11. 许多 AMD AI 库都是 NVIDIA AI 库的分支，导致次优的结果和兼容性问题。

• 12. AMD 客户倾向于仅在推理时使用 手工编写的内核 ，这意味着 在非常狭窄的定义明确的用例之外，其性能很差，而且对快速变化的工作负载没有灵活性 。

给 AMD 的管理建议

我们真诚地希望看到另一个能与 NVIDIA 有效竞争的对手，并希望帮助 AMD 达到这个位置，但不幸的是，在这方面还有许多工作要做。在本文末尾，我们为 Lisa Su 和 AMD 领导团队提供了详细的反馈清单，这里提供一个总结：

• 1. 为 AMD 工程师提供更多计算和工程资源来修复和改进 AMD 生态系统，相比 NVIDIA 为其工程师提供的资源，他们的内部 GPU 设备非常少。最大的 AMD GPU 云服务商 Tensorwave 免费为 AMD 的一个团队提供 GPU 时间来修复软件问题，考虑到他们是付费购买这些 GPU 的，这种情况实在荒谬。
• 2. AMD 需要将更多（数千台）的 MI300X、MI325X 接入 PyTorch CI/CD 进行自动测试，以确保不会出现 AMD 性能退化和功能性漏洞。 NVIDIA 已经为 PyTorch CI/CD 提供了数千个 GPU，以确保出色的开箱即用体验 。
• 3. AMD 执行团队应该亲自大量地内部测试（即" 狗粮测试 "）向公众发布的产品，而不是专注于测试内部版本。最好在直播（twitch.tv）期间进行狗粮测试，以展示真实的开箱即用体验。这就像 geohotz 的直播方式一样。
• 4. AMD 应该与 Meta 合作 ，尽快使生产级 LLM 训练工作负载在 PyTorch ROCm（AMD 对 CUDA 的回答）上正常运行，因为通常情况下，Meta 未使用的 PyTorch 代码路径存在大量漏洞。
• 5. 不要过度依赖设置大量环境标志（多达数十个）来使 AMD 部署可用。相反，应该将这些设置烘焙到默认配置中。让开箱即用体验变得可用！
• 6. 专注于改善开箱即用体验 ，而不是过度依赖需要 5 小时来从源代码 main@specificcommit 构建所有依赖项的自定义 VIP 镜像。
• 7. 不要期望最终用户使用 PYTORCH_TUNABLE_OPS，这是一个有漏洞的原型功能，且不尊重最终用户的时间，因为每次用户想要对代码进行任何更改时都需要花费约 1 小时进行调优。
• 8. AMD 应该提交 MLPerf Training GPT-3 175B 的结果 。MLPerf 是一个公平的基准测试方法，以收敛时间作为指标。

• 9. 我们希望 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 的平均售价较低，还因为它通常使用更便宜的以太网网络。比较一个拥有 16,000 个 H200 的集群和一个拥有 16,000 个 MI300X 的以太网集群，仅网络成本的节省就接近 40%，其余的节省来自于加速器成本的降低。使用白牌以太网交换机相比使用 NVIDIA 的 Quantum-2 交换机可以节省大量成本，但真正的差异在于更便宜的收发器，因为 NVIDIA 品牌的收发器的价格比典型的收发器 OEM 厂商要高出 2-3 倍。

从表面价值来看，MI300X 似乎得到了两全其美：更高的性能和更低的总拥有成本。在其发布时，从这种引人注目的组合来看，期望弱势的 AMD 获得市场份额的增长是合乎逻辑的。下表显示了集群的总前期资本支出 - 我们在文章接近末尾的部分详细分析了集群资本支出组成部分以及详细的网络物料清单(BoM)分析。

随着订单的确定，对 MI300X 潜力的兴奋感不断增长，这还得益于 AMD 乐观的评论和指导。凭借引人注目的规格优势，很容易就能为 AMD 指导意见的进一步上涨找到论据，大多数投资者认为管理层是在保守估计。从理论上讲，AMD 手里握有好牌。毕竟他们在 2024 年数据中心 GPU 市场占有率为个位数中段，从逻辑上讲，到 2027 年即使达到 10-12% 的市场份额的预期路径可能都是保守的，同时这能为 AMD 带来可观的收益增长。

然而，从 2023 年底到 2024 年的大部分时间，2024 全年数据中心 GPU 销售的指导数据一再低于这些高预期。从 2024 年第一季度财报到第三季度财报，AMD 仅将指导意见从 40 亿美元提高到 50 亿美元，远低于基于 CoWoS 和 HBM 供应协议的 60-80 亿美元的投资者目标。我们在加速器模型中的需求观点跟踪到了微软年初的失望表现和后续订单的缺乏。

早期乐观的推理逻辑就像是从杂志上购买某款汽车而不进行试驾，也不征求该型号车主的反馈或阅读任何评论。但不用担心 - SemiAnalysis 已经对 MI300X、H100 和 H200 进行了大规模测试，可以展示为什么 AMD 当前的软件栈问题决定性地推翻了这种推理逻辑。

通用矩阵乘法(GEMM)性能

在基于 transformer 的架构（如 ChatGPT、Llama 等）中，大多数浮点运算都用于矩阵乘法，也就是 GEMM。因此， GEMM 性能是衡量前沿 transformer 模型（如 ChatGPT、Llama、Claude、Grok 等）在硬件上训练效果的良好指标 。

GEMM 需要两个输入矩阵，矩阵 A 和矩阵 B，其中矩阵 A 的形状为 (M, K)，即 M 行 K 列，矩阵 B 的形状为 (K,N)，最终生成形状为 (M,N) 的输出矩阵。

从概念上讲，结果矩阵的每个元素都是沿着输入矩阵的"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 位尾数位)数据类型的情况下。（扩展阅读：《深度学习中的 FP8 格式详解》）

需要注意的是，调用 GEMM 是一个简单的任务，我们不应该遇到 AMD 的软件 bug。但不幸的是，我们遇到了一个 重大 bug： 在夏季的几个月里，torch.matmul 和 F.Linear 这两个 API 在 AMD 上表现出不同的性能。按理说 torch.matmul 和 F.Linear API 应该有相同的性能，但令人惊讶的是，F.Linear 明显更慢！

这是一个奇怪的 bug，因为 torch.matmul 和 F.Linear 都是硬件厂商 GEMM 库的封装，它们本应该达到相同的性能水平。特别是 F.Linear 很重要，因为这是大多数 PyTorch 终端用户启动 GEMM 内核的方式。

在五个月前我们开始测试 AMD 时，公开发布的 AMD PyTorch 仍然存在这个 bug。根本原因是 AMD 实际上有两个不同的底层 GEMM 库：rocBLAS 和 hipBLASLt，其中 hipBLASLt 对 MI300X 进行了更多优化。这个 bug 在于 torch.matmul 使用了优化过的 hipBLASLt，但 AMD 没有默认更改 F.Linear，导致它仍在使用未优化的 rocBLAS 库。

在我们报告 bug 后，AMD 在几个月前最终修复了这个重大 bug。我们希望由于缺乏适当的回归测试，这个问题不会再次出现。如果 AMD 加强测试力度，而不是等待用户发现这些关键问题，其可用性将会得到很大改善。

我们已经将测试中使用的 GEMM 基准测试开源为一个简单的三行代码，任何人都可以轻松运行：

流行的 GEMM 基准测试并不准确

最近，网络上流传着一个基准测试，声称在 GEMM 运算方面，AMD MI300X 的性能接近 H100。

该基准测试存在两个主要问题： 一是没有正确执行 L2 缓存清除，二是仅记录了最高性能，而不是在特定形状的多次迭代中取中位数或平均的 TFLOP/s 。没有在迭代之间清除 L2 缓存，基准测试无法准确反映现实世界中的 GEMM 性能。此外，由于 TFLOP/s 会根据当前迭代次数而变化，因此需要对至少 100 次迭代的结果取平均值或中位数，才能作为准确的 GEMM 基准测试的依据。OpenAI 的 do_bench 默认提供了 L2 缓存清除和平均/中位数计算，因此我们建议工程师在进行微基准测试时使用它。下面，我们将基准测试简化为伪代码，并对上述提到的问题进行了注释。

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 进行测试，以确保准确性。

正如我们即将发布的 H100 vs H200 vs MI300X 推理文章所示，内存带宽对于推理至关重要。

AMD 手工定制 VIP 专属构建与开发中构建

我们之所以能够将 AMD 性能提升至接近 H100/H200 性能的 25% 内部水平，唯一的原因是得到了 AMD 多个团队的支持，帮助修复了众多 AMD 软件的 bug。为了使 AMD 达到可用状态，并获得一定程度的合理性能，AMD 的一位首席工程师专门为我们提供了一个庞大的 ~60 条命令的 Dockerfile，该 Dockerfile 从源代码构建依赖项，因为 Pytorch Nightly 和公共的 PyTorch AMD 镜像运行不佳，并且存在版本差异。 该 Docker 镜像需要大约 5 小时的时间从源代码构建，安装依赖项和子依赖项（hipBLASLt、Triton、PyTorch、TransformerEngine） ，这与 Nvidia 提供的预构建镜像相比，差异巨大，后者提供了即插即用的体验，只需要一行代码。大多数用户并不会从源代码构建 Pytorch 或 hipBLASLt，而是直接使用稳定版本。

在使用公共 PyTorch 时，用户可以选择使用最新的稳定镜像或每日上传的 PyTorch 版本。因此，尽管每日上传的 PyTorch 版本可能包含最新的提交，可能会带来更好的性能或修复一些 bug，但用户必须接受该版本可能未经全面测试，且可能包含来自 Meta、AMD、Nvidia 或其他 PyTorch 贡献者的未发现的新 bug。需要注意的是，大多数终端用户使用的是 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 应该提供最新的 PyTorch 版本——此后 AMD 已开始发布一些这些版本的容器。当前，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 Attention 中，而不是让最终用户安装一个单独的库，这样他们需要花费数小时的时间来构建。这不是一个用户友好的体验。此外，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 训练也是衡量训练到特定收敛时间的一个不错的代理。MLPerf 基准测试考虑了全局批量大小，以及混合精度实现是否会带来收敛惩罚。不幸的是，MLPerf 的运行相当困难，原因是缺乏用户友好的文档和说明，而且其性能通常通过为 MLPerf 特别定制的配置进行最优化，这种配置是普通用户不太可能采用的。需要注意的是，Nvidia 提交了超过 11,000 个 H100 的 MLPerf 训练结果，而 AMD 在内部运行 MLPerf 训练。由于 AMD 的结果可能较弱，因此他们从未提交过任何 MLPerf 训练结果，更不用说 MLPerf GPT3 175B 基准测试了。

在设计我们的 SemiAnalysis 基准测试时，我们希望反映出普通用户的模型实现，因此选择了 torch.scaled_dot_product_attention API（使用 flash attention 后端）、PyTorch 分布式数据并行（DDP）和/或完全分片数据并行（FSDP）与 torch.compile。还需要注意的是，AMD 在其文档中推荐用户使用 torch.scaled_dot_product_attention。我们认为这是最能代表典型用户工作负载的方式。此外，我们使用了一个通用的 PyTorch 原生实现的这些模型，使其尽可能接近典型的机器学习科研用户，并且容易通过一行代码运行。与 MLPerf 相比，我们的基准测试目标是尽可能简单，同时仍然能够作为性能的良好代理。请注意，由于我们没有考虑收敛时间，因此这个基准测试对 AMD 有轻微的偏向，因为我们在 AMD 上设置了更高的微批量大小，而在 Nvidia 上则较低。当考虑收敛时间时，AMD 的结果将比所述的要差。

顺便提一下，许多 AI 从业者表示，由于 Megatron、NeMo 或 3D 并行的高复杂性和缺乏灵活性，他们并没有使用这些库，这些库的僵化性和复杂性使其在机器学习研究中的使用几乎不可能。需要注意的是，在 3D 并行方面，如果它们的软件栈能够正常工作，那么 Nvidia 和 AMD 都能获得更高的性能，这对于 AMD 来说是一个较大的假设。AMD Megatron 是 Nvidia Megatron 的一个分支，且在 GitHub 上的星标数不到 10，意味着它可能没有经过充分的自用验证。提交 bug 报告需要额外的几个月时间才能让 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 模型都使用了 pipeline 并行性，这意味着每个 GPU 服务器上会放置几个 Transformer 层。在现代预训练中，整个模型从来不会放置在单个节点上。

每个训练令牌的模型 FLOP 由如下公式定义：

6 * non_input_embedding_params + 12 * num_layers * num_heads * head_dim * max_seq_len * density

其中，密度（density）是指注意力的稀疏程度，相对于完整的掩码。例如，因果注意力的稀疏度为 50%，而滑动窗口注意力的稀疏度甚至更低。

需要注意的是，最初我们的测试工具使用了 6 * 参数（params），而不是 6 * 非输入嵌入参数（non_input_embedding_params），这是计算每个令牌模型 FLOP 的错误方法。此外，还有一个关于我们如何使用 FSDP 的 bug。我们已更新了测试工具，并进行了回溯性的重新测试，同时更新了 H100、H200、MI300X、公共稳定版、公共夜间版、VIP 镜像以及 AMD 开发构建版本的所有基准测试结果。以下列出的所有结果均基于更新后的测试工具。

单节点训练性能

需要注意的是，我们在本报告中呈现的 H100/H200 性能反映了没有任何 Nvidia 工程师手动调优的开箱即用性能，而 MI300X 的结果是在 AMD 工程师进行了多个月的调优和 bug 修复后得出的。与 AMD 的训练相比，我们没有遇到任何特定于 Nvidia 的 bug，而 AMD 训练相对出现了更多问题。五个月前，由于 AMD 软件在注意力反向传播和 torch 编译中的 bug，许多模型在 AMD MI300X 上无法运行超过 150 TFLOP/s，这迫使用户手动标记模型的一部分为不可编译区域，而不是进行完整的图形编译。

我们发现，对于所有模型，H100/H200 在 MI300X 公共发布版/公共夜间发布版/11月25日从源代码构建的 VIP 镜像中占优。值得注意的是，MI300X 在较小模型（如 GPT 1.5B）或者任何使用非因果注意力层（如 Mistral 7B v0.1）的模型上表现不佳。这是因为 FlexAttention 在截止日期时尚未完全可用，而在 Nvidia GPU 上，自 2024 年 8 月以来，FlexAttention 一直在正常工作。因此，H100/H200 在 TFLOP/s 性能上比 MI300X 公共发布版/公共夜间发布版/11月25日 VIP 构建快了超过 2.5 倍。

对于 12月21日的 MI300X 内部 WIP 开发分支构建，我们仍然看到它在 GPT 1.5B 上的表现不如 H100/H200。此外，在 Mistral 7B 上，它的性能略逊于 H100。在 Llama3 8B 和 Llama3 70B 代理模型中，12月21日的 MI300X WIP 开发构建表现优于 H100/H200，但需要注意的是，这是因为 MI300X WIP 开发使用了 AMD 工程师的开发分支，而该分支尚未合并到 AMD 的主分支中。

三个月前，在 AMD 上尝试进行 FP8 训练时，会导致段错误（segfault）和硬错误。如果偶尔能成功运行，实际上比使用 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 上，MI300X 胜过 H100，但仍然比 H200 的公共稳定版软件发布要慢。即使是他们 12月21日的 WIP 开发分支，H200 的性能也完全压倒了 MI300X。

有趣的是，即使是他们的内部构建版本，MI300X 在非因果注意力层（如 Mistral 7B v0.1）上也表现不佳。Mistral 使用滑动窗口注意力，而一些前沿模型也在使用这种方式。似乎如果你想训练一个不使用因果注意力的模型，AMD MI300X 会自动落后。

虽然很多人发布了硬件性能比较，但大多数没有开源他们的测试代码，也没有使其容易复现。我们采取了开源的方法，并且开源了我们的单节点训练基准测试，使得运行起来非常简单，只需要几行代码：

多节点训练性能

在多节点测试中，我们对比了两台 H100 节点和两台 MI300X 节点的性能。不幸的是，我们未能及时获取到多节点 H200 部署的数据用于本文。

在这一基准测试中，H100 再次以较大优势胜过 MI300X，H100 的性能提升在 10%-25% 之间。随着节点数量的增加，H100 和 MI300X 在单一训练工作负载上的差距进一步扩大。这是一个已知问题，AMD 计划在明年通过部署新的自研 400G AI 专用网卡来解决这一问题。

AMD PYTORCH_TUNABLE_OPS 标志：糟糕的用户体验

为了让 AMD 的训练表现得相对不错，用户需要使用 PYTORCH_TUNABLE_OPS，这是一个针对 AMD 特定的原型标志，允许用户调整 GEMM（矩阵乘法）操作。由于这是一个原型特性（即不稳定的功能），过去该功能存在许多问题，包括但不限于段错误（segfault）、HBM 内存泄漏以及许多单元测试被禁用等问题。这些已知的可调操作问题现已得到修复，但可能仍然存在许多未知的 AMD 软件缺陷。

此外，即使用户没有遇到任何 bug，从而使得这个原型标志能够顺利运行，用户仍然需要花费 1-2 小时来调优任何现代 LLM 模型。尽管用户可以缓存这些 GEMM 操作，但任何代码上的细微变化都会导致用户需要再次花费 1-2 小时进行调优。正如你所想，这会大大降低机器学习科学家在进行模型研发和实验时的迭代速度。

相比之下，在 Nvidia 上，这个标志是无需使用的，因为他们的 GEMM 库（cuBLASLt）开箱即用且经过了调优，cuBLASLt 的启发式模型能够自动为 H100/H200 上的大多数形状选择正确的算法。而在 AMD 上，hipBLASLt/rocBLAS 的启发式模型通常会为大多数形状选择错误的算法，这也是为什么用户需要花费如此多时间进行调优的原因。

我们建议 AMD 修复其 GEMM 库的启发式模型，使其能够开箱即用地选择正确的算法，而不是浪费用户时间进行调优。用户在进行研究时经常需要快速迭代，因此反复运行可调操作会显著降低研究速度。

扩展 NVLink/xGMI 拓扑结构

扩展网络结构对于 GPU 集群来说至关重要，因为它为前沿模型训练中使用的张量并行性和专家并行性提供了极为快速的数据传输通道。因此，我们进行了基准测试，以衡量扩展网络的性能。

H100 和 H200 的扩展网络被称为 NVLink，它为每个 GPU 提供 450GB/s 的带宽，并将 8 个 GPU 连接在一起。而在 MI300X 上，扩展网络被称为 xGMI，按照理论，它连接了 8 个 GPU，并为每个 GPU 提供 448GB/s 的带宽。从表面上看，MI300X 的扩展网络与 H100/H200 非常相似，理论带宽仅低 0.5%。然而，实际情况与理论有很大不同。

首先，MI300X 的 xGMI 是点对点结构，这意味着它并没有为 GPU 之间的每对连接提供 448GB/s 的带宽。实际上，每个 GPU 之间只能以 64GB/s 的速度进行通信。只有当一个 GPU 同时与其他 7 个 GPU 进行通信时，它才可以达到理论上的 448GB/s 带宽。因此，对于张量并行（TP=2），最大带宽为 64GB/s，而对于 TP=4，最大带宽为 189GB/s。

相比之下，由于 Nvidia 的 NVLink 使用的是交换拓扑结构，一个 GPU 可以与另一个 GPU 以完整的 450GB/s 带宽进行通信。此外，H100/H200 中的四个 NVSwitch 支持网络内归约（称为 NVLink SHARP（NVLS），默认启用），这是一种通过在交换机内部执行集合/归约操作来减少数据传输的技术。

全归约/全收集/归约散布/全到全集合操作概述

我们将展示 Nvidia H100/H200 和 AMD MI300 在扩展网络和规模扩展网络上的基准测试。我们将测试的集合操作是前沿 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。这并不令人惊讶，因为 H100/H200 拥有优越的 450GByte/s NVLink 开关拓扑和网络内归约（NVLS），而 MI300X 则使用 7x64GByte/s xGMI 点对点拓扑。

为了重现此测试，您可以使用我们的开源 ClusterMax-NCCL/RCCL 基准测试工具，我们开发它旨在通过一行 Bash 命令轻松运行。ClusterMax 是我们即将推出的评估工具，旨在定量评估 H100/B200/GB200/MI300X Neocloud 集群的性能，并从定性角度评估用户体验。敬请期待我们即将发布的文章《ClusterMax Neocloud 评估 | 如何租用 GPU》。

多节点 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 上，参考设计建议使用 RoCEv2 以太网并搭配 Broadcom Thor-2 NIC。

典型的 GPU 集群几乎总是需要比单级网络更多的层次，因为单级网络只能支持 128 个 GPU（使用 Broadcom 以太网或 Nvidia Spectrum X 以太网）和 64 个 GPU（使用 H100/H200 InfiniBand）。在这样的多级网络中，部署通常使用 8 路优化的胖树架构，其中每个 GPU 都连接到一个独立的交换机（这种连接称为“轨道”）。在我们的《AI Neocloud Playbook 与 Anatomy》文章中，我们详细解释了轨道优化网络的工作原理。

正如 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 子网管理器中并没有默认启用。我们与许多 Neocloud、H100 集群操作员和 AI 前沿实验室进行了沟通，大多数人表示，由于增加了 NCCL_TIMEOUT 错误率以及安装和配置网络的困难，他们没有启用 SHARP。我们询问了 NVIDIA 哪些 AI 客户使用 InfiniBand SHARP，但他们拒绝了具体回答。可以推测，如果 InfiniBand SHARP 对 AI 生产工作负载有用，NVIDIA 的市场营销部门会大力宣传其成功的部署。鉴于目前 InfiniBand SHARP 的采纳率似乎有限，我们在此展示了启用和未启用 SHARP 时的 Nvidia 集合性能。

对于一些基准测试，我们还收集了 Nvidia Spectrum-X 以太网在 Nvidia 内部集群 Israel-1 上的数据。Nvidia Spectrum-X 被用于 xAI 的 20 万 H100/H200 集群，并且在 Spectrum-X 参考架构版本 1.2 中可以支持最多 10 万个 GPU，但通过非参考定制设计，可能支持最多 50 万个 GPU。

我们还在测试 Google Cloud（GCP）H100 的内部以太网，以及 AWS 上部署的 H100 和 H200，这些都使用了 AWS 自有的以太网（称为 EFAv2/EFAv3）。我们将在即将发布的《集合通信深度分析》文章中分享这些测试结果，该文章将提供不同类型的集合操作的可视化，解释不同的 NCCL 协议（SIMPLE、LL、LL128），不同的 NCCL 算法（NVLS、NVLSTREE、RING、TREE、COLNETDIRECT、COLNETCHAIN、PAT），以及如何在 GCP H100 以太网、AWS H100/H200 EFA、InfiniBand H100、Spectrum-X 等平台上运行集合操作。

下面我们展示了一个 32 GPU 全归约集合操作的测试。可以看到，MI300X RoCEv2 的表现位居最后，远落后于正常的 InfiniBand H100 和启用 SHARP 的 InfiniBand H100。简单来说，较差的全归约性能会导致扩展训练性能不佳。

如果您扩展 MI300X（即增加参与集合操作的 GPU 数量），其性能会下降。如您所想，现代的前沿训练通常是在至少 10 万个 GPU 的集群上进行的。与 InfiniBand Non-SHARP 基准相比，MI300X RoCEv2 在所有现实世界的消息大小（16MiB 至 256MiB）下的速度仅为其一半。根据下面的图表，Nvidia Spectrum-X 以太网的性能与 InfiniBand Non-SHARP 的性能非常接近，这得益于 Spectrum-X 与 NCCL 集合库的垂直集成，以及其良好的拥塞控制和自适应路由。AMD 正在尝试在明年通过即将推出的 Pollara 400G NIC 实现垂直集成，该 NIC 支持 Ultra Ethernet，预计能够使 AMD 在与 Nvidia 的竞争中占得一席之地。正如往常一样，Nvidia 并没有停滞不前，到明年年底，它将准备好投入生产其 800G ConnectX-8 NIC，这将提供是 AMD Pollara NIC 两倍速率的线速。

AMD RCCL 是 Nvidia NCCL 的一个分支。AMD 的 RCCL 团队和其他许多团队资源有限，没有足够的计算能力或人力来改进 AMD 生态系统。AMD 的 RCCL 团队目前只有不到 32 个 MI300X 用于研发，这很讽刺，因为改进集合操作的关键在于能够接触到大量的 GPU。坦率地说，这有些荒谬，AMD 应该增加对软件团队的投入，确保他们有更多的 GPU 资源。

这与 Nvidia 的 NCCL 团队形成了鲜明对比，后者可以访问 Nvidia 11,000 H100 内部 EOS 集群的研发资源。此外，Nvidia 还有 Sylvain Jeaugey 这位集合通信领域的专家，此外，Nvidia 还有许多其他世界级的集合操作专家。不幸的是，AMD 在吸引集合库人才方面基本上失败了，主要是由于薪酬和资源较少——与 Nvidia 的工程师相比，后者的工程师通过 RSU（限制性股票单位）增值，年收入常常超过一百万美元。

为了解决这些问题，TensorWave 和 SemiAnalysis 正在与 AMD RCCL 团队合作，以提高集合操作性能。TensorWave 已慷慨地为 AMD 提供了一个中型集群，以帮助 RCCL 团队拥有更多资源来完成他们的工作。事实上，TensorWave 在购买了大量 GPU 后，还需要将 GPU 提供给 AMD，帮助他们修复软件，这实在是荒谬。

另一个值得注意的趋势是，对于非 SHARP 网络，当您将 GPU 数量加倍时，全归约集合操作的速度会以对数方式减少。相比之下，启用 SHARP 时，速度/完成时间保持不变。我们已经得到了最多 1,024 个 H100 的结果，显示 IB SHARP 全归约在任何数量的 GPU 上都是常数时间。我们将在即将发布的《集合通信深度分析》文章中分享这些结果。

对于所有收集（all gather）、全到全（all to all）和减少散布（reduce scatter）集合操作，MI300X 的性能比 InfiniBand 慢 2 到 4 倍。不幸的是，我们没有 Spectrum-X 或 InfiniBand SHARP 的基准数据来进行 all gather 或 reduce scatter 测试。

下面，我们提供了我们的 nccl/rccl 基准测试脚本。不幸的是，由于集群特定的设置，运行过程并不像一行命令那样简单。它确实需要您按照 nccl/rccl 和 nccl-tests/rccl-tests 的 README.md 文件进行操作。在 AWS 和 Google Cloud 上，您可能还需要安装自定义的 nccl 适配器才能正常运行。

AMD 的用户体验不佳，MI300X 开箱即用性差

由于 AMD 内部测试（即“自测”）不充分，以及缺乏自动化测试，MI300X 开箱即用性较差，需要大量的工作和调优。在 2024 年 11 月的 AMD “推进 AI” 活动中，AMD 的 AI 高级副总裁表示，AMD 内部每天晚上进行超过 20 万次测试。然而，这似乎并未有效缓解我们遇到的许多 AMD 软件漏洞，我们怀疑 AMD 并未进行适当的 CI/CD 测试，包括性能回归测试、功能测试和收敛性/数值测试。我们将在这里列举几个例子，帮助读者理解我们遇到的 AMD 软件漏洞的性质，以及为什么我们认为这些问题严重妨碍了在 AMD 上的良好用户体验。

尽管 AMD 自己的文档建议使用 PyTorch 原生 Flash Attention，但今年夏天有几个月，AMD 的 PyTorch 原生 Flash Attention 内核的运行速度低于 20 TFLOP/s，这意味着现代 CPU 在计算 Attention 反向传播时比 MI300X GPU 更快。曾经一度，基本所有使用 PyTorch 在 MI300X 上训练的 Transformer/GPT 模型都运行得非常缓慢。直到通过深度的 PyTorch/Perfetto 分析，发现反向传递（紫色/棕色内核）所占时间远远超过前向传递（深绿色部分），AMD 才注意到这个问题。通常，反向部分的时间应该只占前向传递的约 2 倍（如果使用激活检查点，则略多）。

我们遇到的另一个问题是，使用 torch.compile 时，AMD PyTorch 的 attention 层由于 longsumexp 张量的秩不正确而导致硬错误。令人沮丧的是，这个问题早在 5 月 30 日就已经在 AMD PyTorch 的内部版本中修复，但直到 10 月才被指出并得到修复，才在任何 AMD PyTorch 发行版或 PyTorch nightly 版本中得到更新。这表明，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 版本现在已经修复了收敛性问题，但这与 Nvidia 上的 FlexAttention 形成了鲜明对比，后者自 8 月以来就已可用。这意味着，Nvidia 和 AMD 平台之间，Pytorch 这些出色功能的可用性差距大约有 6 个月。对于前沿 AI 实验室来说，六个月就是一个世纪，OpenAI、Anthropic 和 Google 在这段时间内已经发布了多个模型。

探索提高 AMD 性能的思路

AMD 建议我们尝试使用 PYTORCH_TUNABLE_OPS 通过运行时遍历 GEMM 算法来提高 GEMM 性能。然而，正如我们之前提到的，这个 API 的效果不佳，因为 GEMM 应该在编译 hipBLASLt/RoCBLAS/cuBLASLt 时进行调优，而不是在用户的运行时进行调优。Nvidia H100 的用户大多数情况下不需要使用 PYTORCH_TUNABLE_OPS，因为 cuBLAS 启发式模型会自动选择正确的算法。这与 AMD 的启发式模型形成对比，后者似乎从未能为大多数形状选择正确的算法。我们建议 AMD 停止建议用户尝试 tunable ops，而应该专注于内部正确调优 GEMM 库。

当我们在 AMD 上尝试 PYTORCH_TUNABLE_OPS 时，它导致了超过 25 GB 的 HBM 内存泄漏，MI300X 总容量为 192 GB，这几乎消耗掉了 MI300 相对于 H100 的 HBM 容量优势。解决这个问题的方法是设置默认的 hipBLASLt 和 rocBLAS 工作空间，以防止内存泄漏。

如本文前面所提到的，另一个我们遇到的问题是，MI300X 需要大量的环境标志才能使其真正可用。我们建议 AMD 停止让用户自己设置这些环境标志，而是应设置默认标志，确保环境能够正常使用。问题不仅仅在于标志的数量，还有标志之间复杂的相互作用，这使得故障排查变得困难。在 AMD MI300X 上获得合理的训练性能是一个 NP-难问题。

另一个问题是，由于 AMD 软件 CMake 的 bug 导致硬错误，某些 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 的生态系统中。例如，AMD 应该避免通过分叉 Nvidia/TransformerEngine 并进行源代码转换来支持 FP8 训练，而应该尝试使 PyTorch 本地的 FP8 训练能够在他们自己的硬件上良好运行。目前，AMD 的 PyTorch 本地 FP8 训练方法在 AMD 上无法运行，单元测试甚至无法通过，也没有针对 AMD PyTorch 本地 FP8 训练的 CI/CD。

向 AMD 提出的详细软件改进建议

首先，AMD 需要集中精力吸引更多的软件工程资源，并提高现有工程师的薪酬。目前，AMD 与 Nvidia 之间的薪酬差距意味着顶级人才更倾向于加入 Nvidia 而非 AMD。这些顶级人才还被 Nvidia 吸引，因为 Nvidia 拥有更多的计算资源和更强大的开发支持。AMD 应该为内部开发工作采购更多 GPU，并尽快提交 MLPerf GPT-3 175B 基准测试结果。即使目前这些结果与 Nvidia 的竞争力不相上下，提交这样的基准测试也能启动持续改进的过程。

我们还注意到，AMD 经常为客户提供定制镜像，实际上，AMD 开发人员自己也常常在这些定制镜像上进行开发。这并不是最佳实践，因为这意味着 AMD 工程师的体验与公众使用的镜像不同。AMD 应该通过在内部和客户中使用这些镜像，提升公共镜像的标准，并且 AMD 高层团队应该亲自测试（即“狗粮”）将要公开发布的内容。

我们建议 AMD 创建一个公共仪表盘，每晚更新，展示其硬件在 MLPerf 或 TorchBench 等基准测试中的性能。这个仪表盘还应包括 H100/H200 的性能作为基准。

最后，AMD 需要彻底改变其环境标志的处理方式。与其设置大量的标志来使系统能够运行，AMD 应该将其设置为推荐的默认值，以便用户能够快速开始。

AMD 应与 Meta 合作，确保生产环境下的训练工作负载能够在 ROCm 上运行，因为在 PyTorch 用户中众所周知，PyTorch 的代码路径往往会出现大量 bug，除非 Meta 在内部使用它。目前，Meta 为其生产环境中的 MI300X 推理编写 HIP 核心代码，但并未使用 MI300X 进行实际的训练。如果下一代 Llama 的小型版本能够在 AMD 上进行训练，这将是 AMD 生态系统的巨大改进，也是一次市场营销的胜利。更不用说，这将为 AMD 打开与 Meta 一起逐步向更大规模模型/集群迈进的大门。如果 Meta 采用 AMD GPU 进行实际的模型训练，将是两家公司互利共赢的局面，因为 Meta 也在寻找 Nvidia 的替代训练芯片。

目前，Nvidia 为 PyTorch 的持续改进和开发提供了超过 1000 个 GPU（外部使用），而且还有更多 GPU 用于内部开发。AMD 并未做到这一点。AMD 需要与一个专注于 AMD GPU 的 Neocloud 合作，确保每一代 GPU 都有大约 10,000 个用于内部开发和 PyTorch 的目的。这仍然是 Nvidia 即将推出的大规模 Blackwell 集群的 1/8，但这是一个开始。这些 GPU 可以专门用于 PyTorch 的内部开发和 CI/CD。

Lisa，我们愿意就如何改善 AMD 数据中心 GPU 用户体验进行会面讨论！

H100/H200/MI300X 网络硬件清单分析及每单位 TCO 性能

除了对集合操作和 GEMM 吞吐量的基准测试外，我们还进行了一些实验，探索了更多有价值的主题，以便进行进一步的基准测试并在集群上运行实际工作负载。这些实验涵盖了基准测试的热身和重复效应、VBoost 电源切换、MLPerf GPT-3 训练、BF16 与 FP16 吞吐量、GEMM 输入分布吞吐量、每 FLOP 功率、以及 PyTorch PyPi 分发版与 Nvidia NGC 稳定 PyTorch 镜像的吞吐量比较。

我们还提供了详细的网络硬件清单（BoM）分析，包括 1,000 GPU 以太网、1,000 GPU InfiniBand、16,000 GPU 以太网和 16,000 GPU InfiniBand 集群。我们还讨论了使用 51.2T Radix 交换机与 25.6T Radix 交换机作为后端网络的影响。

最后，我们呈现了一个每单位 TCO 性能分析，展示了 H100/H200/MI300X 在每训练 PetaFLOP 每小时成本（$/hr）方面的表现。这些内容可供所有 SemiAnalysis 订阅用户访问，将对数据中心运营商、机器学习科学家和投资者产生极大兴趣。

扩展阅读：

《AI 新云操作指南与架构分析【技术篇】》

《内存墙：DRAM 的过去、现在与未来》

《AI 扩展定律的演进》

《构建 10 万卡 GPU 集群的技术挑战》

《硬磕 NVIDIA，AMD Yes！COMPUTEX 2024 苏妈主题演讲回顾》

《Nvidia HGX 系列产品详解》

---

扫描下方 二维码 ，关注“ 慢慢学AIGC ”