英伟达CUDA的护城河到底有多深？

英伟达（Nvidia）正面临着多年以来最激烈的竞争，来自英特尔和 AMD 的新加速器在内存容量、性能和价格方面都对其最好的芯片构成了挑战。

然而，仅仅打造一个有竞争力的部件是不够的，你还必须拥有能够利用所有这些 FLOPS 的软件。为此，英伟达花了近二十年的时间在其 CUDA 运行时上构建这些软件。

英伟达在开发者社区中建立了良好的声誉。许多代码库都是针对其特定品牌的硬件而编写和优化的，而用于低层级 GPU 编程的竞争框架则远没有那么成熟。这种早期势头通常被称为“CUDA 护城河”。

但这条护城河到底有多深呢？

你可能已经猜到了，答案实际上取决于你想要实现的目标。 如果你正在为 GPU 进行低层级编程，那么 CUDA 护城河就是非常真实的。现有的代码必须移植、重构和优化，才能在替代品硬件上运行。

这是很难避免的，因为在 CUDA 和英伟达芯片中存在的某些硬件调用，根本不适用于英特尔或 AMD 硬件，反之亦然。这意味着，将三年、四年甚至十年前最初为 CUDA 开发的代码移植到 AMD 的 ROCm 或英特尔的 OneAP 需要开发人员的投入。

正因为如此，英特尔和 AMD 在工具上投入了大量的资金，以自动化 CUDA 源代码的转换过程，使其在它们各自的平台上运行。AMD 有 HIPIFY，它有助于将 CUDA 自动转换为 HIP C++ 代码。

AMD 人工智能集团高级副总裁 Vamsi Boppana 表示：“如果有人真的在做一些内核编码，并且他们非常习惯用 CUDA 来编写，或者他们实际上有一堆的 CUDA 代码，那么我认为，我们就是唯一能够实现平稳迁移路径的替代方案，因为我们有 HIPIFY，你可以得到 HIP C++，而且你也可以编译”。

虽然这可能有一定的道理，但 HIPIFY 并不完美。The Next Platform 之前强调的一个挑战是，HIPIFY 没有考虑纹理内存的设备端模板参数或多个 CUDA 头文件，因此需要开发人员手动干预。

与此同时，英特尔拥有 SYCL。它与 HIPIFY 类似，可以处理大部分繁重的工作（据称高达 95%），即将 CUDA 代码移植到可以在非英伟达加速器上运行的格式，包括来自 AMD 和其他公司的加速器。

最后，我们必须指出的是，AMD 悄悄资助了一个项目的开发，使未转换的 CUDA 代码能够在其硬件上原生运行。然而，今年早些时候，它放弃了这一努力，并采取措施来阻止开发人员的进一步工作，原因我们之前已经深入讨论过。

但是，尽管对于希望通过扩展来支持可替代硬件平台的开发人员来说，CUDA 护城河无疑是一个事实，但直接在内核级别编码的开发人员数量相对较少——至少英特尔和 AMD 的高管都是这样告诉 El Reg 的。

英特尔数据中心和人工智能软件副总裁 Bill Pearson 在最近的一次采访中告诉 The Register：“几年前，大家都在用 CUDA 编程，而且都是直接编程。但现在，我们看到大多数开发人员都在 PyTorch 级别或其他框架上编程。”。

AMD 的 Instinct 加速器也出现了类似的情况，去年该加速器的采用率突然上升。Boppana 解释道：“现实情况是，人们希望在更高的抽象层次上编写代码。”。

特别是 PyTorch，已经成为许多人工智能芯片公司兜售英伟达替代品的首选。它并不是唯一用于现代加速器的高级编程语言，还有 TensorFlow、JAX，可能还有一些我们忘记了的语言，但它是最受欢迎的语言之一。

就 AMD 而言，多年来，PyTorch 一直享有对 ROCm 的原生支持，而对英特尔 GPU 的支持则在今年早些时候才开始推出。稍后我们将简要介绍 IPEX 和 Gaudi 的 PyTorch 特殊品牌，但在此之前，让我们谈谈 PyTorch 的一般情况，因为它有时不一定是芯片制造商所说的灵丹妙药。

PyTorch 背后的想法是，它存在于 CUDA、ROCm 或 OneAPI 等框架之上，只需根据系统中安装的硬件调用相应的后端。理论上，这意味着为 PyTorch 编写的代码应该可以在支持它的任何设备上运行。

Boppana 指出：“对于那些使用诸如 PyTorch 之类的现代框架并支持一组标准库的人来说，我认为这是一条非常简单、低摩擦的通向 GPU 的路径。”。

在实践中，我们还没有完全做到这一点。仅仅因为 PyTorch 可以在这些加速器上工作并不意味着不会再有其他麻烦。

事实仍然是，许多用于构建 PyTorch 应用程序的库和模块在添加对替代架构的支持方面进展缓慢。因此，通常需要一定程度的重构才能使现有脚本运行。

BitsandBytes 只是一个例子。量化库通常用于推理和 QLORA 微调，以减少 LLM 的内存占用，从而可以使这些工作负载在单个 GPU 或节点上完成。

不幸的是，直到最近，BitsandBytes 还没有原生支持英特尔或 AMD 硬件。这意味着你不能像在英伟达硬件上那样运行 pip install bitsandbytes 并期望它能正常工作。相反，英特尔和 AMD 用户不得不追踪特定于供应商的代码分支，并希望它能与最新版本的 PyTorch 和 Python 兼容。

需要明确的是，这不仅仅是 BitsandBytes 的问题——这是很多库的现实问题。

Pearson 解释道：“开发人员希望有库。你已经构建了 GEMM 并对其性能进行了优化，我们必须确保我们有相同版本的 GEMM、库和其他东西。”。

通常，这涉及芯片制造商与社区的合作，对代码库进行分支、修改、在他们的硬件上运行，然后，理想情况下，将调整贡献回主干分支。

“如果我们认为某个特定的库或一组技术在市场上占据了主导地位，那么我们就会吸收并推动它。更重要的是，我们想说社区会推动它，因为我们只能做这么多。”Boppana 解释道。“如果社区已经开始在做贡献了，那么我们绝对会促进这一点。”

好消息是，这种情况正在发生。

Pearson 说：“这些依赖关系——那些独特且依赖于较低层级的小块——在某些情况下仍然存在，但它们越来越少了，而且它们正在一点一点地消失。”。

自从 BitsandBytes 第一次遇到兼容性问题以来，我们观察到对 AMD 和英特尔 GPU 的支持已经通过一个实验性的“多后端”版本进行了扩展。然而，在发布时，安装它仍然不像在英伟达硬件上那么简单。

尽管支持率正在提高，但仍有很多地方需要弥补。

正如你所想象的那样，兼容库的碎片化会造成某种软件的兼容性雷区。除非你拥有正确版本的 Python、PyTorch、BitsandBytes——谁知道还有什么——否则很容易陷入这样的境地：你的脚本出错了。

公平地说，英伟达的客户肯定也会遇到这种情况。但是，由于需要跟踪并在许多情况下编译流行库的兼容版本，这会使情况变得更加复杂。

英特尔、AMD 和英伟达已经采取了措施，方法是提供用作开发环境的预配置容器镜像来缓解其中一些挑战。正如我们之前所探讨的，这些容器镜像可以像预配置的 ROCm、OneAPI 或 CUDA 环境一样简单，也可以包含完整的 PyTorch 构建安装。

“我们有一个容器，例如 PyTorch 容器，你可以去获取 Gaudi，它拥有所有需要的库。”Pearson 解释道。

只有当你意识到 PyTorch 支持在不同的硬件供应商之间并不总是意味着同样的事情时，这些容器的可用性才会变得更加重要。

对于英特尔来说尤其如此，它提供了针对其 GPU 和 Gaudi3 加速器的定制版本的 PyTorch。前往 PyTorch 网站，向下滚动，你很快就会意识到没有 OneAPI 或 Gaudi 选项。这是因为 PyTorch 对 Gaudi 加速器的支持依赖于英特尔开发的库的自定义版本。

直到最近，英特尔 GPU 才添加了原生 PyTorch 支持，在此之前它也存在类似的情况。其原生支持仍处于预览阶段，因此从 PyTorch 主页上可能看不出来，但它确实存在了，我们已经对其进行了测试。

然而，在英特尔的 GPU 添加原生 PyTorch 支持之前，它们依赖于一个名为“英特尔 PyTorch 扩展”（Intel Extension for PyTorch）的自定义构建，简称 IPEX。该软件包包括各种性能优化和库，旨在使在其加速器上的运行代码更加无缝。

Pearson 解释说：“我们已经完成了优化方面的工作，首先构建库，然后优化 GEMM 和这些库中的其他内容，然后让开发人员能够轻松地使用我们提供的模板编写 PyTorch 代码，或者将我们现有的代码从 CUDA 迁移到 Gaudi。”。

“当他们这样做时，他们的体验将在很大程度上变得简单，因为这不是零工作量，但也不需要做很多工作。这涉及将目标从 Nvidia 更改为 Gaudi，然后将输出更改为相同的目标。”他补充道。

虽然我们还没有测试英特尔的 Gaudi 平台，但我们可以说，很多 PyTorch 脚本只需要进行一些调整，就可以在 IPEX 下运行。

随着芯片制造商对流行框架和库原生支持的推动，问题不再是某些东西是否可用，而是性能如何。

使为 x86 或 Arm CPU 构建应用程序如此简单的原因之一是，所需的硬件无处不在。你可以在笔记本电脑、台式机或工作站上开始构建，并随着 CICD 管道的成熟而扩展到专用的构建环境中。

对于在英伟达硬件上构建的开发人员来说，情况也类似。除了少数情况外，CUDA 在移动 GPU 上的运行方式与在 30000 美元的 H100 上的运行方式相同。这意味着，如果你有一个内置了英伟达 GPU 的系统，你就已经拥有了开始开发所需的一切。

但对它的竞争对手来说，就不是那么无缝了。在台式机和工作站领域，AMD 拥有 Radeon 和 Radeon Pro GPU，它们使用其 RDNA 微架构，而其专注于数据中心的 Instinct 芯片则使用其 CDNA 架构。尽管存在这些差异，AMD 仍将 ROCm 支持扩展到了选择 7000 系列的 Radeon 卡上，以支持其开发管道。

在大多数情况下，我们会发现一切正常。话虽如此，但我们在 Flash Attention 2 之类的东西上遇到了麻烦，这是一个相当重要的库，有助于在更大的上下文长度下控制 GenAI 模型的内存消耗。Instinct 部件支持 Flash Attention 2 已经有一段时间了，而将该库引入 Radeon 的努力仍在进行中。

就 Flash Attention 而言，提前出现的 Triton 内核库可以有效地利用内存，可用于在某些情况下克服这一限制。例如，我们在最近的 Axolotl 微调指南中使用了实验性的 AoT Triton 内核。

这在很大程度上取决于市场的优先级。正如你所料，与那些试图构建训练集群和推理数万亿以上参数模型的人相比，想要使用游戏 GPU 编写机器学习应用程序的人数相对较少。

Boppana 承认：“我们仍然非常专注于确保 Instinct 是我们许多优先事项的重点。”并补充说，尽管 MI300X 在一年多前才首次亮相，但通过长期合同或按需服务，该部件已在云上广泛使用了。

然而，Boppana 认识到对工作站级硬件的需求。他评论道：“我个人认为（云）不是唯一的方法，开发人员喜欢办公桌下面的工作站，这样他们的开发就能随意的多了。”。

英特尔面临的情况更为复杂。英特尔的旗舰 AI 加速器是 Gaudi3，至少目前还没有该部件的任何工作站版本。

更重要的是，Gaudi 加速器实际上并不支持 OneAPI，而是依赖于 Habana 自己的 SynapseAI 软件栈。这意味着对于希望在 Gaudi 上构建应用程序的开发人员来说，实际上只能使用英特尔的 Tiber 开发人员云。

当然，英特尔的 GPU（包括其 Arc 游戏卡）都支持 OneAPI。因此，如果你想编写可扩展或扩展到 Datacenter Flex 或 GPU Max 卡集群的代码，你是可以做到的。话虽如此，我们观察到，软件支持通常在到达 Arc 之前先到达了 Datacenter Flex。

另一个不容忽视的问题就是 GPU Max，又名 Ponte Vecchio，已经过时了。因此，在阿贡国家实验室（其 Aurora 系统中有 6 万多个 GPU Max）之外，我们不确定还有多少人会在生产环境中为它们编写代码。

这可能会随着明年 Falcon Shores 的推出而改变，Falcon Shores 将采用 GPU 架构，并搭载一些类似 Gaudi 的设计元素。据推测，该部件还将支持 OneAPI。

虽然 CUDA 的护城河对开发人员和芯片制造商来说仍然是一个持续的挑战，但如果你想做的只是大规模地提供 LLM，那么这并不是你真正需要担心的事情。

无论你选择什么硬件——英特尔、AMD、Cerebras、SambaNova、高通或其他公司——所有这些供应商都开发或贡献了使 LLM 生成 token 所需的必需代码。

几乎每家都有一个框架，用于在他们的硬件上简化聊天机器人风格的应用程序的部署，比如检索增强生成（RAG）。如果你不熟悉这个概念，我们鼓励你在这里查看我们的实践指南。

然而，在某些情况下，提供与 OpenAI 兼容的 API 服务器的能力正是开发人员真正想要的。今天的许多人工智能应用程序实际上只是围绕 OpenAI、Anthropic 或 Mistral AI API 服务器构建的包装器——这意味着代码永远不必直接与 GPU 或 AI 加速器交互。

这也意味着代码是相对可移植的。例如，可以使用 Anthropic 的 Claude 构建一个概念验证，然后出于安全或合规原因，一旦投入生产，就可以将 API 服务器和密钥换成 vLLM 或 TensorRT-LLM 的本地实例。

但是，虽然几乎任何 AI 加速器都可以提供 LLM，但这并不意味着它的性能或效率都达到了应有的水平。

在最近提交的 MLPerf 推理中，AMD 展示了其 MI300X 加速器与英伟达备受推崇的 H100 不相上下。理论上，该部件更高的内存带宽和更快的浮点性能应该会给它带来更大的优势，但对于第一次提交的作品来说，这并非一无是处。

从那时起，我们看到了 ROCm 的许多更新，旨在提高流行模型运行程序的性能，包括 vLLM 和 SG Lang，这些更新有望释放额外的性能。

尽管 Guadi3 尚未在 MLPerf 训练或推理中首次亮相，但很长一段时间以来，Gaudi2 是唯一值得英伟达提及的竞争产品。

对于许多开发人员来说，英伟达 CUDA 的护城河虽然并不像你想象的那么深，但它比 AMD 或英特尔想要的要深。

https://www.theregister.com/AMP/2024/12/17/nvidia_cuda_moat

声明：本文为 InfoQ 翻译，未经许可禁止转载。

InfoQ 老友！请留步！极客邦 1 号客服上线工作啦！