當前位置： 主页 > HK News 香港新聞 > 香港看世界 > 產業新聞 > 《如何打破CUDA壟斷？LLVM奠基人長文解讀》

2025-Jun-07

如果您希望可以時常見面，歡迎標星收藏哦~編者按：多年來，領先的人工智能公司一直堅稱，只有擁有龐大計算資源的公司才能推動前沿研究，這強化了這樣一種觀點：除非你擁有數十億美元的基礎設施投入，否則“不可能趕上”。但 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 eDSLTriton 最初是哈佛大學菲利普?蒂萊（Philippe Tillet）的一箇研究項目，在從事 OpenCL 相關工作多年後，於 2019 年首次發表（詳見我之前關於 OpenCL 的文章 ）。蒂萊加入 OpenAI 後，該項目獲得了巨大的發展動力，PyTorch 2 決定採用它，更是讓...

(請各位謹慎甄別內容，自擔風險。)