CFG Labs 从两年前就开始关注并且大量投资 GAI 板块，并且将在未来继续助力行业的发展。本文作者 Frank 为 AI，机器学习，神经网络领域专家，无论在学术以及工作经验方面都获得了惊人的成绩和经验。

在过去十年中，机器学习软件开发的格局经历了重大变化。许多框架层出不穷，但大多数框架都严重依赖利用 Nvidia 的 CUDA，并在 Nvidia GPU 上表现最佳。然而，随着 PyTorch 2.0 和 OpenAI 的 Triton 的到来，Nvidia 在该领域的主导地位（主要是由于其软件护城河）正在被打破。

本报告将触及的主题包括：为什么谷歌的 TensorFlow 输给了 PyTorch，为什么谷歌未能公开利用其在人工智能领域的早期领先地位，机器学习模型训练时间的主要组成部分，内存容量 / 带宽 / 成本墙，模型优化。为什么其他人工智能硬件公司到目前为止还不能在 Nvidia 的主导地位上有所作为，为什么硬件将开始变得更加重要，Nvidia 在 CUDA 上的竞争优势是如何被抹去的，以及 Nvidia 的一个竞争对手在训练芯片的大型云上的重大胜利。

1,000 英尺的总结是，机器学习模型的默认软件栈将不再是 Nvidia 的闭源 CUDA。游戏比赛在 Nvidia 的法庭上，他们让 OpenAI 和 Meta 控制了软件栈。由于 Nvidia 专有工具的失败，该生态系统建立了自己的工具，现在 Nvidia 的护城河将被永久地削弱了。

TensorFlow vs. PyTorch

几年前，框架生态系统是相当分散的，但 TensorFlow 是领先者。谷歌看起来已经准备好控制机器学习行业了。他们拥有最常用的框架 TensorFlow，并设计 / 部署了唯一成功的人工智能特定应用加速器 TPU，从而拥有了先发优势。

相反，PyTorch 赢了。谷歌未能将其先发优势转化为对新生的 ML 行业的主导地位。如今，谷歌在机器学习界有些孤立，因为它没有使用 PyTorch 和 GPU，而是使用自己的软件栈和硬件。在典型的谷歌风格中，他们甚至有一个名为 Jax 的第二框架，直接与 TensorFlow 竞争。

甚至还有人在无休止地谈论谷歌在搜索和自然语言处理方面的主导地位因大型语言模型而减弱，特别是那些来自 OpenAI 和各种利用 OpenAI API 或正在建立类似基础模型的初创公司。虽然我们认为这种厄运和忧郁被夸大了，但这是另一个故事了。尽管有这些挑战，谷歌仍然处于最先进的机器学习模型的前沿。他们发明了 Transformer，并在许多领域保持最先进的水平（PaLM、LaMBDA、Chinchilla、MUM、TPU）。

回到 PyTorch 获胜的原因。虽然有从谷歌手中夺取控制权的因素，但主要是由于 PyTorch 相对于 TensorFlow 的灵活性和实用性的提高。如果我们把它归结为第一个主要层面，PyTorch 与 TensorFlow 的不同之处在于使用了 "Eager 模式 "而不是 "图形模式"。

Eager 模式可以被认为是一种标准的脚本执行方法。深度学习框架立即执行每个操作，当它被调用时，逐行执行，就像任何其他的 Python 代码。这使得调试和理解你的代码更加容易，因为你可以看到中间操作的结果，看到你的模型是如何表现的。

相比之下，图模式有两个阶段。第一阶段是定义一个代表要执行的操作的计算图。计算图是一系列相互连接的节点，代表操作或变量，而节点之间的边代表它们之间的数据流。第二阶段是延迟执行计算图的优化版本。

这种两阶段的方法使得理解和调试你的代码更具挑战性，因为在图的执行结束之前，你无法看到正在发生什么。这类似于 "解释的 "与 "编译的 "语言，如 Python 与 C++。调试 Python 比较容易，主要是因为它是解释的。

虽然 TensorFlow 现在默认有 Eager 模式，但研究界和大多数大型科技公司已经围绕着 PyTorch 解决。几乎所有上了新闻的生成性人工智能模型都是基于 PyTorch 的，这就是一个例子。谷歌的生成式人工智能模型是基于 Jax 的，而不是 TensorFlow。

当然，还有一长串使用 TensorFlow 和 Keras 等其他框架的图像网络，但新模型开发的计算预算都流向了 PyTorch 模型。关于 PyTorch 获胜的更深层次的解释，请看这里。一般来说，如果你在 NeurIPS（主要的人工智能会议）的大厅里走动，所有生成性人工智能，非谷歌的工作都是用 PyTorch。

机器学习训练组件

如果我们把机器学习模型的训练归结为最简单的形式，那么在机器学习模型的训练时间中，有两个主要的时间组成部分。

1. 计算（FLOPS）。在每层内运行密集的矩阵乘法

2. 内存（带宽）。等待数据或层权重到达计算资源。受带宽限制的操作的常见例子是各种归一化、点式操作、SoftMax和ReLU。

在过去，机器学习训练时间的主导因素是计算时间，等待矩阵乘法。随着 Nvidia 的 GPU 不断发展，这很快就不再是首要关注的问题了。通过利用摩尔定律，Nvidia 的 FLOPS 增加了多个数量级，但主要是架构上的变化，如张量核心和低精度浮点格式。相比之下，内存没有遵循同样的路径。

如果我们回到 2018 年，当 BERT 模型是最先进的，而 Nvidia V100 是最先进的 GPU 时，我们可以看到，矩阵乘法不再是提高模型性能的主要因素。从那时起，最先进的模型在参数数量上增长了 3 到 4 个数量级，而最快的 GPU 在 FLOPS 上也增长了一个数量级。

https://arxiv.org/pdf/2007.00072.pdf

即使在 2018 年，纯粹的计算型工作负载占了 99.8% 的 FLOPS，但只占运行时间的 61%。与矩阵乘法相比，归一化和点化操作分别实现了 250 倍的 FLOPS 和 700 倍的 FLOPS，但它们却消耗了该模型近 40% 的运行时间。

内存墙

随着模型规模的不断扩大，大型语言模型仅在模型权重方面就需要几十亿字节，甚至上百万亿字节。由百度和 Meta 部署的生产型推荐网络需要几十 TB 的内存，用于其大规模的嵌入表。\在大型模型训练 / 推理中，很大一部分时间不是用来计算矩阵乘法，而是等待数据到达计算资源。一个明显的问题是，为什么架构师不把更多的内存放在靠近计算的地方。答案是 $$$。

内存遵循一个从近而快到慢而便宜的层次结构。最近的共享内存池在同一个芯片上，一般由 SRAM 组成。一些机器学习 ASIC 试图利用巨大的 SRAM 池来保存模型权重，但这种方法存在一些问题。即使是Cerebras 的~250 万美元的晶圆规模的芯片也只有 40GB 的 SRAM 在芯片上。没有足够的内存容量来容纳 100B 以上参数模型的权重。

Nvidia 的架构一直在芯片上使用小得多的内存。当前一代 A100 有 40MB，下一代 H100 有 50MB。在台积电的 5 纳米工艺节点上，1GB 的 SRAM 需要大约 200mm^2 的硅。一旦实现了相关的控制逻辑 / 结构，这将需要超过 400mm^2 的硅，或约为 Nvidia 数据中心 GPU 总逻辑面积的 50%。鉴于 A100 GPU 的价格为 1 万多美元，H100 的价格为 2 万多美元，从经济上讲，这是不可行的。即使你忽略了 Nvidia 在数据中心 GPU 上约 75% 的毛利率（约 4 倍的加价），每 GB 的 SRAM 内存的成本仍将在 100 美元左右，而这是一个完全产出的产品。

此外，片上 SRAM 存储器的成本不会因为传统的摩尔定律工艺技术的缩减而降低多少。同样的 1GB 内存在下一代台积电 3 纳米工艺技术下实际上成本更高。虽然 3D SRAM 将在一定程度上帮助解决 SRAM 成本问题，但这只是一个暂时的曲线弯曲。

台积电的 3 纳米难题，它甚至有意义吗？- N3 和 N3E 工艺技术和成本详解

存储器层次结构的下一步是紧密耦合的片外存储器，即 DRAM。DRAM 的延迟比 SRAM 高一个数量级（~>100 纳秒对~10 纳秒），但它也便宜得多（1 美元 /GB 对 100 美元 /GB）。

几十年来，DRAM 一直遵循摩尔定律的路线。当戈登 - 摩尔创造这个词的时候，英特尔的主要业务是 DRAM。他关于晶体管的密度和成本的经济预测在 2009 年之前对 DRAM 来说通常是正确的。但自 2012 年以来，DRAM 的成本几乎没有提高。

对内存的需求只增不减。DRAM 现在占了服务器总成本的 50%。这就是内存墙，它已经在产品中显现出来。将 Nvidia 2016 年的 P100 GPU 与刚刚开始出货的 2022 年的 H100 GPU 相比，内存容量增加了 5 倍（16GB -> 80GB），但 FP16 性能却增加了 46 倍（21.2 TFLOPS -> 989.5 TFLOPS）。

虽然容量是一个重要的瓶颈，但它与另一个主要瓶颈 -- 带宽密切相关。增加内存带宽通常是通过并行化获得的。虽然现在标准的 DRAM 每 GB 只需几美元，但为了获得机器学习所需的巨大带宽，Nvidia 使用了 HBM 内存，这是一种由3D 堆叠的 DRAM 层组成的设备，需要更昂贵的包装。HBM 的价格在每 GB 10 到 20 美元之间，包括包装和产量成本。

内存带宽和容量的成本限制在 Nvidia 的 A100 GPU 中不断显现出来。A100 在没有进行大量优化的情况下，FLOPS 的利用率往往非常低。FLOPS 利用率衡量的是训练一个模型所需的总计算 FLOPS 与 GPU 在模型训练时间内可计算的理论 FLOPS。

即使领先的研究人员进行了大量优化，60% 的 FLOPS 利用率也被认为是大型语言模型训练的一个非常高的利用率。剩下的是时间开销，即等待另一个计算 / 内存的数据的空闲时间，或重新计算结果，正好减少内存瓶颈。

从当前一代 A100 到下一代 H100，FLOPS 增长了 6 倍多，但内存带宽只增长了 1.65 倍。这导致了许多人对 H100 的低利用率的担心。A100 需要很多技巧来绕过内存墙，而 H100 则需要实现更多的技巧。

H100 为 Hopper 带来了分布式共享内存和二级组播。这个想法是，不同的 SM（认为是核心）可以直接写到另一个 SM 的 SRAM（共享内存 /L1 缓存）。这有效地增加了缓存的大小，减少了 DRAM 读 / 写的所需带宽。未来的架构将依靠向内存发送更少的操作来减少内存墙的影响。应该注意的是，较大的模型倾向于实现更高的利用率，因为 FLOPS 的需求更多的是以指数形式 / 扩展，而内存带宽和容量的需求更多的是以线性形式扩展。

操作符融合 -- 解决方法

就像训练 ML 模型一样，了解你所处的状态可以让你缩小优化的范围，这很重要。例如，如果你把所有的时间都花在了内存传输上（也就是说，你处于一个内存带宽受限的状态），那么增加 GPU 的 FLOPS 是没有用的。另一方面，如果你把所有的时间都花在执行大的 chonky matmuls 上（即计算约束制度），那么把你的模型逻辑改写成 C++ 来减少开销也没有用。https://horace.io/brrr_intro.html

回到 PyTorch 获胜的原因，是 Eager 模式带来的灵活性和可用性的提高，但转到 Eager 模式并不全是阳光和彩虹。在 Eager 模式下执行时，每个操作都要从内存中读取、计算，然后在处理下一个操作之前发送到内存。如果不进行大量的优化，这将大大增加对内存带宽的需求。

因此，在 Eager 模式下执行的模型的主要优化方法之一被称为运算器融合。操作符融合，而不是把每个中间结果写到内存中，所以多个函数在一次计算中被计算，以尽量减少内存的读 / 写。操作符融合改善了操作符调度、内存带宽和内存大小的成本。

https://horace.io/brrr_intro.html

这种优化通常涉及到编写定制的 CUDA 内核，但这比使用简单的 python 脚本要困难得多。作为一种内在的妥协，随着时间的推移，PyTorch 在其内部稳定地实现了越来越多的运算符。其中许多运算符只是将多个常用的操作融合到一个更复杂的函数中。

操作符的增加使得在 PyTorch 中创建模型变得更加容易，而且由于内存读写次数减少，Eager 模型的执行速度也更快。缺点是，PyTorch 在几年内就膨胀到了 2000 多个运算符。

我们会说软件开发人员很懒，但说实话，几乎所有的人都很懒。如果他们习惯了 PyTorch 中的某个新运算符，他们就会继续使用该运算符。开发者甚至可能没有认识到性能的提高，而是使用那个运算符，因为这意味着写更少的代码。

此外，并不是所有的操作都能被融合。通常需要花费大量的时间来决定哪些操作需要融合，哪些操作需要分配给芯片和集群层面的特定计算资源。融合哪些操作的策略，虽然一般来说是相似的，但根据架构的不同，确实有很大的不同。

Nvidia 是国王

运营商的增长和作为默认的地位帮助了 Nvidia，因为每个运营商都很快为他们的架构进行了优化，但没有为任何其他硬件优化。如果一家人工智能硬件创业公司想要完全实现 PyTorch，那就意味着要以高性能支持不断增长的 2000 个运算器的原生列表。

在 GPU 上训练一个高 FLOPS 利用率的大规模模型所需的人才水平越来越高，因为需要所有的技巧来提取最大的性能。Eager 模式执行加上运算器融合意味着所开发的软件、技术和模型被推到了当前一代 GPU 所具有的计算和内存的比例范围内。

每个开发机器学习芯片的人都要面对同样的内存墙。ASICs 必须支持最常用的框架。ASIC 受制于默认的开发方法，GPU 优化的 PyTorch 代码与 Nvidia 和外部库的混合。在这种情况下，放弃 GPU 的各种非计算包袱而选择更多的 FLOPS 和更严格的编程模型的架构是非常没有意义的。易用性是王道。

打破恶性循环的唯一方法是让在 Nvidia GPU 上运行模型的软件以尽可能少的努力无缝转移到其他硬件。随着模型架构的稳定和来自 PyTorch 2.0、OpenAI Triton 和MLOps 公司（如 MosaicML）的抽象成为默认，芯片解决方案的架构和经济性开始成为购买的最大驱动力，而不是 Nvidia 的卓越软件所提供的易用性。

PyTorch 2.0

几个月前，PyTorch 基金会成立，并从 Meta 的羽翼下退出。在向开放式开发和管理模式转变的同时，2.0 版本已经发布，用于早期测试，并在 3 月全面上市。PyTorch 2.0 带来了许多变化，但最主要的区别是，它增加了一个支持图执行模型的编译解决方案。这一转变将使正确利用各种硬件资源变得更加容易。就在几个月前。伴随着这种向开放式开发和管理模式的转变，2.0 已经发布，用于早期测试，并在 3 月全面上市。

PyTorch 2.0 在 Nvidia 的 A100 上为训练带来了86% 的性能提升，在 CPU 上为推理带来了 26% 的性能提升! 这极大地减少了训练模型所需的计算时间和成本。这些好处可以扩展到其他 GPU 和加速器上，从! 这极大地减少了训练一个模型所需的计算时间和成本。这些好处可以扩展到其他 GPU 和加速器，如AMD、英特尔、Tenstorrent、Luminous Computing、Luminous Computing、Tesla、谷歌、亚马逊、微软、Marvell、Meta、Graphcore、Cerebras、SambaNova 等。

对于目前未优化的硬件，PyTorch 2.0 的性能改进将更大。Meta 和其他公司对 PyTorch 的大量贡献源于他们希望在他们由 GPU 组成的价值数十亿美元的训练集群上更容易实现更高的 FLOPS 利用率。他们也有动力使他们的软件堆栈更容易移植到其他硬件上，为机器学习领域引入竞争。

PyTorch 2.0 还为分布式训练带来了进步，它对数据并行有更好的 API 支持，对数据并行、分片、管道并行和张量并行有更好的 API 支持。此外，它通过整个堆栈原生支持动态形状，在许多其他的例子中，这使得LLM 的不同序列长度更容易得到支持。这是第一次有一个主要的编译器支持从训练到推理的动态形状。

PrimTorch

为 PyTorch 编写一个完全支持所有 2000 多个运算符的高性能后端，对于除 Nvidia GPU 之外的所有机器学习 ASIC 来说都是困难的。PrimTorch 将运算符的数量降至约 250 个原始运算符，同时也为 PyTorch 的终端用户保持了可用性。PrimTorch 使 PyTorch 的不同的、非 Nvidia 的后端实现得更简单和更容易。定制硬件和系统供应商可以更容易地提出他们的软件堆栈。

TorchDynamo

转向图形模式需要一个强大的图形定义。Meta 和 PyTorch 在过去 5 年中一直试图实现这一目标，但他们提出的每个解决方案都有很大的缺陷。他们最终用 TorchDynamo 破解了这个难题。TorchDynamo 将接收任何 PyTorch 用户脚本，包括那些调用外部第三方库的脚本，并生成一个FX 图。

Dynamo 将所有复杂的操作降低到 PrimTorch 的约 250 个原始操作。一旦图形成，未使用的操作就会被丢弃，图决定了哪些中间操作需要存储或写入内存，哪些有可能被融合。这极大地减少了模型内的开销，同时对用户来说也是无缝的。

在测试的 7000 个 PyTorch 模型中，TorchDynamo 已经对超过 99% 的模型起作用，包括来自 OpenAI、HuggingFace、Meta、Nvidia、Stability.AI 等的模型，而无需对原始代码进行任何修改。测试的 7000 个模型是从 GitHub 上使用 PyTorch 的最受欢迎的项目中不加选择地挑选出来的。

谷歌的 TensorFlow/Jax 和其他图形模式的执行管道通常要求用户确保他们的模型适合编译器的架构，以便可以捕获图形。谷歌的 TensorFlow/Jax 和其他图形模式的执行管道通常要求用户确保他们的模型适合编译器的架构，以便可以捕获图形，Dynamo 通过启用部分图形捕获、受保护的图形捕获和及时重新捕获来改变这种情况。

部分图捕获允许模型包括不支持的 / 非 python 结构。当模型的那一部分不能生成图时，就会插入一个图断点，不支持的构造将在部分图之间以急切的模式执行。

守护的图形捕获检查捕获的图形是否有效，以便执行。守护是指需要重新编译的变化。这一点很重要，因为多次运行相同的代码不会多次重新编译。

Just-in-time recapture 允许在捕获的图形无效的情况下重新捕获图形进行执行。

PyTorch 的目标是创建一个统一的前端，具有流畅的用户体验，利用 Dynamo 来生成图形。这个解决方案的用户体验将保持不变，但性能可以得到显著提高。捕获图形意味着可以在大型计算资源基础上更有效地并行执行。

Dynamo 和AOT Autograd然后将优化的 FX 图形传递给 PyTorch 本地编译器水平，TorchInductor。硬件公司也可以把这个图形输入到他们自己的后端编译器中。

TorchInductor

TorchInductor 是一个 python 原生深度学习编译器，可以为多个加速器和后端生成快速代码。Inductor 会把有大约 250 个运算符的 FX 图，降低到大约 50 个运算符。然后 Inductor 进入调度阶段，将运算符融合，并确定内存规划。

然后，Inductor 进入 "封装代码 "阶段，生成代码，在 CPU、GPU 或其他人工智能加速器上运行。包装器代码生成器取代了编译器堆栈的解释器部分，可以调用内核并分配内存。后端代码生成部分利用 OpenAI Triton 用于 GPU 并输出 PTX 代码。对于 CPU，英特尔编译器生成 C++（也会在非英特尔 CPU 上工作）。

今后将支持更多的硬件，但关键是 Inductor 极大地减少了编译器团队为其 AI 硬件加速器制作编译器时必须做的工作。此外，代码的性能更加优化。对内存带宽和容量的要求也大大降低。

我们不希望建立一个只支持 GPU 的编译器。我们想要的是可以扩展到支持各种硬件后端，而拥有 C++ 以及[OpenAI]Triton 则迫使我们具有这种通用性。

OpenAI Triton

OpenAI 的 Triton 对 Nvidia 的机器学习闭源软件护城河来说是非常具有破坏性。Triton 直接接受 Python 或通过PyTorch Inductor 堆栈进行反馈。后者将是最常见的使用情况。然后，Triton 将输入转换为 LLVM 的中间表示，然后生成代码。在 Nvidia GPU 的情况下，它直接生成 PTX 代码，跳过 Nvidia 的闭源 CUDA 库，如 cuBLAS，而选择开源库，如 cutlass。

CUDA 通常被那些专门从事加速计算的人使用，但它在机器学习研究人员和数据科学家中却不太出名。它在高效使用方面有一定的挑战性，需要对硬件架构有深入的了解，这可能会拖慢开发过程。因此，机器学习专家可能要依靠 CUDA 专家来修改、优化和并行化他们的代码。

Triton 弥补了这一差距，使高级语言能够达到与使用低级语言的人相当的性能。Triton 内核本身对于典型的 ML 研究人员来说是相当可读的，这对于可用性来说是非常重要的。Triton 将内存凝聚、共享内存管理和 SM 内的调度自动化。Triton 对于元素 - 明智的矩阵乘法没有特别大的帮助，这些已经被非常有效地完成。Triton 对于昂贵的逐点操作和减少更复杂的操作（如 Flash 关注）的开销非常有用，这些操作涉及矩阵乘法，是一个更大的融合操作的一部分。

OpenAI Triton 今天只正式支持 Nvidia 的 GPU，但这在不久的将来会发生变化。未来还将支持其他多个硬件供应商，这个开源项目正在获得令人难以置信的动力。其他硬件加速器能够直接集成到作为 Triton 一部分的 LLVM IR 中，这大大减少了为新硬件建立 AI 编译器栈的时间。

Nvidia 庞大的软件组织缺乏远见，没有利用他们在 ML 硬件和软件方面的巨大优势，成为机器学习的默认编译器。他们缺乏对可用性的关注，这使得 OpenAI 和 Meta 的外部人员能够创建一个可以移植到其他硬件的软件栈。为什么他们不为 ML 研究人员建立一个像 Triton 一样的 "简化 "CUDA？像 Flash 注意力这样的东西，为什么是出自博士生而不是 Nvidia？

本报告的其余部分将指出在微软大获全胜的具体硬件加速器，以及多个公司的硬件正迅速被整合到 PyTorch 2.0/OpenAI Trion 软件栈中。此外，它将分享相反的观点，作为对 Nvidia 在人工智能培训市场的护城河 / 实力的辩护。

首先，关于将与 OpenAI Triton 整合的硬件。AMD 和 Tenstorrent 正积极地要深度整合到软件栈中。AMD 已经有很多公开的 GitHub 提交。Luminous Computing 的 AI 超级计算机正在 PyTorch Dynamo 层面上整合其软件栈。

据称，硬件方面的大赢家是在微软，AMD 的 MI300 系列 CPU/GPU。微软显然仍将购买 Nvidia，但 MI300 的体面规模将有助于开始打破护城河。AMD 在这里的强项是其硬件工程。AMD 的下一代 MI300 是一个工程的奇迹。AMD 对每瓦特性能的要求是非常高的。虽然英特尔和 Nvidia 有将 GPU 和 CPU 结合在一起的设想，但 AMD 将在 2023 年下半年开始将它们安装到下一代 HPC 中。此外，AMD 正在用真正统一的 HBM 内存在 1 个包中完成这一切。

该芯片是可配置的，可以有各种数量的 CPU 或 GPU 瓦片。上面的渲染图是 4 个 6 纳米的瓦片，上面有 9 个 5 纳米的瓦片。3 个 5 纳米的 Zen 4 个 CPU 芯片在其中一个 6 纳米的瓦片上，2 个 5 纳米的 GPU 芯片在另外 3 个 6 纳米的瓦片上。这可以重新配置，以拥有更多的 CPU 或 GPU 芯片，尽管我们不确定他们是否同时运送这些其他变体。

性能要求似乎很高，特别是当你看了 AMD 的一些脚注。例如，8 倍的人工智能性能，5 倍的人工智能性能 /W，这简直是疯了! AMD 测量了 MI250X 在 560W TDP 下的 FP16 性能为 306.4 TFLOPS。这是其理论峰值性能的 80%。AMD 声称 MI300 的性能使用 FP8，所以考虑到不同的数字格式，这种比较有点虚伪。不管怎么说，使用 AMD 的说法，MI300 在 900W TDP 下的 FP8 性能为 2400 TFLOPS，实现了 5 倍的性能 /W 和 8 倍的性能，与 MI250X 相比。Nvidia 的 Hopper GPU 在 700W 的条件下可以达到 FP8 的~2000 TFLOPS，但它缺少 CPU 组件。

一旦包括 Grace CPU 组件，功率将上升到约 900W，但它也将从 CPU 核心获得温和的性能提升。原始 TFLOPS/W 是相似的。Nvidia 的 Grace Hopper 比 MI300 略早地批量出货。由于在封装、制造成本和 NVLink 网络方面的差异，它也是一个可以扩展到更高容量的设计。主要的缺点是，它仍然必须将数据从封装中传输出来，在 CPU 和 GPU 之间进行传输。虽然这使用的是 NVLink，一个相对高带宽、低延迟的链接，但在每比特的功率、延迟和带宽方面，没有什么能与封装上的传输相比。

对上述报告的辩护是，Triton 目前大量使用了 Nvidia 的开源库，如 Cutlass。这些库对于第三方来说，几乎不存在可以插入 AMD 硬件的情况。当然，Nvidia 开源了许多东西，这些东西很快被第三方供应商采用，包括 Megatron 等框架，该框架已经被亚马逊的内部培训硬件所支持。

在人工智能培训中，硬件公司的关键之处在于，尽可能简单地将正确的控制水平暴露给人们。人们会想要调整并试图理解为什么他们编写的模型表现不佳，但同时，进入硬件的挂钩不能太低级。Nvidia 今天提供了这样的服务。

此外，我们跳过了对融合策略的整个讨论。不是每件硬件都以相同的方式融合相同的行动。这是一个必须做出的有意识的决定，而且融合策略应该在各代硬件之间进行调整。

谷歌的 XLA 为不同版本的 TPU 做了这个工作。今天，PyTorch 和 Triton 中的默认会针对 Nvidia 硬件进行优化。这需要时间来为其他硬件调整这一策略。

我们还跳过了分布式硬件的整个故事。何时、何地以及如何拆分网络、张量、管道、数据等，都是由模型培训师明确地完成。他们更喜欢 Nvidia 的各种分布式训练库，如 NCCL，来做这件事。竞争对手的库，如 AMD 的 RCCL，都非常落后。Meta 公司讨论人工智能硬件和联合封装光学器件。

需要注意的是，Nvidia 有他们的 NVSwitch 盒子在发货。上面讨论得比较多，但 Nvidia 在某种程度上过度构建了网络。此外，他们正在进行一些计算操作，如在交换机中进行全还原，这是其他公司没有尝试过的。这将使扩展到数以千计的加速器变得更加容易。

简而言之，Nvidia 拥有网络、软件和先发优势。这些优势在未来仍将保持强劲，Nvidia 将保持 90% 以上的商户销售额。重要的威胁是，超大规模的公司将能够达到计算成本和内存的正确组合，而不需要 Nvidia 对许多工作负载的巨大加价。

缺乏一种为人工智能租用 Nvidia GPU 的方法，而没有云服务提供商的利润率 x Nvidia 的利润率，这是 Nvidia 的一个主要问题。我们预计 Nvidia 未来将开始提供更多的管理培训服务，以应对这一保证金堆积问题。否则，内部硬件将开始通过更低的成本击败他们。Nvidia 已经提供了云游戏服务（GeForce Now）和创意云服务（Omniverse），所以这并不离谱。

本文为以下链接的编译版本

https://www.semianalysis.com/p/nvidiaopenaitritonpytorch

背景图和第一张图为 Stable Diffusion 制作。