聊聊字節(jié) AML 萬卡工作 MegaScale: Scaling Large Language Model Tr...

1. 摘要

字節(jié)介紹了用于訓(xùn)練大規(guī)模語言模型（LLM）的生產(chǎn)系統(tǒng) MegaScale。在這個系統(tǒng)上高效穩(wěn)定的在萬卡級別進(jìn)行千億級別模型訓(xùn)練。同時考慮到訓(xùn)練計算的高效性，通過模型塊和優(yōu)化器設(shè)計、計算和通信重疊、算子優(yōu)化、數(shù)據(jù)流水線和網(wǎng)絡(luò)性能調(diào)優(yōu)來共同設(shè)計算法和系統(tǒng)組件?？紤]到LLM訓(xùn)練作業(yè)的長時間跨度。許多穩(wěn)定性問題只有在大規(guī)模下才會出現(xiàn)，而深入的可觀測性是解決這些問題的關(guān)鍵。我們開發(fā)了一套診斷工具，用于監(jiān)控系統(tǒng)組件和堆棧中的事件，識別根本原因，并得出有效的技術(shù)來實現(xiàn)容錯和減輕滯后現(xiàn)象。在使用 12,288 個 GPU 訓(xùn)練 175B 的 LLM 模型時，MegaScale 實現(xiàn)了 55.2% 的模型 FLOPs 利用率（MFU），相比 Megatron-LM 提高了 1.34 倍的MFU。

2.整體介紹

大規(guī)模語言模型（LLM）已成為人工智能（AI）中一項具有變革性的技術(shù)。LLM的最新進(jìn)展顯著提升了它們的能力。LLM 在機(jī)器翻譯、文本摘要和對話代理等廣泛領(lǐng)域展示了巨大潛力。訓(xùn)練 LLM 是一項艱巨的任務(wù)，需要大量的計算資源。scaling law 規(guī)定了模型大小和訓(xùn)練數(shù)據(jù)大小是決定模型能力的關(guān)鍵因素。為了實現(xiàn)最先進(jìn)的模型能力，許多工作致力于在數(shù)千億甚至數(shù)萬億參數(shù) tokens 大型模型上進(jìn)行訓(xùn)練。這里介紹了字節(jié)面對數(shù)十億用戶的場景，有著廣闊的人工智能場景。LLM 訓(xùn)練的規(guī)模之大從系統(tǒng)的角度引入了兩個特定的挑戰(zhàn)：

• 第一個挑戰(zhàn)是在大規(guī)模情況下實現(xiàn)高效的訓(xùn)練。模型 FLOPs 利用率（MFU），即吞吐量與理論最大吞吐量（假設(shè)使用100%的峰值FLOPs）之間的比率最大化。（集合通信，op優(yōu)化、數(shù)據(jù)預(yù)處理和GPU內(nèi)存消耗等因素對 MFU 產(chǎn)生重要影響）

• 第二個挑戰(zhàn)是在大規(guī)模情況下實現(xiàn)高穩(wěn)定性的訓(xùn)練，即在整個訓(xùn)練過程中保持高訓(xùn)練效率。從生產(chǎn)的角度來看，穩(wěn)定性尤為重要，因為 LLM 的訓(xùn)練時間很長。（故障和滯后對于大模型訓(xùn)練資源浪費(fèi)是巨大的）

在這篇論文中，介紹了 MegaScale，一個用于大規(guī)模訓(xùn)練 LLM 的生產(chǎn)系統(tǒng)的設(shè)計、實現(xiàn)和工程經(jīng)驗。MegaScale 能夠?qū)?LLM 訓(xùn)練擴(kuò)展到超過 10,000 個GPU。我們能夠利用大量GPU的計算能力來高效穩(wěn)定地訓(xùn)練 LLM。在構(gòu)建和運(yùn)行 MegaScale 時，我們應(yīng)用了兩個系統(tǒng)原則：算法與系統(tǒng)的協(xié)同設(shè)計和深入的可視化性。修改/優(yōu)化包括：并行Transformer、滑動窗口注意力和LAMB 優(yōu)化器。利用混合并行策略，包括數(shù)據(jù)并行、流水線并行、張量并行和序列并行。重要的是，針對每種并行策略的模式設(shè)計了定制的技術(shù)，以最大程度地增加通信和計算之間的重疊。應(yīng)用 prefetching 和 treebased loading 來優(yōu)化數(shù)據(jù)流水線。利用 non-blocking asynchronous operations 操作，并消除大規(guī)模集體通信組初始化的全局 barriers。設(shè)計了自定義的網(wǎng)絡(luò)拓?fù)?，減少了 ECMP 哈希沖突，定制了擁塞控制，并調(diào)整了重傳超時參數(shù)以實現(xiàn)高網(wǎng)絡(luò)性能。（通讀論文后發(fā)現(xiàn)，這篇論文對現(xiàn)世的技術(shù)都做了很細(xì)致修改和優(yōu)化，確實是投入了很大的人力和物力）

3.優(yōu)化介紹

本節(jié)將深入探討用于優(yōu)化大模型訓(xùn)練的方法，以實現(xiàn)高效的大規(guī)模訓(xùn)練效果。（全是干貨，高能預(yù)警）

3.1 算法優(yōu)化

3.1.1 Parallel transformer block

采用這種方法，attention block 和 MLP block 的計算可以并行執(zhí)行，從而減少計算時間。先前的研究表明，這種修改不會降低具有數(shù)千億參數(shù)的模型的質(zhì)量。如下圖1所示。

3.1.2 Sliding window attention (SWA)

滑動窗口 attention 是一種稀疏注意力機(jī)制，它在輸入序列中的每個標(biāo)記周圍使用一個固定大小的窗口。其計算復(fù)雜度為O(s×w)，其中 s 是輸入序列的長度，w 是固定的窗口大小。相對于計算復(fù)雜度為O(s×s)的完全自注意力機(jī)制，滑動窗口注意力更加高效，前提是w ? s。先前的研究和字節(jié)的基準(zhǔn)測試表明，通過堆疊這種窗口注意力的層，可以保留整個輸入的信息，從而實現(xiàn)更快的訓(xùn)練而不降低準(zhǔn)確性。

3.1.3 LAMB optimizer

在大規(guī)模訓(xùn)練中，通常會受到 batch size 的限制。特別是，增加 batch size 可能會對模型的收斂產(chǎn)生不利影響。LAMB優(yōu)化器已經(jīng)證明可以將 BERT 的訓(xùn)練 batch size 擴(kuò)展到 64K 而不降低準(zhǔn)確性。在LLM設(shè)置中，字節(jié)的實驗證明，LAMB 可以將 batch size 擴(kuò)展到 4 倍而不損失準(zhǔn)確性。因此，通過 LAMB 優(yōu)化器，MegaScale 減少了87.5%的 pipeline bubbles。

3.2 集合通信優(yōu)化

3.2.1 Overlapping in data parallelism

在 3D 并行中，單個設(shè)備可能承載多個 model chunks。為了最大限度地利用帶寬，重疊計算是基于 model chunks 進(jìn)行的。all-gather 操作在模型塊的前向傳遞之前觸發(fā)，減少 reduce-scatter 操作在其后向傳遞之后開始。這導(dǎo)致了一個挑戰(zhàn)，即無法隱藏第一個 all-gather 操作和最后一個 reduce-scatter 操作。受 PyTorch FSDP 的啟發(fā)，初始的 all-gather 操作在每次迭代開始時預(yù)取，使其能夠與數(shù)據(jù)加載操作重疊，有效地將通信時間減少了1 /（2 * vpp_size）的因子。我們還首先啟動高優(yōu)先級的通信，以最大程度地實現(xiàn)重疊。通信操作的優(yōu)先級由依賴于通信結(jié)果的相應(yīng)計算操作的順序確定。如下圖 2 所示。

all-gather 操作能夠與數(shù)據(jù)加載操作重疊。

3.2.2 Overlapping in pipeline parallelism

在 pipeline parallelism 中的重疊計算。pipeline parallelism 采用 point-to-point 的發(fā)送/接收通信方式。MegaScale使用了前文提到的 interleaved 1F1B 調(diào)度方法。我們注意到，在熱身階段，前向傳遞只依賴于其前一個接收操作。因此，我們將發(fā)送和接收操作解耦，這兩個操作通常是一起實現(xiàn)的，并且可能被較慢的操作阻塞。通過打破這種依賴關(guān)系，我們使發(fā)送操作能夠與計算重疊，如下圖 3 左側(cè)所示。冷卻階段可以看作是熱身階段的逆過程，允許對相同技術(shù)進(jìn)行逆向應(yīng)用。至于穩(wěn)定階段，前向和后向計算都不依賴于相鄰的通信操作。以后向計算為例，如下圖3右側(cè)所示，它的前一個接收操作是為下一個前向計算而進(jìn)行的，而發(fā)送操作是為前一階段的后向計算而進(jìn)行的。因此，發(fā)送和接收操作可以異步啟動，與計算重疊進(jìn)行。

3.2.3 Overlapping in tensor/sequence parallelism

在張量/序列并行中的重疊計算。張量并行常用于在計算密集型操作中對權(quán)重進(jìn)行分區(qū)，而像LayerNorm 和 Dropout 這樣的操作則沿序列維度進(jìn)行分區(qū)以節(jié)省 GPU 內(nèi)存。這需要進(jìn)行all-gather 和 reduce-scatter 操作，以便在 GPU 之間進(jìn)行輸入收集和輸出重新分配。如下圖 4 展示了 parallel transformer block 架構(gòu)中的通信模式。在這里，這兩個通信操作位于關(guān)鍵路徑上。為了消除這種開銷，選擇將 all-gather 和 reduce-scatter 與 FFN 路徑上的并行線性層融合在一起。由于 FFN 路徑上的 GEMM 內(nèi)核更大，通信可以更好地隱藏起來。將GEMM 內(nèi)核分成小塊，并將執(zhí)行與通信進(jìn)行流水線處理。這種策略可以類似地應(yīng)用于反向傳遞中。

3.3 Efficient Operators

• attention part：采用了FlashAttention-2

• LayerNorm 和 GeLU：將這些 kernel fuse 在一起，我們減少了啟動多個 kernel 所帶來的開銷，并有助于優(yōu)化內(nèi)存訪問模式，從而實現(xiàn)更好的性能。

3.4 Data Pipeline

• 異步數(shù)據(jù)預(yù)處理：數(shù)據(jù)預(yù)處理不在關(guān)鍵路徑上。因此，在每個訓(xùn)練步驟結(jié)束時，當(dāng)GPU 在同步梯度時，下一個步驟的數(shù)據(jù)預(yù)處理可以開始，這樣就隱藏了預(yù)處理的開銷。

• Redundant dataloader elimination：在分布式訓(xùn)練的典型數(shù)據(jù)加載階段中，每個GPU工作器都配備有自己的數(shù)據(jù)加載器，負(fù)責(zé)將訓(xùn)練數(shù)據(jù)讀入 CPU內(nèi)存，然后將其傳遞給GPU。這導(dǎo)致工作器之間競爭磁盤讀取帶寬，從而創(chuàng)建了一個瓶頸。值得注意的是，在 LLM 訓(xùn)練設(shè)置中，同一臺機(jī)器上的 GPU 工作器屬于相同的張量并行組（通常tp放置在機(jī)內(nèi)）。因此，它們每次迭代的輸入本質(zhì)上是相同的。基于這個觀察，我們采用了一個基于兩層tree-based 的方法。我們在每臺機(jī)器上使用一個單獨(dú)的專用數(shù)據(jù)加載器將訓(xùn)練數(shù)據(jù)讀入一塊共享內(nèi)存中。隨后，每個 GPU 負(fù)責(zé)將必要的數(shù)據(jù)復(fù)制到對應(yīng)的 GPU 內(nèi)存中。這消除了冗余的讀取，并顯著提高了數(shù)據(jù)傳輸?shù)男省?/p>

3.5 Collective Communication Group Initialization

在分布式訓(xùn)練中，初始化階段涉及在 GPU之間建立NVIDIA Collective Communications Library (NCCL)通信組。當(dāng) GPU 數(shù)量擴(kuò)展到一萬多個時，使用torch.distributed的開銷很大。字節(jié)在同一個AI集群上進(jìn)行了實驗，實證測量結(jié)果表明，在 2048 個NVIDIA Ampere GPU上，Megatron-LM 的初始化時間約為 1047 秒。重啟次數(shù)較大時開銷很大。

導(dǎo)致初始化時間過長的兩個主要原因：

• 第一個問題出現(xiàn)在同步步驟中，每個進(jìn)程在初始化特定通信組結(jié)束時都會進(jìn)行 barrier 操作。PyTorch中使用 TCPStore 在內(nèi)部對通信連接進(jìn)行分布式鍵值存儲，單線程的阻塞讀寫方式運(yùn)行。將 TCPStore 替換為 非阻塞、異步的 Redis。這將在 2048 個GPU上將初始化時間縮短到 361 秒。(這部分按照我的理解畫了如下圖5示意圖)
  

• 第二個問題與全局 barrier 的不謹(jǐn)慎使用有關(guān)。每個進(jìn)程在初始化其相應(yīng)的通信組后都會執(zhí)行一個全局 barrier。我們仔細(xì)設(shè)計了通信組初始化的順序，以最小化對全局 barrier 的需求。這種方法將全局 barrier 的時間復(fù)雜度從O(n^2) 降低到 O(n)。經(jīng)過這些優(yōu)化，初始化時間在 2048 個 GPU 上縮短到不到 5 秒，在超過 10,000 個 GPU 上縮短到不到 30 秒。

3.6 Network Performance Tuning

網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。字節(jié)的數(shù)據(jù)中心網(wǎng)絡(luò)采用基于 Broadcom Tomahawk 4 芯片的高性能交換機(jī)構(gòu)建。每個 Tomahawk 芯片的總帶寬為 25.6Tbps，具有 64 個400Gbps端口。三層交換機(jī)以類似 CLOS 的拓?fù)浣Y(jié)構(gòu)連接，用于連接超過 10,000 個 GPU。對于每一層的交換機(jī)，下行鏈路和上行鏈路之間的帶寬比例為1:1。也就是說，32個端口用作下行鏈路，32個端口用作上行鏈路。該網(wǎng)絡(luò)提供高帶寬和小直徑。每個節(jié)點(diǎn)可以在有限的跳數(shù)內(nèi)與其他節(jié)點(diǎn)進(jìn)行通信。

3.6.1 Reducing ECMP hashing conflicts

字節(jié)精心設(shè)計網(wǎng)絡(luò)拓?fù)洳才啪W(wǎng)絡(luò)流量，以減少 ECMP 哈希沖突。首先，在頂級機(jī)架交換機(jī)（ToR）級別，將一個 400 G下行鏈路端口分成兩個帶有特定 AOC 電纜的 200G 下行鏈路端口。由于每個上行鏈路的帶寬是下行鏈路的兩倍，沖突概率降低了。其次，服務(wù)器上的 8 個200G 網(wǎng)卡以多重連接方式連接到 8 個不同的交換機(jī)上。通過相同的一組 ToR 交換機(jī)連接的GPU 服務(wù)器數(shù)量可以達(dá)到 64 個。我們策略性地將我們訓(xùn)練任務(wù)中的數(shù)據(jù)密集節(jié)點(diǎn)調(diào)度到同一個機(jī)架頂部（ToR）交換機(jī)下運(yùn)行。這種方法顯著減少了通信所需的交換機(jī)跳數(shù)，并進(jìn)一步降低了 ECMP 哈希沖突的概率。(這部分按照我的理解畫了如下圖6示意圖)

3.6.1 擁塞控制

在分布式訓(xùn)練中，當(dāng)默認(rèn)使用 DCQCN 協(xié)議時，all-to-all 通信可能導(dǎo)致?lián)砣瓦^度使用優(yōu)先級流控制（PFC）。過度使用 PFC 可能導(dǎo)致（HoL blocking），從而降低網(wǎng)絡(luò)吞吐量。為了緩解這些問題，字節(jié)開發(fā)了一種算法，結(jié)合了 Swift 和 DCQCN 的原理，將往返時延（RTT）的精確測量與顯式擁塞通知（ECN）的快速擁塞響應(yīng)能力相結(jié)合。這種方法顯著增強(qiáng)了吞吐量，并最小化與PFC 相關(guān)的擁塞問題。

3.6.2 Retransmit timeout setting

可以通過設(shè)置 NCCL 中的參數(shù)來控制重傳計時器和重試次數(shù)，我們調(diào)整這些參數(shù)以實現(xiàn)在鏈路抖動下的快速恢復(fù)。為了進(jìn)一步減少恢復(fù)時間，我們在網(wǎng)卡上啟用了 adap_retrans 功能。該功能可以在較短的間隔內(nèi)進(jìn)行重傳，并在鏈路抖動時間較短時更快地恢復(fù)傳輸。

4. Fault Tolerance

隨著訓(xùn)練集群規(guī)模擴(kuò)大到數(shù)萬個 GPU，軟件和硬件故障幾乎是不可避免的。為了實現(xiàn)自動故障識別和快速恢復(fù)，在 LLM 訓(xùn)練中引入了一個強(qiáng)大的訓(xùn)練框架，實現(xiàn)了最小人為干預(yù)和對正在進(jìn)行的訓(xùn)練任務(wù)幾乎沒有影響的容錯能力。

4.1 Robust Training Workflow

如圖 8 所示，當(dāng)接收到提交的訓(xùn)練任務(wù)時，驅(qū)動程序與自定義的 Kubernetes 接口進(jìn)行交互，以分配計算資源并為每個執(zhí)行器啟動相應(yīng)的 Pod。一個執(zhí)行器管理一個節(jié)點(diǎn)。一旦執(zhí)行器完成一系列的初始化任務(wù)，它會在每個 GPU 上創(chuàng)建訓(xùn)練進(jìn)程和一個強(qiáng)大的訓(xùn)練守護(hù)進(jìn)程，后者會定期向驅(qū)動程序發(fā)送心跳信號。這些心跳信號封裝了各種形式的信息，以實現(xiàn)實時異常檢測并提前發(fā)出警告。當(dāng)驅(qū)動程序檢測到特定訓(xùn)練進(jìn)程的異常狀態(tài)，或者在預(yù)定義的時間窗口內(nèi)未收到執(zhí)行器的心跳信號時，它將觸發(fā)故障恢復(fù)過程。驅(qū)動程序會暫停所有執(zhí)行器上正在進(jìn)行的訓(xùn)練任務(wù)，并命令它們運(yùn)行一系列自檢診斷。

4.2 Data Collection and Analysis

心跳消息包括執(zhí)行器的基本信息，如 IP 地址、Pod 名稱和硬件信息等。此外，還報告了訓(xùn)練進(jìn)程的當(dāng)前狀態(tài)，使驅(qū)動程序能夠及時檢測到任何明顯的異常。訓(xùn)練進(jìn)程的 stdout/stderr 日志也包括在內(nèi)。它們將被實時聚合、過濾和分析。如果檢測到特定的警告或錯誤關(guān)鍵詞，驅(qū)動程序?qū)蟾鎸崟r的診斷信息。此外，RDMA 流量指標(biāo)也包括在內(nèi)，用作網(wǎng)絡(luò)利用率和效率的指標(biāo)。訓(xùn)練過程中的某些異?？赡懿粫憩F(xiàn)為明顯的錯誤，使得訓(xùn)練似乎按預(yù)期進(jìn)行。在這種情況下，RDMA 流量指標(biāo)起到了關(guān)鍵的指示作用。由于訓(xùn)練任務(wù)的周期性特性，每個步驟的網(wǎng)絡(luò)流量特征應(yīng)該呈現(xiàn)類似的模式。因此，RDMA 流量的顯著下降或異常波動是潛在異常的信號。在檢測到這種異常情況時，驅(qū)動程序?qū)l(fā)出警報以進(jìn)行手動調(diào)查。如果流量完全停止，驅(qū)動程序?qū)⒆詣訂庸收匣謴?fù)過程。

為了增強(qiáng)對訓(xùn)練穩(wěn)定性和性能的監(jiān)控，字節(jié)開發(fā)了一個精度達(dá)到毫秒級的監(jiān)控系統(tǒng)。采用不同級別的監(jiān)控來跟蹤各種指標(biāo)。第二級監(jiān)控通常用于評估整體健康狀況，并排除對訓(xùn)練的常見配置影響。例如，ECN/PFC/QoS配置、鏈路抖動或其他網(wǎng)卡問題。另一方面，毫秒級監(jiān)控用于確定網(wǎng)絡(luò)是否擁塞，以及數(shù)據(jù)并行性和管道并行性的數(shù)據(jù)傳輸速度是否達(dá)到了物理限制。

4.3 Diagnostic Tests

在自檢診斷中，執(zhí)行時間和準(zhǔn)確性之間存在權(quán)衡。延長診斷持續(xù)時間可能會對有效的訓(xùn)練時間產(chǎn)生不利影響，而高誤報率可能會導(dǎo)致對實際上正常工作的機(jī)器進(jìn)行不必要的排除。字節(jié)部署了一套輕量級的診斷測試，能夠有效覆蓋在實際訓(xùn)練過程中遇到的廣泛硬件和軟件故障。

• Intra-host network tests
  針對主機(jī)內(nèi)部網(wǎng)絡(luò)的測試。為了診斷主機(jī)內(nèi)部網(wǎng)絡(luò)潛在的瓶頸，我們使用我們內(nèi)部開發(fā)的工具進(jìn)行兩項測試。

  • 第一項是回環(huán)測試（Loopback test），它測量了所有RDMA網(wǎng)卡（RNIC）與各種主機(jī)內(nèi)部終點(diǎn)（包括內(nèi)存節(jié)點(diǎn)和GPU）之間的回環(huán)帶寬。這使得能夠根據(jù)端到端帶寬結(jié)果推斷鏈路特定的帶寬降低和 PCIe 配置的異常。

  • 第二項是 RNIC 到 RNIC 的測試，它檢查同一主機(jī)上不同 RNIC 之間的連接性和帶寬性能。這些測試可以提供關(guān)于 RNIC 是否符合硬件速度規(guī)格以及底層路由配置是否正確的信息。通過這些測試，我們可以了解到主機(jī)內(nèi)部網(wǎng)絡(luò)的性能狀況，以及可能存在的硬件或配置問題。

• NCCL tests：為了識別 GPU 通信中的潛在故障，我們在單個節(jié)點(diǎn)內(nèi)的所有 GPU 之間運(yùn)行全互連測試，觀察帶寬是否與預(yù)期的基準(zhǔn)相符。一旦通過了主機(jī)內(nèi)通信測試，每個節(jié)點(diǎn)還會在同一 ToR 交換機(jī)下與相鄰機(jī)器進(jìn)行全歸約測試，以評估節(jié)點(diǎn)間的 GPU 通信。通過這些測試，我們可以檢查 GPU 之間的通信性能，并確定是否存在潛在的故障或性能問題。這些測試有助于確保 GPU 之間的高效通信，并為訓(xùn)練任務(wù)提供良好的性能。

4.4 Fast Checkpointing and Recovery

在識別和驅(qū)逐故障節(jié)點(diǎn)之后，驅(qū)動程序需要通過加載最近的檢查點(diǎn)中的模型權(quán)重和優(yōu)化器狀態(tài)來恢復(fù)訓(xùn)練。確保最新的檢查點(diǎn)盡可能接近故障發(fā)生時的訓(xùn)練進(jìn)度狀態(tài)非常關(guān)鍵，以最小化計算和時間上的損失。這要求在訓(xùn)練過程中增加檢查點(diǎn)的頻率，同時減少加載 checkpoint 過程引入的延遲，特別是阻塞訓(xùn)練進(jìn)度的關(guān)鍵路徑上的時間，以提高整個系統(tǒng)的吞吐量。

為了實現(xiàn)快速的檢查點(diǎn)操作，引入了一個優(yōu)化的兩階段方法。

• 在第一階段，每個 GPU 工作進(jìn)程將其片上狀態(tài)寫入主機(jī)內(nèi)存，然后繼續(xù)訓(xùn)練過程。通過優(yōu)化 PyTorch 的序列化機(jī)制和使用固定內(nèi)存，由于高速的 PCIe 帶寬，這個過程可以在幾秒鐘內(nèi)完成，從而最小程度地中斷正在進(jìn)行的訓(xùn)練過程。

• 在第二階段，一個后臺進(jìn)程接管，異步地將狀態(tài)從主機(jī)內(nèi)存?zhèn)鬏數(shù)椒植际轿募到y(tǒng)（部署中為HDFS），以進(jìn)行集中維護(hù)。將操作分解為兩個階段使得 GPU 工作進(jìn)程在轉(zhuǎn)儲狀態(tài)后幾乎可以立即恢復(fù)訓(xùn)練，而寫入 HDFS 的耗時過程則由一個獨(dú)立的非阻塞進(jìn)程來完成。

為了緩解了 HDFS 的帶寬限制，同一數(shù)據(jù)并行組中的工作進(jìn)程。因此，我們指定組中的一個工作進(jìn)程從 HDFS 中讀取共享的狀態(tài)分區(qū)，從而線性減少負(fù)載。然后，這個工作進(jìn)程將狀態(tài)分區(qū)廣播給所有共享相同數(shù)據(jù)的其他 GPU 工作進(jìn)程。這種方法有效地緩解了HDFS的帶寬限制，大大減少了恢復(fù)時間。

這些監(jiān)控和分析工具的實施是為了應(yīng)對那些不易察覺的問題，以確保訓(xùn)練過程的順利進(jìn)行。它們提供了額外的保障，幫助我們在面對硬件異常時能夠更加全面地了解問題，并采取適當(dāng)?shù)拇胧﹣斫鉀Q這些問題，以確保訓(xùn)練的成功進(jìn)行。

5. Training Troubleshooting

對于一些硬件異常，無法通過自檢發(fā)現(xiàn)的問題，字節(jié)實現(xiàn)了以下異常檢測的監(jiān)控和分析工具。

5.1 Performance Diagnosis with CUDA Event Monitor

在數(shù)萬個 GPU 的規(guī)模下，我們觀察到與規(guī)模較小的實驗不同的是，不同的運(yùn)行會展現(xiàn)出不同的計算效率。即使在相同的配置下，這種不一致性仍然存在，正如圖 9 所示。還觀察到在這個規(guī)模下，訓(xùn)練任務(wù)的性能并不一致。各種訓(xùn)練任務(wù)的最大工作集（MFU）隨時間逐漸下降。雖然這使我們懷疑個別機(jī)器之間存在差異，但在單個 GPU 的 GEMM 微基準(zhǔn)測試中沒有發(fā)現(xiàn)明顯的差異。

為了診斷這些性能問題，我們開發(fā)了一個性能分析工具，記錄每個機(jī)器排名在運(yùn)行過程中關(guān)鍵代碼段的執(zhí)行時間。與之前的工具（如 torch 分析器或 MegatronLM 計時器）不同，我們的工具基于 CUDA events 方法計時。這種方法最大程度地減少了對 CUDA 同步的需求，從而防止性能下降，并使我們能夠在生產(chǎn)訓(xùn)練作業(yè)中始終穩(wěn)定地運(yùn)行它。

這個工具提供了兩種可視化模式，并可以從不同的角度分析收集到的數(shù)據(jù)。通過這個工具，我們可以更好地理解訓(xùn)練過程中的性能問題，并從不同的視角進(jìn)行分析，以找出潛在的原因并采取相應(yīng)的措施來解決這些問題。

• 第一種模式使用熱圖來顯示不同維度上機(jī)器之間的時間消耗差異，如圖 10 所示。字節(jié)收集了計算階段（前向和后向）跨設(shè)備的延遲數(shù)據(jù)，并對步驟的延遲進(jìn)行平均。聚合的數(shù)據(jù)使用熱圖進(jìn)行可視化。熱圖顯示，在訓(xùn)練過程中，大約有 0.5% 的機(jī)器表現(xiàn)出明顯較慢的性能，從而影響整體的訓(xùn)練進(jìn)度。訓(xùn)練效率主要由最慢的機(jī)器（即滯后者）的性能決定，這導(dǎo)致不同運(yùn)行之間的訓(xùn)練效率不一致，因為集群內(nèi)的機(jī)器調(diào)度是隨機(jī)的。在排除這些異常機(jī)器之后，各次運(yùn)行的 MFU 變得一致。
  

• 另一種模式以跟蹤格式顯示不同分布式視圖（數(shù)據(jù)并行、流水線并行、張量并行）上的機(jī)器事件時間線。傳統(tǒng)的分析器（如PyTorch Profiler）主要設(shè)計用于單節(jié)點(diǎn)的活動分析。這種方法在執(zhí)行依賴關(guān)系經(jīng)?？缭蕉鄠€節(jié)點(diǎn)的分布式訓(xùn)練場景中提供的信息有限。通過將各個 rank 的跟蹤跨度聚合到一個時間線上，我們獲得了全面的視角，揭示了整體的執(zhí)行順序、流水線 bubble 和數(shù)據(jù)并行排名之間的同步特性。圖 11 顯示了字節(jié)的分布式跟蹤器如何可視化流水線并行的實際執(zhí)行情況，通過在流水線并行組中整合事件數(shù)據(jù)，詳細(xì)說明了不同流水線階段之間的數(shù)據(jù)依賴關(guān)系。

每個 CUDA events 計時器的數(shù)據(jù)都存儲在遠(yuǎn)程分析數(shù)據(jù)庫中，可以輕松地從任何步驟事件中檢索詳細(xì)信息。雖然計時器數(shù)據(jù)以逐行格式寫入本地文件，但一個獨(dú)立的流處理進(jìn)程會實時將此日志文件與 Kafka 隊列同步。分析數(shù)據(jù)庫通過消費(fèi)來自 Kafka 隊列的數(shù)據(jù)保持更新，實現(xiàn)了即時分析而不中斷訓(xùn)練作業(yè)。在真實的生產(chǎn)訓(xùn)練中，所有的監(jiān)控功能都被打開，與訓(xùn)練時間相比，額外開銷可以忽略不計。

5.2 3D Parallel Training Visualization

通過 3D 并行和字節(jié)的優(yōu)化技術(shù)，數(shù)據(jù)流和任務(wù)序列的情況變得非常復(fù)雜。每個 GPU 工作節(jié)點(diǎn)在給定時刻可能同時進(jìn)行多個同步或異步操作，導(dǎo)致它們之間存在復(fù)雜的依賴關(guān)系。這種復(fù)雜性增加了故障診斷的挑戰(zhàn)：當(dāng)單個GPU工作節(jié)點(diǎn)發(fā)生故障時，整個節(jié)點(diǎn)集群可能在 NCCL 通信操作中停滯，最終導(dǎo)致系統(tǒng)范圍的超時。在外部，這種情況表現(xiàn)為通用的阻塞，但其根本原因往往被大量的超時消息所掩蓋。為了快速定位有問題的節(jié)點(diǎn)，字節(jié)讓每個 GPU 工作節(jié)點(diǎn)在通信超時時記錄其正在進(jìn)行的事件。然后，利用這些日志根據(jù) 3D 并行設(shè)置中的邏輯拓?fù)錁?gòu)建數(shù)據(jù)依賴的可視化表示。

通過構(gòu)建基于邏輯拓?fù)涞臄?shù)據(jù)依賴可視化表示，能夠更好地理解和分析在 3D 并行設(shè)置中的數(shù)據(jù)流和任務(wù)序列。這有助于我們快速定位故障節(jié)點(diǎn)，并深入了解故障的根本原因。通過這種可視化表示，我們能夠更好地理解并解決由于故障而導(dǎo)致的節(jié)點(diǎn)間的通信問題，從而提高分布式訓(xùn)練的穩(wěn)定性和可靠性。

6. 大模型訓(xùn)練經(jīng)驗

在這一部分，描述了 MegaScale 的部署和運(yùn)營經(jīng)驗。為LLM（大型語言模型）訓(xùn)練構(gòu)建了專用的 A I集群。截至2023年9月，在生產(chǎn)環(huán)境中用于 LLM 訓(xùn)練的最大 AI 集群包含超過10,000個NVIDIA Ampere GPU。字節(jié)還正在基于最新的 NVIDIA Hopper GPU 構(gòu)建大規(guī)模集群，因為NVIDIA正在加快生產(chǎn)進(jìn)度。

6.1 Training Performance

175B 模型的強(qiáng)擴(kuò)展訓(xùn)練性能。在使用 3072 到 12288 個GPU進(jìn)行訓(xùn)練時，將 batch size 設(shè)置為 6144。對于 256 到 1024 個GPU，由于 GPU 內(nèi)存限制，我們將批量大小減小到 768。在此報告了訓(xùn)練 300B tokens 所需的訓(xùn)練時間。MFU 列中括號中的數(shù)字表示相較于Megatron-LM 的 MegaScale 加速比。

Megatron-LM 和 MegaScale 在 530B 模型上的弱擴(kuò)展訓(xùn)練性能，其中 batch size 與 GPU 數(shù)量成比例地進(jìn)行了縮放。

消融研究：字節(jié)評估了 MegaScale 優(yōu)化技術(shù)的有效性。圖 14 展示了在 256 個GPU上訓(xùn)練175B模型時，不同優(yōu)化技術(shù)對 MFU 改進(jìn)的詳細(xì)情況?；鶞?zhǔn)是原始的Megatron-LM，其MFU為 47.7%。值得注意的是，在這個評估中，Megatron-LM和MegaScale都開啟了網(wǎng)絡(luò)優(yōu)化。我們首先對Megatron-LM應(yīng)用了兩種算法技術(shù)，即并行 Transformer 塊和滑動窗口注意力，實現(xiàn)了 5.6% 的MFU改進(jìn)。通信是大規(guī)模語言模型訓(xùn)練的主要瓶頸，而 MegaScale 的 3D 并行通信重疊隱藏了開銷，并使訓(xùn)練加速了 6.2% 的MFU。進(jìn)一步采用了高效的op，獲得了 1.7% 的加速。其他優(yōu)化技術(shù)，如數(shù)據(jù)流水線優(yōu)化和 6.3 中提到的問題代碼消除，進(jìn)一步實現(xiàn)了 1.1% 的性能提升。最后，我們使用 LAMB 優(yōu)化器將批量大小從 256 擴(kuò)展到 768，這顯著延長了交錯流水線并行中的穩(wěn)定階段，并實現(xiàn)了 3.0% 的MFU改進(jìn)。綜上所述，通過所有這些優(yōu)化，MegaScale 在 MFU 數(shù)量上比基準(zhǔn)模型提高了 17.6%。

這些結(jié)果表明，MegaScale的優(yōu)化技術(shù)在提高訓(xùn)練性能方面非常有效。通過算法技術(shù)、通信優(yōu)化、高效運(yùn)算符以及其他優(yōu)化措施的應(yīng)用，MegaScale能夠顯著提高M(jìn)FU并加速訓(xùn)練過程。這些優(yōu)化技術(shù)的結(jié)合使得MegaScale在大規(guī)模語言模型訓(xùn)練中表現(xiàn)出色，并取得了顯著的性能提升。這進(jìn)一步證明了MegaScale作為一種高效的大規(guī)模訓(xùn)練解決方案的能力，并為加快語言模型研究和開發(fā)的進(jìn)展提供了有力支持。

6.2 Model Convergence and Stability

6.3 Problems Discovered and Fixed

字節(jié)對上述生產(chǎn)訓(xùn)練作業(yè)的故障記錄進(jìn)行了幾周的分析。研究結(jié)果表明，在這些記錄中，超過90%的異常情況都可以通過強(qiáng)大訓(xùn)練框架自動檢測、定位和恢復(fù)，例如 CUDA 錯誤和segmentation fault。檢測故障并執(zhí)行診斷測試所需的平均時間不到10分鐘。此外，系統(tǒng)可以在 latest checkpoints 后的 15 分鐘內(nèi)趕上訓(xùn)練進(jìn)度，保持超過90%的有效訓(xùn)練時間比例。

這些結(jié)果表明，MegaScale 具備強(qiáng)大的故障診斷和修復(fù)能力。通過自動檢測和定位異常情況，并在短時間內(nèi)執(zhí)行診斷測試，MegaScale 能夠快速恢復(fù)訓(xùn)練過程，并保持高效的訓(xùn)練時間利用率。這為大規(guī)模語言模型的生產(chǎn)訓(xùn)練提供了可靠的保障，減少了故障對訓(xùn)練過程的影響，并提高了訓(xùn)練的穩(wěn)定性和可靠性。同時，故障排除工具的應(yīng)用也為我們解決一些復(fù)雜問題提供了有力的支持，進(jìn)一步提升了訓(xùn)練的效率和可行性。

6.3.1 Computational stragglers

在利用CUDA events 計時器的基礎(chǔ)上，字節(jié)在多個實驗設(shè)置中進(jìn)行了另一個相關(guān)觀察。注意到，與其他節(jié)點(diǎn)相比，特定主機(jī)執(zhí)行相同的前向計算大約需要多出 10% 的時間。在不同實驗中的這種一致性觀察讓我們得出結(jié)論，問題不在于軟件，而是集群中某些機(jī)器固有的問題。在將這些有問題的主機(jī)從集群中隔離和移除后，我們觀察到MFU提高了約0.7%。

這個發(fā)現(xiàn)表明，在大規(guī)模語言模型的訓(xùn)練過程中，存在一些計算滯后的主機(jī)。這些主機(jī)的性能可能受到一些因素的影響，例如硬件配置或網(wǎng)絡(luò)連接。通過識別并排除這些問題主機(jī)，能夠提高整體的訓(xùn)練效率。0.7% 的 MFU 改進(jìn)雖然看似不大，但在大規(guī)模訓(xùn)練中，這個改進(jìn)可以顯著提升訓(xùn)練速度和資源利用率。因此，解決計算滯后者問題對于實現(xiàn)高效的大規(guī)模語言模型訓(xùn)練是非常重要的。

6.3.2 MFU decreasing

在這樣的大規(guī)模訓(xùn)練實驗中，字節(jié)觀察到訓(xùn)練效率并不是始終保持一致的。相反，隨著訓(xùn)練的進(jìn)行，訓(xùn)練作業(yè)的 MFU 逐漸下降。通過基于CUDA events 計時器指標(biāo)的逐步分析，我們注意到了幾個關(guān)鍵發(fā)現(xiàn)。

• 不規(guī)則的垃圾回收可能會給訓(xùn)練過程引入干擾

• PyTorch 操作可能會導(dǎo)致性能波動。

在修改或刪除這些有問題的代碼段之后，不再觀察到 MFU 的顯著下降，如圖16所示。

這個發(fā)現(xiàn)表明，在大規(guī)模訓(xùn)練中，存在一些導(dǎo)致訓(xùn)練效率下降的代碼段。這些代碼段的波動性可能會干擾訓(xùn)練過程，導(dǎo)致某些進(jìn)程的執(zhí)行時間延遲，從而影響整體訓(xùn)練效率。通過識別并修改或刪除這些有問題的代碼段，我們能夠提高訓(xùn)練的穩(wěn)定性和效率，避免 MFU 的明顯下降。這進(jìn)一步證明了 MegaScale 的故障診斷和修復(fù)能力的重要性，以及故障排除工具在解決復(fù)雜問題中的作用。

6.3.3 Frequent network interface flapping problem

偶爾會遇到訓(xùn)練停滯或訓(xùn)練速度下降的問題，原因是頻繁的網(wǎng)絡(luò)接口抖動。當(dāng)發(fā)生網(wǎng)絡(luò)接口抖動現(xiàn)象時，網(wǎng)絡(luò)接口首先會斷開，然后再次連接。斷開和重新連接之間的間隔通常持續(xù)幾秒鐘。在斷開的過程中，所有正在傳輸?shù)臄?shù)據(jù)包都會丟失。

• 從中學(xué)到的第一個教訓(xùn)是應(yīng)該將超時閾值明確地設(shè)置為較大的值（猜測是NCCL_IB_TIMEOUT），否則默認(rèn)值會使 NCCL 的超時時間非常短，在網(wǎng)絡(luò)卡重新連接之前就會返回完成錯誤。

• 學(xué)到的第二個教訓(xùn)是，這個問題的根本原因是網(wǎng)卡、AOC電纜和交換機(jī)之間的鏈路質(zhì)量不好。通過對網(wǎng)絡(luò)卡信號強(qiáng)度、AOC 電纜質(zhì)量和交換機(jī)側(cè)信號強(qiáng)度進(jìn)行較低級別的質(zhì)量控制，可以將抖動頻率降低到令人滿意的水平。

這個發(fā)現(xiàn)表明，頻繁的網(wǎng)絡(luò)接口抖動可能會對訓(xùn)練過程產(chǎn)生負(fù)面影響。由于網(wǎng)絡(luò)接口抖動導(dǎo)致數(shù)據(jù)包丟失，可能會導(dǎo)致訓(xùn)練停滯或訓(xùn)練速度下降。為了解決這個問題，需要采取一些措施來改善鏈路質(zhì)量，包括檢查和調(diào)整網(wǎng)絡(luò)卡信號強(qiáng)度、更換較低質(zhì)量控制的 AOC 電纜以及優(yōu)化交換機(jī)側(cè)的信號強(qiáng)度。通過降低抖動頻率，可以提高訓(xùn)練的穩(wěn)定性和效率。這也強(qiáng)調(diào)了在大規(guī)模訓(xùn)練中網(wǎng)絡(luò)基礎(chǔ)設(shè)施的重要性，以及對網(wǎng)絡(luò)連接質(zhì)量的監(jiān)控和維護(hù)的必要性。

7. 相關(guān)工作

EverFlow 、LossRadar 和NetBouncer 等工具利用交換機(jī)的能力來診斷網(wǎng)絡(luò)問題，如網(wǎng)絡(luò)路徑故障或特定網(wǎng)絡(luò)端口故障。NetBouncer利用IP-in-IP隧道技術(shù)進(jìn)行路徑探測。EverFlow需要將網(wǎng)絡(luò)數(shù)據(jù)包鏡像到集中服務(wù)器以進(jìn)行調(diào)試。（見原文）

8. 總結(jié)

在這篇論文中，深入研究了 MegaScale 的設(shè)計、實現(xiàn)和部署。MegaScale 是一個用于在超過10,000 個GPU的規(guī)模上進(jìn)行 LLM（Large Language Model）訓(xùn)練的生產(chǎn)級系統(tǒng)。MegaScale利用算法和系統(tǒng)的協(xié)同設(shè)計來優(yōu)化訓(xùn)練效率。在使用 12,288 個GPU訓(xùn)練一個 175B 的 LLM 模型時，MegaScale 實現(xiàn)了 55.2% 的最大訓(xùn)練吞吐量（MFU），相比于 Megatron-LM 有1.34 倍的改進(jìn)。強(qiáng)調(diào)在整個訓(xùn)練過程中需要容錯能力，并實現(xiàn)了一個定制的魯棒訓(xùn)練框架來自動定位和修復(fù)故障。提供了一套全面的監(jiān)控工具，用于對系統(tǒng)組件和事件進(jìn)行深入觀察，有助于識別復(fù)雜異常的根本原因。字節(jié)這篇工作細(xì)致的修改/優(yōu)化了現(xiàn)有 LLM 主流技術(shù)，給 LLM的訓(xùn)練的人員提供了實用的見解，也為這個快速發(fā)展的領(lǐng)域的未來研究鋪平了道路。

9. 參考

1. https://arxiv.org/pdf/2402.1562

- The End -

GiantPandaCV

長按二維碼關(guān)注我們

本公眾號專注：

1. 技術(shù)分享；

2. 學(xué)術(shù)交流；

3. 資料共享。

歡迎關(guān)注我們，一起成長！