和TensorFlow一樣，英偉達CUDA的壟斷格局將會被打破？

十年來，機器學習軟體開發的模式發生了重大變化。許多框架如雨後春筍般湧現，但大多數都嚴重依賴英偉達的 CUDA，並在英偉達的 GPU 上以獲得最佳的性能。然而，隨著 PyTorch 2.0 和 OpenAI Triton 的到來，英偉達在這一領域的主導地位正在被打破。

Google早期在機器學習模型架構、訓練、模型最佳化方面都具有很大優勢，但現在卻難以充分發揮這些優勢。而在硬體方面，其他 AI 硬體公司很難削弱英偉達的統治地位。直到 PyTorch 2.0 和 OpenAI Triton 出現，機器學習模型的預設軟體堆疊將不再是英偉達的閉源 CUDA。

TensorFlow vs. PyTorch

類似的競爭出現在機器學習框架中。幾年前，框架生態系統相當分散，但 TensorFlow 是領跑者。表面看來，Google穩操機器學習框架產業，他們憑藉 TensorFlow 設計了 AI 應用特定加速器 TPU，從而獲得了先發優勢。

#然而現在看來，PyTorch 贏了，Google未能將其先發優勢轉化為新興ML 產業的主導地位。如今，Google在機器學習社群中似乎有些被孤立了，因為它沒有使用 PyTorch 和 GPU，而是使用自己的軟體堆疊和硬體。甚至，Google研發了第二個機器學習框架 ——JAX，直接與 TensorFlow 競爭，這是典型的「Google行為」。

有些人認為，由於大型語言模型的興起，特別是OpenAI 的大型語言模型和各種利用OpenAI API 構建的語言模型，谷歌在搜尋和自然語言處理方面的主導地位正在減弱。也許這種觀點過於悲觀，畢竟目前大多數模型的基礎架構仍是Google開發的 transformer。

那麼，為什麼 PyTorch 能大獲全勝？主要原因是相對於 TensorFlow，PyTorch 具有更高的靈活性和可用性。 PyTorch 與 TensorFlow 主要的不同之處在於使用 Eager 模式而非 Graph 模式。

Eager 模式可以說是標準的腳本執行方法，與普通的 Python 程式碼沒什麼兩樣。這使得調試和理解程式碼更加容易，因為使用者可以看到中間操作的結果，以及模型是如何運作的。

相反，Graph 模式分為兩個階段。第一階段代表要執行操作的計算圖，其中的節點代表操作或變量，而節點之間的邊表示它們之間的資料流。第二階段是延遲執行計算圖的最佳化版本。

這種兩階段的方法使得理解和偵錯程式碼更具挑戰性，因為在圖執行結束之前使用者無法看到發生了什麼。這類似於「解釋型」與「編譯型」語言，如 Python 與 C ，除錯 Python 更容易，因為它是解釋型語言。

雖然 TensorFlow 現在也預設使用 Eager 模式，但研究社群和大多數大型科技公司都選擇使用 PyTorch。

機器學習訓練元件

如果將機器學習模型訓練簡化為最簡單的形式，影響機器學習模型訓練的因素主要有兩點：

• 計算( FLOPS ) ：在每一層內運行密集矩陣乘法；
• 記憶體頻寬。

以前，影響機器學習訓練時間的主要因素是計算時間，等待系統執行矩陣乘法。隨著英偉達 GPU 的不斷發展，這很快就不再是主要問題了。

英偉達利用摩爾定律將 FLOPS 提高了多個數量級，但主要是架構變化 —— 張量核（tensor core）和更低精度的浮點數格式。相比之下，儲存方面沒有太大的變化。

2018 年，最先進的模型是BERT，英偉達V100 是最先進的GPU，那時矩陣乘法已經不再是提高模型性能的主要因素。之後，模型在參數數量上成長了 3 到 4 個數量級，而最快的 GPU 在 FLOPS 上成長了 1 個數量級。

即使在 2018 年，純計算綁定的工作負載也佔 FLOPS 的 99.8%，但僅佔運行時的 61%。與矩陣乘法相比，歸一化和逐點運算（pointwise ops）使用的 FLOPS 僅為矩陣乘法的 1/250 和 1/700，但它們消耗了近 40% 的模型運行時間。

記憶體牆

##隨著模型規模的不斷飆升，大型語言模型（LLM）僅用於模型權重的記憶體就需要100 GB 以上。百度和 Meta 部署的產品推薦網路需要數十 TB 的記憶體來儲存其海量嵌入表。大型模型訓練 / 推理中的大部分時間都沒有花在計算矩陣乘法上，而是在等待資料傳輸。顯然，問題在於為什麼架構師不將更多記憶體放在更靠近運算的位置，問題的答案也是可想而知的 —— 成本。

最近的共享記憶體池一般是同一晶片上的 SRAM。一些機器學習 ASIC 試圖利用巨大的 SRAM 池來保存模型權重。但即使是 Cerebras 的價值約 5000000 美元的晶圓級晶片也只有 40GB 的 SRAM。記憶體容量不足以容納 100B 參數模型的權重。

英偉達設計的晶片片上記憶體容量少很多 ——A100 有 40MB，H100 有 50MB。台積電 5 奈米晶片上的 1GB SRAM 需要約 200 平方毫米的矽，要實現相關的控制邏輯 / 結構，將需要超過 400 平方毫米的矽。鑑於 A100 GPU 的成本在 1 萬美元以上，而 H100 更是接近 2 萬美元，從經濟角度來看，這種方法是不可行的。即使忽略英偉達在資料中心 GPU 上約 75% 的利潤率，對於完全量產的產品，SRAM 記憶體的成本仍在 100 美元 / GB 左右。

此外，片上 SRAM 記憶體的成本不會隨著傳統摩爾定律製程技術的縮小而降低太多。同樣的 1GB 內存，採用台積電下一代 3nm 製程工藝，成本反而更高。雖然 3D SRAM 將在一定程度上幫助降低 SRAM 成本，但這只是暫時的。

記憶體層次結構的下一步是緊密耦合的片外記憶體 DRAM。 DRAM 的延遲比 SRAM 高一個數量級（約 100nsVS10ns），但它也便宜得多。幾十年來，DRAM 一直遵循著摩爾定律。當戈登摩爾創造這個詞時，英特爾的主要業務就是 DRAM。他對晶體管密度和成本的預測在 2009 年之前對 DRAM 普遍適用。不過自 2012 年以來，DRAM 的成本幾乎沒有改善。

#然而，人們對記憶體的需求只增不減。 DRAM 現在佔伺服器總成本的 50%，逐漸形成所謂的「記憶體牆」。將英偉達 2016 年的 P100 GPU 與最新的 H100 GPU 進行比較，我們會發現記憶體容量增加到原來的 5 倍（16GB → 80GB），FP16 效能增加到 46 倍（21.2 TFLOPS → 989.5 TFLOPS）。

雖然記憶體容量是一個重要瓶頸，但另一個瓶頸 —— 記憶體頻寬也非常關鍵。記憶體頻寬的增加通常是透過並行性獲得的。雖然如今標準 DRAM 的價格僅為幾美元 / GB，但為了獲得機器學習所需的海量頻寬，英偉達使用 HBM 內存 —— 一種由 3D 堆疊 DRAM 層組成的設備，需要更昂貴的封裝。 HBM 的成本大概是 10-20 美元 / GB，包括封裝和產量成本。

記憶體頻寬和容量的成本限制問題在英偉達的 A100 GPU 中尤其明顯。如果不進行大量最佳化，A100 只能具有非常低的 FLOPS 使用率。

即使研究人員進行了大量最佳化，大型語言模型的 FLOPS 使用率也只能達到 60% 左右 。很大一部分時間花費在等待另一個計算 / 記憶體的數據，或及時重新計算結果以減少記憶體瓶頸。

從 A100 到 H100，FLOPS 成長到原來的 6 倍以上，但記憶體頻寬僅成長到 1.65 倍。這導致許多人擔心 H100 的利用率會很低。 A100 需要很多技巧才能繞過記憶體牆，而 H100 還需要實現更多技巧。

H100 為 Hopper 架構帶來了分散式共享記憶體和 L2 多播 ( multicast ) 。這個想法讓一個 SM 中的資料可以直接寫入另一個 SM 的 SRAM（共享記憶體 /L1 Cache）。這有效地增加了快取的大小並減少了 DRAM 讀 / 寫所需的頻寬。未來的架構將減少向記憶體發送的操作數量，以最大限度地減少記憶體牆的影響。值得注意的是，較大的模型往往會實現更高的利用率，因為 FLOPS 需要按參數量的三次方成比例擴展，而記憶體頻寬和容量需求往往以二次方擴展。

算子融合

#

如果将所有时间都花在内存传输上（即处于内存带宽限制状态），那么增加 GPU 的 FLOPS 将无济于事。另一方面，如果将所有时间都花在执行大型 matmuls 上，那么即使将模型逻辑重写为 C 来减少开销也将无济于事。

PyTorch 之所以能胜过 TensorFlow，就是因为 Eager 模式提高了灵活性和可用性，但转向 Eager 模式并不是只有好处。在 Eager 模式下运行时，每次运算都要从内存中读取、计算，然后在处理下一次运算之前发送到内存。如果不进行大量优化，这会显著增加内存带宽需求。

因此对于在 Eager 模式下执行的模型，有一种主要的优化方法是算子融合。融合运算在一次传递中计算多个函数，以最小化内存读 / 写，而不是将每个中间结果写入内存。算子融合改善了运算符调度、内存带宽和内存大小成本。

这种优化通常涉及编写自定义 CUDA 内核，但这比使用简单的 Python 脚本要难得多。随着时间的推移，PyTorch 中稳定地实现了越来越多的算子，其中许多算子只是简单地将多次常用运算融合到一个更复杂的函数中。

算子的增加让在 PyTorch 中创建模型变得更容易，并且由于内存读 / 写更少，Eager 模式的性能更快。缺点是 PyTorch 在几年内激增到了 2000 多个算子。

我们可以说软件开发人员太懒了，但说实话，又有谁没懒惰过呢。一旦习惯了 PyTorch 中的一个新算子，他们就会继续用它。开发人员甚至可能没有意识到性能在提高，而是继续使用该算子，因为这样就不用编写更多的代码。

此外，并非所有算子都可以融合。决定要融合哪些运算，将哪些运算分配给芯片和集群级别的特定计算资源都需要花费大量的时间。算子在何处融合的策略虽大体相似，但因为架构的不同也会有很大差异。

英伟达曾是王者

算子的增长和默认的地位对英伟达来说是优势，因为每个算子都针对其架构进行了快速优化，但并未针对任何其他硬件进行优化。如果一家 AI 硬件初创公司想要全面实施 PyTorch，那就意味着以高性能支持不断增长的 2000 个算子列表。

因为提取到最大性能需要很多技巧，在 GPU 上训练具有高 FLOPS 利用率的大型模型所需的人才水平越来越高。Eager 模式执行加算子融合意味着开发的软件、技术和模型都在不断地被推动，以适应当前一代 GPU 具有的计算和内存比率。

每个开发机器学习芯片的人都受制于同一个内存墙。ASIC 受制于支持最常用的框架，受制于默认的开发方法、GPU 优化的 PyTorch 代码以及英伟达和外部库的混合。在这种情况下，避开 GPU 的各种非计算包袱而支持更多 FLOPS 和更严格的编程模型的架构意义不大。

然而，易用性第一。打破恶性循环的唯一方法是让在英伟达的 GPU 上运行模型的软件尽可能轻松无缝转移到其他硬件。随着模型架构的稳定和来自 PyTorch 2.0、OpenAI Triton 和 MLOps 公司（如 MosaicML）的抽象成为默认，芯片解决方案的架构和经济性开始成为购买的最大驱动力，而不是英伟达高级软件提供的易用性。

PyTorch 2.0

几个月前，PyTorch 基金会成立，并脱离了 Meta 。除了对开放式开发和治理模型的更改外，2.0 还发布了早期测试版本，并于 3 月全面上市。PyTorch 2.0 带来了许多变化，但主要区别在于它添加了一个支持图形执行模型的编译解决方案。这种转变将使正确利用各种硬件资源变得更加容易。

PyTorch 2.0 在英伟达 A100 上的训练性能提升了 86%，在 CPU 上的推理性能提升了 26%。这大大减少了训练模型所需的计算时间和成本。这些好处可以扩展到来自 AMD、英特尔、Tenstorrent、Luminous Computing、特斯拉、谷歌、亚马逊、微软、Marvell、Meta、Graphcore、Cerebras、SambaNova 等的其他 GPU 和加速器。

對於目前未最佳化的硬件，PyTorch 2.0 具有更大的效能改進空間。 Meta 和其他公司對 PyTorch 做出如此巨大的貢獻，是因為他們希望在自己價值數十億美元的 GPU 訓練集群上以更少的努力實現更高的 FLOPS 利用率。這樣他們也有動力使軟體堆疊更易於移植到其他硬件，將競爭引入機器學習領域。

在更好的 API 的幫助下，PyTorch 2.0 還可以支援資料並行、分片、pipeline 並行和張量並行，為分散式訓練帶來了進步。此外，它在整個堆疊中原生支援動態形狀，在許多其他範例中，這更容易支援 LLM 的不同序列長度。下圖是主要編譯器首次支援訓練到推理的Dynamic Shapes：

##PrimTorch

對於除英偉達GPU 之外的每個機器學習ASIC 來說，為PyTorch 編寫一個完全支援所有2000 多個算子的高效能後端並非易事。 PrimTorch 將算子的數量減少到約 250 個原始算子，同時也保持 PyTorch 最終使用者的可用性不變。 PrimTorch 讓 PyTorch 的不同非英偉達後端的實作更簡單、更容易存取。客製化硬體和系統供應商可以更輕鬆地推出他們的軟體堆疊。

TorchDynamo

轉向圖模式需要可靠的圖定義。為了實現這一轉向，Meta 和 PyTorch 已經嘗試了大約 5 年的時間，但是他們提出的每個解決方案都存在明顯的缺點。最後，他們用 TorchDynamo 破解了這個難題。 TorchDynamo 將攝取任何 PyTorch 使用者腳本，包括呼叫外部第三方函式庫的腳本，並產生 FX 圖。

Dynamo 將所有複雜算子減少到 PrimTorch 中的約 250 個原始算子。一旦圖形成，未使用的算子將被丟棄，圖會決定哪些中間算子需要儲存或寫入記憶體、哪些可能被融合。這大大減少了模型內的開銷，同時對使用者來說也是「無縫」的。

在測試的7000 個PyTorch 模型中，TorchDynamo 已經適用於99% 以上的模型，包括來自OpenAI、HuggingFace、Meta、英偉達、Stability.AI 等的模型，而無需對原始程式碼進行任何更改。測試的 7000 個模型是從 GitHub 上使用 PyTorch 的最受歡迎專案中隨機挑選出來的。

Google的TensorFlow/Jax 和其他圖模式執行pipeline 通常要求使用者確保他們的模型適合編譯器架構，以便可以捕獲圖。 Dynamo 透過啟用部分圖捕獲、受保護的圖捕獲和即時重新捕獲來改變這一點。

部分圖擷取允許模型包含不受支援的 / 非 python 建構。當無法為模型部分產生圖時，將插入圖中斷，並且將在部分圖之間以 eager 模式執行不支援的構造。

受保護的圖捕獲會檢查捕獲的圖是否對執行有效。 「保護」的意思是一種需要重新編譯的更改。這很重要，因為多次運行相同的程式碼不會多次重新編譯。如果捕獲的圖對於執行無效，則即時重新捕獲允許重新捕獲圖。

#PyTorch 的目標是建立一個具有流暢UX 的統一前端，該前端利用Dynamo產生graph。此解決方案的使用者體驗不會發生變化，但效能可以顯著提升。捕獲圖可以在大量計算資源上更有效地並行執行。

隨後，Dynamo 和 AOT Autograd 將最佳化的 FX 圖表傳遞給 PyTorch 本機編譯器層級 TorchInductor。硬體公司也可以將此圖輸入到他們自己的後端編譯器中。

TorchInductor

TorchInductor 是 Python 原生深度學習編譯器，可以為多個加速器和後端產生快速程式碼。 Inductor 將採用約 250 個算子的 FX 圖，並將它們降低到約 50 個算子。接著，Inductor 進入調度階段，在該階段融合算子，並確定記憶體規劃。

隨後，Inductor 進入“Wrapper Codegen”，它產生在 CPU、GPU 或其他 AI 加速器上運行的程式碼。封裝器 Codegen 取代了編譯器堆疊的解釋器部分，可以呼叫核心和分配記憶體。後端程式碼產生部分利用適用於 GPU 的 OpenAI Triton 並輸出 PTX 程式碼。對於 CPU，英特爾編譯器產生 C （也適用於非英特爾 CPU）。

#

未来他们将支持更多硬件，但关键是 Inductor 大大减少了编译器团队在为其 AI 硬件加速器制作编译器时必须做的工作量。此外，代码针对性能进行了更优化，内存带宽和容量要求得到了显著降低。

研究人员们需要的不是只支持 GPU 的编译器，而是想要支持各种硬件后端。

OpenAI Triton

对英伟达的机器学习闭源软件来说，OpenAI Triton 是一个颠覆性的存在。Triton 直接采用 Python 或通过 PyTorch Inductor 堆栈提供数据，后者是最常见的用法。Triton 负责将输入转换为 LLVM 中间表征，并生成代码。英伟达 GPU 将直接生成 PTX 代码，跳过英伟达的闭源 CUDA 库（如 cuBLAS），转而使用开源库（如 cutlass）。

CUDA 在加速计算领域很受欢迎，但在机器学习研究人员和数据科学家中却鲜为人知。使用 CUDA 可能会带来重重挑战，并且需要深入了解硬件架构，这可能导致开发过程变慢。因此，机器学习专家可能就要依赖 CUDA 专家来修改、优化和并行化他们的代码。

Triton 弥补了这一缺陷，使高级语言实现了与低级语言相当的性能。Triton 内核本身对典型的 ML 研究者来说非常清晰，这对可用性来说非常重要。Triton 在 SM 中自动执行内存合并、共享内存管理和调度。Triton 对逐元素矩阵乘法不是特别有用，但矩阵乘法已经可以非常高效地完成。Triton 对于成本高昂的逐点运算和减少复杂操作的开销非常有用。

OpenAI Triton 目前仅正式支持英伟达的 GPU，但在不久的将来会发生变化，将支持多个其他硬件供应商。其他硬件加速器可以直接集成到 Triton 的 LLVM IR 中，这大大减少了为新硬件构建 AI 编译器堆栈的时间。

英伟达庞大的软件体系缺乏远见，无法利用其在 ML 硬件和软件方面的巨大优势，也就没能成为机器学习的默认编译器。他们缺乏对可用性的关注，而 OpenAI 和 Meta 也正是得益于此才能够创建出可移植到其他硬件的软件堆栈。

原文链接：https://www.semianalysis.com/p/nvidiaopenaitritonpytorch​

以上是和TensorFlow一樣，英偉達CUDA的壟斷格局將會被打破？的詳細內容。更多資訊請關注PHP中文網其他相關文章！