1. 从单卡到千卡集群：大模型分布式训练到底在解决什么问题
很多人第一次接触大模型训练，脑子里想的都是模型结构、注意力机制、数据配比这些事，但真正上手跑一次百亿参数级别的训练任务就会发现，模型代码可能两天就写完了，剩下的两周全耗在“怎么让它跑起来”上。单卡显存装不下、梯度同步慢得离谱、训练到一半loss突然炸掉、checkpoint存了三个小时还没写完——这些才是日常。分布式训练架构要解决的核心矛盾就一句话：单张卡的显存和算力有物理上限，而模型规模和训练数据量在持续膨胀。
我拿一个具体的数字来算这笔账。假设一个模型有130亿参数，用FP16存储，光权重就需要26GB显存。训练时还要存梯度（26GB）、优化器状态（Adam的话，FP32的momentum和variance各占52GB，合计104GB），再加上前向传播的激活值。粗算下来，没有160GB以上的显存根本跑不动。而目前单张主流加速卡的显存普遍在40GB到80GB之间，差距一目了然。这就是为什么必须做分布式——把模型切开放到多张卡上，或者把数据切开放到多张卡上，或者两者兼而有之。
分布式训练的策略大致可以分成四类，我按“切什么”来区分：
- 数据并行（Data Parallelism, DP）：每张卡持有完整的模型副本，但喂给每张卡不同的数据batch。梯度通过AllReduce同步。优点是实现简单，缺点是模型必须能装进单卡。
- 流水线并行（Pipeline Parallelism, PP）：把模型按层切成若干段，每段放到不同的卡上。数据像流水线一样依次经过各段。优点是能训超大模型，缺点是存在“气泡”（bubble），即某些卡在等待上游输出时处于空闲状态。
- 张量并行（Tensor Parallelism, TP）：把单个矩阵运算拆开，比如一个大的矩阵乘法切成几块，分别在不同卡上算完再拼起来。优点是切分粒度细，缺点是通信频繁，对带宽要求极高。
- 专家并行（Expert Parallelism, EP）：主要用于MoE（混合专家）架构，把不同的专家网络放到不同的卡上，每个token只激活部分专家。优点是参数量可以做得极大而计算量可控，缺点是负载均衡很难做好。
实际的大规模训练几乎不会只用一种策略，而是把这几样组合起来，业内常说的“3D并行”就是DP+PP+TP的组合。再往上还有ZeRO（零冗余优化器）这类技术，它本质上是对数据并行中冗余存储的优化——每张卡不再存完整的优化器状态，而是切分存储，需要时再通过通信拼起来。ZeRO把数据并行的显存效率提升了一个数量级，让“用数据并行训大模型”重新变得可行。
理解这些策略的关键在于抓住一个核心权衡：计算和通信的比值。切得越细，单卡的计算量越小，但卡与卡之间需要交换的数据就越多。如果通信时间超过了计算时间，加卡反而会变慢。这就是为什么张量并行通常只在单机内部（通过NVLink等高带宽互联）使用，而跨机场景更多用流水线并行或数据并行——因为跨机网络的带宽通常比机内互联低一个数量级。
一个常见的误区是“卡越多越快”。实际上，当并行度超过某个阈值后，通信开销会吃掉全部收益。我在一个项目里见过有人用32张卡做张量并行，结果比8卡还慢，原因就是跨机通信的延迟太高，每次矩阵乘都要等数据传过来。
所以做分布式训练架构设计，第一步不是写代码，而是算账：模型多大、单卡显存多少、机内带宽多少、跨机带宽多少、目标batch size多大。把这些数字摆出来，方案基本就确定了。下面我会逐个拆解每种并行策略的实现细节、通信原语、以及在实际项目中怎么选、怎么调。
2. 数据并行的通信原语与ZeRO的显存账本
数据并行是最直观的策略，也是大多数人接触分布式训练的第一个方案。它的逻辑很简单：每张卡有一份完整的模型，各自跑不同的数据，算完梯度后大家同步一下，确保每张卡上的模型保持一致。但“同步一下”这三个字背后涉及大量工程细节，尤其是当卡数上去之后，通信就成了瓶颈。
2.1 AllReduce的工作机制与Ring实现
数据并行的核心通信操作是AllReduce：所有卡把自己的梯度拿出来，求和（或求平均），然后每张卡都拿到求和后的结果。最朴素的实现是选一张主卡收集所有梯度、求和、再广播回去，但这样主卡会成为瓶颈，而且带宽利用率极低。实际用的是Ring AllReduce，把所有卡组成一个逻辑环，分两个阶段：
- Scatter-Reduce阶段：每张卡把自己的梯度分成N份（N等于卡数），然后沿着环依次传递并累加。经过N-1步后，每张卡上有一份完整的求和结果。
- AllGather阶段：把上一步得到的各部分结果沿着环传播，经过N-1步后每张卡都拥有完整的梯度。
Ring AllReduce的妙处在于，它的通信量与卡数无关，只与梯度大小有关。每张卡发送和接收的数据量都是2×(N-1)/N×梯度大小，当N很大时趋近于2倍梯度大小。这意味着加卡不会显著增加单卡的通信负担，理论扩展性很好。
但理论归理论，实际中Ring AllReduce的效率受限于两个因素：一是环上最慢的那张卡会拖累所有人（木桶效应），二是如果梯度很大，通信时间可能超过计算时间。我实测过一个10亿参数的模型，梯度用FP16存储是2GB，在25Gbps的跨机网络上做一次AllReduce大约需要1.3秒，而单步计算可能只要0.5秒。这种情况下通信就是纯开销，加卡只会让情况更糟。
2.2 ZeRO的三个阶段与显存收益计算
ZeRO（Zero Redundancy Optimizer）的思路是：数据并行中每张卡都存了完整的优化器状态、梯度和模型参数，但这些信息其实是冗余的——既然大家最终要同步成一样的，为什么每张卡都要存一份？ZeRO把这部分冗余切分到各卡上，需要时再通过通信收集。
ZeRO分三个阶段，逐步加深切分程度：
| 阶段 | 切分内容 | 显存节省（相对基线） | 额外通信 |
|---|---|---|---|
| ZeRO-1 | 优化器状态 | 约4倍 | 无 |
| ZeRO-2 | 优化器状态+梯度 | 约8倍 | 无 |
| ZeRO-3 | 优化器状态+梯度+参数 | 与卡数成正比 | 前向/反向各一次AllGather |
以130亿参数模型为例，用Adam优化器、FP16混合精度训练，基线显存占用大约是：参数26GB + 梯度26GB + 优化器状态104GB = 156GB。开启ZeRO-1后，优化器状态被切分到N张卡上，每卡只存104/N GB，总显存降到26+26+104/N。当N=8时，每卡约65GB，已经能装进80GB的卡了。开启ZeRO-3后，参数也被切分，每卡只存26/N GB，N=8时每卡约16GB，非常宽裕。
但ZeRO-3的代价是通信量增加。每次前向传播需要AllGather收集参数，反向传播再AllGather一次，反向结束后还要ReduceScatter梯度。通信量大约是ZeRO-1的1.5倍。所以在带宽充足的场景下，ZeRO-3很香；如果跨机带宽紧张，ZeRO-1或ZeRO-2可能更划算。
实操建议：先用ZeRO-1，如果显存不够再升到ZeRO-2，最后才考虑ZeRO-3。ZeRO-3虽然省显存，但通信开销和实现复杂度都明显更高，而且对训练速度的影响在带宽受限时非常明显。
2.3 梯度累积与micro-batch的配合
数据并行中还有一个常被忽略的细节：梯度累积。当单卡显存装不下目标batch size时，可以把一个大batch拆成几个micro-batch，依次前向和反向，梯度累加起来，等所有micro-batch跑完再做一次AllReduce。这样等效于增大了batch size，但通信频率降低了。
这里有个容易踩的坑：BatchNorm和梯度累积的交互。如果模型里有BatchNorm层，每个micro-batch的统计量是独立的，累积后的梯度并不等价于大batch的梯度。解决办法是用SyncBatchNorm，让所有卡的所有micro-batch一起算统计量，但这又增加了通信。所以现在大模型基本都用LayerNorm或RMSNorm，天然没有这个问题。
另一个坑是学习率的缩放。增大等效batch size后，学习率通常需要相应调整。常见的做法是线性缩放（batch size翻倍，学习率翻倍）或平方根缩放。但这不是铁律，具体要看优化器和数据分布。我在一个项目里试过线性缩放，结果训练初期loss震荡得厉害，后来改成平方根缩放才稳定下来。
3. 流水线并行的气泡问题与调度策略
流水线并行的核心思想是把模型按层切成若干段（stage），每段放在不同的卡上。数据从第一段进入，经过前向传播后传给第二段，以此类推。反向传播则反过来。这样每张卡只需要存模型的一部分，显存压力大大降低。
但流水线并行有个天然缺陷：气泡。假设模型切成4段，放在4张卡上。第一张卡算完第一个micro-batch的前向后，把结果传给第二张卡，自己开始算第二个micro-batch的前向。但第二张卡在收到第一个micro-batch的结果之前是空闲的。同理，第三张卡要等第二张卡算完才能开始。这就导致在流水线填充和排空阶段，部分卡处于空闲状态。
3.1 GPipe与PipeDream的调度差异
解决气泡问题的思路有两种代表：GPipe和PipeDream。
GPipe的做法是把一个batch切成多个micro-batch，所有micro-batch依次走完前向，然后再依次走反向。这样气泡只出现在流水线的填充和排空阶段，中间阶段所有卡都在满负荷工作。气泡占比大约是 (stage数-1) / micro-batch数。比如4段流水线、16个micro-batch，气泡占比约19%。micro-batch越多，气泡越小，但显存占用也越大，因为要存所有micro-batch的激活值。
PipeDream的做法更激进：它让前向和反向交错进行，每张卡算完一个micro-batch的前向后，立刻开始算上一个micro-batch的反向。这样气泡几乎为零，但问题是梯度更新会变得异步——不同stage可能在不同版本的参数上计算。PipeDream通过维护多个版本的权重来解决一致性问题，但实现复杂度很高，实际用得不多。
目前主流框架（如Megatron-LM、DeepSpeed）默认用的是GPipe风格的调度，因为实现简单且效果稳定。1F1B（One Forward One Backward）调度是GPipe的改进版，它在流水线填满后，每张卡交替执行一个前向和一个反向，进一步压缩了气泡。
3.2 流水线切分的实操原则
流水线怎么切，直接决定了训练效率和显存均衡。几个实操原则：
- 按层切，不要按算子切：流水线并行的通信粒度是stage之间的激活值，如果切得太细，通信次数会暴增。通常以Transformer层为单位切分。
- 均衡各stage的计算量：如果第一段有10层、第二段有2层，那第二段的卡大部分时间在等第一段。理想情况下每段层数相近。但首尾段有embedding和输出层，计算量可能不同，需要单独调整。
- 考虑通信开销：stage之间的通信量等于激活值的大小，与batch size和序列长度成正比。如果序列很长，激活值可能很大，跨机传输会成为瓶颈。这种情况下可以把流水线并行限制在机内，跨机用数据并行。
我在一个项目里把40层模型切成8段，每段5层，结果发现第一段和最后一段明显更慢——因为第一段要做embedding查表，最后一段要做logits计算和loss。后来改成第一段3层、中间段各5层、最后一段7层，整体吞吐提升了约12%。这种微调没有理论公式，只能实测。
注意：流水线并行和数据并行可以叠加。常见配置是“机内流水线+跨机数据并行”，这样跨机通信只发生在数据并行的梯度同步上，频率低、数据量大，适合高延迟网络。
4. 张量并行：把矩阵乘法拆开算
张量并行是切分粒度最细的策略，它直接对模型中的矩阵运算下手。以Transformer中的多头注意力为例，假设有H个头，可以把H个头分到不同的卡上，每张卡算一部分头，最后拼接。前馈网络（FFN）中的两个大矩阵也可以按列或按行切分。
4.1 列并行与行并行的组合
张量并行的核心操作是矩阵乘法的切分。考虑一个线性层 Y = XA，其中X是输入，A是权重矩阵。有两种切法：
- 列并行：把A按列切成[A1, A2]，每张卡算Y1 = XA1和Y2 = XA2，最后拼接得到Y。这种切法不需要通信，因为每张卡独立算出一部分输出。
- 行并行：把A按行切成[A1; A2]，每张卡算Y1 = X1A1和Y2 = X2A2，最后需要AllReduce求和得到Y = Y1 + Y2。
Transformer的FFN通常是“先列并行再行并行”：第一个线性层用列并行，第二个线性层用行并行。这样中间不需要通信，只在最后做一次AllReduce。注意力层也是类似，Q、K、V的投影用列并行，输出投影用行并行。
这种设计的精妙之处在于，它把通信次数降到了最低。一个Transformer层只需要两次AllReduce（注意力输出一次，FFN输出一次），而且通信量是激活值大小，相对可控。
4.2 张量并行的通信瓶颈与适用场景
张量并行的通信非常频繁，每层都要做AllReduce，而且通信量与激活值大小成正比。如果跨机做张量并行，网络延迟会直接拖垮训练速度。所以张量并行几乎只在单机内部使用，依赖NVLink或类似的高带宽互联。
我实测过一组数据：在机内NVLink（带宽约600GB/s）上做张量并行，8卡扩展效率能到85%以上；同样的配置放到跨机25Gbps网络上，扩展效率直接掉到30%以下。差距就是这么明显。
所以实际的大模型训练配置通常是：
- 机内：张量并行（8卡），利用高带宽互联
- 跨机：流水线并行或数据并行，通信频率低
比如一个1750亿参数的模型，可以用8路张量并行+16路流水线并行，总共128张卡。每8张卡在一个节点内做张量并行，节点之间做流水线并行。这样跨机通信只发生在stage边界，频率远低于张量并行。
4.3 序列并行与上下文并行的补充
当序列长度很长时（比如32K tokens），激活值的显存占用会变得很大。这时候可以引入序列并行：把序列维度也切分开，每张卡处理一部分token。序列并行通常和张量并行配合使用，因为LayerNorm和Dropout等操作需要完整的序列信息，序列并行可以避免在这些地方做额外的通信。
上下文并行是序列并行的一种扩展，专门针对超长序列场景。它把注意力计算中的KV缓存也切分开，每张卡只存一部分KV，计算时通过通信获取需要的部分。这在长文本生成任务中非常有用，但实现复杂度较高，目前主要在少数框架中支持。
5. 混合并行实战：从方案设计到参数调优
前面分别讲了数据并行、流水线并行和张量并行，实际项目中几乎不会只用一种，而是根据模型规模、硬件配置、网络条件组合使用。这一节我以一个具体场景为例，走一遍方案设计和调优的完整流程。
5.1 场景设定与硬件盘点
假设我们要训练一个70亿参数的模型，硬件是4个节点，每个节点8张80GB显存的加速卡，机内NVLink互联，跨机25Gbps网络。目标batch size是4M tokens，序列长度4096。
先算显存。70亿参数，FP16存储是14GB，梯度14GB，Adam优化器状态56GB，合计84GB。单卡80GB装不下，必须切分。用ZeRO-1切分优化器状态，8卡时每卡7GB，总显存14+14+7=35GB，加上激活值大约10GB，总共45GB，能装下。所以数据并行+ZeRO-1是可行的。
但4M tokens的batch size，如果每卡micro-batch是8，序列长度4096，那每卡每步处理32K tokens。4M/32K=128，需要128步梯度累积。这个累积步数太多了，训练效率会很低。所以需要增加并行度来降低单卡负担。
改用8路张量并行+4路数据并行：每8张卡组成一个张量并行组，共4个组做数据并行。张量并行把模型切成8份，每卡只存1/8的模型，显存压力骤降。数据并行组之间做梯度同步，通信频率低。这样每卡micro-batch可以设大一些，梯度累积步数减少。
5.2 并行维度的分配逻辑
并行维度的分配有一个经验法则：优先用满机内带宽，再考虑跨机。具体来说：
- 张量并行放在机内：因为通信最频繁，必须用高带宽互联。通常设为单节点的卡数（如8）。
- 流水线并行跨机：通信频率中等，跨机可以接受。但要注意stage之间的负载均衡。
- 数据并行跨机：通信频率最低（每步一次），适合跨机。但梯度同步的数据量大，需要网络带宽支撑。
对于上面的场景，8路张量并行正好用满一个节点。剩下4个节点可以做数据并行，或者2路流水线+2路数据并行。如果模型层数很多（比如80层），可以考虑流水线并行，把模型切成4段，每段20层，放在4个节点上。但这样每个节点内的8张卡做张量并行，节点之间做流水线并行，数据并行度为1。这意味着没有数据并行，batch size受限于单条流水线的吞吐。
实际选择取决于模型结构和训练目标。如果模型层数不多（比如32层），流水线切4段每段8层也可以，但气泡占比会高一些。如果追求高吞吐，数据并行更简单直接。
5.3 通信重叠与计算图优化
分布式训练的性能瓶颈往往不在计算，而在通信。把通信和计算重叠起来，是提升效率的关键手段。常见做法：
- 梯度同步与反向传播重叠：在反向传播算完某一层的梯度后，立刻开始这层的AllReduce，而不是等所有层都算完再统一同步。这样通信和计算可以并行。
- 流水线并行中的1F1B调度：前向和反向交错执行，让不同stage的卡尽量保持忙碌。
- ZeRO-3中的参数预取：在前向传播需要某一层参数之前，提前发起AllGather，等参数到了直接算，减少等待时间。
这些优化在主流框架中都有实现，但需要正确配置才能生效。比如PyTorch的DDP默认支持梯度同步与反向重叠，但需要设置gradient_as_bucket_view=True来减少内存拷贝。DeepSpeed的ZeRO-3需要配置stage3_prefetch_bucket_size来启用预取。
一个容易忽略的点：通信重叠会增加显存占用，因为需要缓存多份梯度或参数。如果显存本来就紧张，开启重叠可能导致OOM。这时候需要权衡：是牺牲一点速度换显存，还是牺牲显存换速度。
5.4 训练稳定性与故障恢复
大规模分布式训练跑几天甚至几周是常态，期间硬件故障、网络抖动、进程崩溃都可能发生。没有故障恢复机制，一次崩溃可能损失几天的训练进度。
Checkpoint策略是基础。但存checkpoint本身也有讲究：
- 异步保存：不要让所有卡停下来等checkpoint写完。可以用后台线程异步写盘，训练继续。
- 分片保存：每张卡只存自己那部分参数，恢复时各卡读各自的。这样并行度高，速度快。
- 定期保存+滚动删除：保留最近N个checkpoint，避免磁盘爆满。
除了checkpoint，还需要监控训练稳定性。Loss突然飙升、梯度范数异常、某些卡的吞吐明显下降，这些都是故障前兆。我习惯在训练脚本里加一个简单的监控：每100步打印一次各卡的吞吐和梯度范数，如果某张卡连续几次吞吐低于平均值20%以上，就发告警。
另一个实操经验：在正式训练前，先跑一个短时间的“冒烟测试”，用真实数据和真实并行配置跑几百步，确认没有OOM、没有通信死锁、loss能正常下降。这个测试能提前暴露90%的配置问题，比直接上大规模训练再排查要高效得多。
6. 经典论文的阅读顺序与核心贡献拆解
分布式训练领域的论文很多，但真正奠定基础的也就那么几篇。我按“先读什么、后读什么”的顺序梳理一下，每篇只说核心贡献和实操价值。
6.1 并行策略的奠基性工作
Megatron-LM（2019）是张量并行的开山之作。它详细描述了如何把Transformer的注意力层和FFN层做列并行和行并行切分，并给出了通信量的理论分析。这篇论文的价值在于，它证明了张量并行可以在不损失精度的前提下大幅降低单卡显存，而且给出了具体的切分方案。读这篇的时候重点关注第3节“Model Parallelism”，里面有完整的矩阵切分图示。
GPipe（2019）提出了流水线并行的micro-batch调度方案。核心贡献是证明了流水线并行可以用“填充-稳定-排空”的三段式调度来压缩气泡，并且给出了气泡占比的公式。这篇论文的实验部分展示了在8卡上训练一个80亿参数模型的结果，扩展效率相当不错。读的时候注意第4节的调度算法伪代码。
PipeDream（2019）提出了异步流水线并行，用权重版本管理来解决梯度一致性问题。虽然实际用得不多，但它对气泡问题的分析很透彻，值得一读。特别是它提出的“1F1B”调度，后来被Megatron-LM采纳并改进。
6.2 ZeRO系列与显存优化
ZeRO（2020）是微软DeepSpeed团队的工作，系统性地分析了数据并行中的显存冗余，并提出了三个阶段的切分方案。这篇论文的精华在第4节，它用表格形式给出了每个阶段的显存节省和通信开销对比。我建议重点看ZeRO-1和ZeRO-2，因为这两个阶段没有额外通信，性价比最高。
ZeRO-Offload（2021）进一步把优化器状态和梯度卸载到CPU内存，让单卡也能训大模型。核心思路是利用CPU内存比GPU显存大得多的特点，把不常用的数据放过去。代价是CPU和GPU之间的数据传输，但通过计算和传输重叠可以部分掩盖。这篇论文适合显存极度受限的场景。
ZeRO-Infinity（2021）把卸载扩展到NVMe磁盘，理论上可以训任意大的模型。但磁盘IO速度是硬伤，实际训练速度会慢很多。这篇论文的价值更多在于展示了“显存不够就往外存”的极限思路。
6.3 混合并行与自动化策略
Megatron-Turing NLG（2021）是一个5300亿参数模型的训练报告，详细描述了如何组合张量并行、流水线并行和数据并行来训练超大模型。这篇论文的实操价值极高，它给出了具体的并行配置、batch size、学习率调度等超参数。读的时候重点关注第3节“Parallelism”和第4节“Training Details”。
Alpa（2022）提出了自动并行策略搜索，根据模型计算图和硬件拓扑自动决定用什么并行组合。核心贡献是把并行策略选择形式化为一个优化问题，并用整数线性规划求解。这篇论文适合想深入了解并行策略自动化的读者，但实现复杂度较高，实际项目中用得不多。
FlexFlow（2019）是另一个自动并行的工作，它提出了“SOAP”搜索空间，把并行维度分为Sample、Operation、Attribute、Parameter四个维度。这篇论文的搜索算法比较复杂，但它的分析框架很有启发性。
6.4 论文阅读的实操建议
读这些论文的时候，我建议带着三个问题去读：
- 它解决了什么显存或通信瓶颈？每篇论文的动机都是某个具体的瓶颈，搞清楚这个瓶颈是什么，才能理解它的设计选择。
- 它的通信量是多少？大部分论文都会给出通信量的理论分析，这是判断它是否适合你的场景的关键。
- 它的实验配置是什么？论文里的实验配置（卡数、网络、模型大小）直接决定了它的结论是否适用于你的场景。如果论文用的是机内NVLink，而你是跨机网络，那它的扩展效率数据对你参考价值有限。
另外，论文里的公式推导不用全看，但关键公式要理解。比如ZeRO的显存节省公式、流水线的气泡占比公式、张量并行的通信量公式，这些是方案设计的理论基础。
7. 框架选型与踩坑记录
理论讲完了，最后说说工具。分布式训练的框架主要有PyTorch DDP、DeepSpeed、Megatron-LM、FairScale、Colossal-AI等。每个框架的定位和适用场景不同，选错了会走很多弯路。
7.1 各框架的定位与适用边界
PyTorch DDP是最基础的方案，只支持数据并行，但胜在稳定、易用、和PyTorch生态无缝集成。如果你的模型能装进单卡，或者用ZeRO-1/2就能装下，DDP是首选。它的API极其简单，基本上把model包一层DistributedDataParallel就能跑。
DeepSpeed是微软的框架，核心卖点是ZeRO系列显存优化和Offload。它和PyTorch兼容性好，配置通过JSON文件管理，比较灵活。缺点是文档质量参差不齐，有些配置项的含义需要看源码才能搞清楚。我在用DeepSpeed的时候踩过一个坑：stage3_gather_16bit_weights_on_model_save这个配置如果不设成True，保存的checkpoint是分片的，恢复时需要额外处理。
Megatron-LM是英伟达的框架，专注于张量并行和流水线并行，性能优化做得非常极致。缺点是代码耦合度高，想改模型结构比较麻烦。它更适合从头训练标准Transformer架构的场景，不太适合做研究性质的模型改动。
Colossal-AI是一个较新的框架，主打自动并行和异构内存管理。它的API设计比较友好，支持多种并行策略的组合。但生态还不如DeepSpeed成熟，遇到问题可参考的资料少一些。
选型建议：先用DDP跑通，显存不够上DeepSpeed ZeRO，需要张量并行或流水线并行再考虑Megatron-LM或Colossal-AI。不要一上来就上最复杂的框架，调试成本太高。
7.2 常见报错与排查思路
分布式训练的报错信息往往很隐晦，因为涉及多进程通信。我整理了几个高频问题和排查方法：
| 报错现象 | 可能原因 | 排查方法 |
|---|---|---|
| NCCL timeout | 某张卡卡住或网络不通 | 检查各卡是否都在运行，用nvidia-smi看GPU利用率 |
| OOM但显存看起来够 | 激活值或临时缓冲区超预期 | 减小micro-batch，开启梯度检查点 |
| Loss变成NaN | 学习率太大或梯度爆炸 | 降低学习率，加梯度裁剪 |
| 训练速度突然下降 | 某张卡降频或网络拥塞 | 监控各卡吞吐和温度 |
| Checkpoint恢复后loss异常 | 优化器状态未正确恢复 | 确认checkpoint包含优化器状态 |
NCCL timeout是最常见的，通常是因为某张卡上的进程挂了，但其他卡还在等它。解决办法是设置合理的timeout，并在超时后打印各卡状态。PyTorch的init_process_group有个timeout参数，默认是30分钟，可以调小到几分钟，这样出问题时能更快发现。
7.3 性能调优的实操清单
最后给一份性能调优的检查清单，按优先级排序：
- 确认通信瓶颈在哪：用profiler看AllReduce、AllGather等操作占了多少时间。如果超过30%，说明通信是瓶颈。
- 调整micro-batch大小：micro-batch越大，计算效率越高，但显存占用也越大。找到显存刚好够用的最大值。
- 开启通信重叠：DDP的
gradient_as_bucket_view、DeepSpeed的overlap_comm、Megatron的--overlap-grad-reduce。 - 优化数据加载：用
DataLoader的num_workers和prefetch_factor，确保GPU不等数据。 - 检查是否有不必要的同步：比如
torch.cuda.synchronize()调用过多，或者日志打印太频繁。 - 尝试不同的并行组合：如果当前配置扩展效率低，换一种并行策略试试。有时候TP=4+PP=2比TP=8+PP=1更快。
一个反直觉的经验：有时候减少卡数反而更快。因为通信开销降低了，单卡的计算效率提升了。我在一个项目里从32卡降到16卡，总吞吐只下降了10%，但训练稳定性大幅提升，综合下来反而更划算。
分布式训练没有银弹，每个方案都有取舍。理解原理、算清账、多实测，比盲目套用别人的配置要靠谱得多。
