資料智能時代，計算是剛需，也是痛點，最主要的特點就是一個字－大。
將「大」分割成三個特點，則包括：
這囊括了資料和演算法的複雜性，而資料、演算法、算力是智慧時代三要素，前兩者的複雜性最後都要由算力承載。
這使得業界對算力的需求在空間和時間上都極速膨脹，有如海嘯之勢。
GPU 卻有辦法將海嘯在空間上細分成萬千條涓涓細流，在時間上縮短流水的路徑，在結構上精簡路徑分支，將大規模任務層層拆解成小規模任務，舉重若輕般承載了海量算力需求，成為智慧時代的算力基礎。 針對上述三個特點，GPU 基於吞吐量、顯存等指標，分別採用平行、融合、簡化三種方法，在算子層面進行加速。GPU 加速的主要方法論，也適用於大模型的工業化。
伴隨底層晶片、算力、數據等基礎設施的完善和進步，全球AI 產業正逐步從運算智能走向感知智能、認知智能，並相應形成「晶片、算力設施、AI 框架&演算法模型、應用場景」的產業分工、協作體系。 2019 年以來，AI 大模型帶來問題泛化求解能力大幅提升，「大模型 小模型」逐步成為產業主流技術路線，驅動全球 AI 產業發展全面加速。
不久前，DataFun 舉辦《AI 大模型技術路線和工業化落地實踐》分享活動，來自NVIDIA、百度、字節跳動火山翻譯、騰訊微信等6 位專家，從模型訓練技術與推理方案、多語言機器翻譯的應用、大規模語言模型研發與落地等多面向，帶來AI大模型技術路線與工業化落地實務的精彩分享。他們在業界落地大模型的時候，很大程度上都採用了平行、融合與簡化的方法，也從訓練、推理層面延伸到了演算法建模層面。
#並行方法是一種空間換時間的方法，它將海嘯細分成涓涓細流。具體而言，對於資料大批量的計算，每個計算步驟的耗時都比較長。 GPU 利用並行運算，也就是把沒有運算依賴的資料盡可能並行，把大批量拆分成小批量，以減少每個運算步驟的 GPU 空閒等待時間，提高運算吞吐量。
為了實際完成大模型的訓練，就需要高效率的軟體框架，使得訓練在單一GPU、單一節點甚至在大規模叢集上都有很好的運算效率。 因此，NVIDIA 開發了 Megatron 訓練框架。Megatron 採用了模型並行、Sequence 並行等最佳化手段以高效地訓練 Transformer 大模型，可訓練萬億級參數量的模型。
在演算法建模層面，火山翻譯和百度主要對 MoE 模型等建模方法進行了探索。模型並行可分為 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 兆參數規模的模型。
#Tensor 並行其實並沒有對Layer-norm 以及Dropout做拆分，因此這兩個算子在每個GPU 之間是複製的。
然而，這些操作本身不需要大量計算，卻非常佔用啟動記憶體。
為此，Megatron 又提出了 Sequence 並行的最佳化方法。 Sequence 並行的好處是不會增加通訊量，並且可以大幅減少顯存佔用
由於 Layer-norm 和 Dropout 沿著序列的維度是獨立的，因此可以按照 Sequence 維度進行拆分。
使用了 Sequence 並行之後，對於超大規模的模型而言，其實顯存佔用量還是很大的。因此，Megatron 又引進了激活重計算技術。
Megatron 的做法是，找到一些計算量很少但顯存佔用很大的算子，例如Attention 裡的Softmax、Dropout 等算子，對這些算子進行激活重計算就可以顯著減少顯存，且計算開銷增加不大。
Sequence 並行和選擇性激活重計算的結合可以將顯存佔用降低到原來的 1/5 左右。相對於原本直接將所有活化進行重計算的方案，其顯存也只有其兩倍，同時計算開銷顯著降低，並且隨著模型規模增大，計算開銷的佔比也會逐漸降低。到萬億規模模型的時候，重計算的開銷只佔整體的 2% 左右。
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 分析來優化。
多卡推理方案增加了通訊開銷，對模型推理延遲有一定影響。
#融合是解決平行運算中遇到的自然矛盾的方法，平行計算和串列計算是兩種基本的計算模式。而在應用平行運算的時候，最典型的困難就是大量的串列依賴，以及因此產生的中間值顯存佔用問題，而 GPU 顯存通常會成為大模型訓練和推理的硬體效能瓶頸之一。
對於海量計算串行依賴問題，最主要的方法是將細流的路徑縮短，也就是減少中間停留過程。 具體來說，就是利用算子融合，把次序存在先後依賴關係的算子合併，以減少顯存佔用。
算符融合不僅在運算層面，也可以在運算子設計層面實現。
#Pipeline 並行中如果將前向和反向過程分開，就會出現顯存佔用過多問題。
因此，Megatron 又提出了 Pipeline 並行的新模式 1F1B，每個 GPU 以交替的方式執行每個 micro batch 的正向和反向過程，以儘早釋放其佔用的顯存，進而減少顯存佔用。
1F1B 並不能減少 bubble time，為了進一步減少 bubble time，Megatron 又提出了 interleaved 1F1B 模式。也就是原本每個 GPU 負責連續 4 個層的運算，現在變成負責連續兩層的運算，只有原來的一半，從而 bubble time 也變成了原來的一半。
當在做GPU 運算的時候，每個運算流程都可以封裝成一個GPU 的Kernel，放到GPU 上執行，且是順序性的。傳統的算子庫為了通用性，會把算子設計的非常基本，因此數量也非常多，帶來的弊端是顯存佔用多，因為需要存儲大量的中間隱藏表示，另外這對頻寬的要求也比較高，最終可能造成延遲或性能損失。
火山翻譯基於 CuBLAS 乘法介面將其他非矩陣乘法算子進行了融合，包括了 Softmax、LayerNorm 等。
除了比較通用算子的融合，火山翻譯還針對一些特定算子比如Beam Search 無法很好地利用GPU 並行性的特點，優化其計算依賴問題，從而實現加速。
在四個主流 Transformer 模型上，LightSeq 算子融合在 PyTorch 的基礎上取得了最高 8 倍的加速。
#簡化是比較簡單直覺的加速方式，在細微處將流水分支精簡。具體而言，就是對於計算高複雜性，在保證性能的前提下將算子複雜度簡化，最終減少計算量。
超大規模模型的單卡推理一般會涉及模型壓縮。
常見的模式壓縮方案是量化、蒸餾和剪枝。量化是業界最常用的模型壓縮方案之一。雖然量化的計算採用了更低的精度，但可以保持模型的參數量級，在某些情況下或許能更好地保證模型整體的精度。
#目前有兩種量化方法，一種是訓練後量化，一種是量化感知訓練。後者通常比前者對模型的精度保持更好。
完成量化後，可以透過 TensorRT 或 FasterTransformer 等推理加速框架，進一步加速超大模型的推理。
LightSeq 在訓練過程的量化中採用了真 int8 量化，也就是在矩陣乘法之前，會執行量化操作，並且在矩陣乘法之後才執行反量化操作。而不像過去的偽量化那樣，在矩陣乘法之前就執行了量化和反量化操作，以讓模型適應量化所帶來的損失和波動。後者在實際運算中並不能帶來加速，反而可能增大延時，或使得顯存佔用上升。而真 int8 量化在實際應用上也帶來了很好的加速效果。
#第二種模式壓縮方式是蒸餾。蒸餾可以針對不同應用場景採用不同的策略對超大模型進行壓縮，在某些情況下，蒸餾可以讓超大模型擁有更好的泛化能力。
最後一種模型壓縮方案是剪枝。剪枝可分為全模型剪枝和部分層剪枝，對於超大模型，了解模型關鍵層非常重要，需要避開這些對精度影響最大的部分的剪枝，這對於稀疏 MoE 模型也是適用的。
大模型的研究和落地已成趨勢，預計在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 利用率。在 1,750 億參數的 GPT-3 模型上，GPU 使用率可達 52.8%。而在 5,300 億參數規模以上的模型上，利用率可達 57%。
也就是說，根據 Richard Sutton 的“贏家定律”，效率，將成為大模型工業化的主基調。
以上是大模型工業化的方法論，都藏在GPU裡的詳細內容。更多資訊請關注PHP中文網其他相關文章！
