一、背景

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

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

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

二、摘要

大型語(yǔ)言模型 （LLM） 的表現(xiàn)令人印象深刻，然而，高效利用大規(guī)模集群資源開(kāi)發(fā) LLM 并非易事。因?yàn)?LLM 往往面臨許多挑戰(zhàn)，例如頻繁的硬件故障、復(fù)雜的并行化策略和資源利用率不平衡。本文中，作者追蹤了內(nèi)部 Acme GPU 集群為期 6 個(gè)月的工作負(fù)載，并進(jìn)行了深入的分析。具體來(lái)說(shuō)，作者首先將 LLM 與之前傳統(tǒng) LLM 的工作負(fù)載進(jìn)行對(duì)比，并揭示了針對(duì) LLM 系統(tǒng)的潛在機(jī)會(huì)。此外，作者還介紹了相關(guān)的系統(tǒng)：（1）容錯(cuò)預(yù)訓(xùn)練，涉及 LLM 的故障診斷和自動(dòng)恢復(fù)來(lái)增強(qiáng)容錯(cuò)能力。（2）評(píng)估中的調(diào)度解耦，通過(guò)分解和調(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，并且都通過(guò) 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ī)器之間沒(méi)有高速網(wǎng)絡(luò)互聯(lián)，感覺(jué)不太適合大規(guī)模分布式訓(xùn)練，常見(jiàn)解決方案為 4*200Gbps 或 8*200Gbps）
• Kalos 集群比較新，單節(jié)點(diǎn)使用 5 個(gè) 200Gbps 高速 IB 網(wǎng)卡，其中 4 個(gè)用于后向的 GPU 傳輸，1 個(gè)專用于高性能的存儲(chǔ)?？偣?302 個(gè)節(jié)點(diǎn)，2416 個(gè) A100 GPU。?

Seren 和 Kalos 兩個(gè)集群都是用于訓(xùn)練場(chǎng)景的，不涉及任何的 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 利用率

對(duì)于大規(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)來(lái)顯示 GPU 的利用情況。

3.3.1 GPU Utilization

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

3.3.2 GPU SM Active

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

• Kernel 在整個(gè)時(shí)間間隔內(nèi)使用 N 個(gè) Block 運(yùn)行在所有的 SM 上，對(duì)應(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，可見(jiàn)只有 60% 左右，還有一定提升空間：

3.3.3 GPU SM Occupancy

對(duì)應(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% 多：

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

如下圖所示，我們?cè)?T4 GPU（包含 40 個(gè) SM） 上通過(guò)一個(gè)小的實(shí)驗(yàn)來(lái)說(shuō)明幾個(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%。?

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

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

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

更短的任務(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)象可能有幾方面的原因：

• 硬件升級(jí)：比如 GPU，網(wǎng)絡(luò)升級(jí)，任務(wù)執(zhí)行更快。
• 資源濫用：用戶通常會(huì)申請(qǐng)過(guò)多的資源。
• 額外關(guān)聯(lián)的工作負(fù)載：比如 LLM 開(kāi)發(fā) Pipeline 中通常會(huì)有很多小的評(píng)估任務(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。

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

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

4.2 工作負(fù)載類別

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

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

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

針對(duì) LLM 預(yù)訓(xùn)練，作者也開(kāi)發(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%。?

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

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

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

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

六、異常分析

作者統(tǒng)計(jì)了兩個(gè)集群中的監(jiān)控?cái)?shù)據(jù)以及運(yùn)行日志，以便分析異常。在 Kalos 集群中，作者收集 了 32,500 個(gè)任務(wù)，其中 31,293（96.3%）個(gè)推理任務(wù)（比如評(píng)估），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ì)算平臺(tái)和遠(yuǎn)程存儲(chǔ)的問(wè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 問(wèn)題（CUDAError、ECCError），NVLink 問(wèn)題（NVLinkError）和網(wǎng)絡(luò)問(wèn)題（NCCLRemoteError、S3StoreError）。而其中的 NodeFailure 表示未知硬件問(wèn)題導(dǎo)致的故障。解決這些問(wèn)題需要細(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ò)修改代碼解決。?

6.2 異?；謴?fù)

通常有三種場(chǎng)景需要重啟任務(wù)，一種是作業(yè)發(fā)生異常，另一種是訓(xùn)練 loss 出現(xiàn)毛刺（loss 突然增加，有些會(huì)重新下降，有些不會(huì)），還有一種是作業(yè)卡住。重啟需要從最新的 Checkpoint 開(kāi)始，也會(huì)導(dǎo)致訓(xùn)練進(jìn)度的回退；此外，在沒(méi)有自動(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)度回退也更少。

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

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

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

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

7.2 針對(duì)評(píng)估的解耦調(diào)度

其主要?jiǎng)訖C(jī)就是前面介紹的，評(píng)估階段很多時(shí)間 GPU 都是空閑的，而評(píng)估任務(wù)又有很多，這導(dǎo)致了 GPU 資源的浪費(fèi)。為此作者將相關(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閑談