（原标题：CUDA护城河，太难跨越了）

如果您希望可以时常见面，欢迎标星收藏哦~

来源：内容编译自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。