多GPU并行策略

可视化演示

展示数据并行（AllReduce梯度同步）、模型并行（层内张量切分）、流水线并行（stage划分与气泡）三大策略的原理与通信模式，三模式切换理解并行方案选型。

并行训练逻辑

主厨先算了一笔账：单灶台一晚上最多出 200 份菜，而订单有 2000 份。多开几个灶台看似简单，但厨房不是人越多越快——统一下单、食材协调、出菜检验这些环节，都必须所有厨师同步等待，无法并行。这几段“开不了小灶”的时间，直接决定了整晚能出多少桌菜。

训练深度学习模型同样如此。训练过程可以理解为“试做菜”：前向传播是照着菜谱试做一道菜，反向传播是试吃后倒推每一步哪里出了问题，给出调整建议，优化器再修改菜谱。单张 GPU 算力再强，面对大模型的海量参数与海量数据，试做周期也会拉长到数周甚至数月。多 GPU 并行就是把大任务拆成小块，但无论怎么拆，都受一条铁律约束：可并行的部分能随 GPU 数线性加速，不可并行的部分会成为天花板。

这条铁律叫 Amdahl 定律。设串行时间占比为 f，GPU 数为 N，加速比 S 为：

所以，主厨不是盲目加灶台，而是先找出哪些环节没法并行——比如开菜单、对账。GPU 集群也一样，拿到一台多卡机器，第一步永远是量化串行瓶颈在哪，再决定用什么并行策略。

数据并行原理

老板拍板的第一套方案：四个厨师各拿一本同款菜谱，从四堆不同的食材中各取一份，各自完整地做一道菜。每隔一段时间，四人围坐在一起，把刚才试吃的心得汇总平均——“盐少了”“火候过了”——统一修订菜谱，再继续做下一批。每轮改进都建立在四份经验之上，学习效率翻了四倍。

这就是数据并行（Data Parallel）。每张 GPU 上都存放一份完整的模型副本，各自读取不同的 mini-batch 数据，独立完成前向与反向传播，算出各自的梯度；随后通过 All-Reduce（一种把所有卡的梯度汇总后再发给每一张卡的集体通信操作）把梯度求平均，用平均梯度统一更新模型权重。相当于把 batch size 放大了 N 倍，训练效果和用超大 batch 在单卡上训练近似等价。

数据并行实现简单、扩展性好，是最常用的并行方式，但短板是通信：每轮更新都要把全部梯度汇总一次，模型越大，同步通信量越大。假设模型大小为 M 字节、卡间带宽为 B 字节/秒，每轮同步时间近似为：

四名厨师各自做菜的时间可以完全重叠，但“碰头开会”的时间没法重叠。菜谱越厚（模型越大），开会越久——当模型大到一定程度，每轮同步的通信开销就会吞噬所有加速收益，逼着团队寻找第二种方案。

模型并行原理

第二种方案：招牌菜实在太复杂，一本菜谱两百页，没人能完整背下来。主厨把菜谱按工序拆成四份——酱汁部、主料部、摆盘部、出品部——每个厨师只精通一块。做一道菜时，半成品必须依次经过每位厨师的手：我做完酱汁递给你，你调好主料再递给他。

这就是模型并行（Model Parallel）。它把网络结构本身拆开，分给多张 GPU 共同承载。拆法有两大类：层间并行把不同层分给不同 GPU，激活值逐层串行传递，这是流水线并行的雏形；层内并行也叫张量并行（Tensor Parallel），把同一层里的权重矩阵切开，多卡合力算一个层。大型 Transformer 模型更常用张量并行，因为单层的矩阵乘太大了。

具体做法是：一个大矩阵乘 \(Y = XW\)，把权重按输出维度切成 P 块，每张卡只算自己那块 \(XW_i\)，最后通过一次 All-Reduce 把结果聚合起来。公式写作：

拆菜谱让每位厨师只背五十页，但每道工序之间都要“递一次菜”。如果递菜通道太窄（网络带宽低），频繁的层内通信就会拖慢节奏——这才有了下一节流水线并行，用更少的通信承担切模型的任务。

流水线并行原理

老板又提出第三种方案：既然菜谱已按工序拆好，不如把厨房改成流水线——洗切、烹炒、装盘三段接力。传统做法是一次只传一个托盘，那么启动时装盘工得空等，收尾时洗切工得空等，这些“空转”就是气泡。聪明的做法是同时送多个托盘，让各段始终有活干。

流水线并行（Pipeline Parallel）是层间模型并行的工程化升级。它把模型按层分成 P 个阶段，每个阶段放在一张或一组 GPU 上；训练数据被切成 M 个微批量（micro-batch），像托盘一样依次流经各阶段，前向传播和反向传播可以交错进行。以 1F1B 调度为例，每个阶段在算完一个微批次的前向后，立刻算下一个微批次的反向，避免长时间闲置。

衡量流水线效率的核心指标是气泡占比：把 M 个微批量送进 P 段流水线，总时间相当于 \(M + P - 1\) 个时间段，其中开头 P-1 段在“填充”、结尾 P-1 段在“排空”，空闲占比为：

流水线让“传菜”从频繁的手递手变成流水线上的托盘滑动——只在相邻阶段传递一次激活值，通信频率比张量并行低得多。只要托盘足够多，各段厨师就能像齿轮一样咬合转动，气泡被挤到最小。

混合并行策略

真正的大宴会厨房从来不止一套方案：十几个灶台同时开火炒菜（数据并行），每个灶台上又有几位厨师各管一道工序（模型并行），同时备菜、炒菜、装盘之间形成流水线（流水线并行）。三种协作方式拧成一股绳，这就是混合并行。

现代大模型训练几乎都在用混合并行。以 Megatron 系列框架为例，训练 LLM 时会同时启用数据并行、流水线并行和张量并行，构成“3D 并行”：数据并行扩大每轮吃下的数据量、提升吞吐；流水线并行把模型纵向切成多段、降低单卡显存压力；张量并行把每段内的层再横向切开、进一步分摊显存并提升单层计算并行度。三种并行度之间存在简单的乘法关系：总 GPU 数等于三者之积。

就像大厨房里有人管全局出餐节奏、有人管具体灶台、有人管切配——3D 并行把 GPU 编排成一支分工明确的“后厨团队”。但这支团队能不能高效运转，最终还得看传菜通道（通信网络）是否够宽。

通信开销平衡

主厨最怕的不是做菜慢，而是“空转等菜”：灶台五分钟能炒完一道菜，传菜生却要八分钟才把食材送到，厨师只能干等。协作厨房的效率，不取决于做菜最快的环节，而取决于“做菜 + 传菜”整条链路。

多 GPU 训练同理。每次迭代的实际耗时等于计算时间加通信时间（两者若能重叠，则取较大者）。三种并行策略的通信特征差异很大：数据并行每轮传全量梯度，通信量正比于模型大小；张量并行每层都要聚合一次激活值，通信频繁但对单次传输量要求不大；流水线并行只在阶段边界传激活值，通信频率低、单次量也不大，代价是气泡。带宽越高、拓扑越优，通信占比就越低。

工程上用一个简洁的效率指标来评估配置是否合理：设计算时间为 \(T_{\text{compute}}\)，通信时间为 \(T_{\text{comm}}\)，效率 \(\eta\) 定义为计算时间占总时间比例：

好的厨师长会在“做菜”和“传菜”之间找平衡：传菜通道窄，就减少频繁传菜，少用张量并行、多用流水线；厨师手速慢，就增加灶台，多用数据并行。集群拓扑与模型结构，共同决定最优策略。

方案选型实践

要不要把后厨改造成流水线？主厨会先回答三个问题：菜谱多厚（模型大小）？一天多少桌（数据量）？后厨多大、走廊多宽（GPU 数量与互联）？没有放之四海皆准的答案，只有算完账后的最优解。

选型第一步永远是从显存算起：模型能不能装进单卡？混合精度训练下，每个参数大约需要 16 字节显存：参数本身 4 字节、梯度 4 字节、Adam 优化器状态 8 字节。模型并行（TP × PP）可以把这部分占用按比例摊薄；数据并行不省显存，只是把数据分批。若模型单卡放得下并且想加速，用数据并行；单卡放不下，先切模型；切分粒度过细导致通信爆炸，再上流水线。

第二步看网络拓扑：节点内多卡通常有 NVLink（数百 GB/s），适合张量并行；节点间用 InfiniBand 光缆（约 400Gb/s），适合数据并行与流水线并行。第三步做小规模实测，用性能分析工具定位 GPU 空闲率与通信占比，再迭代配置。单卡显存估算公式如下：

账算清楚了，主厨才敢拍板：这几张灶台、这条动线、这套分工，今晚能否接住两千桌订单。选型没有银弹，只有基于模型规模、数据量与硬件拓扑三者的综合权衡。

AI 应用场景

Python 演示

# Multi-GPU parallelism simulator# Compare data / model / pipeline parallel with simple metrics# All units: model in GB, bandwidth in Gbps, time in seconds def data_parallel(model_gb, batch_time_s, gpu_count, bandwidth_gbps):    # Data parallel: each GPU holds full model copy, sync gradients every step    compute = batch_time_s / gpu_count    sync_time = 2.0 * model_gb / bandwidth_gbps    total = compute + sync_time    efficiency = compute / total    return total, efficiency def pipeline_parallel(stage_count, micro_batches):    # Pipeline parallel: bubble ratio formula    bubble = (stage_count - 1) / (micro_batches + stage_count - 1)    return bubble, 1.0 - bubble def model_parallel(layer_groups, model_gb, bandwidth_gbps):    # Layer-wise model parallel: activations pass between GPU groups    comm_time = layer_groups * model_gb / bandwidth_gbps    return comm_time def main():    print("=== Data Parallel (8 GPUs, 14GB model, 40Gbps) ===")    total, eff = data_parallel(14, 100, 8, 40)    print("total: %.4fs, efficiency: %.2f%%" % (total, eff * 100))     print("\n=== Pipeline Parallel (4 stages, 8 micro-batches) ===")    bubble, util = pipeline_parallel(4, 8)    print("bubble: %.2f%%, utilization: %.2f%%" % (bubble * 100, util * 100))     print("\n=== Model Parallel (3 groups, 40Gbps) ===")    comm = model_parallel(3, 14, 40)    print("comm time per step: %.4fs" % comm) if __name__ == "__main__":    main()

1. def data_parallel(model_gb, batch_time_s, gpu_count, bandwidth_gbps):定义数据并行模拟函数，输入模型大小、单卡计算耗时、GPU 数和带宽。
2. compute = batch_time_s / gpu_count理想情况下计算时间随卡数线性下降，这是“多灶台各炒各菜”的收益。
3. sync_time = 2.0 * model_gb / bandwidth_gbps每次同步梯度要传两遍全量模型，对应公式里的 \(2M/B\)。
4. efficiency = compute / total效率等于计算时间占总时间的比例，通信越重效率越低。
5. def pipeline_parallel(stage_count, micro_batches):定义流水线并行模拟，直接套用气泡公式。
6. bubble = (stage_count - 1) / (micro_batches + stage_count - 1)气泡占比公式，阶段越多气泡越大、微批越多气泡越小。
7. comm_time = layer_groups * model_gb / bandwidth_gbps层间模型并行的通信按阶段边界估算，层越深通信链越长。

常见误区

面试题