写在前面：为什么并行策略决定了“能不能训”和“训得快不快”

在 Ai大模型训练教程 的实战里，你很快会发现：模型、数据、显存、带宽、延迟这五件事绑在一起。单卡跑不动时，第一反应是“加卡”，但加卡后速度反而变慢的情况非常常见，核心原因通常不是算力不够，而是 并行策略导致的通信开销 把收益吃掉了。

大模型训练常见三种并行：

• 数据并行（Data Parallel, DP）：每张卡放一份完整模型，分不同数据，训练后同步梯度。
• 张量并行（Tensor Parallel, TP）：把同一层的矩阵/张量切到多卡上算，层内需要频繁通信。
• 流水线并行（Pipeline Parallel, PP）：把不同层切到不同卡上，按微批次“流水”执行，阶段间传激活。

本文聚焦“怎么选”：从通信开销的结构、规模门槛、以及一套可操作的决策步骤出发，给出具体建议与示例，帮助你在不同 GPU 数量、模型规模、网络条件下做出更接近最优的组合。

先建立直觉：三种并行各在通信什么？

数据并行 DP：通信的是梯度（或参数）

DP 的关键通信发生在反向传播结束后的 梯度 All-Reduce（或 ZeRO/FSDP 变体中的 Reduce-Scatter + All-Gather）。

• 通信频率：每个训练 step 一次（或按 bucket 多次）。
• 通信量：与 模型参数量成正比（严格说与参与同步的梯度大小相关）。
• 优点：实现简单、扩展性好（到一定规模内）、对算子改动少。
• 风险：当模型很大或网络较慢时，All-Reduce 会成为瓶颈；同时每卡需要放下完整模型（除非引入 ZeRO/FSDP）。

适合场景直觉：模型还能放进单卡（或靠 ZeRO 能放下），并且你更希望用更多卡吞吐更多数据。

张量并行 TP：通信的是层内中间结果（激活/部分输出）

TP 把一个大矩阵乘（比如 Transformer 的线性层、注意力投影）切分到多卡，每层前向/反向都要做通信，典型是 All-Reduce / All-Gather。

• 通信频率：每一层、每一次前向/反向都会发生，频率远高于 DP。
• 通信量：与 激活大小、隐藏维度、序列长度 强相关。
• 优点：解决“单卡模型放不下”的问题（参数和部分激活分摊）。
• 风险：非常吃网络延迟/带宽；如果 interconnect 弱（例如普通以太网），TP 往往会使吞吐显著下降。

适合场景直觉：单机多卡（NVLink/NVSwitch）内做 TP 最划算；跨机做 TP 代价高。

流水线并行 PP：通信的是阶段间激活（以及梯度回传的激活梯度）

PP 把模型层切成若干 stage，每个 stage 放到一组 GPU 上。微批次（micro-batch）像工厂流水线一样在 stage 间流动。

• 通信频率：每个微批次在相邻 stage 间发送一次激活（前向）和一次梯度（反向）。
• 通信量：与 每个 stage 边界处的激活大小 相关（通常是 batch×seq×hidden）。
• 优点：在模型极大时，比 TP 更“粗粒度”，通信频率低一些；更适合跨节点扩展。
• 风险：有“流水线气泡”（bubble）导致利用率下降；需要合理 micro-batch 数；实现复杂度高。

适合场景直觉：当模型大到必须跨节点切分、TP 不划算时，用 PP 把通信限制在 stage 边界。

通信开销怎么粗算：用“带宽主导 vs 延迟主导”做判断

在工程上你不必精确算到每个字节，但要判断你的系统属于：

• 带宽主导：通信量很大，链路带宽越高越好（例如大规模梯度同步）。
• 延迟主导：消息很多但每次不大，单次通信延迟累积成瓶颈（例如 TP 的层内频繁同步）。

一个实用的粗略公式

一次通信耗时可以近似为：

• T_comm ≈ α + (N_bytes / BW)

其中：

• α 是通信启动/同步开销（延迟项），小消息时占主导。
• BW 是有效带宽。
• N_bytes 是通信字节数。

用它来理解三种并行：

• DP：通信次数相对少，单次消息大 → 更偏带宽主导。
• TP：通信次数多，且每层都来一次 → 更偏延迟主导（同时也吃带宽）。
• PP：通信次数与 micro-batch 成正比，但只发生在 stage 边界 → 介于两者之间，通常比 TP 更不敏感于延迟。

适用规模与典型“门槛”：从显存约束先决定，再优化吞吐

选择并行策略最靠谱的顺序是：

1) 先满足显存：能不能放下模型与训练状态
2) 再看网络：你的互联是否支撑频繁通信
3) 最后追吞吐：用组合并行把算力吃满

下面给出常见门槛规律（不是死规则，但能快速定位）：

1）当模型“单卡可放下”（或轻度 FSDP/ZeRO 可放下）

优先：DP（+ 梯度累积）

• DP 的工程成本最低，扩展最平滑。
• 通过 增大 global batch 或 梯度累积，提高计算/通信比，让 All-Reduce 更“划算”。

此时只有在以下情况才考虑 TP/PP：

• 你追求极致吞吐、并且是单机 NVLink 环境，可以用小规模 TP 提高 GEMM 效率或解决单卡算子瓶颈。
• 你需要更大的序列长度/更大的激活，导致显存压力变大。

2）当模型“单卡放不下”，但“单机多卡能放下”

优先：TP（在单机内） + DP（跨机） 或 FSDP/ZeRO + DP

• 如果你有 NVLink/NVSwitch：TP 的层内通信在机内完成，代价可控。
• 跨节点则尽量避免 TP，把跨节点的部分留给 DP（梯度同步）或 PP（stage 间激活）。

经验建议：

• TP 规模在单机内常取 2/4/8（视 GPU 数与拓扑）。
• TP 越大，层内通信越频繁，吞吐越可能被延迟吃掉。

3）当模型“大到单机多卡也放不下”（必须跨节点）

优先：PP（跨节点） +（每个 stage 内 TP）+ DP

这就是常说的 3D 并行（DP×TP×PP）。直觉是：

• PP 用“粗切分”把模型拆到多机；
• 每个 stage 内部用 TP 利用单机高速互联；
• DP 用于扩大全局 batch，提升吞吐。

此时的关键是控制：

• PP 的 bubble：用足够的 micro-batch 数减少空转。
• stage 划分：让每个 stage 计算量相对均衡，同时减少边界激活大小。

选型决策树：一套可落地的步骤（建议照着做一次）

Step 1：先做显存预算，决定“必须用哪种并行”

训练显存大头通常包括：

• 参数（FP16/BF16）
• 梯度
• 优化器状态（Adam 一般最重）
• 激活（与 batch/seq/hidden/层数相关）

实操建议：

1. 用一个最小配置（小 batch、小 seq）在单卡试跑，记录峰值显存。
2. 打开/关闭 activation checkpointing（梯度检查点）对比，评估激活占比。
3. 若仅优化器状态导致爆显存：优先考虑 ZeRO/FSDP（属于 DP 的内存分片扩展），而不是一上来就 TP/PP。
4. 若参数本身就放不下：才是 TP/PP 的硬需求。

Step 2：根据硬件互联，限制 TP 的“可用半径”

• NVLink/NVSwitch（单机）：适合 TP，尤其是 attention/MLP 的大 GEMM。
• InfiniBand（多机）：DP/PP 都可做，但 TP 跨机要非常谨慎。
• 万兆/普通以太网：尽量只做小规模 DP（甚至单机 DP），大规模 TP/PP 可能收益为负。

简单判断法：

• 如果你跨机带宽/延迟不理想，把跨机通信频率压到最低：优先 DP（bucket 后的大消息）或 PP（相邻 stage 的少数大消息），避免 TP 那种“层层通信”。

Step 3：先用 DP 跑到“通信占比可接受”，再引入 TP/PP

建议先测一个基线：

• 只用 DP（必要时加 ZeRO/FSDP）
• 记录：step time、吞吐（tokens/s）、通信时间占比（如 NCCL profiling）

如果发现：

• GPU 利用率低 + 通信占比高：说明 DP 的梯度同步已经成为瓶颈，考虑：

  • 增大梯度累积（让每次同步之间的计算更多）
  • 调整 bucket size、开启 overlap（通信计算重叠）
  • 需要更高带宽互联
• 显存不够：再引入 TP/PP。

Step 4：引入 TP 的最小化策略（先小后大）

• 从 TP=2 开始，观察吞吐变化。
• TP 增大后，如果吞吐下降且通信时间暴增，说明受限于延迟或跨机链路。

可操作建议：

• 把 TP 限制在单机内（例如 8 卡机器就 TP=8 或 TP=4），跨机维度用 DP/PP。
• 优先切分计算最重的线性层（框架通常已实现），不要自定义奇怪切法导致额外通信。

Step 5：需要 PP 时，先解决 bubble 和 stage 划分

PP 的两个核心旋钮：

1) micro-batch 数量（m）

• m 越大，bubble 越小，但激活缓存更多、调度开销更高。
• 常见做法：固定 global batch，增加 m、减少每个 micro-batch 的 size。

2) stage 数量（p）与划分位置

• stage 越多，每个 stage 越小，单卡更容易放下，但 bubble 可能更严重。
• 划分要尽量让各 stage 计算量相近；把 embedding、LM head 这类可能造成不均衡的部分单独考虑。

具体示例：在不同规模下怎么组合（给你可复制的思路）

示例 A：8×GPU 单机，模型能放下，但想提吞吐

目标：最大 tokens/s，网络不是问题（机内高速互联）。

推荐顺序：

1. DP=8（如果 batch 够大）
2. 如果 global batch 太小导致利用率不高：加 梯度累积
3. 如仍想更快，尝试 TP=2 + DP=4（保证 TP 在机内）

验证指标：

• DP=8 vs (TP=2,DP=4) 的吞吐对比
• 通信时间占比是否从 All-Reduce 转移为层内 All-Gather/All-Reduce

选择原则：

• 如果 TP 带来更高吞吐且显存余量更大，保留；否则回退 DP。

示例 B：32×GPU（4 机×8 卡），模型单卡放不下，但单机内能用 TP

推荐：TP=4（机内） + PP=2（跨机） + DP=2（举例）

解释：

• TP=4 保证层内通信不跨机。
• PP=2 把模型按层切到两组机器，跨机只在 stage 边界传激活。
• DP=2 提升吞吐，梯度同步跨机进行，但频率低于 TP。

调参步骤：

1. 先固定 TP=4，尝试 PP=2/4，找 bubble 与显存的平衡点。
2. 增加 micro-batch 数，把 GPU 利用率拉满。
3. 最后再加 DP，观察梯度同步是否成为新瓶颈。

示例 C：网络一般（以太网），但你想用多机训练

建议更保守：

• 优先 单机 DP，跨机只做很小规模 DP（甚至不跨机）。

• 如果必须跨机：

  • 尽量提高梯度累积，降低同步频率
  • 避免 TP 跨机
  • PP 也谨慎，因为激活传输会频繁发生在每个 micro-batch

这种情况下“加机器变慢”非常常见，先把网络和存储带宽（数据加载）补齐往往更关键。

常见坑与对策：你一调就能见效的点

坑 1：只看显存不看通信，TP 规模开太大

现象：显存下来了，但 tokens/s 掉很多，GPU 利用率低。

对策：

• 缩小 TP（例如从 8 降到 2/4），把剩余卡用 DP 或 PP。
• 把 TP 限制在 NVLink 域内，不要跨节点。

坑 2：PP micro-batch 太少，bubble 吃掉一半算力

现象：stage 之间等待严重，profile 看到大量 idle。

对策：

• 增大 micro-batch 数 m（常见从 4 提到 16/32）。
• 配合 activation checkpointing 控制激活显存。
• 调整 stage 划分，使每段计算更均匀。

坑 3：DP 下 global batch 太小，通信占比过高

现象：All-Reduce 时间占 step time 很大。

对策：

• 增大梯度累积步数（accumulation steps）。
• 使用更大 bucket，提高带宽利用率。
• 开启通信计算重叠（overlap），确保反向过程中就开始同步。

坑 4：只做 DP 但优化器状态爆显存

现象：参数能放下，Adam 状态导致 OOM。

对策：

• 使用 ZeRO-2/ZeRO-3 或 FSDP，把优化器状态/参数分片。
• 若框架支持，结合 CPU offload（代价是速度）。

最终建议：用一句话总结怎么选

• 能放下就 DP 优先：最稳、最省心，吞吐通常也最好调。
• 放不下但单机互联强：用 机内 TP 解显存/算力，再用 DP 扩展。
• 大到必须跨机切模型：用 PP 做跨机切分，TP 只在机内，DP 用来扩吞吐。

在 Ai大模型训练教程 的实战落地里，最有效的方法不是“拍脑袋选并行”，而是按本文的步骤：先做显存预算，再用硬件互联限制通信半径，最后通过 profile 迭代调参。只要把通信频率和通信半径控制住，你的扩展效率通常就会明显提升。