为什么 OpenCL 没能取代 CUDA？
原文：Chris Lattner，What about OpenCL and CUDA C++ alternatives?（Democratizing AI Compute, Part 5），Modular 官方博客，2025 年 3 月 5 日。
本文为内容整理与编译，非逐句直译；如需核对原文表述，请参阅文末链接。
GPU 并不是随 GenAI 才出现的新事物，试图用 C++ 打造可移植 GPU 编程模型（portable GPU programming model）的尝试也由来已久——OpenCL、SYCL、oneAPI 都曾被寄予厚望，被认为是最有可能撼动 CUDA 的方案。但对多数 AI 从业者而言，这几个名字相当陌生，原因很直接：它们没能在 AI 领域站稳脚跟。Lattner 在这篇文章里复盘了这段历史，试图从管理和产业结构层面，而不只是技术层面，找出症结所在。
OpenCL 的起点：一个苹果内部的战略选择
Lattner 本人是这段历史的亲历者。2008 年，他是苹果实现 OpenCL 的核心工程师之一，当时也是他正在构建的 Clang 编译器（compiler）第一次投入生产环境使用。OpenCL 上线后，苹果做出了一个关键决定：把它贡献给 Khronos Group，交由行业共同标准化，而不是继续闭门自用。
这个决定确实换来了广泛的产业采纳，尤其是在移动端和嵌入式设备上——今天的 Android GPU 计算栈、各类数字信号处理器（DSP）应用中依然能看到 OpenCL 的身影。与 CUDA 从一开始就绑定单一厂商不同，OpenCL 从设计之初就以异构计算（heterogeneous compute）为目标，希望统一覆盖 CPU、GPU 及其他加速器。SYCL、Vulkan、SPIR-V、oneAPI、WebCL 等后续项目，某种程度上都是这条路线的延伸。
但即便技术路线合理、生态覆盖广泛，OpenCL 始终没能成为 AI 计算的主导平台。
"合作竞争"与委员会速度
Lattner 把根源归结为一种典型的产业结构性矛盾——“合作竞争”（coopetition）：硬件厂商之间既要共同维护一个统一标准，又要在市场上互相厮杀。2008 年的苹果还是 PC 领域的小玩家，标准化路线本是它触达更多开发者的捷径。可标准一旦交给委员会，推进速度就变成了共识速度，对于想快速迭代、抢先亮出产品差异化功能（例如 C++ 模板支持）的苹果来说,这几乎是不可接受的。
更深层的问题在于博弈本身：厂商不愿意在委员会里提前公开自己正在研发的硬件特性，因为这等于给竞争对手递刀子。于是普遍的做法是把创新雪藏到硬件发布之后，等这些特性变得不再稀缺，才拿出来讨论——而在此之前，往往先做成自己的厂商专有扩展（vendor-specific extensions）。这种"貌合神离"的合作模式，最终让苹果彻底放弃了 OpenCL：转向自研的 Metal，从未把 OpenCL 引入 iOS，后来也在 macOS 上将其弃用。其他厂商虽然留了下来，但同样的结构性摩擦持续拖慢着 OpenCL 跟上 AI 与 GPU 前沿创新的步伐。
技术层面的碎片化
苹果把 OpenCL 贡献给 Khronos 时，交出去的只是一份技术规格（technical specification），而不是一份完整可用的参考实现（reference implementation）。编译器前端 Clang 部分开源，但缺少一个共享的运行时（runtime），每个厂商都得自己动手补完编译器、维护自己的分支（fork）。没有一份持续演进的共享参考实现，OpenCL 逐渐演变成一堆彼此不兼容的厂商分支和扩展的拼凑物，可移植性——它最初想解决的核心问题——反而被自己削弱了。
厂商为了保留差异化，倾向于把新特性藏进专有扩展里，扩展数量一路膨胀，进一步撕裂了 OpenCL 及其衍生标准的统一性。再加上兼容性和一致性测试（conformance tests）本身就存在缺陷，问题被进一步放大，同时它还继承了此前系列文章讨论过的所有"C++ 式"痛点。开发者需要的是稳定、维护良好的工具链，而 OpenCL 的碎片化、薄弱的一致性测试和参差不齐的厂商支持，让使用体验饱受诟病——曾有开发者调侃，用 OpenCL 的感觉"大概和抱仙人掌差不多舒服"。
AI 需求的演进把差距进一步拉大
当 OpenCL 还在委员会流程里挣扎时，AI 领域正在飞速演进——软件框架和硬件能力齐头并进。TensorFlow 与 PyTorch 的出现，标志着 AI 研究进入了由大厂资金和基础设施驱动的新阶段，这对 OpenCL 构成了实质性的挑战：它能跑通 GPU 计算，却缺乏训练和大规模推理所需的高层 AI 库与优化——没有针对矩阵乘法、Flash Attention、数据中心级训练的原生支持。
业界曾尝试把 TensorFlow 和 PyTorch 扩展到支持 OpenCL，需求非常明确，但很快就撞上了结构性的天花板：可移植到新硬件毫无意义，如果没法把硬件性能真正压榨出来。缺少表达硬件专属优化的手段，加上"合作竞争"持续侵蚀协作空间，进展陷入停滞。
一个标志性的例子是：OpenCL 至今都没有对张量核心（Tensor Cores）——现代 GPU 和 AI 加速器里负责高效矩阵乘法的专用硬件单元——提供标准化支持。这意味着用 OpenCL 通常要付出相对 CUDA 或其他厂商原生方案 5 到 10 倍的性能代价。对本就计算成本高昂的 GenAI 而言，5 到 10 倍的性能损失不是"不方便"，而是彻底出局。
NVIDIA 的协同战略
与 OpenCL 松散的委员会治理形成鲜明对比的，是 NVIDIA 高度集中、极具战略性的打法：深度参与 TensorFlow 和 PyTorch 高层库的协同设计（co-design），确保这些框架始终在 NVIDIA 硬件上跑出最佳性能。由于两大框架天然基于 CUDA 构建，NVIDIA 拿到了巨大的先发优势，并持续加码优化，让"开箱即用"的性能优势进一步扩大。
与此同时，NVIDIA 也维护了一份 OpenCL 实现——但刻意留了一手（例如不开放张量核心的使用），确保 CUDA 始终是不可替代的选项。随着 NVIDIA 在行业中的地位不断巩固，资源投入的天平持续向 CUDA 倾斜，OpenCL 的支持逐渐淡化，最终基本从这条赛道上消失，而 CUDA 巩固了自己不可撼动的行业标准地位。
从这些 C++ GPU 项目中能学到什么
Lattner 把这段历史沉淀为七条判断标准，认为一个真正能够统一行业的系统必须做到：
- 提供可用的参考实现，而不只是一份规格文档加"兼容性"测试——能落地、能规模化的实现，才应该定义什么叫兼容，而不是一纸 PDF。
- 由维护参考实现的团队拥有清晰的领导力和技术愿景。
- 在行业领先厂商的硬件上跑出顶尖性能，否则永远只是二流替代品，无法真正统一行业。
- 快速演进，因为 AI 研究和硬件创新都远未停滞。
- 赢得开发者的真实认可：良好的可用性、工具链和编译速度缺一不可——况且"像 C++"在 AI 领域从来都不是卖点。
- 构建开放社区，因为再强的技术如果没有广泛采纳也没有意义。
- 避免碎片化：一旦标准分裂成互不兼容的分支，就无法再充当软件开发者的统一层。
基于这些标准，Lattner 认为委员会驱动的项目（如 OpenCL）很难真正成功，他对 Intel 主导的 oneAPI（现已并入 UXL Foundation）也持保留态度——名义上开放，实质上仍由单一硬件厂商主导，与其竞争对手同台博弈的格局并未改变。
系列预告
即便抛开"用什么语言写 GPU 代码"的问题，AI 行业还面临一个更根本的挑战：即便有了 CUDA，靠人工手写和调优代码也无法覆盖爆炸式增长的芯片种类、算法组合与工作负载排列。系列下一篇将转向 TVM、OpenXLA、MLIR 这类 AI 编译器（AI compiler）栈，复盘它们各自的得失——而其中的经验教训，与本文的结论相去不远。
原文链接：modular.com/blog/democratizing-ai-compute-part-5-what-about-cuda-c-alternatives