一、背景

我們在之前的兩篇文章中詳細介紹了萬卡 GPU 集群中的網(wǎng)絡(luò)拓撲相關(guān)信息以及在萬卡 GPU 集群中進行大規(guī)模 LLM 訓(xùn)練面對的挑戰(zhàn)和相應(yīng)解決方案。最近又看到阿里團隊在相關(guān)領(lǐng)域的工作，本文中我們簡單對其進行總結(jié)。論文中很多基礎(chǔ)知識沒有展開介紹，強烈建議優(yōu)先閱讀對應(yīng)的兩篇文章：

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

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

二、摘要

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

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

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

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

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

三、引言

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

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

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

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

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

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

根據(jù)以上公式可以進一步預(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ò)中任意兩個節(jié)點之間的最短路徑中最長的一條路徑的長度，通常用跳數(shù)（hops）來表示：

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

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

3.3 錯誤處理

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

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

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

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

3.4 優(yōu)化通信

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

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

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

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

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

四、方法

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

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

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

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

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

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

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

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

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

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

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

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

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

• 在每個 Worker 中都會使用增強的 CCL，并且每個 Worker 上都會有 C4a 以便收集當(dāng)前 Worker 相關(guān)信息，比如 CCL 日志。作者沒有直接使用NCCL是因為其缺乏一些必要的監(jiān)控信息。
• 收集并匯總所有 Worker 的各種信息，并生成 events.csv 和 summary.txt。?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五、評估

5.1 配置

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

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

5.2 C4D 有效性評估

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

在部署 C4D 之前：

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

在部署 C4D 之后：

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

5.3 C4P 有效性評估

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

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

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

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

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

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

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

作者基于真實場景評估了 C4P 的效果，具體來說包含 3 個任務(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。

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

六、參考鏈接

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

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