集合通信与模型并行策略：多卡训练通信代价与显存估算

把模型摊到几十张卡上跑训练头一两周基本都在和两件事较劲显存炸了以及卡在等卡。前者要靠模型并行策略把参数和激活切开后者要靠集合通信把切碎的东西传起来而这两件事本质上是同一枚硬币的两面——你怎么切决定了你要传什么、传多少、传给谁。很多人调参调得很顺一到多卡就卡住问题往往不在算子写错而在对通信代价没有量化的直觉不知道该切哪一维、不知道瓶颈在带宽还是在延迟、不知道扩容后吞吐为什么不升反降。这篇就围绕集合通信与模型并行策略这两条主线把原语语义、环形算法、四种切法的通信特征、显存与通信的定量估算、以及实际排障经验一次讲透。适合已经能在单卡跑通训练、准备上多卡的人也适合已经上了多卡但算力利用率一直上不去、想搞清楚钱花在哪的人。不需要你有分布式系统的底子但需要你接受一件事多卡训练的优化七成是算术题三成才是调参。1. 先把边界划清楚集合通信到底在解决什么问题1.1 单卡撞上的两堵墙决定了后面所有设计单卡训练走到瓶颈一定是两堵墙之一先到。第一堵是显存墙一份混合精度训练的完整状态大约要按每参数 16 字节来算——2 字节的 bf16 权重、2 字节的 bf16 梯度、4 字节的 fp32 主权重、再加上优化器里 4 字节的一阶动量和 4 字节的二阶动量。也就是说一个百亿参数的模型光状态就要 160GB 量级再加激活值、临时缓冲、通信桶单张卡根本放不下。第二堵是算力墙即便显存放得下单卡跑完一次完整训练的时间也不可接受。这两堵墙对应两类完全不同的解法。显存不够就把参数、梯度、优化器状态、激活值这四类东西沿某个维度切开这是并行策略的范畴算力不够就把计算量分给更多卡但分完之后每一份结果还要合并合并就要通信。麻烦在于切开的方式会直接改变通信的模式和体量切参数矩阵的某一维换来的是一次 All-Reduce切网络层换来的是点对点传激活切 batch换来的是梯度全局归约。所以做多卡方案设计时第一步永远不是选框架而是先把我要切哪一维、切完之后通信长什么样、这个通信能不能被计算掩盖住这三问答完。我在实际项目里见过太多反过来的做法先照着某个开源配置抄一份并行度跑起来发现慢再回头一项项试。这种试错成本极高因为并行度组合是乘性的三四种并行维度一交叉可选配置几十种每跑一次都要几十分钟。正确顺序是先算账、后动手算账的核心输入只有三个模型参数量、单步 token 数、以及你的互联带宽。1.2 集合通信和点对点通信是两套不同的思维通信原语分两类。点对点send/recv是两个进程之间的事语义简单但用起来要自己管配对、管顺序、管死锁集合通信collective communication是一组进程共同参与的操作所有参与者在同一个通信域communicator里调用同一个函数语义由原语本身保证。分布式训练里九成以上的通信走的是集合通信原因很实在你不用关心谁发给谁只需要关心我要把大家的东西按什么规则合并。集合通信的关键概念有三个必须分清。第一是通信域一组卡的逻辑编号跨域通信是不允许的组域的时候要保证所有卡对成员列表的认知一致否则会直接挂死。第二是同步语义绝大多数集合原语是阻塞式的调用后要等所有参与者都到齐才返回这意味着任何一张卡掉队整个域都会被拖住——这也是多卡训练里一张卡慢全体等的根源。第三是数据量与消息数大消息看带宽小消息看延迟同一个原语在不同消息尺寸下的耗时曲线完全不是一个形状后面算账时这张曲线比理论带宽重要得多。提醒调试集合通信问题时第一件要做的事是确认所有 rank 调用的原语序列完全一致。只要有一张卡少调了一次或者顺序错了表现就是无报错挂死日志里什么都看不到排查成本极高。养成在通信点前打一行带 rank 号日志的习惯能省下大量时间。1.3 并行策略的本质是把通信量分配到最便宜的链路上理解了上面这些就能给并行策略一个更准确的定义它不是怎么把模型拆开而是怎么把不可避免的通信量分配到代价最低的链路上并且尽量让它藏在计算后面。同样的总通信量放在机内高速互联上可能只占单步时间的百分之几放到跨机网络上就可能直接翻倍。所以任何并行方案的第一步判断都是给通信分类高频大流量的张量并行每层的激活归约必须待在机内低频大流量的数据并行的梯度同步可以跨机但要靠梯度桶和重叠去藏高频小流量的流水线并行的阶段间激活传递看重的是延迟而不是带宽往往要专门优化启动开销。这条分类原则比任何一篇论文里的具体配置都更耐用。你换了模型、换了卡数、换了互联规格具体数值全变但什么通信该放在哪一层的判断逻辑不变。后面几节会把这套判断拆成可以算的数字。2. 五个核心原语语义、代价与它们出现的场景2.1 Broadcast 与 Reduce最基础的两块砖Broadcast广播的语义是指定一个根节点把它的一份数据复制给域内所有其他节点。通信量按接收方算每个非根节点收 S 字节总线上传 S 字节量级的数据。它在训练里最典型的用途是参数初始化——只在 0 号卡上做随机初始化然后广播出去保证所有副本位对齐。另一个用途是分发配置或随机种子。Reduce归约的语义相反所有节点各有一份 S 字节的数据按指定算子求和、求最大值等合并结果只写到根节点。它的通信量是每个非根节点发 S 字节。Reduce 在训练主流程里出现得不多更多是出现在指标汇总、loss 统计这类小消息场景——这类消息量小但频率高如果每步都同步一次累计起来相当可观实践中一般改成每 N 步聚合一次。这两个原语单独用的场合其实有限真正重要的是它们组合出来的东西。理解它们的关键是记住一个对称关系Broadcast 是一传多Reduce 是多合一而 All-Reduce 就是多合一之后再一传多——但这个理解只对语义成立对实现不成立因为如果真按这个顺序做中间结果会全部堆在根节点上根节点的进出带宽成为瓶颈这正是后面环形算法要解决的问题。2.2 All-Reduce梯度同步的绝对主角All-Reduce是所有节点各有一份数据归约之后每个节点都拿到完整结果。它是数据并行的核心操作每张卡算完自己那批数据的梯度All-Reduce 一过所有卡的梯度就一致了等价于用了一个大 batch。这里有个容易算错的点All-Reduce 的通信量并不是每卡收发 S 字节。若模型参数量为 P、梯度用 bf16 存2 字节单份梯度总量 S 2P 字节N 张卡做 All-Reduce采用最优的环形实现时每个节点实际发送和接收的数据量都是 2(N-1)/N × S。N 很大时趋近于 2S也就是说每个节点都要把相当于两倍梯度大小的数据搬进搬出——一遍用于归约阶段的发送一遍用于收集阶段的接收。代入具体数字70 亿参数模型bf16 梯度S 14GB8 卡数据并行每卡收发 2×7/8×14 ≈ 24.5GB。如果机内高速互联的有效带宽按 300GB/s 算峰值标称往往更高但实际能跑到的有效带宽通常只有五六成通信时间约 82ms。这个数字单看不大但它是每步都发生的而且如果网络走的是跨机链路有效带宽掉到 25GB/s同样的量就要 1 秒左右这时它就成了绝对瓶颈。2.3 All-Gather 与 Reduce-Scatter把一个 All-Reduce 拆成两半All-Gather是每个节点持有一份不同的分片收集后所有节点都拿到拼接完整的全量数据。Reduce-Scatter是所有节点各持有一份全量数据先归约再把结果按分片散开每个节点只保留属于自己的那一片。这两个原语的价值在于All-Reduce 在数学上恒等于 Reduce-Scatter 接 All-Gather。这不是文字游戏而是几乎所有高效实现的真实做法。把它拆开的好处是每一半都可以独立优化、独立与其他计算重叠比如在反向传播算到最后几层时就可以对已经算完的梯度分片先做 Reduce-Scatter不必等全部梯度就绪。这两个原语也是 ZeRO 系列方案的骨架。切优化器状态时前向要用参数就 All-Gather 一次反向算完梯度就 Reduce-Scatter 一次随着切分粒度从优化器状态扩展到梯度、再扩展到参数All-Gather 和 Reduce-Scatter 的调用频次会显著上升。这就是用通信换显存的准确含义——省下来的每一字节显存都要用通信量去换换得值不值要算。2.4 All-to-All专家并行绕不开的那道坎All-to-All的语义是每个节点把自己的一份数据切成 N 片第 i 片发给第 i 个节点同时从每个节点收一片。它是唯一一个每个节点发给所有人、也从所有人收的原语因此对网络的对分带宽极其敏感——环形 All-Reduce 可以靠流水掩盖延迟All-to-All 不行它天然是全互联的流量模式。它在训练里主要出现在两个地方。一是专家并行MoEtoken 要按路由结果发到持有对应专家的卡上算完再发回来一来一回两次 All-to-All。二是序列并行中的注意力头重排部分实现在切分注意力计算时会用它做布局变换。MoE 训练里 All-to-All 的耗时占比经常达到两三成原因就在这里它既不能像 All-Reduce 那样切成两段与计算重叠又对跨机链路极度敏感。2.5 五个原语的代价速查把上面的内容压成一张表方便随时对照。表里的 S 指单份数据的字节数N 指通信域内的节点数。原语语义一句话单节点收发量环形实现典型场景性能敏感点Broadcast一传多收 S参数初始化、配置分发延迟Reduce多合一发 S指标汇总频率控制All-Reduce多合一再一传多收发 2(N-1)/N·S数据并行梯度同步带宽、重叠All-Gather分片拼全量收 (N-1)/N·SZeRO 取参数、TP 前向带宽Reduce-Scatter归约后散开发 (N-1)/N·SZeRO 传梯度、TP 反向带宽All-to-All人人发人人收收发 (N-1)/N·S但全互联MoE、布局变换对分带宽注意这张表里的单节点收发量是最优环形实现的数字。如果你的通信库因为拓扑不匹配降级成了线性实现实际量级会变成 N 倍量级的差距而不是百分之几十。遇到扩卡后单步时间线性增长的诡异现象先怀疑拓扑识别失败。3. Ring All-Reduce 为什么快把账算到毫秒级3.1 朴素实现的死穴在根节点假设不用环形按最直觉的方式做 All-Reduce所有卡把梯度发给 0 号卡0 号卡累加完再广播回去。这套流程的语义完全正确但带宽账极难看0 号卡要接收 (N-1)S 字节、发送 (N-1)S 字节而其他卡只发 S、收 S。总线上最忙的那张卡承担了 N 倍于平均值的流量整个操作的耗时被它单点决定扩卡时耗时几乎线性增长——这就是为什么卡越多越慢。环形算法要解决的就是这个不均衡。它的思路非常朴素把数据切成 N 块让每张卡只和自己左右两个邻居说话形成一个逻辑环所有人匀速搬运谁也不特殊。代价是通信步数变多2(N-1) 步但因为每一步所有卡都在并行地传不同的块总时间取决于每张卡搬了多少而不是某张卡搬了多少。3.2 两个阶段先散开归约再拼回全量第一阶段 Reduce-Scatter每张卡把自己的数据切成 N 块第 i 步时每张卡把自己手上第 (rank - i) 块发给下游邻居同时从上游邻居收一块收到后与自己对应的块相加。走完 N-1 步后每张卡手上恰好有一块已经完全归约好的数据块且各卡持有的块互不重复。第二阶段 All-Gather不再做加法纯粹是把第一阶段得到的完整块沿着环继续传N-1 步之后所有卡都集齐了全部 N 块。关键在于两个阶段各走 N-1 步每步传 S/N 字节所以每张卡总发送量 2(N-1)/N·S接收量相同。这个数字和 N 的关系很弱——N8 时是 1.75SN64 时是 1.97S几乎饱和。也就是说环形 All-Reduce 的通信量对节点数不敏感扩卡不会让单卡通信量暴涨这是它成为默认实现的根本原因。3.3 完整算例从参数量推到单步耗时拿一个具体配置走一遍完整流程这套算法你在自己项目里可以原样套用只替换数字。输入参数量 P 7×10⁹梯度精度 bf162 字节数据并行度 N 8全局 batch 每步 200 万 token单卡有效算力按 300 TFLOPS 估这是标称峰值乘上约五成的实际利用率别用标称值算会严重低估耗时。第一步算通信量。S 2P 14GB每卡收发 2(N-1)/N·S 1.75 × 14 24.5GB。有效带宽按 300GB/s通信耗时 ≈ 24.5/300 ≈ 82ms。第二步算计算量。训练一步的浮点运算量约等于 6PDD 是这一步处理的 token 数。6 × 7×10⁹ × 2×10⁶ 8.4×10¹⁶ FLOP。8 张卡合计有效算力 2.4×10¹⁵ FLOP/s计算耗时 ≈ 35 秒。第三步算占比。82ms / 35s ≈ 0.23%。这个比例说明大 batch 下数据并行的梯度同步根本不是瓶颈优化它没有意义该去优化的是别的地方。换个场景再算一次如果每步只有 3.2 万 token小 batch 微调场景计算量降到 1.34×10¹⁵ FLOP计算耗时 ≈ 0.56 秒通信占比变成 15%。这时候梯度同步就值得优化了——手段是梯度分桶、反向传播时边算边发、或者干脆减少同步频率梯度累积。这两个算例的价值不在于数字本身而在于给你一个判断标准通信时间除以计算时间超过 10% 就该动手低于 3% 就别在这上面浪费时间。很多人一上来就折腾通信优化结果发现优化空间只有百分之二纯属白干。3.4 环形不是终点树形、分层与拓扑感知环形算法有个隐性缺点步数随 N 增长2(N-1) 步每步都有固定的启动延迟。当消息很小或者 N 很大时延迟项会盖过带宽项这时候环形反而不如树形。树形算法把步数压到 log N 量级代价是带宽利用率略低所以工程上的常见做法是按消息大小切换大消息走环形小消息走树形这个阈值由通信库自动决定不用你操心但你要知道它存在否则看到小消息性能异常时会误判。更实际的是分层算法。机器内部走高速互联机器之间走网络两层的带宽差一个数量级这时候把所有卡当成一个平坦的环是浪费——跨机流量会白白多跑。分层做法是先机内归约把每台机器的结果压成一份再跨机归约最后机内广播。总跨机流量可以从 (N-1)/N·S 降到 (M-1)/M·SM 是机器数在多机场景下这是实打实的收益。这套优化能不能生效取决于通信库能否正确识别拓扑。容器化部署、虚拟化环境、或者网卡绑定配置错误时拓扑识别经常失败库会退回平坦环甚至线性实现性能直接掉一半以上。所以部署完多机环境第一件事是让通信库打印它识别到的拓扑结构确认机内和跨机的链路都被正确识别这比任何调参都重要。4. 四种切法模型并行策略的通信特征对照4.1 数据并行最省心但显存账最硬做法每张卡放一份完整模型各自吃不同的数据反向算完梯度做一次 All-Reduce然后各自更新。优点实现最简单几乎不用改模型代码通信模式单一扩卡时计算和通信都能近似线性摊薄。缺点显存一点没省——每张卡都要放全套参数、梯度、优化器状态模型大到单卡放不下时直接失效。它的通信特征很明确每步一次 All-Reduce通信量与模型参数量成正比、与卡数弱相关位置固定在反向传播末尾。这个位置固定反而是优点因为可以用梯度分桶把它切成很多小块反向算一层发一层让通信和计算重叠起来。分桶的经验值是每个桶几 MB 到几十 MB桶太小启动延迟占比高桶太大最后几个桶要等很久才能凑满尾延迟明显。实践中普遍用 25MB 上下作为起点再根据实测微调。数据并行真正的坑在有效 batch 变大。8 卡数据并行等价于 batch 乘 8学习率、warmup 步数、优化器 epsilon 都要跟着调否则收敛曲线会明显劣化。很多人只看到吞吐涨了没注意收敛变差最后怪模型结构其实是超参没跟上。4.2 张量并行切矩阵乘通信最密集做法把单层的权重矩阵切开分给不同卡算再把部分和加起来。以一层线性变换 Y XW 为例可以按列切 W每张卡算输出的一部分列也可以按行切 W每张卡算一个部分和最后 All-Reduce 相加。前向按列切、反向按行切是一套经典组合能让每层前向只需一次 All-Reduce、反向再需一次。它的通信特征是最贵的每层两次 All-Reduce消息大小是 batch × 序列长 × 隐藏维度 × 字节数。代入一个常见配置batch 4、序列 4096、隐藏 8192、bf16单次 All-Reduce 数据量约 268MB两次超过 500MB。而一层的计算时间通常在毫秒量级通信时间和计算时间是同一个数量级——这就是张量并行必须待在机内的原因。一旦跨机带宽掉一个数量级通信时间直接压过计算扩卡变成减速。切分粒度也有讲究。张量并行度通常取 2、4、8且必须能整除注意力头数和隐藏维度。取 8 以上时单卡上的矩阵已经很小计算效率下降、通信频次不变性价比急剧变差。我的经验是张量并行度不要超过单机内的卡数且优先选择能整除头数的最大因子剩下的显存压力交给其他维度去解决。4.3 流水线并行切层数用气泡换显存做法把模型按层切成若干段每段放在不同卡上数据像流水线一样从第一段流到最后一段。前向时第 k 段算完把激活发给第 k1 段反向时再传回来。优点通信量极小——只传阶段边界的激活量级是 batch × 序列 × 隐藏 × 字节数且只在相邻卡之间传不走全局集合通信同时显存按段切分参数、梯度、优化器状态都能省下来。缺点气泡。气泡的成因很直白流水线刚启动时后面的段在空等快结束时前面的段在空等。为了让气泡占比下降标准做法是把一个 batch 切成多个 micro-batch 依次灌进去段数 P 和 micro-batch 数 M 的关系决定了气泡率常见的 1F1B 调度下气泡占比约等于 (P-1)/M。所以段数越多、micro-batch 越少浪费越严重。经验上 M 至少取 4P气泡才能压到 25% 以下M 取 8P 时能到 12% 左右再往上收益递减。还有一个实操细节micro-batch 不能无限切小因为每段的最小计算单元要能喂满算力切太碎会让算子启动开销占比上升。所以流水线并行度的实际上限往往不是显存决定的而是我能切出多少个 micro-batch 而不让单次计算太小决定的。这一点在选型时最容易被忽略。4.4 序列并行与专家并行两个专项补丁序列并行主要解决长上下文场景下激活值的显存问题。标准注意力计算中激活值随序列长度平方增长长文本训练时激活值可能比参数还占地方。做法是把序列维度切开每张卡只算一段序列的注意力但在计算注意力的归一化项时需要跨卡做 All-Reduce 归约统计量代价是每层两次小消息通信。另一种变体是只在 LayerNorm 和 Dropout 处切序列这两种操作本身逐元素独立切分后只需在需要全量信息的地方做一次 All-Gather通信量更可控。专家并行面向稀疏结构模型有多个专家子网络每个 token 只激活其中一小部分。做法是把专家分布到不同卡上token 按路由结果用 All-to-All 发过去算完再发回来。它的通信特征是量不大但极难隐藏——All-to-All 无法像 All-Reduce 那样切成两段塞进计算间隙只能整体插入因此对网络对分带宽要求最高。此外还有一个隐性的负载均衡问题如果路由不均某些卡收的 token 特别多整个 All-to-All 就被最慢的那张卡拖住。所以 MoE 训练必须加负载均衡损失并且要监控每张卡的 token 分布这是必做项而不是可选项。4.5 ZeRO 系列把状态切开的中间路线如果数据并行显存放不下、张量并行通信又太贵ZeRO 这条中间路线值得优先考虑。它的思路是不切计算、只切状态分三档递进第一档只切优化器状态。每张卡仍然保存完整的参数和梯度但优化器里的动量、方差、fp32 主权重按卡分片。显存节省大约是把 12 字节的优化器开销除以 N通信量和标准数据并行一样还是每步一次 All-Reduce只是实现上变成 Reduce-Scatter All-Gather。第二档再加上梯度分片。反向算完的梯度直接 Reduce-Scatter 到各自的卡上不再保留全量梯度。省下的显存更多通信量基本持平。第三档连参数也切。前向每层开始前 All-Gather 拿参数用完就释放反向再来一次 All-Gather 取参数算完梯度 Reduce-Scatter。显存降幅最大但每步通信量大约是标准数据并行的 1.5 倍这是必须付的代价。一个粗略的显存估算混合精度下每参数 16 字节标准数据并行每卡要放 16P 字节第三档把其中 14 字节的量和梯度、优化器状态都按 N 分片后每卡大约需要 2P 14P/N 字节。70 亿参数、8 卡标准数据并行要 112GB第三档只要约 26GB差别就在这里。这里必须强调一句第三档不是免费的。它的通信量比标准数据并行多一半而且 All-Gather 发生在每层前向的关键路径上非常依赖通信能否和上一层的计算重叠。如果重叠做不好你会看到显存降下来了但吞吐掉了三成这种情况在跨机部署时尤其明显。4.6 组合策略怎么选一张决策表真实项目里很少只用一种策略常见组合是机内张量并行 跨机数据并行或者机内张量并行 跨机流水线并行 最外层数据并行。选择顺序可以参考下表按优先级从上往下试。优先级策略什么时候用通信代价主要风险1数据并行模型单卡放得下每步一次 All-Reduce量固定有效 batch 变大超参要重调2ZeRO 前两档单卡放不下但通信预算紧与数据并行持平分片参数管理启动慢3张量并行单层就放不下或需要极限吞吐每层两次 All-Reduce最贵必须限制在机内整除头数4流水线并行超大模型跨机扩展相邻传激活量小气泡、micro-batch 调度复杂5ZeRO 第三档显存极紧网络带宽充裕数据并行的 1.5 倍关键路径 All-Gather重叠要求高6专家并行稀疏模型All-to-All最难隐藏负载均衡、对分带宽选择时有个简单的约束链可以套用先用数据并行填满机内再考虑把张量并行限制在单机内剩下的显存缺口交给流水线并行或 ZeRO 第三档最外层再套数据并行。反过来做先开大张量并行跨机几乎必然踩坑因为跨机的张量并行通信开销会直接吃掉全部收益。5. 落地流程从估算到跑通的四步5.1 第一步算显存账定切分维度动手前先在纸上算清四类显存的量级参数 2P 字节、主权重与优化器状态 12P 字节、梯度 2P 字节、激活值这个最难估粗略按每层 batch × 序列 × 隐藏 × 层数 × 若干倍来估实测偏差常常在一倍以上要留余量。算完把总数除以单卡可用显存得到需要的切分倍数 K。然后决定 K 从哪个维度出单层放得下但模型放不下走流水线或 ZeRO单层都放不下必须上张量并行。这一步做完并行度的候选集就收敛到三五种比盲目试要快得多。5.2 第二步算通信账判断瓶颈在哪对每个候选方案估一下单步通信时间和单步计算时间的比值。通信时间的公式上面已经给过计算时间用 6PD 除以总有效算力。这里有个容易忽略的点要按最慢的那条链路估也就是把你的卡按互联域分组机内一组、跨机一组分别算取时间长的那个。如果算出来通信占比超过 20%说明这个方案会被通信卡住要么换策略要么先把重叠做好。低于 5% 就放心跑瓶颈一定在别处比如数据加载、算子效率、显存碎片。5.3 第三步配置关键项把重叠打开框架层面有几个配置项对结果影响巨大列出来备查。具体名字各框架不同但语义是一致的。# 示意配置字段名按你所用框架的实际文档替换 parallel: data_parallel_size: 8 # 最外层跨机 tensor_parallel_size: 4 # 机内必须整除注意力头数 pipeline_parallel_size: 2 # 跨机段数 sequence_parallel: true # 长序列时开激活值可省一半 communication: bucket_size_mb: 25 # 梯度桶大小先按 25 起步再调 overlap_grad_reduce: true # 反向边算边发必开 overlap_param_gather: true # 前向取参数与计算重叠ZeRO-3 必开 hierarchical_allreduce: true # 多机场景机内先归约再跨机 training: micro_batch_size: 1 gradient_accumulation: 16 # 与 pipeline 段数配合凑够 micro-batch 数三个参数值得单独说。微批大小它决定流水线的气泡率太小气泡多太大显存放不下通常从 1 开始往上试直到显存接近上限。梯度累积步数数据并行下它决定有效 batch直接影响收敛改动它必须同步调学习率。桶大小它决定重叠的粒度调这个参数的成本很低改配置重启即可收益却可能有好几个百分点属于性价比最高的调参项。5.4 第四步压测与观测别信单次结果跑通不等于跑好。至少要采三组数据单步耗时的稳定值跳过前 20 步的预热取后面 100 步的中位数、通信耗时占比、以及每张卡的计算耗时分布。观测的重点不是平均值而是离散度。如果每张卡的通信耗时差异超过 10%说明存在慢卡或者拓扑不均扩卡后问题会被放大如果通信耗时占比在长尾样本里突然飙高多半是某次 All-to-All 或者某个大桶触发了拥塞要去看网络侧的计数。我自己的习惯是每次改并行配置都记录一行配置组合、单步耗时、通信占比、显存峰值攒够十几行之后选型就不用再猜了。6. 常见问题与排查实录6.1 症状对照表先定位再动手症状最可能的原因处理动作扩卡后吞吐不增反降张量并行跨了机或拓扑识别失败检查并行度是否超出单机卡数打印拓扑确认训练卡住无报错各 rank 调用的集合通信序列不一致在通信点前打 rank 日志逐段对齐单步耗时抖动很大某个大桶或 All-to-All 触发拥塞调小桶尺寸错开通信峰值显存随步数缓慢上涨通信缓冲未释放或激活未及时回收检查是否有张量被闭包持有收敛明显变差有效 batch 变大但学习率没调按比例放大学习率、延长 warmup通信耗时占比异常高消息太小延迟主导合并小消息减少同步频次某张卡永远最慢慢卡、时钟降频或链路降速换卡、查链路状态、对齐时钟策略6.2 三个踩过的坑第一个坑把张量并行开到了跨机。当时为了省显存把张量并行度从 4 提到 16跨了四台机器结果单步耗时从 1.2 秒涨到 3.8 秒。原因是每层两次 All-Reduce 走了跨机链路带宽差了十几倍重叠完全掩盖不住。改回机内 4 之后剩下的显存缺口用流水线并行补总吞吐反而更好。教训是张量并行度这个数字物理含义是最多不超过一台机器里的卡数不是我想切几份就切几份。第二个坑桶大小调大反而变慢。想当然地认为桶越大、启动开销越少、越快于是从 25MB 调到 200MB。结果是反向传播末尾要等很久才能凑满最后一个桶尾延迟把收益全吃掉了。实测下来 25MB 到 50MB 之间最稳具体取决于层数和单层梯度大小。这类参数的特点是存在一个明显的最优区间别用极值去试。第三个坑流水线气泡被忽略。把流水线并行度设成 8micro-batch 只有 8气泡率算下来接近 90%实际算力利用率低得可怜但看单卡利用率指标却看不出问题——因为卡确实在忙忙着等。后来把梯度累积加到 64气泡降到 11%吞吐直接翻了三倍。这个坑的隐蔽之处在于气泡不表现为空闲而表现为低效的忙碌只看利用率数字会误判。6.3 一份可以贴到项目文档里的避坑清单上多卡前先在单卡测出基线吞吐否则后面无法判断多卡到底是快了还是慢了。并行度全部设成 2 的幂并且验证每一个维度都能整除对应的模型维度头数、隐藏维度、层数。多机部署后第一件事是让通信库输出拓扑确认机内和跨机链路都被正确识别。打开梯度分桶重叠并把桶大小当作一个正式的超参去调至少试三个值。流水线的 micro-batch 数至少取段数的 4 倍8 倍更稳但要确认单次计算没被切得太碎。每次改并行配置同步检查学习率和 warmup 是否需要跟着动尤其是改了数据并行度或梯度累积的时候。观测指标里一定要有每卡耗时的离散度只看平均值会漏掉慢卡和拓扑不均。用通信占比做决策阈值超过 10% 值得优化低于 3% 就别在这上面花时间。最后分享一个我自己的判断习惯面对一个没跑过的并行配置先花十分钟把显存账和通信账各算一遍算出两个数字——需要多少切分倍数、通信占单步时间多少比例。如果这两个数字和预期差得远那说明方案本身选错了再怎么调参也救不回来如果数字对得上但实测不行那问题一定在实现细节上去查拓扑、查重叠、查桶大小方向就明确了。多卡训练最贵的成本从来不是算力而是在错误方向上试错的时间。