一、背景

我們之前詳細介紹過在千卡和萬卡 GPU 集群中預訓練 LLM 的挑戰(zhàn)，其簡單來說可以總結(jié)為幾點：1. 優(yōu)化分布式策略，提升 MFU；2. 異步 Checkpointing，增加 Checkpointing 頻率，減少無效計算；3. 完善的故障診斷及任務恢復機制；4. 監(jiān)控和 Profiling 方案。

然而，在整個 LLM 的開發(fā)周期中，除了預訓練外還有很多其他階段，比如數(shù)據(jù)準備，微調(diào)以及模型評估等，如下圖 Figure 1 所示。這里我們介紹一篇上海 AI Lab 等團隊的工作，其從整個 LLM 集群的角度來揭示大規(guī)模 LLM GPU 集群與傳統(tǒng) DL 集群的差異，以及相應的優(yōu)化工作。

對應的論文為：[2403.07648] Characterization of Large Language Model Development in the Datacenter。

二、摘要

大型語言模型 （LLM） 的表現(xiàn)令人印象深刻，然而，高效利用大規(guī)模集群資源開發(fā) LLM 并非易事。因為 LLM 往往面臨許多挑戰(zhàn)，例如頻繁的硬件故障、復雜的并行化策略和資源利用率不平衡。本文中，作者追蹤了內(nèi)部 Acme GPU 集群為期 6 個月的工作負載，并進行了深入的分析。具體來說，作者首先將 LLM 與之前傳統(tǒng) LLM 的工作負載進行對比，并揭示了針對 LLM 系統(tǒng)的潛在機會。此外，作者還介紹了相關(guān)的系統(tǒng)：（1）容錯預訓練，涉及 LLM 的故障診斷和自動恢復來增強容錯能力。（2）評估中的調(diào)度解耦，通過分解和調(diào)度優(yōu)化實現(xiàn)及時的性能反饋。

三、引言

3.1 集群配置

作者的 Acme 中包含 2 個 GPU 集群，都是單節(jié)點包含 8 個 NVIDIA A100 SXM 80GB GPU 以及 2 個 Intel Xeon Platinum 8358P CPU，并且都通過 NVLink + NVSwitch 實現(xiàn)全互聯(lián)。

• Seren 集群建設(shè)比較早，單節(jié)點只用 1 個 200Gbps 高速 IB 網(wǎng)卡，Seren 集群總共包含 286 個節(jié)點，總共 2288 個 A100 GPU；（PS：機器之間沒有高速網(wǎng)絡互聯(lián)，感覺不太適合大規(guī)模分布式訓練，常見解決方案為 4*200Gbps 或 8*200Gbps）
• Kalos 集群比較新，單節(jié)點使用 5 個 200Gbps 高速 IB 網(wǎng)卡，其中 4 個用于后向的 GPU 傳輸，1 個專用于高性能的存儲。總共 302 個節(jié)點，2416 個 A100 GPU。?

Seren 和 Kalos 兩個集群都是用于訓練場景的，不涉及任何的 Serving 任務。

3.2 Acme Tracing

作者追蹤了兩個集群從 2023.03 到 2023.08 之間共 6 個月的任務，Seren 總共包含 368K 個 CPU 任務，664K 個 GPU 任務；Kalos 包含了 42K 個 CPU 任務和 20K 個 GPU 任務。收集的數(shù)據(jù)源主要包含 4 個部分：

• 任務信息：主要包括任務調(diào)度相關(guān)信息，比如提交時間、啟動時間、結(jié)束時間，以及最終的狀態(tài)信息，比如完成、失敗、取消，以及相關(guān)的資源信息等，比如 CPU、GPU、Memory 等。
• 硬件監(jiān)控數(shù)據(jù)：比較 CPU、GPU 利用率，內(nèi)存、顯存占用，網(wǎng)絡占用，以及電源相關(guān)信息。
• 運行時日志：主要是任務運行中 stdout，stderr 信息，以及 debug 信息等。
• 剖析數(shù)據(jù)：主要是使用 DCGM 等工具剖析的細粒度數(shù)據(jù)。

3.3 GPU 利用率

對于大規(guī)模 LLM 預訓練任務而言，其往往需要大量 GPU，任何的 GPU 計算和 NCCL 通信都會占用 GPU，導致 GPU Utilization 很高，往往能達到平均 95% 以上。因此，其往往導致整個 GPU 集群的 GPU Utilization 很高，需要更細力度的監(jiān)控指標來顯示 GPU 的利用情況。

3.3.1 GPU Utilization

對應 DCGM 的 DCGM_FI_PROF_GR_ENGINE_ACTIVE，表示在一個時間間隔內(nèi) Graphics 或 Compute 引擎處于 Active 的時間占比。Active 時間比例越高，意味著 GPU 在該周期內(nèi)越繁忙。該值比較低表示一定沒有充分利用 GPU，比較高也不意味著已經(jīng)充分利用 GPU。如下圖所示，表示幾個 GPU 的 Utilization 到了 80%-90% 左右：

3.3.2 GPU SM Active

對應 DCGM 的 DCGM_FI_PROF_SM_ACTIVE，表示一個時間間隔內(nèi)，至少一個 Warp 在一個 SM 上處于 Active 的時間占比，該值表示所有 SM 的平均值，對每個 Block 的線程數(shù)不敏感。該值比較低表示一定未充分利用 GPU。如下為幾種 Case（假設(shè) GPU 包含 N 個 SM）：

• Kernel 在整個時間間隔內(nèi)使用 N 個 Block 運行在所有的 SM 上，對應 100%。
• Kernel 在一個時間間隔內(nèi)運行了 N/5 個 Block，該值為 20%。
• Kernel 有 N 個 Block，在一個時間間隔內(nèi)只運行了 1/4 時間，該值為 25%。

如下圖所示為幾個 GPU 的 SM Active，可見只有 60% 左右，還有一定提升空間：

3.3.3 GPU SM Occupancy

對應 DCGM 的 DCGM_FI_PROF_SM_OCCUPANCY，表示一個時間間隔內(nèi)，駐留在 SM 上的 Warp 與該 SM 最大可駐留 Warp 的比例。該值表示一個時間間隔內(nèi)的所有 SM 的平均值，該值越高也不一定代表 GPU 使用率越高。

如下圖所示為幾個 GPU 的 SM Occupancy，只有 20% 多：

3.3.4 實驗

如下圖所示，我們在 T4 GPU（包含 40 個 SM） 上通過一個小的實驗來說明幾個指標的關(guān)系：

• 當只有1 個 Block，1 個 Thread時，GPU Util 也是 100%，因為 GPU 一直在占用，此時 40 個 SM 中只有 1 個一直 Active，所以 SM Active 為 2.5%。
• 當有 40 個 Block，每個 Block 1 個 Thread時，GPU Util 為 100%，SM Active 也為 100%，因為每個 Block 都會占用一個 SM。
• 當有 40 個 Block，每個 Block 128 個 Thread時，GPU Util 為 100%，SM Active 也為 100%，因為每個 Block 都會占用一個 SM。此時 SM Occupancy 到了 12.5%。?

四、數(shù)據(jù)中心刻畫

4.1 LLM 與傳統(tǒng) DL 任務工作負載對比

如下圖 Table 2 所示為 3 個傳統(tǒng) DL 任務（Philly、Helios、PAI）與 LLM 任務（Acme）的集群和任務信息：

更短的任務時間：如下圖 Figure 2(a) 所示為相關(guān)任務的 GPU 時間累積分布（Duration CDF）。可以看出，Seren 和 Kalos 中的 Duration 中位數(shù)為 2 分鐘，比其它集群短 1.7-7.2 倍。出現(xiàn)這個現(xiàn)象可能有幾方面的原因：

• 硬件升級：比如 GPU，網(wǎng)絡升級，任務執(zhí)行更快。
• 資源濫用：用戶通常會申請過多的資源。
• 額外關(guān)聯(lián)的工作負載：比如 LLM 開發(fā) Pipeline 中通常會有很多小的評估任務。
• 失敗率高：大約 40% 的任務失敗，完成的任務值只消耗了 20%-30% 的 GPU 資源。

兩極化的 GPU 利用率：如下圖 Figure 2(b) 所示為相關(guān)任務的 GPU 利用率累積分布（Utilization CDF），可以看出，Seren 和 Kalos 的 GPU 利用率中位數(shù)為 97% 和 99%，而 Philly 和 PAI 分布為 48% 和 4%。這可能是因為作者的 Seren 和 Kalos 集群中都是相似的 Transformer 類型的 LLM 任務，而 Philly 和 PAI 中有各種各樣的任務。此時再用 GPU Utilization 作為利用率指標意義已經(jīng)不大。可以考慮更加細粒度的 SM Active。

高度差異化的工作負載分布：如下圖 Figure 3 所示，作者進一步探究了作業(yè)與 GPU 需求的關(guān)系。可以看出，LLM 的工作負載與傳統(tǒng) DL 任務很不一樣，傳統(tǒng) DL 集群通常依賴搶占機制，但是其對 LLM 集群可能不再合適，其相應的恢復開銷可能很大。

• （a）對作業(yè)數(shù)量而言，所有集群類似，只有 7% 不到的作業(yè)需要超過 8 個 GPU。
• （b）對于作業(yè)時間而言，差異很大，比如對于 Kalos 集群，大規(guī)模作業(yè)（超過 256 GPU）占據(jù)了 96% 以上的資源。?

4.2 工作負載類別

如下圖 Figure 4 所示，在 Seren 和 Kalos 集群中，一多半都是評估（Evaluation）任務，只有極少數(shù)的預訓練（Pretrain）任務，但是預訓練任務卻又占據(jù)了絕大部分的 GPU 時間，在 Kalos 集群尤其明顯。評估任務通常需要比較少的 GPU，不超過 4 個，預訓練通常需要超過 100 個 GPU。評估任務通常以 Batch 方式提交，對時效性要求也不高，可以利用碎片資源。

五、工作負載剖析

5.1 預訓練工作負載剖析

針對 LLM 預訓練，作者也開發(fā)了相應的分布式訓練框架 [2401.09149] InternEvo: Efficient Long-sequence Large Language Model Training via Hybrid Parallelism and Redundant Sharding，其包含 V1 和 V2 兩個版本，如下圖 Figure 10 所示為使用 2048 GPU 訓練 123B LLM 時的 SM Active：

• V1：3D Parallelism，4PP，8PP，SM Active 中存在很多空隙，整體利用率不高。
• V2：Hierarchical ZeRO 版本，每個 subgroup 包含 64 GPU，并且使用了重計算，其 SM Active 明顯提升。相比 V1 版本，任務提速 16%。?

如下圖 Figure 19 所示，1024 GPU 時也有類似結(jié)論：

如下圖 Figure 22 所示，作者也進一步評估了在 1024 GPU 上訓練 Mistral 7B MoE 時的 SM Active，可以看出，其相比 Dense 模型低了很多，主要是因為 MoE 中多了很多 all-to-all 操作，而作者使用的單個 IB NIC 導致其出現(xiàn)瓶頸：

5.2 評估工作負載剖析

如下圖 Figure 13 所示，針對每個評估任務，初始化階段都要加載模型和進行數(shù)據(jù)預處理，這個階段通常不需要 GPU 參與，導致此階段 GPU 的浪費。此外，獲得模型結(jié)果后還會有一定的 CPU 計算，此時 GPU 也會空閑。

六、異常分析

作者統(tǒng)計了兩個集群中的監(jiān)控數(shù)據(jù)以及運行日志，以便分析異常。在 Kalos 集群中，作者收集 了 32,500 個任務，其中 31,293（96.3%）個推理任務（比如評估），647（2.0%）個預訓練任務和調(diào)試任務（1.7%）。在 Seren 任務中，作者僅收集了 675 個訓練任務。

6.1 異常類別

如下圖 Table 3 所示為具體的錯誤類型，總共可以分為 3 類：

• Infrastructure：主要是計算平臺和遠程存儲的問題。主要發(fā)生在作業(yè)執(zhí)行中，其會影響訓練進度。

此種異常失敗的作業(yè)通常使用了大量 GPU，并且恢復的代價往往比較高。雖然失敗數(shù)量上只占了 11%，但GPU 資源（GPU 時間）上占了 82%。并且大部分是預訓練任務，可能會多次遇到硬件故障，例如GPU 問題（CUDAError、ECCError），NVLink 問題（NVLinkError）和網(wǎng)絡問題（NCCLRemoteError、S3StoreError）。而其中的 NodeFailure 表示未知硬件問題導致的故障。解決這些問題需要細致的診斷工作，以查明根因。通常需要維護或更換有缺陷的硬件，然后重啟作業(yè)。

作者甚至提到了高溫可能導致的故障率增加，當預訓練時，機房溫度升高了 5 度，此外作者也發(fā)現(xiàn)大部分異常發(fā)生在 2023.07，是最熱的月份。

• Framework：主要是幾種運行錯誤，比如 RuntimeError、ValueError、AttributeError，主要是 Tensor 操作、Shape 以及數(shù)據(jù)類型相關(guān)，或者一系列不符合預期的行為。通常發(fā)生在作業(yè)起始階段。
• Script：通常是用戶編碼錯誤等，通過修改代碼解決。?

6.2 異常恢復

通常有三種場景需要重啟任務，一種是作業(yè)發(fā)生異常，另一種是訓練 loss 出現(xiàn)毛刺（loss 突然增加，有些會重新下降，有些不會），還有一種是作業(yè)卡住。重啟需要從最新的 Checkpoint 開始，也會導致訓練進度的回退；此外，在沒有自動重啟機制之前，都需要有人值班并手動重啟。如下圖 Figure 14 展示了早期的兩個預訓練任務，其中 104B 為原始訓練框架，123B 為優(yōu)化后的訓練框架，允許在任務結(jié)束之前保持當前的狀態(tài)，相應進度回退也更少。

七、部署 LLM 系統(tǒng)

7.1 容錯預訓練

作者的容錯系統(tǒng)分 3 個關(guān)鍵模塊，如下圖 Figure 15 所示為其中的異常診斷和恢復過程：

• Checkpointing：更頻繁的保存 Checkpoint，以便盡可能少的訓練回退。節(jié)點的 CPU 內(nèi)存比較大，可以緩存多個 Checkpoint，作者會先將 Checkpoint 保存到內(nèi)存中，然后使用一個獨立的線程進行定期的異步保存，可以極大降低 Checkpointing 開銷。通過每 30 分鐘保存一次，其 7B 到 123B 模型的保存開銷減少了 3.6-58.7 倍。
• Diagnosis：通過一系列手段識別任務失敗的根因。通過規(guī)則匹配，向量檢索，以及使用 LLM Agent 等手段來識別錯誤的根因。可以識別 90% 的問題，大幅降低人工成本。
• Recovery：通過一系列錯誤檢測發(fā)現(xiàn)異常節(jié)點，屏蔽并自動恢復任務。如果檢測是 Infrastructure 異常，則會執(zhí)行一系列的異常檢測，比如使用兩輪 NCCL test 來識別 NVLinkError。?

7.2 針對評估的解耦調(diào)度

其主要動機就是前面介紹的，評估階段很多時間 GPU 都是空閑的，而評估任務又有很多，這導致了 GPU 資源的浪費。為此作者將相關(guān)組件解耦，以便提升 GPU 利用率：

八、參考鏈接

1. ??https://arxiv.org/abs/2403.07648??
2. ??https://www.alibabacloud.com/help/zh/ack/ack-managed-and-ack-dedicated/user-guide/introduction-to-metrics??

本文轉(zhuǎn)載自 ??AI閑談??，作者： AI閑談