OpenCL 和 CUDA C++ 的替代方案如何？

# 关于 OpenCL 和 CUDA C++ 替代方案？（AI 算力民主化，第五部分） 来源：https://www.modular.com/blog/democratizing-ai-compute-part-5-what-about-cuda-c-alternatives **GenAI 或许是新事物，但 GPU 不是！**多年来，许多人尝试用 C++ 创建可移植的 GPU 编程模型，从 OpenCL 到 SYCL，再到 OneAPI 等等。这些是看起来最合理的 CUDA 替代方案，旨在实现 AI 算力民主化，但你可能从未听说过它们——因为它们未能对 AI 产生实质影响。 这些项目都为计算领域做出了有意义的贡献，但如果我们真正想要解锁未来的 AI 算力，就必须批判性地审视那些阻碍它们发展的错误——而不是只庆祝成功。概括来说，问题源于“开放竞合”（https://en.wikipedia.org/wiki/Open_coopetition）的挑战——行业参与者既合作又竞争——以及过程中具体的决策失误。 让我们深入探讨。🚀 ## CUDA C++ 替代方案：OpenCL、SYCL 等 有许多项目旨在解锁 GPU 编程，但我最了解的是 **OpenCL**（https://en.wikipedia.org/wiki/OpenCL）。和 CUDA 一样，OpenCL 的目标是为程序员提供类似 C++ 的体验，以便编写在 GPU 上运行的代码。这段历史对我来说很有个人意义：2008 年，我是 Apple 实现 OpenCL 的首席工程师之一（这是我正在构建的 Clang 编译器（https://en.wikipedia.org/wiki/Clang）的第一个生产用途）。在我们发布它之后（https://en.wikipedia.org/wiki/OpenCL#History），我们做出了一个关键决定：将其贡献给 Khronos Group（https://www.khronos.org/opencl/），以便在整个行业中被采纳和标准化。 这一决定带来了 OpenCL 在行业中的广泛采用（参见其标志（https://www.khronos.org/opencl/）），尤其是在移动和嵌入式设备中。时至今日，它在 Android 等平台上驱动 GPU 计算，并在 DSP 等专用应用中取得了巨大成功。与 CUDA 不同，OpenCL 从一开始就设计为可移植，旨在支持跨 CPU、GPU 和其他加速器的异构计算。OpenCL 还启发了其他系统，如 SyCL、Vulkan、SPIR-V、oneAPI、WebCL 等等。 然而，尽管 OpenCL 拥有技术优势和广泛采用，**它从未成为主导的 AI 计算平台**（https://github.com/tensorflow/tensorflow/issues/22#issuecomment-155145957）。主要原因有几个：开放竞合的内在张力、由此引发的技术问题、AI 不断演进的需求，以及 NVIDIA 与 TensorFlow 和 PyTorch 的统一战略。 ### **“竞合”（https://en.wikipedia.org/wiki/Open_coopetition）在委员会速度下运行** 2008 年，Apple 在 PC 领域还是个较小的玩家，认为行业标准化能帮助它接触到更多开发者。然而，尽管 OpenCL 在硬件制造商中获得广泛采纳，它的演进很快遇到了一个主要障碍：委员会驱动开发的速度。对于 Apple 来说，这种缓慢、共识驱动的流程是不可接受的：我们想快速推进平台、添加新功能（例如添加 C++ 模板），并体现 Apple 平台的差异化。我们面临一个赤裸的现实——委员会标准化的弊端在于，事情突然以委员会共识的速度推进……那速度慢得像冰川移动。 硬件供应商认识到统一软件生态系统的长期好处，但在短期内，它们是激烈的竞争对手。这导致了微妙但严重的问题：参与者不会向委员会透露正在开发的硬件特性（以免给竞争对手先机），而是将创新保密到硬件出货之后，只在这些特性成为商品化后才讨论（通过使用厂商特定的扩展）。 竞合：竞争对手之间的“合作”这对 Apple 来说成了一个巨大的问题，这家公司希望在保密中快速行动，以便在产品发布时引起轰动。因此，Apple 决定放弃 OpenCL：它推出了 Metal，从未将 OpenCL 带入 iOS，并最终在 macOS 中弃用了它。其他公司继续使用 OpenCL，但这些结构性挑战持续限制了它跟上尖端 AI 和 GPU 创新的能力。 ### **OpenCL 的技术问题** 尽管 Apple 大胆决定将 OpenCL 标准贡献给 Kronos，但它并没有全情投入：它贡献了 OpenCL 技术规范——但没有完整的参考实现。虽然编译器前端（Clang）的部分代码是开源的，但没有共享的 OpenCL 运行时，这迫使各供应商开发自己的定制分支并完成编译器。每个供应商必须维护自己的实现（一个“分支”），由于缺乏共享且不断演进的参考实现，OpenCL 变成了由各供应商分支和扩展拼凑起来的补丁。这种碎片化最终削弱了它的可移植性——而这正是它本应实现的目标。 此外，由于供应商隐瞒了差异化特性，或将其隔离到供应商特定的扩展中，这些扩展数量激增，分裂了 OpenCL（及其衍生品），侵蚀了它作为统一、供应商无关平台的能力。这些问题因 OpenCL 兼容性和一致性测试的弱点而加剧。除此之外，它还继承了所有我们之前讨论过的“C++ 问题”（https://www.modular.com/blog/democratizing-ai-compute-part-4-cuda-is-the-incumbent-but-is-it-any-good/#pythoncuda）。 开发者需要稳定、支持良好的工具——但 OpenCL 的碎片化、弱一致性测试和不一致的供应商支持使其成为令人沮丧的体验。一位开发者总结道，**使用 OpenCL “就像拥抱仙人掌一样舒服”**（https://futhark-lang.org/blog/2024-07-17-opencl-cuda-hip.html#:~:text=it%20is%20because%20OpenCL%20has,comfortable%20as%20hugging%20a%20cactus）！哎哟。 一位开发者将使用 OpenCL 描述为“就像拥抱仙人掌一样舒服”。（https://futhark-lang.org/blog/2024-07-17-opencl-cuda-hip.html#:~:text=it%20is%20because%20OpenCL%20has,comfortable%20as%20hugging%20a%20cactus）当 OpenCL 在碎片化和委员会驱动的缓慢演进中挣扎时，AI 正在快速进步——无论是在软件框架还是硬件能力方面。这进一步拉大了 OpenCL 提供的功能与现代 AI 工作负载所需功能之间的差距。 ## AI 研究与 AI GPU 硬件的不断演进的需求 TensorFlow 和 PyTorch 的推出引发了一场 AI 研究革命——这得益于基础设施的改进和大公司资金的涌入。这给 OpenCL 带来了重大挑战。虽然它支持 GPU 计算，但缺乏大规模训练和推理所必需的高级 AI 库和优化。与 CUDA 不同，它没有对矩阵乘法、Flash Attention 或数据中心级训练等关键操作的内置支持。 跨行业将 TensorFlow 和 PyTorch（https://github.com/pytorch/pytorch/issues/488）扩展到使用 OpenCL 的努力很快遇到了根本性障碍（尽管这很明显，且需求巨大（https://github.com/tensorflow/tensorflow/issues/22））。那些继续“拥抱仙人掌”的开发者很快发现了一个残酷的现实：如果你无法解锁新硬件的全部性能，那么可移植性就毫无意义。由于无法表达可移植的硬件特定增强，加上竞合压制了协作，进展停滞不前。 一个明显的例子？OpenCL **仍然**没有为 Tensor Cores（https://www.modular.com/blog/democratizing-ai-compute-part-4-cuda-is-the-incumbent-but-is-it-any-good/#tensorcores）提供标准化支持——这些是专用硬件单元，为现代 GPU 和 AI 加速器中的高效矩阵乘法提供动力。这意味着使用 OpenCL 通常会导致性能比使用 CUDA 或其他碎片化的供应商原生软件慢 5 到 10 倍。对于计算成本已经非常高昂的 GenAI 来说，**5 到 10 倍的减速不仅仅是麻烦——而是彻底的失败**。 ### **NVIDIA 与 TensorFlow 和 PyTorch 的战略方法** 当 OpenCL 在碎片化治理的重压下挣扎时，NVIDIA 采取了截然不同的方法——这种方法严格控制、高度战略化且极其有效，正如我们之前讨论过的（https://www.modular.com/blog/democratizing-ai-compute-part-3-how-did-cuda-succeed）。它积极与 TensorFlow 和 PyTorch 共同设计 CUDA 的高级库，确保它们在 NVIDIA 硬件上始终运行最佳。由于这些框架原生构建于 CUDA 之上，NVIDIA 获得了巨大的先发优势——并通过开箱即用的性能优化进一步巩固了这一优势。 NVIDIA 维护了一个象征性的 OpenCL 实现——但它在战略上被削弱了（例如，不能使用 TensorCores）——从而确保 CUDA 实现始终是必要的。NVIDIA 在行业中持续且日益增长的统治地位使其走上了确保 CUDA 实现获得最大投资的道路。随着时间的推移，OpenCL 的支持逐渐减弱，然后消失——而 CUDA 则巩固了其作为无可争议标准的地位。 ## 我们可以从这些 C++ GPU 项目中学到什么？ 对于那些经历过这一切的人来说，上述历史是众所周知的，但真正的价值在于从过去中学习。基于此，我相信成功的系统必须： - 提供**一个参考实现**，而不仅仅是论文规格和“兼容性”测试。一个可工作、可采纳且可扩展的实现应该定义兼容性——而不是一份 PDF 文档。 - 有**强大的领导和愿景**，由维护参考实现的人驱动。 - 在**行业领先的硬件上以顶级性能运行**——否则，它将永远只是一个二流的替代品，而不是能够统一行业的东西。 - **快速演进**以满足不断变化的需求，因为 AI 研究并非停滞不前，AI 硬件创新仍在加速。 - **培养开发者的喜爱**，通过提供良好的可用性、工具和快速编译时间。另外，在 AI 领域，“类似 C++”并不是一个卖点！ - **构建开放社区**，因为没有广泛采用，技术能力就无关紧要。 - **避免碎片化**——一个分裂成不兼容分支的标准无法为软件开发人员提供有效的统一层。 这些是根本原因，让我不相信像 OpenCL 这样的委员会努力能够成功。这也是为什么我对像 Intel 的 OneAPI（https://oneapi.io/）（现在是 UXL Foundation（https://uxlfoundation.org/））这样的项目更加怀疑——这些项目**名义上**开放，但实际上由一家与其他所有厂商竞争的硬件供应商控制。 ## 那 AI 编译器呢？ 在 C++ 方法未能为硬件制造商统一 AI 计算的同时，AI 行业面临着一个更大的挑战——即使在 NVIDIA 硬件上使用 CUDA 也是如此。如果人类必须手动编写所有代码，我们如何扩展 AI 计算？有太多的芯片、太多的 AI 算法和太多的工作负载组合需要手工优化。 随着 AI 的主导地位日益增强，它不可避免地引起了系统开发人员和编译器工程师的兴趣——包括我自己。在下一篇文章中，我们将深入探讨广为人知的“AI 编译器”栈，如 TVM、OpenXLA 和 MLIR——分析哪些有效、哪些无效，以及我们可以从中汲取哪些教训。不幸的是，这些教训与上述内容并无太大不同： > 历史不会重演，但总会有惊人的相似。— 马克·吐温 下次见——在此之前，愿浮点运算力与你同在！👨💻 - Chris ## 下一步是什么？ 了解更多关于 MAX 平台和 Mojo 编程语言的信息，并加入我们，共同构建下一波 AI 创新。 - **开始使用 MAX**（https://docs.modular.com/max/get-started）——探索我们最新的平台，加速您的 AI 工作。 - 查看 **Mojo 手册**（https://docs.modular.com/mojo/manual/）并开始使用我们用于 GPU 编程的下一代语言。 - 在 Modular 论坛（https://forum.modular.com/t/democratizing-ai-compute-part-5-what-about-cuda-c-alternatives/674）上分享您对这篇文章的看法以及向 Chris 提出的问题。Chris 将在下一次社区会议（https://modul.ar/community-meeting-doc）上回答关于本系列的问题，会议时间为 3 月 10 日星期一。