自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

如何高效訓練?綜述匯總:大型深度學習訓練的并行分布式系統(tǒng)

人工智能 新聞
隨著不斷突破模型規(guī)模的界限,解決這些挑戰(zhàn)以實現(xiàn)大模型DL空間的進一步發(fā)展變得越來越必要。因此,已經(jīng)開發(fā)了各種系統(tǒng)和技術(shù)來解決這些問題。

本文經(jīng)自動駕駛之心公眾號授權(quán)轉(zhuǎn)載,轉(zhuǎn)載請聯(lián)系出處。

23年1月論文“Systems for Parallel and Distributed Large-Model Deep Learning Training“, 來自UCSD。

深度學習(DL)已經(jīng)改變了各種領域的應用,包括計算機視覺、自然語言處理和表格數(shù)據(jù)分析。對提高DL模型精度的探索促使探索越來越大的神經(jīng)架構(gòu),最近的一些Transformer模型跨越了數(shù)千億個可學習參數(shù)。這些設計為DL空間帶來了規(guī)模驅(qū)動系統(tǒng)挑戰(zhàn),例如內(nèi)存瓶頸、運行時效率低和模型開發(fā)成本高。解決這些問題的努力已經(jīng)探索了一些技術(shù),如神經(jīng)架構(gòu)的并行化、在內(nèi)存層次結(jié)構(gòu)中溢出數(shù)據(jù)以及高效內(nèi)存的數(shù)據(jù)表示。這項調(diào)查將探索大型模型訓練系統(tǒng)的前景,強調(diào)關鍵挑戰(zhàn)和用于解決這些挑戰(zhàn)的各種技術(shù)。

DL實踐的最新發(fā)展為DL研究引入了系統(tǒng)模型規(guī)模的新挑戰(zhàn)。實踐者已經(jīng)開始探索將非常大的神經(jīng)結(jié)構(gòu)圖用于DL模型,其中一些包含數(shù)十億甚至數(shù)萬億的可訓練參數(shù)!關鍵示例包括NLP Transformer模型BERT Large[16]、GPT-3[13]和Meta的深度學習推薦模型(DLRM)[41]。這些模型的龐大規(guī)模在三個關鍵領域帶來了嚴峻挑戰(zhàn)。

  • (1) 內(nèi)存可擴展性。標準DL訓練通常將模型的參數(shù)保存在加速器(例如GPU)的存儲器上,并使用采樣數(shù)據(jù)來計算每個參數(shù)的梯度更新。對于非常大的模型,保存參數(shù)、中間計算和梯度更新所需的空間通常會超過加速器相對有限的內(nèi)存資源。高端消費級GPU,如特斯拉V100[2],具有16-32GB的設備內(nèi)存,但大型DLRM可能需要數(shù)百GB的空間。
  • (2) 性能。參數(shù)計數(shù)的增加通常與較高的執(zhí)行時間有關。此外,復雜的模型架構(gòu)往往需要大型數(shù)據(jù)集來提高模型的學習能力——例如,GPT-3在300Btoken上進行訓練[13],開源BLOOM語言模型在366B[12]上進行訓練。訓練這樣的模型可能需要數(shù)周甚至數(shù)月的時間[12,41]。因此,可以提高執(zhí)行性能的優(yōu)化對大規(guī)模DL模型的開發(fā)人員非常有益。
  • (3) 訓練費用。前兩個挑戰(zhàn)的標準解決方案通常涉及跨多個設備并行存儲或執(zhí)行。然而,這種方法可能會顯著提高計算成本。BLOOM使用416個A100 GPU進行訓練,Megatron LM使用512個[5]。這對大多數(shù)從業(yè)者來說是不現(xiàn)實的,尤其是當這些GPU需要保留幾周甚至幾個月的訓練時間時。在AWS上復制BLOOM的訓練程序?qū)⒒ㄙM550萬美元。請注意,這甚至沒有考慮到模型選擇的額外成本,包括訓練多個模型以評估最佳超參數(shù)設置和配置[29]。

隨著不斷突破模型規(guī)模的界限,解決這些挑戰(zhàn)以實現(xiàn)大模型DL空間的進一步發(fā)展變得越來越必要。因此,已經(jīng)開發(fā)了各種系統(tǒng)和技術(shù)來解決這些問題。一些方向包括重具體化(rematerialization)[15]、數(shù)據(jù)溢出/CPU卸載[23,36,37,45–47]、流水線/模型并行[21,25,27,33,40]和混合并行[26,31,36,37,60]。這些主題屬于“大模型訓練技術(shù)”的保護傘,已成為工業(yè)界和學術(shù)界研究人員的重點,但該領域的工作量之大使該主題難以確定方向。本文回顧大模型DL訓練系統(tǒng)空間的現(xiàn)狀,并評估該領域未來的增長和發(fā)展方向。

最近發(fā)布了一些關于該領域的高級別、簡短的綜述[20,54],但并不全面,也沒有涉及模型選擇、混合并行性和技術(shù)交叉等關鍵主題。本文將討論這些領域,并進一步深入研究最先進的技術(shù)。

模型并行是指將神經(jīng)架構(gòu)圖劃分或分片為子圖,并將每個子圖或模型分片分配給不同設備的技術(shù)。在前饋網(wǎng)絡中,這些碎片可能指的是堆疊層的組。

模型并行性的加速潛力在很大程度上取決于體系結(jié)構(gòu)和分片策略。前饋網(wǎng)絡上的序列模型分片(如圖A所示)將不提供并行執(zhí)行的范圍,而是在加速器之間引入相關圖(dependency graph)。然而,這種分片策略在序列體系結(jié)構(gòu)(如Transformers)中仍然很流行,因為它可以在多個設備之間分配內(nèi)存需求,而且設置起來相當簡單。在其他情況下,神經(jīng)計算圖為算子間并行提供了自然的機會(如圖B所示)。

如圖所示:A) 說明了如何將不適合單個GPU的大型前饋網(wǎng)絡在三個GPU上進行模型并行化以實現(xiàn)執(zhí)行;(注:執(zhí)行速度并沒有加快——沒有并行執(zhí)行,只有分區(qū)內(nèi)存需求)B) 三個GPU上的性能模型并行分片策略的示例,并行執(zhí)行層用共享顏色表示;這種策略利用了算子圖中現(xiàn)有的并行執(zhí)行機會——如果圖本質(zhì)上更序貫處理,這可能并不一定。

另一種方法是實際劃分網(wǎng)絡中的各個算子。一些算子(如嵌入表)可以以最小的開銷按寬度進行分片(sharded)。其他,如矩陣乘法,仍然可以進行分割(例如使用并行GEMM策略[55]),但需要更多的通信步驟。如圖展示了一個模型并行嵌入表的示例。這些寬度分片策略,通常被稱為張量并行,因為它們需要輸入張量分區(qū),可以實現(xiàn)比算子間模型并行更高性能的算子內(nèi)并行,但需要更多的精力和思考來實現(xiàn)。此外,大多數(shù)張量并行算子至少需要一個全聚集(all-gather)通信步驟來重新聚集分區(qū)輸出,這一事實削弱了性能優(yōu)勢。Mesh TensorFlow[51]提供了一個通用的框架和語言來指定張量并行計算,盡管它不再被支持或維護。

任何類型的模型并行都引入了GPU-GPU通信。最新的英偉達GPU支持“NVLink”互連,即提供高達900GB/s帶寬的高速GPU-GPU通信路由,這有助于最大限度地減少開銷。然而,NVLink并不總是現(xiàn)成的,尤其是當用戶無法輕松定制的云端機器。當不支持NVLink時,GPU-GPU通信通過PCIe互連運行,速度要慢得多。特斯拉V100通常被認為是DL應用程序的標準高性能GPU,支持16GB/s的16通道PCIe 3.0互連。

為了避免通過緩慢的互連傳輸過多數(shù)據(jù),模型并行性用戶通常會選擇一種分區(qū)策略,該策略將最小化需要在片之間傳輸?shù)募せ畹臄?shù)量,或者平衡計算以隱藏通信成本。為此存在各種分片算法[14,25,26,37,46,61]。

數(shù)據(jù)并行是一種常見的深度學習執(zhí)行策略,可以并行消費多個小批量數(shù)據(jù)。數(shù)據(jù)并行執(zhí)行技術(shù)可以分為兩大類——異步數(shù)據(jù)并行和同步數(shù)據(jù)并行。

最著名的數(shù)據(jù)異步并行技術(shù)是Parameter Server,其中一個核心主服務器持有一組基線參數(shù),而分布式worker持有在不同的小批量上訓練的模型副本。分布式工作程序偶爾會向基線服務器發(fā)送更新,而基線服務器又會向分布式工作程序發(fā)送替換參數(shù),以保持它們的更新。工作程序可能會彼此不同步,因為它們只需要與基線服務器通信/同步。異步技術(shù)帶來了許多挑戰(zhàn),例如與單個worker訓練相比,準確性下降,以及由于worker返回時間的差異而導致的不可復制的結(jié)果。由于這些原因,在現(xiàn)代DL訓練環(huán)境中,異步技術(shù)通常被逐步淘汰,取而代之的是同步技術(shù)。

最流行的同步數(shù)據(jù)并行執(zhí)行技術(shù)是分布式數(shù)據(jù)并行(Distributed Data Parallelism,DDP)。DDP復制模型并將副本分配給 不同的加速器。首先接受一個初始的“全局小批量”,然后在副本之間均勻分解,為每個副本生成本地梯度更新。然后,這些梯度在副本之間聚合,產(chǎn)生全局更新,通常使用 all-reduce通信模式。然后將此全局更新并行應用于每個復制副本。該技術(shù)在數(shù)學上等效于使用原始全局小批量的單個GPU訓練。雖然這種技術(shù)引入了一個 all-reduce通信步驟,但這些開銷通常可以在模型執(zhí)行時間下重疊和隱藏。

All Gather和All Reduce通信模式通常用于數(shù)據(jù)并行和更廣泛的分布式DL。這些模式的目的是在不同的處理器上獲取單獨的數(shù)據(jù),然后將它們聚合并分發(fā)回處理器,這樣每個處理器現(xiàn)在都擁有相同數(shù)據(jù)的副本。all-together模式都使用一種算法,其中每個處理器將其數(shù)據(jù)傳送給其他每個處理器。如果每個處理器都有一個需要全局廣播的數(shù)據(jù)分區(qū),則通常會使用此方法。每個帶寬使用率高的處理器通常需要 個通信步驟——每個處理器必須與所有其他處理器進行通信。All-reduce模式是All-together之上的一層,它將與一些reduction函數(shù)(例如總和、平均值)相結(jié)合。在同步過程中,運行函數(shù)與運行all-together然后運行局部函數(shù)應用程序相比,省去了一個步驟。例如,Horovod[50]實現(xiàn)了一個為數(shù)據(jù)并行梯度聚合的帶寬最優(yōu)reduce模式,其中每個處理器需要2×( ? 1) 個通信步驟完成完全的gather和educe。

混合并行是指將不同的并行策略結(jié)合起來以實現(xiàn)更高的整體性能的策略。例如,將數(shù)據(jù)并行性疊加在模型并行性之上,可以使用戶實現(xiàn)跨多個設備的內(nèi)存可擴展性,同時加快數(shù)據(jù)并行性的執(zhí)行速度。這些策略需要在設計中進行權(quán)衡。一個簡單的覆蓋混合并行,模型并行性的多設備需求要乘以數(shù)據(jù)并行性的復制要求。任務并行性的進一步疊加(例如,在多模型訓練中)可以將另一個乘法因子添加到等式中。更復雜的混合可能會將數(shù)據(jù)并行應用于模型并行體系結(jié)構(gòu)的某些階段,讓其他階段串行執(zhí)行,如圖所示。注意這個設計打開了新的“搜索空間”——數(shù)據(jù)并行復制應該選擇哪些階段?模型并行分片決策如何影響數(shù)據(jù)并行性能?有限的資源應該如何分配到各個階段,設備互連和拓撲結(jié)構(gòu)如何影響性能?

模型架構(gòu)的規(guī)模大致分為兩類——深度規(guī)?;蛯挾纫?guī)模化。深度規(guī)模化是像Transformers這樣的長序列鏈架構(gòu)最常見的需求。寬度規(guī)模化通常用于非常寬、易于并行化的算子(例如表查找)。

模型并行等技術(shù)對于大型Transformer訓練和一般的深度模型訓練來說是必不可少的。然而,為非常深的模型啟用并行執(zhí)行可能具有挑戰(zhàn)性。對于一個深的層序列,最自然的分片策略是將序列劃分為子序列。但這種方法迫使用戶添加GPU,而實際上并沒有從任何性能優(yōu)勢中獲益——將序列劃分為子序列并不能提供任何并行執(zhí)行加速的機會??紤]一個萬億參數(shù)模型,它甚至需要使用1024個GPU才能適應內(nèi)存。所有這些GPU都只是用于“啟用”執(zhí)行,并沒有提供任何性能優(yōu)勢。事實上,由于GPU間的通信成本,該策略可能比同等的內(nèi)存內(nèi)訓練作業(yè)慢。

存在一些寬度分片(width-wise sharding)策略,例如跨多個GPU并行處理注意塊中的操作。然而,這些方法需要更多的定制,增加通信開銷,并且需要模型設計者付出大量的努力來實現(xiàn)。因此,大多數(shù)用于深度模型訓練的系統(tǒng)更喜歡應用可以針對所有深度模型類進行優(yōu)化的廣義深度分片策略,而不是一次針對單個架構(gòu)。

盡管存在順序依賴性的挑戰(zhàn),但深度分片也可以帶來許多機會。流水線并行和溢出(spilling)等技術(shù)只適用于深度分片模型(depth-wise sharded models)。

在推薦模型中,嵌入表通常是寬度分片最受歡迎的候選者。大多數(shù)公司都使用基于嵌入的電子商務模型,這些公司收集特定實體的數(shù)據(jù)(如Meta、Netflix、TikTok)來創(chuàng)建定制的體驗。一種標準的方法是創(chuàng)建一個表,將用戶ID映射到可訓練向量,然后將這些向量饋送到頂部的其他DNN。然而,要想在Facebook這樣的數(shù)十億用戶平臺上運行,相應的表格必須非常寬。一個30億的索引表,大小為1024個可訓練向量,填充單精度(32位)浮點,需要12TB的內(nèi)存。真實世界的推薦模塊可能包括用于查找的多個表(例如,用戶表、業(yè)務表、視頻目錄表),這進一步增加了內(nèi)存成本。

對嵌入表進行分區(qū)是一項簡單的任務,因為表的查找是并行的——一個索引的查找不依賴于其他索引。因此,將表分配給不同GPU成為子表,是分配內(nèi)存成本的常見策略??缙⑿袌?zhí)行,可以簡單地將小批量中的索引查找請求路由到適當?shù)腉PU。然而,為了在并行表查找之后重新聚合小批量饋送到頂部DNN,需要一個潛在的昂貴的all-together通信步驟。

將寬度分片應用于其他算子(如矩陣乘法)并不常見,但也并非聞所未聞。但總的來說,嵌入表是內(nèi)存最密集的單個操作[9]??紤]到寬度分片的主要用例是嵌入表,針對這種情況進行優(yōu)化可能顯得過于特殊。然而,嵌入表和推薦模型在DL工作負載中占了很大比例——Meta報告稱,他們50%的DL訓練周期都花在了基于嵌入表的推薦模型上[9]。因此,優(yōu)化非常廣泛的模型情況是非常值得的,即使適用性比序貫深度模型可擴展性的優(yōu)化更有限。

如圖對不同訓練系統(tǒng)和技術(shù)進行比較:

一些基本技術(shù),如再具體化,通常被用作更先進大型模型訓練系統(tǒng)的常見構(gòu)建塊。一般來說,這些技術(shù)對組織和結(jié)構(gòu)的影響很小,可以與其他方法集成。

再具體化,也稱為梯度檢查點,試圖最大限度地減少反向傳播的內(nèi)存需求[15,19]。反向傳播需要保存中間算子輸出,以便正確應用梯度計算的鏈式規(guī)則。然而,中間輸出張量可能需要大量內(nèi)存!一些分析[54]表明,激活占ResNet[22]內(nèi)存消耗的95%,占某些Transformer內(nèi)存使用的80%。最初先丟棄除少數(shù)檢查點之外的大多數(shù)激活,用檢查點重新計算反向傳播過程中丟棄的激活,再具體化以計算換取內(nèi)存。通過這種方式,在任何給定點,只有檢查點之間的中間點需要存儲在內(nèi)存中。這種方法確實會產(chǎn)生計算開銷——前向傳播有效地進行了兩次。然而,前向傳播中的算子通常比反向傳播中使用的自動微分程序更快,因此開銷比看起來更小。一些梯度檢查點系統(tǒng)聲稱只有30%的開銷,可以節(jié)省6-7X內(nèi)存[15]。

累積,是針對反向傳播中分批梯度的內(nèi)存需求而言[25]。隨機梯度下降將樣本分批放入模型饋送的小批量中,反過來可以將參數(shù)更新生成的梯度視為每個樣本更新的聚合。累積延遲了這些聚合梯度的應用,而是計算新的小批量梯度更新,并將它們累積到聚合梯度向量上。新梯度現(xiàn)在是2個小批量更新的總和,而不是1個。通過這種方式,可以擴大有效的小批量大小和梯度影響,而無需實際訓練更大的批量。將較小的單個批次稱為微批次(micro batch),并將有效的合計批次稱為小批次(mini-batch)。累積對于流水線并行性至關重要,并且經(jīng)常與其他技術(shù)結(jié)合使用。

大多數(shù)訓練框架(例如TensorFlow、PyTorch)[8,42]使用梯度和參數(shù)的單精度浮點(32位)表示。雙精度表示(64位)相對不常見。減少訓練模型的內(nèi)存需求的一種方法是使用數(shù)據(jù)的半精度(16位)表示,即低精度表征。自然地,當數(shù)值被近似時,這會導致精度損失[38]。然而,這種方法可以提供加速和內(nèi)存節(jié)省。為了嘗試和平衡這一點,自動混合精度(AMP)[3]將自動嘗試并確定何時可以安全地將數(shù)據(jù)壓縮到16位,而不會造成精度損失。AMP在訓練大型模型時,精度損失很少甚至沒有損失,同時實現(xiàn)了高達5.5X的加速[3]。由于AMP直接在非常低的級別修改數(shù)值,因此該技術(shù)通常與用于大模型訓練的實際系統(tǒng)方法正交。

在某些情況下,DL訓練中使用的向量非常稀疏。例如,嵌入表查找通常只涉及表的幾個索引。應用于表的梯度向量將僅在使用的索引處具有非零值,而其余部分置零。實際上,在內(nèi)存中保留所有這些零是不必要的,并且會浪費內(nèi)存。稀疏表示試圖將這些向量壓縮直至非零值,同時避免任何信息丟失。默認情況下,通常用于嵌入表的最簡單方法是將梯度表示為將索引映射到梯度值的K-V對。當將稀疏表示與假設標準向量表示的操作相結(jié)合時,會出現(xiàn)一些復雜情況,例如all-reduce通信模式。一些工作[35]展示了如何通過替代通信模式或?qū)?shù)據(jù)轉(zhuǎn)換回標準表示來解決這一問題。稀疏向量表示解決了一個非常具體的問題,但對于一些算子(如寬嵌入表)的有效訓練至關重要。

流水線并行性針對“序列深度模型”設置[25]。它是模型并行訓練范式的直接擴展。模型并行性創(chuàng)建一個分階段的片序列,創(chuàng)建一個自然的“流水線”結(jié)構(gòu)。流水線只是通過嘗試用執(zhí)行操作填充階段來利用這種流水線結(jié)構(gòu),從而減少純序列模型并行性中存在的空閑。每片都可以被視為流水線的一個階段,因此一個在三個GPU上三次分區(qū)的模型現(xiàn)在是一個三階段流水線。

在CPU流水線中,用發(fā)送到CPU的各種指令填充流水線[52]。對于DL流水線,用微批次填充流水線,就像在梯度累積中一樣[25,27]。從本質(zhì)上講,流水線并行是梯度累積和模型并行的結(jié)合。獨立的微批次在分片流水線中穿梭,然后為每個流水線階段積累每個微批次的梯度。一旦整個小批次(所有微批次的組合)的梯度全部聚合,就可以將其應用于模型。這種設計幾乎就像一個模型-并行-數(shù)據(jù)-并行的混合,其中數(shù)據(jù)片是并行處理的,但在不同的模型-并行片上。如圖對此進行了說明:輸入的小批次被劃分為微批次,然后在流水線階段中運送。, 指的是帶有小批量 的片 前階段, 雖然 , 指的是小批量 的片 后階段, 通過這種方式,實現(xiàn)了一種“流水線式”數(shù)據(jù)并行,即在不同的模型并行級之間并行處理數(shù)據(jù)。請注意,在反向傳播之前,必須清除正向流水線。

反向傳播對流水線并行訓練提出了挑戰(zhàn)。中間輸出必須可用于反向傳播。然而,當與累積相結(jié)合時,這將要求為每個微批次存儲不同的中間輸出集,從而剝奪了累積提供的任何可擴展性優(yōu)勢。GPipe[25]是最早的流水線并行訓練系統(tǒng)之一,提出了將累積與檢查點相結(jié)合來解決這個問題。激活將僅存儲在片/流水線階段的綁定中,在反向傳播過程中,隨著梯度在流水線中向后移動,將進行重新計算。檢查點方法現(xiàn)在是大多數(shù)(如果不是全部的話)流水線并行訓練系統(tǒng)的標準方法[21]。另一個挑戰(zhàn)是流水線的結(jié)構(gòu)。片流水線必須是雙向的。輸入和激活在預測期間向前流動,梯度在反向傳播期間向后流動。這導致了一個問題——流水線中的數(shù)據(jù)在兩個方向上流動時會在階段“碰撞”。因此,在預測和反向傳播之間會發(fā)生流水線沖洗(flush)。如果管理不當,沖洗可能會嚴重影響性能。上圖展示了一個流水線并行化模型。請注意,很大一部分時間都花在了“氣泡”期,即必須完全沖洗流水線的時間。

主要的流水線并行技術(shù)如下。

GPipe[25]建議在保持加速器計數(shù)不變的同時增加微批次的數(shù)量,這樣流水線可以更長時間保持滿狀態(tài)。這不會消除沖洗,但會提高整體效率。然而,這種方法將需要更多的內(nèi)存來存儲很多具備檢查點的微批次激活。DAP-PLE[17]提出了一種可替代的流水線調(diào)度,該調(diào)度可以保持GPipe的收斂行為,但空閑時間較少。不幸的是,它還同時保持更多的微批次“活躍”而大幅增加了內(nèi)存成本,這使得調(diào)度對于已經(jīng)突破內(nèi)存邊界的應用程序來說是不可行的。

異步流水線并行的形式還有另一種解決方案,以保持嚴格的收斂行為為代價,重新排列流水線階段和反向傳播以消除沖洗。這種序列的“解耦”將問題放松為更有效的——以影響數(shù)據(jù)消費和消費順序為代價[21,32,39,59]。例如,PipeDream[21]提出的1F1B模式,為每個后階段(在不同的微批次上)運行一個前階段,保持完美的比例和利用率。但它的設計需要更仔細的分區(qū)和打包,而緩解陳舊權(quán)重更新導致的準確性下降,需要存儲多個權(quán)重副本[21],從而增加了內(nèi)存成本。雖然像1F1B這樣的異步流水線可以很好地執(zhí)行,但它并不是一個通用的解決方案——精度損失是特定情況下的,通常可能是巨大的。精度至關重要且收斂行為必須可復制(例如模型選擇)的應用程序不適合異步流水線并行。

雖然模型并行性著眼于在多個GPU上執(zhí)行分布內(nèi)存需求,但一些系統(tǒng)試圖利用主系統(tǒng)內(nèi)存(DRAM),而不是在更多GPU上橫向擴展。這種方法的主要動機是,雖然GPU內(nèi)存有限且昂貴,但DRAM實際上更便宜且可訪問。

最初的工作[23,30,34,49,56]將卸載(offloading)視為一個“交換”問題——決定何時將張量從GPU內(nèi)存交換到DRAM上。大多數(shù)使用圖分析算法來確定在哪里“注入”交換操作,這取決于激活、梯度或參數(shù)下一次可能在執(zhí)行圖(execution graph)中使用的時間。SwapAdvisor是這些交換系統(tǒng)中最先進的,它使用并行遺傳搜索算法來分析交換算子應該放在哪里以獲得最佳性能。它也是最早支持卸載參數(shù)和激活的系統(tǒng)之一,這對于訓練十億參數(shù)模型架構(gòu)至關重要。

這些復雜的交換過程可能很難設置——SwapAdvisor的搜索算法大約需要一個小時才能完成。此外,它們很難擴展到多GPU訓練,因為沒有明確的方法來擴展交換注入圖的技術(shù)來覆蓋多GPU并行性。

ZeRO-R[46]提出了另一種方法,這是一種向DRAM動態(tài)發(fā)送激活和參數(shù)的卸載系統(tǒng)。這種方法“在需要時卸載”,而不是預先計劃卸載。設計的不規(guī)則性可能會引入內(nèi)存碎片等問題,但與基于圖的設計相比,它增加了很大的靈活性。在后來的版本中,ZeRO Infinity[47]將其擴展到卸載到非易失性快速存儲(NVMe)/磁盤存儲,實現(xiàn)進一步的可擴展性。

Hydra[37]選擇了“獨立塊”策略,將模型體系結(jié)構(gòu)劃分為子模型(如模型并行)然后可以在DRAM和GPU存儲器之間自由地溢出。可以將其與RDBMS中的溢出進行類比,在RDBMS中,獨立的數(shù)據(jù)塊可以向下發(fā)送到較低級別的內(nèi)存。與其他溢出系統(tǒng)不同,Hydra的執(zhí)行模式與模型并行性相同,并完全分離每個模型片的執(zhí)行。它仍然試圖重疊通信和計算,但忽略了其他CPU卸載技術(shù)所探索的細粒度張量卸載的復雜性。這種泛化使其不太適合單GPU執(zhí)行,但使其更適合與多GPU并行化技術(shù)混合。

如圖所示:Hydra的溢出策略只是簡單地提升和降級進出GPU內(nèi)存的模型并行分片。其他溢流設計,如ZeRO Offload使用的,雖然結(jié)構(gòu)不太嚴格,但也類似。

L2L[45]使用了類似于Hydra的設計,但在其分片方法上受到了更多限制。它專門針對Transformer架構(gòu),并將自注意塊(標準Transformer運算器)與專門為其目標模型類選擇的啟發(fā)式方法進行交換。這使它能夠在Transformer架構(gòu)上表現(xiàn)出色,但無法實現(xiàn)Hydra的靈活性或ZeRO-R的動態(tài)通用性。

請注意,這些技術(shù)通常用于深度大模型分布其內(nèi)存需求,因為它們在執(zhí)行中都利用了某種次序。一個非常寬的算子(例如嵌入表)如果沒有性能的大幅降低就無法串行化,也不容易在DRAM和GPU內(nèi)存中溢出。寬算子在混合設備執(zhí)行的唯一選項是串行化并行算子(在表的情況下即索引查找),并將一系列操作重寫為一個深度,而不是寬闊的模型,或者在CPU上實際執(zhí)行寬闊算子。

有些系統(tǒng)更甚,實際上是在CPU上執(zhí)行操作。通常,最好完全使用GPU或TPU計算來運行模型,因為大多數(shù)DL操作符在支持高度并行的加速器上運行得更快。然而,通過卸載,數(shù)據(jù)無論如何都會在CPU上——因此,GPU操作并行地執(zhí)行CPU操作不應增加開銷。

ZeRO[48]提出在GPU執(zhí)行期間在CPU上運行參數(shù)更新,特別是針對流行的Adam優(yōu)化器[28]。Adam優(yōu)化器保存一些狀態(tài)參數(shù)(通常是32位),需要在32位參數(shù)上運行以避免精度下降。不幸的是,這阻止了用戶為了減少內(nèi)存需求而部署16位表示的工作。Adam優(yōu)化器的ZeRO版本在DRAM上保持32位版本的參數(shù),在GPU上保持低精度的16位版本,消耗更少的內(nèi)存。在執(zhí)行過程中,系統(tǒng)將梯度和優(yōu)化器狀態(tài)溢出到DRAM上,然后使用CPU處理對32位參數(shù)運行參數(shù)更新。在與CPU-GPU通信和GPU計算重疊的第二步驟中,更新被傳播到16位參數(shù)。

混合CPU-GPU計算在非常大的推薦模型中也很常見。嵌入表是非常廣泛的內(nèi)存密集型算子,通常會輸入一些較小的DNN進行進一步處理。如果沒有任何優(yōu)化,嵌入表的龐大規(guī)模將迫使只執(zhí)行CPU[9]?;蛘?,用戶可以將嵌入表放置在CPU上,而DNN位于GPU內(nèi)存中,并享受GPU加速的好處。一些工作,如Hotline[10]嘗試和流水線數(shù)據(jù)通過模型,從基于CPU的嵌入表到GPU加速的DNN。他們證明,這種混合計算方法甚至可以比寬度方向的多GPU模型并行更快,因為它消除了all-to-all通信步驟的需求。

并行化技術(shù)可以以不同的方式進行組合。各種系統(tǒng)試圖將各種“基本”并行方法(如數(shù)據(jù)并行、模型并行)的優(yōu)點結(jié)合起來,為用戶提供更高的性能和可擴展性?;旌喜⑿屑夹g(shù)可以分為兩大類——“真正的”混合,從底層開始集成并行技術(shù),以及自上而下的混合,在不同的執(zhí)行階段選擇不同的策略。

接地式混合

傳統(tǒng)上,從一開始就將模型并行性與其他技術(shù)相結(jié)合是一項具有挑戰(zhàn)性的任務。模型并行性提高了GPU對標準執(zhí)行的要求,這可能會使與基于復制或多實例的并行技術(shù)(如數(shù)據(jù)并行性、任務并行性)的組合變得不切實際,因為它們進一步擴大了模型并行性的設備要求。

為了解決這個問題,Hydra[37]建議使用溢出技術(shù)來減少可擴展模型并行訓練所需的GPU數(shù)量,然后在頂部應用任務并行性一層來支持高效的多模型訓練。然后,Hydra系統(tǒng)利用模型并行性的分段特性,實現(xiàn)混合的“細粒度并行”日程,可以優(yōu)于標準的任務并行性和模型并行。如圖對此進行了說明。目前,Hydra是唯一一個明確針對大模型設置多模型的系統(tǒng),但隨著從業(yè)者努力解決模型選擇和多用戶集群管理的成本,這一領域的重要性可能會增加。

最初由ZeRO[46]引入的完全分片數(shù)據(jù)并行性(FSDP,F(xiàn)ully Sharded Data Parallelism)提供了模型并行性和數(shù)據(jù)并行性的混合。與Hydra不同的是,Hydra仍然以模型并行分片的方式執(zhí)行,F(xiàn)SDP只使用模型并行性將模型分布在數(shù)據(jù)并行的實例上,每個數(shù)據(jù)并行克隆都持有一個層組的部分參數(shù)集。當執(zhí)行一個層組時,F(xiàn)SDP運行一個all-together步驟,在每個數(shù)據(jù)并行實例上生成完整的、未分片的層組。然后層組以純數(shù)據(jù)并行方式執(zhí)行。在執(zhí)行該層之后,可以立即對其進行重新丟棄,重新分配內(nèi)存占用空間。反向傳播也采用了類似的方法。

在FSDP中,每個加速器的內(nèi)存需求,減少到單層的最小footprint加上其余部分的分區(qū)內(nèi)存需求。將單層需求分解為一個常數(shù)因子,可以將其表示為 ( / )減少,其中 是原始模型內(nèi)存占用, 是數(shù)據(jù)并行實例的數(shù)量。這使得用戶能夠同時受益于數(shù)據(jù)并行性的性能和模型并行性的可擴展性。請注意,這確實增加了大量的通信開銷——對每一層都運行all-gather——而且與基于溢出的技術(shù)不同,這仍然需要橫向擴展以實現(xiàn)可擴展性。

ZeRO Offload[48]提出將FSDP與每個加速器溢出相結(jié)合,卸載在近期不會使用的分片層參數(shù)。這提供了更好的可擴展性,但通過CPU-GPU通信引入了更多的通信開銷。ZeRO的工作是將通信與計算重疊,但一些速度減慢通常是不可避免的。分析表明,F(xiàn)SDP比標準數(shù)據(jù)并行性慢(盡管更具可擴展性,并且能夠運行更大的模型)。FSDP的支持者聲稱,用戶可以利用其更高的可擴展性來增加批次大?。◤亩箞?zhí)行時間與分布數(shù)據(jù)并行DDP性能保持一致),但批次大小會影響準確性收斂行為。為了獲得更好的FSDP性能而規(guī)?;未笮。赡軙е屡c異步流水線相同的問題(盡管不那么極端)。3D并行性將FSDP與流水線并行性和張量并行性相結(jié)合,利用可擴展的數(shù)據(jù)并行性以及并行的深度和寬度分片執(zhí)行操作。通常采取的形式,是在模型的某些部分應用FSDP,在另一個部分應用流水線,在更適合寬度分片的另一個分段中應用張量并行。3D并行通常需要基于模型架構(gòu)進行大量定制——它不能像Hydra或FSDP那樣開箱即用。也就是說,它已經(jīng)使用Megatron[53]等系統(tǒng)成功地應用于許多非常大規(guī)模的模型的訓練,如Megatron-LM[5]和BLOOM[12]。未來,將3D并行混合與Hydra的分片任務并行相結(jié)合,一種新的“4D并行”成為可能。

策略發(fā)現(xiàn)

策略發(fā)現(xiàn)系統(tǒng)試圖自動化在模型中組合并行化技術(shù)的過程。最近的幾個例子是FlexFlow[26]和Alpa[60]。

FlexFlow是在開發(fā)高級DL并行技術(shù)(如流水線并行、FSDP和分片任務并行)之前構(gòu)建的,它只探索數(shù)據(jù)、張量和模型并行,主要針對卷積神經(jīng)網(wǎng)絡。FlexFlow構(gòu)建了一個設備拓撲圖,將加速器建模為節(jié)點,將互連(例如NVLink、PCIe、Infiniband網(wǎng)絡)建模為邊緣。這允許它產(chǎn)生混合并行執(zhí)行策略,該策略考慮了給定設備配置中邊緣之間的數(shù)據(jù)移動成本。它使用模擬器來評估不同的劃分策略,使用試點通道(pilot passes)來建模運營商運行時間,并基于邊緣帶寬進行理論計算來建模通信開銷。使用模擬器作為啟示(oracle),它評估了劃分算子的不同方法。請注意,這種基于“分割”的并行表示不能支持在不同任務上利用獨立執(zhí)行的并行化技術(shù)(例如任務并行、流水線并行),盡管它可能支持FSDP。此外,它沒有明確說明內(nèi)存的可擴展性或在特定配置中設備內(nèi)存耗盡的可能性[11]。

Alpa更明確地考慮了內(nèi)存可擴展性,并考慮了算子間的并行性(例如,模型并行性、流水線并行性),而不僅僅是像FlexFlow那樣的算子內(nèi)分割。它使用指令級并行(ILP)公式來確定如何設置并行化策略,然后該階段將超過設備內(nèi)存限制時修改執(zhí)行規(guī)劃[60]。占據(jù)更廣闊的策略搜索空間,這種方法可以實現(xiàn)比FlexFlow更好的性能。

這些混合并行化策略非常適合靜態(tài)的、非數(shù)據(jù)依賴的執(zhí)行任務(例如非遞歸神經(jīng)網(wǎng)絡)。然而,它們不能很好地擴展到更動態(tài)的任務,如多模型訓練——它們是用于訓練的編譯器,而不是調(diào)度器。未來的工作可以考慮彌合這一差距,構(gòu)建一個動態(tài)混合并行執(zhí)行器。

推薦模型的模型數(shù)據(jù)并行性

DLRM給從業(yè)者帶來了獨特的挑戰(zhàn),因為它們結(jié)合了兩種不同的擴展挑戰(zhàn)。嵌入表是非常明智的,并且保證了模型并行執(zhí)行的寬度分割。頂級DNN是計算密集型的,但規(guī)模較小,并且將從數(shù)據(jù)并行性中獲益最多。因此,將張量并行性應用于模型的表格,并將數(shù)據(jù)并行性應用到DNN,這種混合策略將在推薦模型上表現(xiàn)良好。這種方法已成為完全GPU加速DLRM訓練的標準[41],盡管異構(gòu)CPU-GPU執(zhí)行也適用于訪問GPU資源較少的用戶。

混合并行DLRM訓練在多個GPU上劃分嵌入表,并在每個GPU上放置頂部DNN的局部副本。分片的表處理在樣本維度上分片的輸入,然后運行分區(qū)的all-gather來重新聚集表輸出,并在批次維度上為每個數(shù)據(jù)并行副本進行分區(qū)。如圖對此進行了說明。

這種方法使從業(yè)者能夠從神經(jīng)架構(gòu)中的數(shù)據(jù)和模型并行性中受益。通信步驟是密集的,通常會帶來沉重的開銷[35],但并行執(zhí)行的好處通常會超過這一點。

總的來說,混合并行性在適當?shù)臅r候結(jié)合不同并行化策略的優(yōu)點,為用戶提供了高效訓練模型的能力。混合并行技術(shù),如分片任務并行和FSDP,從一開始就結(jié)合了可擴展性和效率,而策略發(fā)現(xiàn)和DLRM混合并行可以幫助訓練模型架構(gòu),其在這個圖的不同階段具有混合并行需求。

原文鏈接:https://mp.weixin.qq.com/s/vMg0vH4Vb_8pMUcGEWz8_w

責任編輯:張燕妮 來源: 自動駕駛之心
相關推薦

2020-07-13 09:40:11

PyTorch框架機器學習

2017-09-01 05:35:58

分布式計算存儲

2023-10-26 18:10:43

分布式并行技術(shù)系統(tǒng)

2017-10-25 16:30:47

深度學習分布式訓練

2018-05-19 00:26:13

UAI Train分布式訓練

2022-03-15 09:10:00

分布式訓練實踐

2022-12-01 09:34:01

模型論文

2019-05-05 08:37:39

分布式PyTorchGPU

2019-08-05 07:58:01

分布式架構(gòu)系統(tǒng)

2018-12-14 10:06:22

緩存分布式系統(tǒng)

2018-08-28 15:47:03

人工智能深度學習機器學習

2020-09-21 09:15:12

系統(tǒng)

2020-10-30 07:47:42

分布式

2018-11-07 05:38:07

深度學習神經(jīng)網(wǎng)絡算法

2012-02-23 09:59:05

Hadoop分布式應用

2011-09-28 11:22:52

Hadoop

2012-05-21 10:19:31

Hadoop

2012-09-12 15:30:19

分布式集群

2023-04-19 16:51:54

分布式Primus開源

2021-07-19 11:56:56

分布式訓練框架
點贊
收藏

51CTO技術(shù)棧公眾號