一、背景

我們?cè)谥暗膬善恼轮性敿?xì)介紹了萬(wàn)卡 GPU 集群中的網(wǎng)絡(luò)拓?fù)湎嚓P(guān)信息以及在萬(wàn)卡 GPU 集群中進(jìn)行大規(guī)模 LLM 訓(xùn)練面對(duì)的挑戰(zhàn)和相應(yīng)解決方案。最近又看到阿里團(tuán)隊(duì)在相關(guān)領(lǐng)域的工作，本文中我們簡(jiǎn)單對(duì)其進(jìn)行總結(jié)。論文中很多基礎(chǔ)知識(shí)沒(méi)有展開(kāi)介紹，強(qiáng)烈建議優(yōu)先閱讀對(duì)應(yīng)的兩篇文章：

• ??萬(wàn)卡 GPU 集群互聯(lián)：硬件配置和網(wǎng)絡(luò)設(shè)計(jì)??
• ??萬(wàn)卡 GPU 集群實(shí)戰(zhàn)：探索 LLM 預(yù)訓(xùn)練的挑戰(zhàn)??

對(duì)應(yīng)的論文為：[2406.04594] Boosting Large-scale Parallel Training Efficiency with C4: A Communication-Driven Approach

二、摘要

大型語(yǔ)言模型（LLM）由于規(guī)模很大，需要大量的語(yǔ)料進(jìn)行預(yù)訓(xùn)練，并行訓(xùn)練技術(shù)也就非常有必要，其往往需要數(shù)千個(gè) GPU 來(lái)共同訓(xùn)練一個(gè)模型。不幸的是，當(dāng)前并行訓(xùn)練的效率往往不是最優(yōu)的，這主要?dú)w因于如下兩個(gè)問(wèn)題：

• 首先，硬件故障在所難免，會(huì)導(dǎo)致訓(xùn)練任務(wù)中斷。無(wú)法快速識(shí)別故障組件會(huì)導(dǎo)致 GPU 資源的大量浪費(fèi)。
• 其次，LLM 訓(xùn)練中通常采用同步訓(xùn)練方式，GPU 必須等待參數(shù)同步完成后才能進(jìn)入下一輪計(jì)算，網(wǎng)絡(luò)擁塞會(huì)大大增加 GPU 的等待時(shí)間。

為了應(yīng)對(duì)這些挑戰(zhàn)，論文作者提出了一種由通信驅(qū)動(dòng)的解決方案，即 C4（Calibrating Collective Communication over Converged Ethernet）。其關(guān)鍵想法有兩點(diǎn)：

• 首先，在并行訓(xùn)練中，集合通信表現(xiàn)出周期性和同質(zhì)性的特征，因此任何異?？隙ㄊ怯捎谀撤N形式的硬件故障引起的。利用此特性，C4 可以快速識(shí)別故障組件，迅速隔離異常并重新啟動(dòng)任務(wù)，從而避免因異常檢測(cè)時(shí)延而造成的資源浪費(fèi)。
• 其次，集合通信的可預(yù)測(cè)通信模型（涉及少量大流量）使 C4 能夠高效地執(zhí)行流量規(guī)劃，從而大大減少網(wǎng)絡(luò)擁塞。

C4 已經(jīng)在阿里的生產(chǎn)系統(tǒng)中廣泛實(shí)施，將錯(cuò)誤引起的開(kāi)銷減少了約 30%，并將某些通信成本適中的運(yùn)行時(shí)性能提高了約 15%。

三、引言

3.1 訓(xùn)練預(yù)估

如下表所示，LLM 的預(yù)訓(xùn)練代價(jià)很高，往往需要上千 GPU 訓(xùn)練幾十天。尤其是，早期的百 B 規(guī)模 LLM 都只在幾百 B Token 上訓(xùn)練，而現(xiàn)在的 LLM 通常會(huì)訓(xùn)練幾 T Token，比如 LLaMA-3 系列模型訓(xùn)練的 Token 數(shù)已經(jīng)達(dá)到 15T。

對(duì)于現(xiàn)在廣泛采用的 Decoder Only LLM，可以根據(jù)其模型參數(shù)量和 Token 數(shù)以及訓(xùn)練資源預(yù)估出訓(xùn)練時(shí)長(zhǎng)。具體來(lái)說(shuō)，每個(gè) Token 的 Forward 計(jì)算量大約為 2 倍的參數(shù)量，如下所示，其中 W 是模型參數(shù)量：

考慮到大部分情況下總的計(jì)算量與 Forward 計(jì)算量的比例接近 3:1，因此可以根據(jù)每個(gè) Token 的計(jì)算量預(yù)估出訓(xùn)練中的計(jì)算量約為（與論文 [2001.08361] Scaling Laws for Neural Language Models  中結(jié)論一致）：

根據(jù)每個(gè) Token 計(jì)算量和計(jì)算資源可以大概預(yù)估出訓(xùn)練的總時(shí)長(zhǎng)，其中 MFU 表示 Model FLOPS Utilization，是廣泛采用的用于衡量分布式訓(xùn)練效率的指標(biāo)：

訓(xùn)練天數(shù) = Token 數(shù) * Ctoken / (GPU 數(shù) * GPU FLOPs * MFU * 3600 * 24)

根據(jù)以上公式可以進(jìn)一步預(yù)估使用 8192 H100-80G GPU，10T Token 數(shù)據(jù)訓(xùn)練 175B 模型的天數(shù)為 30 天：

10T*6*175B/(8192*1000T*50%)/3600/24=30 天

3.2 基本概念

網(wǎng)絡(luò)直徑（Network Diameter）指的是網(wǎng)絡(luò)中任意兩個(gè)節(jié)點(diǎn)之間的最短路徑中最長(zhǎng)的一條路徑的長(zhǎng)度，通常用跳數(shù)（hops）來(lái)表示：

• 最短路徑：在網(wǎng)絡(luò)圖中，從一個(gè)節(jié)點(diǎn)到另一個(gè)節(jié)點(diǎn)的所有可能路徑中，所需跳數(shù)最少的一條路徑。
• 最長(zhǎng)的最短路徑：對(duì)于網(wǎng)絡(luò)中所有可能的節(jié)點(diǎn)對(duì)，每個(gè)對(duì)都有一個(gè)最短路徑，網(wǎng)絡(luò)半徑就是這些最短路徑中跳數(shù)最多的那一條的跳數(shù)。

交換基數(shù)（Switch Radix）是指交換機(jī)上可用的端口數(shù)量。例如，一個(gè) 48 Port 的交換機(jī)的交換基數(shù)就是 48。交換基數(shù)越大，交換機(jī)能夠直接連接的節(jié)點(diǎn)數(shù)就越多。這意味著在網(wǎng)絡(luò)拓?fù)渲?，從一個(gè)節(jié)點(diǎn)到另一個(gè)節(jié)點(diǎn)可能只需要經(jīng)過(guò)更少的跳數(shù)。直接連接的節(jié)點(diǎn)越多，數(shù)據(jù)包傳輸過(guò)程中需要經(jīng)過(guò)的中間節(jié)點(diǎn)就越少，從而減少了網(wǎng)絡(luò)直徑。

3.3 錯(cuò)誤處理

LLM 預(yù)訓(xùn)練基本都采用分布式同步訓(xùn)練方式，其集合通信是同步的。也就是說(shuō)，任何異常都可能導(dǎo)致整個(gè)作業(yè)失敗。為了使作業(yè)繼續(xù)運(yùn)行，用戶在訓(xùn)練中都會(huì)定期保存 Checkpoint，以便作業(yè)失敗后可以從最后一個(gè) Checkpoint 恢復(fù)。

如下圖 Figure 1 所示，在執(zhí)行 DL 訓(xùn)練作業(yè)之前或之中都可能出現(xiàn)嚴(yán)重錯(cuò)誤，它們會(huì)以不同的方式影響系統(tǒng)利用率：

• 如果錯(cuò)誤發(fā)生在作業(yè)開(kāi)始之前，則將在系統(tǒng)診斷、錯(cuò)誤組件隔離和作業(yè)重新啟動(dòng)方面花費(fèi)額外的時(shí)間。這種情況下，通常需要花費(fèi)大量時(shí)間來(lái)診斷和精確定位缺陷組件，可能需要數(shù)小時(shí)甚至數(shù)天。
• 如果錯(cuò)誤發(fā)生在作業(yè)執(zhí)行中，則會(huì)浪費(fèi)更多的額外時(shí)間，包括Post-Checkpoint Cost（導(dǎo)致 Checkpoint 之后的計(jì)算浪費(fèi)）和Fault Detection Cost（在錯(cuò)誤發(fā)生和用戶檢測(cè)到錯(cuò)誤之間存在延遲）。?

如下圖 Table 1 所示，作者統(tǒng)計(jì)了一個(gè)代表性任務(wù)在一個(gè)月內(nèi)遇到的錯(cuò)誤。數(shù)據(jù)顯示，由于這些錯(cuò)誤，該作業(yè)在一個(gè)月內(nèi)失敗了 40 次。由于當(dāng)時(shí)缺乏有效的故障檢測(cè)和診斷工具，可能需要數(shù)小時(shí)到數(shù)天的時(shí)間才能確定原因并查明缺陷節(jié)點(diǎn)。根據(jù)作者經(jīng)驗(yàn)，大約 30% 的時(shí)間花在錯(cuò)誤檢測(cè)、系統(tǒng)診斷、隔離缺陷節(jié)點(diǎn)和重新啟動(dòng)任務(wù)上，只有 70% 的時(shí)間用于實(shí)際訓(xùn)練任務(wù)。從用戶視角看，87.5% 是 “NCCL Error”，而實(shí)際的故障問(wèn)題可能包含多種，比如 GPU 硬件錯(cuò)誤，網(wǎng)絡(luò)斷開(kāi)、內(nèi)存溢出等，也可能是用戶代碼異常，比如常見(jiàn)的 Tensor 大小不匹配。其大部分故障都是單節(jié)點(diǎn)的異常，發(fā)現(xiàn)并隔離節(jié)點(diǎn)即可避免再次受該節(jié)點(diǎn)異常影響。

3.4 優(yōu)化通信

除了異常導(dǎo)致作業(yè)崩潰之外，GPU 還可能由于集合通信操作或數(shù)據(jù)加載延遲而出現(xiàn)停頓：

• 首先，各種流程之間的流量沖突或硬件問(wèn)題（如以太網(wǎng)鏈路故障）可能導(dǎo)致通信成本升高。為了同時(shí)擴(kuò)展系統(tǒng)規(guī)模并提高系統(tǒng)可用性和可維護(hù)性，作者采用了雙 Port NIC進(jìn)行系統(tǒng)互聯(lián)，每個(gè) Port 連接到不同的 Leaf 交換機(jī)，節(jié)點(diǎn)和 Leaf 交換機(jī)之間將有兩個(gè)可用鏈路，任何一個(gè)鏈路失效，另一條鏈路可以接管所有流量，當(dāng)然也會(huì)成為系統(tǒng)瓶頸。
• 此外，處理硬件缺陷造成的通信開(kāi)銷之外，還可能出現(xiàn)多個(gè)數(shù)據(jù)流爭(zhēng)奪單個(gè)鏈路的可用帶寬。

對(duì)于現(xiàn)在的分布式訓(xùn)練作業(yè)，帶寬限制會(huì)顯著增加通信時(shí)延并導(dǎo)致通信性能下降。隨著模型和訓(xùn)練集群規(guī)模擴(kuò)大，這個(gè)問(wèn)題進(jìn)一步加劇。如下圖 Figure 2 展示了訓(xùn)練 22B GPT 模型時(shí)實(shí)際性能和理論性能的差異，實(shí)際性能與理論性能的差異隨著 GPU 數(shù)的增加逐漸擴(kuò)大，當(dāng)達(dá)到 512 GPU 時(shí)，實(shí)際性能下降到理論性能的 30%。

與傳統(tǒng)云環(huán)境中的通信模式不同，DL 訓(xùn)練集群中通常只有少數(shù)較持久的連接，每個(gè)節(jié)點(diǎn)通常管理大約幾百個(gè)連接。這種環(huán)境下流量的沖突會(huì)導(dǎo)致這些連接的有效帶寬發(fā)生大幅變化，從而導(dǎo)致通信時(shí)延增加數(shù)倍。然而，這一挑戰(zhàn)也伴隨著機(jī)遇，DL 中的流量通常是周期性的、可預(yù)測(cè)的，這為通過(guò)工程手段提高通信效率提供了獨(dú)特的優(yōu)勢(shì)。

從本質(zhì)上講，大規(guī)模訓(xùn)練集群的有效性能受到硬件缺陷和流量沖突的顯著影響。為了確保 GPU 在模型計(jì)算過(guò)程中高效運(yùn)行，最大限度地減少故障檢測(cè)和系統(tǒng)診斷所浪費(fèi)的時(shí)間至關(guān)重要。此外，為了防止 GPU 在定期同步期間停頓，必須消除任何多余的通信開(kāi)銷。

四、方法

4.1 并行訓(xùn)練穩(wěn)定性

基于以上的分析，作者通過(guò)兩種策略解決硬件故障：

• 降低硬件故障率，該策略至關(guān)重要，但作者沒(méi)有太多介紹，主要提到了溫度控制是關(guān)鍵（要點(diǎn) 1）。比如，通過(guò)動(dòng)態(tài)電壓和頻率調(diào)節(jié)（DVFS）等方法有助于防止 GPU 過(guò)熱，但會(huì)影響性能一致性。作者通過(guò)更快的風(fēng)扇和更好的空調(diào)系統(tǒng)改善冷卻效果，實(shí)現(xiàn)溫度調(diào)節(jié)。當(dāng)然，未來(lái)的 AI 基礎(chǔ)設(shè)施建設(shè)也開(kāi)始轉(zhuǎn)向更高效的冷卻方案，比如液冷。（PS：NVIDIA 新一代 Blackwell GPU 的功耗進(jìn)一步增加，這一挑戰(zhàn)更加明顯，因此 NVIDIA 也提到了液冷系統(tǒng)。）
• 系統(tǒng)性容錯(cuò)：在傳統(tǒng)云應(yīng)用中通常采用在線容錯(cuò)方案，比如使用冗余計(jì)算來(lái)容忍計(jì)算故障，通過(guò)糾錯(cuò)碼和/或三重副本技術(shù)提供高可靠存儲(chǔ)，使用多路徑策略承受網(wǎng)絡(luò)異常；然而，在大規(guī)模 LLM 訓(xùn)練中，通常采用離線容錯(cuò)方案，例如定期保存 Checkpoint。作者與用戶深入討論，得到一個(gè)關(guān)鍵信息：底層系統(tǒng)不應(yīng)該將任何不確定性引入模型訓(xùn)練過(guò)程中（要點(diǎn) 2）。因此，作者采用了混合的技術(shù)方案，具體而言：

利用成熟的云存儲(chǔ)技術(shù)提供可靠的數(shù)據(jù)存儲(chǔ)。

準(zhǔn)備備份節(jié)點(diǎn)以替換故障節(jié)點(diǎn)。作者針對(duì) 128 臺(tái)機(jī)器 1024 個(gè) GPU 會(huì)分配 8 臺(tái)機(jī)器 64 個(gè) GPU 作為備份，以確保在這 136 臺(tái)機(jī)器中的任何 128 臺(tái)上訓(xùn)練時(shí)具有相同的通信吞吐和計(jì)算性能。

關(guān)于網(wǎng)絡(luò)，業(yè)界普遍采用單 Port NIC（例如 1*400Gbps）來(lái)減少哈希沖突的可能性。然而，這種方式可能帶來(lái)可靠性問(wèn)題，端口異?？赡芷仁谷蝿?wù)從最近的 Checkpoint 重新啟動(dòng)。而作者采用了 2*200Gbps 雙上行鏈路來(lái)增強(qiáng)可靠性，同時(shí)解決網(wǎng)絡(luò)哈希沖突以維持性能。本質(zhì)上講，確保每一層的最大可靠性，再加上跨層優(yōu)化，對(duì)于實(shí)現(xiàn)最高效、最可靠的整體系統(tǒng)至關(guān)重要（要點(diǎn) 3）。

作者的 C4D 容錯(cuò)架構(gòu)包括如下幾點(diǎn)：

• 通過(guò)糾錯(cuò)碼實(shí)現(xiàn)可靠的數(shù)據(jù)傳輸。
• 通過(guò)雙上行鏈路和多路徑通信實(shí)現(xiàn)網(wǎng)絡(luò)可靠性。
• 通過(guò) Checkpoint 和冗余節(jié)點(diǎn)處理計(jì)算故障。

如下圖 Figure 3 所示，該系統(tǒng)的核心是 C4D（C4 Diagnose）子系統(tǒng)，旨在快速檢測(cè)硬件故障以提示任務(wù)重啟。C4D 利用了兩個(gè)洞察（要點(diǎn) 4）：

• 并行訓(xùn)練任務(wù)通常是有規(guī)律的、可預(yù)測(cè)的，基于此可以識(shí)別出一些異常。
• 并行訓(xùn)練中的 Bulk Synchronous Parallel（BSP）模型需要有規(guī)律的同步點(diǎn)，這些同步點(diǎn)可以作為衡量異常的錨點(diǎn)。

PS：下圖中的 Wi 表示訓(xùn)練中的 Worker Pod，Ni 表示 Node，SW 表示 NIC Switch。

• 物理機(jī)監(jiān)控（Server Monitor）、網(wǎng)絡(luò)監(jiān)控（Network Monitor）可以提供基本的硬件信息，與任務(wù)無(wú)關(guān)。
• 每個(gè) Worker 也會(huì)提供相應(yīng)的統(tǒng)計(jì)信息和日志，并由C4 Runtime Fault Detection來(lái)匯總，并將相關(guān)信息同步給Job Steering Service和Background Root Cause Analysis。
• Job Steering Service 會(huì)根據(jù) C4 Events 相關(guān)信息來(lái)決定是否隔離節(jié)點(diǎn)或重啟任務(wù)。
• Background Root Cause Analysis 除了接收 C4 Events 外，也會(huì)接收物理機(jī)監(jiān)控和網(wǎng)絡(luò)監(jiān)控，以便找到問(wèn)題的根因。?

如下圖 Figure 4 所示為 C4D 的主要原理，其包含 3 個(gè)基本組件：增強(qiáng)的 CCL（Collective Communication Library）、C4a（C4 agent）以及 C4a Master：

• 在每個(gè) Worker 中都會(huì)使用增強(qiáng)的 CCL，并且每個(gè) Worker 上都會(huì)有 C4a 以便收集當(dāng)前 Worker 相關(guān)信息，比如 CCL 日志。作者沒(méi)有直接使用NCCL是因?yàn)槠淙狈σ恍┍匾谋O(jiān)控信息。
• 收集并匯總所有 Worker 的各種信息，并生成 events.csv 和 summary.txt。?

如下圖 Figure 5 所示為其增強(qiáng)的 CCL 庫(kù)，和其它的 CCL 類似，整個(gè) CCL 包含 4 層，作者對(duì)其中下面的 3 層進(jìn)行了擴(kuò)展，以增加監(jiān)控功能：

• Communicator 層：會(huì)記錄 Communicator ID、Rank 數(shù)，Rank 分配情況信息。
• Operation 層：監(jiān)控集合通信操作類型、算法、數(shù)據(jù)類型、元素個(gè)數(shù)以及操作的持續(xù)時(shí)間和計(jì)數(shù)。
• Transport 層：收集連接細(xì)節(jié)信息（比如，RDMA IP 和 QP 編號(hào)）以及消息統(tǒng)計(jì)信息，包括傳輸?shù)挠?jì)數(shù)、大小和持續(xù)時(shí)間等。?

在運(yùn)行時(shí)收集上述信息并非易事，需要成本低，準(zhǔn)確率高。為了精確監(jiān)控通信 Kernel 執(zhí)行模式，作者優(yōu)化了所有相關(guān)的 CUDA Kernel，以直接記錄其開(kāi)始和完成時(shí)間，因?yàn)?CPU 時(shí)間戳和 CUDA Event 并不夠準(zhǔn)確?；谝陨鲜占降男畔?，可以檢測(cè)到集群中常見(jiàn)的 4 種錯(cuò)誤類型：通信 Hang，非通信 Hang，通信慢（Communication Slow）和非通信慢（Non-Communication Slow）。檢測(cè)前兩種錯(cuò)誤類型相對(duì)容易，作者并沒(méi)有深入討論，而是將重點(diǎn)集中在識(shí)別慢的問(wèn)題。如下為兩個(gè)案例：

案例 1：通信慢檢測(cè)。以數(shù)據(jù)并行中的 AllReduce 為例，所有 Worker 都要求所有模型副本的梯度平均。因?yàn)樗?Worker 的數(shù)據(jù)切分方式一樣，通信量也一樣，理論上任意兩個(gè) Worker 的通信時(shí)延應(yīng)該相同。因此可以構(gòu)建一個(gè) 2 維混淆矩陣，橫軸表示 Destination 的 Worker ID，縱軸表示 Source 的 Worker ID，對(duì)應(yīng)位置的值表示通信 Latency。如下圖 Figure 6 所示：

• 只有一個(gè)點(diǎn) Latency 比較高，表明這兩個(gè) Worker 的鏈路存在瓶頸。
• 一行 Latency 都比較高，表示對(duì)應(yīng)位置的 Source Worker 可能存在問(wèn)題。
• 一列 Latency 都比較高，表示對(duì)應(yīng)位置的 Destination Worker 可能存在問(wèn)題。?

案例 2：非通信慢檢測(cè)。以 AllReduce 操作中的 Ring 算法為例，所有參與的 Worker 相互連接，形成一個(gè)環(huán)狀結(jié)構(gòu)。每個(gè) Worker 僅與相鄰 Worker 通信，可以稱為“上一個(gè) Rank”和“下一個(gè) Rank”。具體而言，Worker 從“上一個(gè) Rank”接收數(shù)據(jù)塊，對(duì)其 local 數(shù)據(jù)執(zhí)行 Reduce 操作，然后將生成的數(shù)據(jù)傳遞給“下一個(gè) Rank”。事實(shí)上，由于要求接收方必須首先準(zhǔn)備接收緩沖區(qū)并通知發(fā)送方，然后才能進(jìn)行數(shù)據(jù)傳輸，存在一種不明確的“接收方驅(qū)動(dòng)”調(diào)度邏輯。因此，可以通過(guò)查看接收方等待數(shù)據(jù)的時(shí)間來(lái)診斷非通信慢問(wèn)題，比如由計(jì)算或數(shù)據(jù)加載引起的等待：

• 如果接收方遇到非通信慢問(wèn)題，則發(fā)送方可能已經(jīng)在等待，從而一旦接收方發(fā)起調(diào)度信號(hào)就可以快速接收數(shù)據(jù)。
• 相反，如果發(fā)送方存在非通信慢問(wèn)題，即使接收方發(fā)起調(diào)度信號(hào)后也不會(huì)及時(shí)發(fā)送數(shù)據(jù)，從而導(dǎo)致接收方等待時(shí)間過(guò)長(zhǎng)。

4.2 并行訓(xùn)練可擴(kuò)展性

并行訓(xùn)練性能依賴于單節(jié)點(diǎn)計(jì)算效率，數(shù)據(jù)訪問(wèn)速度以及集合通信速度等。單節(jié)點(diǎn)計(jì)算能力可以通過(guò)混合精度或者使用 Transformer Engine 來(lái)提升，數(shù)據(jù)訪問(wèn)效率可以通過(guò) Alluxio 等 Cache 機(jī)制實(shí)現(xiàn)。本文主要聚焦在集合通信效率，其中一個(gè)關(guān)鍵因素是訓(xùn)練穩(wěn)定性。

如果將網(wǎng)絡(luò)帶寬視作一種資源，則優(yōu)化集合通信性能相當(dāng)于尋找一種最優(yōu)的資源分配方案。事實(shí)上，集合通信可以看做是兩個(gè) Worker 之間一對(duì)一通信的集合，如果包含 Reduce 操作，也可能涉及計(jì)算。因此，尋找最優(yōu)資源分配的問(wèn)題可以分解為兩個(gè)問(wèn)題：

• 最小化每一次一對(duì)一通信的資源需求。
• 將每一次一對(duì)一通信映射到網(wǎng)絡(luò)資源上，使得總通信時(shí)間最短。

第一個(gè)問(wèn)題不是本文的重點(diǎn)，為了完整性，作者只是做了簡(jiǎn)單介紹。一旦一對(duì)一通信的數(shù)據(jù)量固定，其對(duì)網(wǎng)絡(luò)資源的消耗與數(shù)據(jù)在網(wǎng)絡(luò)中傳輸?shù)木嚯x成正比。為了減少數(shù)據(jù)傳輸距離，作者采用了兩種優(yōu)化策略：

• 首先，通過(guò)創(chuàng)新的網(wǎng)絡(luò)架構(gòu)最小化網(wǎng)絡(luò)直徑，AI 訓(xùn)練服務(wù)器內(nèi)部提供高速 NVLink 互連，它是網(wǎng)絡(luò)固有的一部分（要點(diǎn) 5）。因此，網(wǎng)絡(luò)實(shí)際上是一個(gè)分層拓?fù)洌渲?NVLink 構(gòu)成第一層，不同服務(wù)器間的 RDMA 網(wǎng)絡(luò)構(gòu)成第二層。此外，還采用了雙上行鏈路技術(shù)，這不僅可以提高網(wǎng)絡(luò)可靠性，還可以增加交換芯片的基數(shù)。顯然，對(duì)于給定數(shù)量的 endpoint 和指定的網(wǎng)絡(luò)拓?fù)?，交換基數(shù)越大，網(wǎng)絡(luò)直徑越小。
• 其次，利用網(wǎng)絡(luò)拓?fù)涓兄{(diào)度技術(shù)來(lái)確保需要通信的兩個(gè) Rank 在網(wǎng)絡(luò)中盡可能接近。

基于以上優(yōu)化，大多數(shù)情況下都能實(shí)現(xiàn)良好的性能。例如，對(duì)于小規(guī)模的單個(gè)任務(wù)，所有通信都可以在單層 Leaf 交換機(jī)內(nèi)完成。但對(duì)于較大規(guī)模的訓(xùn)練任務(wù)或多個(gè)任務(wù)并存的場(chǎng)景，進(jìn)一步優(yōu)化是必不可少的。上述兩種場(chǎng)景的根本問(wèn)題其實(shí)是一樣的：有大量的流量需要 Spine 交換機(jī)轉(zhuǎn)發(fā)，導(dǎo)致大量的流量沖突。

為了應(yīng)對(duì)這一挑戰(zhàn)，作者引入了 C4P（C4 Performance）系統(tǒng)，旨在減少不必要的通信成本。C4P 通過(guò)以下方式優(yōu)化并發(fā)作業(yè)和鏈路故障下的通信：

• 在任務(wù)啟動(dòng)時(shí)識(shí)別和避免故障鏈路。
• 在路徑之間平衡 RDMA QP 以分配負(fù)載。
• 根據(jù)網(wǎng)絡(luò)變化和流量沖突動(dòng)態(tài)調(diào)整 QP 工作負(fù)載。

本質(zhì)上，C4P 是一種流量工程（traffic engineering）技術(shù)，旨在通過(guò)調(diào)節(jié)網(wǎng)絡(luò)內(nèi)每個(gè)數(shù)據(jù)流的傳輸路徑來(lái)最大限度地減少網(wǎng)絡(luò)擁塞。這個(gè)概念并不新鮮，但由于網(wǎng)絡(luò)中有大量連接，它在傳統(tǒng)數(shù)據(jù)中心并不常用。C4P 在并行訓(xùn)練場(chǎng)景中很實(shí)用，主要是因?yàn)椴⑿杏?xùn)練產(chǎn)生的流量特征與傳統(tǒng)云應(yīng)用進(jìn)程的流量特征有顯著不同。也就是說(shuō)，并行訓(xùn)練任務(wù)涉及的數(shù)據(jù)流數(shù)量很少，但傳輸?shù)臄?shù)據(jù)量很大。少量大流量的存在使得 C4P 可以精心規(guī)劃每個(gè)數(shù)據(jù)流的路線（要點(diǎn) 6）。

C4P 遵循 C4D 的軟件結(jié)構(gòu)，但有關(guān)鍵區(qū)別，如下圖 Figure 7 所示：

• 首先，與專注于單個(gè)作業(yè)的 C4D master 不同，C4P master 充當(dāng)多個(gè)作業(yè)或租戶的控制中心。
• 此外，C4P 的 CCL 可以為通信 Worker 請(qǐng)求路徑分配，而 C4D 的 CCL 收集監(jiān)控?cái)?shù)據(jù)。
• 最后，C4P 的 master 分配通信路徑，而 C4D 的 master 處理故障檢測(cè)和診斷。?

與先前的研究類似，作者使用路徑探測(cè)（path-probing）進(jìn)行精細(xì)的流量工程：C4P 首先隔離并屏蔽 Leaf 交換機(jī)和 Spine 交換機(jī)之間的故障鏈路，從而創(chuàng)建健康鏈路網(wǎng)絡(luò)。C4P master 通過(guò)每個(gè) Leaf 交換機(jī)隨機(jī)選擇的服務(wù)器執(zhí)行全網(wǎng)狀路徑探測(cè)，識(shí)別和分類可靠路徑。在創(chuàng)建連接時(shí)，CCL 會(huì)向 C4P master 發(fā)出路徑請(qǐng)求，后者通過(guò)指定 RDMA 連接的源 Port 來(lái)響應(yīng)所選路徑。master 通過(guò)禁止從左 Port 到右 Port 的路徑（反之亦然）來(lái)確保來(lái)自同一 NIC 的流量在左 Port 和右 Port 之間保持平衡。此外，來(lái)自同一 Leaf 交換機(jī)下的節(jié)點(diǎn)的流量分布在所有可用的 Spine 交換機(jī)上，以防止網(wǎng)絡(luò)擁塞。CCL 不斷評(píng)估各種路徑上的消息完成時(shí)間，并優(yōu)先考慮最快的數(shù)據(jù)傳輸。如果最佳 QP 的隊(duì)列已滿，則選擇下一個(gè)最佳隊(duì)列。這種方法有助于在路徑錯(cuò)誤或流量擁塞的情況下保持較低的傳輸延遲。

C4P 的部署方法與 C4D 相似，兩個(gè)系統(tǒng)都嵌入到用戶鏡像中，以方便與 Kubernetes (K8s) 集成。然而，一個(gè)顯著的區(qū)別是，C4P master 在系統(tǒng)級(jí)別上運(yùn)行，提供全局訪問(wèn)，而 C4D master 則發(fā)揮更本地化的作用，僅限于單個(gè)作業(yè)范圍。

五、評(píng)估

5.1 配置

如下圖 Table 2 所示為作者運(yùn)維的集群配置及相應(yīng)評(píng)估的配置，可以看出，單節(jié)點(diǎn) 8*H800 GPU，對(duì)應(yīng) 8 個(gè) 400Gbps BlueField-3 NIC，每個(gè) 400 Gbps NIC 會(huì)分成 2 個(gè) 200 Gbps Port。作者測(cè)試時(shí)使用了 16 個(gè)節(jié)點(diǎn)，共 128 H800 GPU。其中的網(wǎng)絡(luò)為 3-Tier Clos 拓?fù)洌?:1 收斂。網(wǎng)絡(luò)拓?fù)渲惺褂貌┩ǖ?Trident4 作為 Leaf 交換機(jī)（64 x 200GbE, 或 32 x 400GbE），Tomahawk4 作為 Spine 交換機(jī)（128 × 200GbE，或 64 x 400GbE），其集群可以支持超過(guò) 10000 GPU，在單 Pod 中是 512 GPU（(128/2/2)*(64/2/2)=512）。

作者基于一個(gè)真實(shí)的 LLM 訓(xùn)練任務(wù)評(píng)估了 C4D 的有效性，其中模型包含 175B 參數(shù)量，使用 2400 GPU 進(jìn)行訓(xùn)練，模型從頭訓(xùn)練需要 1 個(gè)月的時(shí)間。C4P 的有效性是基于集合通信 Benchmark 和 3 個(gè)典型的訓(xùn)練任務(wù)來(lái)評(píng)估。為了確保通信基準(zhǔn)測(cè)試的無(wú)偏評(píng)估，作者使用基于環(huán)的算法。

5.2 C4D 有效性評(píng)估

如下圖 Table 3 所示，作者以內(nèi)部 2400 GPU，訓(xùn)練 1 個(gè)月的任務(wù)為例，對(duì)比了在部署容錯(cuò)系統(tǒng)之前（2023 年 6 月）和之后（2023 年 12 月）錯(cuò)誤導(dǎo)致的停機(jī)時(shí)間?？梢钥闯?，部署 C4D 后停機(jī)時(shí)間大幅減少，從 31.19% 下降到 1.16%。

在部署 C4D 之前：

• 大部分停機(jī)花費(fèi)在系統(tǒng)診斷和隔離，占 19.65%，主要是排查問(wèn)題，通常花費(fèi)數(shù)小時(shí)到數(shù)天時(shí)間。從表中也可以看出，大多數(shù)錯(cuò)誤都是 GPU 缺陷引起，包括 GPU ECC Error，NVLink Error 和 CUDA Error。
• 第二個(gè)主要因素是Post-Checkpoint時(shí)間，占 7.53%，也就是重啟導(dǎo)致浪費(fèi)的計(jì)算時(shí)間。其解決方案主要是更頻繁地保存 Checkpoint。
• 第三個(gè)因素是檢測(cè)時(shí)間，占 3.41%，通常用戶不會(huì)立刻意識(shí)到任務(wù)異常，比如 Pytorch 作業(yè)可能會(huì)掛起 30 分鐘才會(huì)終止進(jìn)程，這種延遲也會(huì)帶來(lái)資源浪費(fèi)。

在部署 C4D 之后：

• 顯著加快了錯(cuò)誤檢測(cè)和故障組件的精確定位，將響應(yīng)時(shí)間縮短到僅幾十秒。盡管如此，仍然需要幾分鐘來(lái)隔離受影響節(jié)點(diǎn)并重新啟動(dòng)作業(yè)。
• 可以每 10 分鐘保存一個(gè) Checkpoint，相應(yīng)的 Post-Checkpoint 時(shí)間可以大幅降低。
• 在部署 C4D 之前的 6 個(gè)月里系統(tǒng)中最脆弱的組件也被修復(fù)和增強(qiáng)，相應(yīng) Re-Initialization 的時(shí)間也從 0.6% 降低到 0.15%。?

5.3 C4P 有效性評(píng)估

平衡一個(gè) NIC 上兩個(gè)物理 Port 之間的流量。每個(gè) Source GPU 和 Destination GPU 都對(duì)應(yīng)一個(gè) NIC，每個(gè) NIC 都有兩個(gè)物理 Port，如果 Source GPU 中的數(shù)據(jù)從對(duì)應(yīng)的某個(gè) Port 發(fā)出后，再經(jīng)過(guò)交換機(jī)，可能被路由到 Destination GPU 對(duì)應(yīng)的任何一個(gè) Port，這樣也就可能存在不均衡導(dǎo)致性能下降。使用 C4P，可以為每個(gè)物理 Port 中的流量綁定一條專用路徑，從而防止這種不均衡。作者使用 NVIDIA 的 NVIDIA/nccl-tests 來(lái)測(cè)量相應(yīng)的 busbw，這是一個(gè)反映有效通信性能的指標(biāo)（busbw 越高，通信時(shí)延越低）。如下圖 Figure 8 所示為啟用 C4P 后 AllReduce 操作的性能，可以看出 busbw 都明顯提升。比較奇怪的是其中紅框里的 busbw 超過(guò)了 NIC 的 400 Gbps，作者介紹說(shuō)是 busbw 的計(jì)算方法導(dǎo)致，但并未具體介紹計(jì)算方法有什么問(wèn)題（PS：如果是采用 Tree-based 算法，機(jī)內(nèi)通信可以使用 NVLink，那么是可能超過(guò) busbw 的；但是作者提到了采用的是 Ring-based 算法，所以按道理 busbw 應(yīng)該小于 NIC 帶寬，而且也沒(méi)看出計(jì)算方式有什么問(wèn)題，此處存疑）。

多作業(yè)流量負(fù)載均衡。為了評(píng)估 C4P 在同時(shí)執(zhí)行多種作業(yè)下的有效性，作者使用 8 個(gè) AllReduce Benchmark 來(lái)模擬作業(yè)。每個(gè)作業(yè)都會(huì)被分配 2 個(gè)節(jié)點(diǎn)，并且來(lái)自不同的 Leaf 交換機(jī) Group，以確保 2 個(gè)節(jié)點(diǎn)之間的流量肯定需要通過(guò) Spine 交換機(jī)。如下圖 Figure 9a 所示，使用 C4P 后可以有效提升實(shí)際吞吐。為了評(píng)估 C4P 在擁塞網(wǎng)絡(luò)環(huán)境中的性能，作者特意將網(wǎng)絡(luò)中的 Spine 交換機(jī)屏蔽了一半，從而將網(wǎng)絡(luò)收斂比變?yōu)?2:1。重新進(jìn)行上述實(shí)驗(yàn)，可以得出類似結(jié)論，當(dāng)然，因?yàn)槭諗勘葹?2:1，極限帶寬也只有 200Gbps。

需要說(shuō)明的是，即使啟用了 C4P，并發(fā)任務(wù)的性能也會(huì)略有變化。具體來(lái)說(shuō)，最高和最低吞吐之間有 11.27 Gbps 的小差距。這種差異歸因于 RDMA NIC 中的擁塞控制機(jī)制，該機(jī)制根據(jù)網(wǎng)絡(luò)條件動(dòng)態(tài)調(diào)整發(fā)送方的數(shù)據(jù)傳輸速率。如下圖 Figure 10 所示，每個(gè)綁定端口每秒接收大約 15,000 個(gè)擁塞通知數(shù)據(jù)包 (CNP)，數(shù)量在 12,500 到 17,500 之間波動(dòng)。CNP 的波動(dòng)直接導(dǎo)致了流量的有效帶寬變化。盡管存在這些變化，但啟用 C4P 后，總體吞吐量大幅提高了 65.55%，長(zhǎng)尾問(wèn)題明顯得到緩解：

對(duì)動(dòng)態(tài)鏈路故障的容忍度。全局流量工程（Global traffic engineering）的高效性取決于網(wǎng)絡(luò)條件的穩(wěn)定性。個(gè)別鏈路中斷后可能需要重新路由受影響的流量，這可能導(dǎo)致網(wǎng)絡(luò)中的流量分配不合理，并降低全局流量工程的有效性。此時(shí)將啟動(dòng) C4P 的負(fù)載均衡機(jī)制以調(diào)整流量分布。為了評(píng)估這種機(jī)制的有效性，作者同樣在 1:1 收斂比的情況下復(fù)現(xiàn)了以前的實(shí)驗(yàn)，并在實(shí)驗(yàn)中故意屏蔽某些鏈路。

• 如下圖 Figure 11a 所示為未啟動(dòng) C4P 負(fù)載均衡時(shí)流量的吞吐的變化，鏈路異常后平均帶寬只有 185.76 Gbps。
• 如下圖 Figure 11b 所示為啟動(dòng) C4P 負(fù)載均衡后流量的吞吐變化，鏈路異常后平均帶寬依然有 301.46 Gbps，大幅提升 62.3%。?

為了展示 C4P 負(fù)載均衡如何提高系統(tǒng)吞吐量，作者從 Leaf 交換機(jī)收集了每個(gè)端口的流量分布的統(tǒng)計(jì)數(shù)據(jù)。如下圖 Figure 12 所示，在鏈路異常之前，所有端口都表現(xiàn)出接近最佳的帶寬利用率。然而，鏈路異常后：

• （a）：未啟動(dòng)負(fù)載均衡，只有 3 個(gè)端口顯示流量增加，還有很多正常的端口流量下降。
• （b）：?jiǎn)?dòng)負(fù)載均衡，C4P 動(dòng)態(tài)調(diào)整了流量分布，大部分端口還有較高的帶寬利用率，因此才能提高系統(tǒng)吞吐量。?

作者基于真實(shí)場(chǎng)景評(píng)估了 C4P 的效果，具體來(lái)說(shuō)包含 3 個(gè)任務(wù)：

• job1：使用 Megatron 框架訓(xùn)練 GPT 模型，22B 參數(shù)量，TP 為 8，DP 為 16。
• job2：使用 Deepspeed 訓(xùn)練 LLaMA 模型，7B 參數(shù)量，采用 Zero-Optimization，僅使用 DP。
• job3：使用 Megatron 框架訓(xùn)練 GPT 模型，參數(shù)量 175B，TP 為 8，PP 為 8，DP 為 2。

性能評(píng)估結(jié)果如下圖 Figure 13 所示，可以看出，job 1 和 job 2 的吞吐都有所提升。job1 提升 15.96%，job2 提升 14.1%，而 job3 幾乎沒(méi)有提升。這與訓(xùn)練中通信的占比有關(guān)，前兩個(gè) job 訓(xùn)練中通信開(kāi)銷占到 30% 以上，但 job3 使用了 16 的梯度累積，大大降低了通信成本，所以提升比較小。

六、參考鏈接

1. ??https://arxiv.org/abs/2406.04594??

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