剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化精華

amei2000go

發(fā)布于 2024-6-19 11:05

瀏覽

1收藏

一、背景

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

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

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

二、摘要

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

三、引言

3.1 集群配置

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

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

Seren 和 Kalos 兩個(gè)集群都是用于訓(xùn)練場景的，不涉及任何的 Serving 任務(wù)。

3.2 Acme Tracing

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

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

3.3 GPU 利用率

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

3.3.1 GPU Utilization

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

3.3.2 GPU SM Active

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

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

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

3.3.3 GPU SM Occupancy

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

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

3.3.4 實(shí)驗(yàn)

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

當(dāng)只有1 個(gè) Block，1 個(gè) Thread時(shí)，GPU Util 也是 100%，因?yàn)?GPU 一直在占用，此時(shí) 40 個(gè) SM 中只有 1 個(gè)一直 Active，所以 SM Active 為 2.5%。
當(dāng)有 40 個(gè) Block，每個(gè) Block 1 個(gè) Thread時(shí)，GPU Util 為 100%，SM Active 也為 100%，因?yàn)槊總€(gè) Block 都會(huì)占用一個(gè) SM。
當(dāng)有 40 個(gè) Block，每個(gè) Block 128 個(gè) Thread時(shí)，GPU Util 為 100%，SM Active 也為 100%，因?yàn)槊總€(gè) Block 都會(huì)占用一個(gè) SM。此時(shí) SM Occupancy 到了 12.5%。?

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

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

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

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

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

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

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

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

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

4.2 工作負(fù)載類別

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

五、工作負(fù)載剖析

5.1 預(yù)訓(xùn)練工作負(fù)載剖析

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

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

5.2 評估工作負(fù)載剖析

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

六、異常分析

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

6.1 異常類別

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

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

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

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

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

6.2 異常恢復(fù)

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)

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

7.1 容錯(cuò)預(yù)訓(xùn)練

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

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

剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化-AI.x社區(qū)