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

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

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

異構環境兼容性：多廠商CCLs（如ACCL、TCCL）的差異化實現，增加了跨平臺部署與調優的復雜度。

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

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

集合通信路徑的架構解析

通信路徑的層級劃分

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

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

現有方案的局限性

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

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

EPS（E2E Path Scheduler，端到端路徑規劃）的技術實現

架構設計目標

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

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

關鍵技術模塊

通信環解析與拓撲重構

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

路由規劃算法

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

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

如何使用 EPS？

安裝配置

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

配置控制面板

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

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

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