网络层 开放阅读

Collective Communication

Collective Communication

概念 ID
collective-communication
更新时间
2026-05-29
来源数量
待补

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间做负载均衡。

核心算子详解

  1. AllReduce:最核心。每个参与进程输入一个等长向量,所有进程最终输出这些向量的逐元素规约结果(如求和)。在数据并行中规约梯度。
  2. ReduceScatter:规约+分散。每个进程得到最终规约向量的一段切片。在ZeRO优化器(分片状态)中大量使用。
  3. AllGather:每个进程的数据拼接后,所有进程得到完整向量。
  4. 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分片

技术演进史

阶段时间特征标志性事件
萌芽期~2000sMPI规范定义集合通信原语MPI-2标准确立AllReduce等语义
深度学习适配2014-2017GPU通信库出现,从通用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/NVLinkROCm生态为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系列被多个超算选用,但通信生态成熟度受关注
IntelGaudi加速器+oneCCL,主打性价比被市场视作生态二线;Gaudi 3/ Falcon Shores前景待验证
Broadcom/Marvell交换机芯片、高速SerDes/DSPAI网络底层受益方;800G/1.6T光模块及交换机ASIC供应商
云厂商(Google/AWS/Azure/Meta)自研芯片TPU/Trainium/Maia+定制化通信部分减少了对外部NCCL生态的依赖,但训练集群中仍大量使用NVIDIA GPU

投资逻辑

  1. 硬件互联锁定效应:NVIDIA的NVLink与InfiniBand高度绑定CUDA;即使AMD硬件算力追平,通信库/网络切换成本巨大,构成极宽的“经济护城河”。判断AI训练投资的可持续性,需评估对NVIDIA通信生态的依赖度。
  2. All-to-All成为新战场:MoE模型路线如果成为下一代训练范式,All-to-All优化将成为下一个关键瓶颈点,在竞争中可能带来技术窗口期。
  3. 以太网的追赶机会:因为成本(InfiniBand溢价)和开放性,UEC联盟推动的超级以太网在推理及部分训练场景有增量机会,对博通、Marvell及高速光模块厂商有利,但需警惕对NVIDIA高利润网络业务的长远侵蚀。
  4. 投资映射:训练网络每升级一代(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数量,超过该数量后,通信延迟增加会吃掉算力增益,称为“通信墙”


学习路径

  1. MPI标准基础(浅度):了解Broadcast, Scatter, Gather, Reduce, AllReduce, All-to-All的语义。可阅读MPI官方文档或MPI教程。
  2. NCCL官方文档与测试:运行nccl-tests,理解all_reduce_perf日志,看懂Bus BW与Alg BW的区别。
  3. Distributed深度学习实战:用PyTorch DDP训练一个简单模型,通过profiling工具查看通信耗时;尝试DeepSpeed ZeRO,观察AllGather/ReduceScatter。
  4. 进阶论文:
    • “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,生产级十万卡经验)
  5. 源码与实现:阅读NCCL开源版本(部分)、MSCCL代码,理解Ring/All-to-All的分块传输和流控制。

一句话总结

集合通信是大模型并行训练中跨GPU的同步核心;从AllReduce到All-to-All,其算法与实现直接决定了千卡到十万卡集群上的训练墙能否被打破。


延伸阅读与来源

  1. NCCL官方: https://developer.nvidia.com/nccl
  2. Meta 100k+ GPU集合通信论文: Si et al., “Collective Communication for 100k+ GPUs,” arXiv:2510.20171, 2025.
  3. Megatron-LM张量并行: Shoeybi et al., “Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism,” arXiv, 2019.
  4. DeepSpeed ZeRO通信分析: Rajbhandari et al., “ZeRO: Memory Optimizations Toward Training Trillion Parameter Models,” SC 2020.
  5. MoE与All-to-All: Lepikhin et al., “GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding,” ICLR 2021.
  6. UEC联盟: https://uec-org.org

注:技术指标(如NVLink带宽等)均依据NVIDIA官方公开产品数据;市场估算来自行业口径及供应链分析,已明确标注。

source: 公开披露与公开资料整理 本页仅用于产业链学习、信息检索和研究辅助;不构成投资建议,不预测涨跌,不提供买卖、仓位或目标价建议。
完整概念页 复盘 13 节结构 公司投研页 沿产业链找到受益公司 投资课 把概念转成可跟踪模型