1. 这不是概念背诵是分布式训练现场的“作战地图”你刚进大模型团队打开训练日志看到满屏的--tp-degree4 --pp-stage8 --dp-world-size16像看天书开会时同事说“我们把 PP 拆成 12 层TP 放到 A100 NVLink 组内DP 走 RDMA”你点头如捣蒜但心里在想这四个字母到底谁管哪块、谁和谁打架、为什么非得这么拆别急——这不是考英语缩写而是你在真实训练集群里调度显存、带宽、计算单元的三张作战地图TP张量并行管单卡算不动的“大矩阵”DP数据并行管海量样本的“流水线”PP流水线并行管超长模型的“工厂产线”CP上下文并行和 EP专家并行则是为特定瓶颈定制的特种战术。本文不讲论文定义只还原我在 Meta、阿里、字节三个团队实操 LLaMA-3 70B、Qwen2-72B、DeepSeek-V2 236B 训练时怎么用这五种并行策略把 128 张 H800 塞满、把通信开销压到 15% 以内、把吞吐从 18 tokens/sec 拉到 42 tokens/sec 的全过程。关键词就五个LLM、分布式计算、TP、DP、PP——后面两个 CP 和 EP 是实战中高频出现但资料极少的“隐藏关卡”我会用真实配置片段、通信拓扑图文字描述、显存占用热力图数值模拟给你拆解清楚。适合正在跑训、调参、报错的算法/Infra 同学也适合想搞懂大模型底层逻辑的架构师。如果你连torch.distributed初始化都配过三次才成功这篇就是为你写的。2. 为什么必须拆——从单卡 OOM 到集群调度的本质矛盾2.1 单卡根本装不下一个 LLM显存爆炸的数学真相先看最直观的痛点你手头有 8 张 A100 80G想训一个 70B 参数的模型。参数本身占多少显存简单算70B × 2 字节FP16 140GB。光参数就超了单卡容量更别说梯度140GB、优化器状态AdamW 两份梯度 两份动量 ≈ 280GB、激活值sequence length2048 时仅第一层前向激活就超 1.2GB。总显存需求 ≈ 参数 梯度 优化器状态 激活值 140 140 280 200 ≈ 760GB。8 张卡理论总显存 640GB实际可用约 580GB系统预留、PCIe 开销缺口 180GB。这不是“加卡就能解决”的问题而是显存增长与模型规模呈线性而计算密度FLOPs/GB却在下降——你堆卡越多通信瓶颈越重有效算力反而掉得更快。我见过最典型的反例某团队用 64 张 V100 训 13B 模型DP 分 64 份每卡 batch size1结果 90% 时间花在 AllReduce 同步梯度上吞吐比 8 卡还低 37%。所以拆不是为了“炫技”而是用空间换时间、用通信换计算、用拓扑换效率的生存策略。2.2 五种并行的本质谁在切什么切完怎么拼并行类型切的对象切的维度关键约束典型通信模式实战中最常踩的坑TP单层权重矩阵沿 K 或 O 维度如 QKV 投影同一 layer 内所有 TP rank 必须在同一物理机NVLink/RDMA 低延迟AllReduce前向、ReduceScatter反向TP 组内卡数 ≠ 2 的幂次如 3 卡 TP导致通信不均衡DP训练 batch样本维度batch dim所有 DP rank 可跨机但需高带宽 RDMA 网络AllReduce梯度同步DP 组大小 单机 PCIe 通道数引发 PCIe 瓶颈PP模型层layer沿层数维度如 0-15 层 vs 16-31 层相邻 PP stage 必须能低延迟通信通常同机或直连Send/Recvactivation/gradPP 微批次micro-batch数 pipeline bubbleGPU 利用率60%CP输入序列context沿 sequence length 维度需支持 FlashAttention-2 的分段计算如 4K→2×2KAllGatherkey/value cacheCP 与 TP 混用时attention mask 同步错误导致 loss nanEPFFN 专家expert沿 expert id 维度每个 token 只路由到 top-k 专家k2需专家负载均衡AllToAllexpert output专家分布倾斜hot expert 占用 80% 显存触发 OOM提示TP、PP、CP 都在“切模型”但切的粒度不同——TP 切单层内部矩阵PP 切层间顺序CP 切单层输入序列DP 是唯一不切模型、只切数据的EP 是为 MoE 架构特化的切法和 FFN 层强耦合。2.3 为什么不是“选一个”而是“叠着用”——混合并行的必然性单用 DP70B 模型在 128 卡上每卡仍要存完整 70B 参数 梯度 优化器显存超限。单用 TPTP32 时单层权重被切成 32 块但 attention 的 QKV 计算需跨 TP rank gather通信量爆炸O(N²) → O(N²×TP)。单用 PPPP16 时pipeline bubble 占用 50% GPU 时间且每 stage 仍需存整层参数显存没省下来。真实方案必然是混合TP 解决单层算不动PP 解决整模型放不下DP 解决数据吞吐不够CP/EP 解决特定瓶颈。比如 LLaMA-3 70B 在 128×H800 上的典型配置TP8, PP4, DP4—— 即 8 卡组内做张量并行NVLink 组4 组 TP 做流水线并行每组负责 1/4 层4 组 PP 做数据并行跨机 AllReduce。此时单卡显存占用 (70B / 8 / 4) × 2 梯度 优化器 激活 ≈ 4.3GB 4.3GB 8.6GB 1.8GB ≈ 19GB远低于 80G 限制。而 CP 和 EP 是“按需启用”当 sequence length 8K 时启 CP当模型用 Mixtral 架构时启 EP。3. TP张量并行把矩阵乘法“掰开揉碎”再组装3.1 不是简单切权重而是重构计算图TP 的核心不是“把 W 矩阵切成几块”而是重写前向/反向计算逻辑让每块卡只算一部分中间结果再通过通信拼出最终输出。以 Linear 层y x W b为例W: [d_in, d_out]列切Column ParallelW 按列切即 d_out 维度每卡存 W_i: [d_in, d_out/TP]。前向时y_i x W_i各卡输出 y_i 形状为 [seq_len, d_out/TP]需 AllGather 拼成完整 y。反向时grad_W_i x.T grad_y_igrad_x grad_y_i W_i.T其中 grad_y_i 需 ReduceScatter因 grad_y 被 AllGather 过。行切Row ParallelW 按行切d_in 维度每卡存 W_i: [d_in/TP, d_out]。前向时x_i x[:, i*d_in/TP:(i1)*d_in/TP]y_i x_i W_i各卡输出 y_i 形状为 [seq_len, d_out]需 AllReduce 求和得 y。反向时grad_W_i x_i.T grad_ygrad_x_i grad_y W_i.Tgrad_x_i 需 AllGather 拼回 grad_x。注意Attention 中 QKV 投影常用列切因输出维度 d_head×n_head 大O 投影常用行切因输入维度 d_model 大。这是为平衡通信量——列切 AllGather 通信量 O(d_out×seq_len)行切 AllReduce 通信量 O(d_out×seq_len)但行切的 grad_x AllGather 通信量 O(d_in×seq_len)而 d_ind_model 通常 d_out所以 QKV 用列切更优。3.2 实操关键NVLink 组网与通信原语选择TP 组必须物理同机或 NVSwitch 直连否则 NVLink 延迟 100ns vs PCIe 1μs差 10 倍。我们实测TP8 在单机 8×A100 上AllReduce 延迟 2.3μs若强行跨机RDMA延迟升至 18μsTP 效率跌至 41%。工具链选择上Megatron-LM工业级首选TP 实现最稳。其ColumnParallelLinear/RowParallelLinear封装了通信细节你只需设--tensor-model-parallel-size8。DeepSpeedstage3支持 TP但需手动配置mpumodel parallel unit易出错。优势是与 ZeRO 结合好。ColossalAIGemini引擎自动划分 TP但对 custom op 支持弱。配置要点# Megatron-LM 启动命令关键参数 python pretrain_gpt.py \ --tensor-model-parallel-size 8 \ # TP8 --pipeline-model-parallel-size 1 \ # 此时 PP1纯 TP --num-layers 80 \ # 总层数 --hidden-size 8192 \ # d_model --ffn-hidden-size 28672 \ # d_ffn --seq-length 4096 \ --micro-batch-size 4 \ # 每卡 micro-batch --global-batch-size 256 \ # DP × TP × micro-batch 256实操心得TP 组大小必须是 2 的幂次2/4/8/16。曾见团队用 TP123×4因 NCCL 的 ring-allreduce 要求组大小为 2 的幂导致通信 fallback 到 slow path吞吐降 35%。另外TP 切分后LayerNorm 的weight和bias必须 broadcast 到所有 TP rank否则 BN 统计错——Megatron 默认处理但自研框架常漏这点。3.3 TP 的代价通信墙与显存伪共享TP 最大代价是通信开销。以 QKV 投影为例d_model8192, n_head64, d_head128列切 TP8前向 AllGather 通信量 8192×128×64 / 8 × 2 字节 2.1MBFP16行切 TP8反向 grad_x AllGather 通信量 8192×4096 / 8 × 2 字节 8.4MBseq_len4096通信量随 TP 增大而线性增长但计算量不变因此存在最优 TP。我们实测 LLaMA-3 70B 在 H800 上TP4 时通信占比 12%TP8 时 23%TP16 时 41%。建议TP ≤ min(单机卡数, √(d_model))。d_model8192 时 √d_model≈91但单机最多 8 卡故 TP8 是上限。显存方面TP 是“伪共享”每卡存 1/TP 的权重但激活值activation仍需 AllGather所以显存节省 ≠ 1/TP。例如 TP8 时权重显存降为 1/8但 activation 显存几乎不变AllGather 后仍要存完整 y因此总显存节省约 30-40%而非 87.5%。4. DP数据并行让海量数据“并行喂食”但别卡在喂食口4.1 DP 不是“复制模型”而是“复制梯度同步逻辑”DP 的本质是每张卡跑完整模型但只算自己 batch 的前向/反向最后 AllReduce 同步梯度。它不减少单卡显存只提升吞吐。误区是“DP 卡越多越好”但实际受限于三个瓶颈通信瓶颈AllReduce 梯度通信量 模型参数量 × 2 字节。70B 模型 AllReduce 一次 140GB。NCCL AllReduce 在 128 卡 RDMA 上理论带宽 12.8TB/s但实际有效带宽受拓扑影响。我们实测128 卡 AllReduce 140GB耗时 1.8s占 step time 32%。PCIe 瓶颈若 DP 组跨多机梯度需经 PCIe 上传到网卡单卡 PCIe 4.0 x16 带宽 32GB/s140GB 传输需 4.4s远超 RDMA 传输时间。负载不均DP 组内卡型号/驱动版本不一致导致某卡慢 1ms全组等它——我们曾因一台卡驱动未更新使 64 卡 DP 吞吐跌 40%。4.2 DP 的黄金配置组大小与网络拓扑强绑定DP 组大小必须匹配物理网络拓扑单机内 DP8 卡 A100用 PCIe Switch 互联DP8 时 AllReduce 走 NVLink延迟最低。跨机 DP必须用 RoCEv2/RDMA且交换机需支持 ECNExplicit Congestion Notification防丢包。我们用 Mellanox Quantum-2 交换机DP 组 ≤ 32 卡单台交换机端口数。混合 DP-TPDP 组内每卡是 TP 子组。例如 TP8DP4即 4 个 TP 组每组 8 卡DP 在组间同步。此时 AllReduce 通信量 (70B / 8) × 2 17.5GB比纯 DP 140GB 小 8 倍。配置命令DeepSpeed// ds_config.json { train_batch_size: 256, gradient_accumulation_steps: 4, optimizer: {type: AdamW, params: {lr: 3e-4}}, zero_optimization: { stage: 3, offload_optimizer: {device: cpu}, contiguous_gradients: true }, distributed_backend: nccl, fp16: {enabled: true}, wall_clock_breakdown: true }启动时deepspeed --num-gpus 128 --master-port 29500 train.py --deepspeed ds_config.jsonDeepSpeed 自动按卡数分 DP 组。注意DP 与 ZeRO 结合是刚需。ZeRO Stage 1optimizer state partitioning可省 2/3 优化器显存Stage 2gradient partitioning再省 1/2 梯度显存Stage 3parameter partitioning让单卡只存 1/DP 的参数——这才是 DP 能训大模型的根基。没 ZeRO 的 DP就是裸奔。4.3 DP 的隐形杀手梯度同步时机与精度损失DP 的 AllReduce 必须在反向结束、优化器 step 前完成。但若某卡反向慢如显存碎片化会拖慢全组。我们用 NCCL 的NCCL_ASYNC_ERROR_HANDLING1捕获超时但更治本的是梯度裁剪gradient clipping前置在 AllReduce 前对 local_grad 做 clip避免 nan 梯度传播。代码# PyTorch DDP 模式下非 DeepSpeed torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) # 必须在 loss.backward() 后、optimizer.step() 前 dist.all_reduce(grad, opdist.ReduceOp.AVG) # DDP 自动做精度上FP16 AllReduce 易溢出。解决方案AllReduce 用 FP32 accumulatorNCCL 默认开启或改用torch.float32梯度。我们实测FP16 AllReduce 在 70B 模型上step 2000 后 loss 开始震荡切 FP32 accumulator 后稳定。5. PP流水线并行把模型变成“芯片产线”让 GPU 不闲着5.1 PP 不是“分层”而是“时空折叠”——解决 pipeline bubblePP 把模型按层切分每 stage 负责一段。但 naive PP 问题巨大假设 80 层模型切 4 stage每 stage 20 层micro-batch1则t0stage0 算第 1 个 micro-batch 前向t1stage0 算第 2 个stage1 算第 1 个...t20stage0~3 全部 busy但只有 stage3 在算第 1 个 micro-batch 反向t40第 1 个 micro-batch 反向完成开始 optimizer.stepbubble 时间 (PP_stages - 1) × micro-batch_time。PP4 时50% 时间 GPU 闲置。解决方案是1F1BOne Forward One Backward调度每个 stage 在算完前向后立即算上一个 micro-batch 的反向如果 ready。Megatron 的PipelineSchedule实现此逻辑需设置--pipeline-model-parallel-size4 --micro-batch-size4则 bubble 降至 (4-1)×412 个 micro-batch占空比从 50% 升至 85%。5.2 PP 的核心约束stage 边界必须是“干净”的 tensorPP 切分点不能在 LayerNorm 或 Residual Add 内部否则跨 stage 的 tensor shape 不匹配。标准切法Transformer Block 边界每 block 包含attn mlp add norm切在 block 之间最安全。Attention 内部不可切QKV 计算需完整 d_model 输入不能切一半。Embedding/Head 层单独处理word embedding 和 lm-head 必须放在 stage0/stage_last否则 AllGather 通信爆炸。我们曾把 PP 切在 FFN 的 GELU 和 Linear 之间导致反向时 grad_input shape 错[seq, d_ffn/2] vs [seq, d_ffn]debug 3 天才发现。5.3 PP 的实操陷阱activation checkpointing 与通信优化PP 的 activation 显存巨大每 micro-batch 存一份中间结果。解决方案是activation checkpointing只存 forward 的 input反向时重算。但 PP 下 checkpointing 更复杂——需在 stage 边界存/取。Megatron 用recompute_methoduniform每 n 层 checkpoint 一次。我们设--recompute-granularityfull整个 block checkpoint显存降 35%但 compute time 12%。通信优化关键Send/Recv 用 P2P NCCL避免走 AllReduce。Megatron 的p2p_communication模块封装此逻辑。overlap communication with computation在 stage0 算前向时stage1 同步上一个 micro-batch 的 activation。需--overlap-pp-communication参数。配置示例python pretrain_gpt.py \ --pipeline-model-parallel-size 4 \ # PP4 --tensor-model-parallel-size 8 \ # TP8 --num-layers 80 \ # 总层 --layers-per-virtual-pipeline-stage 20 \ # 每 stage 20 层 --micro-batch-size 4 \ # 每卡 micro-batch --global-batch-size 256 \ # DP × TP × PP × micro-batch 256 --recompute-granularity full \ # checkpoint 整 block --overlap-pp-communication \ # 通信计算重叠实操心得PP stage 数必须整除总层数。LLaMA-3 70B 有 80 层PP5 或 8 或 10 可行PP6 不行80/6 非整数Megatron 会报错Number of layers must be divisible by pipeline model parallel size。另外PP1 时--pipeline-model-parallel-size1必须显式指定否则默认为 0启动失败。6. CP上下文并行与 EP专家并行解决 TP/PP 顾不到的“特种战场”6.1 CPContext Parallel当 sequence length 8KTP 也扛不住时TP 切权重但 attention 的 KV cache 显存 seq_len × d_model × n_head × 2 字节。seq_len32K 时KV cache 32768×8192×64×2 ≈ 34GB单卡放不下。CP 的思路是把长序列切成多段每段由不同卡算 attention再 gather 结果。FlashAttention-2 支持window_size和alibiCP 在此基础上扩展分段方式seq_len32KCP4则每卡处理 8K tokens计算自己的 QK^T再 AllGather 所有 K/V本地算 softmax(QK^T)·V。通信量AllGather K/V 通信量 8K×8192×64×2 × 4 34GB但这是单次比 TP 的持续通信更可控。适用场景RAG、长文档摘要、代码生成。我们训 CodeLlama-70Bseq_len16K时CP4 使显存降 42%吞吐升 1.8×。配置ColossalAIfrom colossalai.context import ParallelMode from colossalai.nn.parallel import ContextParallelModule # 在 attention layer 中 wrap cp_attn ContextParallelModule( moduleflash_attn_module, cp_groupcp_group, # CP process group scatter_idx0, # scatter on seq_len dim gather_idx1 # gather on head dim )注意CP 与 TP 混用时attention mask 必须同步。我们曾因 CP 的 causal mask 未 AllGather导致后半段 tokens 看到未来 tokenloss nan。6.2 EPExpert ParallelMoE 模型的“专家调度中心”EP 专为 MoEMixture of Experts设计如 Mixtral-8x7B总参数 45B但每次只激活 2 个 expert共 8 个实际计算量 ≈ 13B。EP 的目标是让每个 expert 独占一组卡token 动态路由到对应 expert。路由机制top-k router 输出 expert idAllToAll 将 tokens 发到对应 expert 卡。例如 8 expertEP8则每卡存 1 个 expertAllToAll 后每卡收到自己 expert 的 tokens。负载均衡router 需加 load balancing loss否则 hot expert 占用 90% 显存。我们用z_lossauxiliary_loss系数 0.01。通信量AllToAll 通信量 tokens_per_micro_batch × d_model × 2 字节。micro-batch4seq_len2048则 4×2048×8192×2 ≈ 1.3GB比 DP 的 140GB 小两个数量级。配置DeepSpeed-MoE{ moe: { expert_count: 8, expert_used_count: 2, capacity_factor: 1.2, loss_scale: 0.01, alltoall_dtype: fp32 } }实操心得EP 的 expert 分布必须均匀。我们用--moe-expert-count8 --moe-expert-used-count2但发现某些 batch 全部 token 路由到同一 expert触发 OOM。解决方案在 router 输出加 temperature1.2 的 softmax软化路由并监控expert_utilizationmetric低于 80% 时告警。7. 混合并行的终极配置如何为你的模型和集群“量体裁衣”7.1 四步决策法从模型规模、硬件、数据到目标吞吐不要抄别人配置用这套流程自己算算显存底线单卡最大可用显存如 H800 80G - 5G 系统开销 75G。估算param_mem grad_mem optim_mem act_mem 75G。param_mem params × 2 / (TP × PP)grad_mem params × 2 / (TP × PP)optim_mem params × 8 / (TP × PP × DP) AdamWact_mem ≈ 2 × seq_len × d_model × 2 粗略用 profiler 实测算通信瓶颈TP/PP/CP 的 AllReduce/AllGather/AllToAll 通信量总和 网络带宽 × step_time × 0.7。定 PP 上限PP ≤ 总层数 / 4保证每 stage ≥ 10 层避免 bubble 过大。定 TP 上限TP ≤ min(单机卡数, √d_model)且必须 2 的幂次。案例Qwen2-72Bd_model8192, layers80, seq_len4096在 128×H800 上Step 1act_mem ≈ 2×4096×8192×2 128MBparam_mem72B×2/(TP×PP) 75G → TP×PP 1.92 → TP×PP ≥ 2Step 2TP8, PP4, DP4 → TP×PP×DP128刚好 128 卡Step 3PP4 ≤ 80/420OKStep 4TP8 ≤ √8192≈91OK最终TP8, PP4, DP4, CP1, EP17.2 工具链选型实战对比表工具TP 支持PP 支持CP 支持EP 支持易用性社区活跃度典型用户Megatron-LM★★★★★★★★★★✘✘中高NVIDIAMeta, Baidu, AlibabaDeepSpeed★★★★☆★★★★☆✘★★★★★高config 驱动极高MSMicrosoft, OpenAIColossalAI★★★★☆★★★★☆★★★★☆★★★★☆低API 复杂高国内ByteDance, TencentFlexFlow★★★☆☆★★★☆☆★★☆☆☆★★☆☆☆低需写 DAG中学术研究推荐组合生产环境用Megatron DeepSpeed ZeROMegatron 做 TP/PPDeepSpeed 做 ZeRO-3既稳又省显存。研究新架构用 ColossalAICP/EP 支持最全。7.3 一次配错三天白干五个血泪教训TP 组跨机以为 RDMA 能替代 NVLink实测 TP8 跨机后AllReduce 延迟 18μs → step time 2.3s → 吞吐跌 58%。教训TP 必同机用nvidia-smi topo -m确认 NVLink 拓扑。PP stage 数不整除层数LLaMA-3 80 层设 PP6启动报错AssertionError: Number of layers...。教训先grep num_layers config.json再算 PP。DP 未开 ZeRO70B 模型 DP128单卡显存 68GOOM。教训ZeRO Stage 3 是 DP 的生命线--zero-stage 3必加。CP 未同步 mask长文本训练 loss nandebug 发现 causal mask 未 AllGather。教训CP 下所有 tensor包括 mask都要通信用dist.all_gather显式处理。EP router 无负载均衡8 expert 中 2 个占 95% 显存其余 6 个空闲。教训moe_aux_loss_coeff必设 0.01监控expert_balance_ratio。8. 附录快速诊断手册——看到这些现象立刻查对应并行现象最可能原因立即检查项解决方案GPU 利用率 40%但 loss 下降慢PP bubble 过大nvidia-smi dmon -s u -d 1查 utilization--micro-batch-size是否太小增大 micro-batch-size或减 PPAllReduce 通信耗时 30% stepDP 组过大或网络差nsys profile看 ncclKernel 时间ibstat查 RDMA link status减 DP 组大小或换 ECN 交换机OOM 报错在 forward 第一层TP 切分错误--tensor-model-parallel-size是否设错nvidia-smi查显存分配检查 TP 配置确保同机loss nan且只在 step 1000 出现CP mask 未同步或 EP router 无负载均衡print(mask.shape)print(expert_usage)加 AllGather mask调大 aux_loss训练速度忽快忽慢波动 20%DP 组内卡负载不均nvidia-smi -q -d UTILIZATION查各卡 GPU-Utildmesg查驱动错误统一驱动版本禁用节能模式最后分享个小技巧在pretrain_gpt.py开头加一行 torch.cuda.memory._set_memory_pl