大模型分布式训练：拆数据、拆模型的策略与实战指南

1. 为什么单卡训练撑不起大模型：先看清分布式要解决的两座大山

先聊点直接的开场。如果你已经开始跑大模型训练，无论是一个亿级参数模型还是几十亿级别的开源底座，你大概率会在某个深夜面对这样一个场景：显存报错 OOM、训练速度慢到按天起步、或者干脆在数据加载阶段就卡死。这时候大家都会想起同一个词——分布式训练。但分布式训练不是简单地把任务丢到多张卡上就跑得动，它背后的核心逻辑，就是从拆数据到拆模型的一系列策略组合。

市面上讲分布式训练的资料其实很多，但大部分要么是纯理论框架，要么是只讲某一个具体框架的API用法。我这篇想换个方式：从“拆”这个字入手，把数据和模型两条拆解路线讲透，再用实际配置和踩坑经验告诉你怎么选出适合自己场景的策略组合。适合的读者很明确——已经从单卡起步、准备把训练规模推进到多卡甚至多机阶段的人，以及那些分布式概念都懂、但一上手就出各种玄学问题的同学。

先说清楚分布式训练要解决的两座大山，这样后面看策略才不会迷茫。

第一座山是显存墙。一个几十亿参数的模型，光参数用半精度存储，每10亿参数大约就是2GB显存。这还只是参数本身。训练过程中还要有梯度，梯度是参数的两倍（Adam优化器甚至有动量项和方差项，开销更高）。再加上激活值、中间状态、通信缓冲区，一个70亿参数的模型用Adam训练，单卡显存需求量通常超过了60GB。消费级显卡哪怕满配两张24GB，都塞不进去。这就是为什么有人说“训练大模型是富人的游戏”——其实不是，只是你没有用对拆法。

第二座山是算力墙。就算模型勉强塞进了单卡，训练速度也极其感人。因为大模型训练的瓶颈往往不在单次计算，而在于总计算量。每次前向反向涉及的浮点运算次数，在几十亿参数规模下都是天文数字。单卡算力再强也有物理上限，你需要的不是一张聪慧的卡，而是多张卡协同并联跑。

而分布式训练的所有策略，本质上就是在回答三个问题：参数在哪一层被切分、计算如何并行、梯度如何在设备间同步。拆数据对应的是数据并行，拆模型对应的是模型并行，拆后的排列组合就是各种混合并行方案。下面我把每条路线的原理、适用场景、以及实际落地时那些坑挨个讲清楚。

2. 先拆数据：数据并行的通信账单与梯度同步开销

2.1 数据并行到底在并行什么

数据并行是我们最容易理解的一种拆法。每个设备（GPU）持有完整的一份模型副本，但喂给每张卡的数据是不同批次（batch）的一部分。例如总批次大小为128、用8张卡做数据并行，那么每张卡实际处理16条样本。每张卡独立计算梯度，然后通过通信把所有梯度聚合求平均，再用平均梯度更新各自持有的模型参数。

这里有个关键认知：数据并行并没有降低单卡显存对模型大小的要求——每张卡仍然要装下完整模型。它的核心收益是增加“吞吐量”和“每卡数据处理量”。你用8张卡跑，数据处理速度差不多能达到单卡的5~7倍（线性增长会受限于通信开销）。那数据并行适合什么场景？很简单：模型单卡放得下、但训练速度太慢、或者想把batch size扩大到单卡上限之外的情况。

现在大多数主流的分布式训练框架（比如深度学习框架内置的分布式数据并行机制）都默认走了这个路线。你要做的就是把数据加载器改成分布式采样器、把模型包一层分布式封装，然后在启动命令里告诉框架你有几张卡。理论上10分钟可以跑通。

2.2 梯度同步的通信账单：AllReduce是怎样工作的

数据并行的核心通信操作是一个叫 AllReduce 的集体通信原语。每张卡算完自己的梯度后，大家把梯度聚到一起，最终每张卡都拿到所有梯度之和或者平均值。

AllReduce的底层实现有不同算法，在节点内多卡通信时，常用的是点对点环状或树状算法；跨节点时则依赖网卡和高速网络。这里我不打算把每种算法都展开，而是强调一个所有做数据并行的人都要有的意识：通信量 = 模型参数量 × 梯度字节数 × 2（一次缩放、一次广播）。模型是10亿参数，梯度用FP32就是4字节，那么每步训练至少要有80GB的通信数据在设备之间流动（10亿×4×2=80GB）。这只是单次梯度同步的量。

所以，当你的训练速度提升不如预期时，别先怀疑代码写错了，先算一下你的通信账单。如果模型太大、每步训练时间太短而通信占比过高，那数据并行一定会遇到瓶颈。吞吐量上不去，有时候不是算力不够，是通信在拖后腿。

2.3 数据并行的关键超参：批次大小与学习率的关系

数据并行还有一个很多人容易忽略但影响极大的细节：总批次大小变了，学习率也要跟着调整。

单卡训练时你调好的学习率，原样搬到8卡数据并行时往往不灵。因为梯度平均的统计特性变了——更多的样本参与梯度估计，梯度的方差降低，最优点附近可以走更大的步子。实践上有个经验法则：线性缩放法则（linear scaling rule），即卡数增加几倍、批次扩大几倍，学习率大约也同步放大同样的倍数。比如单卡批次256、学习率0.001，换到8卡批次2048时，学习率可以先调到0.008左右起步。

但这也不是绝对的。批次过大后，模型收敛会遇到另一个问题：泛化性下降。大批次训练会让模型更容易收敛到尖锐极小值，测试集表现可能不如小批次。很多大模型预训练团队采用折中方案——批次增大但学习率增长不取满倍率，同时配合学习率预热（warmup）来稳定训练。我个人的经验是，先跑一个短时间的对比实验，用同样的总步数分别跑单卡基线和多卡基线，对比训练困惑度曲线的差异，再决定学习率的具体数值，不要盲目照搬任何经验公式。

3. 再拆模型：模型并行的三个层级与显存账本

3.1 朴素模型并行：按层切分，为什么效率垫底

当模型大到单卡放不下时，就得从模型本身动手。最直观的做法是朴素模型并行（也叫层并行）：把模型按层切成几段，每张卡负责一段。比如一个24层的Transformer，切成三块，卡0跑0~7层，卡1跑8~15层，卡2跑16~23层。

这样做的致命问题在于：流水线是串行的，同一时间只有一张卡在工作。前向计算时，卡0算完拿给卡1，卡1再拿给卡2；反向传播时又倒过来。除了各卡内部可以重叠一部分计算和通信，总体利用率很差。8张卡做层并行，实际加速可能只有1.5~2倍。你多花的卡钱变成了排队等待的队列。所以朴素模型并行只适合作为教学案例，或者在你完全没办法时的救急方案，正常规划训练时基本不用。

3.2 张量并行：把一层切成多块，通信昂贵但显存立省

张量并行是真正在“拆模型”核心机制上下工夫的方案。它的思路是把一个单独的算子（例如Transformer里的线性层或者注意力头的矩阵乘法）拆到多张卡上并行计算。一张卡的矩阵乘法是y = xW，张量并行下可以把W按行切成两块，分别放到两张卡上算一半，再用一次性 AllReduce 把结果合并。

这种拆法的显存账本好看：一张算不动的巨型参数矩阵，拆开后每张卡只存一半，显存压力瞬间减半，再配合更多卡还能继续拆。但代价是通信极频繁——一个 Transformer 层内部往往需要多次 AllReduce，一个批次里的每步训练都有几十上百次小型集体通信。所以张量并行在单机内部多卡时效果很好（卡间走NVLink等高速互联），跨节点时效果会大幅恶化。业内一般建议张量并行只在单机内做，跨节点的张量并行要么网络极好，要么干脆别碰。

3.3 流水线并行：把串行拆成流水，隐藏通信延迟

刚才说朴素层并行效率低，是因为同一时间只有一段在算。流水线并行用了一种很聪明的改进方式：把微批次（micro-batch）切开，让不同设备同时处理不同微批次的数据。本质上就是用一定程度的显存开销去换流水线的吞吐利用率。卡0在算第2个微批次时，卡1正在算第1个微批次的下游层，流水线被填满，设备利用率明显提升。

定义微批次数量时有个经典公式值得记住：理想状态下，流水线并行的吞吐上限约等于（微批次总数 + 流水线级数 - 1）/ 微批次总数，所以微批次数量越多，流水线越满。但这会让每个微批次的显存开销总和变大，因为多个微批次的中间激活值同时驻留在显存里。具体怎么选微批次数量，我一般从“设备数×16”起步，如果显存充足再往上涨，观察吞吐量变化。有一个普遍经验是：流水线并行的切分点要选在模型层与层之间依赖最松的地方，而 Transformer 结构天然适合，大部分团队按编码器/解码器阶段或按层块均分即可。

3.4 混合并行的通信拓扑与显存分配实战

谈完张量并行和流水线并行，可以把它们组合起来看了。现实中很少单独用某一种模型并行。常见做法是：先跨节点做流水线并行（因为跨节点通信最慢，让通信只发生在切层边界、频率最低），再在节点内部用张量并行（利用节点内高速互联），然后以上两者都是每组只负责模型的一个分片，在组之间再做数据并行，每个组可以拥有不同的数据批次。这就是所谓的“3D并行”。

举一个我实际搭过的配置为例：某团队要在8台机器、总共64张卡上跑一个百亿参数级别模型。整体压下来的方案是：流水线并行度设为8（跨8台机器），张量并行度设为2（单机内两张卡），数据并行度设为4（也就是有4个流水线副本并行跑不同批次）。这样组合完，张量并行组内通信都在节点内，流水线的跨节点通信每层只发生有限几次，数据并行的梯度同步也是较长周期的集体通信。整条链路里通信最频繁的，反而是节点内张量并行的 AllReduce，但它的数据量小、延迟极低，整体没有形成瓶颈。

显存分配上有一个通用估算思路：每张卡的显存 = 参数分片 + 梯度分片 + 优化器状态分片 + 激活值 + 通信缓冲区。前三个是“常驻”，激活值是动态的，最容易爆。如果你的模型偏大，建议优先选激活检查点（activation checkpointing）来砍激活值，它用一小部分重计算换显存，属于大模型训练的默认配置，真正能帮你把卡跑满的往往是这个而不是花哨的并行策略。

4. 策略选型与框架落地：什么场景选什么拆法的决策表

4.1 先回答三个问题，再选并行策略

很多人在并行策略上纠结半天，其实是没搞清楚自己的约束。我的建议是，做选择前先回答三个问题：

1. 你的模型单卡到底放不放得下？放得下就优先数据并行，最简单、收益最明确。
2. 你的模型是不是大到必须拆模型？如果需要拆，优先考虑流水线并行+张量并行组合，不要单独用某一种。
3. 你的硬件拓扑是什么？单机多卡和多机多卡的天花板完全不同。节点内通信带宽高、延迟低，适合张量并行；跨节点通信带宽有限，只适合低频通信的流水线并行、数据并行。

这张决策表是我在很多实际项目里反复验证过的，可以直接参考：

4.2 深度学习框架自带能力 vs 第三方训练框架

落地层面，工具选型同样重要。以最常见的深度学习框架为例，它自带分布式数据并行接口、张量并行接口和分布式检查点能力，很多中小规模项目其实不需要引入额外框架。

但如果你做的模型规模偏大，或者想省去手工切分模型的痛苦，就不得不看第三方框架了。现在主流的训练调度框架里，能力最丰富的是两类：一类是通用深度学习框架里的分布式能力（偏底层的弹性调度、分布式RPC），另一类是针对大模型做了深度优化、适合预训练和微调的专用框架（类似某种社区常用的并行训练工具包）。这两种各自的代表我不好直接点名，但可以用特征来描述：前者灵活、能精细控制每一层，但配置复杂、学习曲线陡峭；后者封装度高，ZeRO、张量并行、流水线并行往往都是一两行配置就自动切好，适合大多数业务团队。

我在多个项目的经验是：如果团队没有人专门写分布式底层代码，就不要硬啃前者。用封装度高的框架，把心思放在超参和数据质量上，收益更大。如果团队确实有底层高手、模型结构又特殊，那前者给你自由，值得投入。

4.3 从单机多卡起步的推荐步骤

很多时候群里有人问“我只有两台机器、八张卡，怎么开始分布式训练”，我的建议永远是从最小可运行版本起步，不要一上来就搞最复杂的组合拳：

1. 先跑通数据并行。把模型装进单卡能放下的最小版本，用官方数据并行接口跑起来，确认反向传播和梯度同步正常。
2. 加激活检查点。增大模型，开启激活检查点保住显存，观察训练吞吐量的变化。
3. 引入流水线并行。模型再大时，把模型按层切成两段，用微批次填充流水线，确认吞吐量没有下降1/2以上。
4. 最后再加张量并行。这一步只在节点内做，配合设置好通信组。加完观察每个Transformer层的通信热点。
5. 再做分片优化器。把优化器状态分散到全部设备上，这一步能显著降低显存峰值，代价是多一点通信。

每次加一个变量，跑一段确认结果正常，再加下一个。别一次全上，出了问题很难定位是并行切分还是通信拓扑的问题。

5. 通信瓶颈再把关：跨机网络、通信调度与吞吐量实测

5.1 跨机网络是大模型训练的最大变数

很多人本地单机跑分布式，吞吐量不错，一上多机就崩，大概率是跨机网络的锅。这里有个硬道理：节点内通信和跨节点通信，走的不是同一张网络，成本差了一个量级。节点内的 NVLink 之类互联带宽非常高、延迟极低；跨节点的网卡受限于带宽和路由延迟，哪怕用的是InfiniBand或高速网卡，延迟也远高于节点内。

所以规划混合并行时，通信频率最高的并行维度一定放在节点内。我见过一个实际案例：某团队在双机上做了张量并行度4的配置，两台机器各2张卡参与同一个Transformer层切分，结果训练速度比单机只快一点点，瓶颈全在网络。后来把张量并行度砍到2（单机内）、跨机改用流水线并行，吞吐量直接翻倍。

跨节点慢还有一个隐蔽原因——通信重叠不够。很多人以为AllReduce只是发数据，其实通信和计算可以重叠：当前层的反向梯度算完后，可以先发出去，同时继续算下一层。大多数框架默认能自动做这种重叠，但要检查环境变量和通信后端配置是否正确。

5.2 通信调度：异步与同步的数据并行差异

数据并行同步模式里有同步和数据并行与异步数据并行的区别。同步模式就是每步等待所有工作节点的梯度到齐再更新，严格保证一致性，训练确定性好，但慢卡或网络波动会拖住所有人。异步模式则是每个节点算完就更新，速度更快但会出现梯度滞后（staleness）问题，训练不稳定。

大模型预训练绝大多数用同步模式。异步多用于推荐系统这类大规模稀疏模型场景。我的建议是：除非你有充分理由，否则别在大模型训练上碰异步。训练不稳定时的排查负担，远大过那一点点速度增益。如果你确实要用异步，至少要做梯度裁剪、限制滞后程度等补偿手段。

5.3 用吞吐量实测数据检验策略选型是否合理

判断一套并行策略到底合不合理，不能靠感觉，得靠数据。训练吞吐量有两个常用指标：每秒处理的样本数，或者每秒处理的Token数（大模型预训练更常用）。你可以每隔一定步数记录日志，用总样本数除以训练总时长，得到有效吞吐量。注意这里要算墙钟时间，包括通信等待时间，不是纯粹的GPU计算时间。

我在调并行策略时有一个经验标准：在8卡节点内，把一个常规规模的模型从纯数据并行改成数据并行+激活检查点，吞吐量下降不应超过15~25%；加流水线并行后，设备有效利用率（模型FLOPs利用率，即MFU）不应低于40%。如果你的MFU只有20%上下，大概率是通信和计算没有重叠好，或者微批次数量太小，流水线没填满。

实测也经常遇到反直觉的情况：增加卡数后吞吐量不升反降。这时第一件事是确认是不是小批次问题——每卡批次太小，梯度同步的通信开销超过了新增算力带来的收益。数据并行的最低每卡批次建议是16条以上（图像或NLP均类似），低于这个值就要小心通信成本盖过计算收益。

6. 训练稳定性与调试技巧：看得出来问题，才能修得好问题

6.1 显存OOM不再随机：从激活值到通信缓冲区的排查清单

分布式训练常见的OOM，和单卡OOM的原因不大一样。单卡OOM往往确实是模型太大或批次太大，分布式OOM则经常是某个并行维度配置不当引发的连锁反应。

排查顺序我建议这样固定下来：

1. 看是不是激活值爆了：激活检查点是否开启？关闭了它就必然在深层模型上爆显存。
2. 看通信缓冲区：分布式框架为了通信会预分配显存缓冲区，配置不当会在通信开始前直接OOM。适当调小通信缓冲区大小，看是否解决。
3. 看优化器状态：用的是否为分片优化器（如ZeRO-2/3）？没做分片，一个几十亿参数模型的优化器状态可能占掉大半显存。
4. 看数据加载器：PyTorch类框架的数据加载器进程会占用CPU内存，某些配置下会把页面缓存和显存映射逼到极限。

另外，显存不均衡也是一个常见现象。张量并行下如果不对序列维度做均匀切分，有些卡会负载过重先爆，别的卡还有余量。解决思路是检查通信组内各卡的显存分配日志，看是否均匀。

6.2 梯度异常与训练崩溃的定位方法

训练崩溃是另一个高频问题，比OOM更让人抓狂，因为错误五花八门。我这里说一个我总结的高效定位路径：

• 先查NaN或Inf出现的位置：开启异常检测，它能定位到第一次出现NaN的层和关键张量，极大缩小排查范围。
• 再确认并行策略是否与模型结构冲突：比如对某些归一化层做张量并行时，如果切法不对，数值稳定性会出问题。业界在张量并行实现里通常对归一化层不做切分或做特殊处理，你如果手动切模型，务必遵守这一惯例。
• 最后看通信组配置是否正确：很多莫名崩溃其实是通信组（进程组）划分和实际物理设备不对应导致的。每次都检查一下全局进程组、各组设备的排序，尤其在多机多卡启动时，设备顺序错一位就会引发诡异的随机崩溃。

训练收敛性变差（loss不降或反而升高）则大概率不是代码问题，而是超参没配合好并行策略：批次变了学习率没变、或者批次太大导致噪声不足。这时候别去折腾代码，回头调超参。

6.3 日志与监控：如何用数据定位慢卡和网络抖动

分布式训练的调优无法离开监控日志。一个实用的做法是记录每张卡的以下指标：

• 计算时间占比和通信时间占比（每步分解）
• 通信库的耗时拆解（AllReduce、广播、梯度规约等）
• 吞吐量趋势变化
• 显存使用曲线

如果某张卡的计算时间明显长于其他卡，可能存在负载不均衡；如果通信时间随着步数增长而变慢，可能交换机或网络出现拥塞。慢卡问题还有一个经典原因——CPU数据加载不均匀，某些数据加载进程没有预取足够数据，导致GPU等数据。

现在很多训练框架自带了性能剖析工具，能直接把每步耗时细分到不同操作。我会在怀疑通信瓶颈时跑一次剖析，输出结果里往往直接能看到AllReduce耗时占比是不是已经超过30%。如果确认是通信瓶颈，再去调整并行策略，效率比盲猜高很多。

7. 进阶经验分享：几个不常见但很好使的细节优化

最后聊几个我在长期实操中觉得价值很高、但常规文档里很少单独拿出来讲的细节。

第一，序列并行值得了解。它其实是在张量并行基础之上，对激活值做进一步切分的技巧。Transformer里很多显存消耗其实来自长序列的激活值，序列并行把激活值也拆到多卡上，但不增加通信量，等于用同样的通信开销白捡一段显存。如果模型卡在激活值爆显存，而你已经开了激活检查点还是不够，序列并行很可能就是最后那根救命稻草。

第二，检查点（checkpoint）的保存策略要单独设计。分布式训练保存检查点不是简单地存模型权重，还涉及优化器状态、随机数生成器状态、数据加载器位置等。我见过很多人训练到一半崩溃，重启后发现要从头再来，就是因为检查点没保存优化器状态和一个关键的做法——用“只保存CPU、不保存GPU内存”的方式导出每个分片，否则恢复时会因为张量设备不匹配而失败。如果用的是封装度高的第三方框架，这些一般都能自动处理，但如果你手工实现分布式训练，这一点是必修课。

第三，不要低估数据加载的分布式化改造。数据并行的数据加载器如果用不好，跨卡会出现重复样本或漏样本。有很多团队做到了8卡，结果每个epoch的有效样本量反而不对，训练了很长时间才意识到。检查方法很简单：在启动训练时对每个数据分片打印首尾样本的索引，做一次人工核对。

第四，通信后端的选择要看硬件。单机多卡优先用适合GPU直接通信的后端，多机则根据网络协议选择。很多人默认配置跑着没事，但吞吐量就是差一截，回头一看是通信后端和硬件不匹配。这种排查成本很低，收益却非常直接。

大模型分布式训练这个圈子，策略、框架和硬件迭代都很快，但“拆数据、拆模型、再组合通信”这套底层逻辑短期内不会变。与其追求一步到位的最优配置，不如把每种拆法的通信成本和显存账本算清楚，再根据你的硬件和模型规模慢慢逼近。你踩过的每一个显存墙和通信瓶颈，都是在为下一次更大规模的训练积累经验。