想象你是一家高档餐厅的主厨，要为一桌客人上一道「佛跳墙」。这道菜工序繁多，一个人做太慢，于是你让几位厨师分工：一位负责鲍鱼、一位负责海参、一位负责高汤。这就是张量并行——把一个大模型切分成几份，让多块 GPU 各算一部分。 但问题来了：每位厨师做完自己的部分后，必须把成果跟其他人「对一下」——鲍鱼要并入汤里，海参要摆进盅中，最终的菜才能完整上桌。这份「对菜单、传菜、汇总」的时间，就是通信开销。 人越多，每位厨师真正炒菜的时间变短了，但互相传菜、确认口味的时间却一点没少。当传菜时间超过炒菜时间，加人反而更慢。这就是张量并行最核心的困境：GPU 数量增加时，通信量与计算量的比值不断上升，并行效率随之下降。本文就带你把这个「后厨总账」算清楚，并看看通信计算重叠、梯度累积、拓扑优化这三招，如何让几十人甚至上千人协作时依然高效。

岗位关联

对 AI 从业者而言，理解通信开销分析，是配置大模型分布式训练、避免「百万算力只跑出一半效率」悲剧的关键基本功。它能直接指导千卡集群中的并行度选择，是 AI 基础设施工程师的核心能力。

目录
  1. 可视化演示
  2. 通信原语基础
  3. 通信量推导
  4. 扩展率分析
  5. 优化策略
  6. 并行度选择
  7. 生产实践
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

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

通信原语基础

后厨开工了。佛跳墙需要 8 位厨师每人守住一个炖盅，各自炖一味料。但上菜前，主厨必须确认「每一位客人的盅里都有全部八味料」。于是有了两种传菜方式：All-Reduce 就像大家把各自的料汁倒进一个大盆，混匀后再平均分回每个人的盅里——所有人都拿到一模一样的「综合配方」；All-Gather 则像每个人把自己做好的那块端到台面上，拼成一整份完整摆盘——所有人都能看到完整的成品是什么样。

在张量并行中，这两种操作分别出现在不同阶段。当网络前向传播的输出需要汇总求和时（比如列并行后的输出投影），用 All-Reduce；当某个 GPU 持有一块切分后的激活张量、而后续算子需要完整张量时（比如残差连接和 Dropout 之前），用 All-Gather。理解它们的关键是：通信的内容是「完整维度」的张量，而不是切分后的小块——因为最终每个人都必须拿到整体信息。

通信的信息量由激活张量决定。设 batch 大小为 b、序列长度为 s、隐藏层宽度为 h、每个数值占 d 个字节（float32 为 4），那么一次 All-Reduce 传输的消息大小为 b·s·h·d，与切了几块无关——就像传菜时你得传「完整的一道菜」而不是「半道菜」。

回到后厨：无论后厨有 2 个人还是 32 个人，「把完整配方分给每个人」这件事要传的总料汁量是不变的。这份「不变的传菜量」与「越分越少的炒菜量」之间的赛跑，正是通信开销的核心矛盾。

Mlayer=4×b×s×h×dM_{\text{layer}} = 4 \times b \times s \times h \times d
这个公式表示：一个 Transformer 层张量并行前向加反向共做 4 次集合通信，每次消息都是 b·s·h·d 字节。消息大小只由模型和 batch 决定，与 GPU 数量无关。
  1. b（Batch）一次迭代中的样本数。batch 越大，每条消息的元素越多，通信量越大。
    bb
  2. s（Sequence Length）序列长度，即每个样本的 token 数。
    ss
  3. h（Hidden Size）隐藏层宽度，是模型规模的核心指标。h 越大，单个张量越大。
    hh
  4. b×s×h（消息元素数）激活张量的总元素数量，这是通信消息的「体积」。
    b×s×hb \times s \times h
  5. ×d（字节换算）每个元素占 d 字节，float32 时 d=4。
    Mmsg=b×s×h×dM_{\text{msg}} = b \times s \times h \times d
  6. ×4（通信次数）前向 2 次 All-Reduce/All-Gather、反向 2 次，共 4 次，得到总通信字节数。
    Mlayer=4×b×s×h×dM_{\text{layer}} = 4 \times b \times s \times h \times d

通信量推导

既然传菜量不变，那炒菜量呢？主厨发现：8 位厨师各炖一味，每位厨师的活只有原来的八分之一。设单 GPU 每层计算量为 72·b·s·h²，切分成 t 份后，每个 GPU 只需算 72·b·s·h²/t。计算被平分，通信却原封不动——这就是效率流失的根源。

现在把两边都换算成时间。设单卡算力为 P（每秒浮点运算次数）、通信带宽为 B（每秒字节数）。计算时间是「工作量 ÷ 算力」，通信时间是「消息字节数 ÷ 带宽」。两者相除，得到通信计算比 R——它衡量「传菜时间」相对于「炒菜时间」有多长。

这个公式给主厨的启示很扎心：后厨越大（t 大），传菜占比越高；灶台火力越猛（P 大），反而显得传菜越慢——因为菜熟得太快，等传菜的时间占比更大了。只有把过道修宽（B 大）或让每道菜更费功夫（h 大），通信占比才会被稀释。

R=TcommTcalc=t×P×d18×h×BR = \frac{T_{\text{comm}}}{T_{\text{calc}}} = \frac{t \times P \times d}{18 \times h \times B}
R 是通信时间与计算时间的比值。R 越大，GPU 花在「传菜」上的时间比例越高，并行越不划算。这个公式揭示了四个关键趋势：并行度 t 越大、单卡算力 P 越高、数值精度 d 越大，通信占比越高；隐藏层 h 越宽、带宽 B 越大，通信占比越低。
  1. 单 GPU 每层计算时间每层总计算量 72·b·s·h² 被 t 个 GPU 平分，除以单卡算力 P。
    Tcalc=72×b×s×h2t×PT_{\text{calc}} = \frac{72 \times b \times s \times h^2}{t \times P}
  2. 每层通信字节数4 次集合通信，每次 b·s·h·d 字节。
    Ncomm=4×b×s×h×dN_{\text{comm}} = 4 \times b \times s \times h \times d
  3. 每层通信时间字节数除以带宽 B。
    Tcomm=4×b×s×h×dBT_{\text{comm}} = \frac{4 \times b \times s \times h \times d}{B}
  4. 两者相除通信计算比等于通信时间除以计算时间。
    R=TcommTcalc=4×b×s×h×d/B72×b×s×h2/(t×P)R = \frac{T_{\text{comm}}}{T_{\text{calc}}} = \frac{4 \times b \times s \times h \times d / B}{72 \times b \times s \times h^2 / (t \times P)}
  5. 约分化简分子分母中的 b、s、h 约去，常数 4/72 化简为 1/18，得到最终表达式。
    R=t×P×d18×h×BR = \frac{t \times P \times d}{18 \times h \times B}

扩展率分析

假设 t=1 时，一位全能厨师 10 分钟炖好一盅佛跳墙。现在请来 t 位厨师，理论上每位只需 10/t 分钟。可现实是：每位厨师做完都要花固定的 0.12 分钟「对菜单」（通信）。t=4 时，炒菜只需 2.5 分钟，总耗时 2.62 分钟，还算划算；t=32 时，炒菜 0.31 分钟，传菜却还是 0.12 分钟（按前文模型，通信的计算量占比已超过实际？这里用固定 C 示意）——传菜从「小插曲」变成了「主角」。

设 A 为 t=1 时的单层计算时间参数，C 为固定通信时间参数，则并行效率 E(t) 等于「实际计算时间占总时间的比例」：

沿用后厨场景：传菜时间 C 好比厨房过道固定的通行时间。无论切菜多快，这 0.12 分钟的「过道费」省不掉——人越多，每人摊到的炒菜时间越短，「过道费」占比就越刺眼。当 t 超过某个值，加人不仅不提速，反而是在给过道添堵。

E(t)=A/tA/t+C=AA+C×tE(t) = \frac{A / t}{A / t + C} = \frac{A}{A + C \times t}
E(t) 表示 t 个 GPU 相比 1 个 GPU，算力被「有效利用」的比例。当 t 从 1 增长到 32，分母中的 C×t 不断变大，E 不断走低。这就是并行效率随 GPU 数量增加而下降的数学本质。
  1. A（计算时间常数）t=1 时完成单层计算所需的时间参数，它等于计算量除以算力。
    A=72×b×s×h2PA = \frac{72 \times b \times s \times h^2}{P}
  2. A/t（分摊后的计算时间）计算被 t 个 GPU 平分，理想线性加速。
    Tcalc=AtT_{\text{calc}} = \frac{A}{t}
  3. C（固定通信时间）每次前向加反向的通信开销，与 t 无关。
    Tcomm=CT_{\text{comm}} = C
  4. 总时间与效率效率 = 计算时间 ÷ 总时间。分子分母同乘 t，得到关于 t 的显式表达式。

优化策略

面对传菜瓶颈，主厨有三招。第一招是通信计算重叠：以前厨师要等菜传完才开始下一道，现在改成——鲍鱼炖着的同时，先把炖盅递给下一位（通信与计算并行）。把 All-Reduce 拆成小块，与矩阵乘的按行计算交替执行，通信就被「藏」在计算背后。完美重叠下，耗时不再是两者相加，而是取较大者：

第二招是梯度累积。多个小 batch 的梯度先在本地攒着，攒够一批再做一次同步，把「一趟趟跑过道」变成「一趟推车送完」。注意它减少的是通信的启动次数而非单次数据量——这对很多小消息通信的场景尤其有效。第三招是拓扑优化：把传菜动线重新设计——机内用 NVLink 高速通道（像后厨内的传送带），跨节点用 RDMA 网络，优先让 TP 通信只走最快的 NVLink，避免掉进慢速跨机网络。

回到后厨：重叠是「边炖边传」，梯度累积是「攒车发货」，拓扑优化是「重修动线」。三招组合起来，即便 32 个人的后厨，也能把传菜时间压到看不见。

Topt=max⁡(Tcalc,Tcomm)T_{\text{opt}} = \max(T_{\text{calc}}, T_{\text{comm}})
完美重叠意味着通信和计算同时进行，总耗时只由较慢的一方决定。虽然实际中无法做到 100% 重叠，但这个公式给出了理论下界——也是优化效果的标杆。
  1. T_calc（计算时间）单层矩阵乘所需时间，随 t 增大而缩小。
    TcalcT_{\text{calc}}
  2. T_comm（通信时间）单层集合通信所需时间，与 t 基本无关。
    TcommT_{\text{comm}}
  3. max 取较大者重叠后两者并行执行，总耗时由慢的一方决定。
    max⁡(Tcalc,Tcomm)\max(T_{\text{calc}}, T_{\text{comm}})
  4. 意义优化目标就是把 T_calc 和 T_comm 的差距拉平，让两者始终在并行跑，谁也别干等谁。

并行度选择

主厨面临一个现实问题：后厨到底该招多少人？选并行度不是越大越好，而是要看「灶台」（单节点 GPU 数）和「过道」（带宽）。工程上有条铁律：张量并行度一般不超过单节点内的 GPU 数（常见为 8）。原因是机内 NVLink 带宽可达 600 GB/s，而跨节点的网络带宽往往只有它的几十分之一——一旦 TP 通信跨节点，C 值爆炸式增长，再聪明的重叠也救不回来。

什么时候该用多大的 TP？关键在于临界并行度。当 t 增大到某个值时，通信时间反超计算时间，效率跌破 50%，此后加人就是负收益。这个临界值由计算与通信的比值决定：

在实际训练中，不能只看 TP 一个维度。一张 8 卡 A100 节点用 TP=8 把模型切到极致，但想要扩展到几百卡，就得靠数据并行（每张卡跑同样的模型副本、不同数据）和流水线并行（按层分段）来组合。混合并行的原则是：TP 管「单机内切得动」，DP 管「扩到千卡」，PP 管「塞进显存」。

t∗=ACt^{\ast} = \frac{A}{C}
t* 是并行效率恰好为 50% 的临界并行度。当 t < t* 时，加人收益明显；当 t > t* 后，通信已占主导，继续扩大 TP 只会浪费资源。工程上通常把 t 控制在 t*/2 以内，保证效率在 70% 以上。
  1. A（计算时间常数）与模型规模和单卡算力有关，模型越大 A 越大。
    AA
  2. C（通信时间常数）与带宽和通信次数有关，带宽越高 C 越小。
    CC
  3. 比值 A/C计算时间相当于几个通信时间；比值越大，能承受的并行度越高。
    AC\frac{A}{C}
  4. 临界值含义当 t = A/C 时，通信时间等于计算时间，效率为 50%。
    E(t∗)=AA+C×(A/C)=12E(t^{\ast}) = \frac{A}{A + C \times (A/C)} = \frac{1}{2}

生产实践

千卡集群的「千人宴」怎么组织？业界常见的配置是：每节点 8 卡组成一个 TP=8 组，一起吃透一份模型；多个节点之间用 DP 并行处理不同 batch；若模型大到单节点装不下，再加 PP 按层切。这样，TP 的通信被牢牢锁在 NVLink 高速过道内，跨节点的慢速网络只承担低频的梯度同步。

端到端效果如何？定义集群有效利用率 μ = 实际计算时间占比 = 1/(1 + R̄)，其中 R̄ 是综合考虑所有并行维度后的平均通信计算比。在千卡级训练中，TP=8 的老练配置通常能把 μ 维持在半数以上；而如果误把 TP 拉到 32，μ 会跌到三成以下——相当于一千张卡只有三百张在干活，GPU 利用率惨不忍睹。

从后厨到机房，逻辑一脉相承：合理分工 + 高效传菜 = 高吞吐。张量并行的通信开销不是洪水猛兽，只要算清楚 R 和 E，选定 t 小于临界值，再用重叠、累积、拓扑三招把通信藏起来，千人后厨也能井井有条。而这一切权衡的起点，正是你手中那支笔——把通信开销先算明白。

μ=11+Rˉ\mu = \frac{1}{1 + \bar{R}}
μ 是集群的「算力有效利用率」。R̄ 为平均通信计算比。R̄ 越高，μ 越低。这个公式把「传菜总账」浓缩成一个数字，是评估并行方案优劣的核心指标。
  1. R̄（平均通信计算比）把 TP、DP、PP 各维度的通信和计算统一折算后的比值。
    Rˉ=TcommtotalTcalctotal\bar{R} = \frac{T_{\text{comm}}^{\text{total}}}{T_{\text{calc}}^{\text{total}}}
  2. 1 + R̄（总时间因子）总时间 = 计算时间 × (1 + 通信计算比)。
    Ttotal=Tcalc×(1+Rˉ)T_{\text{total}} = T_{\text{calc}} \times (1 + \bar{R})
  3. 取倒数（有效占比）计算时间占总时间的比例。
    μ=TcalcTtotal=11+Rˉ\mu = \frac{T_{\text{calc}}}{T_{\text{total}}} = \frac{1}{1 + \bar{R}}
  4. 工程解读μ 越高 GPU 越「没白买」。业界千卡训练的合理目标是把 μ 维持在 50% 左右。

AI 应用场景

千卡集群并行策略配置

阶段：分布式训练配置

解决的问题：在 1024 卡集群上训练 GPT-3 级别大模型时，如果盲目把张量并行度提高到 16 或 32，通信开销会吞噬算力——实际吞吐可能比 TP=8 降低 40% 以上。AI 基础设施团队需要根据 h、P、B 计算通信计算比 R，从而确定「每节点 TP=8 + 跨节点 DP + 必要 PP」的组合方案。

具体案例：某团队训练 175B 参数模型，原本在 512 卡上 TP=16，测出模型 FLOPs 利用率只有 28%。按 R 公式分析发现跨节点通信占比过高，改为 TP=8（单节点）+ DP=64，利用率提升到 47%，训练时间缩短约三分之一。

通信调度优化

阶段：训练框架底层算子调度

解决的问题：通信与计算串行执行时，GPU 在等待 All-Reduce 期间完全空闲，白白浪费算力。通过把 All-Reduce 拆分为与矩阵乘行块匹配的小块，并用 CUDA stream 让通信与计算并行，可大幅提高 GPU 利用率。

具体案例：Megatron 风格的框架在 Transformer 层内将 MLP 的计算与前一层的梯度 All-Reduce 做重叠调度，实测单层耗时从「计算+通信」的串行和降为接近 max（计算，通信）。训练吞吐提升 15%-30%，且无需改动模型代码。

硬件网络选型评估

阶段：集群基础设施规划

解决的问题：新建训练集群时，是采购更贵的 NVLink 服务器，还是加大跨节点网络带宽？用 R = t·P·d/(18·h·B) 可以定量评估：若单卡算力高但机内带宽不足，TP 通信占比会显著升高，此时投资机内互联比盲目堆卡更划算。

具体案例：某 AI 公司评估两个方案：A 方案单机 8 卡 NVLink 600GB/s，B 方案单机 8 卡 PCIe 300GB/s。按 h=8192、TP=8 测算，A 方案通信占比约 26%，B 方案约 45%，最终选择 A 方案并在节点间用 InfiniBand 做 DP，训练效率领先 B 方案近一倍。

Python 演示

python22 行
# 模拟张量并行中通信开销对训练效率的影响def analyze_layer(tp_size, hidden, seq_len, batch, flops, bw, dtype_bytes=4):    """计算单 GPU 每层计算时间、通信时间和并行效率"""    calc_flops = 72.0 * batch * seq_len * hidden * hidden / tp_size    calc_time = calc_flops / flops    comm_bytes = 4.0 * batch * seq_len * hidden * dtype_bytes    comm_time = comm_bytes / bw    total_time = calc_time + comm_time    efficiency = calc_time / total_time    return calc_time, comm_time, total_time, efficiency def main():    flops = 1e15           # 单卡算力约 1 PFLOP/s（新一代加速卡）    bw = 600e9             # 机内 NVLink 带宽约 600 GB/s    hidden, seq_len, batch = 8192, 2048, 2    print(f"{'TP':>4} {'计算(ms)':>10} {'通信(ms)':>10} {'总时间(ms)':>12} {'效率':>8}")    for tp in [1, 2, 4, 8, 16, 32]:        c, m, t, e = analyze_layer(tp, hidden, seq_len, batch, flops, bw)        print(f"{tp:>4} {c*1000:>10.3f} {m*1000:>10.3f} {t*1000:>12.3f} {e:>8.1%}") if __name__ == '__main__':    main()
目的：用 Python 复现通信开销量化模型，输入模型规模（hidden、seq_len、batch）、硬件参数（算力、带宽），输出不同张量并行度下的计算时间、通信时间和并行效率，直观呈现效率下降曲线。
  1. calc_flops = 72.0 * batch * seq_len * hidden * hidden / tp_size单 GPU 每层计算量：总计算量被 t 个 GPU 平分，所以除以 tp_size
  2. comm_bytes = 4.0 * batch * seq_len * hidden * dtype_bytes每层通信字节数：4 次集合通信，每次传完整激活张量，与 tp_size 无关
  3. calc_time = calc_flops / flops计算时间 = 计算量 ÷ 算力
  4. comm_time = comm_bytes / bw通信时间 = 字节数 ÷ 带宽
  5. efficiency = calc_time / total_time并行效率 = 计算时间占比，等价于正文的 E(t)
  6. for tp in [1, 2, 4, 8, 16, 32]遍历常见并行度，观察效率变化趋势
  7. print(...)表格化输出，方便对比 1/2/4/8/16/32 卡时效率如何从 100% 跌到 41%

常见误区

误区「多买几张卡把 TP 从 8 提到 16，训练速度应该翻倍吧？反正模型显存也装不下。」

正解这就像后厨从 8 人加到 16 人，但过道还是那么窄——每人炒菜时间减半，传菜却要等更久。TP 扩大后计算量确实减半，但通信字节数不变（消息大小与 t 无关），通信计算比反而线性上升。实测 TP=16 相比 TP=8 通常只快 10%-20%，甚至可能更慢。所以 TP 的选择要用 E(t) 公式验证，而不是直觉加卡。

为何常见：大家习惯性认为「并行度翻倍、速度翻倍」，忽略了 Amdahl 定律中不可并行部分（通信）的存在。加上厂商宣传「线性扩展」的误导，容易产生这个直觉。

误区「要给所有 GPU 同步数据，每多一块卡就要多传一份消息，通信量肯定随 GPU 数线性增长。」

正解恰恰相反，All-Reduce 的消息大小是 b·s·h·d，只由 batch、序列长度和隐藏层宽度决定，与切了几块无关。以环状 All-Reduce 为例，每块 GPU 发送约总消息量的一半（t 很大时趋于总消息量），增加 GPU 不会让单块卡的数据发送量按比例上涨。导致效率下降的真正原因不是「通信量变大」，而是「计算量变小而通信量不变」——比值上升了。

为何常见：把「总通信次数」和「单次消息大小」混淆了，也容易把数据并行中「梯度同步量随模型增大」的记忆错误迁移到张量并行上。

误区「既然可以把通信藏在计算后面，那通信开销就不是问题了，TP 调到 64 也没关系。」

正解重叠只是「掩盖」而非「消灭」。通信仍然占用带宽、占用 SM 资源、增加功耗，而且真实场景中矩阵乘和 All-Reduce 很难做到完美重叠——算子碎块化会降低计算效率，通信调度本身也有开销。完美重叠的理论极限是 max(T_calc, T_comm)，但当 T_comm 已经远大于 T_calc 时，再怎么重叠，总耗时也被通信时间卡死。

为何常见：看到优化示意图中「通信和计算并行」就以为开销清零，忽略了物理带宽上限和调度本身的代价。

误区「梯度累积把好几个 batch 的梯度攒起来一次同步，那张量并行的逐层 All-Reduce 也应该能省掉吧？」

正解注意区分两个维度的通信。张量并行每层前向/反向的 All-Reduce 是计算图的一部分——前向需要汇总各卡的部分结果，这一层通信无法用梯度累积跳过。梯度累积优化的是数据并行维度的梯度同步：原本每个 micro-batch 都要跨节点同步梯度，现在攒 N 个 micro-batch 只同步一次，通信启动次数降为 1/N，释放了网络资源，间接为 TP 的机内通信腾出带宽。两者是互补关系，不是替代关系。

为何常见：初学者容易把所有「通信」混为一谈，以为梯度同步是唯一的通信来源，忽略了张量并行中激活值汇总的逐层通信。

误区「跨节点通信慢？买更贵的交换机，把跨节点带宽提到和 NVLink 一样，TP 就能跨节点了。」

正解带宽只是通信时间的一个因子（T_comm = M/B），延迟和拓扑同样关键。TP 通信是逐层同步、低粒度高频的通信模式，即使带宽提升，跨节点时动辄几十微秒的延迟叠加在每层 4 次通信上，仍会产生巨大空转。加上 TP 通信必须等前一层的计算结果才能发起，天然串行。因此工程上 TP 仍以单节点为界，跨节点扩展交给 DP/PP——它们通信频率低、粒度大，才更适合慢速网络。

为何常见：把通信开销简化成「带宽不够」，忽略了通信模式（同步频率、依赖关系、拓扑）与并行策略的匹配关系。这就是为什么 TP 跨节点的方案在业界极少被采用。

面试题

Q1. 张量并行中，多个 GPU 将各自的部分结果求和后广播回所有 GPU，这个操作是？

单选题 · easy

  • A.广播 Broadcast
  • B.全规约 All-Reduce← 正确答案
  • C.点对点通信
  • D.分散 Scatter

答案：B。这就像所有厨师把料汁倒进大盆混匀再分回各盅。All-Reduce 的语义就是「所有节点先归约（求和/求平均），再把结果广播给所有节点」。Broadcast 是单源到多目的，Scatter 是分发不同切片，均不符合「归约后再广播」的语义。

Q2. 张量并行度从 1 增大到 t 时，单 GPU 的通信计算比 R 如何变化？

单选题 · easy

  • A.线性下降
  • B.保持恒定
  • C.线性上升← 正确答案
  • D.先升后降

答案：C。R = t·P·d/(18·h·B)，分子含 t 的一次项，所以 R 随 t 线性上升。原因是计算量被 t 平分而通信量不变。类比后厨：人越多，传菜时间相对炒菜时间的占比越高。A、B、D 都与公式结论矛盾。

Q3. 下列哪项是张量并行中缓解通信开销的有效手段？

单选题 · easy

  • A.通信计算重叠← 正确答案
  • B.弃用 All-Reduce
  • C.无限扩大并行度
  • D.隐藏层宽度减小

答案：A。通信计算重叠把通信藏在计算背后，总耗时趋近 max(T_calc, T_comm)。B 不现实——张量并行离不开集合通信；C 会放大 R；D 虽能降低每次通信量但也大幅削弱模型能力，不是「缓解通信」的手段。

Q4. 设 b、s、h、d 分别为 batch、序列长度、隐藏层宽度和数值字节数，一个 Transformer 层张量并行前向+反向的通信字节数约为？

单选题 · mid

  • A.2×b×s×h×d
  • B.b×s×h×d
  • C.8×b×s×h×d
  • D.4×b×s×h×d← 正确答案

答案：D。单次集合通信消息大小为 b×s×h×d，每层前向 2 次（Attention 输出和 MLP 输出）、反向 2 次，共 4 次，总字节数 4×b×s×h×d。选项 A 少算了一半，B 只算了一次，C 多算了一倍。

Q5. 通信计算比 R = t·P·d/(18·h·B) 中，增大哪个参数可以降低 R？

单选题 · hard

  • A.并行度 t
  • B.隐藏层 h← 正确答案
  • C.单卡算力 P
  • D.数值字节数 d

答案：B。h 在分母上，增大隐藏层宽度会摊薄通信占比——因为计算量随 h² 增长而通信量只随 h 线性增长。这相当于「菜做得更费工时，传菜占比自然下降」。增大 t、P、d 都会让 R 变大，通信相对更贵。

Q6. 临界并行度 t* = A/C 的含义是什么？

单选题 · mid

  • A.通信量最大的并行度
  • B.效率降至 50% 的并行度← 正确答案
  • C.计算时间最长的并行度
  • D.效率最高的并行度

答案：B。当 t = A/C 时，E(t) = A/(A + C·t) = A/(A + A) = 1/2，效率恰为 50%。低于它加人收益明显，高于它通信反客为主。A 是本末倒置，C 是计算时间最长（实际 t 越大计算越短），D 是误导项——效率最高的永远是 t=1。

Q7. 下列哪些手段可以缓解张量并行的通信瓶颈？（多选）

多选题 · mid

  • A.通信计算重叠← 正确答案
  • B.优化通信拓扑← 正确答案
  • C.梯度累积降频← 正确答案
  • D.无限扩大并行度

答案：ABC。通信计算重叠让通信与计算并行；拓扑优化（如环状 All-Reduce、TP 走 NVLink）降低通信耗时；梯度累积减少同步频率、释放网络资源——三者都是工程验证有效的「破局三招」。D 恰恰是加剧问题的错误做法。

Q8. 关于 All-Reduce 与 All-Gather 的说法，正确的有？（多选）

多选题 · mid

  • A.均为集合通信原语← 正确答案
  • B.消息大小与并行度无关← 正确答案
  • C.都只用于反向传播
  • D.都用于梯度同步

答案：AB。两者都让所有节点获得完整结果，属于集合通信；消息大小都是 b·s·h·d，与 t 无关。C 错——All-Gather 常用于前向传播恢复完整张量；D 错——All-Gather 更多用于激活值拼接而非梯度同步，梯度同步主力是 All-Reduce。

Q9. 关于张量并行生产实践的表述，正确的有？（多选）

多选题 · hard

  • A.通常限制在单节点内← 正确答案
  • B.与数据并行组合扩展← 正确答案
  • C.TP 可跨百卡节点扩展
  • D.梯度累积降低同步频率← 正确答案

答案：ABD。TP 通信依赖高速带宽和低延迟，单节点 NVLink 是理想载体，因此 A 对；跨节点扩展交给 DP/PP，B 对；C 错——跨节点 TP 会让通信计算比爆炸，百卡 TP 在实践中几乎不存在；D 对——梯度累积把多次小同步合并为一次，降低启动开销。

Q10. 已知通信计算比 R 与并行度 t 成正比，当 t=4 时并行效率为 80%，则 t=16 时效率约为？

单选题 · extreme

  • A.40%
  • B.60%
  • C.50%← 正确答案
  • D.25%

答案：C。效率公式 E = 1/(1 + k·t)。由 E(4)=0.8 得 1+4k=1.25，解得 k=0.0625。代入 t=16：E = 1/(1+16×0.0625) = 1/2 = 50%。这演示了通信开销随并行度扩大的「收益递减」——t 翻两番，效率却从 80% 滑落到 50%。