大模型分布式训练：集合通信与模型并行策略调优指南

1. 从一次扩展效率腰斩说起集合通信究竟卡在哪半夜两点某实验室的几十张加速卡一起跑一个百亿参数级别的训练任务单卡吞吐看着挺漂亮扩到八卡也还行扩到三十二卡的时候每秒处理的样本数只涨了不到一半扩到六十四卡直接原地踏步甚至回退。日志里没有报错显存没爆CPU 也不是瓶颈监控面板上唯一跳起来的是网络吞吐曲线——跑满了而且是一直跑满。这类现场我见过太多次。绝大多数人第一次做分布式训练注意力都放在模型结构、学习率、数据清洗上等真正卡住了才发现集合通信与模型并行策略才是决定这套集群能不能跑起来的那道门槛。集合通信说白了就是一群卡之间怎么开会:谁把数据发给谁、发多少、按什么顺序发、什么时候该等别人。模型并行策略则回答另一个问题:一张卡装不下这个模型我该沿哪个维度把它切开切完之后这些碎片之间需要多久通一次话。这两个问题是一体两面——你选了哪种切法就决定了你要付多少通信账单。这篇内容适合三类人看。第一类是刚接手多卡训练、被扩展效率上不去折磨的工程师你需要知道瓶颈到底在哪一层。第二类是要在多机集群上把一个几十亿到几百亿参数的模型塞进去、并且跑得不太慢的算法同学你需要一套选型逻辑而不是拍脑袋。第三类是写训练框架或者做性能分析的你想搞清楚各种并行组合背后的通信量公式从而判断某个方案值不值得尝试。我不会只讲概念会把通信量算成 MB、把耗时算成毫秒把配置写成能直接改参数复现的形式。先说结论性的判断:在大规模训练里计算是线性的通信是对数的甚至更差。你加一倍卡算力翻倍但通信的参与方也翻倍延迟项和带宽争抢同时恶化。所有并行策略的设计本质上都是在做同一件事——把不可避免的通信压缩到最小、藏到计算后面去、或者干脆限制在最快的那条链路上。2. 集合通信原语与性能模型先把通信贵算成具体数字2.1 六个基本原语各自对应什么训练动作集合通信的原语不多掰着手指头数得过来但每一个在训练里都有明确的对应动作搞清楚映射关系后面看任何并行方案都不会迷糊。Broadcast广播一个卡的数据发给所有卡。典型场景是训练开始时把初始权重从 rank 0 分发出去或者加载 checkpoint 后对齐参数。通信量就是一份数据的大小 S延迟是 log N 级别树形或 N 级别线性实现上一般走树。AllReduce全规约所有卡各自有一份数据规约求和/求平均之后每张卡都拿到完整结果。这是数据并行的命脉——每张卡算自己那部分 batch 的梯度然后 AllReduce 求平均。也是张量并行里每层都要做的事。ReduceScatter规约散射规约之后每张卡只保留结果的一个分片。它是 AllReduce 的前半段也是分片式数据并行ZeRO、FSDP 那一类方案省显存的关键动作。AllGather全收集每张卡有一片数据收集之后每张卡都拿到全部。是 AllReduce 的后半段也是分片方案在需要用到完整参数时的回收集动作。AllToAll全交换每张卡给其他每张卡各发一份不同的数据。专家混合模型MoE里把 token 路由到对应专家所在的卡靠的就是它某些张量并行的布局转换也用它。Reduce规约到单卡和Scatter/Gather属于变体实际训练里用得少但做指标统计比如把所有卡的 loss 汇总到一张卡打印时会碰到。这里有个很多人忽略的等价关系:AllReduce ReduceScatter AllGather。这不是学术上的拆解而是实打实的工程事实几乎所有高性能实现内部都是这么干的。理解这一点你就能明白为什么分片式并行不会额外增加通信量——它只是把一次 AllReduce 拆成两半前半段顺手把结果切了后半段再按需收集。2.2 通信量公式环算法的 2(N-1)/N 是怎么来的集合通信的性能模型可以用一个极简的式子概括:T ≈ α S / Bα 是单次消息的固定延迟微秒级S 是消息大小B 是有效带宽。小消息看 α大消息看 B这一条能解释后面 80% 的性能现象。以最常用的环形 AllReduce 为例。设卡数 N每张卡的数据量 S字节。算法分两个阶段:第一阶段叫 reduce-scatter做 N-1 步。每步中每张卡把自己手上的一块数据发给下游邻居同时接收上游邻居的一块并做累加。走完 N-1 步之后每张卡持有某一个分片的完整规约结果。第二阶段叫 all-gather同样 N-1 步。每张卡把自己持有的那块完整分片沿着环传一圈最终所有卡拼出完整结果。两个阶段的传输量分别都是 S(N-1)/N加起来:AllReduce 总通信量 2S(N-1)/NN 很大时这个系数趋近于 2。也就是说不管你用多少张卡AllReduce 每个卡实际收发的数据量最多是数据本身的两倍。这是环算法的漂亮之处也是它成为默认选择的原因——通信量对卡数不敏感只跟数据量有关。但代价藏在延迟项里:总步数是 2(N-1)每一步都有一次完整的网络往返握手。当 S 很小比如每步只同步几百 KB 的指标时2(N-1)·α 会完全主导这时候环算法反而慢树形或递归倍增这类 log N 步的算法更合适。这就是为什么集合通信库会针对不同消息大小自动切换算法——小消息走树大消息走环这个阈值通常在几百 KB 到几 MB 之间。其余原语的通信量可以一并记住Broadcast 是 SAllGather 是 S(N-1)/NReduceScatter 是 S(N-1)/NAllToAll 是 S(N-1)/N但每张卡发出的数据互不相同无法用规约压缩。2.3 从算法带宽到总线带宽为什么你的实测值和理论值差一倍新手最容易被这个坑住。拿一个 7B 参数模型做例子bf16 精度梯度也是 bf16一份梯度 14GB。八卡 AllReduce按公式算通信量 2 × 14 × 7/8 24.5GB。如果卡间链路是 50GB/s理论耗时 0.49 秒。实测往往只有理论的一半甚至三分之一于是开始怀疑人生。问题出在带宽这个词的口径上。厂商标的 50GB/s 是单向单端口带宽而环形 AllReduce 里每张卡同时在做收和发收和发各占一半再加上算法内部把数据切成 N 份流水线传输实际每个端口的有效利用率会打折扣。所以性能分析里要用**总线带宽bus bandwidth**这个概念换算关系是:busbw algbw × 2(N-1)/N其中 algbw 是你用数据量 / 耗时直接算出来的算法带宽。只有当 busbw 接近硬件链路的物理上限时你的实现才算跑满。做性能基线时先把 busbw 测出来再去看训练里的通信占比才能判断到底是通信实现不行还是你的并行策略本身通信量就太大。提示做基线测试时一定要用和训练时相同的数据规模和相同的进程拓扑。八卡单机跑出来的数字直接拿去推多机场景误差会大到没有参考价值因为跨机链路的带宽通常只有机内高速互联的几分之一。2.4 拓扑决定天花板为什么张量并行几乎从不出单机集群的物理结构是分层的:卡内显存带宽最高卡间高速互联次之跨机网络再次之通常还差一个数量级。这个带宽悬崖直接决定了并行策略的适用边界。单机内那几条高速链路延迟在微秒级、带宽在数百 GB/s跨机网络即使是很好的无损网络单端口也就几十 GB/s延迟高一个数量级。于是逻辑很清晰:通信频繁、对延迟敏感的并行方式必须关在单机里。张量并行每层都要同步属于这一类。通信稀疏、只同步梯度的并行方式可以跨机。数据并行属于这一类它每一步只通信一次。流水线并行介于两者之间它只在阶段边界传激活值量不大但有时序耦合跨机可接受但需要精心安排 micro-batch 调度来掩盖。我在实际配置里见过最常见的错误是把张量并行度设成跨越机器边界的数值。表面上看模型切开了、显存够了跑起来发现每层的 AllReduce 需要跨机往返单步时间直接翻三倍。这个问题后面在选型章节还会展开。3. 并行策略拆解数据、张量、流水线各自的分工与代价3.1 数据并行最简单也最容易撞上通信墙数据并行的逻辑最直观——每张卡放一份完整模型各自喂不同的数据反向传播后把梯度 AllReduce 求平均然后各自更新。它的优点是实现简单、收敛行为和单卡几乎一致、模型代码不用改。缺点也很直白:每张卡都要存一份完整的模型、梯度和优化器状态。算一笔账。一个 13B 参数的模型混合精度训练时显存占用大致是:组成部分精度大小参数bf1626 GB梯度bf1626 GB优化器一阶矩fp3252 GB优化器二阶矩fp3252 GBfp32 主权重副本fp3252 GB合计—约 208 GB单卡 80GB 显存装不下。这就是为什么纯数据并行在十亿参数以上基本走不通必须上分片或者混合并行。即便显存够通信也是问题。每步一次全量梯度 AllReduce通信量约 2 倍梯度大小前面算过而且这个量与 batch size 无关。这意味着你把 batch 调小、想多跑几步通信占比反而更高。数据并行的扩展效率曲线通常是:小规模线性得很好过了某个卡数开始掉头向下那个拐点就是通信时间开始追平计算时间的位置。工程上缓解这个问题的常规手段是梯度分桶 反向传播重叠。思路是:反向传播是从后往前一层层算的某几层的梯度算完就可以立刻发出去做 AllReduce不必等整个反向结束。把梯度按 25MB 左右切成桶这个默认值是有讲究的——太小则延迟项占主导太大则重叠不充分桶一满就触发异步规约让通信藏在后面的反向计算里。实测下来这一步能把数据并行的有效通信开销压掉 60% 到 80%是性价比最高的优化之一。3.2 张量并行把矩阵切开代价是每层都要对话张量并行解决的是单层都放不下的问题。以最常见的两层线性变换为例做法是把第一个矩阵按列切、第二个矩阵按行切中间结果在两张卡上各持一半经过一次 AllReduce 之后得到完整输出。反向传播时梯度也需要一次 AllReduce 来对齐。所以张量并行的通信特征是:每个 Transformer 层、每个 micro-batch前向一次 AllReduce、反向一次 AllReduce。一个 32 层的模型一层里注意力块和 MLP 块各有一组一次前向就是几十次集合通信。通信量怎么估它同步的不是参数而是激活值大小约为batch × seq_len × hidden_dim × 2 字节。取 batch4、seq2048、hidden5120单次约 84MB一次前向 64 次 AllReduce32 层 × 2 个块累计就是 5GB 级别。这个量在机内高速链路上还能扛跨机就完全没法看。这就解释了行业里那条不成文的规矩:张量并行度不要超过单机的卡数而且尽量贴着高速互联的拓扑边界走。八卡一机张量并行度就设 8四卡一机就设 4。设成 16 意味着有一半的通信要跨机性能必然塌方。还有一个容易被忽略的点:张量并行的通信量与 batch 无关。你把 micro-batch 调小计算量按比例下降但集合通信的次数不变、延迟不变于是通信占比反而升高。所以用了张量并行之后micro-batch 不宜切得太碎否则延迟项会把收益吃光。3.3 流水线并行用时间换空间代价是空泡流水线并行切的是层。前几层放机器 A中间放机器 B最后放机器 C数据像流水线一样依次流过。每张卡只需要存自己那几层的参数显存压力大幅下降而且卡之间只传激活值和梯度通信量小、频率低跨机也能接受。它的核心问题是空泡——流水线要填满才有意义。最朴素的实现所有 micro-batch 先做完全部前向、再做全部反向在开始和结束阶段会有大量卡闲着。设流水线阶段数 p、micro-batch 数 m气泡率的近似公式是:气泡占比 ≈ (p - 1) / (m p - 1)代入具体数字感受一下。p4、m4 时气泡率 3/7 ≈ 43%几乎一半时间在等p4、m32 时气泡率 3/35 ≈ 8.6%可以接受。所以流水线并行的关键是 micro-batch 数要远大于阶段数一般建议 m ≥ 4p。主流调度是 1F1B一前一后交替每张卡做完一个 micro-batch 的前向就紧接着做另一个 micro-batch 的反向让激活值的内存占用保持平稳而不是 GPipe 那样全部前向做完再全部反向那个方案显存会爆。更激进的交错式调度把每张卡负责的层打散成多个虚拟阶段能把气泡进一步压到 (p-1)/(m·vp-1)v 是虚拟阶段数但通信次数也随之上升属于精细调优的范畴。实操上还有两个细节。第一流水线的第一个和最后一个阶段负载天然不均衡第一个只做前向的一部分、最后一个只做反向的一部分会导致参数更新节奏不齐需要额外的 embedding 层拆分或损失缩放对齐。第二流水线要求所有 micro-batch 大小严格一致除非做变长调度数据加载器那边要保证最后一个 batch 能被整除否则会挂住——这个坑我踩过表现是训练跑到第 N 步就不动了日志毫无提示。3.4 混合并行真实集群里的组合方式到了几百卡的规模没有哪个单一策略能撑住标准做法是三维混合:TP × PP × DP 总卡数。举个具体配置。64 张卡单机 8 卡。合理的切法是 TP8关在单机内、PP4跨 4 台机器、DP2。这样每份模型被切成 4 段流水线、每段内部再切 8 份张量一共 32 张卡装一份完整模型副本两份副本做数据并行。选型的判断顺序我一般是这么走的:先看单层能不能放下。单层参数 激活超过单卡显存必须上张量并行且并行度不超过单机卡数。再看总层数够不够切。流水线并行度受层数限制32 层的模型切 8 段每段 4 层已经比较勉强切 16 段就是每段 2 层通信和调度开销会盖过收益。剩下的卡全给数据并行因为它的通信效率最高。最后看全局 batch 够不够。数据并行度越大需要的全局 batch 越大才能保证每卡上的 batch 不至于太小一般每卡不小于 1理想是 4 以上否则梯度噪声大、收敛变差。对于混合专家MoE这类结构还要额外引入专家并行靠 AllToAll 把 token 送到对应专家所在的卡上。这个通信模式的麻烦之处在于它是动态的——每个 token 去哪张卡取决于路由结果负载天然不均衡要做容量因子限制和 token 丢弃策略否则最慢的那张卡会拖住整个 AllToAll。4. 显存与通信的再平衡分片、重计算与重叠4.1 分片式数据并行用通信换显存的三档开关前面算过13B 模型纯数据并行要 208GB 显存。分片式方案ZeRO / FSDP 这一类的思路是:既然每张卡都存一份完整的优化器状态太浪费那就切开每张卡只存 1/N。这个思路分三档递进代价各不相同:档位切分对象单卡显存13BN8通信量变化第一档只切优化器状态约 39 GB与纯数据并行相同第二档优化器状态 梯度约 32 GB与纯数据并行相同第三档优化器状态 梯度 参数约 26 GB约增加 50%第一档和第二档是白捡的——显存省了通信量没变因为梯度 AllReduce 之后本来就要扔掉或者说规约后每张卡只需要自己那份顺手做成 ReduceScatter 就行。这是最划算的优化任何显存吃紧的场景都应该先开这一档。第三档才是真正的取舍。参数被切开了前向传播走到某一层时需要先把这一层的完整参数 AllGather 回来用完立刻释放。通信量因此增加约 50%前向一次 gather、反向一次 gather、反向一次 reduce-scatter加起来是原来的 1.5 倍。但它能把显存压到接近线性可分片的程度是单卡装不下大模型的兜底方案。实操上要注意第三档的 AllGather 是按层触发的层与层之间可以流水。好的实现会把下一层的参数预取和当前层的计算重叠起来把增加的那 50% 通信藏掉大半。判断一个实现好不好就看它的通信覆盖率——如果监控显示网络吞吐曲线有明显的空隙说明预取没做好。4.2 激活重计算拿算力换显存的另一条路参数、梯度、优化器状态之外还有一块常被低估的显存消耗:激活值。长序列场景下激活值能占到总显存的一半以上因为它跟 batch、序列长度、层数都成正比。激活重计算也叫梯度检查点的做法是:前向时不保存中间激活反向时重新算一遍。代价是多一次前向计算大约增加 30% 的计算量收益是激活显存降到原来的 1/√L 到 1/LL 是层数取决于切分粒度。这个取舍值不值要看你的瓶颈在哪。如果计算利用率已经很高比如 50% 以上再增加 30% 计算会更慢但如果因为显存不足被迫把 batch 设得很小、导致通信占比居高不下那重计算反而是提速的——它让你能把 batch 放大摊薄通信开销。我在一个长序列任务上做过对比开重计算之后 micro-batch 从 1 提到 4单步时间只增加了 12%整体吞吐提升近一倍。4.3 通信与计算重叠把账单藏起来所有优化里重叠是最无本万利的一类——通信时间没有减少但它发生在计算的同时等于不要钱。三个最有效的重叠点:梯度规约与反向计算重叠。前面提过按桶触发反向算到哪层就发哪层。这是数据并行的标配框架默认基本都开了但要确认桶大小设置合理。张量并行的 AllReduce 与前向计算重叠。这个需要框架层面的支持把矩阵乘法和集合通信放到不同的流上让第 i 层的通信和第 i1 层的计算并行。手写的话要小心同步点很容易写出隐藏的死锁或者竞态。分片方案的参数预取与计算重叠。第三档分片在前向时需要 gather 下一层的参数这个 gather 可以和当前层的计算并行发起。重叠做得好不好看一个指标就够了:通信覆盖率 通信时间被计算掩盖的比例。经验上调得好的数据并行能到 90% 以上张量并行因为通信密集能到 60% 到 70% 就算不错。5. 一套可复现的实操流程与配置5.1 第一步把集群拓扑摸清楚任何调优之前先测基线。要测的东西就三样:机内卡间带宽、跨机带宽、跨机延迟。用集合通信库自带的带宽测试工具跑一遍标准的 AllReduce数据量从 1MB 扫到 1GB画出带宽随消息大小的曲线。看曲线上的三个位置:小消息区64KB曲线平缓且低说明延迟主导这时候优化方向是减少通信次数或者合并消息。中段拐点带宽开始爬升的位置这个拐点对应延迟项和带宽项相等的消息大小通常是几百 KB。大消息平台能否跑到硬件标称值的 80% 以上跑不到就说明网络配置或者拓扑有问题。同时要记录实际的进程到卡的映射关系。这一段经常出岔子:容器环境下如果没把 rank 和物理卡对应关系固定好框架可能把本该同机通信的两个 rank 排到了跨机性能莫名其妙掉一半。检查办法是打印每个 rank 的主机名和本地设备号肉眼看一遍是不是连续的。5.2 第二步并行策略选型的判断流程我把上面几节的判断逻辑整理成一张可执行的表:判断问题判断依据结论单卡能否装下参数梯度优化器状态参数量 × 16 字节混合精度粗估能装下则不需要切参数单层参数能否装进单卡最大单层参数量 × 2 字节装不下必须上张量并行张量并行度上限单机卡数不超过这个值模型层数是否够切流水线层数 / 流水线度 ≥ 4否则气泡太大剩余卡数总卡数 / (TP × PP)全部给数据并行全局 batch 是否够每卡 batch ≥ 1理想 ≥ 4不够就减小并行度或增大全局 batch按这个流程走一遍先得到主要是能跑的配置再进入调优。别一上来就追求最优先跑通再跑快。5.3 第三步初始化与通信原语的写法分布式初始化的顺序很关键错一步就是几小时的排查。常见的正确顺序是:设定当前设备、初始化进程组、打印 rank 信息对齐、再做任何集合通信。下面这段是等价写法示意注释里标了每一步的用意:# 伪代码常见分布式接口的习惯写法 # 1) 先绑定本地设备避免所有进程挤在 0 号卡上 local_rank env_int(LOCAL_RANK) set_device(local_rank) # 2) 初始化进程组。跨机必须走高速网络后端 # 并显式指定通信网卡不要依赖自动探测 init_process_group( backendnccl, init_methodenv://, timeouttimedelta(minutes30), # 大模型加载慢默认超时常常不够 ) # 3) 打印拓扑肉眼核对排布是否符合预期 if global_rank() 0: print_topology() # 4) 屏障一次确保所有进程都起来了再往下走 barrier()几个容易翻车的点。超时时间一定要调大——几百亿参数的模型加载 checkpoint 动辄十几分钟默认的十分钟超时会在你还没开始训练的时候就报错而且报错信息通常只有一句连接超时看不出根因。通信网卡要显式指定多网卡机器上自动探测经常选错选到管理网卡上带宽差十倍。设备绑定要在初始化进程组之前做顺序反了会出现莫名其妙的显存分配失败。集合通信原语的使用上有一个新手常犯的错误:在条件分支里调用集合通信。比如if rank 0: all_reduce(tensor)这会导致除 0 号以外的所有进程都在等一个永远不会到来的消息整个任务挂死且没有任何报错。铁律是:集合通信必须被所有进程以相同的顺序调用。如果你确实只想对某部分数据做规约用 mask 或者传入不同形状的张量不要用分支。5.4 第四步跑起来之后看什么指标训练跑通只是开始真正决定成败的是几个观测量。扩展效率。用 N 卡的吞吐除以单卡吞吐再除以 N。八卡能到 0.85 以上算好六十四卡能到 0.6 就算合格。低于这个数先查是不是并行度的切法和拓扑不匹配。通信占比。用性能分析工具抓一段 profile看集合通信的总耗时除以总步时间。数据并行健康值在 10% 以内张量并行在 30% 以内。超过这个范围说明通信没被藏住。计算利用率。用实际达到的浮点运算量 / 硬件峰值估算大模型训练通常在 40% 到 55% 之间。数字低但通信占比也不高说明瓶颈在数据加载或者算子效率上别往通信方向查了。每卡负载均衡。把所有卡的步时间打出来看最大值和最小值的差距。超过 5% 就要查——可能是流水线阶段分配不均也可能是数据加载的随机性导致某张卡总是分到长样本。MoE 结构下这个指标尤其重要一个专家的负载爆炸能让整个集群等它。5.5 第五步一个具体的调参示例假设场景:32 层、13B 参数、hidden 5120、序列长度 204832 张卡、单机 8 卡。第一轮按流程判断:单卡装不下前面算过 208GB需要切。单层参数约 0.4Bbf16 下 800MB单卡放得下理论上不需要张量并行。但考虑到激活值8 卡一机内上 TP4 更稳。流水线 32 层切 4 段每段 8 层m 取 16 的话气泡率 3/19 ≈ 16%。剩余 32/(4×4) 2数据并行度 2。全局 batch 设为 64每卡 micro-batch 64 / (2 × 16) 2梯度累积 1 步。这个配置能跑但数据并行只有 2通信占比不高主要开销在流水线气泡上。第二轮优化:把 micro-batch 数提到 32气泡率降到 3/35 ≈ 8.6%但每卡 micro-batch 变成 1计算粒度太细算子启动开销上来。折中取 m24。第三轮开梯度分桶重叠桶大小从默认调到 32MB因为这里是跨机通信延迟高桶大一点能减少握手次数开激活重计算把 micro-batch 从 2 提到 4同时把梯度累积降到 0.5即用更大的全局 batch。每轮都要记录三个数字:单步时间、每卡吞吐、通信占比。三轮下来的典型结果可能是单步时间从 1.8s 降到 1.2s提升 33%。这个量级的优化绝大多数来自调度和重叠而不是换了什么高深的并行方案。6. 常见问题与排查速查6.1 挂起与超时九成是集合通信不匹配分布式训练最让人抓狂的故障是没有任何报错就是不动了。这类问题的根因几乎都是集合通信的两个参与方对不上——要么次数不一致要么顺序不一致要么张量形状不一致。排查顺序我一般是这样的:现象最可能的原因验证方法训练启动后无输出、无进展某个 rank 在集合通信前就崩了其余在等看每张卡的日志最后一行找到那个没打印ready的跑到某一步卡住前一步正常条件分支里有集合通信或 batch 数不能整除检查数据加载器是否 drop_last检查循环里的 if报连接超时网卡选错、超时设置太小、防火墙规则显式指定网卡超时调到 30 分钟以上报张量形状不匹配各 rank 传入的 tensor 大小不同打印每个 rank 的形状注意最后一个 batch偶发挂死重启就好网络抖动或显存碎片开集合通信库的调试日志看是不是有重传一个非常实用的技巧:开集合通信库的调试日志把日志级别设成 INFO 或 WARN它会把每次集合通信的操作类型、数据量、参与方都打出来。挂住的时候看最后一条日志停在哪个操作上再对比各个 rank 的日志立刻就能定位是谁没跟上。这个手段比看 Python 堆栈有用得多因为挂起通常发生在 C 层面的等待上Python 栈是看不到的。注意调试日志会显著拖慢性能绝对不能在生产训练里长期开着。定位完立刻关掉否则你会以为是训练本身变慢了。6.2 扩展效率不线性按层次往下剥加卡不提速是最高频的问题。我的排查顺序是固定的从便宜到贵:第一步确认是不是数据加载拖累。把所有卡的 GPU 利用率打出来如果普遍在 60% 以下且波动大先查数据管道。多卡场景下数据加载的压力是线性增长的单卡时不是瓶颈的预处理多卡时很容易成为瓶颈。解决办法是增加加载进程数、把预处理放到卡上做、或者提前把数据编码成定长格式。第二步确认并行度切法和拓扑匹配。打印 rank 到物理机的映射看通信量最大的那组通常是张量并行组是不是都落在同一台机器内。这一步能解决相当一部分莫名掉速的问题。第三步看通信覆盖率。抓 profile看通信时间有没有和计算重叠。如果通信时间几乎等于理论值、没有重叠说明桶大小设置不合理或者框架的重叠开关没打开。第四步才去看算法层面的通信量。这时候要算:当前配置下每步的总通信量是多少 GB除以实测带宽得到理论耗时和 profile 里的通信时间对比。如果实测远大于理论说明有争抢或者拥塞如果基本吻合那就是通信量本身就太大了得换并行方案。这个顺序很重要。我见过太多人一上来就怀疑算法改来改去最后发现是数据加载的进程数设成了 1。6.3 那些文档里不会写的经验显存碎片比显存不足更麻烦。训练跑了几百步突然 OOM重启就好这是典型的碎片问题。原因是不同 batch 的形状不一致比如变长序列没有 padding 到固定长度导致缓存块无法复用。解决办法是强制把所有 batch pad 到固定长度或者设置显存分配策略为可扩展段。这个问题在长序列场景下尤其常见。checkpoint 保存会打断流水线。大规模训练里保存一次 checkpoint 可能要几十秒所有卡都在等主进程写完。做法是异步保存——先把张量拷到 CPU 内存立刻返回继续训练后台线程慢慢写盘。要注意拷到 CPU 这一步本身也是同步的最好用 pinned memory 加快。学习率要随全局 batch 调整。这一点经常被忽略:你为了填满流水线把全局 batch 从 64 提到 512学习率还按原来的设收敛曲线会明显变差。经验规则是线性缩放加 warmupwarmup 步数也要按比例增加。别在训练中途改并行配置。想从 32 卡扩到 64 卡继续训练需要重新切分参数和优化器状态这个过程叫 checkpoint 重切分。它要求源配置和目标配置的切分维度能整除否则某些参数分片对不上。稳妥做法是每换一次配置就从最近的 checkpoint 重新开始一小段 warmup不要指望无缝衔接。监控里一定要有每步耗时的分布而不只是平均值。平均值 1.2 秒看起来很稳但如果分布是 0.8 秒和 1.6 秒各一半说明存在系统性的抖动通常是某些卡在等 straggler。看 P99 和最大值能提前发现负载不均。序列长度变化会连带改变最优配置。短序列512场景下激活值小显存瓶颈在优化器状态优先开第一档分片长序列8192场景下激活值占大头优先开激活重计算和序列并行。同一个模型换任务并行配置往往要重调不要照搬。测试扩展效率时用弱扩展不要用强扩展。强扩展是固定全局 batch、加卡减每卡 batch这种测法在小 batch 下通信占比会急剧上升测出来的效率天然难看不代表实际部署效果。实际训练通常是全局 batch 随卡数增加所以要用弱扩展来测每卡 batch 保持不变。最后一件事我自己的习惯是每换一套配置都把关键参数、实测的单步时间、通信占比、扩展效率记到一张表里。跑过十几组之后你会对这个规模的集群、这种模型、大概应该在什么区间建立起直觉下次换模型时不需要从零试起直接从表里最接近的那一行改两个参数就能开工。这个习惯比任何调优技巧都值钱——它把每次踩坑变成了可复用的资产而不是一次性消耗。