在大模型训练过程中，通信原语起着举足轻重的作用。大模型训练涉及海量数据和复杂计算，需要多节点协作。通信原语能保障各节点间高效数据交互，像All-Reduce可实现全局梯度同步，让各节点获取相同规约结果，保证模型参数更新一致性；Reduce-Scatter能将规约结果分块到各节点，便于并行计算。
合理运用通信原语可优化训练流程，减少通信延迟，提升计算资源利用率，加速训练速度。若通信原语使用不当，会出现数据传输瓶颈、训练效率低下等问题，影响大模型训练效果和性能。
售前一定要懂通信原语
云计算/智算解决方案售前人员懂大模型训练通信原语十分必要，作为售前，第一要能准确理解客户需求，能通过通信原语与客户探讨训练规模、架构，识别通信方面痛点，如数据并行时的All - Reduce操作，可评估资源需求。
第二，售前也要能提供专业方案，可根据不同通信原语为客户设计合理架构和网络拓扑，优化资源配置，像针对超大模型训练采用的Reduce - Scatter和All - Gather操作。
第三，有利于与研发团队协作，使用共同技术语言，准确传达客户需求，避免沟通障碍。同时，熟悉掌握通信原语，还能与建立客户信任，展示专业能力，深入讨论通信原语让客户感受公司实力，同时能准确解答客户疑问，帮助客户做出明智决策，确保为客户提供贴合需求的云计算/智算解决方案。
训练中通讯操作的必要性
在将神经网络训练并行化到集群的不同节点时，我们必须考虑如何把不同的计算操作合理分配到各个可用节点上。而要实现这一目标，就不可避免地需要对分布式集群的通讯进行操作。
在神经网络的训练学习过程中，随机梯度下降算法（SGD）是常用的训练方法。
以分布式数据并行训练为例，在这种模式下，每一块NPU都拥有整个神经网络模型的完整副本。每次迭代时，每块NPU只会被分配小批次（Batch）数据样本中的一个子集。接着，GPU会利用这些Batch样本数据进行网络模型的前向计算，随后计算损失误差并进行反向传播，以此来计算损耗相对于网络参数的梯度。
最后，各个GPU之间相互通信，计算不同GPU所得到梯度的平均值，再将这个平均梯度应用到总体权重上，从而得到网络模型在本次迭代中的最新权重。在整个过程中，每块 GPU 都按锁定步骤推进迭代。
一旦某块 GPU 完成本轮迭代，它必须等待集群里所有 GPU 都完成各自迭代后，神经网络的总体权重才能被正确更新。 简单来说，这就如同在单个 GPU 上执行随机梯度下降算法（SGD），只不过是把数据分发到多个 GPU 上并行计算，以此实现加速。这便是简单的分布式数据并行（DP）方式。
当仅有两个NPU，且网络模型参数以兆字节计量时，GPU间的通信方式或许影响不大。但一旦网络模型的参数量攀升至十亿乃至万亿级别，仅计算梯度所产生的临时变量，就会占用数十亿字节的GPU内存空间，同时还需协调数十个GPU协同作业，此时通信机制的重要性便凸显出来。
例如，参照上图所示的最直接数据并行通信方式：各个GPU计算自身小Batch数据上的梯度，随后将各自梯度发送至CPU。接着，CPU求取所有梯度的平均值，并把这一平均值发回给其他所有GPU。 在这种由单个CPU负责数据收发的机制里，CPU需要从全部GPU接收参数，再将参数逐一发送至每个GPU。显然，随着分布式集群系统中GPU节点数量的增加，通信成本会急剧上升。
以三亿个可训练参数的网络模型为例，评估上述通信策略在真实网络模型中的带宽效果。假设每个参数4字节，三亿参数约1.2GB。若分布式系统网络硬件带宽为每秒1GB，将系统并行到2个NPU，每次迭代会减慢1.2秒；并行到10个GPU，每次迭代减慢10.8秒，迭代时间随GPU数量线性增长。
数据发送量越大，通信耗时越长。不同通信通道带宽不同，像互联网连接每秒15MB，千兆以太网每秒125MB，HPC集群的Infiniband可达每秒GB级。即便每次迭代仅耗时几秒，通信成本的线性增长也会导致分布式并行不仅无法优化，反而降低训练效率。
大模型参数更新策略
在数据并行训练中，各个NPU依据自身获取的batch数据进行前向计算得出损失，继而通过反向传播算出梯度。梯度计算完成后，梯度同步问题随即而来：各节点都有基于自身数据算出的梯度，怎样在不同节点间维持模型不同副本的一致性呢？
要是不同模型最终以某种形式获得不同权重，权重更新就会不一致，最终致使网络模型参数收敛迭代情况不稳定，这就是模型一致性问题。如何同步更新网络模型参数，成为分布式机器学习系统的关键难题。
为解决模型一致性问题，分布式训练的梯度同步策略分为异步（Asynchronous）梯度更新与同步（Synchronous）梯度更新机制。
|| 同步梯度更新策略
同步，即所有节点均采用相同模型参数开展训练，等所有设备完成batch训练，收集梯度并求均值，最后一次性更新所有网络模型参数。由于每轮迭代结束时，计算快的节点得等待计算慢的节点信息完成同步，才能开启下一轮迭代，如同木桶效应，同步方式的性能取决于集群中通讯最慢的节点 。
|| 异步梯度更新策略
在异步通讯模式下，各节点完成一个batch数据的训练后，无需等待其他节点，可直接更新Server中的网络模型参数。这种异步更新方式避免了因等待单节点数据而产生的阻塞，从而使整体训练速度大幅提升。
然而，异步通讯存在梯度失效（stale gradients）问题。起初所有节点采用相同参数进行训练，但在异步环境中，当某节点完成T步迭代训练时，可能会发现模型参数已被其他设备在T + n步更新。若此时该节点将T步迭代训练得到的参数更新至Server，就会导致n步内的梯度更新失效。尽管异步训练速度较快，但受梯度失效问题影响，可能陷入次优解（sub-optimal training performance） 。
在大模型的训练过程中，分布式并行操作是不可或缺的关键环节。为有效解决通信瓶颈问题，一方面需要充分借助分布式集群的带宽，对通讯操作进行精细优化；另一方面，还需对深度学习的参数同步策略予以深度优化。
AI框架中的通信实现
在分布式集群中，网络硬件丰富多样，涵盖了 Ethernet、InfiniBand 等类型。深度学习框架一般不会直接对硬件进行操作，而是借助通信库来完成通信任务。使用通信库的关键在于，它能够屏蔽底层硬件的复杂细节，为开发者提供统一封装的通信接口，降低开发难度。MPI 和 NCCL 是最为常用的通信库，其中 MPI 主要聚焦于 CPU 的并行通信，而 NCCL 则专注于 GPU 之间的通信，二者在不同场景下发挥着重要作用。
|| 通信原语来源于MPI
消息传递接口MPI（Message Passing Interface）是用于并行计算的标准通信协议， 在计算集群、超算等场景下，MPI 应用广泛，很多传统科学计算的并行程序都借助它来编写。因其接口兼容性出色、通信功能丰富，在深度学习框架里，MPI 主要承担 CPU 数据的通信任务。 作为开放接口，MPI 有多种实现库。其中，Open MPI 是一种被广泛使用的开源实现。此外，部分硬件厂商也会提供针对自身硬件进行优化后的 MPI 实现版本。
自1994年首次发布以来已成为高性能计算（HPC）领域最重要的并行编程模型之一。MPI定义了一组函数接口规范，使程序员能够在分布式内存系统中编写可移植的并行程序。
MPI具有以下核心特点：
标准化：由MPI论坛制定和维护的开放标准
可移植性：可在各种硬件平台和操作系统上运行
高效性：针对大规模并行计算优化
丰富功能：提供超过300个通信原语
我们关注到MPI源于LLM训练，但MPI已经来源已久。
MPI的发展历程见证了高性能计算通信技术的演进与革新。这一标准化进程始于1994年MPI-1的发布，它首次统一了并行计算的通信规范，定义了基础的点对点通信（如Send/Recv）和集体通信操作（如Broadcast、Reduce），并创新性地提出通信器（Communicator）概念，解决了早期各厂商私有接口不兼容的问题。
1998年推出的MPI-2实现了重大扩展，引入动态进程管理、并行文件I/O和远程内存访问等关键特性，使MPI从单纯的通信库升级为支持复杂应用场景的完整并行计算平台。
随着计算规模不断扩大，2012年发布的MPI-3针对超大规模系统进行了深度优化，其标志性的非阻塞集体操作显著提升了通信与计算的重叠能力，同时增强了容错机制和工具接口。
最新一代MPI-4标准于2021年问世，重点优化了持久化通信请求和大规模系统支持，通过减少重复通信开销来适应现代超算和AI训练集群的需求。值得注意的是，MPI标准始终保持严格的向后兼容性，各版本迭代均围绕实际应用痛点展开，体现了"性能导向"的核心设计哲学。
经过近三十年的发展，MPI已从最初的通信规范成长为支撑科学计算、人工智能和大数据处理的基石技术，其演进历程不仅反映了并行计算技术的进步，更彰显了工业界与学术界协同标准化的成功典范。当前主流实现如OpenMPI和MPICH仍在持续完善对MPI-4的支持，确保这一经典标准在E级计算时代继续发挥关键作用。
|| 英伟达NCCL
NCCL（NVIDIA Collective Communication Library ，英伟达集合通信库）是专门实现多个 GPU 甚至多个节点之间通信的工具。它针对英伟达的计算卡和网络进行了优化，能够显著降低通信延迟，提升带宽性能。
NCCL 具备丰富的通信功能，其接口形式与 MPI 类似，能够满足大多数深度学习任务的通信需求。在深度学习框架中，NCCL 主要负责 GPU 数据的通信。 由于 NCCL 是 NVIDIA 基于自身硬件量身定制的，所以优化更具针对性且操作便捷。在英伟达硬件环境下，NCCL 的表现通常优于其他通信库。
OpenMPI的通信算法和通信操作原语在2009年就已成熟开源，而Nvidia在2015年下半年才首次发布NCCL。面对OpenMPI已实现众多All Reduce算法的情况，有人会疑问英伟达为何还要开发NCCL，甚至认为有了NCCL就不再需要MPI。但实际上并非如此。
从OpenMPI源码能看出，它没有考虑深度学习场景以及GPU系统架构。它把各个工作节点等同看待，没有顾及节点间延迟和带宽的差异，所以无法在异构场景下充分发挥硬件性能。Nvidia采取了聪明的策略，不与MPI竞争，而是结合自身硬件，对MPI未做好的通信性能进行优化。在多机多卡分布式训练中，MPI主要用于节点管理，NCCL则专注于GPU的实际规约通信，二者可轻松结合，MPI负责CPU到CPU的通信，NCCL负责GPU到GPU的通信。
NCCL的优势是完全适配英伟达硬件，能充分发挥性能，不过其基本算法原理和OpenMPI实现的算法差异不大。NCCL 1.x只能进行单机内部通信，到2017年第二季度发布的NCCL 2.0才开始支持多节点通信。所以在NCCL 2.0之前，集合通信还得依赖MPI。
|| 集合通信与通信原语
分布式训练过程中设计到许多通信上的操作， 每个操作有其不同的术语并且有所区别。
集合通信（Collective Communications）是一种涉及进程组内所有进程的全局通信操作。在这一操作体系中，发送（send）、接收（receive）、复制（copy）、组内进程栅栏同步（Barrier）以及节点间进程同步（signal + wait）是最为基础的操作。
这些基础操作经过有机组合，形成了一组通信模板，即通信原语。例如
1对多的广播（Broadcast）
多对1的收集（Gather）
多对多的收集（All-Gather）
1对多的发散（Scatter）
多对1的规约（Reduce）
多对多的规约（All-Reduce）
组合的规约与发散（Reduce-Scatter）
以及多对多的（All-to-All）等
集合通信面临的挑战主要在于如何提升通信效率，以及怎样适配最佳的网络硬件连接拓扑结构。
|| Broadcast 广播
Broadcast是一种1对多的通信原语，即存在一个数据发送者和多个数据接收者。在集群环境中，该原语可将一个节点自身的数据广播至其他节点。如示意图所示，以集群中的训练加速卡节点为例，用圈圈表示节点，相同颜色的小方块代表相同的数据。当主节点0执行Broadcast操作时，数据便会从主节点0传播至其他节点。
在分布式机器学习的实际应用场景中，网络参数的初始化是一个关键环节，而广播操作在其中扮演着重要角色。如图所示，在数据传输过程里，单个sender（发送端）承担着数据发送的任务，它将存储于0卡上、尺寸规格为1xN的Tensor（张量）数据，以广播的形式传递至其他各个节点。经过这一广播过程，最终，每个节点所对应的计算卡均会输出一个尺寸为[1xN]的矩阵数据，实现了数据在各节点间的同步与共享，为后续的分布式计算提供了统一的参数基础 。
|| Scatter 发散
Scatter同样属于1对多的通信原语，有一个数据发送者和多个数据接收者，可在集群内将一个节点自身的数据发散到其他节点上。与Broadcast不同的是，Broadcast是将主节点0的数据完整发送给所有节点，而Scatter则是先将数据进行切片，再分发给集群内的所有节点。如示意图所示，不同颜色的小方块代表不同的数据，主节点0将数据分成四份分别发送到节点0-3。其反向操作是Gather。
Scatter的应用场景包括：
1. 在ReduceScatter组合操作中，承担其中的Scatter操作部分；
2. 在模型并行初始化时，将模型scatter到不同的GPU上。
|| Gather 收集
Gather操作是多对1的通信原语，具有多个数据发送者和一个数据接收者，能够在集群内将多个节点的数据收集到一个节点上。如示意图所示，不同颜色的小方块代表不同的数据。
Gather是数据的多对1收集，它将多张GPU卡上的数据集中收集到1张GPU卡上，其反向操作是Scatter。在ReduceScatter组合里的 Scatter操作中，Gather扮演着重要角色。这个机制对很多平行算法很有用，比如并行的排序和搜索。
|| All-Gather 全收集
All-Gather属于多对多的通信原语，存在多个数据发送者和多个数据接收者。在集群内，它先将多个节点的数据收集到一个主节点上（Gather操作），然后再把收集到的数据分发到其他节点上（broadcast操作），实现了将集群内所有数据收集到所有节点的功能。
All-Gather是数据的多对多同步全收集，可看作是Gather + Broadcast的操作组合，其反向操作是ReduceScatter。它在模型并行领域应用广泛，例如在模型并行的前向计算中，需要用allgather把模型并行里切分到不同GPU上的参数全同步到一张GPU上，以便进行前向计算。
|| Reduce 规约
|| Reduce-Scatter 规约发散
Reduce-Scatter属于多对多的通信原语，有多个数据发送者和多个数据接收者。在集群内，所有节点都按维度执行相同的Reduce规约运算，然后将结果发散到集群内的所有节点上。该操作等价于先进行节点个数次的reduce规约运算操作，再执行节点个数次的scatter操作，其反向操作是All-Gather。
其应用场景丰富，既适用于数据并行，也适用于模型并行，例如在数据并行allReduce里的 ReduceScatter+ Allgather组合中，承担其中的ReduceScatter操作部分；在模型并行里在前向allgather后的反向计算中，也会用到ReduceScatter操作。
如示意图所示，先对GPU 0-3的数据进行reduce操作，将其规约为 A(A1+A2+A3+A4) + B(B1 +B2 + B3+B4) + C(C1 + C2 + C3+C4) + D(D1 + D2 + D3+D4) 到一张GPU上，然后再进行分片scatter到集群内所有的XPU卡上。
|| All-Reduce 规约发散
All-Reduce属于多对多的通信原语，有多个数据发送者和多个数据接收者。在集群内，所有节点都执行相同的Reduce操作，能够将集群内所有节点的数据规约运算得到的结果发送到所有节点上。All-Reduce操作可以通过在主节点上执行Reduce+Broadcast或Reduce-Scatter + All-Gather来实现。如示意图所示，先在主节点上执行Reduce得到规约累加和26，然后再把这个累加和26 Broadcast到其他节点，这样整个集群内的每个节点的数值就都保持一致。
All-Reduce是数据的多对多规约运算，它将所有GPU卡上的数据规约（如SUM求和）到集群内的每张GPU卡上。在数据并行中应用广泛，例如在数据并行的各种通信拓扑结构，如Ring allReduce、Tree allReduce里的allReduce操作中，都发挥着关键作用。
|| All-To-All 全交换
All-To-All操作中，每一个节点的数据会Scatter到集群内所有节点上，同时每一个节点也会Gather集群内所有节点的数据。它是对All-Gather的扩展，二者的区别在于，在All-Gather操作中，不同节点向某一节点收集到的数据是相同的，而在All-To-All中，不同的节点向某一节点收集到的数据是不同的。
All-To-All是数据的多对多转置，它将所有GPU卡上的数据转置到所有的GPU卡上。在模型并行领域应用较多，例如在模型并行里的矩阵转置操作中，以及数据并行到模型并行的矩阵转置过程中，都有其用武之地。
