谁能挑战英伟达 CUDA?

Wallstreetcn
2023.12.21 01:58
portai
I'm PortAI, I can summarize articles.

在最近的一场 “AI Everywhere” 发布会上,Intel 的 CEO Pat Gelsinger 批评了 Nvidia 的 CUDA 生态系统,并表示整个行业都希望能够挑战 CUDA。尽管 CUDA 为人工智能算法的训练和部署提供了便利,但行业对其过度依赖产生了警惕性。一些公司如 Google 和 OpenAI 正在研发自己的解决方案。本文将深入分析 CUDA 的强势来源以及谁能够打破其垄断。

在最近的一场 “AI Everywhere” 发布会上,Intel 的 CEO Pat Gelsinger 炮轰 Nvidia 的 CUDA 生态护城河并不深,而且已经成为行业的众矢之的。Gelsinger 称,“整个行业都希望能干掉 CUDA,包括 Google、OpenAI 等公司都在想方设法让人工智能训练更加开放。我们认为 CUDA 的护城河既浅又窄。”

Gelsinger 的这番话确实道出了整个人工智能行业对于 Nvidia 的 CUDA 又爱又恨的情绪;一方面,由于有了 CUDA 生态,人工智能算法的训练和部署从硬件层角度变得容易,人工智能工程师无需成为芯片专家,也能够让人工智能训练高效地运行在 Nvidia 的 GPU 上。而从另一个角度,整个业界也过于依赖 CUDA,以至于不少主打人工智能公司都对于 CUDA 的过度依赖产生了警惕性,这也就是 Gelsinger 所说的 Google、OpenAI 等公司都在设法研制自己的相应解决方案(例如 OpenAI 的 Triton)。本文将深入分析 CUDA 的强势到底来源于哪里,以及究竟谁能打破 CUDA 垄断。

什么是 CUDA?

首先,我们先分析一下 CUDA 的来龙去脉。当我们在谈论 “CUDA” 的时候,我们究竟在谈论什么?事实上,我们认为,CUDA 包含三个层次。

首先,CUDA 是一套编程语言。最初,3D 图像加速卡的主要任务是加速 3D 图像的渲染,其用途相当专一。在本世纪初,Nvidia 推出了 GPU 的概念以允许用户使用图像加速卡去做通用计算,并且在大约十五年前推出了相应的 CUDA 编程语言,其主要任务是提供 GPU 的编程模型,从而实现通用 GPU 编程。在 CUDA 编程语言中,Nvidia 提供了 GPU 的各种硬件抽象,例如基于线程的并行计算、内存存取等概念,从而为 GPU 编程提供了方便。

除了编程语言之外,CUDA 的第二层含义是一套高性能编译系统。在使用 CUDA 编程之后,还需要把用 CUDA 语言编写的程序使用 CUDA 编译器针对相应硬件优化并且映射到更底层的硬件指令(对于 Nvidia 显卡来说就是 PTX)。CUDA 的编译器和 GPU 硬件的整合效率相当高,因此能编译出非常高效的底层指令,这也是 CUDA 的另一个核心组成部分。

最后,CUDA 的第三层是含义是 Nvidia 基于 CUDA 语言的一系列高性能函数库,以及人工智能/高性能计算社区基于 CUDA 语言开发的一系列代码库。例如,CUDA 的常用高性能函数库包括用于线性计算的 cuBLAS 和 CUTLASS,用于稀疏矩阵计算的 cuSPARSE,用于傅立叶变幻的 cuFFT,用于数值求解的 cuSOLVER 等。这些函数库的发展至今已经历经了十余年的努力,其优化几乎已经做到了极致。另外,人工智能社区也有大量基于 CUDA 开发的代码库,例如 Pytorch 的默认后端就是 CUDA。

CUDA 每个层面的护城河

如上分析可知,CUDA 其实包含了三个层面:编程语言,编译器和生态。那么,CUDA 这三个层面的护城河究竟在有多高?

首先,从编程语言的角度,事实上一直有 OpenCL 等社区开源语言试图去实现类似(甚至更加广泛的功能;OpenCL 针对的不只是 GPU 编程,还包括了 FPGA 等异构计算体系)的功能,AMD 的 ROCm 平台也是试图做到与 CUDA 语言等价。从编程语言角度,CUDA 并非不可取代。

其次,从编译器的角度来看,CUDA 提供的高性能编译器确实是一个很高的护城河。编译器的性能从很大程度上决定了用户编写的程序在 GPU 上执行的效率;或者换句话说,对于人工智能应用来说,一个很直观的衡量标准就是用户编写的人工智能算法,能多大程度上利用 GPU 的峰值算力?大多数情况下,峰值算力平均利用率不到 50%。另外,编译器的性能还牵扯到了用户调优的过程。如果用户是 GPU 专家,通过在编写 GPU 程序时进行调优(例如使用某种特定的方式去编写语句),也可以很大程度上弥补编译器的不足(因为编译器的一个重要功能就是对编写的程序做优化,那么如果编写的程序已经比较优化了那么对编译器优化能力的要求就可以低一些)。但是,这就牵扯到了用户的门槛,如果编译器性能不够好,需要用户是专家才能实现高效率的 GPU 程序,就会大大提高用户门槛,即只有拥有一支精英 GPU 编程专家团队的公司才能充分发挥出 GPU 的性能;相反如果编译器性能够好,那么就可以降低用户门槛,让更多公司和个人也可以使用 GPU 高性能运行算法。从这个角度来说,经过十多年的积累,CUDA 的编译器(NVCC)已经达到了相当高的水平。最近的另一个新闻也从侧面印证了编译器性能的重要性:AMD 在 12 月初的发布会上宣布新的 MI300X 平台在运行 Llama2-70B 模型的推理任务时,比起 Nvidia H100 HGX 的性能要强 1.4 倍;一周后,Nvidia 回应称 AMD 在编译测试时并没有使用合理的设置,在使用正确设置后 H100 HGX 的性能事实上比 MI300X 要强 1.5 倍。由此可见,一个好的编译器优化对于充分利用 GPU 的性能可以说是至关重要。

然而,编译器的护城河也并不是高不可破。例如,OpenAI 的开源 Triton 编译器可以同时兼容 Nvidia 和 AMD 以及更多平台,支持把用户使用 Python 编写的程序直接优化编译到底层硬件指令语言,并且在 Nvidia 的成熟 GPU 上实现和 CUDA 接近的执行效率。如果 Triton 这样的开源编译器获得成功的话,至少从某种角度上可以省去其他人工智能芯片公司花数年精力去开发自己的编译器的需求。

第三个层面是生态。目前,CUDA 在生态领域可以说是遥遥领先,因为 CUDA 有着十多年的高性能程序库的积累,以及基于这些程序库上面社区开发的各种高性能框架代码。生态的积累首先需要能提供一个领先的解决方案——如果其他公司也能提供一个高性能的编程语言和编译器方案的话,自然会有社区去基于它开发代码,而经过长期不懈的积累之后,生态自然也会赶上。例如,人工智能领域最流行的框架 PyTorch 从这两年开始也对于 AMD 的 ROCm 提供了支持,这就是生态领域的一个例子。换句话说,只要给足够的时间和与 CUDA 语言/编译器性能接近的方案,生态自然会慢慢赶上。

谁能打破 CUDA 的护城河

之前我们分析了 CUDA 从三个层面的护城河,我们可以发现,Nvidia 的 CUDA 从三个层面分别来看,编译器和生态的护城河比较高,但也不是不可超越。我们看到,软件科技公司之间正在试图超越这条护城河,例如 OpenAI 的 Triton 编译器能提供几乎比肩 CUDA 的性能,而人工智能编程框架 PyTorch 的最新版本已经在后端集成了 Triton,可望在 Nvidia 已经推出的成熟 GPU 上能实现很高的性能。

然而,Nvidia CUDA 最强的护城河事实上在于软件 - 芯片协同设计。如前所述,在 Nvidia 的 GPU 推出一段时间之后(例如半年或一年),第三方的软件公司的方案(例如 OpenAI 的 Triton)在研究透彻这款 GPU 之后,可以让自己的方案做到比肩 CUDA 的水平。这意味着两点:

首先,第三方软件公司开发编译器去尝试匹配 CUDA 的性能永远是一个追赶的过程,Nvidia 发布新的 GPU 和相应 CUDA 版本之后,需要半年到一年的时间才能实现性能基本匹配,但是基本难以到达 Nvidia 新 GPU 发布就立刻实现性能匹配甚至领先。

其次,芯片公司如果被动等待第三方软件公司的编译器去适配自己的人工智能加速硬件以追赶 Nvidia 的话,永远无法打破 Nvidia CUDA 的领先地位。原因是,第三方软件公司适配新的人工智能加速硬件需要时间;而在一年后等到第三方软件公司的方案达到接近 CUDA 的水平的时候,Nvidia 已经发布下一代 GPU 了。这就陷入了永远在追赶过程中的陷阱,难以打破 CUDA 护城河并实现领先。

因此,能真正打破 CUDA 护城河的,必须是有芯片 - 软件协同设计能力的团队,而不仅仅是一个软件公司。这个团队可以是一家拥有强大软件能力的芯片公司(例如,Nvidia 就是这样的一个拥有强大芯片 - 软件协同设计能得芯片公司的例子),或者是芯片和科技公司的结合。只有在芯片设计过程中就开始编译器和软件生态的适配,才能够在芯片发布的初期就能推出芯片性能和软件性能同时都比肩 Nvidia GPU +CUDA 的产品,从而真正打破 CUDA 的护城河。

如何在芯片设计过程中就实现软硬件协同设计?事实上,编译器的设计是基于一种编程模型,把硬件抽象为一些不同的层次(例如内部并行计算,内存存取等等),并且进一步根据这些硬件抽象去构建性能模型,来实现性能的预测和优化。从芯片设计的角度,需要能充分理解编译器层面的这些硬件抽象和性能模型并不会百分百准确,因此如何设计一个好的芯片架构让编译器能够较为容易地去优化程序就很重要。而从编译器的角度,如前所述每一款芯片的编程模型和硬件抽象层都会略有不同,因此需要在芯片设计周期中就介入开始编译器的优化和硬件建模。两者相结合,就能实现在芯片推出时就同时有很强的芯片理论性能和高度优化的编程语言/编译器,最终实现整体解决方案能和 Nvidia 的 GPU+CUDA 做有力的竞争。

从这个角度来看,Google 的 TPU+XLA 就是一个满足之前所属芯片 - 软件协同设计的案例。Google 的自研 TPU 过程中和 XLA 编译器通过软硬件结合设计实现整体高性能方案(这也是 TPU 在 MLPerf benchmark 上和 Nvidia 的方案性能接近甚至领先的重要原因)。虽然 TPU 并不对第三方销售因此这个方案并不会完全打破 Nvidia CUDA 的护城河,但是它至少提供了一个打破 Nvidia CUDA 护城河的技术方向。从另一个方面,AMD 和 Intel 等芯片公司在编译器领域的方案目前还有待加强,但是通过和 OpenAI 等科技公司合作,通过在下一代 AI 产品的设计过程中就和 Triton 这样的领先编译器方案协同设计,可望能在未来追赶 Nvidia GPU + CUDA 的性能;而在性能接近之后,生态的培养就只是一个时间问题了。

综上,我们认为,CUDA 虽然是一个软件生态,但是如果想要打破 CUDA 的护城河,需要的是软硬件协同设计。

风险提示及免责条款

市场有风险,投资需谨慎。本文不构成个人投资建议,也未考虑到个别用户特殊的投资目标、财务状况或需要。用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。