当前位置：正文

CUDA护城河，太难跳跃了

（原标题：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。

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

半导体佳构公众号推选

专注半导体鸿沟更多原创内容

平和全球半导体产业动向与趋势

*免责声明：本文由作家原创。著述内容系作家个东谈主不雅点，半导体行业不雅察转载仅为了传达一种不同的不雅点，不代表半导体行业不雅察对该不雅点赞同或撑捏，若是有任何异议，迎接预计半导体行业不雅察。

今天是《半导体行业不雅察》为您分享的第3984期内容，迎接平和。

『半导体第一垂直媒体』

实时 专科 原创 深度

公众号ID：icbank

心爱咱们的内容就点“在看”分享给小伙伴哦