让不懂建站的用户快速建站，让会建站的提高建站效率！
发布日期：2024-12-18 08:15 点击次数：66
（原标题：CUDA护城河，有多深？）
要是您但愿不错常常碰头，接待标星保藏哦~
Nvidia 正面对着多年来最强烈的竞争，英特尔和 AMD 推出的新加快器在内存容量、性能和价钱方面对其最好芯片组成挑战。
然而，只是打造一个有竞争力的部件是不够的：你还必须领有不错行使整个 FLOPS 的软件——Nvidia 花了近二十年的期间通过其 CUDA 运行时来构建它。
Nvidia 在开导者社区中地位显耀。许多代码库齐是针对其特定品牌的硬件编写和优化的，而竞争的初级 GPU 编程框架则远莫得那么熟习。这种早期势头频频被称为“CUDA 护城河”。
但骨子上这条护城河到底有多深？
“坚不可摧”的CUDA
您可能一经猜到了，谜底骨子上取决于您念念要结束的办法。要是您正在为 GPU 进行初级编程，那么 CUDA 护城河就相称确凿。现存代码必须移植、重构和优化才气在替代硬件上运行。
这是很难幸免的，因为 CUDA 和 Nvidia 芯片中存在的某些硬件调用在 Intel 或 AMD 硬件中根底不存在——反之也是。这意味着将三年、四年致使十年前来源为 CUDA 开导的代码带到 AMD 的 ROCm 或 Intel 的 OneAPI 中是开导东说念主员的欢跃。
因此，英特尔和 AMD 参增加半资金开导器具，以自动化将 CUDA 源代码调遣为在各自平台上运行的历程。AMD 领有 HIPIFY，可匡助自动将 CUDA 调遣为 HIP C++ 代码。
AMD 东说念主工智能集团高等副总裁 Vamsi Boppana 告诉 El Reg：“要是有东说念主果真在作念一些内核创作（kernel authoring），而况他们相称习尚用 CUDA 来编写，或者他们骨子上有一堆闲置的 CUDA 代码，那么我合计，咱们是独一粗略结束沉静搬动旅途的其他信得过替代决议，因为咱们有 HIPIFY，你不错得到 HIP C++，而况你不错进行编译。”
天然这种说法可能有些意旨，但 HIPIFY 并不圆善。The Next Platform之前在之前的著述中曾强调过的一个挑战是，HIPIFY 莫得讨论纹理内存（texture memory）中的树立端模板参数（device-side template arguments ）或多个 CUDA 头文献（header files），因此需要开导东说念主员手动插手。
与此同期，英特尔领有 SYCL，它与 HIPIFY 近似，不错处置大部分贫寒的责任（据称高达 95%），将 CUDA 代码移植为不错在非 Nvidia 加快器（包括 AMD 和其他公司的加快器）上运行的时势。
临了，咱们不得不提的是，AMD 曾偷偷资助了一个技俩，让未翻译的 CUDA 代码粗略在其硬件上原生运行。然而，本年早些时候，AMD 毁掉了这一起劲，并给与方法进犯开导东说念主员进一步开展责任，原因咱们之前一经深切推敲过。
不外，尽管 CUDA 护城河关于但愿扩大对替代硬件平台的复古的开导东说念主员来说无疑是履行，但在内核级别编写代码的开导东说念主员数目相对较少 —— 至少英特尔和 AMD 的高管是这样告诉El Reg 的。
英特尔数据中心和 AI 软件副总裁 Bill Pearson 在最近吸收 The Register 采访时示意：“几年前，一切齐是 CUDA，东说念主们齐在平直层面进行编程。但现在，咱们看到大多数开导东说念主员齐在 PyTorch 层面或其他框架上进行编程。”
AMD 的 Instinct 加快器也出现了近似的情况，昨年该加快器的给与率顷刻间高潮。“履行情况是，东说念主们但愿在更高的概述端倪上进行编写，”Boppana 讲授说念。
基于 PyTorch 构建的梯子
PyTorch 尤其成为许多兜销 Nvidia 替代品的 AI 芯片公司的首选。它不是当代加快器的独一高等编程说话，还有 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 还没原生复古 Intel 或 AMD 硬件。这意味着您无法像在 Nvidia 硬件上那样运行“pip install bitsandbytes”并期许它粗略正常责任。相背，Intel 和 AMD 用户必须找到特定于供应商的代码分支，并但愿它粗略与最新版块的 PyTorch 和 Python 兼容。
需要明确的是，这不单是是 BitsandBytes 的情况——这是许多库的履行情况。
“开导东说念主员但愿库粗略存在。您一经领有已构建并经过性能优化的 GEMM，咱们必须确保咱们的沟通 GEMM 和库等的版块存在，”Pearson 讲授说念。
频频，这波及芯片制造商与社区和洽，分叉代码库，进行修改，在他们的硬件上运行，然后理念念情况下将调治孝敬回干线分支。
“要是咱们合计某个特定库或一组手艺具有市集主导需求，那么咱们就会倾向于鼓舞它。更热切的是，咱们但愿社区会鼓舞它，因为咱们能作念的有限，”Boppana 讲授说念。“要是社区开算作念出孝敬，那么咱们足够会复古它。”
好音问是，这样的情况正在发生。
Pearson说：“这些依赖关系——那些独到的、依赖于较低层的小块——在某些情况下仍然存在，但它们越来越非常，而况它们正在一丝一丝地灭亡。”
自从第一次际遇 BitsandBytes 兼容性问题以来，咱们留意到对 AMD 和 Intel GPU 的复古已通过实验性的“多后端”版块得到彭胀。然而，在发布时，装配它仍然不像在 Nvidia 硬件上那么浅陋。
不外，尽管复古正在改善，但仍有多半责任要作念。
软件兼容性雷区
您可能不错念念象得到，兼容库的碎屑化会形成软件兼容性问题。除非您领有正确版块的 Python、PyTorch、BitsandBytes（谁知说念还有什么），不然您的剧本就会出错，这种情况很容易发生。
平正地说，Nvidia 的客户也一定会际遇这种情况。但由于需要跟踪并在许厚情况下编译流行库的兼容版块，情况只会变得愈加复杂。
英特尔、AMD 和 Nvidia 已给与方法缓解其中一些挑战，方法是提供用作开导环境的预配置容器映像（container images ）。正如咱们之前所探讨的那样，这些容器映像不错像预配置的 ROCm、OneAPI 或 CUDA 环境相同浅陋，也不错包含完整的 PyTorch 装配。
“举例，咱们有一个容器 —— PyTorch 容器 —— 你不错去取得 Gaudi，它领有所需的整个库，”Pearson 讲授说。
当你清醒到 PyTorch 复古在不同的硬件供应商之间并不老是意味着归并件事时，这些容器的可用性才会变得愈加热切。
英特尔尤其如斯，它提供了针对其 GPU 和 Gaudi3 加快器进行调治的 PyTorch 定制版块。赶赴 PyTorch 网站，向下滚动，您很快就会清醒到莫得 OneAPI 或 Gaudi 的选项。这是因为 Gaudi 加快器对 PyTorch 的复古依赖于英特尔开导的库的定制版块。
直到最近添加了原生 PyTorch 复古后，英特尔 GPU 的情况才有了近似变化。原生复古仍处于预览阶段，因此从 PyTorch 主页上可能看不出来，但它确乎存在，而况咱们一经测试过了。
然而，在英特尔的 GPU 增加原生 PyTorch 复古之前，它们依赖于一个名为英特尔 PyTorch 彭胀（简称IPEX）的自界说版块。该软件包包含各式性能优化和库，旨在使在其加快器上运行代码愈加无缝。
“咱们在优化方面作念了许多责任，来源构建库，然后优化 GEMM 和这些库中的内容，然后开导东说念主员粗略平缓地使用咱们提供的模板编写 PyTorch 代码，或者给与咱们现存的代码并将其从 CUDA 搬动到 Gaudi，”Pearson 讲授说。
“当他们这样作念时，他们的体验将在很猛进度上变得平缓，因为这不是零责任（zero work），但也不是许多责任要作念。它波及将办法从 Nvidia 革新为 Gaudi，然后将输出革新为沟通的办法，”他补充说念。
天然咱们还莫得测试过英特尔的 Gaudi 平台，但咱们不错说，许多 PyTorch 剧本只需要进行极少调治就不错在 IPEX 下运行。
跟着芯片制造商鼓舞对流行框架和库的土产货复古，某些东西是否可行已不再是一个问题，而是一个性能若何的问题。
开导渠说念或缺少开导渠说念
为 x86 或 Arm CPU 构建应用门径如斯浅陋的原因之一是构建应用门径所需的硬件无处不在。您不错在条记本电脑、台式机或责任站上开动构建，并在其熟习时彭胀到具有 CICD 管说念的专用构建环境。
关于使用 Nvidia 硬件进行开导的开导东说念主员来说，情况也近似。除了少数例外，CUDA 在搬动 GPU 上的运行花样与在价值 30000 好意思元的 H100 上的运行花样沟通。这意味着，要是您的系统配备了 Nvidia GPU，那么您一经领有了开动开导所需的一切。
竞争敌手的情况就没那么顺利了。在台式机和责任站范畴，AMD 领有 Radeon 和 Radeon Pro GPU，它们使用 RDNA 微架构，而其专注于数据中心的 Instinct 芯片则使用 CDNA 架构。尽管存在这些互异，AMD 仍将 ROCm 复古彭胀到部分 7000 系列 Radeon 卡，以期巩固其开导东说念主员渠说念。
在大多数情况下，咱们发现一切正常。不外，咱们在使用 Flash Attention 2 等居品时际遇了贫乏，这是一个卓越热切的库，有助于在更大的高下文长度下限度 GenAI 模子的内存消费。Flash Attention 2 一经在 Instinct 部件上得到复古一段期间了，而将该库引入 Radeon 的起劲仍在进行中。
关于 Flash Attention 来说，提前推出的 Triton 内核库不错擢升内存行使率，在某些情况下不错克服这一为止。举例，咱们在最近的 Axolotl微调指南中使用了一个实验性的 AoT Triton 内核。
这在很猛进度上取决于市集优先规章。正如您所料念念的那样，与那些试图构建西宾集群和推理多半万亿以上参数模子的东说念主比较，念念要使用游戏 GPU 编写 ML 应用门径的东说念主数目相对较少。
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 系统中有 60,000 多个 GPU）以外，咱们不细目有些许东说念主会在分娩中为 GPU Max 编写代码。
来岁推出的 Falcon Shores 可能会更动这一近况，它将给与 GPU 架构，并搭载一些近似 Gaudi 的策画元素。据推断，该部件还将复古 OneAPI。
绕过护城河
天然 CUDA 护城河关于开导商和芯片制造商来说仍然是一个执续的挑战，但要是您只念念大限制提供 LLM，那么这并不是您信得过需要挂牵的事情。
岂论您遴荐什么硬件——英特尔、AMD、Cerebras、SambaNova、高通或其他公司，整个这些供应商齐开导了或孝敬了让 LLM 产生令牌所需的必要代码。
简直每个东说念主齐有一个框架，用于简化在其硬件上部署聊天机器东说念主式应用门径（如检索增强生成 (RAG)）。
然而，在某些情况下，提供与 OpenAI 兼容的 API 劳动器的智商才是整个开导东说念主员信得过念念要的。目下的许多 AI 应用门径骨子上只是围绕 OpenAI、Anthropic 或 Mistral AI API 劳动器构建的包装器 - 这意味着代码始终无用平直与 GPU 或 AI 加快器交互。
这也意味着代码相对可移植。举例，不错使用 Anthropic 的 Claude 构建见识考证，然后出于安全或合规原因，一朝参加分娩，API 劳动器和密钥就不错换成 vLLM 或 TensorRT-LLM 的土产货实例。
尽管简直任何 AI 加快器齐不错提供 LLM，但这并不虞味着它的性能或成果粗略达到应有的水平。
在最近的 MLPerf 推理提交中，AMD 展示了其 MI300X 加快器，其性能可与 Nvidia 备受崇敬的 H100相比好意思。表面上，该部件更高的内存带宽和更快的浮点性能应该会给它带来更大的上风——但关于初度提交而言，这并非什么了不得的事情。
从当时起，咱们看到 ROCm 进行了屡次更新，旨在擢升流行模子运行器（包括 vLLM 和 SG-Lang）的性能，并有望开释额外的性能。
天然 Guadi3 尚未在 MLPerf 西宾或推理中初度亮相，但耐久以来，Gaudi2 是独一值得 Nvidia 说起的竞争部分。
关于许多开导东说念主员来说，不错说 Nvidia 的 CUDA 护城河并不像你念念象的那么深 - 但它比 AMD 或英特尔但愿的要深。
https://www.theregister.com/2024/12/17/nvidia_cuda_moat/
半导体杰作公众号保举
专注半导体范畴更多原创内容
温煦公共半导体产业动向与趋势
*免责声明：本文由作家原创。著述内容系作家个东说念主不雅点，半导体行业不雅察转载仅为了传达一种不同的不雅点，不代表半导体行业不雅察对该不雅点赞同或复古，要是有任何异议，接待联系半导体行业不雅察。
今天是《半导体行业不雅察》为您共享的第3980期内容，接待温煦。
『半导体第一垂直媒体』
及时 专科 原创 深度
公众号ID：icbank
心爱咱们的内容就点“在看”共享给小伙伴哦
