過去十年機器學習軟件開發(fā)行業(yè)概覽：英偉達 CUDA 壟斷地位下降，PyTorch 超越谷歌 Tensorflow

作者 | Dylan Patel

譯者 | 馬可薇

策劃 | Tina

在過去的十年間，機器學習軟件開發(fā)的格局翻天覆地。流水的框架鐵打的英偉達，這些框架大多都極度依賴英偉達的 CUDA（統(tǒng)一計算架構），且在英偉達 GPU 上性能最好。不過，隨著 PyTorch 2.0 和 OpenAI 的 Triton 的到來，英偉達因其軟件護城河而在這一領域的制霸地位恐將不保。

本篇報告中將涵蓋以下主題：為何谷歌的 TensorFlow 輸給了 PyTorch，谷歌為何沒能利用其在人工智能領域的早期領導地位，機器學習模型訓練時間的主要構成成分，內存容量、帶寬、成本墻，模型優(yōu)化，為何其他人工智能硬件公司至今無法撼動英偉達的統(tǒng)治地位，為何硬件地位逐漸重要，英偉達在 CUDA 上的競爭優(yōu)勢是如何消失的，以及英偉達的競爭對手在大型云的芯片訓練上所取得的重大勝利。

問題簡述是，英偉達閉源 CUDA 將不再涵蓋機器學習模型的默認軟件棧。英偉達雖然搶占先機，但卻讓 OpenAI 和 Meta 后來居上掌控了軟件棧，英偉達專有工具的失敗致使后者在生態(tài)系統(tǒng)中建立了自己的工具，英偉達的護城河也遭到了永久地削弱。

TensorFlow vs. PyTorch

僅僅幾年前，在相當分散的框架生態(tài)系統(tǒng)中，掌握最常用框架 TensorFlow 的谷歌作為領跑者，設計并部署了唯一成功的人工智能指定應用加速器 TPU，他們看似已經(jīng)搶占先機、準備好制霸機器學習行業(yè)了。

2019 年機器學習框架狀態(tài)，PyTorch 掌控研究領域，Tensorflow 掌控行業(yè)領域

可事實卻是 PyTorch 贏了，而谷歌沒能將先手優(yōu)勢轉換為對新生機器學習行業(yè)的主導權。如今的谷歌使用自研軟硬件棧而非 PyTorch 和對應 GPU，導致其在機器學習社區(qū)的地位頗為尷尬，谷歌甚至還有另一套名為 Jax 的框架，直接和 TensorFlow 相競爭。

不僅如此，關于谷歌在搜索及自然語言處理方面的主導地位會因大型語言模型而衰退之類的言論也是甚囂塵上，尤其是來自那些 OpenAI 及各種利用 OpenAI 的 API 的、或基于類似基礎模型的初創(chuàng)公司。雖說可能是有些杞人憂天，但我們今天不談這些。目前來說，雖然挑戰(zhàn)不斷，但谷歌仍是處于機器學習模型的最前沿。谷歌所發(fā)明的 Transformer 在 PaLM、LaMBDA、Chinchilla、MUM，以及 TPU 等諸多領域依舊是最先進的。

讓我們回到 PyTorch 贏得一籌的話題中去。雖然也有從谷歌手中奪取掌控權的成分在，但 PyTorch 主要還是贏在了其相對 TensorFlow 而言更高的靈活性和可用性，從原則為先的角度來看，PyTorch 與 TensorFlow 的不同在于前者使用的是“動態(tài)圖模式（Eager Mode）”而非“圖模式（Graph Mode）”。

動態(tài)圖模式可被看作是一種標準的腳本執(zhí)行方式。深度學習框架會隨調用立即逐行執(zhí)行所有操作，這點和任何的 Python 代碼執(zhí)行都一樣。因此，代碼的調試和理解也都更加容易，操作間的結果和模型表現(xiàn)也更直觀。

相較之下，圖模式則有兩個階段，第一階段定義需要執(zhí)行操作的計算圖，其中計算圖是一系列代表操作、變量的相交節(jié)點，節(jié)點相連的邊則代表其間的數(shù)據(jù)流。第二階段定義延遲執(zhí)行計算圖的優(yōu)化版本。因為圖的執(zhí)行過程中我們無從得知到底發(fā)生著什么，所以這種分階段的方式讓代碼調試更具挑戰(zhàn)，也更難理解。這與“解釋性”和“編譯性”編程語言類似，可解釋的 Python 調試要比 C 更容易。

盡管現(xiàn)在 TensorFlow 也默認擁有了動態(tài)圖模式，但研究社區(qū)和多數(shù)大型技術公司都已經(jīng)習慣了 PyTorch 的解決方案。至于 PyTorch 更勝一籌的深層解釋，請見這里。總之，主流 AI 大會 NeurIPS 上最優(yōu)秀的那些非谷歌的生成性人工智能都是用的 PyTorch。

機器學習訓練組件

追根究底，影響機器學習的模型訓練耗時主要有兩個因素:1. 計算（FLOPS），即每層內運行密集的矩陣乘法 2. 內存（帶寬），即等待數(shù)據(jù)或層權重獲取計算資源。常見受帶寬限制的操作有歸一化、點式操作、SoftMax、ReLU。

曾經(jīng)主要影響機器學習訓練時長的計算時間、等待矩陣乘法等因素，隨著英偉達 GPU 的不斷發(fā)展都已不再重要。英偉達的 FLOPS 在摩爾定律下英偉達的 FLOPS 在摩爾定律下提升了多個數(shù)量級，但主要架構變化還是集中在張量核心及低精度浮點格式上，內存方面則沒有太多變化。

英偉達 GPU 增長趨勢

2018 年的 BERT 模型和英偉達的 GPU V100 均是時代頂尖產(chǎn)品，我們不難發(fā)現(xiàn)，矩陣乘法已經(jīng)不再是提高模型性能的主要因素。自此之后，最為先進的模型在參數(shù)數(shù)量上有了 3 至四個數(shù)量級的增長，而最快的 GPU 也有了一個數(shù)量級的增長。

PyTorch中操作類占比

即使是在 2018 年，純粹的計算性質工作負載在占據(jù) 99.8%的 FLOPS 同時，僅占用了 61%的運行時間。歸一化和逐點操作相較矩陣乘法而言，分別擁有 250 倍和 700 倍 FLOPS 的減少，但同時也消耗了模型近 40%的運行時間。

內存墻

隨著模型規(guī)模的不斷擴張，大型語言模型的權重本身便占據(jù)了千億、乃至太字節(jié)。百度和 Meta 所部署的生產(chǎn)型推薦網(wǎng)絡其中的大規(guī)模嵌入表就可占用幾十兆字節(jié)內存，大型模型訓練或推理中的大部分時間并沒有花在矩陣乘法的計算，而是在等待數(shù)據(jù)到達計算資源?；蛟S你會問，為什么架構師不把更多內存放在靠近計算模塊的地方？答案只有一個字，貴。

存儲層級

存儲層級所遵循的規(guī)律是從近且快，到慢但廉價的。共享內存池最近可以在同一塊芯片上，通常這種情況是由 SRAM（靜態(tài)隨機存取存儲器）組成。有的機器學習 ASIC 嘗試利用大型 SRAM 池保存模型權重，但即使是Cerebras價值約5百萬美元的晶圓規(guī)模芯片上也只有 40G 的 SRAM。我們沒有足夠的內存來容納 100B 以上的參數(shù)模型權重。

英偉達的架構常常會在芯片上使用更為少量的內存，當前一代 A100 包括了 40MB 內存，而下一代的 H100 上也只有 50MB。臺積電 5 納米工藝節(jié)點上 1GB 的 SRAM 需要大約 200 平方毫米的硅，加上相關的控制邏輯和結構的實現(xiàn)后就需要超過 400 平方毫米的硅，或使用英偉達數(shù)據(jù)中心 GPU 總邏輯面積的 50%左右?？紤]到 A100 GPU 超過 1 萬美元的價格，H100 的價格很可能也會兩萬美元起步，經(jīng)濟層面上這條路行不通。就算我們忽略英偉達數(shù)據(jù)中心 GPU 的 75%毛利率（約為四倍加價），實現(xiàn)產(chǎn)品的完全產(chǎn)出所需要每 GB 的 SRAM 內存，成本仍在一百美元上下。

此外，芯片上 SRAM 內存的花銷并不會隨著傳統(tǒng)摩爾定律所帶來的工藝技術縮減而下降太多，在下一代臺積電 3 納米工藝技術下，同樣 1GB 的內存成本實際是在增長的。3D SRAM 雖然會在一定程度上降低 SRAM 成本，但這也只是價格曲線的暫時下跌。

存儲層次中的下一層是緊密耦合的片外內存 DRAM。DRAM 相較于 SRAM，延遲要高上一個數(shù)量級（約 100 納秒和 10 納秒的區(qū)別），但 DRAM 也要便宜許多（DRAM 每 GB 一美元，SRAM 每 GB 一百美元）

數(shù)十年來 DRAM 一直遵循摩爾定律，事實上，在戈登·摩爾創(chuàng)造“摩爾定律”這個詞時，英特爾的主要業(yè)務就是 DRAM。摩爾關于晶體管密度與成本的經(jīng)濟預測對 2009 年之前的 DRAM 通常都是準確的，但自 2012 年來，DRAM 的成本幾乎沒有提升。

DRAM 每 GB 價格

我們對內存的需求只增不減，目前 DRAM 已經(jīng)占據(jù)了服務器總成本的50%。內存墻的存在已經(jīng)開始在產(chǎn)品中顯露出來了。相比英偉達 2016 年的 GPU P100，2022 年剛剛發(fā)售的 GPU H100 在內存容量上提升了五倍（16GB 到 80GB 的提升），而 FP16 性能卻提升了足足 46 倍（21.1 TFLOPS 至 989.5 TFLOPS）。

容量瓶頸與另一同樣重要的帶寬瓶頸息息相關。并行化是增加內存帶寬的主要手段，如今的 DRAM 每 GB 價格區(qū)區(qū)幾美元，而英偉達為了達到機器學習所需要的巨大帶寬而用上了 HBM 內存，這是一種由3D堆疊的DRAM層所組成的設備，且需要更為昂貴的包裝。HBM 的價格區(qū)間為 10 至 20 美元每 GB，其中包含有包裝與產(chǎn)量成本。

內存帶寬與容量限制在英偉達 A100 GPU 中被反復提及。沒有大量優(yōu)化過的 A100 常常會有極低的 FLOPS 利用率，F(xiàn)LOPS 利用率是通過計算（模型訓練時總計算 FLOPS）/(GPU 在模型訓練時間內理論可計算 FLOPS）而得出。

即使是在頂尖研究者所做的大量優(yōu)化下，60%的 FLOPS 利用率對于大型語言模型訓練而言也算是非常高的了。剩下的時間都是開銷，包括等待其他計算或內存數(shù)據(jù)的空閑期，或為減少內存瓶頸而進行即時重新計算結果。

FLOPS 在 A100 至 H100 兩代間增長了 6 倍有余，但內存帶寬卻只有 1.65 倍的增長，從而導致了許多對 H100 低利用率問題的擔憂。人們?yōu)樽?A100 繞過內存墻搞出了許多變通方案，而這種努力在 H100 上恐怕會只多不少。

H100為Hopper架構帶來了分布式共享內存和二級組播，其中不同 SM（可看作內核）可直接寫入其他 SM 的 SRAM（共享內存/L1 緩存）。此舉在有效增加緩存大小的同時，縮減了DRAM讀寫所需的帶寬。后續(xù)架構也將通過減少向內存?zhèn)鬏數(shù)牟僮骶徑鈨却鎵Φ挠绊憽Ｖ档米⒁獾氖?，因為?FLOPS 的需求會隨參數(shù)數(shù)量增加而立方擴展，對內存帶寬及容量的需求則常呈二次曲線發(fā)展，所以較大型的模型也更傾向于實現(xiàn)更高的利用率。

算子融合 – 治標不治本

同機器學習模型訓練一樣，明白自己所處狀態(tài)才能更精確地進行重要的優(yōu)化。舉例來說，如果我們處于內存帶寬約束的狀態(tài)，時間全花在了內存?zhèn)鬏斏?，那么增?GPU 的 FLOPS 并不能解決問題。而如果是處于計算約束的狀態(tài)，笨重的矩陣乘法非常耗時的話，那么試圖通過將模型邏輯改寫成 C 來削減開銷也是沒效果的。

雖然 PyTorch 是通過動態(tài)圖模式增加了靈活性和可用性而贏得的比賽，但動態(tài)圖模式也不是完美的。在動態(tài)圖模式中執(zhí)行的每個操作都需要從內存中讀取、計算，再發(fā)送到內存之后，才能處理下一個操作。在缺乏大量優(yōu)化的情況下，這種模式將大大增加對內存帶寬的需求。

因此，動態(tài)圖模式中執(zhí)行模型的主要優(yōu)化手段之一是算子融合。用融合操作符的方式取代將每次的中間結果寫入內存，在一次計算中計算多個函數(shù)，從而盡可能減少對內存的讀寫。算子融合改善了操作符的調度，也削減了內存帶寬和容量的成本。

算子融合簡圖

這種優(yōu)化方式常常需要編寫自定義 CUDA 內核，這可比簡單使用 Python 腳本要難多了。PyTorch 的內置變通方案長期以來在 PyTorch 內部實現(xiàn)了越來越多的操作符，這其中的許多操作符都只是將多個常用操作融合到一個更為復雜的函數(shù)中。

操作符的增加讓 PyTorch 中的模型創(chuàng)建更加輕松，隨著內存讀寫次數(shù)的減少，動態(tài)圖模式的性能也更快。但隨之而來的代價是 PyTorch 中運算符在短短幾年內就膨脹至兩千有余。

人們常說軟件開發(fā)者是懶人，但老實說又有誰不是呢。在熟悉了 PyTorch 中某個新增的操作符后，開發(fā)者們通常只會覺得這個新操作符能讓自己少些點代碼，而完全沒有意識到其中的性能提高。

此外，并不是所有的操作都能融合。大部分時間我們都在決定要融合哪些操作，又要將哪些操作分配給芯片和集群層面特定的計算資源。雖然一般來說算子融合的策略都多少有些類似，但根據(jù)架構的不同也會有所區(qū)別。

英偉達稱王

操作符數(shù)量的發(fā)展和其默認的首選地位讓英偉達受益很多，每個被迅速優(yōu)化的操作符都是針對英偉達架構的，且對其他硬件并不適用。任何想要完整實現(xiàn) PyTorch 的人工智能硬件初創(chuàng)公司，都得靠高性能才能原生支持兩千多個且還在不斷增長的操作符。

在 GPU 上訓練高 FLOPS 利用率的大型模型所需的技術水平越來越高，為達到最佳性能所需花樣也越發(fā)繁多。動態(tài)圖模式的執(zhí)行和算子融合，意味著軟件、技術、模型的開發(fā)都要被迫適應最新一代 GPU 的計算和內存比例范圍。

內存墻是任何機器學習芯片的開發(fā)者都逃不開的命運。ASIC 必須要能支持常用框架的同時，也要能支持混合使用英偉達及外部庫的、基于 GPU 優(yōu)化的 PyTorch 代碼這一默認開發(fā)策略。因此，為圖更高 FLOPS 及更嚴格的編程模型，而主動放棄 GPU 的各種非計算包袱這種行為是非常沒有意義的。

易用性是王道。

要打破這種惡性循環(huán)的唯一方式是將英偉達 GPU 上運行模型的軟件，盡可能地無縫轉移至其他硬件上。隨著 PyTorch 2.0、OpenAI Triton，以及諸如MosaicML的MLOps公司所提供的模型架構穩(wěn)定性和抽象逐漸得到主流承認，芯片解決方案的架構和性價比逐漸取代了英偉達卓越的軟件所帶來的易用性，成為驅動購買力的主要因素。

PyTorch 2.0

數(shù)月之前剛剛成立的PyTorch基金會正式脫離了Meta的掌握。在向開放式開發(fā)和管理模式轉變的同時，2.0 的早期測試版本已經(jīng)發(fā)布，并預計于 2023 年三月全年上市。PyTorch 2.0 與前代最主要的區(qū)別在于，新增的一個支持圖執(zhí)行模型的編譯解決方案，讓各種硬件資源的利用更加輕松。

PyTorch 2.0 在英偉達 A100 上的訓練性能有了86%的提升，CPU上的推理則有26%的提升，極大地縮減了模型訓練所需的計算時間和成本。而這種性能提升也可以類推至包括AMD、英特爾、Tenstorrent、Luminous Computing、特斯拉、谷歌、亞馬遜、微軟、Marvell、Meta、Graphcore、Cerebras、SambaNova 在內的多個 GPU 和加速器上。

PyTorch 2.0 的性能提升在未經(jīng)優(yōu)化的硬件上更為明顯。Meta 及其他公司對 PyTorch 的大量貢獻背后，是希望能在他們數(shù)十億美元的訓練集群上，以最小的努力實現(xiàn)更高的 FLOPS 利用率，讓他們的軟件棧更易于移植到其他硬件上，從而為機器學習領域引入新的競爭力。

分布式訓練也受益于 PyTorch 2.0，數(shù)據(jù)并行、分片、管道并行及張量并行均得到了更優(yōu)秀的 API 支持。除此之外，PyTorch 2.0 也通過全棧提供了對動態(tài)圖形的原生支持，讓LLM不同序列長度等更易于支持。這也是主流編譯器第一次支持從訓練到推理的動態(tài)形狀。

PrimTorch

對任何非英偉達 GPU 之外的任何機器學習 ASIC 來說，想要編寫一個完整支持全部兩千余個操作符的高性能后端是非常具有挑戰(zhàn)性的。而 PrimTorch 卻可以在保障 PyTorch 終端用戶可用性不變的前提下，將操作符數(shù)量減少至約 250 個原始操作符，讓非英偉達的 PyTorch 后端實現(xiàn)更簡單容易，定制硬件和操作系統(tǒng)的供應商也更容易提出自己的軟件棧。

TorchDynamo

穩(wěn)健的圖定義是向圖模式轉變的必需品，而過去五年間 Meta 和 PyTorch 在這方面解決方案的嘗試都有著明顯的缺陷，直到 TorchDynamo 的出現(xiàn)。TorchDynamo 可接收任何 PyTorch 用戶腳本并生成FX圖，甚至是調用三方外部庫的腳本也可以。

Dynamo 將所有復雜操作都壓縮為 PrimTorch 中約 250 個原始操作符。圖成型后所有未使用的操作會被棄置，成型的圖決定了有哪些中間操作需要被存儲或寫入內存，有哪些可以被融合。這種方式極大地削減了模型內開銷，對用戶而言也是無感的。

目前在不修改任何源碼的前提下，TorchDynamo已在超過七千個PyTorch模型上通過了可行性測試，其中不乏來自 OpenAI、HuggingFace、Meta、英偉達、Stability.AI 的模型。這七千多個模型是從 GitHub 上熱度最高的 PyTorch 項目中直接選取的。

谷歌的 TensorFlow、Jax 及其他圖模式的執(zhí)行管道，通常需要用戶自行保障模型對編譯器架構的兼容性，才能確保圖可以被捕獲。而 Dynamo 通過啟用部分圖捕獲、受保護的圖捕獲及即時重新捕獲進行改善。

• 部分圖捕獲允許模型包括不支持或非 Python 的結構。在無法生成圖的模型構造部分插入圖斷點，并在部分圖之間以動態(tài)圖模式執(zhí)行。
• 受保護圖捕獲校驗被捕獲的圖是否可有效執(zhí)行。保護是指需要重新編譯的代碼變更，畢竟多次重復執(zhí)行的同一段代碼并不會重新編譯。
• 即時重新捕獲允許無效執(zhí)行的圖重新被捕獲。

PyTorch 意圖創(chuàng)建一個依賴 Dynamo 圖生成的、統(tǒng)一且流暢的 UX。這項解決方案在不改變用戶體驗的同時顯著提高性能，而圖捕獲意味著在大型計算資源的基礎上執(zhí)行可以更高效地并行進行。

Dynamo 及AOT自動求導會在之后將優(yōu)化后的 FX 圖傳入 PyTorch 本地編譯器層，即 TorchInductor。其他硬件企業(yè)也可直接取用此時的圖并輸入至他們自己的后端編譯器中。

TorchInductor

作為原生的 Python 深度學習編譯器，TorchInductor 可為多個加速器和后端生成快速代碼。Inductor（電感器）可接收包含約 250 個操作符的 FX 圖，并進一步將其操作符數(shù)量削減至 50 左右。在這之后，Inductor 會進入調度階段，融合算子并確定內存規(guī)劃。

之后，Inductor 會進入“代碼封裝”階段，生成可在 CPU、GPU 及其他人工智能加速器上運行的代碼。封裝后的代碼可調用內核并分配內存，取代了編譯器堆棧中解釋器的部分。其中，后端代碼的生成部分借助 OpenAI 的 GPU 語言 Triton，輸出 PTX 代碼。對 CPU 而言，英特爾編譯器所生成的 C 代碼也可以在非英特爾的 CPU 上運行。

后續(xù)還會新增更多對硬件的支持，但 Inductor 確實顯著降低了在編寫 AI 硬件加速器的編譯器時所需的工作量。此外，代碼性能也得到了優(yōu)化，對內存帶寬和容量的要求也大大地降低了。

我們寫的編譯器不能只支持 GPU，而要能擴展到對各類硬件后端的支持。C 及（OpenAI）Triton 迫使著我們一定要具備這種通用性。——Jason Ansel – Meta AI

OpenAI Triton

OpenAI 的 Triton 語言對英偉達機器學習閉源軟件的護城河有著毀滅性的打擊。Triton 可直接接收 Python 腳本，或者更常見地接收通過PyTorch的Inductor堆棧的信息流。隨后 Triton 會將輸入轉換為 LLVM 中間表示并生成代碼，使用 cutlass 等開源庫取代英偉達的閉源 CUDA 庫（如 cuBLAS）。

CUDA 在專職于加速計算的開發(fā)者中更為常用，在機器學習研究者或數(shù)據(jù)科學家之間則沒什么知名度。高效地使用 CUDA 并不容易，需要使用者對硬件架構有深入理解，并可能會拖慢開發(fā)過程。因此，機器學習專家們常常會依賴 CUDA 專家對他們的代碼進行修改、優(yōu)化，以及并行化。

而 Triton 則彌補了這一差距，讓高層語言達到與底層語言相媲美的性能水平。Triton 的內核本身對一般的機器學習研究者而言具備可讀性，這一點對語言可用性非常重用。Triton 將內存凝聚、共享內存管理，以及 SM 內部的調度全部自動化，但對元素層面的矩陣乘法沒什么太大幫助，后者本身已經(jīng)足夠高效了。此外，Triton 在昂貴的逐點操作方面很有效，對涉及矩陣乘法的大型算子融合而言，也可明顯削減復雜如Flash注意力等操作的開銷。

時至今日，OpenAI 的 Triton 才正式支持英偉達的 GPU，不過很快就要不同了。數(shù)個其他硬件供應商都會在后續(xù)對其提供支持，這項開源項目的前途一片光明。其他硬件加速器能夠直接集成至 Triton 中 LLVM IR，意味著在新硬件上建立人工智能編譯器堆棧的時間將大幅縮短。

英偉達龐大的軟件組織缺乏遠見，沒能利用自己在機器學習軟硬件方面的巨大優(yōu)勢，一舉成為機器學習的默認編譯器。英偉達對可用性關注的缺失讓外界中 OpenAI 及 Meta 得以開發(fā)出向其他硬件方向移植的軟件棧。他們?yōu)槭裁礇]能為機器學習研究者們開發(fā)出一個像是 Triton 之類的*簡化版*CUDA？為什么像是Flash注意力一類的技術是出自一個博士生而不是英偉達本身？

本篇報告中的剩余部分將會列出能讓微軟拿下一城的具體硬件加速器，以及目前正被快速集成至 PyTorch 2.0 或 OpenAI Trion 軟件棧中多家公司的硬件產(chǎn)品。此外，報告中也將列出相反觀點，為英偉達在人工智能培訓領域的護城河或實力提供辯護。

查看英文原文：How Nvidia’s CUDA Monopoly In Machine Learning Is Breaking – OpenAI Triton And PyTorch 2.0

本文轉載來源：

https://www.infoq.cn/article/9TFWk1rM2h8hLJUvbUG0