在分布式AI訓練場景中，GPU集合通信路徑是支撐多節(jié)點協(xié)同計算的核心基礎設施。通過集合通信庫（如NVIDIA NCCL、華為HCCL等），跨GPU的數(shù)據(jù)交換（AllReduce、Broadcast等操作）得以高效執(zhí)行，從而實現(xiàn)大規(guī)模模型參數(shù)的同步與梯度聚合。

然而，隨著智算集群規(guī)模的擴展，通信路徑的復雜性呈指數(shù)級增長，暴露出以下技術難題。

路徑黑盒化：現(xiàn)有集合通信庫（Collective Communication Libraries, CCLs）對用戶屏蔽底層通信細節(jié)（如物理拓撲、網卡綁定策略、路由選擇），導致性能瓶頸難以定位。

異構環(huán)境兼容性：多廠商CCLs（如ACCL、TCCL）的差異化實現(xiàn)，增加了跨平臺部署與調優(yōu)的復雜度。

動態(tài)資源適配不足：傳統(tǒng)靜態(tài)路由規(guī)劃無法適應動態(tài)負載變化，易造成網絡擁塞與帶寬利用率低下。

故障溯源低效：訓練中斷時，需人工排查模型、硬件、網絡多層級問題，MTTR（平均修復時間）顯著增加。

集合通信路徑的架構解析

通信路徑的層級劃分

GPU集合通信路徑涵蓋以下核心層級：

• 節(jié)點內通信：通過NVLink/PCIe實現(xiàn)多GPU間P2P直連，依賴CUDA驅動層優(yōu)化。
• 跨節(jié)點通信：基于RDMA（如RoCEv2）協(xié)議，通過智能網卡（如ConnectX系列）與交換機構建低延遲、高吞吐的數(shù)據(jù)通道。
• 邏輯通信環(huán)：NCCL等庫根據(jù)硬件拓撲自動構建邏輯環(huán)形/樹形結構，優(yōu)化數(shù)據(jù)流并行性。

現(xiàn)有方案的局限性

盡管NCCL通過拓撲感知算法優(yōu)化通信效率，但其運行時仍存在以下缺陷：

• 路徑不可觀測：用戶無法獲取通信環(huán)的實際物理路徑（如交換機端口映射、QoS策略）。
• 配置僵化：缺少動態(tài)路由調整機制，無法感知網絡擁塞或鏈路故障。
• 診斷信息碎片化：日志分散于各節(jié)點，缺乏全局視圖與關聯(lián)分析能力。

EPS（E2E Path Scheduler，端到端路徑規(guī)劃）的技術實現(xiàn)

架構設計目標

EPS旨在打破集合通信的“黑盒”狀態(tài)，提供以下核心能力：

• 全路徑可視化：實時映射邏輯通信環(huán)至物理網絡拓撲。
• 智能路由優(yōu)化：基于實時流量狀態(tài)生成最優(yōu)路徑配置。
• 自動化運維：通過API驅動網絡設備策略下發(fā)，減少人工干預。

關鍵技術模塊

通信環(huán)解析與拓撲重構

EPS通過解析NCCL日志中的ncclTopoGraph結構，提取邏輯GPU通信組（如Ring、Tree），并關聯(lián)物理設備信息（GPU UUID、網卡端口號）。結合LLDP協(xié)議與交換機CLI查詢，動態(tài)構建端到端路徑拓撲圖（如圖1）。

路由規(guī)劃算法

采用混合式路徑選擇策略：

• 靜態(tài)權重分配：基于鏈路帶寬、延遲、丟包率構建代價模型。
• 動態(tài)負載均衡：集成Prometheus監(jiān)控數(shù)據(jù)，實時感知隊列深度與ECN標記，觸發(fā)路徑重計算。
• 容災路由：預設多路徑冗余，在鏈路故障時自動切換至備份路徑。

如何使用 EPS？

安裝配置

演示環(huán)境中的 Master 節(jié)點為一臺獨立的 CentOS 服務器，項目指定的工作目錄為 /home/admin/EPS

配置控制面板

演示使用 EasyRoCE Toolkit 內的統(tǒng)一監(jiān)控面板（UG，Unified Glancer），在此之前需要提前完成該平臺的部署，請參閱：一文解讀開源開放生態(tài)下的RDMA網絡監(jiān)控實踐 中的“監(jiān)控平臺配置”部分。

我們只需要為 UG 再添加一個呈現(xiàn) HTML 的 Pannel，并完成 HTML 源的配置（如下圖所示），EPS 解析出來的集合通信環(huán)信息就將作為各類 RDMA 網絡相關監(jiān)控指標信息的補充，輔助集群設施調優(yōu)決策。

完成以上所有步驟，我們就可以在 UG 看到實時更新的集合通信庫運行信息，手動更新NCCL 日志文件，可以看到 UG 中呈現(xiàn)的解析信息也同步刷新。