在最近的一場“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的護城河，需要的是軟硬件協同設計。

審核編輯：劉清