把模型摊到多张卡上的时候真正难住的往往不是怎么切这个数学问题而是切完之后每一次前向、每一次反向要发多少条消息、每条多大、走哪条链路、能不能被计算盖住。集合通信与模型并行这两件事在我看来越来越像是同一枚硬币的两面模型并行决定了切法而切法直接决定了通信模式集合通信原语的特性又反过来限制了你能切多狠。很多人第一次把单机多卡的数据并行脚本改成张量并行会发现 loss 曲线完全一致、代码也没报错但吞吐掉了一半——问题不在正确性在通信没算清楚。这篇内容想解决的就是这个断层。它适合已经跑过单机多卡、能看懂基本的分布式启动脚本但对All-Reduce 到底是几步张量并行一层要通信几次流水线的气泡怎么算这类问题只有模糊印象的人。我会从切分动机讲到原语原理再给可复现的通信量估算方法和真实的排障路径。文中涉及的具体框架接口用通用的dist命名空间代指各家实现的函数签名大同小异思路是通用的。1. 从单卡装不下倒推模型并行的三条切分路径1.1 显存账本的四个组成部分要先搞清楚模型并行在切什么得先把显存账本拆开。一张卡上的显存大致被四样东西占据参数、梯度、优化器状态、激活值。前三个是静态的规模跟参数量成正比激活值是动态的跟 batch size 和序列长度成正比。按混合精度训练算一笔账一个参数量为 P 的模型参数本身bf16占 2P 字节梯度bf16占 2P优化器如果用的是带动量与方差的一阶二阶状态且主权重保持 fp32那部分大约占 12P 到 16P。加起来静态开销就是 16P 到 20P 字节。一个 70B 的模型光静态部分就要 1.1 到 1.4 TB八张 80G 的卡加起来才 640G怎么都塞不下。这时候有三条路把参数本身切开张量并行、流水线并行把优化器和梯度切开分片式数据并行或者把激活值切开序列并行、上下文并行、激活重计算。模型并行特指前一类——它改变的是某一层由谁来算而不是哪些数据由谁来算。这个区分很关键。数据并行里每张卡都有完整的模型副本通信发生在梯度聚合阶段属于一次大批量同步模型并行里没有任何一张卡持有完整模型通信发生在层与层之间、甚至层内部属于高频小批量同步。后者对延迟更敏感这也是为什么模型并行对互联带宽的要求远高于数据并行。1.2 张量并行切的是层内流水线并行切的是层间张量并行的思路是把单个算子内部的矩阵乘法拆开。一个线性层的权重矩阵按列或按行切成若干块分给不同设备每张卡算出一部分结果再通过集合通信拼回完整输出。它的优点是单层内就能并行负载均衡好做没有空闲等待缺点是每层都要通信而且通信发生在关键路径上无法被计算完全掩盖。流水线并行的思路是沿网络深度切。前若干层放卡 0接着若干层放卡 1以此类推。数据像流水线一样从前往后流动卡 0 算完第一批数据把激活传给卡 1同时开始算第二批。它的优点是通信量极小——只在阶段边界传一次激活量级比张量并行低一到两个数量级缺点是有气泡即流水线填充和排空阶段部分卡在空转。实际的大规模训练基本是两者叠加再叠数据并行业界常见的组合是节点内张量并行 跨节点流水线并行 全局数据并行。为什么这么配因为张量并行的通信频率高必须放在高带宽的节点内互联上流水线并行的通信频率低跨节点也能接受。这个组合不是拍脑袋定的是被互联拓扑逼出来的。1.3 一个常被忽略的判断什么时候不该上模型并行单卡能放下、单机八卡能放下的时候优先选数据并行加分片优化器而不是模型并行。原因很直接数据并行的通信是每步一次全量梯度同步通信量与参数量成正比但频率低而且可以和反向传播重叠模型并行的通信在关键路径上改起来牵一发动全身调试成本高一个量级。我见过的典型误判是模型 13B八卡 80G明明用分片式数据并行就能跑却先上了张量并行结果每层四次全局同步把吞吐拖到不如数据并行。判断标准其实很简单——算一下你的模型静态开销除以卡数如果单卡余量还超过 30%就别碰模型并行。真正必须上模型并行的场景只有两类单卡装不下最小可训练单元哪怕 batch1、开了重计算或者单机装不下、必须跨机但仍希望保持较高的计算效率。2. 集合通信原语把 All-Reduce 拆开看才明白瓶颈在哪2.1 八种原语里真正高频使用的只有四种教科书上列出的集合通信原语一般有 Broadcast、Scatter、Gather、Reduce、All-Gather、Reduce-Scatter、All-Reduce、All-to-All 这么几种。但在分布式训练里高频出现的其实只有四个All-Reduce梯度同步、All-Gather参数或激活拼接、Reduce-Scatter分片归约、All-to-All专家路由、序列重排。理解它们的关系有个讨巧的办法All-Reduce 等于 Reduce-Scatter 加 All-Gather。也就是说先把数据切成 N 份每份在一个设备上完成归约Reduce-Scatter再把每份结果广播给所有设备All-Gather。这个分解不是概念游戏分片式数据并行正是利用了这个等价关系——它不需要完整的 All-Reduce只需要前半段把梯度归约到对应的持有者手里需要时再用后半段把参数拼回来。Broadcast、Scatter、Gather、Reduce 这几个单向原语在训练主路径上用得少但在初始化广播初始权重保证各卡一致、检查点保存Gather 到 rank 0 落盘这些环节绕不开。All-to-All 平时用不上一旦涉及专家混合模型或者需要做全局的 token 重排它就是绝对主角而且它的通信模式和其他几个完全不同——每个设备给其他每个设备发不同的数据是唯一一个人人对人人的全连接式通信。2.2 环形 All-Reduce 的两次扫描与 2(N-1)/N 这个系数以 N 个设备、待归约数据量 S 字节为例环形算法把数据切成 N 块每块 S/N。第一阶段 Reduce-Scatter 走 N-1 步。第 k 步时设备 i 把当前手上的某一块发给下游设备 i1同时接收上游设备 i-1 发来的块并累加。走完 N-1 步后设备 i 恰好持有第 i 块的完整归约结果所有设备的该块都累加过了。第二阶段 All-Gather 同样走 N-1 步把各自持有的那一块沿环传播一圈最终每个设备都拿到全部 N 块的完整结果。算一下总传输量每个阶段每个设备发出 (N-1) 份、每份 S/N两个阶段合计 2(N-1)S/N。当 N 增大时这个系数趋近于 2也就是说 8 卡和 512 卡的 All-Reduce每个设备承担的数据量几乎一样。这是环形算法最漂亮的地方——通信量对规模几乎不敏感。作为对比朴素做法是先全部 Reduce 到 0 号卡再 Broadcast 出去通信量是 2(N-1)S随 N 线性增长。8 卡时是 14S环形是 1.75S差 8 倍。所以环形以及它的变体能成为默认选择不是因为实现简单而是因为带宽复杂度最优。代价在延迟上。环形走 N-1 步意味着 N-1 次往返N 越大延迟越高。当消息很小时带宽项可以忽略延迟项主导这时树形算法N 的以 2 为底的对数量级步数反而更快。这就是为什么通信库会根据消息大小自动切换算法也是为什么小张量必须合并发送。2.3 用 alpha-beta 模型估一次通信要多久工程上估算集合通信时间用 alpha-beta 模型就够了T alpha S / B其中 alpha 是单次消息的固定延迟微秒级跨机比机内高一个数量级S 是消息字节数B 是有效带宽。代入环形 All-Reduce 的步数和步长T_allreduce ≈ 2(N-1) * alpha 2(N-1)/N * S / B这个式子能解释好几个现象。第一小消息场景下 T 几乎只跟 N 和 alpha 有关跟你传 1KB 还是 10KB 关系不大——所以反向传播里按层逐个 All-Reduce 是灾难必须攒成大桶。第二N 越大延迟项越重跨机场景下 alpha 本身就大所以跨机做高频小消息通信非常吃亏。第三带宽项里 S 是被 N 除过的所以提高 N 不会让带宽项变差只会让延迟项变差——大消息场景下加卡几乎不损失效率。举一组具体数字感受一下机内互联 alpha 约 5 微秒、有效带宽约 150 GB/s跨机 RDMA 的 alpha 约 20 到 50 微秒、有效带宽约 25 GB/s。同样是 8 卡、64 MiB 的消息机内耗时约 275us 1.7564MiB/150GB/s ≈ 70us 0.78ms ≈ 0.85ms跨机则是 2730us 1.7564MiB/25GB/s ≈ 420us 4.7ms ≈ 5.1ms。差了六倍。这个差距就是张量并行为什么不跨机的全部答案。2.4 通信量的三种表达方式别搞混新手最容易在三个数字上绕晕算法传输量、网络实际流量、应用层消息大小。算法传输量是上面算的 2(N-1)S/N指单个设备网卡上累计收发的字节数网络实际流量要考虑协议头、重传、多路径分摊通常比算法量高 5% 到 15%应用层消息大小就是你传进all_reduce的那个张量有多少字节。做容量规划时要看的是算法传输量乘以迭代次数做网络选型时要看的是峰值流量做代码优化时要盯的是应用层消息大小和消息个数。三个数字混着用估算就会偏出好几倍。3. 张量并行切矩阵的配对规则决定了通信次数3.1 列切与行切必须成对出现的原因一个线性层做的是 Y XW。列切是把 W 按列拆成 [W1, W2]每张卡持有完整输入 X各算 Y1 XW1、Y2 XW2输出在特征维上拼接。行切是把 W 按行拆成 [W1; W2]输入 X 也按列拆成 [X1, X2]各算 Y1 X1W1、Y2 X2W2两个部分结果需要相加才是最终 Y。区别就在最后一步列切之后输出是分片但完整的只是分在不同卡上行切之后输出是部分和需要归约。所以列切后面接 All-Gather如果需要完整输出行切后面接 All-Reduce。但如果一个列切紧跟着一个行切情况就变得很划算列切的输出分片恰好就是行切需要的输入分片中间的 All-Gather 可以完全省掉。这就是经典的列-行配对一个 Transformer 层里的两层 MLP先升维再降维正好是这个结构attention 里的 QKV 投影加输出投影也是这个结构。配对之后每对线性层只需要在行切之后做一次 All-Reduce。这个设计不是巧合是专门为减少通信次数设计的。如果两个都按列切中间要插一次 All-Gather如果两个都按行切中间要插一次 All-Reduce 而且输出还是部分和。只有列跟行配对中间零通信。3.2 一个 Transformer 层前向要发几次 All-Reduce按标准的切法一个 Transformer 层self-attention 加 MLP在张量并行下的前向通信是两次 All-Reduce一次在 attention 的输出投影之后一次在 MLP 的第二个线性层之后。反向传播是对称的每个 All-Reduce 的梯度回传还需要一次对应的 All-Reduce所以反向也是两次。合起来每层每个训练步是四次 All-Reduce。每层的通信量是batch × seq_len × hidden × dtype_bytes乘以四。注意这里用的是全局 batch 和全局序列长度不是除以 TP 之后的。这一点非常关键——张量并行让每张卡的计算量降到 1/TP但通信量保持不变。结果是计算通信比随 TP 增大而线性恶化。TP 从 1 加到 2单卡计算量减半、通信量翻倍因为多了一次跨卡同步比值降到四分之一从 4 加到 8同样的规律再来一遍。这就解释了为什么张量并行超过 8 之后效率曲线会明显下折除非你的互联带宽也跟着涨。3.3 一组具体的通信量算例设定全局 batch 4序列长度 2048hidden 4096bf16 精度2 字节TP 8模型 100 层。单次 All-Reduce 的数据量S 4 × 2048 × 4096 × 2 67,108,864 字节 64 MiB按环形算法单卡实际传输量2 × (8-1)/8 × 64 MiB 112 MiB每层四次单层单卡 448 MiB。100 层就是约 43.75 GiB约合 47 GB。按机内 150 GB/s 有效带宽算单步通信约 0.31 秒。如果同样的事情放在跨机 25 GB/s 的链路上就是 1.9 秒——而这一层的计算时间可能才零点几秒通信直接成为绝对瓶颈。这个算例还有一层意思如果把 batch 从 4 降到 1通信量降到四分之一但计算量也降到四分之一比例不变。所以调小 batch 救不了张量并行的效率只有换更快的互联或者减少 TP 才行。3.4 序列并行补上了张量并行的一个漏洞标准张量并行有个浪费LayerNorm、Dropout、残差相加这些逐元素操作的输入在每张卡上是完全重复的。也就是说本来只要存一份的激活被 TP 倍地冗余存了。序列并行的做法是在这些逐元素操作处把激活按序列维切开每张卡只处理自己那段序列到需要完整 hidden 维的线性层之前再用 All-Gather 拼回来、算完再用 Reduce-Scatter 切回去。通信量上All-Gather 加 Reduce-Scatter 的组合与一次 All-Reduce 大致相当也就是说通信成本没有实质增加但激活显存降下来了。这笔买卖在长序列场景下非常划算——序列长度 8K 以上时激活显存往往是压死骆驼的最后一根稻草。实现在工程上需要注意切分点的插入位置切早了会多出无谓的拼装切晚了省不下显存。4. 流水线并行气泡公式背后的取舍4.1 全前向全后向的气泡与显存双重代价最朴素的流水线调度是把一个 batch 切成 m 个微批先让所有微批依次走完整个前向再依次走完整个反向。这就是所谓的全前向全后向方案。它的时间开销很好算流水线深度为 p微批数为 m每个微批在前向或反向占一个时间槽。总槽数是 m p - 1其中真正满载的槽只有 m 个剩下 p - 1 个是填充和排空也就是气泡。气泡占比bubble_ratio (p - 1) / (m p - 1)p 8、m 16 时是 7/23 ≈ 30%三成的算力在空转。要压到 10% 以下m 得提到 64 左右7/71 ≈ 10%。但真正致命的是显存。全前向全后向要求所有 m 个微批的激活同时驻留因为反向传播要等全部前向做完才开始。这意味着流水线并行省下来的参数显存被 m 倍的激活显存吃回去了。m 想开大压气泡激活就爆m 开小省显存气泡就大。这个矛盾在用这个方案的时候几乎无解。4.2 一前一后交替调度把峰值激活压到常数级改进方案的核心思想是把反向提前。具体做法是先做 p-1 个微批的前向把流水线灌满warmup进入稳态后每做一次前向就紧接着做一次最早那个微批的反向一前一后交替最后把剩余的微批反向排空cooldown。这样做的好处是稳态阶段每个流水级上同时在飞的微批数量被限制在 p 附近而不是全部 m 个。峰值激活显存从 O(m) 降到大约 O(p)m 就可以放心开大气泡自然被压薄。代价是调度复杂度和通信模式的改变。一前一后交替意味着前向和反向的通信交织在一起如果通信和计算的重叠没做好反而可能比全前向全后向更慢。另外反向提前意味着某些参数在被使用前就已经算过梯度需要注意梯度累积的顺序正确性实现上要维护好每个微批的状态机。4.3 交错式调度的气泡公式与它的隐性成本再进一步的优化是把每个设备负责的连续层块再拆成 v 个小块让一个设备负责多个不连续的层块。这样相当于把流水线深度虚拟地扩大了 v 倍气泡占比变成bubble_ratio (p - 1) / (m × v p - 1)p 8、m 32、v 2 时是 7/71 ≈ 10%同样的 m 下气泡减半。看着很美。但隐性成本在两处。第一通信次数增加 v 倍——设备之间要来回跳每个小块边界都要传一次激活。虽然单次数据量不变但消息个数翻倍延迟项跟着翻倍在网络延迟高的跨机场景下这个代价不小。第二调度状态机复杂度再上一个台阶每块的微批编号、前向反向的依赖关系都要单独维护调试难度显著上升。我的经验是v 2 在机内互联上收益明确值得上v 再往上加收益递减而调试成本陡增除非你用的是专门的成熟调度框架否则不建议手写。4.4 微批数量怎么定三个约束取交集微批数 m 的选择同时受三个约束。第一是气泡约束上面那个公式决定了 m 至少要多大才能把气泡压到可接受范围。通常目标是气泡占比低于 15%反推 m ≥ (p-1)/0.15 - p 1。第二是显存约束m 越大同时在飞的微批越多激活显存越高。虽然一前一后调度把峰值压到 O(p)但 warmup 阶段还是要同时持有 p-1 个微批的激活这部分省不掉。第三是整除约束一个全局 batch 要能被 m 和流水线级数整除而且切出来的微批大小要能填满计算单元太小了算子效率会掉。三个约束一取交集可选的 m 往往只有两三个值。实践中的典型配置是 p 8、m 32 或 64气泡占比落在 10% 到 20% 之间同时把全局 batch 定在 128 到 512 的量级。5. 让通信藏进计算里重叠、分桶与通信域5.1 梯度分桶是最容易拿到的免费收益反向传播有个天然的有利性质梯度是从后往前逐层算出来的算完一层的梯度其实就可以开始同步了不必等全部算完。但要真正利用这一点必须解决消息太小的问题——单层梯度可能只有几十 KB按 alpha-beta 模型这时候延迟项占绝对主导逐层同步的效率极低。解决方案是分桶把梯度按固定大小常见是 25 MB 到 100 MB 之间装进若干个桶一个桶填满了就立刻发起 All-Reduce同时反向传播继续算下一层往下一个桶里填。这样既保证了消息足够大带宽利用率高又实现了通信与计算的重叠。分桶顺序有讲究。因为反向是逆序的最先算完的是最后几层所以桶的填充顺序应该和反向顺序对齐。如果装桶逻辑和反向顺序不一致会出现桶等着后面某层的梯度才能发的情况重叠窗口被白白浪费掉。分桶大小也不能一味求大。桶太大第一个桶要等很久才能填满开头那段通信完全无法重叠桶太小消息碎延迟开销上来了。25 MB 是个常见的经验甜点具体还要看你的互联带宽——带宽越高最优桶越小。5.2 通信域分组把全局同步拆成互不干扰的子集分布式训练里最常见的并行组合是张量并行组 数据并行组嵌套。一个 8 卡张量并行、8 组数据并行的配置总共 64 张卡但全局 All-Reduce 是绝对不该出现的。正确的做法是建两个正交的通信域张量并行组只包含同一份模型副本内的 8 张卡数据并行组包含跨副本的 8 张卡每张卡对应一个位置。张量并行的 All-Reduce 只在组内做数据并行的梯度同步也只在组内做两个组互不干扰。这么设计的原因是通信量差异巨大。张量并行的通信每层四次、频率极高必须限制在高带宽的机内范围数据并行的通信每步一次、量级相同但频率低得多跨机也能承受。如果用一个全局通信域所有通信都会扩散到最大范围性能会塌方式下降。建组的时候有个细节容易错dist.new_group(ranks)这个调用本身是集合通信操作所有进程必须以相同的顺序、相同的方式调用它否则会挂死。常见写法是先算好各个维度的分组划分再在一个循环里按固定顺序把所有组都建出来保证每个 rank 都执行了相同的调用序列。# 分组构建必须所有 rank 顺序一致 tp_groups, dp_groups [], [] for i in range(dp_size): for j in range(tp_size): ranks [i * tp_size j] # 具体切分逻辑按你的拓扑调整 # 每个 rank 都要参与所有 group 的创建调用 g dist.new_group(ranks) if rank in ranks: tp_groups.append(g)上面这段是示意实际切分索引要按你的 rank 排布来算。核心是那个每个 rank 都参与创建的原则。5.3 拓扑感知跨机带宽才是真正的天花板所有通信量估算最后都要落到一条物理链路上。同一台机器内的卡通过高带宽互联直连带宽是跨机链路的五到十倍延迟低一个数量级。所以任何高频通信都必须收敛在机内。判断自己的配置是否踩线看两个数张量并行组是不是跨机了数据并行组的通信量占单步时间的比例是多少前者一旦跨机基本可以判定性能不可接受后者如果超过 30%说明通信没被计算盖住要么加大计算密度提高 batch 或序列长度要么减少通信频率。还有一个容易漏的点是网卡和卡的亲和性。多网卡机器上每张卡应该优先走物理上最近的那张网卡。如果进程没有正确绑定可能出现卡 0 的数据绕到卡 7 那边的网卡出去多绕一跳交换机带宽减半。这类问题不会报错只会让吞吐莫名其妙地低排查起来特别费时间。6. 真机排障卡死在集合通信上的那几个小时6.1 无报错挂起先查集合通信的调用顺序分布式训练最让人抓狂的症状是所有 rank 都停住、CPU 占用为零、没有任何报错连超时都要等很久才触发。绝大多数情况下根因是各 rank 的集合通信调用序列不一致。比如某个分支只在 rank 0 上执行或者在某个 rank 上提前continue跳过了一次 All-Reduce其他 rank 就会永远等在那里。集合通信是强同步的一个都不能少。排查路径是这样走的第一步看日志最后一条打印在哪个位置确认挂在了前向、反向还是优化器更新阶段。第二步在可疑区域把每个集合通信调用前后都打上带 rank 号的日志跑一次看哪个 rank 少了一条。第三步检查所有条件分支凡是可能跳过的路径要么改成所有 rank 都执行、用 mask 控制数据要么改成非集合通信的本地操作。还有一类隐蔽的情况某些 rank 用了不同的通信域。组 A 的成员在组 A 上做 All-Reduce另一个 rank 却在全局组上做两边永远对不上。这类问题在有嵌套并行、动态建组的代码里特别容易出。另一类会导致挂起的硬件层原因是共享内存段不够。数据加载的多进程和某些通信后端会用到共享内存容器环境里默认的共享内存往往只有 64 MB跑起来没多久就卡死。这个坑我踩过不止一次特征是一开始能跑、跑一会就挂而且挂的位置随机。把共享内存挂载调大就能解决。6.2 吞吐只有预期一半从拓扑和网卡查起不报错、能跑完、但速度明显不对这类问题比挂起更难查因为你没有明确的错误信息。我的排查顺序是固定的先确认实际走的是哪条链路再确认每张卡的实际收发速率最后才怀疑算法。确认链路可以看通信库的初始化日志里面会打印检测到的互联类型机内高带宽互联还是走网络以及用了哪些网卡。如果发现本该走机内高速链路的通信走了网络那配置肯定有问题常见原因是可见设备的环境变量设置不一致导致各进程看到的卡编号错位。确认收发速率可以在训练跑起来之后抓一下网卡的实时流量。如果流量远低于链路容量说明要么消息太小没打满带宽要么重叠没做好导致通信和计算串行。前者调大分桶后者检查分桶逻辑。算法层面的怀疑放在最后。因为集合通信的算法选择通常是库自动做的手动指定反而容易选错——大消息选了低带宽算法或者小消息选了高延迟算法两种情况都会让性能显著下降但表现不同前者是带宽跑不满后者是延迟占比异常高。6.3 症状与方向的对照表症状大概率方向优先验证手段全 rank 静止、无报错、CPU 空闲集合通信调用序列不一致 / 通信域不匹配在每次集合通信前后打 rank 日志比对调用次数跑一段时间后随机挂死共享内存不足 / 文件句柄耗尽 / 内存泄漏检查共享内存挂载大小观察常驻内存曲线能跑完但吞吐只有一半通信未被重叠 / 拓扑走错 / 消息过碎抓网卡实时流量对照估算值加卡后单卡吞吐反降通信域跨了慢链路 / 计算通信比恶化确认张量并行组是否跨机只有部分 rank 慢进程与设备的亲和性绑定错误检查 NUMA 与网卡绑定关系首步极慢、后续正常通信库初始化与拓扑探测开销属正常现象可用缓存缩短不必深究这张表不是穷举但覆盖了实际碰到的大多数场景。有个通用原则值得记住分布式问题的定位成本主要在信息收集不在修复。所以花时间把日志打全、把监控指标铺开比事后猜要划算得多。7. 几个我在选型和调参上的实际体会第一先把单机跑满再考虑跨机。我见过太多在跨机配置上反复调优、最后发现是单机内部的通信域都没建对的例子。单机八卡的吞吐基线如果没打准后面所有的优化都失去了参照物。第二估算表要在动手前就写好。不用很复杂一张纸列清楚参数量、hidden、层数、batch、序列长度、计划用几路张量并行几路流水线并行然后按第三节的方法把每层通信量和单步总通信量算出来再对照你的互联带宽估一个通信时间。这个数字如果已经超过你预期的单步时间说明方案选错了改结构比改代码便宜。第三气泡和显存是一对反向指标任何声称两个都优化了的方案要么是换了硬件要么是藏了别的代价。看到气泡占比降下来第一反应应该是去查激活显存或者通信次数有没有涨。第四别迷信大 TP。张量并行的效率曲线在超过单机卡数之后会陡降这不是实现问题是计算通信比的数学规律。真要往上堆规模走流水线并行或者数据并行加分片把高频通信留在机内。第五超时时间要主动调。默认的超时对大规模训练来说往往太短一次正常的检查点保存就可能超时触发重启。但反过来把超时设得极长也有问题——真挂了你要等很久才发现。折中的做法是把超时设成正常单步时间的几十倍并且打开心跳监控让异常通过监控暴露而不是靠超时报错。第六保留一份通信量基线脚本。我通常会在代码里留一个函数输入并行配置就输出理论通信量每次改并行策略先跑一遍。这东西看着简陋但能在改配置之前就判断出这条路走不通省下的调试时间远超写它的成本。def estimate_tp_comm(batch, seq_len, hidden, dtype_bytes, tp_size, n_layers, steps1): 估算张量并行下每卡每步的 All-Reduce 传输量字节 s batch * seq_len * hidden * dtype_bytes per_ar 2 * (tp_size - 1) / tp_size * s # 环形算法单卡传输量 return per_ar * 4 * n_layers * steps # 每层前后向各两次 # 示例batch4, seq2048, hidden4096, bf16, TP8, 100 层 print(estimate_tp_comm(4, 2048, 4096, 2, 8, 100) / 1024**3, GiB)跑出来的结果和第三节手工算的一致约 43.75 GiB。把它和你的互联带宽一除就知道理论通信下限是多少。剩下的工作就是让实际耗时尽量逼近这个下限而不是想方设法绕开它——通信量是结构决定的绕不开只能藏。
把模型摊到多张卡上的时候真正难住的往往不是怎么切这个数学问题而是切完之后每一次前向、每一次反向要发多少条消息、每条多大、走哪条链路、能不能被计算盖住。集合通信与模型并行这两件事在我看来越来越像是同一枚硬币的两面模型并行决定了切法而切法直接决定了通信模式集合通信原语的特性又反过来限制了你能切多狠。很多人第一次把单机多卡的数据并行脚本改成张量并行会发现 loss 曲线完全一致、代码也没报错但吞吐掉了一半——问题不在正确性在通信没算清楚。这篇内容想解决的就是这个断层。它适合已经跑过单机多卡、能看懂基本的分布式启动脚本但对All-Reduce 到底是几步张量并行一层要通信几次流水线的气泡怎么算这类问题只有模糊印象的人。我会从切分动机讲到原语原理再给可复现的通信量估算方法和真实的排障路径。文中涉及的具体框架接口用通用的dist命名空间代指各家实现的函数签名大同小异思路是通用的。1. 从单卡装不下倒推模型并行的三条切分路径1.1 显存账本的四个组成部分要先搞清楚模型并行在切什么得先把显存账本拆开。一张卡上的显存大致被四样东西占据参数、梯度、优化器状态、激活值。前三个是静态的规模跟参数量成正比激活值是动态的跟 batch size 和序列长度成正比。按混合精度训练算一笔账一个参数量为 P 的模型参数本身bf16占 2P 字节梯度bf16占 2P优化器如果用的是带动量与方差的一阶二阶状态且主权重保持 fp32那部分大约占 12P 到 16P。加起来静态开销就是 16P 到 20P 字节。一个 70B 的模型光静态部分就要 1.1 到 1.4 TB八张 80G 的卡加起来才 640G怎么都塞不下。这时候有三条路把参数本身切开张量并行、流水线并行把优化器和梯度切开分片式数据并行或者把激活值切开序列并行、上下文并行、激活重计算。模型并行特指前一类——它改变的是某一层由谁来算而不是哪些数据由谁来算。这个区分很关键。数据并行里每张卡都有完整的模型副本通信发生在梯度聚合阶段属于一次大批量同步模型并行里没有任何一张卡持有完整模型通信发生在层与层之间、甚至层内部属于高频小批量同步。后者对延迟更敏感这也是为什么模型并行对互联带宽的要求远高于数据并行。1.2 张量并行切的是层内流水线并行切的是层间张量并行的思路是把单个算子内部的矩阵乘法拆开。一个线性层的权重矩阵按列或按行切成若干块分给不同设备每张卡算出一部分结果再通过集合通信拼回完整输出。它的优点是单层内就能并行负载均衡好做没有空闲等待缺点是每层都要通信而且通信发生在关键路径上无法被计算完全掩盖。流水线并行的思路是沿网络深度切。前若干层放卡 0接着若干层放卡 1以此类推。数据像流水线一样从前往后流动卡 0 算完第一批数据把激活传给卡 1同时开始算第二批。它的优点是通信量极小——只在阶段边界传一次激活量级比张量并行低一到两个数量级缺点是有气泡即流水线填充和排空阶段部分卡在空转。实际的大规模训练基本是两者叠加再叠数据并行业界常见的组合是节点内张量并行 跨节点流水线并行 全局数据并行。为什么这么配因为张量并行的通信频率高必须放在高带宽的节点内互联上流水线并行的通信频率低跨节点也能接受。这个组合不是拍脑袋定的是被互联拓扑逼出来的。1.3 一个常被忽略的判断什么时候不该上模型并行单卡能放下、单机八卡能放下的时候优先选数据并行加分片优化器而不是模型并行。原因很直接数据并行的通信是每步一次全量梯度同步通信量与参数量成正比但频率低而且可以和反向传播重叠模型并行的通信在关键路径上改起来牵一发动全身调试成本高一个量级。我见过的典型误判是模型 13B八卡 80G明明用分片式数据并行就能跑却先上了张量并行结果每层四次全局同步把吞吐拖到不如数据并行。判断标准其实很简单——算一下你的模型静态开销除以卡数如果单卡余量还超过 30%就别碰模型并行。真正必须上模型并行的场景只有两类单卡装不下最小可训练单元哪怕 batch1、开了重计算或者单机装不下、必须跨机但仍希望保持较高的计算效率。2. 集合通信原语把 All-Reduce 拆开看才明白瓶颈在哪2.1 八种原语里真正高频使用的只有四种教科书上列出的集合通信原语一般有 Broadcast、Scatter、Gather、Reduce、All-Gather、Reduce-Scatter、All-Reduce、All-to-All 这么几种。但在分布式训练里高频出现的其实只有四个All-Reduce梯度同步、All-Gather参数或激活拼接、Reduce-Scatter分片归约、All-to-All专家路由、序列重排。理解它们的关系有个讨巧的办法All-Reduce 等于 Reduce-Scatter 加 All-Gather。也就是说先把数据切成 N 份每份在一个设备上完成归约Reduce-Scatter再把每份结果广播给所有设备All-Gather。这个分解不是概念游戏分片式数据并行正是利用了这个等价关系——它不需要完整的 All-Reduce只需要前半段把梯度归约到对应的持有者手里需要时再用后半段把参数拼回来。Broadcast、Scatter、Gather、Reduce 这几个单向原语在训练主路径上用得少但在初始化广播初始权重保证各卡一致、检查点保存Gather 到 rank 0 落盘这些环节绕不开。All-to-All 平时用不上一旦涉及专家混合模型或者需要做全局的 token 重排它就是绝对主角而且它的通信模式和其他几个完全不同——每个设备给其他每个设备发不同的数据是唯一一个人人对人人的全连接式通信。2.2 环形 All-Reduce 的两次扫描与 2(N-1)/N 这个系数以 N 个设备、待归约数据量 S 字节为例环形算法把数据切成 N 块每块 S/N。第一阶段 Reduce-Scatter 走 N-1 步。第 k 步时设备 i 把当前手上的某一块发给下游设备 i1同时接收上游设备 i-1 发来的块并累加。走完 N-1 步后设备 i 恰好持有第 i 块的完整归约结果所有设备的该块都累加过了。第二阶段 All-Gather 同样走 N-1 步把各自持有的那一块沿环传播一圈最终每个设备都拿到全部 N 块的完整结果。算一下总传输量每个阶段每个设备发出 (N-1) 份、每份 S/N两个阶段合计 2(N-1)S/N。当 N 增大时这个系数趋近于 2也就是说 8 卡和 512 卡的 All-Reduce每个设备承担的数据量几乎一样。这是环形算法最漂亮的地方——通信量对规模几乎不敏感。作为对比朴素做法是先全部 Reduce 到 0 号卡再 Broadcast 出去通信量是 2(N-1)S随 N 线性增长。8 卡时是 14S环形是 1.75S差 8 倍。所以环形以及它的变体能成为默认选择不是因为实现简单而是因为带宽复杂度最优。代价在延迟上。环形走 N-1 步意味着 N-1 次往返N 越大延迟越高。当消息很小时带宽项可以忽略延迟项主导这时树形算法N 的以 2 为底的对数量级步数反而更快。这就是为什么通信库会根据消息大小自动切换算法也是为什么小张量必须合并发送。2.3 用 alpha-beta 模型估一次通信要多久工程上估算集合通信时间用 alpha-beta 模型就够了T alpha S / B其中 alpha 是单次消息的固定延迟微秒级跨机比机内高一个数量级S 是消息字节数B 是有效带宽。代入环形 All-Reduce 的步数和步长T_allreduce ≈ 2(N-1) * alpha 2(N-1)/N * S / B这个式子能解释好几个现象。第一小消息场景下 T 几乎只跟 N 和 alpha 有关跟你传 1KB 还是 10KB 关系不大——所以反向传播里按层逐个 All-Reduce 是灾难必须攒成大桶。第二N 越大延迟项越重跨机场景下 alpha 本身就大所以跨机做高频小消息通信非常吃亏。第三带宽项里 S 是被 N 除过的所以提高 N 不会让带宽项变差只会让延迟项变差——大消息场景下加卡几乎不损失效率。举一组具体数字感受一下机内互联 alpha 约 5 微秒、有效带宽约 150 GB/s跨机 RDMA 的 alpha 约 20 到 50 微秒、有效带宽约 25 GB/s。同样是 8 卡、64 MiB 的消息机内耗时约 275us 1.7564MiB/150GB/s ≈ 70us 0.78ms ≈ 0.85ms跨机则是 2730us 1.7564MiB/25GB/s ≈ 420us 4.7ms ≈ 5.1ms。差了六倍。这个差距就是张量并行为什么不跨机的全部答案。2.4 通信量的三种表达方式别搞混新手最容易在三个数字上绕晕算法传输量、网络实际流量、应用层消息大小。算法传输量是上面算的 2(N-1)S/N指单个设备网卡上累计收发的字节数网络实际流量要考虑协议头、重传、多路径分摊通常比算法量高 5% 到 15%应用层消息大小就是你传进all_reduce的那个张量有多少字节。做容量规划时要看的是算法传输量乘以迭代次数做网络选型时要看的是峰值流量做代码优化时要盯的是应用层消息大小和消息个数。三个数字混着用估算就会偏出好几倍。3. 张量并行切矩阵的配对规则决定了通信次数3.1 列切与行切必须成对出现的原因一个线性层做的是 Y XW。列切是把 W 按列拆成 [W1, W2]每张卡持有完整输入 X各算 Y1 XW1、Y2 XW2输出在特征维上拼接。行切是把 W 按行拆成 [W1; W2]输入 X 也按列拆成 [X1, X2]各算 Y1 X1W1、Y2 X2W2两个部分结果需要相加才是最终 Y。区别就在最后一步列切之后输出是分片但完整的只是分在不同卡上行切之后输出是部分和需要归约。所以列切后面接 All-Gather如果需要完整输出行切后面接 All-Reduce。但如果一个列切紧跟着一个行切情况就变得很划算列切的输出分片恰好就是行切需要的输入分片中间的 All-Gather 可以完全省掉。这就是经典的列-行配对一个 Transformer 层里的两层 MLP先升维再降维正好是这个结构attention 里的 QKV 投影加输出投影也是这个结构。配对之后每对线性层只需要在行切之后做一次 All-Reduce。这个设计不是巧合是专门为减少通信次数设计的。如果两个都按列切中间要插一次 All-Gather如果两个都按行切中间要插一次 All-Reduce 而且输出还是部分和。只有列跟行配对中间零通信。3.2 一个 Transformer 层前向要发几次 All-Reduce按标准的切法一个 Transformer 层self-attention 加 MLP在张量并行下的前向通信是两次 All-Reduce一次在 attention 的输出投影之后一次在 MLP 的第二个线性层之后。反向传播是对称的每个 All-Reduce 的梯度回传还需要一次对应的 All-Reduce所以反向也是两次。合起来每层每个训练步是四次 All-Reduce。每层的通信量是batch × seq_len × hidden × dtype_bytes乘以四。注意这里用的是全局 batch 和全局序列长度不是除以 TP 之后的。这一点非常关键——张量并行让每张卡的计算量降到 1/TP但通信量保持不变。结果是计算通信比随 TP 增大而线性恶化。TP 从 1 加到 2单卡计算量减半、通信量翻倍因为多了一次跨卡同步比值降到四分之一从 4 加到 8同样的规律再来一遍。这就解释了为什么张量并行超过 8 之后效率曲线会明显下折除非你的互联带宽也跟着涨。3.3 一组具体的通信量算例设定全局 batch 4序列长度 2048hidden 4096bf16 精度2 字节TP 8模型 100 层。单次 All-Reduce 的数据量S 4 × 2048 × 4096 × 2 67,108,864 字节 64 MiB按环形算法单卡实际传输量2 × (8-1)/8 × 64 MiB 112 MiB每层四次单层单卡 448 MiB。100 层就是约 43.75 GiB约合 47 GB。按机内 150 GB/s 有效带宽算单步通信约 0.31 秒。如果同样的事情放在跨机 25 GB/s 的链路上就是 1.9 秒——而这一层的计算时间可能才零点几秒通信直接成为绝对瓶颈。这个算例还有一层意思如果把 batch 从 4 降到 1通信量降到四分之一但计算量也降到四分之一比例不变。所以调小 batch 救不了张量并行的效率只有换更快的互联或者减少 TP 才行。3.4 序列并行补上了张量并行的一个漏洞标准张量并行有个浪费LayerNorm、Dropout、残差相加这些逐元素操作的输入在每张卡上是完全重复的。也就是说本来只要存一份的激活被 TP 倍地冗余存了。序列并行的做法是在这些逐元素操作处把激活按序列维切开每张卡只处理自己那段序列到需要完整 hidden 维的线性层之前再用 All-Gather 拼回来、算完再用 Reduce-Scatter 切回去。通信量上All-Gather 加 Reduce-Scatter 的组合与一次 All-Reduce 大致相当也就是说通信成本没有实质增加但激活显存降下来了。这笔买卖在长序列场景下非常划算——序列长度 8K 以上时激活显存往往是压死骆驼的最后一根稻草。实现在工程上需要注意切分点的插入位置切早了会多出无谓的拼装切晚了省不下显存。4. 流水线并行气泡公式背后的取舍4.1 全前向全后向的气泡与显存双重代价最朴素的流水线调度是把一个 batch 切成 m 个微批先让所有微批依次走完整个前向再依次走完整个反向。这就是所谓的全前向全后向方案。它的时间开销很好算流水线深度为 p微批数为 m每个微批在前向或反向占一个时间槽。总槽数是 m p - 1其中真正满载的槽只有 m 个剩下 p - 1 个是填充和排空也就是气泡。气泡占比bubble_ratio (p - 1) / (m p - 1)p 8、m 16 时是 7/23 ≈ 30%三成的算力在空转。要压到 10% 以下m 得提到 64 左右7/71 ≈ 10%。但真正致命的是显存。全前向全后向要求所有 m 个微批的激活同时驻留因为反向传播要等全部前向做完才开始。这意味着流水线并行省下来的参数显存被 m 倍的激活显存吃回去了。m 想开大压气泡激活就爆m 开小省显存气泡就大。这个矛盾在用这个方案的时候几乎无解。4.2 一前一后交替调度把峰值激活压到常数级改进方案的核心思想是把反向提前。具体做法是先做 p-1 个微批的前向把流水线灌满warmup进入稳态后每做一次前向就紧接着做一次最早那个微批的反向一前一后交替最后把剩余的微批反向排空cooldown。这样做的好处是稳态阶段每个流水级上同时在飞的微批数量被限制在 p 附近而不是全部 m 个。峰值激活显存从 O(m) 降到大约 O(p)m 就可以放心开大气泡自然被压薄。代价是调度复杂度和通信模式的改变。一前一后交替意味着前向和反向的通信交织在一起如果通信和计算的重叠没做好反而可能比全前向全后向更慢。另外反向提前意味着某些参数在被使用前就已经算过梯度需要注意梯度累积的顺序正确性实现上要维护好每个微批的状态机。4.3 交错式调度的气泡公式与它的隐性成本再进一步的优化是把每个设备负责的连续层块再拆成 v 个小块让一个设备负责多个不连续的层块。这样相当于把流水线深度虚拟地扩大了 v 倍气泡占比变成bubble_ratio (p - 1) / (m × v p - 1)p 8、m 32、v 2 时是 7/71 ≈ 10%同样的 m 下气泡减半。看着很美。但隐性成本在两处。第一通信次数增加 v 倍——设备之间要来回跳每个小块边界都要传一次激活。虽然单次数据量不变但消息个数翻倍延迟项跟着翻倍在网络延迟高的跨机场景下这个代价不小。第二调度状态机复杂度再上一个台阶每块的微批编号、前向反向的依赖关系都要单独维护调试难度显著上升。我的经验是v 2 在机内互联上收益明确值得上v 再往上加收益递减而调试成本陡增除非你用的是专门的成熟调度框架否则不建议手写。4.4 微批数量怎么定三个约束取交集微批数 m 的选择同时受三个约束。第一是气泡约束上面那个公式决定了 m 至少要多大才能把气泡压到可接受范围。通常目标是气泡占比低于 15%反推 m ≥ (p-1)/0.15 - p 1。第二是显存约束m 越大同时在飞的微批越多激活显存越高。虽然一前一后调度把峰值压到 O(p)但 warmup 阶段还是要同时持有 p-1 个微批的激活这部分省不掉。第三是整除约束一个全局 batch 要能被 m 和流水线级数整除而且切出来的微批大小要能填满计算单元太小了算子效率会掉。三个约束一取交集可选的 m 往往只有两三个值。实践中的典型配置是 p 8、m 32 或 64气泡占比落在 10% 到 20% 之间同时把全局 batch 定在 128 到 512 的量级。5. 让通信藏进计算里重叠、分桶与通信域5.1 梯度分桶是最容易拿到的免费收益反向传播有个天然的有利性质梯度是从后往前逐层算出来的算完一层的梯度其实就可以开始同步了不必等全部算完。但要真正利用这一点必须解决消息太小的问题——单层梯度可能只有几十 KB按 alpha-beta 模型这时候延迟项占绝对主导逐层同步的效率极低。解决方案是分桶把梯度按固定大小常见是 25 MB 到 100 MB 之间装进若干个桶一个桶填满了就立刻发起 All-Reduce同时反向传播继续算下一层往下一个桶里填。这样既保证了消息足够大带宽利用率高又实现了通信与计算的重叠。分桶顺序有讲究。因为反向是逆序的最先算完的是最后几层所以桶的填充顺序应该和反向顺序对齐。如果装桶逻辑和反向顺序不一致会出现桶等着后面某层的梯度才能发的情况重叠窗口被白白浪费掉。分桶大小也不能一味求大。桶太大第一个桶要等很久才能填满开头那段通信完全无法重叠桶太小消息碎延迟开销上来了。25 MB 是个常见的经验甜点具体还要看你的互联带宽——带宽越高最优桶越小。5.2 通信域分组把全局同步拆成互不干扰的子集分布式训练里最常见的并行组合是张量并行组 数据并行组嵌套。一个 8 卡张量并行、8 组数据并行的配置总共 64 张卡但全局 All-Reduce 是绝对不该出现的。正确的做法是建两个正交的通信域张量并行组只包含同一份模型副本内的 8 张卡数据并行组包含跨副本的 8 张卡每张卡对应一个位置。张量并行的 All-Reduce 只在组内做数据并行的梯度同步也只在组内做两个组互不干扰。这么设计的原因是通信量差异巨大。张量并行的通信每层四次、频率极高必须限制在高带宽的机内范围数据并行的通信每步一次、量级相同但频率低得多跨机也能承受。如果用一个全局通信域所有通信都会扩散到最大范围性能会塌方式下降。建组的时候有个细节容易错dist.new_group(ranks)这个调用本身是集合通信操作所有进程必须以相同的顺序、相同的方式调用它否则会挂死。常见写法是先算好各个维度的分组划分再在一个循环里按固定顺序把所有组都建出来保证每个 rank 都执行了相同的调用序列。# 分组构建必须所有 rank 顺序一致 tp_groups, dp_groups [], [] for i in range(dp_size): for j in range(tp_size): ranks [i * tp_size j] # 具体切分逻辑按你的拓扑调整 # 每个 rank 都要参与所有 group 的创建调用 g dist.new_group(ranks) if rank in ranks: tp_groups.append(g)上面这段是示意实际切分索引要按你的 rank 排布来算。核心是那个每个 rank 都参与创建的原则。5.3 拓扑感知跨机带宽才是真正的天花板所有通信量估算最后都要落到一条物理链路上。同一台机器内的卡通过高带宽互联直连带宽是跨机链路的五到十倍延迟低一个数量级。所以任何高频通信都必须收敛在机内。判断自己的配置是否踩线看两个数张量并行组是不是跨机了数据并行组的通信量占单步时间的比例是多少前者一旦跨机基本可以判定性能不可接受后者如果超过 30%说明通信没被计算盖住要么加大计算密度提高 batch 或序列长度要么减少通信频率。还有一个容易漏的点是网卡和卡的亲和性。多网卡机器上每张卡应该优先走物理上最近的那张网卡。如果进程没有正确绑定可能出现卡 0 的数据绕到卡 7 那边的网卡出去多绕一跳交换机带宽减半。这类问题不会报错只会让吞吐莫名其妙地低排查起来特别费时间。6. 真机排障卡死在集合通信上的那几个小时6.1 无报错挂起先查集合通信的调用顺序分布式训练最让人抓狂的症状是所有 rank 都停住、CPU 占用为零、没有任何报错连超时都要等很久才触发。绝大多数情况下根因是各 rank 的集合通信调用序列不一致。比如某个分支只在 rank 0 上执行或者在某个 rank 上提前continue跳过了一次 All-Reduce其他 rank 就会永远等在那里。集合通信是强同步的一个都不能少。排查路径是这样走的第一步看日志最后一条打印在哪个位置确认挂在了前向、反向还是优化器更新阶段。第二步在可疑区域把每个集合通信调用前后都打上带 rank 号的日志跑一次看哪个 rank 少了一条。第三步检查所有条件分支凡是可能跳过的路径要么改成所有 rank 都执行、用 mask 控制数据要么改成非集合通信的本地操作。还有一类隐蔽的情况某些 rank 用了不同的通信域。组 A 的成员在组 A 上做 All-Reduce另一个 rank 却在全局组上做两边永远对不上。这类问题在有嵌套并行、动态建组的代码里特别容易出。另一类会导致挂起的硬件层原因是共享内存段不够。数据加载的多进程和某些通信后端会用到共享内存容器环境里默认的共享内存往往只有 64 MB跑起来没多久就卡死。这个坑我踩过不止一次特征是一开始能跑、跑一会就挂而且挂的位置随机。把共享内存挂载调大就能解决。6.2 吞吐只有预期一半从拓扑和网卡查起不报错、能跑完、但速度明显不对这类问题比挂起更难查因为你没有明确的错误信息。我的排查顺序是固定的先确认实际走的是哪条链路再确认每张卡的实际收发速率最后才怀疑算法。确认链路可以看通信库的初始化日志里面会打印检测到的互联类型机内高带宽互联还是走网络以及用了哪些网卡。如果发现本该走机内高速链路的通信走了网络那配置肯定有问题常见原因是可见设备的环境变量设置不一致导致各进程看到的卡编号错位。确认收发速率可以在训练跑起来之后抓一下网卡的实时流量。如果流量远低于链路容量说明要么消息太小没打满带宽要么重叠没做好导致通信和计算串行。前者调大分桶后者检查分桶逻辑。算法层面的怀疑放在最后。因为集合通信的算法选择通常是库自动做的手动指定反而容易选错——大消息选了低带宽算法或者小消息选了高延迟算法两种情况都会让性能显著下降但表现不同前者是带宽跑不满后者是延迟占比异常高。6.3 症状与方向的对照表症状大概率方向优先验证手段全 rank 静止、无报错、CPU 空闲集合通信调用序列不一致 / 通信域不匹配在每次集合通信前后打 rank 日志比对调用次数跑一段时间后随机挂死共享内存不足 / 文件句柄耗尽 / 内存泄漏检查共享内存挂载大小观察常驻内存曲线能跑完但吞吐只有一半通信未被重叠 / 拓扑走错 / 消息过碎抓网卡实时流量对照估算值加卡后单卡吞吐反降通信域跨了慢链路 / 计算通信比恶化确认张量并行组是否跨机只有部分 rank 慢进程与设备的亲和性绑定错误检查 NUMA 与网卡绑定关系首步极慢、后续正常通信库初始化与拓扑探测开销属正常现象可用缓存缩短不必深究这张表不是穷举但覆盖了实际碰到的大多数场景。有个通用原则值得记住分布式问题的定位成本主要在信息收集不在修复。所以花时间把日志打全、把监控指标铺开比事后猜要划算得多。7. 几个我在选型和调参上的实际体会第一先把单机跑满再考虑跨机。我见过太多在跨机配置上反复调优、最后发现是单机内部的通信域都没建对的例子。单机八卡的吞吐基线如果没打准后面所有的优化都失去了参照物。第二估算表要在动手前就写好。不用很复杂一张纸列清楚参数量、hidden、层数、batch、序列长度、计划用几路张量并行几路流水线并行然后按第三节的方法把每层通信量和单步总通信量算出来再对照你的互联带宽估一个通信时间。这个数字如果已经超过你预期的单步时间说明方案选错了改结构比改代码便宜。第三气泡和显存是一对反向指标任何声称两个都优化了的方案要么是换了硬件要么是藏了别的代价。看到气泡占比降下来第一反应应该是去查激活显存或者通信次数有没有涨。第四别迷信大 TP。张量并行的效率曲线在超过单机卡数之后会陡降这不是实现问题是计算通信比的数学规律。真要往上堆规模走流水线并行或者数据并行加分片把高频通信留在机内。第五超时时间要主动调。默认的超时对大规模训练来说往往太短一次正常的检查点保存就可能超时触发重启。但反过来把超时设得极长也有问题——真挂了你要等很久才发现。折中的做法是把超时设成正常单步时间的几十倍并且打开心跳监控让异常通过监控暴露而不是靠超时报错。第六保留一份通信量基线脚本。我通常会在代码里留一个函数输入并行配置就输出理论通信量每次改并行策略先跑一遍。这东西看着简陋但能在改配置之前就判断出这条路走不通省下的调试时间远超写它的成本。def estimate_tp_comm(batch, seq_len, hidden, dtype_bytes, tp_size, n_layers, steps1): 估算张量并行下每卡每步的 All-Reduce 传输量字节 s batch * seq_len * hidden * dtype_bytes per_ar 2 * (tp_size - 1) / tp_size * s # 环形算法单卡传输量 return per_ar * 4 * n_layers * steps # 每层前后向各两次 # 示例batch4, seq2048, hidden4096, bf16, TP8, 100 层 print(estimate_tp_comm(4, 2048, 4096, 2, 8, 100) / 1024**3, GiB)跑出来的结果和第三节手工算的一致约 43.75 GiB。把它和你的互联带宽一除就知道理论通信下限是多少。剩下的工作就是让实际耗时尽量逼近这个下限而不是想方设法绕开它——通信量是结构决定的绕不开只能藏。
