一、背景

我們在之前的兩篇文章中詳細介紹了萬卡 GPU 集群中的網絡拓撲相關信息以及在萬卡 GPU 集群中進行大規模 LLM 訓練面對的挑戰和相應解決方案。最近又看到阿里團隊在相關領域的工作，本文中我們簡單對其進行總結。論文中很多基礎知識沒有展開介紹，強烈建議優先閱讀對應的兩篇文章：

• ??萬卡 GPU 集群互聯：硬件配置和網絡設計??
• ??萬卡 GPU 集群實戰：探索 LLM 預訓練的挑戰??

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

二、摘要

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

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

為了應對這些挑戰，論文作者提出了一種由通信驅動的解決方案，即 C4（Calibrating Collective Communication over Converged Ethernet）。其關鍵想法有兩點：

• 首先，在并行訓練中，集合通信表現出周期性和同質性的特征，因此任何異常肯定是由于某種形式的硬件故障引起的。利用此特性，C4 可以快速識別故障組件，迅速隔離異常并重新啟動任務，從而避免因異常檢測時延而造成的資源浪費。
• 其次，集合通信的可預測通信模型（涉及少量大流量）使 C4 能夠高效地執行流量規劃，從而大大減少網絡擁塞。

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

三、引言

3.1 訓練預估

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

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

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

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

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

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

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

3.2 基本概念

網絡直徑（Network Diameter）指的是網絡中任意兩個節點之間的最短路徑中最長的一條路徑的長度，通常用跳數（hops）來表示：

• 最短路徑：在網絡圖中，從一個節點到另一個節點的所有可能路徑中，所需跳數最少的一條路徑。
• 最長的最短路徑：對于網絡中所有可能的節點對，每個對都有一個最短路徑，網絡半徑就是這些最短路徑中跳數最多的那一條的跳數。

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

3.3 錯誤處理

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

如下圖 Figure 1 所示，在執行 DL 訓練作業之前或之中都可能出現嚴重錯誤，它們會以不同的方式影響系統利用率：

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

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

3.4 優化通信

除了異常導致作業崩潰之外，GPU 還可能由于集合通信操作或數據加載延遲而出現停頓：

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

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

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

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

四、方法

4.1 并行訓練穩定性

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

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

利用成熟的云存儲技術提供可靠的數據存儲。

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

關于網絡，業界普遍采用單 Port NIC（例如 1*400Gbps）來減少哈希沖突的可能性。然而，這種方式可能帶來可靠性問題，端口異常可能迫使任務從最近的 Checkpoint 重新啟動。而作者采用了 2*200Gbps 雙上行鏈路來增強可靠性，同時解決網絡哈希沖突以維持性能。本質上講，確保每一層的最大可靠性，再加上跨層優化，對于實現最高效、最可靠的整體系統至關重要（要點 3）。

作者的 C4D 容錯架構包括如下幾點：

• 通過糾錯碼實現可靠的數據傳輸。
• 通過雙上行鏈路和多路徑通信實現網絡可靠性。
• 通過 Checkpoint 和冗余節點處理計算故障。

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2 并行訓練可擴展性

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

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

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

第一個問題不是本文的重點，為了完整性，作者只是做了簡單介紹。一旦一對一通信的數據量固定，其對網絡資源的消耗與數據在網絡中傳輸的距離成正比。為了減少數據傳輸距離，作者采用了兩種優化策略：

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

基于以上優化，大多數情況下都能實現良好的性能。例如，對于小規模的單個任務，所有通信都可以在單層 Leaf 交換機內完成。但對于較大規模的訓練任務或多個任務并存的場景，進一步優化是必不可少的。上述兩種場景的根本問題其實是一樣的：有大量的流量需要 Spine 交換機轉發，導致大量的流量沖突。

為了應對這一挑戰，作者引入了 C4P（C4 Performance）系統，旨在減少不必要的通信成本。C4P 通過以下方式優化并發作業和鏈路故障下的通信：

• 在任務啟動時識別和避免故障鏈路。
• 在路徑之間平衡 RDMA QP 以分配負載。
• 根據網絡變化和流量沖突動態調整 QP 工作負載。

本質上，C4P 是一種流量工程（traffic engineering）技術，旨在通過調節網絡內每個數據流的傳輸路徑來最大限度地減少網絡擁塞。這個概念并不新鮮，但由于網絡中有大量連接，它在傳統數據中心并不常用。C4P 在并行訓練場景中很實用，主要是因為并行訓練產生的流量特征與傳統云應用進程的流量特征有顯著不同。也就是說，并行訓練任務涉及的數據流數量很少，但傳輸的數據量很大。少量大流量的存在使得 C4P 可以精心規劃每個數據流的路線（要點 6）。

C4P 遵循 C4D 的軟件結構，但有關鍵區別，如下圖 Figure 7 所示：

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

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

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

五、評估

5.1 配置

如下圖 Table 2 所示為作者運維的集群配置及相應評估的配置，可以看出，單節點 8*H800 GPU，對應 8 個 400Gbps BlueField-3 NIC，每個 400 Gbps NIC 會分成 2 個 200 Gbps Port。作者測試時使用了 16 個節點，共 128 H800 GPU。其中的網絡為 3-Tier Clos 拓撲，1:1 收斂。網絡拓撲中使用博通的 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 訓練任務評估了 C4D 的有效性，其中模型包含 175B 參數量，使用 2400 GPU 進行訓練，模型從頭訓練需要 1 個月的時間。C4P 的有效性是基于集合通信 Benchmark 和 3 個典型的訓練任務來評估。為了確保通信基準測試的無偏評估，作者使用基于環的算法。

5.2 C4D 有效性評估

如下圖 Table 3 所示，作者以內部 2400 GPU，訓練 1 個月的任務為例，對比了在部署容錯系統之前（2023 年 6 月）和之后（2023 年 12 月）錯誤導致的停機時間。可以看出，部署 C4D 后停機時間大幅減少，從 31.19% 下降到 1.16%。

在部署 C4D 之前：

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

在部署 C4D 之后：

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

5.3 C4P 有效性評估

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

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

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

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

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

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

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

作者基于真實場景評估了 C4P 的效果，具體來說包含 3 個任務：

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

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

六、參考鏈接

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

本文轉載自??AI閑談??，作者： AI閑談 ????