1. 一个算法同学面对训练框架时的真实困惑先说个场景。你模型写得溜PyTorch 的nn.Module玩得飞起Loss 曲线调得也很漂亮。但有一天你要把一个 70B 的模型塞进训练集群打开训练框架的启动脚本看到这么一行--tensor-parallel-size 8 --pipeline-parallel-size 4 --data-parallel-size 2当场就有点懵。这三个数到底怎么影响训练为什么业界老说8 卡必须张量并行因为单卡放不下TP、DP、PP 这些缩写看文档每个字都认识合在一起完全不知道系统在干嘛。如果公司里用的是 MoE 模型又冒出 CP、EP头更大。这个系列本来就是写给我们团队里算法背景的同事的核心诉求就一句话绕过系统底层的那些晦涩概念直接用模型怎么被切开、数据怎么流动、每张卡在算什么这种视角把分布式训练这层窗户纸捅破。这一篇的目标是让你看完之后再看到任何训练框架的并行配置能自己推算出来每种并行策略各自解决了什么问题、通信开销大不大、适合什么场景。先说一个贯穿全文的判断标准大模型分布式训练的本质不是并行而是切分。显存放不下就切权重算力不够就切数据通信太贵就切流水线。五种并行策略——TP、DP、PP、CP、EP本质上是五种不同的切法。理解每种切法解决了什么问题胜过背一百遍概念定义。2. 先搞懂切分而不是并行五种策略的共同底层逻辑2.1 单卡训练为什么走到头了要明白为什么要切先看单卡训练一个大模型时会发生什么。假设你在训练一个 70B 参数的模型用 FP16 精度存储权重光权重本身就需要 70 × 10^9 × 2 字节 ≈ 140GB 显存。一张 H100 是 80GBA100 也一样权重都放不下更别提反向传播要存的中间激活值、优化器状态Adam 的 momentum 和 variance 又要吃掉好几份权重大小的空间。理论上可以开流水线式的计算把一部分权重挪到 CPU 再换进来也就是 offload但这样训练速度会掉得厉害。工程上一个朴素的解法就是一张卡放不下就多找几张卡每张卡放一部分。这就是并行切分的起点。2.2 切的三个维度数据、模型、序列用生活化的方式理解一个 Transformer 模型训练时存在三个可以切的维度数据维度每个 batch 里有 4096 条样本可以让 8 张卡各自处理 512 条最后把梯度合并。这是最容易想到的切法。模型维度一个 Transformer 有 80 层每张卡放 10 层或者一层里的权重矩阵很大切成几块让多张卡一起算一个 MatMul。这是纯靠堆卡解决显存/算力的方式。序列维度一条样本的序列长度有 128K单卡 attention 算不了就按序列长度切成四段每张卡算一段。这个切法近年越来越重要就是 CP上下文并行。还有一个特殊的维度专家维度。MoE 模型的专家天然可以放在不同卡上不同 token 路由到不同专家这就是 EP。严格说它是模型维度的一种但因为切分逻辑完全不同按 token 而不是按权重/层通常单独讨论。2.3 通信是切分的第一约束条件所有切分方案都绕不开通信代价。分布式训练里张量在卡之间搬来搬去是要花时间的这个时间往往比计算时间还长。写代码时你感受不到但在千卡集群上通信瓶颈会直接让显卡算力利用率掉到 30% 以下。理解五种并行策略时请始终带着两个问题这个策略每步训练需要通信多少数据通信频率高不高这两个问题的答案决定了该策略适合在什么硬件上跑机内 NVLink 高速互联还是机间万兆网络。并行策略切什么通信频率通信数据量适用场景DP 数据并行batch 样本每步一次梯度聚合与模型参数量成正比模型能塞进单卡TP 张量并行权重矩阵/张量维度每个 Transformer 层多次中量与 hidden size 相关模型太大需机内高速互联PP 流水线并行Transformer 层纵向切每个 micro-batch 边界小只需传 activation/梯度层数很多跨机部署CP 上下文并行序列长度维度每层 attention 多次与序列长度呈正相关长序列如 128K/1MEP 专家并行MoE 专家网络每个 token 路由时中量与 token 数量相关MoE 模型这张表建议先截个图后面每节都会反复回扣这张表的内容。3. DP数据并行——最简单的并行但通信量最容易超预期3.1 工作原理与生命周期数据并行Data Parallelism是所有人接触分布式训练的第一个概念。逻辑非常简单每张卡上都有一份完整的模型副本训练时把全局 batch 切成 N 份每张卡处理自己的 N 分之一。前向、反向各自独立完成后把梯度做一次全局同步AllReduce保证所有卡上的模型参数保持一致然后进入下一步。伪代码大概是这样的# 伪代码数据并行训练流程 for batch in dataloader: shards split(batch, num_gpus) # 把batch切成N份 grads [] for i, shard in enumerate(shards): output model(shard.to(device_i)) # 每张卡前向 loss loss_fn(output, target[i]) grad backward(loss) # 每张卡反向 grads.append(grad) averaged_grad all_reduce(mean, grads) # 同步梯度 optimizer.step(averaged_grad) # 更新参数注意几个关键点模型参数每张卡各自存一份所以如果模型有 70B数据并行需要至少 70B × 2 字节 × N 卡的显存总量成本线性增长。它解决的不是单卡放不下的问题而是单卡算不过来、训练太慢的问题。3.2 通信量的精确计算我见过太多算法同学低估 DP 的通信代价。以为数据并行就是每张卡各算各的没多少通信错了。每一步训练都要把梯度做一次全局 AllReduce通信的数据量是模型参数量乘以一个系数。以 70B 模型为例每个梯度是 FP32 精度很多框架用 FP32 做梯度通信以防精度损失梯度张量大小 参数量 × 4 字节 280GB。做一次 AllReduce 意味着每个 GPU 要发送约 280GB 数据实际因为 AllReduce 的 Ring 结构单卡发送量约等于梯度总量的两倍这里先简化。在 8 卡 NVLink 互联环境每步通信耗时约 1~3 秒但如果跨节点用万兆以太网这个时间直接爆炸到几十秒。所以大模型训练里DP 很少作为主力并行策略单独使用它通常和模型并行叠加先用 TP/PP 把模型切开让单卡模型变小然后再用 DP 加速。3.3 ZeRO 系列的边界要理清这里必须澄清一个高频误解ZeRO 不是数据并行它是数据并行之上的显存优化手段。DeepSpeed 的 ZeRO-1/2/3 会把优化器状态、梯度、甚至参数本身在 DP 的卡组间做切分。很多人把用 DeepSpeed 训练等同于数据并行这在概念上是不准确的。ZeRO-DP 本质上是数据并行 模型参数分片它的通信模式分区 AllReduce、通信与计算重叠都更接近模型并行。简单的判断方式如果训练脚本里配置了zero_optimization.stage 3那这个训练任务既在做数据并行也在做参数分片显存占用模式跟纯 DP 完全不同。方案每卡显存占用相对权重 W通信量纯 DPW 梯度 优化器状态每卡全量全量梯度 × 2ZeRO-1W 梯度 优化器状态/N全量梯度 × 2ZeRO-2W 梯度/N 优化器状态/N全量梯度 × 2ZeRO-3W/N 梯度/N 优化器状态/N参数 梯度通信量大增ZeRO-3 虽然显存省到极致但代价是每步需要额外通信模型参数实际训练吞吐往往比 ZeRO-2 低。工程上用 ZeRO-2 居多除非模型真的大到塞不进显存。4. TP张量并行——把一个 MatMul劈成四份4.1 为什么需要 TP权重矩阵的维度切分数据并行解决不了显存问题。一个 70B 模型权重就要 140GB就算用 16 张卡做数据并行每张卡还是需要 140GB 显存去存自己的那份完整权重。TPTensor Parallelism张量并行的思路完全不同不是每张卡存完整的权重而是把一个巨大的权重矩阵切成几块每张卡只存一块但合在一起仍然能算出一个完整的 MatMul。线性层Y X W其中 X 的 shape 是[batch, hidden]W 的 shape 是[hidden, out]。切法有两种列并行把 W 按列切成[hidden, out/n]的 N 块每张卡算X W_i得到[batch, out/n]的部分结果拼起来得到完整输出。对应到 Transformer 的 MLP 第一层和 Attention 的 QKV 投影。行并行把 W 按行切成[hidden/n, out]的 N 块每张卡有一个 X 的切片各自算X_i W_i然后 Add 得到[batch, out]。对应到 MLP 第二层和 Attention 的 Output 投影。4.2 Transformer 里的 TP 完整流程拿标准 Transformer 的一层举例。输入 X 到了这一层后要做 Attention 的 QKV 投影、Attention 输出投射、MLP 的第一层 GELU/ SiLU 和 MLP 输出投射。TP 的经典切分方式Megatron-LM 方案是Q、K、V 三个投影合并成一个大的 QKV 权重矩阵做列并行每张卡算出部分 QKV。Attention 的计算QK^T、softmax、V在部分头上各自完成因为每个 head 是独立的。Attention 的 Output 投影做成行并行把各卡的部分输出 Add 起来。MLP 的第一层hidden → 4*hidden做列并行加激活函数。MLP 的第二层4*hidden → hidden做行并行各卡 Add。这个过程中真正需要的通信只有两处一次是 Attention Output 投影的行并行之后一次是 MLP 第二层行并行之后。而且这里的行并行输出只需要一次 All-Reduce不是每算一步就通信一次。所以 Megatron 设计得很精巧把通信点压到最少同时让每张卡的算力尽量吃满。4.3 TP 的全部秘密都在通信延迟TP 看起来不复杂但它对整个集群硬件的要求极其苛刻。原因在于每个 Transformer 层都有至少 2 次 AllReduce 通信Attention 输出 1 次 MLP 输出 1 次而模型有几十层每层都要来一遍叠加起来通信频率极高。假设 hidden size 为 8192TP8那么 Attention 输出投影的 shape 是[8192/8, 8192]一次 AllReduce 的数据量大约是batch × 8192 × 4 字节。虽然单次数据量不算特别大但频率极高所以TP 的通信要求是低延迟、高带宽。NVLink 的单卡带宽 900GB/s跨机走 InfiniBand 大概 200~400Gb/s仍差一个数量级。这正是为什么业界通行规则是TP 不跨机一个 TP 组基本被限制在一个节点内8 卡 A100/H100 用 NVLink 全互联。我之前在一个项目里亲眼见过有人做 64B 模型把 TP 设成 16也就是说一个 TP 组跨了两台机器结果训练吞吐直接掉了将近一半。原因就是跨机的 AllReduce 延迟让 GPU 在等待通信中空转。排查到最后发现启动脚本里--tensor-parallel-size和节点内卡数不匹配。这个坑很典型后面选型部分再详细说。4.4 算法同学最需要知道的 TP 细节对算法同学来说TP 不需要掌握到能手写通信代码的程度但有几点必须形成反射TP 是算力与显存共享型切分适合单卡放不下权重、又需要极低通信延迟的场景。TP 不解决训练吞吐的线性扩展问题因为每层都有通信等待TP 越大效率越低。一般 TP 不超过 8。TP 与 DP 叠加时先满足 TP 的硬件约束同节点再套 DP 扩展。如果看到TP8, DP4含义是一个 8 卡 TP 组内共享模型权重4 个 TP 组各自处理不同 batch 数据。5. PP流水线并行——用 micro-batch 填满 bubble5.1 按层切分能省显存但不能省时间PPPipeline Parallelism流水线并行是三种经典并行里算法同学理解门槛最低的一个Transformer 有很多层把第 1~20 层放到 GPU 021~40 层放到 GPU 1以此类推。每张卡只需要存自己那一段的权重和中间激活。但这里有个致命问题前向计算是有依赖的第 2 层要等第 1 层算完才能开始。如果老老实实地一层一层传那同一时刻只有一张卡在干活其他卡全在等着利用率就是 1/N。这就违背了并行提高速度的初衷。5.2 micro-batch 与 bubble 率解决方案是引入 micro-batch微批次。把一个大 batch 切成几十个很小的 micro-batch像工厂流水线一样依次送入。假设有 4 段流水线4 张卡、16 个 micro-batch理想状态下第 1 个 micro-batch 在 GPU0 算完后传给 GPU1GPU0 立刻开始第 2 个 micro-batch。这样每个 stage 在大部分时间都在工作只有流水线刚开始填充和末尾排空的时候有空闲这个空闲比例叫 bubble 率。数学上GPipe 调度的 bubble 率 ≈ (P-1)/(MP-1)其中 P 是流水线段数M 是 micro-batch 数量。micro-batch 越多bubble 越小但 micro-batch 太小的代价是设备利用率降低、调度开销变大。现在主流的调度方式是 1F1Bone-forward-one-backward来自 PipeDream。它让每个 stage 交替执行一个 micro-batch 的前向和一个 micro-batch 的反向内存占用比 GPipe 均衡很多工程上基本是标配。如果看到框架配置里有个--num-micro-batches或者类似参数就是在调这个。5.3 PP 的通信开销为什么很小PP 的通信量是五种策略里最小的。每个 stage 之间只需要传递两样东西前向时传给下一段的 activation tensor、反向时传回上一段的梯度 tensor。这两个 tensor 的 shape 和 batch size × hidden size 相关跟模型总参数量没关系。一个 70B 模型切成 4 段每段 17.5B 参数一次前向传的 activation 也就几 MB 到几十 MB。所以 PP 完全可以直接跨机部署对网络带宽要求远低于 TP。这就是为什么大型训练集群里PP 经常被用来做跨机器扩展同一台机器内用 TP机器之间用 PP。5.4 什么时候该用 PP从显存和带宽角度看PP 是最便宜的并行策略但它有一个算法同学必须知道的短板PP 会改变梯度统计性质。由于是切成 micro-batch 逐步算的BatchNorm 之类的操作在这种模式下行为会变得不同。虽然 Transformer 用 LayerNorm 基本不受影响但如果你自定义了依赖全局统计信息的模块就要小心。另外PP 的负载不均衡问题比较明显每段层的计算量可能有差异比如 embed 层、最后的输出层通常比中间层轻需要做图层分配partition的权衡。实用建议单机 8 卡优先用 TP 而不是 PP因为 TP 通信延迟低、负载均衡好。跨机多节点时再考虑 PP 切分模型层。如果模型在 7B~13B 这个区间单卡 A100/H100 已经能放下权重那连 TP 都可以省直接纯 DP 加 ZeRO 就足够了。6. CP上下文并行——长序列的专用武器6.1 长序列为什么会让前面所有并行策略失效一般算法同学在训练 2K/4K 上下文长度的模型时几乎不会遇到 CP 这个名词。但当你想训练一个 128K 甚至 1M 上下文长度的模型时Attention 的显存和时间复杂度都会跟着序列长度平方级增长Full Attention 情况下。举个例子hidden size 8192序列长度 128K单层 Attention 的中间激活就达到128K × 128K的注意力矩阵以 FP16 计算一次存储需要 32GB单卡根本扛不住。DP 切数据没用因为一条样本的序列就不能拆开TP 切权重也没用因为这里卡住的是 activation 和 attention 矩阵本身。这时候必须引入一个新维度——按序列长度切分。6.2 CP 的原理切序列 Ring AttentionCPContext Parallelism上下文并行把一条样本的序列长度切成 N 段每张卡负责一段。单看每一段attention 的 Q 和本地的 K/V 可以做局部计算但每个 token 要 attend 到全序列的 token所以需要一种机制把其他卡上的 K/V 拿过来。工程上最常用的实现是 Ring Attention把 N 张卡排成环状每张卡只持有一段 K/V通过环形传递轮流把其他卡上的 K/V 传到自己这一侧完成完整 attention 计算。这本质上是通信换显存的策略付出的代价是多次点对点通信通信量随序列长度线性增长而不是平方增长。另一种实现方案是异步 AllGather在计算当前分块的 attention 时预先去取下一分块的 K/V。通信与计算重叠延迟能被压得很低但实现复杂度比 Ring 高不少。6.3 CP 与 TP/DP 的区别和组合CP 与 TP 看着有点像——都是把一层的计算拆到多卡上。但切分维度完全不同TP 切的是权重矩阵的列或行每张卡做的是同一个 token 的完整 hidden 表示的一部分。CP 切的是序列维度每张卡上有一批完整的 token 数据算的是这些 token 的局部 Q、K、V只是 attention 时要跨卡拿 K/V。一个实用的视角TP 适合短序列大模型CP 适合长序列模型。当序列长度超过 32K 时CP 几乎是必须的。当前很多长上下文模型的训练配置是TP8 CP88 卡切权重序列再切 8 份两层叠加把 attention 有效序列长度降到单卡的 1/8。在代码层面CUDA 上通常用flash_attention或ring_attention内核来做 CP 的实现支撑。如果你只是用训练框架跑模型CP 一般表现为一个类似--context-parallel-size的启动参数但理解了它是怎么切序列的你才会明白为什么它要求通信拓扑是环形的、为什么通信量随序列变长而变多、为什么短序列任务不必开 CP切多了反而通信占比上升、更慢。7. EP专家并行——MoE 模型的通信换稀疏7.1 MoE 模型带来的新切分需求MoEMixture of Experts混合专家是目前千亿级模型的主流架构思路模型的大部分参数集中在若干专家网络MLP里每个 token 只激活其中一小部分专家。比如一个 8 专家 Top-2 的 MoE每个 token 只走 2 个专家的 MLP计算量大幅降低但参数量维持巨大。但这里有个工程难题slot 层的专家数量如果少比如 8 个放在一张卡里没问题如果专家数量多比如 128 个单卡的显存装不下全部专家权重。这时候有两种做法把专家切到多张卡上每卡放一部分专家这就是 EPExpert Parallelism专家并行。每卡放全部专家但只路由激活其中一部分这是单纯的 MoE 推理不叫 EP。7.2 EP 的工作原理与通信模式EP 的训练流程可以用一段伪代码示意# 伪代码MoE EP 训练流程 # 1. 每张卡的 transformer 层attention 等独立计算 # 2. gate路由计算每个 token 被分配到哪个专家 # 3. token 需要根据路由结果 迁移到对应专家所在的卡上 # 4. 专家计算完后把 token 表示再 all2all 送回原卡 # 5. 继续后续的网络层计算 # 核心通信all2all每张卡与每张卡之间都有数据交换 dispatched_tokens all2all(tokens, routes) # 把 token 送去对应的专家设备 expert_output expert_forward(dispatched_tokens) combine_result all2all(expert_output, routes) # 把结果返回原设备关键点在那一对all2all操作token 需要根据路由结果实际移动到对应专家的卡上算完后再送回来。这个通信模式是全对全的跟 DP 的 AllReduce、TP 的 Ring 都不一样网络压力通常很大。工程上为了减少 token 搬运量会尽量让 token 的迁移发生在同一节点内所以EP 往往与 TP 混合使用比如 8 张卡组成一个 TP 组每个 TP 组内做张量并行共享 attention 层参数但专家分布在多个 TP 组之间。7.3 EP 与 DP、TP 的组合逻辑行业内典型的大规模 MoE 模型分层方案是普通 attention 层用 TP 并行专家层用 EP 并行外部再用 DP 扩展数据。也就是说一张卡上不一定同时存 attention 权重和所有专家权重而是attention 归 attention 的并行、专家归专家的并行通过灵活的设备映射把两类参数安排到不同卡上。对算法同学来说EP 需要形成两个认知EP 的存在让 MoE 模型即使参数量巨大也能保持单次 forward 的计算量可控。因为每个 token 只激活少数专家计算量与激活参数量成正比而不是总参数量。EP 的通信与路由质量直接挂钩。如果路由过于均匀token 在各卡间交换频繁如果路由太集中某个专家过热对应卡会过载形成热点。所以 MoE 训练通常要加负载均衡损失load balancing loss来约束路由让各专家负载尽量均匀。这里有个很实际的经验EP 的专家数量一般取设备数的整数倍比如 64 个专家放在 8 张卡上每张卡 8 个专家这样负载划分比较干净。如果专家数除以设备数除不尽负载不均匀会直接影响吞吐。8. 组合拳实操70B 模型到底该怎么分配8.1 先算显存再定并行策略我给算法同学的建议永远是拿到一个模型先算清楚单卡能不能放下权重、优化器状态、中间激活再决定用什么并行策略。举个 70B 模型训练的例子。70B FP16 权重 140GB如果用 Adam 优化器需要额外存 FP32 master weight140GB、momentum140GB、variance140GB优化器状态合计 420GB。梯度本身还要 140GB可即时释放。训练一个 70B 模型总显存需求粗略在 700GB 以上这还不算 activation。A100 80G 单卡完全没戏所以必须上并行。常见组合配置显存视角通信视角推荐度8×80GTP8权重分片到每卡 17.5GB优化器分片后勉强放下低延迟 NVLink 内通信显存够但算力可能不够适合推理32×80GTP8 PP4TP 内 8 卡共享权重PP 分 4 段TP 机内 PP 机间训练标准打法32×80GTP8 DP4ZeRO-2每 DP 组有完整模型经 TP 切分后优化器状态跨 DP 组切TP 机内 ZeRO 梯度 AllReduce工程实现简单扩展性好64×80GTP8 PP8 DP8三层并行叠加3D 并行TP 机内PP 机间DP 全局大规模集群的常规配置8.2 3D 并行DPTPPP的经典组合次序业界训练大模型的经典方案就是 Megatron-Deepspeed 那套3D 并行。设备分配逻辑通常是先按 TP8 组成一个节点内的张量并行组再在多个节点间按 PP 切层最后在整集群上做 DP 扩展。用大白话解释这套组合拳每一批数据会被复制成 DP 份每个数据副本在一条TPPP 流水线上从头流到尾流水线的每一站stage内部又用 TP 把权重和计算拆到一张节点内的 8 张卡上。这个结构的启动参数看起来像这样--tensor-parallel-size 8 \ --pipeline-parallel-size 8 \ --data-parallel-size 4 \含义是总共 8×8×4 256 张卡其中每 8 张卡内做张量并行8 个 TP 组串成一条 8 段流水线4 条完整流水线并行处理 4 份数据。这是目前工程上最常用的套娃结构。8.3 套娃结构下的显存与效率平衡组合策略里有个重要经验并行的层数越多真正通信开销越低的是 PP真正压显存的是 TP提高扩展效率的是 DP但三者加在一起时通信拓扑变得复杂调试难度大增。经验法则是模型权重超过单卡显存 1.5 倍时需要 TP 或 PP。TP 优先用于提速PP 优先用于跨机部署。DP 负责把整体吞吐打上去但要小心 ZeRO 阶段的通信开销。最后再强调一次TP 不跨机。这是 3D 并行配置里最容易被忽略的约束。在 8 卡 A100 节点上把--tensor-parallel-size设成超过 8一定会跨节点通信性能崩塌基本是必然的。很多所谓为什么我配了 3D 并行比单机还慢的问题追根溯源都是这个原因。9. 算法同学最容易踩的五个认知误区9.1 误区一并行越多越快千万别以为并行维度越全、并行度越大训练就一定越快。并行度增大后通信占比是线性甚至超线性增长的。一个 70B 模型从 TP8 扩展到 TP16实际吞吐可能不升反降因为多出来的 8 卡在大量时间里都在等通信。判断是不是该扩并行度的正确姿势看训练日志里的 GPU 利用率Compute Utilization。如果利用率低于 85%先检查是不是通信等待在拖后腿而不是盲目加压并行度。9.2 误区二把梯度同步当作 DP 的全部DP 不仅仅是同步梯度这么简单。在多机多卡环境下梯度 AllReduce 的实现Ring-AllReduce vs 树形 AllReduce会直接影响扩展比ZeRO 的分区通信也与 DP 的梯度同步各不相同。真正理解 DP 的关键在于谁的梯度、同步给谁、多大体量、多久同步一次。这些细节决定了 DP 是否适合你的模型规模。9.3 误区三TP 和 PP 都叫模型并行所以一样完全不是一回事。TP 是一层模型的多卡并行计算PP 是不同模型层在不同卡上串行计算。TP 的通信频率是每层多次PP 的通信频率是每若干层一次。这也是为什么 TP 必须机内 NVLink 而 PP 可以走机间网络。如果搞反了配置出来的训练集群通信开销会直接爆炸。举个场景如果有人在 8 卡节点上配置 PP8、TP1那么每个节点只有一层模型跨节点传 activation 非常频繁性能会很差。正确做法通常是每节点内先 TP节点间再 PP。9.4 误区四长序列训练直接靠大显存硬扛不少人觉得我的卡显存大序列长点没关系。但 attention 的显存与序列长度是平方关系序列从 8K 提升到 32K光是 attention 输出 buffer 就涨 16 倍。与其压榨单卡显存不如把序列切给多张卡做 CP同时配合 attention 内核优化FlashAttention 等压缩中间结果。CP 与 FlashAttention 是互补的不是替代关系。9.5 误区五MoE 模型用 DP 就完事了如果只是纯 DP 跑 MoE每张卡都要保存全部专家权重MoE 模型的显存优势直接浪费而且每个 token 只激活部分专家DP 复制完整模型等于白白浪费显存。MoE 模型必须配 EP 才能把参数多但计算少的架构优势发挥出来。一个常见的折中方案是EPTP混合attention 部分走 TP专家部分走 EP这样小规模集群也能训练千亿 MoE。如果你开始做 MoE 训练建议从这种混合配置起步。10. 一个实用清单拿到模型后该按什么顺序决定并行方案写到最后给一套我在实际工程里反复使用的决策流程算法同学可以当 checklist 用算显存模型参数量 × 2FP16 权重 优化器状态约 6~12 倍参数量看优化器 activation 估算判断单卡能不能放下。选 TP 粒度如果放不下优先给 TP 设成与节点内卡数相同通常 8让权重先被切开。选 PP 粒度如果单节点内 TP8 显存仍然不够或要扩展到多节点用 PP 把模型层切到多个节点上。PP 切分数一般等于节点数或节点数整数倍。选 DP 粒度模型结构确定后剩下的设备全部做 DP配合 ZeRO 来抠显存。长序列检查序列长度超过 32K 时额外开 CPCP 的大小取 2 的幂。MoE 检查模型里有 MoE 层把专家部分单独用 EP 切分并与 TP 组的位置对齐。盯监控启动训练后第一件事看 GPU 利用率和通信等待时间而不是看 loss 是否下降。如果利用率不高回头调整并行度。我在多个项目里用这套流程排障能解决 80% 以上的训练起不来得不到预期吞吐问题。剩下的 20% 通常出在数据加载、存储 IO 或框架版本差异上那就不是并行策略本身的问题了。最后再分享一个个人体会分布式训练的并行策略归根结底是在显存预算、算力预算、通信预算三者之间做取舍。算法同学习惯了只看模型结构和 loss但一旦模型上了规模这三个预算就会成为真正的约束。把五种并行策略的切分逻辑装进脑子里以后不管是读框架源码、调训练参数还是跟 infra 团队沟通都会顺畅很多。
分布式训练并行策略详解：TP、DP、PP、CP、EP怎么选？
1. 一个算法同学面对训练框架时的真实困惑先说个场景。你模型写得溜PyTorch 的nn.Module玩得飞起Loss 曲线调得也很漂亮。但有一天你要把一个 70B 的模型塞进训练集群打开训练框架的启动脚本看到这么一行--tensor-parallel-size 8 --pipeline-parallel-size 4 --data-parallel-size 2当场就有点懵。这三个数到底怎么影响训练为什么业界老说8 卡必须张量并行因为单卡放不下TP、DP、PP 这些缩写看文档每个字都认识合在一起完全不知道系统在干嘛。如果公司里用的是 MoE 模型又冒出 CP、EP头更大。这个系列本来就是写给我们团队里算法背景的同事的核心诉求就一句话绕过系统底层的那些晦涩概念直接用模型怎么被切开、数据怎么流动、每张卡在算什么这种视角把分布式训练这层窗户纸捅破。这一篇的目标是让你看完之后再看到任何训练框架的并行配置能自己推算出来每种并行策略各自解决了什么问题、通信开销大不大、适合什么场景。先说一个贯穿全文的判断标准大模型分布式训练的本质不是并行而是切分。显存放不下就切权重算力不够就切数据通信太贵就切流水线。五种并行策略——TP、DP、PP、CP、EP本质上是五种不同的切法。理解每种切法解决了什么问题胜过背一百遍概念定义。2. 先搞懂切分而不是并行五种策略的共同底层逻辑2.1 单卡训练为什么走到头了要明白为什么要切先看单卡训练一个大模型时会发生什么。假设你在训练一个 70B 参数的模型用 FP16 精度存储权重光权重本身就需要 70 × 10^9 × 2 字节 ≈ 140GB 显存。一张 H100 是 80GBA100 也一样权重都放不下更别提反向传播要存的中间激活值、优化器状态Adam 的 momentum 和 variance 又要吃掉好几份权重大小的空间。理论上可以开流水线式的计算把一部分权重挪到 CPU 再换进来也就是 offload但这样训练速度会掉得厉害。工程上一个朴素的解法就是一张卡放不下就多找几张卡每张卡放一部分。这就是并行切分的起点。2.2 切的三个维度数据、模型、序列用生活化的方式理解一个 Transformer 模型训练时存在三个可以切的维度数据维度每个 batch 里有 4096 条样本可以让 8 张卡各自处理 512 条最后把梯度合并。这是最容易想到的切法。模型维度一个 Transformer 有 80 层每张卡放 10 层或者一层里的权重矩阵很大切成几块让多张卡一起算一个 MatMul。这是纯靠堆卡解决显存/算力的方式。序列维度一条样本的序列长度有 128K单卡 attention 算不了就按序列长度切成四段每张卡算一段。这个切法近年越来越重要就是 CP上下文并行。还有一个特殊的维度专家维度。MoE 模型的专家天然可以放在不同卡上不同 token 路由到不同专家这就是 EP。严格说它是模型维度的一种但因为切分逻辑完全不同按 token 而不是按权重/层通常单独讨论。2.3 通信是切分的第一约束条件所有切分方案都绕不开通信代价。分布式训练里张量在卡之间搬来搬去是要花时间的这个时间往往比计算时间还长。写代码时你感受不到但在千卡集群上通信瓶颈会直接让显卡算力利用率掉到 30% 以下。理解五种并行策略时请始终带着两个问题这个策略每步训练需要通信多少数据通信频率高不高这两个问题的答案决定了该策略适合在什么硬件上跑机内 NVLink 高速互联还是机间万兆网络。并行策略切什么通信频率通信数据量适用场景DP 数据并行batch 样本每步一次梯度聚合与模型参数量成正比模型能塞进单卡TP 张量并行权重矩阵/张量维度每个 Transformer 层多次中量与 hidden size 相关模型太大需机内高速互联PP 流水线并行Transformer 层纵向切每个 micro-batch 边界小只需传 activation/梯度层数很多跨机部署CP 上下文并行序列长度维度每层 attention 多次与序列长度呈正相关长序列如 128K/1MEP 专家并行MoE 专家网络每个 token 路由时中量与 token 数量相关MoE 模型这张表建议先截个图后面每节都会反复回扣这张表的内容。3. DP数据并行——最简单的并行但通信量最容易超预期3.1 工作原理与生命周期数据并行Data Parallelism是所有人接触分布式训练的第一个概念。逻辑非常简单每张卡上都有一份完整的模型副本训练时把全局 batch 切成 N 份每张卡处理自己的 N 分之一。前向、反向各自独立完成后把梯度做一次全局同步AllReduce保证所有卡上的模型参数保持一致然后进入下一步。伪代码大概是这样的# 伪代码数据并行训练流程 for batch in dataloader: shards split(batch, num_gpus) # 把batch切成N份 grads [] for i, shard in enumerate(shards): output model(shard.to(device_i)) # 每张卡前向 loss loss_fn(output, target[i]) grad backward(loss) # 每张卡反向 grads.append(grad) averaged_grad all_reduce(mean, grads) # 同步梯度 optimizer.step(averaged_grad) # 更新参数注意几个关键点模型参数每张卡各自存一份所以如果模型有 70B数据并行需要至少 70B × 2 字节 × N 卡的显存总量成本线性增长。它解决的不是单卡放不下的问题而是单卡算不过来、训练太慢的问题。3.2 通信量的精确计算我见过太多算法同学低估 DP 的通信代价。以为数据并行就是每张卡各算各的没多少通信错了。每一步训练都要把梯度做一次全局 AllReduce通信的数据量是模型参数量乘以一个系数。以 70B 模型为例每个梯度是 FP32 精度很多框架用 FP32 做梯度通信以防精度损失梯度张量大小 参数量 × 4 字节 280GB。做一次 AllReduce 意味着每个 GPU 要发送约 280GB 数据实际因为 AllReduce 的 Ring 结构单卡发送量约等于梯度总量的两倍这里先简化。在 8 卡 NVLink 互联环境每步通信耗时约 1~3 秒但如果跨节点用万兆以太网这个时间直接爆炸到几十秒。所以大模型训练里DP 很少作为主力并行策略单独使用它通常和模型并行叠加先用 TP/PP 把模型切开让单卡模型变小然后再用 DP 加速。3.3 ZeRO 系列的边界要理清这里必须澄清一个高频误解ZeRO 不是数据并行它是数据并行之上的显存优化手段。DeepSpeed 的 ZeRO-1/2/3 会把优化器状态、梯度、甚至参数本身在 DP 的卡组间做切分。很多人把用 DeepSpeed 训练等同于数据并行这在概念上是不准确的。ZeRO-DP 本质上是数据并行 模型参数分片它的通信模式分区 AllReduce、通信与计算重叠都更接近模型并行。简单的判断方式如果训练脚本里配置了zero_optimization.stage 3那这个训练任务既在做数据并行也在做参数分片显存占用模式跟纯 DP 完全不同。方案每卡显存占用相对权重 W通信量纯 DPW 梯度 优化器状态每卡全量全量梯度 × 2ZeRO-1W 梯度 优化器状态/N全量梯度 × 2ZeRO-2W 梯度/N 优化器状态/N全量梯度 × 2ZeRO-3W/N 梯度/N 优化器状态/N参数 梯度通信量大增ZeRO-3 虽然显存省到极致但代价是每步需要额外通信模型参数实际训练吞吐往往比 ZeRO-2 低。工程上用 ZeRO-2 居多除非模型真的大到塞不进显存。4. TP张量并行——把一个 MatMul劈成四份4.1 为什么需要 TP权重矩阵的维度切分数据并行解决不了显存问题。一个 70B 模型权重就要 140GB就算用 16 张卡做数据并行每张卡还是需要 140GB 显存去存自己的那份完整权重。TPTensor Parallelism张量并行的思路完全不同不是每张卡存完整的权重而是把一个巨大的权重矩阵切成几块每张卡只存一块但合在一起仍然能算出一个完整的 MatMul。线性层Y X W其中 X 的 shape 是[batch, hidden]W 的 shape 是[hidden, out]。切法有两种列并行把 W 按列切成[hidden, out/n]的 N 块每张卡算X W_i得到[batch, out/n]的部分结果拼起来得到完整输出。对应到 Transformer 的 MLP 第一层和 Attention 的 QKV 投影。行并行把 W 按行切成[hidden/n, out]的 N 块每张卡有一个 X 的切片各自算X_i W_i然后 Add 得到[batch, out]。对应到 MLP 第二层和 Attention 的 Output 投影。4.2 Transformer 里的 TP 完整流程拿标准 Transformer 的一层举例。输入 X 到了这一层后要做 Attention 的 QKV 投影、Attention 输出投射、MLP 的第一层 GELU/ SiLU 和 MLP 输出投射。TP 的经典切分方式Megatron-LM 方案是Q、K、V 三个投影合并成一个大的 QKV 权重矩阵做列并行每张卡算出部分 QKV。Attention 的计算QK^T、softmax、V在部分头上各自完成因为每个 head 是独立的。Attention 的 Output 投影做成行并行把各卡的部分输出 Add 起来。MLP 的第一层hidden → 4*hidden做列并行加激活函数。MLP 的第二层4*hidden → hidden做行并行各卡 Add。这个过程中真正需要的通信只有两处一次是 Attention Output 投影的行并行之后一次是 MLP 第二层行并行之后。而且这里的行并行输出只需要一次 All-Reduce不是每算一步就通信一次。所以 Megatron 设计得很精巧把通信点压到最少同时让每张卡的算力尽量吃满。4.3 TP 的全部秘密都在通信延迟TP 看起来不复杂但它对整个集群硬件的要求极其苛刻。原因在于每个 Transformer 层都有至少 2 次 AllReduce 通信Attention 输出 1 次 MLP 输出 1 次而模型有几十层每层都要来一遍叠加起来通信频率极高。假设 hidden size 为 8192TP8那么 Attention 输出投影的 shape 是[8192/8, 8192]一次 AllReduce 的数据量大约是batch × 8192 × 4 字节。虽然单次数据量不算特别大但频率极高所以TP 的通信要求是低延迟、高带宽。NVLink 的单卡带宽 900GB/s跨机走 InfiniBand 大概 200~400Gb/s仍差一个数量级。这正是为什么业界通行规则是TP 不跨机一个 TP 组基本被限制在一个节点内8 卡 A100/H100 用 NVLink 全互联。我之前在一个项目里亲眼见过有人做 64B 模型把 TP 设成 16也就是说一个 TP 组跨了两台机器结果训练吞吐直接掉了将近一半。原因就是跨机的 AllReduce 延迟让 GPU 在等待通信中空转。排查到最后发现启动脚本里--tensor-parallel-size和节点内卡数不匹配。这个坑很典型后面选型部分再详细说。4.4 算法同学最需要知道的 TP 细节对算法同学来说TP 不需要掌握到能手写通信代码的程度但有几点必须形成反射TP 是算力与显存共享型切分适合单卡放不下权重、又需要极低通信延迟的场景。TP 不解决训练吞吐的线性扩展问题因为每层都有通信等待TP 越大效率越低。一般 TP 不超过 8。TP 与 DP 叠加时先满足 TP 的硬件约束同节点再套 DP 扩展。如果看到TP8, DP4含义是一个 8 卡 TP 组内共享模型权重4 个 TP 组各自处理不同 batch 数据。5. PP流水线并行——用 micro-batch 填满 bubble5.1 按层切分能省显存但不能省时间PPPipeline Parallelism流水线并行是三种经典并行里算法同学理解门槛最低的一个Transformer 有很多层把第 1~20 层放到 GPU 021~40 层放到 GPU 1以此类推。每张卡只需要存自己那一段的权重和中间激活。但这里有个致命问题前向计算是有依赖的第 2 层要等第 1 层算完才能开始。如果老老实实地一层一层传那同一时刻只有一张卡在干活其他卡全在等着利用率就是 1/N。这就违背了并行提高速度的初衷。5.2 micro-batch 与 bubble 率解决方案是引入 micro-batch微批次。把一个大 batch 切成几十个很小的 micro-batch像工厂流水线一样依次送入。假设有 4 段流水线4 张卡、16 个 micro-batch理想状态下第 1 个 micro-batch 在 GPU0 算完后传给 GPU1GPU0 立刻开始第 2 个 micro-batch。这样每个 stage 在大部分时间都在工作只有流水线刚开始填充和末尾排空的时候有空闲这个空闲比例叫 bubble 率。数学上GPipe 调度的 bubble 率 ≈ (P-1)/(MP-1)其中 P 是流水线段数M 是 micro-batch 数量。micro-batch 越多bubble 越小但 micro-batch 太小的代价是设备利用率降低、调度开销变大。现在主流的调度方式是 1F1Bone-forward-one-backward来自 PipeDream。它让每个 stage 交替执行一个 micro-batch 的前向和一个 micro-batch 的反向内存占用比 GPipe 均衡很多工程上基本是标配。如果看到框架配置里有个--num-micro-batches或者类似参数就是在调这个。5.3 PP 的通信开销为什么很小PP 的通信量是五种策略里最小的。每个 stage 之间只需要传递两样东西前向时传给下一段的 activation tensor、反向时传回上一段的梯度 tensor。这两个 tensor 的 shape 和 batch size × hidden size 相关跟模型总参数量没关系。一个 70B 模型切成 4 段每段 17.5B 参数一次前向传的 activation 也就几 MB 到几十 MB。所以 PP 完全可以直接跨机部署对网络带宽要求远低于 TP。这就是为什么大型训练集群里PP 经常被用来做跨机器扩展同一台机器内用 TP机器之间用 PP。5.4 什么时候该用 PP从显存和带宽角度看PP 是最便宜的并行策略但它有一个算法同学必须知道的短板PP 会改变梯度统计性质。由于是切成 micro-batch 逐步算的BatchNorm 之类的操作在这种模式下行为会变得不同。虽然 Transformer 用 LayerNorm 基本不受影响但如果你自定义了依赖全局统计信息的模块就要小心。另外PP 的负载不均衡问题比较明显每段层的计算量可能有差异比如 embed 层、最后的输出层通常比中间层轻需要做图层分配partition的权衡。实用建议单机 8 卡优先用 TP 而不是 PP因为 TP 通信延迟低、负载均衡好。跨机多节点时再考虑 PP 切分模型层。如果模型在 7B~13B 这个区间单卡 A100/H100 已经能放下权重那连 TP 都可以省直接纯 DP 加 ZeRO 就足够了。6. CP上下文并行——长序列的专用武器6.1 长序列为什么会让前面所有并行策略失效一般算法同学在训练 2K/4K 上下文长度的模型时几乎不会遇到 CP 这个名词。但当你想训练一个 128K 甚至 1M 上下文长度的模型时Attention 的显存和时间复杂度都会跟着序列长度平方级增长Full Attention 情况下。举个例子hidden size 8192序列长度 128K单层 Attention 的中间激活就达到128K × 128K的注意力矩阵以 FP16 计算一次存储需要 32GB单卡根本扛不住。DP 切数据没用因为一条样本的序列就不能拆开TP 切权重也没用因为这里卡住的是 activation 和 attention 矩阵本身。这时候必须引入一个新维度——按序列长度切分。6.2 CP 的原理切序列 Ring AttentionCPContext Parallelism上下文并行把一条样本的序列长度切成 N 段每张卡负责一段。单看每一段attention 的 Q 和本地的 K/V 可以做局部计算但每个 token 要 attend 到全序列的 token所以需要一种机制把其他卡上的 K/V 拿过来。工程上最常用的实现是 Ring Attention把 N 张卡排成环状每张卡只持有一段 K/V通过环形传递轮流把其他卡上的 K/V 传到自己这一侧完成完整 attention 计算。这本质上是通信换显存的策略付出的代价是多次点对点通信通信量随序列长度线性增长而不是平方增长。另一种实现方案是异步 AllGather在计算当前分块的 attention 时预先去取下一分块的 K/V。通信与计算重叠延迟能被压得很低但实现复杂度比 Ring 高不少。6.3 CP 与 TP/DP 的区别和组合CP 与 TP 看着有点像——都是把一层的计算拆到多卡上。但切分维度完全不同TP 切的是权重矩阵的列或行每张卡做的是同一个 token 的完整 hidden 表示的一部分。CP 切的是序列维度每张卡上有一批完整的 token 数据算的是这些 token 的局部 Q、K、V只是 attention 时要跨卡拿 K/V。一个实用的视角TP 适合短序列大模型CP 适合长序列模型。当序列长度超过 32K 时CP 几乎是必须的。当前很多长上下文模型的训练配置是TP8 CP88 卡切权重序列再切 8 份两层叠加把 attention 有效序列长度降到单卡的 1/8。在代码层面CUDA 上通常用flash_attention或ring_attention内核来做 CP 的实现支撑。如果你只是用训练框架跑模型CP 一般表现为一个类似--context-parallel-size的启动参数但理解了它是怎么切序列的你才会明白为什么它要求通信拓扑是环形的、为什么通信量随序列变长而变多、为什么短序列任务不必开 CP切多了反而通信占比上升、更慢。7. EP专家并行——MoE 模型的通信换稀疏7.1 MoE 模型带来的新切分需求MoEMixture of Experts混合专家是目前千亿级模型的主流架构思路模型的大部分参数集中在若干专家网络MLP里每个 token 只激活其中一小部分专家。比如一个 8 专家 Top-2 的 MoE每个 token 只走 2 个专家的 MLP计算量大幅降低但参数量维持巨大。但这里有个工程难题slot 层的专家数量如果少比如 8 个放在一张卡里没问题如果专家数量多比如 128 个单卡的显存装不下全部专家权重。这时候有两种做法把专家切到多张卡上每卡放一部分专家这就是 EPExpert Parallelism专家并行。每卡放全部专家但只路由激活其中一部分这是单纯的 MoE 推理不叫 EP。7.2 EP 的工作原理与通信模式EP 的训练流程可以用一段伪代码示意# 伪代码MoE EP 训练流程 # 1. 每张卡的 transformer 层attention 等独立计算 # 2. gate路由计算每个 token 被分配到哪个专家 # 3. token 需要根据路由结果 迁移到对应专家所在的卡上 # 4. 专家计算完后把 token 表示再 all2all 送回原卡 # 5. 继续后续的网络层计算 # 核心通信all2all每张卡与每张卡之间都有数据交换 dispatched_tokens all2all(tokens, routes) # 把 token 送去对应的专家设备 expert_output expert_forward(dispatched_tokens) combine_result all2all(expert_output, routes) # 把结果返回原设备关键点在那一对all2all操作token 需要根据路由结果实际移动到对应专家的卡上算完后再送回来。这个通信模式是全对全的跟 DP 的 AllReduce、TP 的 Ring 都不一样网络压力通常很大。工程上为了减少 token 搬运量会尽量让 token 的迁移发生在同一节点内所以EP 往往与 TP 混合使用比如 8 张卡组成一个 TP 组每个 TP 组内做张量并行共享 attention 层参数但专家分布在多个 TP 组之间。7.3 EP 与 DP、TP 的组合逻辑行业内典型的大规模 MoE 模型分层方案是普通 attention 层用 TP 并行专家层用 EP 并行外部再用 DP 扩展数据。也就是说一张卡上不一定同时存 attention 权重和所有专家权重而是attention 归 attention 的并行、专家归专家的并行通过灵活的设备映射把两类参数安排到不同卡上。对算法同学来说EP 需要形成两个认知EP 的存在让 MoE 模型即使参数量巨大也能保持单次 forward 的计算量可控。因为每个 token 只激活少数专家计算量与激活参数量成正比而不是总参数量。EP 的通信与路由质量直接挂钩。如果路由过于均匀token 在各卡间交换频繁如果路由太集中某个专家过热对应卡会过载形成热点。所以 MoE 训练通常要加负载均衡损失load balancing loss来约束路由让各专家负载尽量均匀。这里有个很实际的经验EP 的专家数量一般取设备数的整数倍比如 64 个专家放在 8 张卡上每张卡 8 个专家这样负载划分比较干净。如果专家数除以设备数除不尽负载不均匀会直接影响吞吐。8. 组合拳实操70B 模型到底该怎么分配8.1 先算显存再定并行策略我给算法同学的建议永远是拿到一个模型先算清楚单卡能不能放下权重、优化器状态、中间激活再决定用什么并行策略。举个 70B 模型训练的例子。70B FP16 权重 140GB如果用 Adam 优化器需要额外存 FP32 master weight140GB、momentum140GB、variance140GB优化器状态合计 420GB。梯度本身还要 140GB可即时释放。训练一个 70B 模型总显存需求粗略在 700GB 以上这还不算 activation。A100 80G 单卡完全没戏所以必须上并行。常见组合配置显存视角通信视角推荐度8×80GTP8权重分片到每卡 17.5GB优化器分片后勉强放下低延迟 NVLink 内通信显存够但算力可能不够适合推理32×80GTP8 PP4TP 内 8 卡共享权重PP 分 4 段TP 机内 PP 机间训练标准打法32×80GTP8 DP4ZeRO-2每 DP 组有完整模型经 TP 切分后优化器状态跨 DP 组切TP 机内 ZeRO 梯度 AllReduce工程实现简单扩展性好64×80GTP8 PP8 DP8三层并行叠加3D 并行TP 机内PP 机间DP 全局大规模集群的常规配置8.2 3D 并行DPTPPP的经典组合次序业界训练大模型的经典方案就是 Megatron-Deepspeed 那套3D 并行。设备分配逻辑通常是先按 TP8 组成一个节点内的张量并行组再在多个节点间按 PP 切层最后在整集群上做 DP 扩展。用大白话解释这套组合拳每一批数据会被复制成 DP 份每个数据副本在一条TPPP 流水线上从头流到尾流水线的每一站stage内部又用 TP 把权重和计算拆到一张节点内的 8 张卡上。这个结构的启动参数看起来像这样--tensor-parallel-size 8 \ --pipeline-parallel-size 8 \ --data-parallel-size 4 \含义是总共 8×8×4 256 张卡其中每 8 张卡内做张量并行8 个 TP 组串成一条 8 段流水线4 条完整流水线并行处理 4 份数据。这是目前工程上最常用的套娃结构。8.3 套娃结构下的显存与效率平衡组合策略里有个重要经验并行的层数越多真正通信开销越低的是 PP真正压显存的是 TP提高扩展效率的是 DP但三者加在一起时通信拓扑变得复杂调试难度大增。经验法则是模型权重超过单卡显存 1.5 倍时需要 TP 或 PP。TP 优先用于提速PP 优先用于跨机部署。DP 负责把整体吞吐打上去但要小心 ZeRO 阶段的通信开销。最后再强调一次TP 不跨机。这是 3D 并行配置里最容易被忽略的约束。在 8 卡 A100 节点上把--tensor-parallel-size设成超过 8一定会跨节点通信性能崩塌基本是必然的。很多所谓为什么我配了 3D 并行比单机还慢的问题追根溯源都是这个原因。9. 算法同学最容易踩的五个认知误区9.1 误区一并行越多越快千万别以为并行维度越全、并行度越大训练就一定越快。并行度增大后通信占比是线性甚至超线性增长的。一个 70B 模型从 TP8 扩展到 TP16实际吞吐可能不升反降因为多出来的 8 卡在大量时间里都在等通信。判断是不是该扩并行度的正确姿势看训练日志里的 GPU 利用率Compute Utilization。如果利用率低于 85%先检查是不是通信等待在拖后腿而不是盲目加压并行度。9.2 误区二把梯度同步当作 DP 的全部DP 不仅仅是同步梯度这么简单。在多机多卡环境下梯度 AllReduce 的实现Ring-AllReduce vs 树形 AllReduce会直接影响扩展比ZeRO 的分区通信也与 DP 的梯度同步各不相同。真正理解 DP 的关键在于谁的梯度、同步给谁、多大体量、多久同步一次。这些细节决定了 DP 是否适合你的模型规模。9.3 误区三TP 和 PP 都叫模型并行所以一样完全不是一回事。TP 是一层模型的多卡并行计算PP 是不同模型层在不同卡上串行计算。TP 的通信频率是每层多次PP 的通信频率是每若干层一次。这也是为什么 TP 必须机内 NVLink 而 PP 可以走机间网络。如果搞反了配置出来的训练集群通信开销会直接爆炸。举个场景如果有人在 8 卡节点上配置 PP8、TP1那么每个节点只有一层模型跨节点传 activation 非常频繁性能会很差。正确做法通常是每节点内先 TP节点间再 PP。9.4 误区四长序列训练直接靠大显存硬扛不少人觉得我的卡显存大序列长点没关系。但 attention 的显存与序列长度是平方关系序列从 8K 提升到 32K光是 attention 输出 buffer 就涨 16 倍。与其压榨单卡显存不如把序列切给多张卡做 CP同时配合 attention 内核优化FlashAttention 等压缩中间结果。CP 与 FlashAttention 是互补的不是替代关系。9.5 误区五MoE 模型用 DP 就完事了如果只是纯 DP 跑 MoE每张卡都要保存全部专家权重MoE 模型的显存优势直接浪费而且每个 token 只激活部分专家DP 复制完整模型等于白白浪费显存。MoE 模型必须配 EP 才能把参数多但计算少的架构优势发挥出来。一个常见的折中方案是EPTP混合attention 部分走 TP专家部分走 EP这样小规模集群也能训练千亿 MoE。如果你开始做 MoE 训练建议从这种混合配置起步。10. 一个实用清单拿到模型后该按什么顺序决定并行方案写到最后给一套我在实际工程里反复使用的决策流程算法同学可以当 checklist 用算显存模型参数量 × 2FP16 权重 优化器状态约 6~12 倍参数量看优化器 activation 估算判断单卡能不能放下。选 TP 粒度如果放不下优先给 TP 设成与节点内卡数相同通常 8让权重先被切开。选 PP 粒度如果单节点内 TP8 显存仍然不够或要扩展到多节点用 PP 把模型层切到多个节点上。PP 切分数一般等于节点数或节点数整数倍。选 DP 粒度模型结构确定后剩下的设备全部做 DP配合 ZeRO 来抠显存。长序列检查序列长度超过 32K 时额外开 CPCP 的大小取 2 的幂。MoE 检查模型里有 MoE 层把专家部分单独用 EP 切分并与 TP 组的位置对齐。盯监控启动训练后第一件事看 GPU 利用率和通信等待时间而不是看 loss 是否下降。如果利用率不高回头调整并行度。我在多个项目里用这套流程排障能解决 80% 以上的训练起不来得不到预期吞吐问题。剩下的 20% 通常出在数据加载、存储 IO 或框架版本差异上那就不是并行策略本身的问题了。最后再分享一个个人体会分布式训练的并行策略归根结底是在显存预算、算力预算、通信预算三者之间做取舍。算法同学习惯了只看模型结构和 loss但一旦模型上了规模这三个预算就会成为真正的约束。把五种并行策略的切分逻辑装进脑子里以后不管是读框架源码、调训练参数还是跟 infra 团队沟通都会顺畅很多。