过去十年，机器学习软件开发领域的格局发生了翻天覆地的变化，许多框架相继涌现，但其中的大多数框架在很大程度上都依赖于 Nivida 的 CUDA，并在 Nvidia GPU 上的表现最好。然而，随着 PyTorch 2.0 和 OpenAI Triton 的推出，Nvidia 在这一领域的主导地位正在被打破。
本报告将深入探讨一系列问题，包括：为何 Google 的 TensorFlow 会不如 PyTorch、为何 Google 未能充分利用其在 AI 领域的早期领导地位、机器学习模型训练时间的主要组成部分、以及内存容量、带宽、成本等方面的困扰，模型优化的挑战、其他 AI 硬件公司为何迄今都未能撼动 Nvidia 的主导地位、硬件在未来变得更为关键的原因、Nvidia 在 CUDA 方面竞争优势消失的内因、以及 Nvidia 竞争对手在大型云平台上为训练硅芯片取得的重大胜利。
总结而言，机器学习模型的默认软件堆栈将不再是 Nvidia 的闭源 CUDA。原本掌握主动权的是 Nvidia，但他们却让 OpenAI 和 Meta 接管了这个软件堆栈。由于 Nvidia 在其专有工具方面的失败，该生态系统构建了自己的工具，而如今 Nvidia 的护城河将被永久性地削弱。
TensorFlow vs. PyTorch
虽然框架系统在前几年还相当零散，但 TensorFlow 仍是领先者。Google 似乎有意掌握机器学习行业的控制权，他们通过最常用的 TensorFlow 框架拥有了行业先发优势，同时设计和部署了唯一成功的 AI 应用特定加速器 TPU。然而，最终 PyTorch 获得了胜利，Google 未能利用其先发优势转化为新兴机器学习行业的主导地位。如今，由于 Google 更倾向于使用自家的软件和硬件，而不是 PyTorch 和 GPU，因此在机器学习领域中，它显得有些孤立，这是典型的 Google 风格，他们甚至推出了一个名为 Jax 的第二套框架，直接与 TensorFlow 竞争。
至今还不断有人讨论 Google 在搜索和自然语言处理领域的主导地位是否会因为大型语言模型，特别是来自 OpenAI 以及利用 OpenAI API 或构建类似基础模型的各种初创公司而减弱。尽管面临以上挑战，但 Google 依旧是最先进的机器学习模型的领导者。他们发明了 Transformer，并在许多领域保持着领先地位（PaLM、LaMBDA、Chinchilla、MUM、TPU）。
回溯 PyTorch 获胜的原因。能从谷歌手中夺走控制权的主要原因是 PyTorch 相对于 TensorFlow 具有更高的灵活性和可用性。究其“第一性原理”，PyTorch 与 TensorFlow 的不同之处在于其使用“Eager 模式”而非“Graph 模式”。
Eager 模式可以理解为一种标准的脚本执行方法。深度学习框架会立即执行每个操作，就像调用 Python 代码一样，逐行执行，这使得调试和理解代码更加直观。你可以看到中间操作的结果，了解模型的行为，使整个过程更容易理解。
相比之下，Graph 模式包含两个阶段。第一阶段是表示要执行的操作的计算图的定义。计算图是一系列相互连接的节点，用于表示操作或变量，节点之间的边表示它们之间的数据流。第二阶段是对计算图优化版本的延迟执行。
这种两阶段式的编程方法使得理解和调试代码变得更加具有挑战性，因为在计算图执行完毕之前，你无法看到具体发生了什么。这类似于“解释“与“编译”语言，就像 Python 与 C++ 的区别一样。调试 Python 更容易，主要是因为它是一种解释型语言。
虽然 TensorFlow 现在默认启用了 Eager 模式，但学术界和大多数大型科技公司已经在 PyTorch 上达成了共识。这一点得以体现在所有引起关注的新闻的生成式 AI 模型都是基于 PyTorch 的，而 Google 的生成式 AI 模型则是基于 Jax 而非 TensorFlow。
当然，在图像领域仍然存在很多使用其他框架如 TensorFlow 和 Keras 的项目，但新模型开发的计算预算大多都流向了 PyTorch 模型。总体而言，如果你在 NeurIPS（主要的人工智能会议）的会场走一圈，你会发现所有非 Google 的生成式 AI 项目的工作都是由 PyTorch 完成的。
机器学习训练组件
若将机器学习模型训练过程简化至最基本的形式，模型训练时间主要由两部分组成。
- 计算（FLOPS）：在每一层进行大规模矩阵乘法运算。
- 内存（带宽）：等待数据或层权重传输到计算资源。常见的带宽受限操作包括各种归一化、逐点操作、SoftMax 和 ReLU。
在过去，机器学习训练时间的主要瓶颈是计算时间，即等待矩阵乘法运算的时长。随着 Nvidia GPU 的不断发展，这个问题就不再重要了。
Nvidia 的 FLOPS 通过摩尔定律已经提升了多个数量级，但主要是架构上的变化，如张量核心和较低精度浮点格式等。相比之下，内存并没有沿着相同的路径改进。回到 2018 年，当时 BERT 模型还是最先进的模型，Nvidia V100 是最先进的 GPU，我们可以看到矩阵乘法已经不再是提升模型性能的主要因素。自那时起，最先进的模型在参数数量上增长了 3 到 4 个数量级，而最快的 GPU 在FLOPS上增长了一个数量级。
即使在 2018 年，纯计算型工作负载占 FLOPS 的 99.8%，但只占了 61% 的运行时间。相较于矩阵乘法，归一化和逐点运算的 FLOPS 分别仅为矩阵乘法的 1/250 和 1/700，但它们却消耗了模型近 40% 的运行时间。
内存墙
随着模型规模的不断扩大，大型语言模型仅模型权重一项就需要千亿乃至太字节。百度和 Meta 部署的生产型推荐网络需要数十 TB 的内存来存储其庞大的嵌入表。在大型模型的训练/推理中，耗费的时间很大一部分并非用于计算矩阵乘法，而是在等待数据传输到计算资源。一个显而易见的问题是，为什么架构师不在离计算更近的地方增加更多的内存。答案是：贵。内存遵循由近及远、由快及慢、由昂贵到廉价的层次结构。最近的共享内存池可以在在同一芯片上，通常由 SRAM 制成。尽管一些专为机器学习设计的 ASIC 尝试利用大量的 SRAM 池来保存模型权重，但这种方法存在一些问题。即便是 Cerebras 高达 250 万美元的晶圆规模芯片，其芯片上也只有 40GB 的 SRAM，这远远不足以容纳一个拥有 100B 以上参数的模型的权重。
Nvidia 的架构常常会在芯片上使用相对较小的内存。上一代 A100 芯片的内存容量为 40MB， H100 有 50MB。 在台积电的 5nm 工艺节点上，1GB 的 SRAM 需要约 200 平方毫米的硅片。 一旦相关的控制逻辑/结构被实现，将需要超过 400 平方毫米的硅片，约占 Nvidia 数据中心 GPU 总逻辑面积的 50%。考虑到 A100 GPU 的售价超过 10,000 美元，H100 的价格两万美元起步，从经济角度来看，这是不可行的。即使忽略 Nvidia 在数据中心 GPU 上约 75% 毛利润（约 4 倍溢价），SRAM 内存的每 GB 成本对于一个完全成熟的产品仍然会价值数百美元。
此外，芯片上 SRAM 的内存成本并不会随着传统摩尔定律所带来的工艺技术缩减而下降太多。实际上，使用下一代台积电 3nm 工艺技术，同样 1GB 的内存成本更高。尽管 3D SRAM 在一定程度上有助于降低 SRAM 成本，但这也只是价格曲线的暂时下跌。
存储层次中的下一层是紧密耦合的片外内存 DRAM。DRAM 的延迟比 SRAM 高一个数量级（约为 100 纳秒和 10 纳秒的区别），但它的成本也便宜得多（DRAM 每 GB 1 美元，SRAM 每 GB 100 美元）。
几十年来，DRAM 一直遵循摩尔定律的发展轨迹。当 Gordon Moore 提出这一术语时，英特尔的主营业务就是 DRAM。他对晶体管密度和成本的经济预测在 2009 年以前一直适用于 DRAM，但自 2012 年以来，DRAM 的成本几乎没有几乎没有变化。市场对内存的需求只增不减，如今 DRAM 已占据服务器总成本的 50%，这就是所谓的内存墙，并且它已经在产品中显现出来。相比 Nvidia 2016 年的 GPU P100，2022 年刚刚发售的 GPU H100 在内存容量上提升了五倍（16GB 到 80GB 的提升），但 FP16 性能却提升了46倍（从 21.2 TFLOPS 增至 989.5 TFLOPS）。
尽管容量是一个重要的瓶颈，但它与另一个主要瓶颈 —— 带宽，密不可分。要获得机器学习所需的大规模带宽，通常需要通过并行处理来增加内存带宽。虽然如今标准的 DRAM 每 GB 只需几美元，但为了获得机器学习所需的巨大带宽，Nvidia 采用了 HBM 内存，这是一种由多层 3D 堆叠的 DRAM 组成的设备，需要更昂贵的封装。HBM 的价格区间为 10 至 20 美元每 GB，包括封装和良率成本。
内存带宽和容量的成本限制在 Nvidia 的 A100 GPU 中被反复提及。A100 在没有进行大幅优化的情况下，往往具有非常低的 FLOPS 利用率。FLOPS 利用率是通过计算（模型训练时总计算 FLOPS）/(GPU 在模型训练时间内理论可计算 FLOPS）而得出。
即使在顶尖研究人员进行了大量优化的情况下，对于大型语言模型训练来说，达到 60% 的 FLOPS 利用率已经被认为是非常高效的了。其余时间是沉默成本，即等待来自另一计算/内存的数据或及时重新计算结果，以降低内存瓶颈。
从上一代 A100 到这一代 H100，FLOPS 增长超过 6 倍，但内存带宽仅增长了 1.65 倍。这导致了许多人对 H100 低利用率的担忧。为了避免内存墙，A100 进行了许多变通措施，而在 H100 上可能会更多。
H100 为 Hopper 架构引入了分布式共享内存和 L2 组播。其核心思想是不同的 SM（类似于内核）可以直接写入另一个 SM 的 SRAM（共享内存/L1缓存）。这有效地增加了缓存的大小并减少了 DRAM 读写所需的带宽。 未来的架构也将通过减少对内存的操作缓解内存墙的影响。值得注意的是，随着 FLOPS 需求呈指数增长，较大的模型往往能够实现更高的利用率，而内存带宽和容量的需求往往呈线性增长。
运算融合 —— 解决办法
就像训练 ML 模型一样，了解了具体的规则可以集中精力进行更有意义的优化。 例如，即使消耗大量时间进行内存传输（即处于内存带宽受限的状态），增加 GPU 的 FLOPS 也不会有任何帮助。同时，如果花费了所有时间执行大规模矩阵乘法运算（即处于计算受限的情境），试图通过将模型逻辑改写成 C++ 来削减开销也无济于事。
https://horace.io/brrr_intro.html
回顾为什么 PyTorch 能够获胜，这是因为 Eager 模式增加了灵活性和可用性，但转向 Eager 模式并非一帆风顺。在 Eager 模式下执行时，每个操作都要从内存读取、计算，然后在处理下一个操作前发送到内存。如果不进行大幅度的优化，这将显著增加对内存带宽的需求。
因此，在 Eager 模式下执行模型的主要优化方法之一就是算子融合。算子融合不需要将每个中间结果写入内存，而是一次性计算多个函数，从而最大限度地减少内存读写次数。算子融合改善了运算符调度、内存带宽和大小的成本。这种优化通常需要编写定制的 CUDA 内核，但这比使用简单的 Python 脚本要困难得多。作为一种妥协，PyTorch 在不断的演进中逐渐在 PyTorch 内部本地实现了越来越多的算子。 其中许多算子只是将多个常用算子融合为一个更复杂的函数。
操作符的增加使得在 PyTorch 中创建模型变得更容易，同时由于内存读写量的减少，Eager 模式的性能也变得更快。缺点是 PyTorch 在短短几年内膨胀到了 2,000 多个算子。我们可能会说这是因为软件开发人员懒惰，但实际上，所有人都是懒惰的。如果开发人员已经习惯了 PyTorch 中的某个新算子，他们会继续使用它。开发人员甚至都可能意识不到性能的提升，使用该算子只是因为可以编写更少的代码。
此外，并非所有的算子都可以进行融合。通常需要花费大量时间来决定哪些需要融合，以及将哪些操作分配给芯片和集群级别的特定计算资源。哪些算子应在哪里融合的策略虽然大体相似，但因架构不同而有很大差异。
Nvidia 是王者
算子的增长和作为默认算子的地位让 Nvidia 受益很多，因为每个操作符都针对其架构进行了快速优化，但并没有为其他硬件进行优化。任何想要完整实现 PyTorch 的 AI 硬件初创公司，都得靠高性能才能原生支持两千多个且还在不断增长的操作符。
为了在 GPU 上训练一个具有高 FLOPS 利用率的大型模型，所需的人才水平因需要采用各种技巧来达到最优性能而不断提高。Eager 模式的执行加上算子融合意味着软件、技术、模型的开发都要被迫适应最新一代 GPU 的计算和内存比例范围。
开发机器学习芯片的每个人都受制于同样的内存墙。ASIC 只能支持最常用的框架。ASIC 受制于默认的开发方法，即使用 Nvidia 和外部库混合的 GPU 优化 PyTorch 代码。在这种情况下，为了获得更多的 FLOPS 和更严苛的编程模型而舍弃 GPU 的各种非计算包袱的架构意义不大。
易用性至关重要。
打破这一恶性循环的唯一方法就是让在 Nvidia GPU 上运行模型的软件能够以尽可能少的工作量无缝转移到其他硬件上。随着模型架构的稳定以及来自 PyTorch 2.0、OpenAI Triton 和 类似 MosaicML 等的 MLOps 公司的成为主流，芯片解决方案的架构和性价比开始成为购买的最主要因素，而不再仅仅是 Nvidia 出色软件所带来的易用性。
PyTorch 2.0
就在几个月前，PyTorch 基金会成立并脱离了 Meta 的管理。伴随着向开放式开发和管理模式转变，PyTorch 2.0 也发布了早期测试版本，并于三月份全面上市。PyTorch 2.0 带来了许多变化，但最主要的区别在于它增加了一个支持图执行模型的编译解决方案，这一变化将使得更好地利用各种硬件资源变得更加容易。
PyTorch 2.0 在 Nvidia A100 上的训练性能提高了 86%，在 CPU 上的推理性能提高了 26%！这大大减少了训练模型所需的计算时间和成本。这些优势可扩展到其他 GPU 和加速器，如 AMD、Intel、Tenstorrent、Luminous Computing、Tesla、Google、Amazon、Microsoft、Marvell、Meta、Graphcore、Cerebras、SambaNova 等。
PyTorch 2.0 的性能提升对于目前未经优化的硬件来说将更为显著。Meta 和其他公司对 PyTorch 的大量贡献源于他们希望通过在由 GPU 组成的数十亿美元的训练集群上更轻松地实现更高的 FLOPS 利用率。 他们还希望让自己的软件栈更容易移植到其他硬件上，从而为机器学习领域引入竞争。
PyTorch 2.0 还为分布式训练带来了好处，为数据并行、分片、管道和张量并行提供了更好的 API 支持。此外，PyTorch 2.0 也通过全栈提供了对动态图形的原生支持，使 LLM 的不同序列长度更容易支持。这也是大型编译器首次支持从训练到推理的动态形状。
PrimTorch
为 PyTorch 编写一个性能出色的后端，且完整支持所有 2,000 多个操作符，对于除了 Nvidia GPU 之外的任何机器学习 ASIC 来说都很困难。 PrimTorch 可将操作符的数量减少到约 250 个原始操作符，同时保持对 PyTorch 最终用户的可用性不变。PrimTorch 使得实现不同的、非 Nvidia 的 PyTorch 后端实现更简单容易。定制硬件和系统供应商也可以更轻松地构建自己的软件栈。
TorchDynamo
向图模式转变需要一个强大的图形定义。Meta 和 PyTorch 在过去 5 年里一直在尝试实现这一点，但他们提出的每个解决方案都有明显的缺陷，他们最终通过 TorchDynamo 解决了这个难题。TorchDynamo 可以接受任何 PyTorch 用户脚本，包括调用外部第三方库的脚本，并生成 FX 图。
Dynamo 将所有复杂操作降低到 PrimTorch 中的约 250 个基本操作。一旦形成图形，系统将丢弃未使用的操作，并由图形确定哪些中间操作需要存储或写入内存，哪些可以潜在地被融合。这极大地减少了模型内的开销，同时对用户来说也是无缝的。
在测试的 7,000 个 PyTorch 模型中，TorchDynamo 已经适用于 99% 以上的模型，包括 OpenAI、HuggingFace、Meta、Nvidia、Stability.AI 等公司的模型，而且无需对原始代码进行任何修改。这 7,000 个经过测试的模型是从 GitHub 上使用 PyTorch 的最受欢迎的项目中随机选择的。Google 的 TensorFlow/Jax 和其他图形模式执行管道通常要求用户确保其模型符合编译器架构，以便捕获图形。Dynamo 通过启用部分图形捕获、受保护的图形捕获和即时重新捕获改变了这一情况。
- 部分图形捕获允许模型包含不受支持 / 非 Python 结构。当无法为模型的某个部分生成图形时，将插入一个图形断点，并在部分图形之间以 Eager 模式执行不受支持的构造。
- 受保护的图形捕获会检查捕获的图形是否可以执行。保护是指需要重新编译的变更。这一点很重要，因为多次运行相同的代码不会多次重新编译。
- 如果捕获的图形在执行时无效，则可重新捕获图形。
PyTorch 的目标是创建一个用户体验流畅的统一前端，利用 Dynamo 生成图形。这种解决方案的用户体验将保持不变，但性能可以显著提高。而图捕获意味着执行可以更高效地在大量计算资源的基础上并行化。
Dynamo 和 AOT Autograd 会将优化的 FX 图传递到 PyTorch 本地编译器层级，即 TorchInductor。其他硬件公司也可以将此图输入到其自己的后端编译器中。
TorchInductor
TorchInductor 是一个 Python 原生深度学习编译器，可为多个加速器和后端生成快速代码。Inductor 会将有约 250 个操作符的 FX 图降低到约 50 个左右。然后，Inductor 将进入调度阶段，在这一阶段，算子被融合，内存规划也将确定。
然后，Inductor 会进入“代码封装（Wrapper Codegen）”阶段，生成可在 CPU、GPU 或其他 AI 加速器上运行的代码。代码封装取代了编译器堆栈中的解释器部分，并可以调用内核和分配内存。后端代码的生成部分利用 OpenAI Triton 生成 GPU 的 PTX 代码。对于 CPU，Intel 编译器所生成对 C++ 代码也适用于非英特尔 CPU。
Inductor 将支持更多硬件，但关键在于 Inductor 大幅减少了为其 AI 硬件加速器编写编译器时编译器团队必须完成的工作量。此外，代码的性能也得到了进一步优化，显著降低了内存带宽和容量需求。
我们不希望构建一个仅支持 GPU 的编译器，我们希望创建的是能够扩展到支持各种硬件后端的工具，而 C++ 和 [OpenAI] Triton 的出现，则迫使我们一定要具备这种通用性。—— Jason Ansel – Meta AI
OpenAI Triton
OpenAI 的 Triton 对 Nvidia 机器学习闭源软件的护城河产生了颠覆性的影响。Triton 可直接使用 Python 或通过 PyTorch Inductor 栈提供数据，后者将是最常见的用例。然后，Triton 会将输入转换为 LLVM 中间表示并生成代码。对于 Nvidia GPU，它可以直接生成 PTX 代码，跳过 Nvidia 的闭源 CUDA 库（如 cuBLAS），转而使用开源库（如 cutlass）。
CUDA 常用于加速计算领域，但在机器学习研究人员和数据科学家中的知名度较低。要高效使用 CUDA 可能具有一定挑战性，并且需要对硬件架构有深入了解，这可能会拖慢开发进程。因此，机器学习专家可能需要依赖 CUDA 专家来修改、优化和并行化他们的代码。
Triton 弥补了这一差距，使高级语言能够实现与使用低级语言相当的性能。Triton 的内核代码对于一般的机器学习研究人员来说非常容易理解，这对于可用性而言非常重要。Triton 在 SM 中自动进行内存凝聚、共享内存管理和调度。Triton 对元素层面的矩阵乘法的帮助不大，因为后者已经被执行得足够高效了。Triton 在昂贵的逐点操作和减少更复杂操作（例如涉及矩阵乘法作为更大融合操作的一部分的 Flash Attention）的开销方面非常有用。
目前，OpenAI Triton 只正式支持 Nvidia GPU，但在不久的将来会有所改变。未来还将支持多个其他硬件供应商，而这个开源项目正在取得令人难以置信的发展势头。其他硬件加速器能够直接集成到 Triton 的 LLVM IR 中，这极大地缩短了为新硬件构建 AI 编译器堆栈所需的时间。
Nvidia 的庞大软件组织缺乏远见，未能利用其在机器学习硬件和软件方面的巨大优势，成为机器学习的默认编译器。正是由于他们缺乏对可用性的关注，OpenAI 和 Meta 等外来者才得以创建可移植到其他硬件的软件栈。为什么他们不为机器学习研究人员构建一个像 Triton 的”简化版” CUDA？像 Flash Attention 这样的东西为什么出自博士生之手，而不是 Nvidia？
本报告的剩余分将指出在 Microsoft 取得巨大成功的特定硬件加速器，以及多家公司的硬件正在迅速集成到 PyTorch 2.0/OpenAI Triton 软件堆栈中。此外，报告还将分享相反的观点，为 Nvidia 在人工智能训练市场的护城河和实力提供辩护。
首先，关于将与 OpenAI Triton 集成的硬件。AMD 和 Tenstorrent 正在积极深度集成到该软件堆栈中。AMD 已经在 GitHub 上公开了多次提交。Luminous Computing 的 AI 超级计算机正在 PyTorch Dynamo 层面整合其软件栈。
据称，Microsoft 将通过 AMD 的 MI300 CPU/GPU 系列在硬件方面大获全胜。Microsoft 显然会继续购买 Nvidia，一定规模的 MI300 将有助于开始打破护城河。AMD 在这里的强项是其硬件工程。AMD 的下一代 MI300 堪称工程奇迹。AMD 对 perf/W 的要求非常高。虽然 Intel 和 Nvidia 都希望将 GPU 和 CPU 集成到同一个软件包中，但 AMD 将在 2023 年下半年开始将它们安装到下一代 HPC 中。此外，AMD 还将通过真正统一的 HBM 内存将这一切整合到一个封装中。我们过去曾专门撰文介绍过 MI300 的封装，它将是独一无二的，远远领先于英特尔和 Nvidia 在同一时间段推出的产品。
该芯片可自行配置，可以拥有不同数量的 CPU 或 GPU 芯片。上面的渲染图中有 4 个 6nm 的芯片和 9 个位于其上的 5nm 芯片。在其中的一个 6nm 芯片上有 3 个 5nm 的 Zen 4 CPU 芯片，而在其他 3 个 6nm 芯片的每一个上面都有 2 个 5nm 的 GPU 芯片。但我们不确定他们是否会同时推出其他变体。
AMD 所宣称的性能似乎非常出色，尤其是当你看到 AMD 的一些注脚时。例如，8 倍的 AI 性能，以及 5 倍的 AI perf/W。AMD 在 560W 的 TDP 下测得 MI250X 的 FP16 性能为 306.4 TFLOPS，这相当于其理论峰值性能的 80%。AMD 声称 MI300 的性能使用的是 FP8，鉴于数值格式不同，这样的比较有点不真实。但无论如何，根据 AMD 的说法，MI300 在 900W TDP 下的 FP8 性能约为 2,400 TFLOPS，实现了 5 倍的 perf/W。而与 MI250X 相比，实现了 8 倍的 perf/W。Nvidia 的 Hopper GPU 单独就能在 700 瓦的功耗下实现约 2,000 TFLOPS 的 FP8 性能，但它缺少 CPU 组件。
一旦将 Grace CPU 组件包括在内，功耗将升至约 900W，但 CPU 内核也会带来轻微的性能提升。原始的 TFLOPS/W 与 MI300 类似。Nvidia 的 Grace Hopper 量产时间比 MI300 稍早。由于在封装、制造成本和 NVLink 网络方面的差异，它还是一种可以扩展到更大容量的设计。它的主要缺点是它仍然必须将数据从封装中传输出来，在 CPU 和 GPU 之间传输。虽然它使用的是 NVLink，但在每比特功耗、延迟和带宽方面，没有什么能与封装内传输相比。
对于上述报告的辩护是，Triton 目前大量使用了 Nvidia 的开源库，如 Cutlass。这些库对于第三方与 AMD 硬件进行集成几乎不存在。当然，Nvidia 开源了许多东西，这些东西很快就被第三方厂商采用，包括 Megatron 等框架，该框架已经得到亚马逊内部训练硬件的支持。
对于 AI 培训领域的硬件公司来说，最关键的是以尽可能简单的方式向用户展示正确层次的控制。用户希望能够调整和尝试理解为什么他们编写的模型性能较差，但与此同时，与硬件的连接不能过于底层。
Nvidia 今天已经提供了这个功能。
此外，我们还跳过了有关融合策略的整个讨论，并不是每个硬件都能以相同的方式融合相同的操作。这是一个需要慎重考虑的决策，融合策略应该在不同代的硬件之间进行调整。
Google 的 XLA 已经为不同版本的 TPU 提供了这种功能。目前，在 PyTorch和 Triton 中，默认情况下会对 Nvidia 硬件进行优化。因为这需要一定的时间来调整这一策略以适应其他硬件平台。
我们还跳过了整个分布式硬件的部分：即在何时、何地以及如何拆分网络、张量、流水线、数据等，这些决策是由模型训练员明确执行的。他们更偏向使用 Nvidia 的各种分布式训练库，例如 NCCL。相比之下，竞争对手的库，如 AMD 的 RCCL，在这方面明显滞后。
需要注意的是，Nvidia 的 NVSwitch 装置已经开始发货。上文稍微详细讨论了这一点，即 Nvidia 在一定程度上过度构建了网络。此外，他们还在交换机中执行一些计算操作，例如全局归约，这是其他公司都没有尝试过的。这将使扩展到成千上万个加速器的规模变得更加容易。
Nvidia 在网络、软件和市场占有方面都具有一定优势。这些优势在未来仍将保持强劲，Nvidia 将继续占据 90% 以上的市场份额。一个重要的威胁是，超大规模公司将能够以合理的计算成本和内存组合应对许多工作负载，而无需支付 Nvidia 的高额溢价。
对于 Nvidia 而言，它缺乏一种在没有云服务商保证金 x Nvidia 保证金的情况下为人工智能租用 Nvidia GPU 的方法。我们预计，Nvidia 将在未来推出更多训练托管服务，以应对这一边际堆叠问题。否则，内部硬件将开始通过更低的成本击败他们。值得注意的是，Nvidia 已经提供了云游戏服务（GeForce Now）和创意云服务（Omniverse），因此这并非不可能。
*以上文章翻译自 DYLAN PATEL 的《How Nvidia’s CUDA Monopoly In Machine Learning Is Breaking – OpenAI Triton And PyTorch 2.0》，如需原文，请与我们联系。
