想象你是一家星级餐厅的老板，突然接到一单“千人晚宴”——要在有限的后厨里，用合理的厨师配置，把上百道菜准时端上桌。后厨面积有限（GPU 显存），传菜走廊就那么宽（通信带宽），从下单到上菜只有几小时（训练截止时间）。你手里刚招来一批厨师（GPU），该怎么排兵布阵？是让每个人都拿完整菜谱各炒各的（数据并行）？还是把一道红烧肉拆成切配、煸炒、收汁三段，由几位厨师协作完成（张量并行）？又或者按“切配→炒制→装盘”组成一条流水线（流水线并行）？现实世界里，这些招数往往要组合使用，这就是“混合并行”。本文就用这个后厨视角，带你看懂当模型从 10 亿参数长到 1000 亿参数时，你会面临哪些选择，以及怎么少走弯路。

岗位关联

分布式训练工程师的核心技能之一，就是读懂混合并行的“成本账”。掌握了策略选型的判断逻辑，你就能在同样的 GPU 集群上少花钱、多跑量，让训练效率翻倍。

目录
  1. 可视化演示
  2. 并行策略基础
  3. 集群拓扑认知
  4. 通信瓶颈分析
  5. 显存占用评估
  6. 策略选型决策
  7. 混合并行组合
  8. 成本效益评估
  9. 实战踩坑清单
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示DP/TP/PP三种并行策略、GPU集群三层网络拓扑、不同模型规模配置方案及MFU成本效益评估，交互切换深入理解分布式训练选型。

本节配有交互动效（进入视口后自动加载，约 3KB）。

三种并行：DP数据并行、TP张量并行、PP流水线并行 DP：每卡完整模型，不同数据，梯度同步 TP：模型层内切分，需高带宽互联 混合并行 = DP × TP × PP 实战中三者组合使用。

并行策略基础

假设后厨刚开业，只服务一桌客人。你雇了 8 位厨师，每人面前一份完整菜谱。数据并行（DP）就是最简单粗暴的安排：8 口锅同时炒同一道菜，每口锅炒到自己那份数据后，都要互相品一口核对口味（同步梯度），保证大家炒出来的味道一致。张量并行（TP）则像把“红烧肉”这道菜按食材切块：有人负责切肉、有人负责调汁、有人负责焯水，同一道菜多人同时配合。流水线并行（PP）则像经典流水线：切配组处理完一批食材就递给炒灶组，炒完递给装盘组，一环扣一环。

放到机器学习里，三种并行的本质分别是：数据并行复制模型、切分训练数据；张量并行切分模型权重矩阵；流水线并行按 Transformer 层切分。它们的同步机制也完全不同：DP 需要梯度全局归约（AllReduce），TP 需要前向和反向每层都做 AllReduce，PP 传输的是层间激活值而不是梯度。

DP 的通信量有一个著名估算式——每次梯度同步，每张卡都要把自己的梯度广播给所有人，总通信量近似为两倍模型参数乘以卡数：

所以，当后厨越来越大、菜谱越来越厚时，“每人一份菜谱各炒各的”虽然简单，但核对口味的时间会直线上升——这正是数据并行的软肋，也是我们要引入其他分工的原因。

Tcomm=2×Ngpu×θ\displaystyle T_{comm} = 2 \times N_{gpu} \times \theta
这个公式告诉你：模型参数越多、参与数据并行的卡越多，一次梯度同步要搬运的数据就越大。
  1. N_gpu（参与卡数）数据并行中的 GPU 数量。卡越多，每轮梯度同步要广播的目标越多。
    NgpuN_{gpu}
  2. θ（模型参数量）模型总参数个数，例如 7B 就是 70 亿。
    θ\theta
  3. 常数 2（两趟搬运）AllReduce 可拆成 reduce-scatter 与 all-gather 两趟，每趟都要传一遍完整数据。
    22
  4. 相乘的意义通信总量近似与参数量和卡数线性增长，这就是数据并行在大模型上的软肋。
    Tcomm∝Ngpu×θ\displaystyle T_{comm} \propto N_{gpu} \times \theta

集群拓扑认知

你实地考察新后厨，发现传菜通道分两种：厨房内部的传送带（节点内 NVLink，带宽可达 300GB/s）和连接两栋楼之间的窄走廊（跨节点网络，例如 InfiniBand 25GB/s）。同在后厨内传菜非常快，穿越大堂送菜就慢得多，带宽差距常常是 12 倍甚至更高。

这对应训练集群的拓扑结构：一台 8 卡服务器内部通过 NVLink 全互联，服务器之间通过 IB/RoCE 交换机相连。拓扑决定了通信路径的长度和带宽上限。如果并行策略把需要高频通信的维度放在跨节点路径上，性能会断崖式下跌。

分层通信时间可以写成一个直观的公式：总通信时间等于节点内传输时间加上跨节点传输时间。

排兵布阵前先看地图：能把通信压在节点内的并行维度（如 TP）就压在节点内，需要跨越走廊的维度（如 DP）尽量少传数据。

T=VnodeBnode+VcrossBcross\displaystyle T = \frac{V_{node}}{B_{node}} + \frac{V_{cross}}{B_{cross}}
数据在同一台机器内走快通道（B_node 大），跨机器走慢通道（B_cross 小），总时间是两段路程之和。
  1. V_node（节点内流量）需要在一台机器内传输的数据量，例如张量并行每层同步的数据。
    VnodeV_{node}
  2. B_node（节点内带宽）服务器内部互联带宽，如 NVLink 提供的 300GB/s 高速通道。
    BnodeB_{node}
  3. V_cross（跨节点流量）需要在机器之间传输的数据量，例如数据并行梯度同步中的跨机部分。
    VcrossV_{cross}
  4. B_cross（跨节点带宽）集群网络带宽，如 IB 的 25GB/s，通常远小于节点内带宽。
    BcrossB_{cross}

通信瓶颈分析

晚高峰，后厨的传菜走廊开始拥堵。你发现炒菜只要 3 分钟（计算），传菜却要 6 分钟（通信）——传菜时间反超炒菜时间，厨师们全部干等。这就是通信瓶颈：算力再强，也会被网络拖住。

衡量通信瓶颈的核心指标叫“通信计算比”：

AllReduce 为什么贵？因为每一轮梯度同步都是全局集合通信，所有卡要两两交换数据；网络拥塞时，通信时间不是线性而是排队叠加。实践中可以用梯度压缩、梯度累积、减少同步频率来缓解。

回到后厨：走廊窄就少传菜，或者攒几道菜一起传（梯度累积）、把菜提前打包压缩（梯度压缩）。总之别让传菜员在走廊里排长队。

μ=TcommTcalc\displaystyle \mu = \frac{T_{comm}}{T_{calc}}
μ 大于 1 说明通信时间超过计算时间，GPU 大量空转，训练被网络拖慢。
  1. T_comm（通信时间）完成一轮梯度同步或激活值传输所需的墙钟时间。
    TcommT_{comm}
  2. T_calc（计算时间）完成一轮前向和反向传播所需的纯计算时间。
    TcalcT_{calc}
  3. 比值 μ两个时间的商，用于量化通信相对于计算的拖延程度。
    μ=TcommTcalc\mu = \frac{T_{comm}}{T_{calc}}
  4. 判断标准μ 小于 1 时策略健康；μ 远大于 1 时必须调整并行维度或通信方式。
    μ<1\mu < 1

显存占用评估

后厨台面（显存）是硬约束。做一道菜要占的地方包括：菜谱（参数）、备好的料（梯度），以及为了随时调整味道而保留的小样（优化器状态）。AdamW 优化器会额外保存 fp32 主权重和两个动量，相当于每个参数要占 12 字节。

单卡显存估算公式可以拆成三部分：

注意：显存不完全由模型参数决定。激活值在长序列、大批次下可能比参数还大。选型前必须做显存预算，否则训练到一半就会 OOM 崩溃。

台面不够怎么办？要么减少台面占用（模型并行切分、ZeRO 分片），要么少摆临时物品（激活值重计算、减小批次）。选策略本质上是在“台面”和“走廊”之间找平衡。

M=(2+2+Copt)θ+A\displaystyle M = (2 + 2 + C_{opt})\theta + A
θ 是参数量；前两个 2 分别对应权重和梯度的字节数；C_opt 是优化器状态字节数；A 是激活值占用。
  1. 第一个 2（权重）BF16 精度下每个权重参数占 2 字节。
    2θ2\theta
  2. 第二个 2（梯度）每个参数对应一个梯度，同样占 2 字节。
    2θ2\theta
  3. C_opt（优化器状态）AdamW 需保存 fp32 主权重（4 字节）+ 一阶动量（4 字节）+ 二阶动量（4 字节），共 12 字节每参数。
    Copt=12,  Coptθ=12θ\displaystyle C_{opt} = 12,\; C_{opt}\theta = 12\theta
  4. A（激活值）前向过程暂存的中间结果，与批次大小、序列长度成正比，长序列下可能超过权重本身。
    A∝batch×seq_lenA \propto batch \times seq\_len

策略选型决策

现在你是后厨总指挥了。小型家宴（1B 以下模型），一间后厨就能摆平，数据并行最简单高效。中型宴席（7B~13B），单卡放不下完整模型，就用张量并行切分权重，再叠数据并行，这就是 TP+DP。宴席越大，需要的维度越多。

三种并行度满足严格的乘法关系：

实用决策树很清晰：模型单卡装得下 → DP；装不下但 8 卡内 → TP+DP；百亿级以上且层数很深 → 3D 并行。决策时还要注意显存与算力平衡：TP 省显存但耗通信，PP 省显存但有气泡，DP 灵活但梯度同步贵。

好比后厨排班：小馆子人人全能（DP），中餐厅分工分灶（TP+DP），超大型宴会才需要全流程流水线加分区负责（3D）。别让所有厨师都挤在一条走廊上。

NGPU=NDP×NTP×NPP\displaystyle N_{GPU} = N_{DP} \times N_{TP} \times N_{PP}
先确定总 GPU 数，再分配三个维度：TP 优先限制在节点内，PP 按模型层数划分，DP 用剩余卡数打满。
  1. N_GPU（总卡数）集群中可用于训练的全部 GPU 数量。
    NGPUN_{GPU}
  2. N_TP（张量并行度）权重被切分成多少块，通常不超过单节点卡数。
    NTP≤node_gpusN_{TP} \le node\_gpus
  3. N_PP（流水线并行度）模型按层划分的段数，受到总层数约束。
    NPP≤layersN_{PP} \le layers
  4. N_DP（数据并行度）模型副本的数量，用总卡数除以 TP 和 PP 的乘积得到。
    NDP=NGPUNTP×NPP\displaystyle N_{DP} = \frac{N_{GPU}}{N_{TP} \times N_{PP}}

混合并行组合

在超级宴会里，三种分工不再独立——数据并行管“复制几套人马”，张量并行管“一道菜切几块”，流水线并行管“流程分几段”。它们组成一个三维矩阵，每个厨师都能定位到自己的网格坐标。

ZeRO 则是聪明的“菜谱共享”：与其给每人发一本完整菜谱（每卡存全部参数），不如把菜谱拆成几份分给不同厨师保管，谁需要时再借阅（通信）。这让数据并行在超大模型下也能用起来。

ZeRO 分片后每卡显存：

ZeRO 像“共享菜谱 + 传菜员跑腿”：菜谱确实不再人手一套，但借阅次数多了。所以 ZeRO 也要控制好 DP 规模，否则通信走廊又会堵塞。

Mshard=(2+2+Copt)θNDP+A\displaystyle M_{shard} = \frac{(2 + 2 + C_{opt})\theta}{N_{DP}} + A
优化器状态、梯度、参数按数据并行维度分片，单卡显存随 DP 度近似线性下降。
  1. 分子（总字节）模型权重、梯度、优化器状态三者占用的全部显存。
    (2+2+Copt)θ\displaystyle (2 + 2 + C_{opt})\theta
  2. N_DP（分片数）ZeRO 按数据并行度把上述状态切成多少份。
    NDPN_{DP}
  3. 相除（每卡份额）每张卡只保存全部状态的 1/N_DP，而不是完整副本。
    (2+2+Copt)θNDP\displaystyle \frac{(2 + 2 + C_{opt})\theta}{N_{DP}}
  4. A（激活值）激活值不参与分片，仍是每卡独立计算并暂存。
    AA

成本效益评估

回到财务视角。请了 64 位厨师（64 张卡），真正的“上菜效率”提升了多少？理想情况下，卡数是 10 倍，速度也应快到 10 倍，但通信、气泡、负载不均会让实际加速比打折扣。扩展效率是衡量这一损失的标尺：

吞吐量指标还要看“每卡每秒处理的 token 数”或 MFU（模型浮点利用率）。好的混合并行配置能把 MFU 保持在 40%~60% 以上，盲目组合经常跌破 20%。

花钱要花在刀刃上：与其无限堆卡，不如评估更高带宽的网络、优化切分粒度、改善通信调度。选型不是选最复杂的，而是选每卡吞吐最高的方案。

Escaling=SrealNGPU×100%\displaystyle E_{scaling} = \frac{S_{real}}{N_{GPU}} \times 100\%
效率 100% 是完美线性加速，实际通常在 60%~90%。效率过低说明并行策略和集群不匹配。
  1. S_real（实测加速比）N 张卡训练吞吐量相对单卡的提升倍数，来自实测数据。
    SrealS_{real}
  2. N_GPU（总卡数）名义上的最大加速倍数。
    NGPUN_{GPU}
  3. 相除（效率）实际加速除以理想加速，反映并行化带来的损耗。
    E=SrealNGPU\displaystyle E = \frac{S_{real}}{N_{GPU}}
  4. 工程标准效率高于 80% 可接受，低于 50% 必须排查通信或负载不均。
    E>0.8E > 0.8

实战踩坑清单

经验都是用事故换来的。第一个坑是“盲目堆卡”：客人多就加厨师，结果走廊堵成一锅粥。第二个坑是“忽视通信瓶颈”：明明 μ 已经 1.4 还在加 DP，训练反而变慢。第三个坑是“忽略拓扑约束”：把 TP 铺到跨节点，传菜绕整个大厅。第四个坑是“显存超配”：只算参数不算激活值，跑一半 OOM。

总结一个健康判据：

实践中的正确姿势是“先算账再开卡”：用显存公式估算放不放得下，用通信公式估算快不快，用效率曲线验证是否线性，最后小规模实验（比如 8 卡试跑）验证后再大规模铺开。

后厨的成熟不在于菜谱多，而在于知道什么时候用哪套排班。同样的 GPU，策略选对，训练效率能差一倍以上。

μ=TcommTcalc<1\displaystyle \mu = \frac{T_{comm}}{T_{calc}} < 1
只有当通信时间明显小于计算时间时，当前策略才是健康的。μ 大于 1 就该调整并行维度。
  1. T_comm（实测通信时间）用 profiler 测一轮梯度同步的墙钟时间。
    TcommT_{comm}
  2. T_calc（实测计算时间）测同一轮前向反向纯计算时间。
    TcalcT_{calc}
  3. 小于 1（健康）计算占主导，通信不拖后腿，当前配置合理。
    μ<1\mu < 1
  4. 大于 1（危险）通信占主导，优先缩小跨节点通信量或换成 TP/PP 结构。
    μ>1\mu > 1

AI 应用场景

大模型训练平台的策略自动推荐

阶段：训练任务编排

解决的问题：人工选择并行策略全凭经验，经常出现显存放不下、通信占满导致的训练超时。AI 平台可根据用户提交的模型参数量、单卡显存、节点拓扑，自动套用显存公式和通信比公式，输出最优 TP/PP/DP 组合。

具体案例：某 MLOps 平台接入 70B 模型训练任务，用户只填了模型参数和卡数，平台自动推荐 TP=8、PP=4、DP=2 的配置，并生成训练启动参数，训练效率比人工选型提升 40%。

千亿模型推理服务的 TP/PP 切分

阶段：推理部署

解决的问题：70B 以上模型单卡放不下，张量并行度过大导致首 Token 延迟飙升。推理引擎需要像“后厨排班”一样，在显存约束和延迟目标之间找到最优切分。

具体案例：某推理平台对 175B 模型自动选择 TP=4 + PP=2 的切分，并用微批次流水线填充气泡，首 Token 延迟从 8 秒降到 2 秒，吞吐提升 3 倍。

多租户 GPU 集群的拓扑感知调度

阶段：资源调度

解决的问题：多团队共享异构集群，不同并行策略对拓扑的要求不同，盲目分配导致性能剧烈波动。调度器可利用拓扑感知能力，把 TP 任务优先分配在同一台 8 卡机器内，把 DP 任务分散到不同机器实现负载均衡。

具体案例：某公司集群调度器根据任务声明的并行维度，自动完成“节点内放置”与“跨节点打散”，集群整体有效利用率从 35% 提升到 68%。

Python 演示

python61 行
"""混合并行策略选型计算器：输入模型规模与集群配置，输出推荐方案"""  def estimate_memory(theta_b, tp=1, dp=1, dtype_bytes=2):    """估算单卡显存占用（GB）。     theta_b: 模型参数量（十亿），例如 7 表示 70 亿参数。    简化模型：权重按张量并行切分，优化器状态按数据并行分片（ZeRO 风格）。    """    weight = theta_b * dtype_bytes          # 权重参数    grad = theta_b * dtype_bytes            # 梯度    optimizer = theta_b * 4 * 2             # AdamW: fp32 主权重 + 一阶 + 二阶    model_part = (weight + grad) / tp    opt_part = optimizer / dp    activations = 2.0                       # 激活值余量占位（GB）    return model_part + opt_part + activations  def suggest_strategy(theta_b, mem_gb, node_gpus=8, nodes=1, bandwidth_ratio=12):    """根据模型大小与集群规模给出并行策略建议。"""    total_gpus = node_gpus * nodes     # 1. 小模型：单卡轻松放下，直接数据并行    if theta_b <= 3 and estimate_memory(theta_b, 1, 1) <= mem_gb * 0.8:        return {"策略": "DP", "tp": 1, "dp": total_gpus, "pp": 1}     # 2. 模型大到单路 TP 都放不下：需要 3D + ZeRO    if estimate_memory(theta_b, tp=1, dp=total_gpus) > mem_gb:        tp = min(8, node_gpus)        pp = max(1, round(theta_b / 20))        dp = max(1, total_gpus // (tp * pp))        return {"策略": "3D+ZeRO", "tp": tp, "pp": pp, "dp": dp}     # 3. 跨节点带宽差：节点内 TP + 跨节点 DP    if bandwidth_ratio > 10:        tp = min(4, node_gpus)        dp = max(1, total_gpus // tp)        return {"策略": "TP+DP", "tp": tp, "dp": dp, "pp": 1}     return {"策略": "DP", "tp": 1, "dp": total_gpus, "pp": 1}  def demo():    """演示不同规模模型的选型结果。"""    cases = [1, 7, 70, 175]    for theta in cases:        result = suggest_strategy(theta, 80, 8, 4, 12)        per_gpu = estimate_memory(theta, result["tp"], result["dp"])        print(f"{theta}B 模型: {result} 预估单卡显存 {per_gpu:.1f}GB")  def main():    theta = float(input("请输入模型参数量（十亿）："))    mem = float(input("请输入单卡显存（GB）："))    nodes = int(input("请输入节点数："))    result = suggest_strategy(theta, mem, 8, nodes, 12)    print(result)  if __name__ == "__main__":    demo()
目的：实现一个简化版“选型计算器”，根据模型参数量、单卡显存、节点拓扑，自动推荐数据并行、张量并行、流水线并行或 3D+ZeRO 组合。
  1. weight = theta_b * dtype_bytes模型权重按字节数折算成显存占用，BF16 下每参数 2 字节。
  2. optimizer = theta_b * 4 * 2AdamW 每参数要存 fp32 主权重（4 字节）加两个动量（各 4 字节），共 12 字节。
  3. model_part = (weight + grad) / tp张量并行把权重和梯度切分到多卡，每卡只占 1/TP。
  4. if theta_b <= 3 and estimate_memory(...)小模型单卡放得下时直接数据并行，避免无谓通信。
  5. estimate_memory(theta_b, tp=1, dp=total_gpus) > mem_gb即使优化器状态全部分片都放不下，说明需要 TP 切分权重。
  6. tp = min(8, node_gpus)张量并行度不超过单节点卡数，避免跨节点频繁 AllReduce。
  7. dp = max(1, total_gpus // (tp * pp))数据并行度用剩余卡数补齐，保证总卡数等于三维乘积。

常见误区

误区只要卡够多，数据并行什么模型都能训，反正每卡都有一份完整模型副本。

正解70B 模型在 BF16 下仅权重就占 140GB，单卡 80GB 放不下，数据并行根本启动不了。必须先靠张量并行或 ZeRO 把权重切碎。就像后厨台面放不下整本菜谱，给所有厨师人手一本也白搭，得先把菜谱拆开。

为何常见：数据并行是入门最先接触、代码最简单的方式，遇到瓶颈时第一反应就是“多开几个数据并行副本”。

误区把集群里所有 GPU 都甩上去训练，速度肯定最快，反正算力翻倍了。

正解通信开销随数据并行规模近似线性增长。当通信计算比 μ 超过 1 后，加卡反而变慢。需要先做扩展性测试，画出效率曲线再决定卡数。就像后厨加厨师但走廊不扩宽，多的人都堵在传菜口。

为何常见：直觉上认为资源翻倍速度就翻倍，忽略了并行系统的 Amdahl 效应和通信成本。

误区TP=8 能把显存省 8 倍，那肯定设得越大越好，反正层内参数被切得越碎。

正解TP 在每个 Transformer 层前向和反向都要做至少两次 AllReduce，TP 越大同步频率越高、路径越长，通信量不省反增。小模型上 TP=2 往往比 TP=8 更快。省下的显存可能被通信时间完全吃掉。

为何常见：只盯着显存收益，没算通信账，忽视了张量并行对带宽的高度依赖。

误区流水线并行按层切分，各卡各跑一段，看起来像接力赛，应该天然高效。

正解流水线有气泡（bubble），第一批前向和最后一批反向时大量设备空转，朴素实现下浪费可达 20%~40%。需要引入 micro-batch 和 1F1B 调度来填充气泡。

为何常见：只看到“分阶段并行”的直观图，没意识到每一段之间的依赖会造成等待。

误区DP+TP+PP 都开了就是 3D 并行，配置就是三个数相乘，都不用管顺序。

正解维度之间有强依赖：TP 必须限制在节点内部，PP 应在 TP 之后按层划分，DP 放最外层；还要考虑 ZeRO 分片和通信调度。组合不当会让通信量爆炸式增长，效率远低于单一策略。

为何常见：教程里 3D 并行只是画一个三维网格，掩盖了底层拓扑约束和通信开销的差异。

面试题

Q1. 一个 1B 参数小模型可以完整放进单张 80GB 显卡，集群有 8 张 NVLink 高速互连卡。此时最适合的并行策略是？

单选题 · easy

  • A.数据并行（梯度同步占优）← 正确答案
  • B.张量并行（切分矩阵至细粒度）
  • C.流水线并行（按层切分推理链）
  • D.混合并行（三种策略全平铺）

答案：A。模型单卡装得下，数据并行最简单高效，只需复制模型并同步梯度。张量和流水线并行是为“放不下”设计的，过度使用只会引入不必要的通信开销。就像小宴会一人一口锅足矣，不必把菜拆碎了分工协作。

Q2. 训练 7B 模型时，把张量并行度从 4 提升到 8，通信开销一般会如何变化？

单选题 · mid

  • A.通信开销保持不变
  • B.通信开销显著下降
  • C.通信开销显著上升← 正确答案
  • D.通信开销先升后降

答案：C。张量并行度提升后，每次前向/反向的 AllReduce 要在更多卡之间完成，同步路径更长、聚合延迟更高，通信开销通常显著上升。TP 省显存的代价是通信变贵，这正是 TP 必须限制在单节点内的原因。

Q3. 流水线并行最明显的性能缺陷是什么？

单选题 · easy

  • A.每张卡显存占用翻倍
  • B.计算阶段存在空转气泡← 正确答案
  • C.各层权重完全不一致
  • D.无法使用批量归一化

答案：B。流水线并行在第一批前向和最后一批反向时，大量设备处于等待状态，形成“气泡”。气泡大小与流水线段数正相关，需要用 micro-batch 填充。显存翻倍、权重不一致等说法不符合流水线并行原理。

Q4. 三维并行中，张量并行所在的维度一般应满足什么拓扑约束？

单选题 · mid

  • A.优先限制在一台节点内← 正确答案
  • B.跨越尽可能多的机柜
  • C.与数据并行共用一交换机
  • D.避开 NVLink 使用以太网

答案：A。张量并行每层都要做 AllReduce，通信最频繁，必须放在带宽最高的节点内部（NVLink 域）。跨机柜会让每次同步走慢速网络，训练吞吐断崖式下跌。

Q5. 某 70B 模型用 BF16 训练，单卡显存 80GB，仅权重就约 140GB。最合理的做法是？

单选题 · mid

  • A.张量并行加流水线并行← 正确答案
  • B.单卡优化提高吞吐量
  • C.只增加数据并行度
  • D.缩小批大小不换策略

答案：A。70B 权重远超单卡显存，必须通过张量并行切分权重、流水线并行按层分段，再配合 ZeRO 分片优化器状态。单卡优化和缩批次都不能解决“物理上放不下”的问题；纯数据并行要求每卡放完整模型，同样不可行。

Q6. 混合并行选型时需要重点评估的因素有哪些？

多选题 · mid

  • A.模型参数量与显存占用← 正确答案
  • B.集群互联拓扑与带宽← 正确答案
  • C.训练数据集的标注质量
  • D.梯度同步的通信开销← 正确答案

答案：ABD。选型本质是求解“显存放得下、通信不拥堵”的配置。模型参数量决定显存预算，拓扑和带宽决定通信成本，梯度同步开销决定数据并行是否可行。数据标注质量影响模型效果，但不影响并行策略选择。

Q7. 以下关于 ZeRO 的表述正确的有？

多选题 · hard

  • A.按维度切分优化器状态← 正确答案
  • B.彻底消除跨卡通信全部开销
  • C.让每卡只存一部分冗余数据← 正确答案
  • D.只能与张量并行搭配使用

答案：AC。ZeRO 的核心是把优化器状态、梯度、参数按数据并行维度分片，消除冗余副本。但它只是把“存储冗余”换成“按需通信”，通信开销依然存在，并非完全消除；它既可与数据并行搭配，也可与 TP/PP 组合成 3D 并行。

Q8. 实测某训练任务 μ = T_comm / T_calc = 1.4，此时合理的调整方向是？

单选题 · hard

  • A.减少通信或增大并行计算粒度← 正确答案
  • B.增大数据并行度继续堆卡
  • C.直接切换到张量并行最高档
  • D.关闭梯度压缩并提高精度

答案：A。μ 大于 1 说明通信时间占主导，继续加数据并行只会让通信更拥堵；切到最高 TP 同样加剧 AllReduce 开销。正确方向是压缩通信（梯度压缩、减少同步频率）或调整计算粒度，让计算重新成为主导。

Q9. 数据并行通信量公式 T_comm = 2 × N × θ 中，符号 θ 代表什么？

单选题 · easy

  • A.代表参与并行的卡数
  • B.代表模型参数量← 正确答案
  • C.代表通信计算比
  • D.代表扩展效率值

答案：B。θ 是模型参数量，例如 7B 模型 θ=70 亿。参数量越大，每轮梯度同步要传输的数据越多。N 是参与并行的卡数，μ 是通信计算比，E 才是扩展效率。

Q10. 以下哪些组合在实战中常见且合理？

多选题 · mid

  • A.数据并行和流水线并行组合← 正确答案
  • B.数据并行和张量并行组合← 正确答案
  • C.张量并行跨越多个远程机柜
  • D.流水线气泡用微批次填充← 正确答案

答案：ABD。DP+PP、DP+TP 都是经典组合，分别解决“模型分层放不下”和“层内切分放不下”的问题。流水线气泡用 micro-batch 填充是标准优化手段。而 TP 跨远程机柜会让高频 AllReduce 走慢速网络，属于典型错误配置。