大模型工業化的方法論,都藏在GPU裡
引言
資料智慧時代,計算是剛需,也是痛點,最主要的特點就是一個字——大。
將“大”拆分成三個特點,則包括:
資料大批次
計算序列依賴
計算複雜性高
這囊括了資料和演算法的複雜性,而資料、演算法、算力是智慧時代三要素,前兩者的複雜性最後都要由算力來承載。
這使得業界對算力的需求在空間和時間上都極速膨脹,有如海嘯之勢。
GPU 卻有辦法將海嘯在空間上細分成萬千條涓涓細流,在時間上縮短流水的路徑,在結構上精簡路徑分支,將大規模任務層層拆解成小規模任務,舉重若輕般承載了海量算力需求,成為智慧時代的算力基礎。
針對上述三個特點,GPU 基於吞吐量、視訊記憶體等指標,分別採用並行、融合、簡化三種方法,在運算元層面進行加速。
GPU 加速的主要方法論,亦適用於大模型的工業化。
伴隨底層晶片、算力、資料等基礎設施的完善和進步,全球 AI 產業正逐步從運算智慧走向感知智慧、認知智慧,並相應形成“晶片、算力設施、AI 框架&演算法模型、應用場景”的產業分工、協作體系。2019 年以來,AI 大模型帶來問題泛化求解能力大幅提升,“大模型+小模型”逐步成為產業主流技術路線,驅動全球 AI 產業發展全面加速。
不久前,DataFun 舉辦《AI 大模型技術路線和工業化落地實踐》分享活動,來自 NVIDIA、百度、位元組跳動火山翻譯、騰訊微信等 6 位專家,從模型訓練技術與推理方案、多語言機器翻譯的應用、大規模語言模型研發與落地等多方面,帶來AI大模型技術路線和工業化落地實踐的精彩分享。
他們在業界落地大模型的時候,很大程度上都採用了並行、融合與簡化的方法,並且還從訓練、推理層面延伸到了演算法建模層面。
文|劉曉坤
出品|DataFun社群
圖片|DataFun社群
為了實際完成大模型的訓練,就需要高效率的軟體框架,使得訓練在單個 GPU、單個節點甚至在大規模叢集上都有很好的計算效率。
因此,NVIDIA 開發出了 Megatron 訓練框架。
Megatron 採用了模型並行、Sequence 並行等最佳化手段以高效地訓練 Transformer 大模型,可訓練萬億級別引數量的模型。
在演算法建模層面,火山翻譯和百度主要對 MoE 模型等建模方法進行了探索。
1. 模型並行
模型並行可分為 Pipeline 並行和 Tensor 並行。
Pipeline 並行也就是層間並行(圖中上半部分),將不同的層劃分到不同的 GPU 進行計算。這種模式的通訊只發生在層的邊界,通訊次數和通訊資料量較少,但會引入額外的 GPU 空間等待時間。
Tensor 並行也就是層內並行(圖中下半部分),將一個層的計算劃分到不同的 GPU 上計算。這種模式的實現更加容易,對於大矩陣的效果更好,更好實現 GPU 之間的負載均衡,但通訊次數和資料量都比較大。
為了充分利用 GPU 資源,Megatron 將每個訓練 batch 劃分成了更小的 micro batch。
由於不同的 micro batch 之間沒有資料依賴,因此可以互相覆蓋等待時間,從而能夠提高 GPU 的利用率,進而提高整體的訓練效能。
Tensor 並行把每個運算元的計算劃分到不同的 GPU 上,對於一個矩陣層,存在橫切和縱切兩種方式。
如圖所示,Megatron 在 Transformer block 的 attention 和 MLP 部分都引入了這兩種切分方式。
在 Tensor 並行模式下,每個 Transformer 層的前向反向加起來總共需要四次 All-reduce 通訊,由於 All-reduce 的通訊量較大,因此 Tensor 並行更適合單卡內部使用。
結合 Pipeline 並行和 Tensor 並行,Megatron 可以將在 32 個 GPU 上訓練 1700 億引數模型,擴充套件到在 3072 個 GPU 上訓練 1 萬億引數規模的模型。
2. Sequence 並行
Tensor 並行其實並沒有對 Layer-norm 以及 Dropout做拆分,因此這兩個運算元在每個 GPU 之間是複製的。
然而,這些操作本身不需要大量計算,卻非常佔用啟用視訊記憶體。
為此,Megatron 又提出了 Sequence 並行的最佳化方法。Sequence 並行的好處在於不會增加通訊量,並且可以大大減少視訊記憶體佔用
由於 Layer-norm 和 Dropout 沿著序列的維度是獨立的,因此可以按照 Sequence 維度進行拆分。
使用了 Sequence 並行之後,對於超大規模的模型而言,其實視訊記憶體佔用量還是很大的。因此,Megatron 又引入了啟用重計算技術。
Megatron 的做法是,找到一些計算量很少但視訊記憶體佔用很大的運算元,比如 Attention 裡的 Softmax、Dropout 等運算元,對這些運算元進行啟用重計算就可以顯著減少視訊記憶體,並且計算開銷增加不大。
Sequence 並行和選擇性啟用重計算的結合可以將視訊記憶體佔用降低為原來的 1/5 左右。相對於原本直接將所有啟用進行重計算的方案,其視訊記憶體也只有其兩倍,同時計算開銷顯著降低,並且隨著模型規模增大,計算開銷的佔比也會逐漸降低。到萬億規模模型的時候,重計算的開銷只佔整體的 2% 左右。
3. 演算法並行
MoE 模型因其設計思想簡潔、可擴充套件性強等特點,使其在業界得到了越來越多的關注。
MoE 模型提出了這樣的設計思想,也就是將大模型拆分成多個小模型。每個樣本只需要啟用部分專家模型進行計算,從而大大節省計算資源。
目前最常用的稠密大模型是 BERT、T5、GPT-3,最常用的稀疏 MoE 模型是 T5+MoE,MoE 正成為大模型構建的趨勢。
可以說,MoE 在演算法建模層面,結合了平行計算的思想。
大模型的通用性,體現在多個方面,除了我們已經熟知的幾點,比如注意力機制歸納偏置更弱,模型容量大,模型資料大等等,還可以在任務建模方式上做最佳化,MoE 就是典型的代表。
對於火山翻譯而言,MoE 的基本思路是透過寬度換取深度,因為模型深度越深,計算層數越多,進而推理時間越長。
比如,對於擁有 4 層 Encoder、4 層 Decoder 的 Transformer 模型,每次計算必須經過所有 8 個 FFN 的計算。如果是混合專家模型,則可以把 FFN 平行放置,最終把計算路徑減半,因而推理時間也減半。
而在相同推理時間下,也就是模型深度相近的時候,由於 MoE 可以增加模型寬度,在機器翻譯的最終效果上也有所提升。
針對 24 種非洲語言和英、法語言的多語言翻譯任務,火山翻譯開發出了擁有 128 層 Transformer、24 個專家層的 MoE 模型,相比傳統架構實現了更好的翻譯效果。
但 Sparse MoE 中的“專家模型”可能有些名不副實,因為對於一句話,比如其每個 Token 經過的專家都有可能是不同的。
火山翻譯因此開發了 Hard Gate MoE,使得句子經過的專家由語種確定,這使得模型結構更加簡單,實驗結果也表明其翻譯效果更好。
在演算法建模的並行化探索中,百度也在知識增強跨模態生成大模型 ERNIE-ViLG 2.0 中採用了混合專家擴散模型框架。
為何要對擴散模型採用專家模型?
其實是因為在不同的生成階段,模型建模要求的不同。比如在初始階段,模型著重學習從高斯噪聲中生成有語義的影像,在最後階段,模型著重從含噪影像中恢復影像細節。
實際上,在 ERNIE 3.0 的早期版本中就融合了自編碼和自迴歸,其可在通用的語義表示上,針對具體的生成任務和理解任務,結合兩種建模方式。
融合自編碼和自迴歸的基本思想其實與專家模型的建模方法論類似。
具體來說,是在通用表示的基礎上,根據理解任務適合自編碼網路結構,生成任務適合自迴歸網路結構,來進行建模。此外,這種建模方式通常還能學習到更好的通用表示。
此外,在 ERNIE-UniX2 模型中,百度透過將對比學習、語言模型等預訓練正規化進行融合,將多語言、多模態的理解和生成任務進行了統一。
訓練完 MoE 模型後,推理部署也是非常重視效率的環節。
在進行超大規模模型推理部署方案選擇的時候,首先會根據模型的引數規模、模型結構、GPU 視訊記憶體和推理框架,以及對模型精度和推理效能的權衡來決定是使用單卡推理還是多卡推理。如果視訊記憶體不足,則會考慮模型壓縮或多卡推理的方案。
多卡推理包括 Tensor 並行、Pipeline 並行、Expert 並行等模式。
對 MoE 超大模型採用不同模式會遇到不同的挑戰。其中,MoE 模型的 Tensor 並行和稠密模型類似。
如果選擇 Expert 並行模式,每個 MoE Layer 的 Expert 就會被劃分到不同的 GPU 上,這可能帶來負載均衡問題,從而導致大量的 GPU 是空閒的,最終使得整體吞吐量不高。這是 MoE 多卡推理中需要關注的重點。
對於 Tensor 並行和 Pipeline 並行,除了透過微調減少卡間通訊以外,更直接的方法是提升卡間頻寬。而當對 MoE 模型使用 Expert 並行導致負載均衡問題的時候,可以透過 Profiling 分析最佳化。
多卡推理方案增加了通訊開銷,對模型推理延時有一定影響。
02/融合
融合是解決平行計算中遇到的天然矛盾的方法,平行計算和序列計算是兩種基本的計算模式。而在應用平行計算的時候,最典型的困難就是大量的序列依賴,以及因此產生的中間值視訊記憶體佔用問題,而 GPU 視訊記憶體通常會成為大模型訓練和推理的硬體效能瓶頸之一。
對於海量計算序列依賴問題,最主要的方法是將細流的路徑縮短,也就是減少中間停留過程。具體來說,就是利用運算元融合,把次序存在先後依賴關係的運算元進行合併,以減少視訊記憶體佔用。
運算元融合不僅在計算層面,也可以在運算元設計層面實現。
1. 1F1B
Pipeline 並行中如果將前向和反向過程分開,就會出現視訊記憶體佔用過多問題。
因此,Megatron 又提出了 Pipeline 並行的新模式 1F1B,每個 GPU 以交替的方式執行每個 micro batch 的正向和反向過程,以儘早釋放其佔用的視訊記憶體,進而減少視訊記憶體佔用。
1F1B 並不能減少 bubble time,為了進一步減少 bubble time,Megatron 又提出了 interleaved 1F1B 模式。也就是原本每個 GPU 負責連續 4 個層的計算,現在變成負責連續兩個層的計算,只有原來的一半,從而 bubble time 也變成了原來的一半。
2. Kernel融合
當在做 GPU 計算的時候,每個計算流程都可以封裝成一個 GPU 的 Kernel,放到 GPU 上執行,並且是順序性的。傳統的運算元庫為了通用性,會把運算元設計的非常基本,因此數量也非常多,帶來的弊端是視訊記憶體佔用多,因為需要儲存大量的中間隱藏表示,另外這對頻寬的要求也比較高,最終可能造成延遲或者效能損失。
火山翻譯基於 CuBLAS 乘法介面將其他非矩陣乘法運算元進行了融合,包括了 Softmax、LayerNorm 等。
除了比較通用運算元的融合,火山翻譯還針對一些特定運算元比如 Beam Search 無法很好利用 GPU 並行性的特點,最佳化其計算依賴問題,從而實現加速。
在四種主流 Transformer 模型上,LightSeq 運算元融合在 PyTorch 的基礎上取得了最高 8 倍的加速。
03/簡化
簡化是一種比較簡單直觀的加速方式,在細微處將流水分支精簡。具體而言,就是對於計算高複雜性,在保證效能的前提下將運算元複雜度簡化,最終減少計算量。
超大規模模型的單卡推理一般會涉及模型壓縮。
常見的模型壓縮方案是量化、蒸餾和剪枝。量化是業內最常用的模型壓縮方案之一。雖然量化的計算採用了更低的精度,但可以保持模型的引數量級,在某些情況下或許能更好地保證模型整體的精度。
1. 量化
目前有兩種量化方法,一種是訓練後量化,一種是量化感知訓練。後者通常比前者對模型的精度保持更好。
完成量化後,可以透過 TensorRT 或 FasterTransformer 等推理加速框架,進一步加速超大模型的推理。
LightSeq 在訓練過程的量化中採用了真 int8 量化,也就是在矩陣乘法之前,會執行量化操作,並且在矩陣乘法之後才執行反量化操作。而不像過去的偽量化那樣,在矩陣乘法之前就執行了量化和反量化操作,以讓模型適應量化所帶來的損失和波動。後者在實際計算中並不能帶來加速,反而可能增大延時,或者使得視訊記憶體佔用上升。而真 int8 量化在實際應用中也帶來了很好的加速效果。
2. 蒸餾
第二種模型壓縮方式是蒸餾。蒸餾可以針對不同應用場景採用不同的策略對超大模型進行壓縮,在某些情況下,蒸餾可以讓超大模型擁有更好的泛化能力。
3. 剪枝
最後一種模型壓縮方案是剪枝。剪枝可分為全模型剪枝和部分層剪枝,對於超大模型,瞭解模型關鍵層非常重要,需要避開這些對精度影響最大的部分的剪枝,這對於稀疏 MoE 模型也是適用的。
4. 大模型工業化
大模型的研究和落地已成趨勢,預計在 2022 年,關於大規模語言模型和 Transformers 的論文超過 1 萬篇,比五年前 Transformers 剛提出的時候增長了7倍。另外,大模型也有非常廣泛的應用,比如圖片生成、推薦系統、機器翻譯,甚至是生命科學、程式碼生成等。
OpenAI 也曾經在 2020 年發表過兩篇論文,就展示過一個模型的表現基本上和三個主要的因素掛鉤,即算力、資料集大小、模型引數量,以這三個指標就能很好地預測模型的效果。
Richard Sutton 曾經說過,在過去 70 年的 AI 發展中,一個反覆出現的趨勢是一個通用的能夠高效利用計算資源的方法,總會是最後的贏家。
根據 Richard Sutton 的“贏家定律”,深度學習在過去近十年是贏在了通用性。
但如今,大模型訓練的挑戰已不言而喻。以 GPT-3 為例,其在訓練的時候如果使用原始的混合精度,需要儲存訓練時的引數和梯度以及 FP 32 的主引數,如果使用 Adam 最佳化器,還要儲存兩個最佳化器的動量資訊,則最終總共需要 2.8 個 TB 的視訊記憶體,這遠遠超出了單卡的視訊記憶體容量,需要超過 35 張 A100 才能承載。
NVIDIA 2021 年的論文“Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM”中得出一個經驗公式,表明單次迭代引數量為 1750 億的 GPT-3 模型就需要 4.5 億 FLOPs 的算力。如果整個訓練週期包含 95000 次迭代的話,就需要 430 ZettaFLOPs。換句話說,需要一塊 A100 訓練 16000 天,這還是不考慮計算效率的結論。
也就是說,光靠堆積這三個指標在大模型工業化時代將極大浪費資源。
DeepMind 在 2022 年發表的 ChinChilla 的論文中曾表示,實際上 GPT-3、OPT、PaLM 等大模型,基本都屬於欠擬合模型。如果基於同樣的計算資源,調小模型引數量,並訓練更多步驟,最終的模型效果才能更好一些。這也是微信在 WeLM 大規模語言模型中遵循的設計思想。
業界各企業基本都在開始將注意力從規模上放鬆,轉而關注大模型落地時的效率問題。
比如,從整體執行效率來看,經過 Megatron 最佳化的幾乎所有模型都有 30% 的吞吐量提升,並且隨著模型大小的增加,可以實現更高的 GPU 利用率。在 1750 億引數的 GPT-3 模型上,GPU 利用率可以達到 52.8%。而在 5300 億引數規模以上的模型上,利用率可以達到 57%。
也就是說,根據 Richard Sutton 的“贏家定律”,效率,將成為大模型工業化的主基調。
今天的分享就到這裡,謝謝大家。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024923/viewspace-2931141/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 《你好,李煥英》口碑爆棚,原來秘訣都隱藏在了影迷的評論裡面
- 寫程式碼做副業月入10K+的方法都藏在這幾個公眾號
- 最懂工業的大模型來了!思謀釋出全球首個工業多模態大模型大模型
- IT大神提升程式碼效率的秘密,都私藏在這10個神仙軟體裡
- 藏在VPU裡的玲瓏棋局
- 開源大模型佔GPU視訊記憶體計算方法大模型GPU記憶體
- 用還原論方法研究大語言模型?模型
- 深藏在CSS裡的詩情畫意CSS
- GPU程式設計--OpenCL四大模型GPU程式設計大模型
- 來外灘大會,論一論大模型的邊界大模型
- 贓款藏在哪裡最安全
- SQL優化的方法論SQL優化
- 《我用神器擼大樹》:如何打造一套高價效比的工業化精品模型?模型
- 小雨智造:小米系首家工業具身大模型公司崛起,國家隊助力產業化落地大模型產業
- 讓AI拋棄“小作坊”,擁抱“工業化”:盤古大模型究竟是什麼?AI大模型
- kafka核心原理的祕密,藏在這16張圖裡Kafka
- Oracle效能優化方法論的發展之二:基於OWI的效能優化方法論Oracle優化
- 前員工,困在競業裡
- 無模型的強化學習方法模型強化學習
- NeurIPS 2018,最佳論文也許就藏在這30篇oral論文中
- “金三銀四”春招季,高薪offer原來藏在這些行業裡高薪行業
- document模型裡為什麼只有評論數字段模型
- 企業級資料倉儲遷移工藝和方法論總結
- CPU 執行程式的祕密,藏在了這 15 張圖裡行程
- KaiwuDB 亮相中國 5G+工業網際網路大會,助力新型工業化AI
- 改進大語言模型的最全方法!模型
- 騰訊遊戲商業化方法論之賣什麼遊戲
- Oracle效能優化方法論的發展之四:基於資源瓶頸分析的優化方法論Oracle優化
- 大資料分析方法,你都知道哪些?大資料
- 激勵方法論1、馬斯洛需求模型模型
- Oracle效能優化方法論的發展之三:基於響應時間分析的效能優化方法論Oracle優化
- 5G在工業中應用的討論
- 【工業4.0】工業4.0時代的大生產體系架構架構
- Mata論文:大模型首次用於自動化單元測試改進大模型
- 語義模型在智慧工業運營中的作用模型
- 【工業大資料】製造業大資料標準化應用及成功案例分析大資料
- 再利用OSM模型、UJM模型等指標體系建設方法論模型指標
- 跑ChatGPT體量模型,從此只需一塊GPU:加速百倍的方法來了ChatGPT模型GPU