Collective Communication
3 秒看懂
Collective Communication(集合通訊) 是高效能運算與大規模深度學習訓練的核心通訊範式——它不是單點對單點發訊息,而是一組程序同步參與的資料交換模式(如廣播、規約、全收集等),目的是讓成千上萬個GPU在訓練一個超大型模型時,能以最低延遲、最高頻寬效率完成梯度同步、引數分發這類“全員參與”的操作。
直觀理解:單機訓練不需要它;但當你把GPT-4級別的模型拆到數千張GPU上時,每個GPU算完自己的那一份梯度後,必須通過AllReduce這類集合通訊運算元“對錶”整合所有人的梯度,才能更新模型。集合通訊就是這套“對錶”機制的數學抽象與工程實現。
3 分鐘產業解釋
為什麼深度學習離不開它
大型模型訓練(千卡~十萬卡叢集)將模型、資料或流水線切分到不同GPU。無論資料並行(DP)、張量並行(TP)、流水線並行(PP)還是MoE專家並行,每一輪迭代都需要跨GPU同步梯度、聚合啟用或排程令牌路由。這些同步無法通過點對點通訊高效完成——參與方太多、模式固定、對延遲頻寬要求極高——必須由高度最佳化的集合通訊庫(如NCCL、oneCCL、RCCL、MSCCL等)在底層網路(InfiniBand/RoCE)上高效實現。
核心價值
- 頻寬效率:通過Ring/Tree/Recursive Halving-Doubling等拓撲演算法,將N個GPU間AllReduce的通訊量從O(N²)降為O(N),並充分利用每個節點的雙向頻寬。
- 延遲敏感:訓練步耗時中通訊佔比可達20-50%。集合通訊每最佳化1ms,對萬卡叢集的累計價值以年計。
- 規模門檻:十萬卡級叢集(如Meta於2025年揭露的100k+ GPU叢集)要求集合通訊庫能處理節點故障、拓撲感知、分層通訊等生產級複雜性。
當前產業焦點
- NCCL的統治與挑戰:NVIDIA的NCCL是事實標準,深度繫結CUDA生態;但AMD(RCCL)、Intel(oneCCL)、微軟(MSCCL)在建置替代方案。
- 超大規模最佳化:Meta等廠商針對100k+ GPU叢集設計了分層AllReduce、近資料聚合等機制。[arXiv:2510.20171]
- MoE通訊:All-to-All成為新的瓶頸,催生專用的通訊排程與合併策略。
15 分鐘專家深入
集合通訊在分散式訓練中的定位
在大型模型並行訓練的四種主流策略中,集合通訊扮演著不同的角色:
| 並行策略 | 主導集合通訊模式 | 通訊粒度 | 瓶頸特徵 |
|---|---|---|---|
| 資料並行(DP) | AllReduce(梯度同步) | 後向傳播後 | 通訊量與模型引數規模成正比 |
| 張量並行(TP) | AllReduce / ReduceScatter | 前向/後向傳播中,單層內 | 高頻、延遲高度敏感,要求機內高頻寬(NVLink) |
| 流水線並行(PP) | Send/Recv(點對點,不直接要求集合通訊) | 微批次間 | 流水線氣泡時間,非集合通訊主導 |
| MoE專家並行 | All-to-All(Token分發與結果收集) | 每層MoE前後 | 通訊模式稀疏、隨負載動態變化;路由效率決定通訊量 |
關鍵數值:
- 在千卡資料並行中,一次AllReduce需要在所有GPU間完成全規約。若使用Ring演算法,完成時間 ≈ 2(N-1) × (α + Mβ/N),其中α為延遲,N為節點數,M為訊息大小,β為每位元組傳輸時間。
- 實際訓練中,通訊與計算的Overlap(重疊)是達成近線性擴充套件的關鍵——後向傳播完成一部分梯度即可開始非同步通訊。
生產級基礎設施的分層設計
對於10萬卡級叢集[Meta: arXiv:2510.20171],集合通訊的實現須深度分層:
- 機內層(NVLink域):8卡或16卡之間使用NVSwitch,頻寬可達900GB/s(雙向),演算法上使用低延遲的Tree或Direct Load/Store採集。
- 機間層(InfiniBand/RoCE):跨節點使用Ring或分層Ring,配合RDMA,單鏈路400Gb/s或800Gb/s InfiniBand。
- 資料中心層:引入網路拓撲感知——將通訊儘量限制在同一交換器下(rail-local),減少跨層跳數;同時在多rail間做負載均衡。
核心運算元詳解
- AllReduce:最核心。每個參與程序輸入一個等長向量,所有程序最終輸出這些向量的逐元素規約結果(如求和)。在資料並行中規約梯度。
- ReduceScatter:規約+分散。每個程序得到最終規約向量的一段切片。在ZeRO最佳化器(分片狀態)中大量使用。
- AllGather:每個程序的資料拼接後,所有程序得到完整向量。
- All-to-All:每個程序向所有其他程序傳送獨有資料,並從所有程序接收獨有資料。MoE的核心,每個專家從不同GPU接收Token。
技術原理
張量並行的通訊數學本質
在Megatron-LM風格的Transformer張量並行中:
- Attention層的列並行:Q、K、V權重按列切分到各GPU,各自計算區域性Attention。在前向需AllReduce收集完整Attention輸出;後向需相同模式的AllReduce傳播梯度。該AllReduce基於ReduceScatter + AllGather高效實現。
- MLP層的行並行:權重按行切分,前向不需AllReduce,後向需AllReduce收集對輸入x的梯度。
所以,張量並行的通訊是細粒度的,每Transformer層觸發多次AllReduce,要求頻寬極高——這解釋了為何機內NVLink是關鍵,跨節點張量並行基本不可行。
AllReduce的兩種主導演算法
Ring AllReduce(資料傳輸邏輯呈環形):
- 步驟1: ReduceScatter。每個GPU向環中的下一個鄰居傳送資料,沿環累積,經過N-1步後,每個GPU持有一片完整規約的切片。
- 步驟2: AllGather。每個GPU將自己的切片沿環傳送,經過N-1步後所有GPU獲得完全規約向量。
- 通訊量:2(N-1)/N × M ≈ 2M(最優)。
- 延遲:2(N-1)個傳輸步,對機間環境友好(充分利用雙向頻寬,延遲與大N相關)。
Tree AllReduce(邏輯樹):
- Reduce階段自葉子向根匯聚;Broadcast階段自根向葉子分發。
- 延遲:2log₂(N)步,遠優於Ring;但頻寬利用率在根節點易成瓶頸,且需單獨實現。
現代NCCL根據訊息大小和節點數動態選擇Ring與Tree,並混合使用Recursive Halving-Doubling。
All-to-All的排程挑戰
All-to-All在MoE中:N個GPU各路由Top-k專家,一個Token可能要跨GPU發給另一個專家的輸入緩衝區。當專家負載不均時,某GPU可能接收遠多於傳送的Token,導致網路擁塞。最佳化方向包括:Token分組合並、多階段All-to-All、專家放置與通訊排程協同設計。
GPU 0 GPU 1 GPU 2 GPU 3
Out [0,1,2,3] → [A,B,C,D] → [x,y,z,w] → [α,β,γ,δ]
↘↙↘↙↘↙ ↘↙↘↙ ↘↙↘↙ ↘↙↘↙
In 來自各GPU給GPU0 ...對應... ...對應... 來自各GPU給GPU3
的Token分片技術演進史
| 階段 | 時間 | 特徵 | 標誌性事件 |
|---|---|---|---|
| 萌芽期 | ~2000s | MPI規範定義集合通訊原語 | MPI-2標準確立AllReduce等語義 |
| 深度學習適配 | 2014-2017 | GPU通訊庫出現,從通用MPI轉向CUDA最佳化 | NCCL 1.0(2015)釋出,聚焦單機多卡 |
| 萬卡擴充套件期 | 2018-2022 | 多機多卡;NVIDIA收購Mellanox;高階互聯 | NCCL 2.0支援跨節點;NVSwitch;IB HDR |
| 超大規模與異構 | 2023-至今 | 十萬卡級;AMD/Intel追趕;MoE引發All-to-All瓶頸 | Meta 100k+ GPU叢集[arXiv:2510.20171];UEC聯盟成立(超乙太網路) |
技術路線對比
| 維度 | NCCL(NVIDIA) | RCCL(AMD) | MSCCL(微軟) | oneCCL(Intel) |
|---|---|---|---|---|
| 生態繫結 | 深度繫結CUDA/NVLink | ROCm生態 | 為Azure/AI定製 | Intel GPU/Gaudi |
| 拓撲感知 | NVSwitch/InfiniBand深度最佳化 | 適配AMD Infinity Architecture | 對Azure超算網路調優 | 面向Gaudi的內部互聯 |
| 開源狀態 | 閉源(庫形式開源) | 開源 | 開源 | 開源 |
| AllReduce演算法 | 動態選擇Ring/Tree/Double Tree | 當前版本以Ring為主 | 引入Greedy等演算法 | 以Ring/遞迴減半為主 |
| All-to-All支援 | 較基礎;第三方擴充套件 | 基礎支援 | MoE場景深度定製 | 基礎 |
來源:各廠商文件及公開論文; [部分功能未充分揭露]
上下游
上游:硬體與互聯層
- GPU/加速器:NVIDIA H100/B200、AMD MI300X、Intel Gaudi等,片上及片間互聯決定第一步頻寬。
- 機內互聯:NVLink/NVSwitch(NVIDIA)、Infinity Fabric(AMD),頻寬>900GB/s。
- 網路互連:InfiniBand(Quantum/NVIDIA)、RoCE(乙太網路)、PCIe/CXL。800Gb/s鏈路成超大規模標配。
- 交換器/拓撲:胖樹、Torus、DragonFly,決定跨節點延遲和全域性頻寬。
下游:應用與演算法層
- 大型模型訓練架構:Megatron-LM、DeepSpeed、PyTorch FSDP,這些架構隱式呼叫NCCL等通訊後端。
- 最佳化器:ZeRO-1/2/3,分別依賴AllGather、ReduceScatter運算元實現狀態分片。
- MoE系統:Switch Transformer、GLaM、Mixtral等,重度依賴All-to-All排程。
- 推論(大型模型):張量並行同樣需要集合通訊,但負載特徵與訓練不同(前向為主)。
關鍵指標
- 匯流排頻寬(Bus Bandwidth): 所有節點間實際傳輸的有效資料速率。理想AllReduce的Bus BW ≈ 2 × 單節點頻寬。NCCL logs或nccl-tests的report值,千卡叢集可達幾百GB/s到TB/s級別。
- 演算法探測延遲: 對於M大小的AllReduce,從呼叫到完成的端到端時間;生產環境需控制在毫秒級。
- 擴充套件效率: 實測頻寬/理論頻寬。90%以上為優秀;隨著節點數增加,維持在高水平是極難的工程課題。
- 通訊-計算重疊率: 通訊時間佔總步時比例需壓至30%以下;通過CUDA Graph、前置AllReduce等手段提升重疊。
- 拓撲利用率: 實際使用的網路路徑在物理拓撲中的匹配度,避免跨pod擁塞。
供需與市場資料
- 市場規模:與AI訓練叢集資本支出強相關。2025年全球AI伺服器出貨超[供應鏈估算:數百萬臺],配套的InfiniBand/NVLink/高速乙太網路裝置市場數十億美元級別。集合通訊作為其上的軟體棧,雖不直接售賣,但構成核心價值壁壘。
- 驅動因素:訓練模型引數量從GPT-3的175B走到GPT-4的[MoE~1.8T規模(市場估算)];模型規模每擴大一個數量級,集合通訊的壓力呈超線性增長。
- 格局:NVIDIA憑藉NCCL+InfiniBand/NVLink生態佔據≥90%的加速器互聯市場;UEC(超乙太網路聯盟)推動開放乙太網路方案,AMD/Intel/Gaudi推動開放通訊棧,但替代進度緩慢。
代表公司與資本對映
| 公司 | 定位 | 資本市場關聯 |
|---|---|---|
| NVIDIA | 閉環生態:NVLink+NCCL+InfiniBand;雲端上有Quantum交換器 | 直接受益標的;通訊生態是其AI硬體定價權核心支柱 |
| AMD | 建置RCCL+Infinity Architecture,追趕中 | MI300X系列被多個超算選用,但通訊生態成熟度受關注 |
| Intel | Gaudi加速器+oneCCL,主打價效比 | 被市場視作生態二線;Gaudi 3/ Falcon Shores前景待驗證 |
| Broadcom/Marvell | 交換器晶片、高速SerDes/DSP | AI網路底層受益方;800G/1.6T光模組及交換器ASIC供應商 |
| 雲端廠商(Google/AWS/Azure/Meta) | 自研晶片TPU/Trainium/Maia+定製化通訊 | 部分減少了對外部NCCL生態的依賴,但訓練叢集中仍大量使用NVIDIA GPU |
投資邏輯
- 硬體互聯鎖定效應:NVIDIA的NVLink與InfiniBand高度繫結CUDA;即使AMD硬體算力追平,通訊庫/網路切換成本巨大,構成極寬的“經濟護城河”。判斷AI訓練投資的可持續性,需評估對NVIDIA通訊生態的依賴度。
- All-to-All成為新戰場:MoE模型路線如果成為下一代訓練範式,All-to-All最佳化將成為下一個關鍵瓶頸點,在競爭中可能帶來技術視窗期。
- 乙太網路的追趕機會:因為成本(InfiniBand溢價)和開放性,UEC聯盟推動的超級乙太網路在推論及部分訓練場景有增量機會,對博通、Marvell及高速光模組廠商有利,但需警惕對NVIDIA高獲利網路業務的長遠侵蝕。
- 投資對映:訓練網路每升級一代(400G→800G→1.6T),光模組、交換器、線纜(銅/光)的配套量價齊升;集合通訊軟體的最佳化程度直接決定該升級能否被轉化為真實的訓練擴充套件效率。
常見誤讀糾偏
誤讀1:“集合通訊等同於MPI,有NCCL就夠了”
糾偏:MPI是最初的載體,但NCCL是為GPU間通訊完全重新設計的——它繞過OS記憶體棧,直接通過GDR(遠端直接GPU記憶體訪問)和核心驅動實現極致的低延遲和高頻寬。MPI生態(OpenMPI等)仍存在,但在深度學習訓練中逐漸被NCCL及架構內建通訊後端取代。兩者目標不同:MPI面向通用HPC,NCCL面向GPU加速訓練。
誤讀2:“MoE的All-to-All溝通量不大,可以忽略”
糾偏:在GPT-4等MoE大型模型中,Token路由每步都要觸發All-to-All通訊,其總通訊量可達梯度同步AllReduce的2-3倍。如果不做合併排程,將嚴重拖慢步時,需要專門的緩衝合併和通訊排程演算法來緩解。
誤讀3:“用更多GPU加速AllReduce總是更快”
糾偏:AllReduce的延遲與參與節點數強相關(特別是Ring演算法)。儘管匯流排頻寬理論上隨節點數增加,但每步的延遲(α項)隨N線性增長。訓練大規模資料並行時,存在最優GPU數量,超過該數量後,通訊延遲增加會吃掉算力增益,稱為“通訊牆”。
學習路徑
- MPI標準基礎(淺度):瞭解Broadcast, Scatter, Gather, Reduce, AllReduce, All-to-All的語義。可閱讀MPI官方文件或MPI教程。
- NCCL官方文件與測試:執行
nccl-tests,理解all_reduce_perf日誌,看懂Bus BW與Alg BW的區別。 - Distributed深度學習實戰:用PyTorch DDP訓練一個簡單模型,通過profiling工具檢視通訊耗時;嘗試DeepSpeed ZeRO,觀察AllGather/ReduceScatter。
- 進階論文:
- “Bandwidth Optimal All-reduce Algorithms for Clusters of Workstations”(經典樹/環演算法)
- Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism(張量並行的通訊分析)
- Meta: Collective Communication for 100k+ GPUs（arXiv:2510.20171，生產級十萬卡經驗）
- 原始碼與實現:閱讀NCCL開源版本(部分)、MSCCL程式碼,理解Ring/All-to-All的分塊傳輸和流控制。
一句話總結
集合通訊是大型模型並行訓練中跨GPU的同步核心;從AllReduce到All-to-All,其演算法與實現直接決定了千卡到十萬卡叢集上的訓練牆能否被打破。
延伸閱讀與來源
- NCCL官方: https://developer.nvidia.com/nccl
- Meta 100k+ GPU集合通訊論文: Si et al., “Collective Communication for 100k+ GPUs,” arXiv:2510.20171, 2025.
- Megatron-LM張量並行: Shoeybi et al., “Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism,” arXiv, 2019.
- DeepSpeed ZeRO通訊分析: Rajbhandari et al., “ZeRO: Memory Optimizations Toward Training Trillion Parameter Models,” SC 2020.
- MoE與All-to-All: Lepikhin et al., “GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding,” ICLR 2021.
- UEC聯盟: https://uec-org.org
注:技術指標(如NVLink頻寬等)均依據NVIDIA官方公開產品資料;市場估算來自行業口徑及供應鏈分析,已明確標註。