如何打破CUDA壟斷？LLVM奠基人長文解讀

👆如果您希望可以時常見面，歡迎標星🌟收藏哦~

編者按：

多年來，領先的人工智慧公司一直堅稱，只有擁有龐大計算資源的公司才能推動前沿研究，這強化了這樣一種觀點：除非你擁有數十億美元的基礎設施投入，否則“不可能趕上”。但 DeepSeek 的成功卻講述了一個不同的故事：新穎的理念可以帶來效率上的突破，從而加速人工智慧的發展；規模更小但更專注的團隊可以挑戰行業巨頭，甚至創造公平的競爭環境。

我們認為，DeepSeek 的效率突破預示著AI 應用需求的激增。如果 AI 要繼續發展，就必須降低總體擁有成本 (TCO) ——透過擴大替代硬體的覆蓋範圍、最大限度地提高現有系統的效率以及加速軟體創新。否則，未來 AI 的效益將面臨瓶頸——要麼是硬體短缺，要麼是開發者難以有效利用現有的各種硬體。

這不僅僅是一個抽象的問題——這是我（指代本文作者Chris Lattner，下同）整個職業生涯都在努力解決的一個挑戰。

過去 25 年來，我一直致力於為世界釋放計算能力。我創立並領導了LLVM的開發，LLVM 是一項編譯器技術，它為 CPU 在編譯器技術的新應用領域打開了大門。如今，LLVM 已成為 C++、Rust、Swift 等效能導向型程式語言的基礎。它支援幾乎所有 iOS 和 Android 應用，以及 Google 和 Meta 等主要網際網路服務的基礎設施。

這項工作為我在蘋果領導的幾項關鍵創新鋪平了道路，包括建立OpenCL（一個早期的加速器框架，現已被整個行業廣泛採用）、使用LLVM重建蘋果的CPU和GPU軟體堆疊，以及開發Swift程式語言。這些經歷強化了我對共享基礎設施的力量、軟硬體協同設計的重要性，以及直觀、開發者友好的工具如何釋放先進硬體的全部潛力的信念。

2017 年，我開始著迷於 AI 的潛力，並加入 Google，領導 TPU 平臺的軟體開發。當時，硬體已經準備就緒，但軟體尚未投入使用。在接下來的兩年半時間裡，透過團隊的共同努力，我們在 Google Cloud 上推出了 TPU，並將其擴充套件到每秒百億億次浮點運算 (ExaFLOPS)，並構建了一個研究平臺，促成了Attention Is All You Need和BERT等突破性成果。

然而，這段旅程也揭示了人工智慧軟體更深層次的問題。儘管 TPU 取得了成功，但它們仍然僅與 PyTorch 等人工智慧框架半相容——谷歌憑藉巨大的經濟和研究資源克服了這個問題。一個常見的客戶問題是：“TPU 能開箱即用地執行任意人工智慧模型嗎？”真相是？不能——因為我們沒有 CUDA，而 CUDA 是人工智慧開發的事實標準。

我並非迴避解決行業重大問題的人：我最近的工作是建立下一代技術，以適應硬體和加速器的新時代。這包括 MLIR 編譯器框架（目前已被整個行業廣泛採用的 AI 編譯器），以及我們團隊在過去 3 年中構建的一些特別的東西——但我們稍後會在合適的時機分享更多相關資訊。

由於我的背景和在業界的人脈，我經常被問及計算的未來。如今，無數團隊正在硬體領域進行創新（部分原因是NVIDIA 市值飆升），而許多軟體團隊正在採用 MLIR 來支援新的架構。與此同時，高層領導們也在質疑，為什麼儘管投入了大量資金，AI 軟體問題仍然懸而未決。挑戰並非缺乏動力或資源。那麼，為什麼這個行業會感到停滯不前呢？

我不認為我們陷入了困境。但我們確實面臨著一些棘手的基礎性問題。

為了向前發展，我們需要更好地理解行業底層動態。計算是一個技術含量極高的領域，發展迅速，充斥著各種術語、代號和新聞稿，旨在讓每一款新產品都聽起來具有革命性。許多人試圖撥開迷霧，只見樹木不見森林，但要真正理解我們的發展方向，我們需要探究其根源——那些將一切聯絡在一起的基本構件。

首先，我們將以一種簡單易懂的方式回答這些關鍵問題：

CUDA 到底是什麼？
CUDA 為何如此成功
️CUDA 真的好嗎？
為什麼其他硬體製造商難以提供可比的 AI 軟體？
為什麼 Triton、OneAPI 或 OpenCL 等現有技術還沒有解決這個問題？
作為一個行業，我們該如何向前發展？

我希望本文能夠激發有意義的討論，並提升人們對這些複雜問題的理解。人工智慧的快速發展——例如 DeepSeek 最近的突破——提醒我們，軟體和演算法創新仍然是推動行業發展的動力。對底層硬體的深入理解繼續帶來 “10 倍” 的突破。

人工智慧正以前所未有的速度發展，但仍有諸多潛力有待挖掘。讓我們攜手突破，挑戰固有認知，推動行業發展。讓我們一起深入探索！

“CUDA”究竟是什麼？

似乎在過去一年裡，每個人都開始談論 CUDA：它是深度學習的支柱，是新型硬體難以與之競爭的原因，也是英偉達護城河與市值飆升的核心。

DeepSeek 的出現讓我們有了驚人的發現：它的突破是透過 “繞過” CUDA、直接進入 PTX 層實現的…… 但這究竟意味著什麼呢？似乎每個人都想打破這種技術鎖定，但在制定計劃之前，我們必須先了解自己面臨的挑戰。

CUDA 在人工智慧領域的主導地位不可否認，但大多數人並不完全理解 CUDA 究竟是什麼。有人認為它是一種程式語言，有人稱它是一個框架。許多人認為它只是 “英偉達用來讓 GPU 執行更快的東西”。這些說法並非完全錯誤，也有很多傑出人士試圖解釋它，但沒有一種能完全涵蓋 “CUDA 平臺” 的全貌。

CUDA 並非單一事物，它是一個龐大的分層平臺，是一系列技術、軟體庫和底層最佳化的集合，共同構成了一個大規模的平行計算生態系統。它包括：

一種底層並行程式設計模型，開發者可以用類似 C++ 的語法利用 GPU 的原始計算能力。
一套複雜的庫和框架，這些中介軟體支援人工智慧等關鍵垂直應用場景（例如用於 PyTorch 和 TensorFlow 的 cuDNN 庫）。
像 TensorRT-LLM 和 Triton 這樣的高階解決方案，它們能在不需要開發者深入瞭解 CUDA 的情況下，支援人工智慧工作負載（例如大語言模型服務）。

而這只是冰山一角。

在本章節中，我們將深入剖析 CUDA 平臺的關鍵層級，探究其發展歷程，並解釋它為何對如今的人工智慧計算如此重要。這為我們系列文章的下一部分內容奠定了基礎，屆時我們將深入探討 CUDA 如此成功的原因。提示：這與其說是技術本身的原因，不如說和市場激勵因素有很大關係。

讓我們開始吧！

CUDA 發展之路：從圖形處理到通用計算

在 GPU 成為人工智慧和科學計算的強大引擎之前，它們只是圖形處理器，是專門用於渲染影像的處理器。早期的 GPU 將影像渲染功能硬編碼在矽晶片中，這意味著渲染的每個步驟（變換、光照、光柵化）都是固定的。雖然這些晶片在圖形處理方面效率很高，但缺乏靈活性，無法用於其他型別的計算。

2001 年，英偉達推出 GeForce3，這一切發生了改變。GeForce3 是第一款帶有可程式設計著色器的 GPU，這在計算領域是一次重大變革：

在此之前：固定功能的 GPU 只能應用預定義的效果。
在此之後：開發者可以編寫自己的著色器程式，解鎖了可程式設計圖形管線。

這一進步伴隨著 Shader Model 1.0 的推出，開發者可以編寫在 GPU 上執行的小程式，用於頂點和畫素處理。英偉達預見到了未來的發展方向：GPU 不僅可以提升圖形效能，還能成為可程式設計的平行計算引擎。

與此同時，研究人員很快就提出了疑問：“如果 GPU 能執行用於圖形處理的小程式，那我們能否將其用於非圖形任務呢？”

斯坦福大學的 BrookGPU 專案是早期對此進行的重要嘗試之一。Brook 引入了一種程式設計模型，使 CPU 能夠將計算任務解除安裝到 GPU 上，這一關鍵理念為 CUDA 的誕生奠定了基礎。

這一舉措具有戰略意義且極具變革性。英偉達沒有把計算當作一項附帶實驗，而是將其列為首要任務，將 CUDA 深度融入其硬體、軟體和開發者生態系統中。

CUDA 並行程式設計模型

2006 年，英偉達推出 CUDA（統一計算裝置架構），這是首個面向 GPU 的通用程式設計平臺。CUDA 程式設計模型由兩部分組成：“CUDA 程式語言” 和 “英偉達驅動程式”。

CUDA 是一個分層堆疊，需要從驅動程式到核心的深度整合

CUDA 語言源自 C++，並進行了擴充套件，以直接暴露 GPU 的底層特性，例如 “GPU 執行緒” 和記憶體等概念。程式設計師可以使用該語言定義 “CUDA 核心”，這是一種在 GPU 上執行的獨立計算任務。下面是一個非常簡單的示例：

CUDA 核心允許程式設計師定義自定義計算，這些計算可以訪問本地資源（如記憶體），並將 GPU 用作高速平行計算單元。這種語言會被翻譯成 “PTX”，PTX 是一種組合語言，是英偉達 GPU 支援的最低階介面。

但是程式究竟如何在 GPU 上執行程式碼呢？這就要用到英偉達驅動程式了。它充當 CPU 和 GPU 之間的橋樑，負責處理記憶體分配、資料傳輸和核心執行。以下是一個簡單示例：

請注意，這些操作都非常底層，充滿了繁雜的細節（如指標和 “幻數（magic numbers）”）。如果出現錯誤，通常會以難以理解的程式崩潰形式提示。此外，CUDA 還暴露了許多英偉達硬體特有的細節，例如 “warp 中的執行緒數”（這裡暫不深入探討）。

儘管存在這些挑戰，但這些元件讓整整一代硬核程式設計師能夠利用 GPU 強大的計算能力來解決數值問題。例如，2012 年 AlexNET 點燃了現代深度學習的火種。它之所以能夠實現，得益於用於卷積、啟用、池化和歸一化等人工智慧操作的自定義 CUDA 核心，以及 GPU 提供的強大算力。

雖然大多數人聽到 “CUDA” 時，通常想到的是 CUDA 語言和驅動程式，但這遠不是 CUDA 的全部，它們只是其中的一部分。隨著時間的推移，CUDA 平臺不斷發展，涵蓋的內容越來越多，而最初的首字母縮寫詞（CUDA）已經無法準確描述其全部意義。

高階 CUDA 庫：讓 GPU 程式設計更易上手

CUDA 程式設計模型為通用 GPU 計算打開了大門，功能強大，但它帶來了兩個挑戰：

CUDA 使用難度較大。
更糟糕的是，CUDA 在效能可移植性方面表現不佳。

為第 N 代 GPU 編寫的大多數核心在第 N + 1 代 GPU 上仍能 “繼續執行”，但效能往往較差，遠達不到第 N + 1 代 GPU 的峰值效能，儘管 GPU 的優勢就在於高效能。這使得 CUDA 成為專業工程師的有力工具，但對大多數開發者來說，學習門檻較高。這也意味著每次新一代 GPU 推出時（例如現在新出現的 Blackwell 架構），都需要對程式碼進行大量重寫。

隨著英偉達的發展，它希望 GPU 對那些在各自領域是專家，但並非 GPU 專家的人也有用。英偉達解決這一問題的方法是開始構建豐富而複雜的閉源高階庫，這些庫抽象掉了 CUDA 的底層細節，其中包括：

cuDNN（2014 年推出）—— 加速深度學習（例如卷積、啟用函式運算）。
cuBLAS—— 最佳化的線性代數例程。
cuFFT—— 在 GPU 上進行快速傅立葉變換（FFT）。
以及許多其他庫。

有了這些庫，開發者無需編寫自定義 GPU 程式碼就能利用 CUDA 的強大功能，英偉達則承擔了為每一代硬體重寫這些庫的工作。這對英偉達來說是一項巨大的投資，但最終取得了成效。

cuDNN 庫在這一過程中尤為重要，它為谷歌的 TensorFlow（2015 年推出）和 Meta 的 PyTorch（2016 年推出）鋪平了道路，推動了深度學習框架的興起。雖然此前也有一些人工智慧框架，但這些是首批真正實現規模化應用的框架。現代人工智慧框架中包含數千個 CUDA 核心，每個核心都極難編寫。隨著人工智慧研究的爆發式增長，英偉達積極擴充套件這些庫，以涵蓋重要的新應用場景。

CUDA 上的 PyTorch 建立在多層依賴關係之上

英偉達對這些強大的 GPU 庫的投入，使得全球開發者能夠專注於構建像 PyTorch 這樣的高階人工智慧框架，以及像 HuggingFace 這樣的開發者生態系統。他們的下一步是打造開箱即用的完整解決方案，讓開發者完全無需瞭解 CUDA 程式設計模型。

全面的垂直解決方案助力AI和GenAI快速發展

人工智慧的熱潮遠遠超出了研究實驗室的範疇，如今它無處不在。從影像生成到聊天機器人，從科學發現到程式碼助手，生成式人工智慧（GenAI）在各個行業蓬勃發展，為該領域帶來了大量新應用和開發者。

與此同時，出現了一批新的人工智慧開發者，他們有著截然不同的需求。在早期，深度學習需要精通 CUDA、高效能計算（HPC）和底層 GPU 程式設計的專業工程師。如今，一種新型開發者（通常稱為人工智慧工程師）在構建和部署人工智慧模型時，無需接觸底層 GPU 程式碼。

為了滿足這一需求，英偉達不僅提供庫，還推出了交鑰匙解決方案，將底層的一切細節都抽象掉。這些框架無需開發者深入瞭解 CUDA，就能讓人工智慧開發者輕鬆最佳化和部署模型。

Triton Serving—— 一種高效能的人工智慧模型服務系統，使團隊能夠在多個 GPU 和 CPU 上高效執行推理。
TensorRT—— 一種深度學習推理最佳化器，可自動調整模型，使其在英偉達硬體上高效執行。
TensorRT-LLM—— 一種更專業的解決方案，專為大規模大語言模型（LLM）推理而構建。
以及許多（眾多）其他工具。

NVIDIA 驅動程式和 TensorRT-LLM 之間存在多個層

這些工具完全遮蔽了 CUDA 的底層複雜性，讓人工智慧工程師能夠專注於人工智慧模型和應用，而無需關注硬體細節。這些系統提供了強大的支援，推動了人工智慧應用的橫向擴充套件。

整體的 “CUDA 平臺”

CUDA 常被視為一種程式設計模型、一組庫，甚至僅僅是 “英偉達 GPU 執行人工智慧所依賴的東西”。但實際上，CUDA 遠不止如此。它是一個統一的品牌，是一個真正龐大的軟體集合，也是一個經過高度最佳化的生態系統，所有這些都與英偉達的硬體深度整合。因此，“CUDA” 這個術語含義模糊，我們更傾向於使用 “CUDA 平臺” 這一表述，以明確我們所談論的更像是 Java 生態系統，甚至是一個作業系統，而不僅僅是一種程式語言和執行時庫。

CUDA 的複雜性不斷擴大：涵蓋驅動程式、語言、庫和框架的多層生態系統

從核心來看，CUDA 平臺包括：

龐大的程式碼庫：經過數十年最佳化的 GPU 軟體，涵蓋從矩陣運算到人工智慧推理的所有領域。
廣泛的工具和庫生態系統：從用於深度學習的 cuDNN 庫到用於推理的 TensorRT，CUDA 涵蓋了大量的工作負載。
針對硬體最佳化的效能：每次 CUDA 釋出都會針對英偉達最新的 GPU 架構進行深度最佳化，確保實現頂級效率。
專有且不透明：當開發者與 CUDA 的庫 API 互動時，底層發生的很多操作都是閉源的，並且與英偉達的生態系統緊密相連。

CUDA 是一套強大且龐大的技術體系，是整個現代 GPU 計算的軟體平臺基礎，其應用甚至超越了人工智慧領域。

既然我們已經瞭解了 “CUDA” 是什麼，接下來就需要明白它為何如此成功。提示一下：CUDA 的成功並非真的取決於效能，而是戰略、生態系統和發展勢頭。在下一篇文章中，我們將探討是什麼讓英偉達的 CUDA 軟體塑造並鞏固了現代人工智慧時代。

CUDA 如何取得成功？

如果作為一個生態系統，我們希望取得進展，就需要了解 CUDA 軟體帝國是如何佔據主導地位的。理論上，存在一些替代方案，比如 AMD 的 ROCm、英特爾的 oneAPI、基於 SYCL 的框架等，但在實際應用中，CUDA 仍然是 GPU 計算領域無可爭議的王者。

這一切是如何發生的呢？

答案並不僅僅在於卓越的技術，儘管技術確實起到了一定作用。CUDA 是一個開發者平臺，它的成功得益於出色的執行、深入的戰略投資、連貫性、生態系統鎖定，當然，還有一點點運氣。

本章節將深入剖析 CUDA 如此成功的原因，探究英偉達的層層戰略 —— 從早期對通用平行計算的押注，到與 PyTorch 和 TensorFlow 等人工智慧框架的緊密結合。歸根結底，CUDA 的主導地位不僅是軟體的勝利，更是長期平臺思維的典範。

CUDA 的早期發展

構建一個計算平臺的關鍵挑戰之一，是吸引開發者學習並投入其中。如果只能針對小眾硬體，就很難形成發展勢頭。在一期精彩的《Acquired》播客節目中，黃仁勳分享了英偉達早期的一個關鍵戰略，即保持 GPU 的跨代相容性。這使得英偉達能夠利用其已廣泛普及的遊戲 GPU 使用者基礎，這些 GPU 最初是為執行基於 DirectX 的 PC 遊戲而銷售的。此外，開發者可以在低價的臺式電腦上學習 CUDA，之後再擴充套件到價格高昂、效能更強大的硬體上。

這在如今看來或許顯而易見，但在當時卻是一個大膽的舉措：英偉達沒有為不同的應用場景（筆記型電腦、桌上型電腦、物聯網、資料中心等）打造單獨最佳化的產品線，而是構建了一條連續統一的 GPU 產品線。這意味著要做出一些權衡，比如在功耗或成本效率方面有所犧牲，但作為回報，它建立了一個統一的生態系統，開發者在 CUDA 上的投入可以從遊戲 GPU 無縫擴充套件到高效能資料中心加速器。這種策略與蘋果維護和推動 iPhone 產品線發展的方式頗為相似。

這種方法有兩個好處：

降低准入門檻：開發者可以使用已有的 GPU 學習 CUDA，便於進行實驗和採用。
產生網路效應：隨著越來越多的開發者開始使用 CUDA，更多的軟體和庫被開發出來，這讓該平臺變得更有價值。

這種早期的使用者基礎使 CUDA 的應用範圍從遊戲領域擴充套件到科學計算、金融、人工智慧和高效能計算（HPC）領域。一旦 CUDA 在這些領域獲得關注，它相較於其他替代方案的優勢就變得很明顯：英偉達持續的投入確保了 CUDA 始終處於 GPU 效能的前沿，而競爭對手卻難以構建一個與之相媲美的生態系統。

抓住並乘上人工智慧軟體的浪潮

隨著深度學習的爆發，CUDA 的主導地位得以鞏固。2012 年，開啟現代人工智慧革命的神經網路 AlexNet，是使用兩塊英偉達 GeForce GTX 580 GPU 進行訓練的。這一突破不僅表明 GPU 在深度學習方面速度更快，還證明了它們對人工智慧的發展至關重要，使得 CUDA 迅速成為深度學習的預設計算後端。

隨著深度學習框架的出現，尤其是谷歌在 2015 年推出的 TensorFlow 和 Meta 在 2016 年推出的 PyTorch，英偉達抓住機遇，大力投入最佳化其高階 CUDA 庫，以確保這些框架在其硬體上儘可能高效地執行。正如我們在第 2 部分所討論的，英偉達積極最佳化 cuDNN 和 TensorRT，而不是讓人工智慧框架團隊自行處理底層的 CUDA 效能調優。

這一舉措不僅使 PyTorch 和 TensorFlow 在英偉達 GPU 上的執行速度大幅提升，還讓英偉達能夠緊密整合其硬體和軟體（這一過程被稱為 “硬體 / 軟體協同設計”），因為這樣減少了與谷歌和 Meta 之間的協調成本。英偉達每推出新一代的主要硬體，就會發佈一個新版本的 CUDA，以利用新硬體的功能。人工智慧領域渴望速度和效率，非常願意將這項工作交給英偉達，這直接導致這些框架與英偉達硬體緊密繫結。

但谷歌和 Meta 為什麼會任由這種情況發生呢？實際上，谷歌和 Meta 並非專注於構建一個廣泛的人工智慧硬體生態系統，它們更關注利用人工智慧來推動營收增長、改進產品以及開展新的研究。它們的頂尖工程師優先處理那些對公司內部指標有重大影響的專案。例如，這些公司決定打造自己的專有 TPU 晶片，將精力投入到為自家的硬體進行最佳化上。因此，把 GPU 相關的事務交給英偉達處理也就順理成章了。

替代硬體製造商則面臨著艱鉅的挑戰，他們試圖複製英偉達龐大且不斷擴充套件的 CUDA 庫生態系統，但卻沒有像英偉達那樣專注於硬體整合。競爭對手不僅進展艱難，還陷入了一個惡性迴圈，總是在追趕英偉達硬體上的下一個人工智慧進展。這也影響了谷歌和 Meta 的內部晶片專案，催生了包括 XLA 和 PyTorch 2 在內的眾多專案。我們會在後續文章中深入探討這些內容，但如今可以看到，儘管人們抱有一些期望，卻沒有什麼能讓硬體創新者具備與 CUDA 平臺相媲美的能力。

英偉達憑藉每一代新硬體不斷擴大領先優勢。然後，在 2022 年末，ChatGPT 突然爆火，隨之而來的是，生成式人工智慧和 GPU 計算走向了主流。

利用生成式人工智慧的熱潮

幾乎在一夜之間，對人工智慧計算的需求急劇飆升，它成為了價值數十億美元產業、消費級應用以及企業競爭戰略的基礎。大型科技公司和風險投資公司向人工智慧研究初創企業和資本支出建設投入了數十億美元，而這些資金最終都流向了英偉達，因為只有它能夠滿足不斷激增的計算需求。

隨著對人工智慧計算需求的激增，企業面臨著一個嚴峻的現實：訓練和部署生成式人工智慧模型的成本高得驚人。每一點效率的提升，無論多麼微小，在大規模應用時都能轉化為巨大的成本節約。由於英偉達的硬體已經在資料中心根深蒂固，人工智慧公司面臨著一個艱難的抉擇：針對 CUDA 進行最佳化，否則就會落後。幾乎一夜之間，整個行業都轉向編寫特定於 CUDA 的程式碼。結果是，人工智慧的突破不再僅僅由模型和演算法驅動，現在還取決於從經過 CUDA 最佳化的程式碼中榨取每一分效率的能力。

以 FlashAttention – 3 為例，這項前沿的最佳化技術大幅降低了執行 Transformer 模型的成本，但它是專門為 Hopper GPU 打造的，透過確保只有在英偉達最新的硬體上才能獲得最佳效能，進一步強化了英偉達的技術鎖定。持續的研究創新也遵循著同樣的模式，比如 DeepSeek 直接採用 PTX 組合語言，在儘可能低的層面上實現對硬體的完全控制。隨著英偉達新的 Blackwell 架構即將推出，可以預見整個行業又要重新編寫所有程式碼了。

強化 CUDA 主導地位的迴圈

這個系統正在加速發展並形成自我強化的態勢。生成式人工智慧已成為一股不可阻擋的力量，推動著對計算能力的無盡需求，而英偉達掌握著所有的優勢。龐大的使用者基礎確保了大多數人工智慧研究都是基於 CUDA 進行的，這反過來又促使人們對最佳化英偉達的平臺進行投資。

英偉達每一代新硬體都帶來新的功能和更高的效率，但這也需要重新編寫軟體、進行新的最佳化，並且對英偉達的技術堆疊產生更深的依賴。未來似乎不可避免：在這個世界裡，CUDA 對人工智慧計算的掌控只會越來越緊。

然而，CUDA 並非完美無缺。

鞏固 CUDA 主導地位的這些因素，也正逐漸成為瓶頸，帶來技術挑戰、效率低下的問題，還阻礙了更廣泛的創新。這種主導地位真的對人工智慧研究領域有益嗎？CUDA 是對開發者有利，還是僅僅對英偉達有利呢？

讓我們退一步思考：我們已經瞭解了 CUDA 是什麼以及它為何如此成功，但它真的好嗎？我們將在下面章節探討這個問題。

CUDA佔據主導地位，但它真的好嗎？

回答 CUDA 是否 “好” 這個問題，遠比聽起來要棘手。我們討論的是它的原始效能？它的功能特性？還是它在人工智慧開發領域更廣泛的影響呢？

CUDA 是否 “好”，這取決於你問的是誰以及他們的需求是什麼。在本章節中，我們將從那些日復一日使用它的人，也就是在生成式人工智慧（GenAI）生態系統中工作的人的角度來評估 CUDA：

對於在 CUDA 基礎上進行開發的人工智慧工程師來說，它是必不可少的工具，但同時也伴隨著版本管理的麻煩、驅動行為不透明以及對平臺的深度依賴等問題。
對於為英偉達硬體編寫 GPU 程式碼的人工智慧工程師而言，CUDA 提供了強大的最佳化能力，但要獲得頂級效能，就必須承受其中的痛苦。
對於那些希望自己的人工智慧工作負載能在多家廠商的 GPU 上執行的人來說，CUDA 與其說是解決方案，不如說是一個障礙。
還有英偉達公司本身，它圍繞 CUDA 積累了鉅額財富，獲取了鉅額利潤，並鞏固了其在人工智慧計算領域的主導地位。

那麼，CUDA 到底 “好不好” 呢？讓我們深入探討每個角度來尋找答案！

AI工程師

如今，許多工程師在人工智慧框架（如 LlamaIndex、LangChain 和 AutoGen 等智慧庫）的基礎上構建應用程式，而無需深入瞭解底層硬體細節。對於這些工程師來說，CUDA 是強大的助力。它在行業內的成熟度和主導地位帶來了顯著優勢：大多數人工智慧庫都設計為能與英偉達硬體無縫協作，而且大家都聚焦於單一平臺，促進了整個行業的合作。

然而，CUDA 的主導地位也帶來了一系列長期存在的挑戰。其中最大的障礙之一是管理不同 CUDA 版本的複雜性，這簡直是一場噩夢。這種無奈成為了眾多梗圖的主題：

這可不只是個梗圖，對許多工程師來說，這是他們真實的經歷。這些人工智慧從業者需要不斷確保 CUDA 工具包、英偉達驅動和人工智慧框架之間的相容性。不匹配的情況可能會導致令人沮喪的構建失敗或執行時錯誤，無數開發者都有過切身體會：

“我無法使用最新的英偉達 PyTorch Docker 映象構建系統。原因是透過 pip 安裝的 PyTorch 是基於 CUDA 11.7 構建的，而容器使用的是 CUDA 12.1。” 或者：“管理英偉達 GPU 驅動和 CUDA 開發軟體可能很有挑戰性。升級 CUDA 版本或更新 Linux 系統可能會導致諸如 GPU 驅動損壞等問題。”

遺憾的是，這類麻煩並不罕見。解決這些問題通常需要深厚的專業知識和耗費大量時間進行故障排查。英偉達依賴不透明的工具和複雜的設定流程，這讓新手望而卻步，也減緩了創新的速度。

為應對這些挑戰，英偉達歷來都是在更高層級提供個別針對性的解決方案，而不是解決 CUDA 層本身這一根本問題。例如，它最近推出了 NIM（英偉達推理微服務），這是一套容器化的微服務，旨在簡化人工智慧模型的部署。雖然這可能會簡化某一特定用例，但 NIM 也將底層操作抽象化了，增加了使用者對其技術的依賴，限制了對底層最佳化和創新的接觸，而這些恰恰是 CUDA 價值主張的關鍵所在。

在 CUDA 基礎上構建應用的人工智慧工程師面臨著相容性和部署方面的挑戰，而那些更接近硬體底層工作的人員，即人工智慧模型開發者和效能工程師，則要應對一系列截然不同的權衡取捨。

AI模型開發者和效能工程師

對於致力於突破人工智慧模型極限的研究人員和工程師來說，CUDA 既是必不可少的工具，也是令人沮喪的限制因素。對他們而言，CUDA 不是一個簡單的 API，而是他們編寫的每一個對效能至關重要的操作的基礎。這些工程師在底層進行最佳化工作，編寫自定義 CUDA 核心，調整記憶體訪問模式，儘可能地從英偉達硬體中榨取每一分效能。生成式人工智慧的規模和成本要求他們這麼做。但 CUDA 是賦予了他們能力，還是限制了他們的創新能力呢？

儘管 CUDA 佔據主導地位，但它也逐漸顯露出不足。它設計於 2007 年，遠在深度學習出現之前，更不用說生成式人工智慧了。從那以後，GPU 發生了巨大的變化，張量核心（Tensor Cores）和稀疏特性成為人工智慧加速的核心要素。CUDA 早期的貢獻是讓 GPU 程式設計變得容易，但它並沒有隨著現代 GPU 為實現 Transformer 和生成式人工智慧效能所必需的特性而發展。這就迫使工程師們不得不繞過它的侷限性，才能獲得工作負載所需的效能。

CUDA 無法充分發揮現代 GPU 的全部功能

像 FlashAttention-3（示例程式碼）和 DeepSeek 的創新技術等前沿技術，要求開發者繞過 CUDA，使用英偉達更低階的組合語言 PTX。PTX 的文件並不完善，在不同硬體代際之間不斷變化，對開發者來說實際上就是個黑箱。

更麻煩的是，PTX 比 CUDA 更依賴英偉達，而且可用性更差。然而，對於追求前沿效能的團隊來說，別無選擇，他們只能繞過 CUDA，承受諸多不便。

張量核心：提升效能的關鍵，但使用難度大

如今，人工智慧模型的大部分浮點運算（FLOPs）來自 “張量核心”，而非傳統的 CUDA 核心。然而，直接對張量核心進行程式設計並非易事。雖然英偉達提供了一些抽象工具（如 cuBLAS 和 CUTLASS），但要充分發揮 GPU 的效能，仍需要晦澀難懂的知識、反覆的試驗和測試，而且常常需要逆向工程一些未文件化的行為。隨著每一代新 GPU 的推出，張量核心都會發生變化，但相關文件卻未能及時更新。這使得工程師在充分挖掘硬體潛力時資源有限。

人工智慧用 Python，而 CUDA 用 C++

另一個主要限制是，編寫 CUDA 程式碼基本上需要使用 C++，而現代人工智慧開發大多是用 Python 完成的。使用 PyTorch 進行人工智慧模型和效能開發的工程師並不想在 Python 和 C++ 之間來回切換，這兩種語言的程式設計思路差異很大。這種不匹配減緩了迭代速度，造成了不必要的阻礙，還迫使人工智慧工程師在本應專注於模型改進的時候，卻要去考慮底層效能細節。此外，CUDA 對 C++ 模板的依賴導致編譯時間極長，而且經常會出現難以理解的錯誤資訊。

如果你樂於專門為英偉達硬體進行開發，就會面臨上述這些挑戰。但如果你關注的不只是英偉達呢？

開發可移植軟體的工程師和研究人員

並非所有人都願意開發鎖定英偉達硬體的軟體，其中的挑戰顯而易見。CUDA 無法在其他廠商的硬體上執行（比如我們口袋裡的手機晶片這類硬體），而且沒有其他方案能在英偉達硬體上提供與 CUDA 相同的效能和功能。這就迫使開發者針對多個平臺多次編寫人工智慧程式碼。

在實際操作中，許多跨平臺人工智慧開發工作都困難重重。早期版本的 TensorFlow 和 PyTorch 有 OpenCL 後端，但在功能和速度上都遠遠落後於 CUDA 後端，這使得大多數使用者還是選擇使用英偉達的產品。維護多條程式碼路徑（CUDA 用於英偉達，其他方案用於其他平臺）成本高昂，而且隨著人工智慧的快速發展，只有大型機構才有資源進行這樣的工作。

CUDA 造成的這種分化形成了一個自我強化的迴圈：由於英偉達擁有最大的使用者群體和最強大的硬體，大多數開發者首先會針對 CUDA 進行開發，並期望其他方案最終能趕上來。這進一步鞏固了 CUDA 作為人工智慧預設平臺的主導地位。

接下來，我們探討 OpenCL、TritonLang 和 MLIR 編譯器等替代方案，並瞭解為什麼這些選項沒有對 CUDA 的主導地位造成影響。

CUDA 對英偉達自身有好處嗎？

答案當然是肯定的：“CUDA 護城河” 造就了贏者通吃的局面。到 2023 年，英偉達佔據了資料中心 GPU 市場約 98% 的份額，鞏固了其在人工智慧領域的主導地位。正如我們在之前的文章中所討論的，CUDA 是連線英偉達過去和未來產品的橋樑，推動了像 Blackwell 這樣的新架構的應用，維持了英偉達在人工智慧計算領域的領先地位。

然而，像Jim Keller這樣的傳奇硬體專家認為，“CUDA 是片泥沼，而非護城河”，他將其與拖累英特爾的 X86 架構相類比。

Jim Keller認為， “ CUDA 是沼澤，而不是護城河”

CUDA 怎麼會成為英偉達的問題呢？這存在幾個挑戰。

CUDA 的可用性對英偉達影響最大

黃仁勳曾說過，英偉達僱傭的軟體工程師比硬體工程師還多，其中很大一部分人都在編寫 CUDA 相關程式碼。但 CUDA 在可用性和可擴充套件性方面的挑戰減緩了創新速度，迫使英偉達大量招聘工程師來解決這些問題。

CUDA 的龐大體量影響新硬體的推出

CUDA 在英偉達自身不同代際的硬體之間無法實現效能的可移植性，而且其龐大的庫規模是一把雙刃劍。當推出像 Blackwell 這樣的新一代 GPU 時，英偉達面臨一個選擇：重寫 CUDA，或者推出無法充分發揮新架構效能的硬體。這就解釋了為什麼每一代新硬體在推出時效能都不是最優的。擴充套件 CUDA 的功能既昂貴又耗時。

創新者的困境

英偉達對向後相容性的堅持，這曾是 CUDA 早期的賣點之一，如今卻成了 “技術債務”，阻礙了其自身的快速創新。雖然對老一代 GPU 的支援對開發者群體至關重要，但這迫使英偉達優先考慮穩定性，而非進行革命性的變革。這種長期支援耗費時間和資源，可能會限制其未來的靈活性。

儘管英偉達向開發者承諾會保持連續性，但 Blackwell 如果不打破與 Hopper PTX 的相容性，就無法實現其效能目標，現在一些 Hopper PTX 操作在 Blackwell 上無法執行。這意味著那些繞過 CUDA 而選擇 PTX 的高階開發者可能需要為下一代硬體重寫程式碼。

儘管存在這些挑戰，但英偉達在軟體方面的出色執行和早期的戰略決策，為其未來的增長奠定了良好的基礎。隨著生成式人工智慧的興起，以及基於 CUDA 構建的生態系統不斷發展，英偉達有望繼續處於人工智慧計算的前沿，並已迅速成長為全球最具價值的公司之一。

CUDA 的替代方案在哪裡？

總之，CUDA 既是恩賜也是負擔，這取決於你處於生態系統的哪一方。它的巨大成功推動了英偉達的主導地位，但它的複雜性、技術債務以及對供應商的鎖定，給開發者和人工智慧計算的未來帶來了重大挑戰。

隨著人工智慧硬體的快速發展，一個自然而然的問題出現了：CUDA 的替代方案在哪裡？為什麼其他方案還沒有解決這些問題呢？在接下來的章節中，我們將探討最具代表性的替代方案，分析阻礙它們突破 CUDA 護城河的技術和戰略問題。

像 OpenCL 這樣的 CUDA C++ 替代方案怎麼樣？

生成式人工智慧（GenAI）或許是新事物，但 GPU 可不是！多年來，許多人嘗試用 C++ 建立可移植的 GPU 程式設計模型，從 OpenCL 到 SYCL，再到 OneAPI 等等。這些本是最有可能替代 CUDA 的方案，旨在實現人工智慧計算的民主化，但你可能從未聽說過它們，因為它們在人工智慧領域並未發揮重要作用。

這些專案都為計算領域做出了有意義的貢獻，但如果我們真想為未來解鎖人工智慧計算，就必須認真審視那些阻礙它們發展的錯誤，而不能只盯著成功之處。從宏觀層面看，問題源於 “開放式競合” 的挑戰，即行業參與者既合作又競爭，以及過程中特定的管理失誤。讓我們深入探討一下。

CUDA C++ 的替代方案：OpenCL、SYCL 等

有許多專案致力於實現 GPU 程式設計，其中我最瞭解的是 OpenCL。和 CUDA 一樣，OpenCL 旨在為程式設計師提供類似 C++ 的程式設計體驗，以便在 GPU 上執行程式碼。這背後還有我的一段個人經歷：2008 年，我是蘋果公司負責實現 OpenCL 的首席工程師之一（這是我當時構建的 Clang 編譯器首次投入實際應用）。在我們完成開發後，做出了一個關鍵決定，將其貢獻給 Khronos Group，以便在整個行業得到採用和標準化。

這一決定使得 OpenCL 在行業內得到廣泛應用（見相關標識），尤其在移動和嵌入式裝置領域。如今，它依然非常成功，為安卓等平臺以及數字訊號處理器（DSP）等專業應用中的 GPU 計算提供支援。與 CUDA 不同，OpenCL 從一開始就設計為具有可移植性，旨在支援 CPU、GPU 和其他加速器之間的異構計算。OpenCL 還啟發了其他系統，如 SyCL、Vulkan、SPIR-V、oneAPI、WebCL 等等。

然而，儘管 OpenCL 在技術上有優勢且應用廣泛，但它從未成為主導的人工智慧計算平臺。主要原因有以下幾點：開放式競閤中固有的矛盾、由此產生的技術問題、人工智慧不斷變化的需求，以及英偉達針對 TensorFlow 和 PyTorch 的統一戰略。

委員會決策速度下的 “競合” 問題

2008 年，蘋果在個人電腦領域還只是個小角色，當時認為行業標準化能讓其接觸到更多開發者。雖然 OpenCL 確實在硬體製造商中得到廣泛採用，但其發展很快遇到了一個重大障礙：委員會驅動的開發速度太慢。對蘋果來說，這種緩慢、依賴共識的決策過程是個大問題：我們希望快速推進平臺發展，新增新功能（比如新增 C++ 模板），並展現蘋果平臺的差異化。我們面臨著一個殘酷的現實 —— 委員會制定標準的弊端在於，一切都按照委員會達成共識的速度推進，而這個速度就像冰川移動一樣緩慢。

硬體供應商們認識到統一軟體生態系統的長期益處，但在短期內，他們又是激烈的競爭對手。這就引發了一些微妙卻很嚴重的問題：參與者們不會向委員會透露正在研發的硬體特性（以免讓競爭對手搶佔先機），而是會在硬體釋出後才公開這些創新，並且只有在這些特性成為通用功能後才會進行討論（轉而使用特定供應商的擴充套件）。

合作競爭：競爭對手之間的“合作”

這種情況對蘋果來說是個大麻煩，因為蘋果想要快速秘密推進專案，以便在產品釋出時大放異彩。因此，蘋果決定放棄 OpenCL，推出了 Metal 替代它，從未在 iOS 系統中引入 OpenCL，後來還在 macOS 系統中棄用了它。其他公司雖然繼續使用 OpenCL，但這些結構性挑戰持續限制著它，使其無法跟上前沿人工智慧和 GPU 創新的步伐。

OpenCL 的技術問題

雖然蘋果大膽地將 OpenCL 標準貢獻給了 Kronos，但並沒有全力以赴：蘋果貢獻的只是 OpenCL 的技術規範，而沒有完整的參考實現。儘管編譯器前端（Clang）的部分是開源的，但沒有共享的 OpenCL 執行時，這就迫使供應商們開發自己的定製版本並完善編譯器。每個供應商都必須維護自己的實現（即 “分支”），由於缺乏共享且不斷發展的參考標準，OpenCL 變成了一個由特定供應商的分支和擴充套件拼湊而成的產物。這種碎片化最終削弱了它原本旨在實現的可移植性。

此外，由於供應商們隱瞞差異化特性，或者將這些特性分離成數量眾多的特定供應商擴充套件，導致 OpenCL（及其衍生專案）碎片化，侵蝕了它作為一個統一的、與供應商無關的平臺的能力。

OpenCL 在相容性和一致性測試方面的不足，更是加劇了這些問題。最重要的是，它還存在我們之前提到的所有 “C++ 相關問題”。

開發者們想要的是穩定且得到良好支援的工具，但 OpenCL 的碎片化、薄弱的一致性測試以及不一致的供應商支援，讓使用它成為了一件令人沮喪的事。一位開發者總結說，使用 OpenCL “就像擁抱仙人掌一樣難受”！太扎心了。

一位開發人員將使用 OpenCL 描述為“就像擁抱仙人掌一樣難受”。

就在 OpenCL 受困於碎片化和緩慢的發展速度時，人工智慧在軟體框架和硬體效能方面都在迅速進步。這使得 OpenCL 所能提供的功能與現代人工智慧工作負載的需求之間的差距越來越大。

AI研究和AI GPU硬體不斷變化的需求

TensorFlow 和 PyTorch 的推出掀起了人工智慧研究的革命，不斷完善的基礎設施和大型企業大量資金的湧入為其提供了強大動力。這給 OpenCL 帶來了巨大挑戰。雖然 OpenCL 支援 GPU 計算，但缺乏大規模訓練和推理所需的高階人工智慧庫和最佳化。與 CUDA 不同，它沒有對矩陣乘法、Flash Attention 或資料中心規模的訓練等關鍵操作的內建支援。

儘管將 TensorFlow 和 PyTorch 擴充套件以使用 OpenCL 的跨行業努力有明顯的需求，但很快就遇到了根本性的障礙。那些堅持使用 OpenCL 的開發者很快發現了一個殘酷的現實：如果無法充分發揮新硬體的效能，那麼對新硬體的可移植性就毫無意義。由於無法實現可移植的特定硬體增強功能，再加上競合關係破壞了合作，相關進展陷入了停滯。

一個明顯的例子是，OpenCL 至今仍未對張量核心（Tensor Cores）提供標準化支援，而張量核心是現代 GPU 和人工智慧加速器中實現高效矩陣乘法的專用硬體單元。這意味著，與使用 CUDA 或其他碎片化的特定供應商原生軟體相比，使用 OpenCL 通常會導致效能降低 5 到 10 倍。在生成式人工智慧領域，計算成本已經高得驚人，效能降低 5 到 10 倍可不只是不方便的問題，而是根本無法接受。

英偉達針對 TensorFlow 和 PyTorch 的戰略舉措

當 OpenCL 在碎片化管理的重壓下艱難前行時，英偉達採取了截然不同的策略。正如我們前面討論過的，英偉達的策略是嚴格控制、極具戰略性且卓有成效的。英偉達積極與 TensorFlow 和 PyTorch 共同設計 CUDA 的高階庫，確保這些框架在英偉達硬體上始終能達到最佳執行效果。由於這些框架原生就構建在 CUDA 之上，英偉達一開始就佔據了巨大優勢，並且透過最佳化使其效能從一開始就出類拔萃。

英偉達雖然保留了 OpenCL 的實現，但從戰略上對其進行了限制（比如無法使用張量核心），這就確保了 CUDA 的實現始終是必要的。隨著英偉達在行業內的主導地位不斷鞏固和提升，它不斷加大對 CUDA 實現的投入。久而久之，OpenCL 的支援逐漸減少，直至消失，而 CUDA 則鞏固了其作為無可爭議的行業標準的地位。

我們能從這些 C++ GPU 專案中學到什麼？

經歷過這些的人都很清楚上述歷史，但真正的價值在於從過去中吸取教訓。基於此，我認為成功的系統必須具備以下幾點：

提供參考實現，而不只是一份書面規範和 “相容性” 測試。一個可用、可採用且可擴充套件的實現才應定義相容性，而不是一份 PDF 文件。
由維護參考實現的團隊提供強有力的領導和明確的願景。
在行業領先企業的硬體上實現頂級效能，否則它永遠只能是二流的替代方案，無法成為統一行業的標準。
快速發展以滿足不斷變化的需求，因為人工智慧研究不會停滯不前，人工智慧硬體創新仍在加速。
提供出色的可用性、工具和快速的編譯時間，以此贏得開發者的青睞。另外，在人工智慧領域，“類似 C++” 可不是什麼賣點！
建立開放的社群，因為沒有廣泛的採用，技術實力再強也無濟於事。
避免碎片化，一個分裂成不相容分支的標準，無法為軟體開發人員提供有效的統一框架。

這些就是我認為像 OpenCL 這樣由委員會推動的專案永遠不會成功的根本原因。這也是為什麼我對英特爾的 OneAPI（現 UXL Foundation）等專案更加懷疑，這些專案名義上是開放的，但實際上由單一硬體供應商掌控，而該供應商又與其他所有供應商存在競爭關係。

AI編譯器呢？

在 C++ 相關方案未能為硬體製造商統一人工智慧計算的同時，人工智慧行業面臨著一個更大的挑戰，即使是在英偉達硬體上使用 CUDA 也存在問題。如果所有程式碼都需要人工編寫，我們要如何實現人工智慧計算的擴充套件呢？晶片種類繁多，人工智慧演算法層出不窮，工作負載的組合更是不計其數，靠人工最佳化根本無法完成。

隨著人工智慧的影響力不斷擴大，它不可避免地引起了系統開發者和編譯器工程師（包括我在內）的關注。在下一篇文章中，我們將深入探討廣為人知的 “人工智慧編譯器” 棧，如 TVM、OpenXLA 和 MLIR，分析哪些成功了，哪些失敗了，以及我們能從中吸取什麼教訓。遺憾的是，這些教訓與上面提到的並沒有太大不同：

歷史不會簡單重複，但總會押著相同的韻腳。—— 馬克・吐溫

人工智慧編譯器（TVM 和 XLA）怎麼樣？

在人工智慧硬體發展的早期階段，編寫高效能的 GPU 程式碼雖然繁瑣，但仍在可掌控範圍內。工程師們可以用 C++ 為所需的關鍵操作精心編寫 CUDA 核心，英偉達再將這些核心整合到像 cuDNN 這樣的庫中，以此鞏固其行業地位。但隨著深度學習的不斷發展，這種方式完全行不通了。

神經網路規模越來越大，架構愈發複雜，研究人員對迭代週期的速度要求也越來越高。像 PyTorch 這樣的框架中，獨特運算元的數量呈爆發式增長，如今已達數千個。要為每個新的硬體目標手動編寫並最佳化每個運算元？這根本不可能。

PyTorch 運算子按版本計數

這一挑戰促使行業發生了根本性轉變：既然手動編寫核心不可行，那要是有一個編譯器能自動生成核心會怎麼樣呢？人工智慧編譯器應運而生，旨在解決這一難題，這標誌著從人工編寫 CUDA 程式碼向機器生成、硬體最佳化計算的轉變。

但歷史表明，構建一個成功的編譯器棧不僅是技術上的挑戰，更是生態系統、碎片化和控制權的爭奪戰。那麼，哪些成功了？哪些失敗了？我們能從 TVM 和 OpenXLA 等專案中學到什麼呢？

什麼是 “AI編譯器”？

人工智慧編譯器的核心是一個系統，它能夠將像 PyTorch 或 TensorFlow 中的高階操作，自動轉換為高效的 GPU 程式碼。它執行的最基本最佳化之一叫做 “核心融合”。為了理解其重要性，我們來看一個簡單的例子：先將兩個矩陣相乘（“矩陣乘法”），然後應用 ReLU（修正線性單元）啟用函式。這些是常見神經網路中簡單卻重要的操作。

簡單方法：兩個獨立核心

最直接（但效率低下）的做法是先進行矩陣乘法，將結果儲存在記憶體中，然後再次讀取該結果以應用 ReLU 函式。

對於可能編寫 CUDA 核心的工程師來說，這些操作非常熟悉（不過要記住，CUDA 使用的是複雜的 C++ 語法！），並且有許多提高效率的實現技巧。

雖然上述方法簡單且模組化，但這樣執行操作的速度極慢，因為在matmul()之後，整個矩陣C被寫入記憶體，然後在relu()中又再次讀取。這種記憶體資料傳輸嚴重影響效能，在 GPU 上尤其如此，因為在 GPU 中，記憶體訪問的成本比本地計算更高。

融合核心：一次遍歷，無額外記憶體傳輸

解決方案很簡單：我們可以將這兩個操作 “融合” 為一個核心，消除冗餘的記憶體訪問。在matmul()之後，我們不再儲存C，而是在同一迴圈中立即應用relu()：

雖然這種轉換帶來的效能提升因硬體和矩陣大小而異，但效果可能非常顯著：有時效能可提升兩倍！為什麼會這樣呢？透過融合操作：

我們消除了一次額外的記憶體寫入 / 讀取操作，減輕了記憶體頻寬的壓力。
我們將資料保留在暫存器或共享記憶體中，避免了緩慢的全域性記憶體訪問。
由於中間緩衝區被移除，我們減少了記憶體使用以及分配 / 釋放記憶體的開銷。

這只是核心融合的一個簡單示例：還有許多更強大的轉換方法，人工智慧核心工程師一直在挑戰最佳化的極限（瞭解更多）。隨著生成式人工智慧對計算需求的不斷攀升，這些最佳化比以往任何時候都更加關鍵。

卓越效能，但複雜度呈指數級增長！

對於那些追求低成本和最前沿效能的人來說，實現這類最佳化既令人興奮又充滿樂趣，但背後隱藏著一個事實：這種方法無法擴充套件。

現代機器學習工具包包含數百種不同的 “操作”，如矩陣乘法、卷積、加法、減法、除法等，除了 ReLU 之外，還有數十種啟用函式。每個神經網路需要以不同方式組合這些操作，這導致需要實現的組合數量呈爆炸式增長（數百種操作 × 數百種操作 = 多得數不清）。英偉達的庫（如 cuDNN）提供了一個固定的選項列表供選擇，但無法滿足新研究的通用性需求。

此外，還有其他方面的複雜性增長：新的數值資料型別（如 “float8”）不斷湧現，當然，人工智慧需要支援的硬體種類也在激增。

複雜性的三個維度

早期人工智慧編譯器：TVM

人工智慧編譯器有很多，其中最早且最成功的之一是 TVM（Tensor Virtual Machine：張量虛擬機器）。這個系統獲取來自 TensorFlow/PyTorch 的模型，並針對不同硬體進行最佳化，即自動應用核心融合技術。該專案大約在 2016 年由華盛頓大學的陳天奇和路易斯・塞澤教授發起，2018 年一篇概述 TVM 架構的論文介紹了其多項創新成果和效能優勢。TVM 後來開源並融入了 Apache 專案。

在其發展過程中，TVM 被眾多硬體製造商採用（包括 ARM、高通、Facebook、英特爾等公司的公開貢獻），應用於嵌入式、數字訊號處理（DSP）等多個領域。TVM 的核心貢獻者後來創立了 OctoAI，英偉達在 2024 年末收購了該公司，從而控制了許多 TVM 的原始開發者，這也可能影響該專案的未來發展。

TVM 是人工智慧編譯器行業的重要一步，但我們能從中學到什麼呢？以下是我的關鍵收穫。免責宣告：雖然 TVM 使用了 LLVM，我也對其很感興趣，但我從未直接參與其中。這是我作為局外人的觀點。

無法在現代硬體上實現最佳效能

TVM 在現代人工智慧硬體上難以實現最佳效能，尤其是隨著 GPU 向張量核心（TensorCores）和其他專用加速技術發展。雖然 TVM 後來增加了對新硬體的支援，但往往滯後，無法充分釋放硬體效能。因此，它和 OpenCL 有同樣的問題：如果無法充分利用硬體，就無法實現高效能。

商業利益衝突導致碎片化

與 OpenCL 不同，TVM 不僅僅是一個規範，它有實際的實現。這使得它開箱即用的實用性更強，吸引了眾多硬體供應商。但碎片化問題依然存在：供應商們對程式碼進行分叉，做出不相容的更改，並且難以保持同步，這減緩了專案進展。這導致架構變更的執行出現摩擦（因為下游供應商抱怨他們的分叉版本被破壞），進而阻礙了開發。

需要敏捷應對人工智慧的快速發展

最後一個挑戰是，TVM 出現得比較早，但它周圍的人工智慧創新速度極快。由於得到谷歌、Meta 和英偉達等大型公司的支援，TensorFlow 和 PyTorch 迅速發展，效能不斷提升，這也改變了 TVM 的效能對比基準。而生成式人工智慧的出現更是給 TVM 帶來了致命一擊，改變了整個行業格局。TVM 是為 “傳統人工智慧（TradAI）” 設計的，處理的是相對簡單的需要融合的運算元，而生成式人工智慧涉及與硬體深度整合的大型複雜演算法，如 FlashAttention3。隨著行業的發展，TVM 逐漸落後。

相對沒那麼重要（但仍然不可忽視）的是，TVM 還存在技術問題，比如由於過度自動調優導致編譯時間極長。這些問題共同導致專案發展放緩。

如今，英偉達僱傭了許多 TVM 的原核心成員，這使得 TVM 的未來充滿不確定性。與此同時，谷歌則透過 OpenXLA 踐行自己的理念……

谷歌的 XLA 編譯器：一個名稱下的兩個不同系統

與起源於學術專案的 TVM 不同，XLA 是由谷歌開發的。谷歌是最先進的人工智慧公司之一，資金雄厚，在人工智慧硬體領域有著重大利益。谷歌開發 XLA 是為了在其（如今已取得成功的）TPU 硬體中取代 CUDA，確保為自身人工智慧工作負載實現緊密整合和最佳效能。2017 年，我加入谷歌大腦團隊，幫助將 TPU（以及 XLA）從一個實驗專案擴充套件為全球第二成功的人工智慧加速器（僅次於英偉達）。

Google TPU

谷歌有數百名工程師參與 XLA 的開發（具體人數因統計方式而異），其發展迅速。谷歌增加了對 CPU 和 GPU 的支援，並最終成立了 OpenXLA 基金會。XLA 被用作多個重要硬體專案的人工智慧編譯器基礎，包括 AWS 的 Inferentia/Trainium 等。

除了程式碼生成，XLA 最大的成就和貢獻之一是能夠處理大規模機器學習模型。在超大規模場景下，使用數千個晶片進行訓練的能力至關重要。如今，最大的實用模型開始需要先進技術將其在多臺機器上進行分割槽，XLA 開發出了簡潔有效的方法來實現這一點。

既然投入如此巨大，為什麼像 PyTorch 和 vLLM 這樣的領先專案不在 GPU 上使用 XLA 呢？答案是，XLA 實際上是兩個不同的專案，只是品牌名稱合併了，其背後存在工程師激勵結構問題、管理難題以及技術問題，這些使得 XLA 在實際應用中存在困難。

谷歌使用 XLA-TPU，而 OpenXLA 面向其他使用者

需要理解的最重要一點是，XLA 有兩種形式：1）內部閉源的 XLA-TPU 編譯器，為谷歌的人工智慧基礎設施提供支援；2）OpenXLA，這是面向 CPU 和 GPU 的公共專案。這兩個版本有部分程式碼（“StableHLO”）是共享的，但 XLA 的絕大部分程式碼（以及相應的工程工作）是針對谷歌 TPU 的，屬於閉源專有程式碼，並不用於 CPU 或 GPU。如今，在 GPU 上使用 XLA 通常需要呼叫標準的 CUDA 庫來提升效能。

這就導致了嚴重的激勵結構問題 —— 谷歌的工程師可能想要構建一個出色的通用人工智慧編譯器，但他們的收入與 TPU 的效能表現掛鉤。領導層沒有太多動力為 GPU 或其他替代硬體最佳化 XLA，一切都以保持 TPU 的競爭力為目標。以我的經驗來看，如果某項設計變更可能影響 TPU 效能，XLA 就不會優先考慮那些對其他晶片有利的改變。

結果就是，XLA 在 TPU 上表現出色，但在其他地方卻不盡如人意。

OpenXLA 的管理

XLA 很早就作為開源專案釋出，但明確由谷歌控制。谷歌憑藉在人工智慧領域的早期領先地位和 TensorFlow，使得 XLA 被行業內其他團隊採用。2023 年 3 月，該專案更名為 OpenXLA，並宣佈獨立。

儘管進行了更名，但谷歌仍然控制著 OpenXLA（從其管理結構可以看出），而且似乎也沒有持續投入：社群貢獻不斷減少，OpenXLA 的官方賬號自 2023 年起就不再活躍。

XLA 的技術挑戰

和 TVM 一樣，XLA 也是圍繞一組固定的預定義運算元（StableHLO）設計的。這種方法在 2017 年處理像 ResNet-50 這樣的傳統人工智慧模型時效果很好，但在應對現代生成式人工智慧工作負載時卻力不從心，因為現代生成式人工智慧在資料型別、自定義核心和特定硬體最佳化方面需要更高的靈活性。如今，這是一個關鍵問題，現代生成式人工智慧演算法在資料型別上需要創新（見下圖），或者像 DeepSeek 所展示的那樣，在硬體層面和新型通訊策略上進行創新。

vLLM 0.7 中按硬體型別支援的資料型別

因此，XLA（和 TVM 一樣）也被生成式人工智慧甩在了後面：如今，許多關鍵工作負載都是在像 Pallas 這樣的實驗性系統中編寫的，即使在 TPU 上也繞過了 XLA 編譯器。核心原因是，為了簡化人工智慧編譯，XLA 對硬體進行了過多的抽象。這在早期人工智慧模型中可行，但生成式人工智慧需要對加速器進行細粒度控制，而這正是 XLA 天生不具備的能力。所以，和 TVM 一樣，XLA 也逐漸被淘汰。

從 TVM 和 XLA 中吸取的教訓

我為我們在 XLA-TPU 中取得的技術成就感到自豪：XLA 為許多代際研究突破提供了支援，包括 Transformer 的發明、無數的模型架構，以及在其他地方看不到的研究和產品擴充套件。顯然，它是英偉達之外最成功的訓練和推理硬體，支撐著谷歌眾多領先的人工智慧產品和技術。雖然我對 TVM 瞭解較少，但我非常尊重它對編譯器研究、自動調優以及為許多早期人工智慧系統提供支援所做出的貢獻。

即便如此，我們還是能從這兩個專案中學到很多。回顧從 OpenCL 專案中吸取的教訓：

“提供參考實現”：它們都提供了實用的實現，而不像 OpenCL 那樣只是一個技術規範。👍
“擁有強大的領導力和願景”：它們都有明確的領導團隊和背後的願景。👍 然而，OpenXLA 的願景與希望採用它的硬體團隊並不一致。和許多谷歌的專案一樣，其長期前景不明朗，依賴它存在風險。👎
“在行業領先企業的硬體上實現頂級效能”：如果不呼叫 CUDA 庫，XLA 和 TVM 都無法充分發揮英偉達 GPU 的效能，因此，如果沒有類似的庫可供呼叫，它們在其他人工智慧加速器上的效能表現也存疑。👎 XLA 在 TPU 上確實展現了 TPU 硬體的強大能力以及比英偉達硬體更好的擴充套件性。👍
“快速發展”：這兩個專案都是為傳統深度學習構建的，但生成式人工智慧打破了它們的設想。向大規模模型、複雜記憶體層次結構和新型注意力機制的轉變，需要新的硬體 – 軟體協同設計水平，而這是它們無法應對的。👎 這最終使得那些希望在支援生成式人工智慧的現代硬體上使用它們的人對其興趣大減。👎👎
“贏得開發者的喜愛”：XLA 的優勢在於提供了一個簡單清晰、易於理解的模型，這使得 JAX 框架等得以興起。👍👍 TVM 技術很酷，但由於編譯時間長且與流行的人工智慧模型不相容，使用體驗不佳。👎
“建立開放的社群”：TVM 建立了開放的社群，OpenXLA 也有此目標。因此，它們都從行業應用中受益。👍
“避免碎片化”：這兩個專案都沒有做到 ——TVM 被下游廣泛分叉和修改，XLA 的程式碼庫從不接受對非 CPU/GPU 硬體的支援，所有支援的硬體都是下游自行新增的。👎

AI編譯器技術的優缺點

像 TensorFlow 和 PyTorch 1.0 這樣的第一代人工智慧框架嚴重依賴手工編寫的 CUDA 核心，無法適應快速發展的人工智慧工作負載。作為第二代方法，TVM 和 XLA 透過自動編譯解決了這一問題。然而，這樣做的同時，它們犧牲了第一代框架的關鍵優勢：自定義演算法的可擴充套件性、對硬體的細粒度控制以及動態執行能力，而這些特性對於生成式人工智慧至關重要。

除了從 OpenCL 專案中吸取的教訓，我們還可以提出一些期望：

實現完全可程式設計性：如果對開發者隱藏晶片的強大功能，就無法實現人工智慧的民主化。如果你花費 1 億美元購買特定型別的 GPU 叢集，你肯定希望充分釋放晶片的全部效能，而不受限於簡化的介面。
充分利用 AI 的複雜性：AI 編譯器的主要優勢在於，它允許開發者無需手動編寫大量程式碼，即可擴充套件到 AI 的指數級複雜性（運算子、資料型別等）。這對於解鎖下一代研究至關重要。
支援大規模應用：XLA 的變革效能力在於能夠輕鬆擴充套件到多個加速器和節點。這項能力對於輕鬆支援最大規模、最具創新性的模型至關重要。這是 CUDA 從未真正突破的領域。

儘管這些 AI 編譯器各有優劣，但它們都未能完全釋放 GPU 效能或實現 AI 計算的大眾化。相反，它們強化了各自為政：XLA 仍然以 TPU 為中心，而 TVM 則分裂成互不相容的特定供應商分支。它們的失敗，恰恰是 CUDA 替代方案本應獲得成功的方式！

也許 Triton“語言”會拯救我們？

然而，就在這些編譯器苦苦掙扎的同時，一種不同的方法正在形成。它並非試圖取代 CUDA，而是旨在擁抱 GPU 程式設計，同時使其更具可程式設計性。

Triton 和新一波 Python eDSL 的出現，試圖彌合 CUDA 的原始強大功能與 Python 的易用性之間的差距。在下一篇文章中，我們將深入探討這些框架，看看它們的優勢所在，不足之處，以及它們是否最終擺脫了過去的錯誤。

當然，你已經知道答案了。CUDA帝國依然佔據主導地位。但為什麼呢？更重要的是——我們能做些什麼呢？

那些不記得過去的人註定會重蹈覆轍。——喬治·桑塔亞那

也許有一天，編譯器技術能夠在不剝奪我們能力的情況下減輕我們的痛苦。

Triton 和 Python eDSL 怎麼樣？

人工智慧編譯器面臨著一個根本性的權衡：它們旨在透過抽象底層細節來提升易用性和可擴充套件性，但現代生成式人工智慧工作負載需要可程式設計性和硬體控制權，才能實現頂級效能。CUDA C++ 能提供這種控制水平，但其使用難度大是出了名的。與此同時，人工智慧開發大多在 Python 環境中進行，因此，行業自然試圖將 GPU 程式設計與 Python 結合起來，以彌合兩者之間的差距。

但這裡有個問題：Python 無法在 GPU 上執行。為了填補這一空白，研究人員開發了嵌入式領域特定語言（eDSLs），這是一種基於 Python 的抽象語言，表面上看起來像 Python，但實際上在底層會編譯成高效的 GPU 程式碼。其理念很簡單：讓工程師們在無需忍受 C++ 複雜性的情況下，就能獲得 CUDA 的強大功能。但它真的有效嗎？

在本章節中，我們將深入剖析 Python eDSLs 的工作原理、優缺點，並仔細研究 Triton（該領域最受歡迎的方法之一）以及其他一些工具。Python eDSLs 能否同時兼顧效能和易用性，還是說它們只是實現人工智慧計算民主化道路上的又一次彎路？

什麼是嵌入式領域特定語言（eDSL）？

當某個特定領域擁有獨特的表達方式，能提高開發者的工作效率時，就會用到領域特定語言，其中最廣為人知的或許就是 HTML、SQL 和正則表示式。“嵌入式領域特定語言（eDSL）” 是一種複用現有語言語法，但透過編譯器技術改變程式碼執行方式的領域特定語言。eDSL 廣泛應用於許多系統，從分散式計算（PySpark）到深度學習框架（TensorFlow、PyTorch），再到 GPU 程式設計（Triton）。

例如，PySpark 允許使用者用 Python 表達資料轉換操作，然後構建一個最佳化的執行計劃，使其能在叢集上高效執行。同樣，TensorFlow 的tf.function和 PyTorch 的torch.fx會將類似 Python 的程式碼轉換為最佳化的計算圖。這些 eDSL 抽象掉了底層細節，讓開發者無需具備分散式系統、GPU 程式設計或編譯器設計方面的專業知識，就能輕鬆編寫高效程式碼。

eDSL 是如何工作的？

eDSL 的神奇之處在於，它會在 Python 程式碼執行前捕獲程式碼，並將其轉換為可處理的形式。它們通常利用裝飾器（Python 的一個特性）在函式執行前攔截函式。當你使用@triton.jit時，Python 會將函式交給 Triton 處理，而不是直接執行它。

下面是一個簡單的 Triton 示例：

當 Triton 接收到這段程式碼時，它會將函式解析為抽象語法樹（AST），該樹表示函式的結構，包括操作和資料依賴關係。這種表示方式使 Triton 能夠分析程式碼模式、應用最佳化，並生成執行相同操作的高效 GPU 程式碼。

透過複用 Python 現有的語法和工具，eDSL 的開發者可以專注於構建編譯器邏輯，而無需設計一門全新的語言，也不用編寫自己的解析器、語法和工具鏈。

eDSL 的優勢

eDSL 為構建領域特定編譯器的人帶來了巨大優勢：透過將語言嵌入 Python，開發者可以專注於編譯器邏輯，而不必重新發明一門完整的程式語言。設計新語法、編寫解析器和構建整合開發環境（IDE）工具是一項浩大的工程，而藉助 Python 現有的語法和 AST 工具，eDSL 開發者可以跳過這些步驟，直接解決眼前的問題。

eDSL 的使用者也能從中受益：Python eDSL 讓開發者可以在熟悉的環境中工作。他們可以使用相同的 Python IDE、自動補全功能、除錯工具、包管理器（如pip和conda）以及庫生態系統。開發者無需學習像 CUDA C++ 這樣全新的語言，只需用 Python 編寫程式碼，eDSL 會在底層引導程式碼執行。

然而，這種便利性也伴隨著重大的權衡，對於期望 eDSL 表現得像常規 Python 程式碼的開發者來說，可能會感到沮喪。

eDSL 面臨的挑戰

當然，天下沒有免費的午餐。eDSL 存在一些權衡取捨，其中一些問題可能會讓開發者深感困擾。

看起來像 Python，但並非真正的 Python

這是 eDSL 中最令人困惑的部分。雖然程式碼看起來像常規 Python，但它的行為在某些關鍵方面並不像 Python：

為什麼會這樣呢？因為 eDSL 並不是在執行 Python 程式碼，而是捕獲並將函式轉換為其他形式。它決定支援哪些結構，許多常見的 Python 特性（如動態列表、異常處理或遞迴）可能根本無法使用。這可能會導致一些在 Python 中本應正常工作的程式碼突然出現無聲失敗或難以理解的錯誤。

錯誤和工具限制

除錯 eDSL 程式碼可能是一場噩夢。當代碼出現故障時，你通常不會得到熟悉的 Python 友好錯誤資訊。相反，你看到的是來自編譯器內部深處的晦澀堆疊跟蹤資訊，幾乎無法判斷哪裡出了問題。更糟糕的是，像 Python 偵錯程式這樣的標準工具通常根本無法使用，你只能依賴 eDSL 提供的除錯功能（如果有的話）。此外，雖然 eDSL 存在於 Python 環境中，但它們不能直接使用 Python 庫。

表達能力有限

eDSL 透過複用 Python 的語法來工作，這意味著它們無法引入可能對其領域有用的新語法。像 CUDA C++ 這樣的語言可以新增自定義關鍵字、新結構或特定領域的最佳化，而 eDSL 則侷限於 Python 的子語言，這限制了它的清晰表達能力。

最終，特定 eDSL 的質量決定了這些權衡帶來的困擾程度。實現良好的 eDSL 可以提供流暢的體驗，而設計不佳的 eDSL 則可能是一個充滿挫折的 “雷區”，總是與開發者的預期相悖。那麼，像 Triton 這樣的 eDSL 是否能做到恰到好處呢？它與 CUDA 相比又如何呢？

Triton：OpenAI 用於 GPU 程式設計的 Python eDSL

Triton 最初是哈佛大學菲利普・蒂萊（Philippe Tillet）的一個研究專案，在從事 OpenCL 相關工作多年後，於 2019 年首次發表（詳見我之前關於 OpenCL 的文章）。蒂萊加入 OpenAI 後，該專案獲得了巨大的發展動力，PyTorch 2 決定採用它，更是讓其影響力大增。

與通用人工智慧編譯器不同，Triton 在注重 Python 開發者易用性的同時，仍允許進行深度最佳化。它在高階簡潔性和低階控制權之間取得了平衡，為開發者提供了足夠的靈活性來微調效能，而不會讓他們陷入 CUDA 的複雜性中。

讓我們來探究一下 Triton 如此實用的原因。

以塊為中心的程式設計模型

傳統的 GPU 程式設計要求開發者從單個執行緒的角度思考問題，手動管理同步和複雜的索引。Triton 透過在塊級別進行操作簡化了這一過程，因為 GPU 本身就是以塊為單位處理工作的，這樣就消除了不必要的底層協調工作：

這種模型抽象掉了執行緒管理，簡化了基本索引，同時也讓利用張量核心（GPU 中負責大部分浮點運算的專用硬體）變得更加容易：

在 CUDA 中需要幾十行復雜程式碼才能實現的功能，在 Triton 中只需一個函式呼叫，同時還能實現高效能。Triton 會自動處理資料佈局轉換和特定硬體的最佳化。

簡化的最佳化

CUDA 最令人頭疼的方面之一是處理多維資料時複雜的索引計算。Triton 極大地簡化了這一過程：

這些陣列操作類似於 NumPy，但會編譯成高效的 GPU 程式碼，且沒有執行時開銷。

Triton 還包括編譯器驅動的最佳化（如向量化），並支援簡化的雙緩衝和軟體流水線技術，這些技術可以使記憶體傳輸與計算重疊進行。在 CUDA 中，使用這些技術需要深入瞭解 GPU 知識；而在 Triton 中，非專業人員也能輕鬆使用這些技術。如需深入瞭解，OpenAI 提供了詳細的教程。

Triton 使 GPU 程式設計變得更加容易上手，但這種易用性也有代價。讓我們來看看它面臨的一些關鍵挑戰。

Triton 的不足之處

Triton 在某些情況下應用廣泛且非常成功（例如，研究前沿模型訓練的研究人員和特定的專業應用場景）。然而，它並沒有在所有應用中得到廣泛採用，特別是在對效率要求極高的人工智慧推理場景中，Triton 並不適用。此外，儘管多年前行業領導者曾做出預測，但 Triton 既沒有統一生態系統，也未能挑戰 CUDA 的主導地位。讓我們深入瞭解一下，除了所有 eDSL 都存在的普遍限制（前面已描述）之外，Triton 還面臨哪些挑戰。

與 CUDA C++ 相比，GPU 效能和總體擁有成本（TCO）顯著下降

Triton 為了提高開發效率而犧牲了效能（正如其建立者所解釋的那樣）。雖然這使得編寫 GPU 程式碼變得更加容易，但也導致 Triton 無法實現最佳效率。效能下降的幅度各不相同，但在當今主導人工智慧計算的英偉達 H100 上，效能損失 20% 是很常見的情況。

問題出在哪裡呢？編譯器的最佳化效果比不上熟練的 CUDA 開發者，尤其是對於如今先進的 GPU。在我數十年構建編譯器的過程中，從未見過 “足夠智慧的編譯器” 這種說法真正實現過！這就是為什麼包括 DeepSeek 在內的領先人工智慧實驗室，在處理高要求的工作負載時，仍然依賴 CUDA 而不是 Triton：在生成式人工智慧領域，20% 的效能差異是無法接受的；在大規模應用中，這意味著雲服務賬單會從 10 億美元增加到 8 億美元！

管理問題：OpenAI 的控制和關注點

Triton 是開源的，但它的發展路線圖由 OpenAI 掌控。這就產生了問題，因為 OpenAI 與其他前沿模型實驗室直接競爭，這引發了一個問題：它會優先考慮更廣泛的人工智慧社群的需求，還是隻關注自身的需求呢？

許多工程師都抱怨很難為 Triton 貢獻改進內容，尤其是當這些更改與 OpenAI 的內部優先順序不一致時。一個常見的抱怨是，對替代硬體的支援遠遠落後，因為 OpenAI 沒有動力為自己不使用的加速器進行最佳化。Triton 的開發團隊也承認，“對新使用者的支援幾乎不存在”，而且他們沒有精力滿足社群的需求。

工具和偵錯程式支援不足

CUDA 雖然複雜，但它擁有成熟的工具生態系統，如 Nsight Compute、分析器 API 和記憶體偵錯程式，這些工具能幫助開發者深入瞭解效能瓶頸。Triton 無法與這些工具協同工作。從設計上看，eDSL 旨在抽象掉底層細節。因此，當出現問題時，開發者無法確定問題的根源，只能猜測編譯器做了什麼。儘管 Triton 的程式設計模型更簡單，但這種缺乏可觀測性的問題使得在 Triton 中進行效能除錯比在 CUDA 中更具挑戰性

GPU 可移植性，但缺乏效能可移植性和通用性

用 Triton 編寫的 GPU 程式碼，如果是為某一特定 GPU 編寫的，執行起來 “相當快”，但在不同型別的 GPU 上，即使是英偉達的不同硬體，程式碼執行速度也會變慢。例如，為 A100 最佳化的 Triton 程式碼在 H100 上的效能往往較差，因為更新的架構需要不同的程式碼結構才能達到 80% 的效能，而 Triton 並沒有對流水線和非同步記憶體傳輸等進行抽象。

Triton 核心需要針對新一代 NVIDIA 硬體進行重寫才能釋放其效能。

遷移到 AMD GPU 上的情況更糟。雖然 Triton 在技術上支援 AMD 硬體，但在效能和功能對等方面遠遠落後於英偉達，使得跨廠商的可移植性難以實現。對於非 GPU 人工智慧加速器（如 TPU、Groq 晶片或 Cerebras 晶圓）來說，情況更糟。這些架構不遵循 Triton 所假設的單指令多執行緒（SIMT）執行模型，這會導致效能嚴重下降，或者需要大量的變通方法，使得這種方法變得事倍功半。

最終，“一次編寫，隨處執行” 的承諾通常變成了 “一次編寫，隨處執行，但在替代平臺上效能會大幅下降”。

Triton 表現如何？

在我們之前的文章中，我們開始列出對人工智慧程式設計系統的期望。按照這些期望來衡量，Triton 有幾個顯著的優勢，但也面臨一些挑戰：

“提供參考實現”：Triton 提供了完整的實現，而不僅僅是規範，還有實際示例和教程。👍
“擁有強大的領導力和願景”：Triton 在 OpenAI 的領導下有明確的方向，但優先考慮的是 OpenAI 的需求，而非更廣泛的社群需求。長期的管理問題仍然令人擔憂，特別是對於競爭的人工智慧實驗室來說。👍👎
“在行業領先企業的硬體上實現頂級效能”：Triton 在英偉達硬體上執行良好，但與最佳化後的 CUDA 相比，通常存在約 20% 的效能差距。它在支援像 FP8 和 TMA 這樣的最新硬體特性方面也存在困難。👎
“快速發展”：Triton 已經適應了一些生成式人工智慧的需求，但在支援前沿硬體特性方面仍有滯後。其發展速度取決於 OpenAI 的內部優先順序，而非行業需求。👎
“贏得開發者的喜愛”：Triton 提供了簡潔的、基於 Python 的程式設計模型，許多開發者認為它直觀且高效。它與 PyTorch 2.0 的整合擴大了其應用範圍。👍👍👍
“建立開放的社群”：雖然 Triton 是開源的，但它的社群受到 OpenAI 對路線圖控制的限制。外部組織的貢獻面臨重大障礙。👎
“避免碎片化”：Triton 本身針對英偉達 GPU 是統一的 👍，但其他硬體供應商對它進行了廣泛的分叉，不同版本存在不同的限制和權衡。👎
“實現完全可程式設計性”：Triton 在標準操作方面提供了良好的可程式設計性 👍，但無法訪問 / 控制所有硬體特性，尤其是最新加速器的功能。👎
“應對人工智慧的複雜性”：Triton 能夠高效處理常見模式，簡化了開發過程 👍。但它不支援自動融合，無法解決指數級增長的複雜性問題。👎
“支援大規模應用”：Triton 專注於單裝置核心，缺乏對多 GPU 或多節點擴充套件的內建支援，但它與 PyTorch 的整合很好地解決了這個問題。👍

總體而言，很明顯 Triton 是人工智慧開發生態系統中非常有價值的一部分，尤其是在針對英偉達 GPU 進行開發時。話雖如此，雖然 Triton 因其與 PyTorch 的整合而成為最知名的 eDSL，但其他專案，如 Pallas、CUTLASS Python 和 cuTile，正在探索在開發效率、效能和硬體支援之間進行不同的權衡。這些替代方案都基於類似的理念，但在解決 GPU 可程式設計性問題上採取了獨特的方法。

其他 Python eDSL：Pallas、CUTLASS Python、cuTile 等

Python eDSL 的目的並非追求極致效能，而是讓編譯器開發者更容易將產品推向市場。因此，這類工具眾多，Triton 只是其中最知名的。以下是一些常被問到的工具（免責宣告：我沒有直接使用過這些工具）。

谷歌 Pallas

谷歌 Pallas 是 JAX 的一個子專案，旨在支援自定義操作，特別是針對 TPU。它深受 Triton 的啟發，但與提供高階、使用者友好的 API 不同，它更多地暴露了底層編譯器細節。

從外部來看，Pallas 功能強大但使用難度較大，需要深入瞭解 TPU 硬體和編譯器內部原理。它的文件中強調了許多潛在的風險，很明顯這是一個面向具有底層知識的專家的工具。因此，它在谷歌之外的應用範圍有限。

CUTLASS Python 和cuTile

在GTC 2025 大會上，NVIDIA 宣佈了兩款新的 Python eDSL：CUTLASS Python和cuTile。目前這兩款產品尚未提供下載，但以下是一些初步印象：

CUTLASS Python –本次 GTC 演講中介紹的CUTLASS Python 似乎深受 Google Pallas 的啟發。它公開了底層編譯器細節，需要深厚的硬體知識，並且沒有 CUDA 開發人員所依賴的工具或偵錯程式。它首先在 Blackwell 上釋出，我懷疑 NVIDIA 是否會將其開源或支援其他硬體供應商。我也很好奇 Python 缺乏靜態型別，在編寫此類底層系統程式碼方面效果如何。
cuTile – 這款產品在 X （示例）上被廣泛轉發，但除了幾張幻燈片外，關於其上市日期和技術細節一無所知。它似乎被定位為 Triton 的專有替代品。NVIDIA 承認cuTile 比 TRT-LLM 慢約 15%。鑑於 NVIDIA 專注於峰值效能，目前尚不清楚它是否會使用 cuTile 構建自己的 CUDA 庫。如果它正式上市，那麼NVIDIA 內部的真正採用將是真正的考驗。

這些 eDSL 只是 NVIDIA 龐大的 Python GPU 生態系統的一部分。在GTC 2025 大會上，NVIDIA 表示：“沒有單一的工具——你需要根據工作選擇合適的工具。” NVIDIA 甚至舉辦了一場名為“用 Python 編寫 CUDA 核心的 1001 種方法”的會議——光是想想如何選擇正確的路徑就感覺像是一場噩夢。

NVIDIA 表示：“沒有任何單一工具能夠適用於所有應用程式。”（來源：NVIDIA GTC 2025，CUDA：新功能及未來）

作為一名開發者，我認為幾十個帶有微妙權衡的選項對我沒有幫助。我們需要更少、更高效地使用工具，而不是一個不斷增加的選擇清單。NVIDIA 正在分裂其自身的開發者生態系統。

MLIR：AI 編譯器的統一未來？

在我於 2017 年和 2018 年致力於擴充套件 Google TPU 的過程中，我發現了一種模式：第一代 AI 框架（例如 TensorFlow 和 PyTorch）缺乏可擴充套件性，而第二代 AI 編譯器（例如XLA）則犧牲了靈活性。為了打破這種迴圈，我帶領團隊構建了全新的MLIR 編譯器框架——一個模組化、可擴充套件的編譯器框架，旨在支援 AI 快速發展的硬體格局。

它成功了嗎？MLIR 推動了整個行業的突破——Triton 、cuTile 等Python DSL都建立在其之上，重新定義了 GPU 程式設計。但與之前的TVM 和 XLA一樣，MLIR 也面臨著治理挑戰、碎片化以及企業利益衝突。真正統一的AI 編譯器堆疊的願景似乎仍然遙不可及，幾十年來一直困擾著這個行業的權力鬥爭依然存在。

碎片化似乎不可避免，抵抗也徒勞無功。統一的編譯器技術真的能幫助人工智慧計算民主化嗎？

MLIR 編譯器基礎設施怎麼樣？

到 2018 年，人工智慧軟體出現了系統碎片化問題。TensorFlow、PyTorch、JAX、Glow、ONNX、TensorFlow-Lite、XLA、TVM，這樣的框架名單越來越長，每個框架都構建了自己錯綜複雜的 “人工智慧圖”，其中包含不同的 “操作（ops）”。整個生態系統分裂成一個個孤島，每個都競相針對不同硬體進行最佳化，只是在細微差異中重複發明相同的概念。複雜性呈爆炸式增長，必須有所改變。

當時，我正在協助谷歌擴充套件 TPU（以及其他一些內部專用積體電路），以支援 TensorFlow。很明顯，我們不能為每個專案都從頭開始重新構建編譯器基礎設施，我們需要一個更好的基礎。幸運的是，我有多年構建 LLVM 的經驗，而且我的上司是傑夫・迪恩（Jeff Dean）。傑夫是一位傳奇工程師，本身也是編譯器領域的博士，他也看到了同樣的問題。

在一次一對一的交談中，傑夫大概是這麼說的：“嘿，克里斯，我也覺得我們存在編譯器方面的問題。你為什麼不構建一個新的編譯器來整頓這一混亂局面呢？”

於是，MLIR 應運而生，它是一個模組化、可擴充套件的編譯器基礎設施，旨在為這場混亂帶來秩序。它提供了一個能夠跨硬體平臺、軟體框架，以及滿足機器學習快速發展需求的基礎。它的目標是統一這些系統，並提供一個能協調眾多不同硬體製造商計算資源的技術平臺。

但實現統一併非易事。這個原本的技術專案很快演變成了一個戰場：開源治理、企業競爭以及相互衝突的願景交織在一起。這本可以是一場簡單的工程勝利，卻變得複雜得多。

如今，MLIR 幾乎嵌入了每一個主要的人工智慧技術棧中，包括 CUDA，但它仍未實現人工智慧計算民主化的夢想。

這就是 MLIR 的故事：它如何誕生、帶來了哪些改變，以及一路走來的權力鬥爭。

MLIR 的起源故事

現代人工智慧系統依賴於複雜的操作圖，如矩陣乘法、卷積、注意力機制等，所有這些都串聯成計算流水線。正如第 6 部分所討論的，要高效地最佳化和轉換這些操作，需要一個堅實的編譯器基礎。

但在 2018 年，大多數人工智慧框架都在重新發明編譯器技術，而且往往做得並不好。許多框架都缺失了像靜態單賦值（SSA）這樣的基本技術。每個框架都有自己臨時拼湊的圖系統，用一些無法擴充套件的方法組合在一起。結果就是一個碎片化、低效率的生態系統，充斥著大量重複內容。

我知道我們需要一種更好的方法，所以我召集了四位志同道合的同事，在谷歌的一個小房間裡展開討論。我們花了好幾天時間在白板上進行頭腦風暴，勾勒出一個適用於人工智慧的現代、可擴充套件的編譯器基礎設施可能的樣子。我們的核心問題是：我們能否構建一種統一的表示形式，以支援每一個人工智慧框架、每一個硬體後端，以及從代數簡化到多面體分析等各種最佳化？

大約 2018 年：我和四位同事聚集在白板前，集思廣益，構思下一代編譯器

我們提出的突破性想法如今被稱為 MLIR 方言（MLIR dialects），這是一種將特定領域的問題與編譯器核心基礎設施清晰分離的方法。與強制每個使用者採用僵化、一刀切的中間表示形式（如 LLVM 和其他編譯器）不同，MLIR 允許編譯器工程師定義自己的表示形式，包括自定義操作、型別和語義，以適應各自的領域。

在當時，這與大多數編譯器的構建方式截然不同。傳統的基礎設施是一體化的，將所有前端和處理過程都納入單一、僵化的模型中。但 MLIR 從一開始就接納異構性，它允許不同層次的抽象共存、轉換，並實現無縫互操作。

這種模組化是關鍵所在。MLIR 為開發者提供了一個共享基礎，無論他們處理的是 TensorFlow 圖、PyTorch 中間表示（IR），還是自定義 TPU 操作，都無需反覆重新實現相同的基礎設施。這使得構建專用編譯器無需從頭開始，並且實現了人工智慧編譯器棧的真正可組合性。

MLIR 不僅僅是又一個編譯器，它是一個用於構建眾多編譯器的框架。

MLIR 在谷歌內部及外部的發展

MLIR 最初是谷歌大腦（Google Brain）內部的一個研究專案，一個專注的團隊試圖重新思考人工智慧編譯器應有的工作方式。我的團隊專注於基礎工作：設計中間表示（IR）、實現轉換，並驗證核心想法是否可行。與此同時，谷歌的開放文化和 MLIR 的模組化設計，使得其他人很容易接觸並嘗試使用它。沒過多久，MLIR 就開始獨立發展起來。

在谷歌內部，致力於定製專用積體電路（ASIC）的團隊看到了它的潛力。MLIR 為他們提供了一種結構化的方式來表達和最佳化特定硬體的操作。專注於應用的團隊開始將其用於移動人工智慧領域，TensorFlow 團隊則將 MLIR 引入了 TensorFlow Lite。甚至一些對 MLIR 的靈活性感興趣的獨立研究人員，也開始用它來為新穎的編譯器技術製作原型。

隨之而來的是各種應用場景的小爆發。每一個新應用都帶來了新的反饋，而那時我們往往還處於深入迭代階段。關鍵的是，這驗證了我們以方言為優先的方法，證明了 MLIR 可以在從邊緣裝置到資料中心加速器等截然不同的領域中進行擴充套件。最終，我們達到了一個臨界點：MLIR 成為了眾多專案中至關重要的基礎設施。

我們很多人都希望 MLIR 能充分發揮潛力，超越谷歌內部的應用場景。

MLIR 社群內著名的 meme，內容大概為 MLIR 能解決很多問題

（圖片來源：Mehdi Amini）

所以我們邁出了重要一步：將 MLIR 開源，並貢獻給 LLVM 基金會，讓整個行業都能使用。為了推動其被採用，我們定期組織 “開放設計會議”，外部貢獻者可以參與 MLIR 的演進，並從背後的工程投入中受益。這種開放協作促進了 MLIR 在全球範圍內的發展勢頭，尤其受到渴望擁有現代基礎設施的編譯器開發者的歡迎。

在這一推動下，MLIR 迅速發展。如今，它是許多重要人工智慧專案的基礎，如 OpenXLA、Triton，甚至 CUDA 的部分內容也基於它。它還為量子計算、硬體設計（透過 CIRCT ）等許多其他領域的編譯器提供支援。從新興的創業公司到超大規模企業，全球眾多公司都開始使用 MLIR 構建下一代編譯器。MLIR 早期的發展和成功，很大程度上要歸功於谷歌的領導和開放的方式，我認為這一點在行業中仍未得到充分認可。

然而，儘管取得了這些成功，宏偉的願景仍然遙不可及。生態系統依舊碎片化，CUDA 仍然佔據主導地位。真正實現人工智慧計算民主化的夢想，依然只是一個夢想。

那麼，發生了什麼呢？為什麼 MLIR 在技術上取得了成功，卻未能打破 CUDA 的壟斷呢？

要理解這一點，我們需要探討影響 MLIR 發展的政治因素、權力鬥爭和妥協。

競相打造端到端人工智慧解決方案

從一開始，MLIR 就被設想為通用編譯器基礎設施，這是一個旨在支援特定領域編譯器的框架。其目標是實現靈活性和模組化，MLIR 從來都不僅僅是關於機器學習的。事實上，MLIR 中的 “ML” 代表的並非機器學習（沒錯，編譯器相關的笑話就是這麼專業！）。然而，人工智慧領域渴望得到更多，他們想要一個端到端的編譯器，能夠將 TensorFlow 或 PyTorch 模型順利對映到各種硬體上。

打造首個基於 MLIR 的端到端 AI 解決方案的競賽已經開始

於是，各方開始競相在 MLIR 的基礎上構建端到端的人工智慧解決方案。包括 OpenXLA、TritonLang 等在內的其他專案，都將 MLIR 作為實現細節，以強化自身的技術棧。這就引發了一個問題：每個人都想成為下一代人工智慧技術棧，那麼誰會率先成功呢？

這場競賽就此開始。多年後，我們得到了一個令人遺憾的答案：沒有人成功。

MLIR 人工智慧方言的激增

將 MLIR 貢獻給 LLVM 基金會極大地推動了它的應用。這為企業提供了一個共享基礎，也讓編譯器工程師有機會在所在組織中展現自己的影響力。

LLVM 基金會負責監督和處理法律事務，但不干預技術設計，這方面由社群自行組織。

以谷歌為首，整個行業的工程師們開始貢獻與人工智慧相關的方言，包括算術（arith）、線性代數（linalg）和張量（tensor）等，為構建現代人工智慧編譯器棧提供了一些有用的部分。最初是谷歌的研究團隊率先接觸到 MLIR 並進行貢獻，但這開創了一個先例：許多 “可能有用” 的貢獻被納入上游程式碼庫，而管理機制有限，專案負責人很難從原則上拒絕。

不幸的是，這種方言的激增在 MLIR 設計的早期就發生了，而且其中許多設計決策並不符合生成式人工智慧不斷發展的需求。例如，早期的很多工作都圍繞改進 TensorFlow 和構建 OpenXLA 展開，所以這些方言在設計時並沒有將對 PyTorch 和生成式人工智慧的一流支援納入考慮（正如我們在本系列前面所討論的）。

雖然許多努力都實現了最初的目標，但世界已經發生了變化。

競爭性 “競合” 帶來的問題

由於各種原因，幾乎所有早期參與 MLIR 開發的人員（包括我自己）都離開了谷歌，其中很多人去了硬體公司。MLIR 知識的傳播本是一個積極成果，意味著這項技術會得到更廣泛的應用，但它也帶來了新的挑戰。

問題在於，MLIR 的成功使得其核心開發者分散到了整個行業。曾經的盟友和同事如今在相互競爭的公司工作，他們開始在共享的 MLIR 方言基礎上構建專有的人工智慧技術棧。原本的開放協作很快與商業競爭產生了衝突。由於缺乏中央協調，這些團隊之間的溝通逐漸中斷。相互衝突的優先順序引發了緊張局勢，MLIR 曾經統一的願景開始支離破碎。

MLIR 的身份危機：機器學習解決方案還是編譯器框架？

MLIR 如今面臨著身份危機：它是適用於任何領域的通用編譯器框架，還是一個人工智慧解決方案呢？如今，作為通用的、可複用的基礎設施，MLIR 的地位無可比擬，它支援從硬體設計到量子計算等各個領域。另一方面，內建的與人工智慧相關的方言存在爭議且並不完善，但對許多開源和專有的下游技術棧來說仍至關重要。

這感覺就像 OpenCL 的情況再次上演：沒有參考技術棧、硬體供應商相互競爭，而且競爭環境表面上一團和氣，就像當年的 Khronos 委員會一樣。

新的希望：改進 MLIR 治理

這些緊張局勢已經持續了多年，在更廣泛的 LLVM 和 MLIR 社群中都能深切感受到。

幸運的是，出現了新的希望：LLVM 社群秉持精英管理的理念，在協調工程師方面有著良好的記錄，即便這些工程師所在的公司在市場上處於競爭關係。MLIR 社群中有許多優秀的工程師，他們多年來全身心投入到專案改進中，努力應對這些挑戰，並且現在已經取得了一些進展！

MLIR 現在有了一個新的領域團隊來指導其發展，同時還有新的組織結構、章程和管理小組。章程定義了不同的領域小組：MLIR 核心（與領域無關的基礎設施）和各種方言（如與機器學習相關的部分）。我非常感謝每一位花時間改進 MLIR、解決這些問題的人，這樣的工作對構建這個生態系統的所有人以及下游使用者都有著深遠的影響。

如果我能許一個願望，我希望 “MLIR” 能明確指代與領域無關的編譯器基礎設施，而這些方言能有一個新的、不同的名字（比如 “TensorIR”？）。這樣可以減少對 “MLIR” 實際含義的混淆！

從 MLIR 中吸取的教訓

我從 MLIR 專案中得到的最大教訓是，在核心基礎尚未完全穩固時過早進行擴充套件，可能會引發長期問題。早期的濃厚興趣和大量貢獻令人興奮，但這也意味著許多設計決策是並行做出的，缺乏明確的指導和協調。我們快速完成了很多工作，卻犧牲了在每個層面做到極致的機會，結果陷入了海勒姆定律（Hyrum's Law）的困境。

這也讓我再次體會到在其他專案中得到的管理經驗：當有太多聰明的工程師朝著不同方向快速前進時，後期很難掌控專案方向，即便專案有著設計精美的中間表示（IR）。就 MLIR 而言，雖然我在 LLVM/MLIR 社群仍有一定影響力，但我意識到這種影響力無法與僱主提供的薪酬相抗衡，薪酬會促使貢獻者將自己的工作納入程式碼庫，以便繼續進行下一個錯誤修復或專案。

另一個教訓與有宏大目標的基礎設施專案有關。我對 MLIR 的目標是統一編譯器的實現，它的成功超出了我的預期。但我也鼓勵並推動其他人追求更高目標，大家都樂觀地認為社群主導的專案能夠推動世界前進。但結果並不理想，這讓我更加深刻地認識到，在我參與構建的其他具有行業影響力的專案（LLVM、Clang、Swift 和 “MLIR 核心”）中得到的一個教訓：小團隊最擅長凝聚在一個成功願景下並推動其實現。只有在專案的定位穩固確立之後，再向更廣泛的社群擴展才有意義。

MLIR 有許多方言，但很多都有爭議或不完整。

按照我此前的慣例，我將根據對下一代人工智慧解決方案的期望特性清單，來評估 MLIR 的人工智慧方言。以下是我的看法：

“提供參考實現”：雖然 MLIR 在通用編譯器基礎設施方面表現出色，但它並沒有提供一個可以直接用於人工智慧工作負載的端到端解決方案，只是提供了一些需要 “自行組裝” 的有用構建模組。👎
“擁有強大的領導力和願景”：早期，MLIR 的人工智慧方言缺乏明確的領導，貢獻往往由個人或不同團隊推動，導致方向分散，核心定位也不清晰。雖然現在有了強有力的領導趨勢，但問題仍未解決。👎
“在行業領先企業的硬體上實現頂級效能”：雖然 MLIR 核心為最佳化提供了堅實的基礎，但據我所知，基於 MLIR 人工智慧方言構建的下游實現，在英偉達 GPU 上執行生成式人工智慧大語言模型（LLMs）時，效能都無法與 CUDA 相媲美（包括 Triton 或 cuTile，它們的效能會比 CUDA 低 15 – 20%）。👎
“快速發展”：MLIR 的發展速度令人矚目，來自廣泛社群的貢獻源源不斷。其靈活的設計使其能夠快速適應新的應用場景和領域。👍
“贏得開發者的喜愛”：MLIR 確實贏得了編譯器工程師和系統研究人員的青睞，為構建定製編譯器提供了靈活而強大的工具包。👍 然而，人工智慧開發者，尤其是機器學習領域的開發者，認為學習曲線陡峭，而且它與現有機器學習框架的整合也不夠無縫。👎
“建立開放的社群”：MLIR 建立了一個真正開放且蓬勃發展的社群。定期的設計會議、開放的貢獻機制以及跨公司的合作，幫助它獲得了眾多行業參與者的廣泛採用和投入。👍👍
“避免碎片化”：這是 MLIR 最薄弱的環節。早期方言和貢獻的激增，再加上缺乏強有力的中央管理，導致下游系統出現碎片化。由於相互競爭的專案走向不同方向，統一人工智慧編譯方法的願景難以維持。👎👎👎

歸根結底，正如我們之前討論的，用這種方式來衡量 “MLIR 核心” 作為編譯器構建工具包是極不公平的，MLIR 被數十個系統廣泛使用，它無疑實現了最初的使命。MLIR 人工智慧方言的成功，最好透過它對無數使用它的下游人工智慧實現的影響來衡量，只是我不確定該如何衡量。

硬體公司為何難以開發人工智慧軟體？

在本系列文章的這個階段，一種模式逐漸顯現：無論是 OpenCL/OneAPI、TVM/XLA、MLIR，還是其他一些出發點良好的專案，我們看到了眾多構建統一人工智慧基礎設施的有力嘗試，但沒有一個能提供讓開發者滿意的解決方案。專案走向碎片化，承諾落空，使用替代硬體的使用者手中的工具總是不盡如人意。

殘酷的事實是：只有英偉達真正解決了這個問題。CUDA 不僅僅是基礎設施，它是一種策略，背後有緊密的垂直整合、一線的應用工程師，以及對實際效能的不懈追求。它既不開放，也不完美，但對英偉達來說卻非常有效，即便 “創新者的困境” 在英偉達總部聖克拉拉（Santa Clara）依然存在。

那麼，為什麼其他硬體公司做不到呢？為什麼這個行業中最聰明的人，在數十億美元資金的支援下，開發出的軟體卻沒人想用呢？當你與一個根基深厚、垂直整合的行業領導者競爭時，局勢對你極為不利，而且行業和企業內部的激勵機制也影響著最終結果。

“告訴我激勵機制，我就能告訴你結果。”—— 查理・芒格（Charlie Munger）

我們將在下一章節深入探討這個問題。在此之前，願每一種方言都能規範發展！

為什麼硬體公司難以構建人工智慧軟體？

自 2023 年 ChatGPT 推出以來，生成式人工智慧重塑了科技行業，但 GPU 並非一夜之間突然出現。十多年來，硬體公司在人工智慧晶片上投入了數十億美元，研發出幾十種架構，耗費了無數的工程工時。然而，英偉達依舊佔據著主導地位。

這是為什麼呢？

因為 CUDA 不僅僅是一個軟體開發工具包（SDK）。它是一座旨在讓你深陷其中的開發者體驗堡壘，也是一種精心策劃的商業策略，讓競爭對手永遠落後兩年。它並不招人喜歡，也不夠優雅。但它行之有效，其他產品難以望其項背。

在本系列文章中，我們追溯了那些充滿希望的替代方案的興衰歷程，如 OpenCL 和 SyCL、TVM 和 XLA、Triton、MLIR 等等。模式很明顯：技術抱負遠大，早期令人興奮，但最終走向碎片化。與此同時，CUDA 的護城河卻越來越深。

讓硬體行業領導者夜不能寐的萬億美元難題是：鑑於巨大的機遇，以及開發者對替代方案的迫切需求，為什麼我們無法突破困境呢？

答案並非是硬體公司無能。這些公司裡不乏才華橫溢的工程師和經驗豐富的高管。問題出在結構上：激勵機制不合理、優先事項相互衝突，而且嚴重低估了在這個領域進行軟體開發所需的投入。在這個行業，你需要的不只是晶片，而是一個平臺。構建平臺意味著要做出艱難、不受歡迎的長期賭注，而且還不能保證會有人買賬。

在本文中，我們將揭示硬體公司所處的無形約束矩陣，這個系統從設計上就使得構建具有競爭力的人工智慧軟體變得幾乎不可能。

我在硬體 / 軟體協同設計領域的職業生涯

我熱衷於創新硬體領域，閱讀各類刊物，只要是關於塑造未來的晶片、技術棧和系統的內容，我都不放過。幾十年來，我痴迷於硬體 / 軟體協同設計的精妙之處：當協同設計發揮作用時，就像變魔術一樣神奇；而當它失效時…… 這正是本系列文章探討的主題。

我從中也收穫了一些經驗：

我在科技行業的第一份真正工作是在英特爾，為奔騰 MMX（第一款支援 SIMD 指令的個人電腦處理器）最佳化首發遊戲。在那裡，我學到了關鍵一課：沒有經過最佳化的軟體，即便晶片效能再卓越，也無法充分發揮其速度優勢。這段早期對硬體 / 軟體相互作用的體驗讓我印象深刻。
在蘋果公司，我參與構建了編譯器基礎設施，助力蘋果過渡到自研晶片。蘋果讓我明白，真正的硬體 / 軟體整合需要卓越的組織紀律。蘋果之所以成功，是因為各個團隊有著統一的願景，沒有任何業務部門能夠凌駕其上，而不是僅僅滿足於妥協。
在谷歌，我與硬體和人工智慧研究團隊共同擴充套件 TPU 軟體棧。憑藉看似無限的資源和緊密的硬體 / 軟體協同設計，我們利用對工作負載的瞭解，充分發揮了專用晶片的強大效能，打造出一艘令人驚歎的定製人工智慧競賽遊艇。
在 SiFive 公司，我完全轉換了視角，在這家硬體公司領導工程團隊的經歷，讓我深刻認識到硬體商業模式和組織價值觀的殘酷現實。

從這些經歷中，有一點變得很清晰：軟體團隊和硬體團隊使用不同的 “語言”，工作節奏不同，衡量成功的標準也不同。但還有更深層次的因素在起作用，我逐漸發現了一個無形的約束矩陣，它影響著硬體公司對待軟體的方式，也解釋了為什麼軟體團隊在開發人工智慧軟體時尤其艱難。

在深入探討之前，讓我們先站在硬體公司高管的角度思考，這樣就能逐漸看清這個約束矩陣。

人工智慧硬體公司的思維方式

硬體公司並不缺乏聰明才智。問題不在於智商，而在於思維模式。

如今，人們對人工智慧晶片的架構要素已經有了充分的瞭解：脈動陣列、張量核心、混合精度計算、特殊的記憶體層級等。製造晶片仍然極具挑戰性，但它已不再是取得成功的瓶頸。真正的挑戰在於讓別人使用你的晶片，而這意味著需要配套軟體。

生成式人工智慧工作負載的發展速度極快。硬體公司不僅要著眼於當下的熱門需求，更要為開發者未來兩年的需求進行設計。然而，他們仍困在與現實脫節的思維模式中，就像試圖用陸地文化在開闊水域中競賽一樣。

有趣的事實：LLVM 的吉祥物是一隻飛龍，有點像前面沒有爪子的龍。

在 CPU 時代，軟體相對簡單：為 LLVM 構建一個後端，你的晶片就能融入一個生態系統，Linux 系統、瀏覽器、編譯後的應用程式等都能適配。但人工智慧領域沒有這樣的便利條件，既沒有統一的編譯器，也沒有通用的作業系統。你要為一個混亂且變化迅速的技術棧開發軟體，包括 PyTorch、vLLM，以及本週流行的各種智慧體框架，而你的客戶卻在使用英偉達的工具。你需要讓這些軟體在人工智慧工程師眼中就像原生應用一樣易用，而這些工程師既不瞭解你的晶片，也不想去了解。

儘管如此，晶片仍然是硬體公司的核心產品，利潤表將這一點體現得淋漓盡致。軟體、文件、工具、社群建設呢？這些都被視為開銷。這是約束矩陣的第一個限制：從結構上來說，硬體公司無法將軟體生態系統視為一個獨立的產品。高管們往往優先最佳化資本支出、物料清單成本和晶片流片時間。軟體雖然也有預算，但總是不夠，尤其是隨著人工智慧軟體需求的不斷增加。結果就形成了一種以演示為驅動的文化：推出晶片，編寫一些核心，執行幾個基準測試，再製作一個華麗的主題演講來證明晶片的浮點運算效能。

結果我們再熟悉不過了：晶片在技術上令人印象深刻，但配套軟體卻無人問津。軟體團隊承諾在下一個週期進行改進，可他們上次也是這麼說的。這不是個人的失敗，而是整個行業圍繞晶片而非生態系統構建所導致的激勵機制和資源配置的系統性失調。

為什麼生成式人工智慧軟體如此難以開發且成本高昂？

開發生成式人工智慧軟體不僅困難重重，而且就像在不斷移動的山坡上，逆著跑步機跑步一樣艱難。與其說這是一個工程挑戰，不如說是碎片化、不斷演進的研究和嚴苛期望共同構成的一場 “完美風暴”，而這些都是約束矩陣的組成部分。

碎片化的人工智慧研究創新帶來的困境

人工智慧工作負載並非一成不變，而是一個不斷變化的 “動物園”。這周流行 Transformer，下週可能就是擴散模型、混合專家模型（MoEs）或大語言模型智慧體。接著又會出現新的量化技巧、更好的最佳化器，或者某個研究團隊堅持要立即實現最高效能的晦澀運算元。

大家都知道，硬體創新是實現差異化的關鍵，但常常被忽視的是，每一項硬體創新都會隨著不斷變化的應用場景增加軟體的開發負擔。每一項硬體創新都要求軟體工程師深入理解它，同時還要緊跟快速發展的人工智慧研究，並知道如何將兩者結合起來。

結果就是，你不是在構建一個簡單的 “技術棧”，而是在構建一個模型 × 量化格式 × 批次大小 × 推理 / 訓練 × 雲端 / 邊緣 × 本週流行框架的交叉產物。

這種組合的複雜性呈爆炸式增長，這就是為什麼除了英偉達，其他公司都難以跟上節奏。最終，生態系統圖變得錯綜複雜，就像下面這樣：

相容性矩陣凸顯了 vLLM 的複雜性。資料來源： vLLM

你競爭的物件不只是 CUDA，而是整個行業

真正的問題不只是 CUDA，而是整個人工智慧生態系統都在為英偉達的硬體編寫軟體。每一個框架、學術論文和庫都是針對英偉達最新的張量核心進行最佳化的，每一項最佳化也都是先在英偉達的硬體上實現。這就是我們在第 3 部分探討過的惡性迴圈：CUDA 就像一個軟體引力阱，將整個行業的努力都吸引到英偉達的硬體上。

對於其他硬體來說，僅僅實現相容性是不夠的，你必須超越全球為英偉達晶片最佳化的開源團隊。首先，你的硬體要能 “執行” 工作負載，其次，效能還必須優於他們現有的硬體 + 軟體組合。

軟體團隊總是人手不足

無論你有多少軟體工程師，面對強大的競爭對手，都遠遠不夠。無論他們多麼才華橫溢、全力以赴，都難以與之抗衡。他們的收件箱裡滿是客戶的緊急問題、內部的功能需求，以及對基準測試結果的急切請求。他們疲於應對各種突發狀況，而沒有時間構建預防問題的工具。每一次重大成功都只是讓他們更清楚還有多少工作要做。

他們有很多想法，想要投資基礎設施建設、構建長期的抽象模型、明確公司的軟體理念。但他們無法做到，因為他們無法停下手中當前晶片的相關工作，為下一款晶片做準備。與此同時……

商業部門總是 “追逐大客戶”

當有大客戶帶著資金和特定需求出現時，商業部門往往會欣然接受。這些客戶手握話語權，追逐他們在短期內確實有意義。

但這也有高昂的代價：每爭取到一個大客戶，都會讓團隊離構建可擴充套件平臺的目標更遠。團隊沒有時間去制定一個可擴充套件的整體策略，而這種策略可能在未來吸引眾多小客戶。這樣一來，軟體團隊就被迫像諮詢公司一樣運作，而不是成為一個產品型公司。

一開始，這種情況可能並不明顯，但很快，工程師們就會採用一些臨時解決方案、進行程式碼分叉、部分整合，雖然能讓某一項功能變快，但卻會破壞其他五項功能。最終，軟體棧變成了一個充滿技術債務和內部特定知識的 “鬼屋”，難以除錯、擴充套件困難，而且幾乎沒有文件記錄 —— 誰有時間寫文件呢？要是理解這些程式碼的工程師離職了，又該怎麼辦呢？

在硬體競賽中取得領先的挑戰

這些問題並非個例，而是開發生成式人工智慧軟體面臨的普遍現實。這場競賽不是短跑，而是一場帆船賽：混亂、不可預測，受外部環境的影響和工程技術一樣大。大家都在同一片海域航行，但乘坐的船隻卻截然不同。

快艇：初創公司追求基準測試結果，而非通用性和易用性

初創公司處於生存模式，他們的目標是證明晶片可用、速度快，並且有人願意購買。這意味著選擇幾個基準測試工作負載，想盡辦法讓它們高效執行，哪怕使用一些技巧或非常規手段。通用性和易用性並不重要，唯一重要的是證明晶片在當下真實可用且具有競爭力。他們不是在構建軟體棧，而是在製作商業簡報。

定製競賽遊艇：專注單一晶片的公司構建垂直技術棧

大型科技公司（Mag7）和先進的初創公司採取了不同的策略。他們打造定製的 “TPU 競賽遊艇”，透過定製設計在特定競賽中獲勝。這些晶片可能速度很快且設計精良，但往往需要專業的團隊、操作手冊，甚至專屬的模型才能發揮作用。由於這些晶片突破了 GPU 的常規設計，它們必須從頭開始構建定製的軟體棧。

他們不得不掌控整個技術棧，結果呢？這給人工智慧工程師帶來了更多的碎片化問題。選擇其中一款晶片，可能意味著理論上的浮點運算效能更優且成本更低，但卻要犧牲英偉達生態系統帶來的發展動力。對這些公司來說，最有前景的策略是鎖定幾個大客戶，比如前沿實驗室或對浮點運算效能有需求、又不想支付英偉達 “專利費” 的主權雲服務提供商。

遠洋班輪：行業巨頭受限於傳統和規模

然後是行業巨頭，如英特爾、AMD、蘋果、高通等，這些公司擁有數十年的晶片研發經驗和龐大的產品組合，包括 CPU、GPU、NPU，甚至 FPGA，產品出貨量達數十億。但這種規模也帶來了問題：軟體團隊分散在眾多程式碼庫和優先事項中，精力分散。他們的客戶甚至都搞不清所有的軟體和版本，不知從何下手。

一種看似誘人的方法是透過翻譯器相容 CUDA，這樣能實現 “相容性”，但效能卻始終無法達到最佳。現代 CUDA 核心是針對英偉達 Hopper 架構的張量核心、張量記憶體加速器（TMA）和記憶體層級設計的，將這些核心翻譯適配到你的架構上，無法讓你的硬體脫穎而出。

遺憾的是，在這種規模下，最好的結果也不過像英特爾的 OneAPI 那樣：開放、可移植且由社群管理，但缺乏發展動力和靈魂。OneAPI 在生成式人工智慧領域沒有獲得關注，原因和 OpenCL 一樣：它是為上一代 GPU 工作負載設計的，而人工智慧發展太快，它根本跟不上。只有與時俱進，開放才有意義。

英偉達：主宰比賽的航空母艦

英偉達就像領航的航空母艦：龐大、協調有序，周圍還有補給船、戰鬥機和衛星通訊裝置支援。當其他公司還在為一款晶片的軟體開發苦苦掙扎時，英偉達已經向任何可能超越它的對手發起了挑戰。當其他公司還在為某個基準測試進行最佳化時，全世界都在為英偉達的產品進行最佳化，甚至外部環境都彷彿在配合它的發展。

如果你參與這場競賽，就會受到它的影響。問題不在於你是否在進步，而在於與它的差距是在縮小還是在擴大。

突破困境

在 “實現人工智慧計算的民主化” 這個系列文章中，我們已經剖析了行業現狀。CUDA 的主導地位並非偶然，它是持續投資、平臺控制和市場反饋迴圈的結果，而這些是其他公司難以複製的。其他公司在替代方案上也投入了大量資金：大型科技公司構建了垂直整合的技術棧，行業巨頭推出了開放平臺，充滿活力的初創公司也嘗試了創新方法，但都未能成功打破英偉達的壟斷。

但我們現在不再迷茫。我們已經看清了這個約束矩陣：這些因素是如何相互作用的，陷阱在哪裡，為什麼即使是最優秀的軟體團隊在硬體公司也難以取得突破。現在的問題不再是我們為什麼被困住，而是我們能否突破困境。