摘要：英伟达在开发者社区中享有盛誉。不少代码库都专门针对这家特定品牌的硬件所编写和优化，而其他同样面向底层GPU编程的竞争框架则远远不够成熟。这样的早期格局，往往被人们称为“CUDA护城河”。

英伟达正面临着多年以来最激烈的竞争态势，英特尔及AMD的新款加速器试图在内存容量、性能以及价格等多个方面对其芯片产品发起猛攻。

然而，单纯打造一款有竞争力的产品还远远不够：厂商还必须开发出能够充分发掘算力资源的软件——英伟达花了近二十年时间，才构建起强大的CUDA运行时生态。

英伟达在开发者社区中享有盛誉。不少代码库都专门针对这家特定品牌的硬件所编写和优化，而其他同样面向底层GPU编程的竞争框架则远远不够成熟。这样的早期格局，往往被人们称为“CUDA护城河”。

那么，让英伟达引以为傲的这条护城河到底有多深？

其实可以想见，这个问题的答案取决于我们想要实现的目标。如果正面向GPU进行底层编程，那么CUDA护城河就相当真实具体，意味着必须对现有代码进行移植、重构和优化才能在其他替代硬件上运行。

这并不难理解，毕竟CUDA和英伟达芯片中的某些硬件调用在英特尔或者AMD硬件当中根本不存在——反之亦然。也就是说要想把三年、四年甚至是十年之前为CUDA开发的代码引入AMD ROCm或者英特尔OneAPI，首先需要说服已经习惯于英伟达平台的开发者们。

也正因为如此，英特尔和AMD才投入巨资开发工具，希望实现将CUDA源代码转换为各自平台可以运行的自动化流程。比如说AMD的HIPIFY，就能帮助自动将CUDA转换为HIP C++代码。

AMD公司AI部门高级副总裁Vamsi Boppana在采访中表示，“对于那些负责编写内核的开发者而言，他们已经非常习惯用CUDA来完成，至少多年以来已经积累下大量CUDA代码。我认为我们是唯一能够帮助其顺利完成迁移的替代方案，因为我们提供HIPIFY以提供可以编译的HIP C++代码。”

虽然确实在很大程度上解决了问题，但HIPIFY也还远称不上完美。根据技术媒体的调查，HIPIFY面临的一大挑战就是其没有考虑纹理内存中的设备端模板参数或者多个CUDA头文件的情况，这些都需要由开发人员手动干预。

另一方面，英特尔则拥有SYCL。它与HIPIFY类似，能够承担起大部分繁重的迁移工作（据称高达95%），高效将CUDA代码移植至可以在非英伟达加速器（包括AMD及其他厂商的加速器）上运行的格式。

最后需要着重提到的，还有AMD悄悄资助开发的项目，号称能够将未经转译的CUDA代码直接在其硬件上原生运行。但就在今年早些时候，可能是担心违反英伟达的CUDA服务条款规定、也可能出于其他考虑，AMD方面放弃了这一努力，并采取措施压制了开发人员的进一步尝试。

但虽然CUDA护城河对于希望扩大对替代硬件平台的支持范围的开发者来说是铁一般的事实，但至少在英特尔和AMD的高管们看来，真正需要在内核级别编写代码的开发人员其实并不太多。

英特尔公司数据中心与AI软件副总裁Bill Pearson在最近一次采访中指出，“几年之前整个市场就只有CUDA，人们也习惯于直接编程。但现在，我们看到大多数开发人员都已经在PyTorch或者其他框架上编程。”

AMD公司的Boppana也解释道，该公司在其Instinct加速器上也看到了类似的情况，即过去一年间该款加速器的采用率迎来飙升。“现实情况是，人们希望在更高级的抽象层上进行编程。”

由PyTorch构建起的阶梯

在这波趋势之下，PyTorch尤其成为各大兜售英伟达替代产品的AI芯片厂商的首选。虽然并不是面向现代加速器的唯一高级编程语言，毕竟还有TensorFlow、JAX以及其他多种选项，但PyTorch无疑是最受欢迎的语言之一。

多年以来，AMD的ROCm一直得到PyTorch的原生支持，而对英特尔GPU的支持也在今年早些时候正式推出。我们在后文中会具体聊聊PyTorch对于IPEX和Gaudi的支持，但在此之前，不妨先对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和英特尔GPU客户面对的情况只会更加复杂。

英特尔、AMD以及英伟达已经在采取措施应对其中部分挑战，具体办法就是提供作为开发环境的预配置容器镜像。正如前文已经提到，这些容器镜像可以简单被预配置为ROCm、OneAPI或者CUDA环境，也可以包含完整的PyTorch安装。

Pearson解释称，“比方说，当我们有了PyTorch容器，那么接下来只需要获取Gaudi运行需要的所有库即可。”

正是因为对PyTorch的具体支持在各家硬件供应商之间各有不同，这些容器的出现才显得格外重要。

对于英特尔来说尤其如此，他们提供面向其GPU及Gaudi3加速器进行调整的定制版PyTorch。访问PyTorch网站、向下滚动，大家就会很快意识到这里根本不提供OneAPI或者Gaudi选项。这是因为Gaudi加速器上的PyTorch支持，实际上依赖于英特尔开发的自定义库版本。

直到最近添加对PyTorch的原生支持之前，英特尔GPU的情况也基本类似。好在虽然这项原生支持能力尚处于预览阶段，所以还没有正式登陆PyTorch官方主页，但其确实存在而且我们也亲自进行了测试。

而且在英特尔GUP添加原生PyTorch支持能力之前，这种兼容性主要是依靠名为Intel Extension for PyTorch（即英特尔PyTorch扩展，简称IPEX）的自定义版本实现的。该软件包含一系列性能优化和库，旨在以更加无缝的方式让代码运行在英特尔的加速器之上。

Pearson解释道，“我们已经完成了优化工作，先是构建库、之后优化GEMM和这些库的具体内容，由此帮助开发人员轻松使用我们提供的模板编写PyTorch代码，或者使用我们的现有代码以实现从CUDA向Gaudi的迁移。”

他同时补充称，“这种方式的开发体验总体上还是比较轻松的，虽然还达不到零负担，但整个过程确实不需要太多额外调整。大致的操作就是将指向目标从英伟达变更为Gaudi，然后将输出也调整至同一目标。”

虽然我们还没有测试过英特尔的Gaudi平台，但基本可以认定，很多PyTorch脚本只需稍加调整就可以在IPEX之下运行。

随着各家芯片制造商推动对于主流框架和库的原生支持，最大的问题已经不在于其是否能够运行，而是运行性能如何。

磕磕绊绊的开发流程

为x86或者Arm CPU构建应用程序之所以如此简单，最重要的原因之一就是所需的硬件无处不在、能够轻松获取。大家可以在笔记本电脑、台式机或者工作站上着手构建，并在改进成熟之后通过CI/CD（持续集成/持续部署）管线将其扩展至专用构建环境。

对于在英伟达硬件上构建项目的开发者来说，情况也差不多。除了少数例外，CUDA在移动GPU上的运行方式跟在3万美元的H100GPU上完全相同。也就是说，只要你的系统配备有英伟达GPU，那么开发前的一切准备工作就已然就绪。

但在竞争对手这边，事情就没这么顺利了。在台式机和工作站领域，AMD拥有Radeon和Radeon Pro GPU，它们使用的是自家RDNA微架构，而其专注于数据中心的Instinct芯片则使用其CDNA架构。尽管存在诸多差异，AMD仍然将ROCm支持扩展到了部分7000系列Radeon卡之上，以期巩固其在开发者群体中的认可度。

在大多数情况下，我们发现一切确实能够正常运行。可话虽如此，我们在Flash Attention 2上还是遇到了麻烦——这是一套相当重要的库，负责在更大的上下文长度之下保证生成式AI模型始终拥有可控的内存占用量。实际上Instinct家族对于Flash Attention 2的支持已经落实了一段时间，但将该库引入Radeon的努力却仍在进行当中。

还是以Flash Attention为例，之前出现的Triton内核库就能有效动用内存，以在某些情况下克服这方面局限。比如我们在最近的Axolotl微调指南中就使用了一款实验性的AoT Triton内核。

但这在很大程度也跟市场的整体倾向有关。其实不难想象，相较于那些专业构建训练集群并依托拥有万亿以上参数的大体量模型运行推理的用户相比，想要使用游戏GPU编写机器学习应用程序的群体在规模上确实相对更小。

Boppana也承认，“我们仍然将主要精力集中在保障Instinct的兼容性身上，这也是我们诸多项目的考量重点。”尽管MI300X一年多之前才首次亮相，但该部件已经在云端得到广泛部署，包括通过长期合同以及按需调用等形式。

但Boppana也意识到了市场对于工作站级硬件的需求。他观察到，“我个人认为云不可能是唯一的方法，开发人员都希望在自己的办公桌下摆一台工作站，这样他们就可以随意探索尝试、不必太多考虑运行成本。”

对于英特尔来说，情况则更加复杂。英特尔的旗舰级AI加速器是Gaudi 3——而至少到目前，这款硬件还不提供任何工作站版本。

更重要的是，Gaudi加速器实际上并不支持OneAPI，反而依赖于Habana自家的SynapseAI软件技术栈。也就是说，打算在Gaudi之上构建应用程序的开发人员，实际只能使用英特尔的Tiber开发者云。

当然，英特尔家的GPU（包括其Arc游戏显卡）倒是都能支持OneAPI。因此如果想要编写可以扩展至Datacenter Flex或者GPU Max显卡集群的代码，肯定是没有问题。可话虽如此，根据我们的观察，各类软件支持永远是先在Datacenter Flex这边实现，之后才被推向Arc。

另一个不容忽视的问题，就是GPU Max（又名Ponte Vecchio）已经落伍。因此除了阿贡国家实验室（其Aurora系统中安装有6万多张这款GPU）之外，我不确定还有多少人会在生产场景中为其编写代码。

随着明年Falcon Shores的推出，这种情况可能会改变，其将采用GPU架构以及一系列继承自Gaudi的设计元素。据推测，这款加速器也将支持OneAPI。

绕过护城河

虽然CUDA护城河对于开发者和芯片制造商来说仍是一大现实挑战，但对于只是想大规模构建大语言模型的用户，这其实并不需要各位太过担心。

无论大家选择哪种硬件——包括英特尔、AMD、Cerebras、SambaNova、高通或者其他厂商——所有这些供应商都开发或者贡献了能够让大模型顺利生成token所需的必要代码。

几乎每家厂商都有自己的框架，用于简化在其硬件上部署聊天机器人式应用方案（例如检索增强生成RAG）的具体流程。

当然，在某些情况下，开发人员也确实希望获得与OpenAI相兼容的API服务器。毕竟当下的很多AI应用程序实际上就是围绕着OpenAI、Anthropic或者Mistral AI API服务器构建的打包器——也就是说，其代码从来不需要直接跟GPU或者AI加速器执行交互。

也就是说其代码相对易于移植。例如，可以使用Anthropic的Claude构建概念验证，而后出于安全或者合规考虑，在投入生产之后将API服务器及密钥更换成vLLM或者TensorRT-LLM的本地实例。

然而，尽管几乎任何AI加速器都可以支撑起大语言模型，但这并不代表其性能或者运行效率都能满足开发者们的需求。

在最近的MLPerf推理测试当中，AMD表示其MI300X加速器在性能上已经与英伟达家备受推崇的H100几乎相当。从理论上讲，MI300X加速器拥有更高的内存带宽和更强大的浮点性能，拥有这些优势完全在意料之中。但这毕竟是AMD的首次公开比较，背后有着极其重大的现实意义。

而且自此之后，我们又迎来了ROCm的一系列更新，旨在提高各类主流模型运行器（包括vLLM和S-Lang）的性能表现。相信在这些更新的加持之下，MI300X将迸发出更强劲的性能表现。

相比之下，Gaudi 3尚未正式在MLPerf训练或者推理测试中亮相。长期以来，英特尔能够拿来与英伟达竞争的就只有Gaudi 2加速器。

所以也可以这样总结：尽管未必像很多朋友想象中那般坚不可摧，但仍比英特尔或者AMD所希望的更深。

来源：至顶网