想象一个工程队要在一夜之间砌出一面“会思考的墙”——一个大语言模型。墙太长太厚，任何一个工人（GPU）的内存都装不下全部砖块和图纸。工头决定把墙面切成几段，每位师傅负责一段——这就是“张量并行”。可是这面墙不是普通的墙：每一层砖都必须和左右两段严丝合缝地咬合，才能让“思想”从砖缝间流过。于是师傅们不得不频繁传图纸、对砖缝、汇报心得。这些放下手里的活、跑来跑去开黑会的时间，就是“通信开销”。如果通信开销太大，墙可能砌得比单个人慢慢砌还慢——白并行了。这篇文章将带你搞懂：为什么张量并行离不开通信？通信量怎么算？瓶颈卡在哪？以及怎样让团队协作又快又省。

岗位关联

对 AI 从业者而言：理解并优化张量并行通信开销，是训练和推理大模型时选对并行策略、榨干每块 GPU 算力的核心基本功，直接决定训练吞吐与成本。

目录
  1. 可视化演示
  2. 通信必要成因
  3. 张量并行分片
  4. 通信量计算
  5. 通信时间模型
  6. 并行度选择
  7. 通信优化招数
  8. 工程实践要点
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

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

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

通信必要成因

夜深了，工地上灯光通明。工头老周看着图纸直发愁：这面“会思考的墙”全长七百亿块砖，别说一个工人，就算把全世界最强的工人请来，他的脑袋也装不下这面墙的全部图纸。于是他把墙切成 P 段，请来 P 位师傅合作。可是墙切开了，思想不能切开——每一层砖都必须左右对齐，才能让“信号”沿着墙面跑起来。这就注定师傅们不可能各砌各的，必须不断交流。

从技术上说，大模型的权重矩阵动辄几十上百 GB，远超单卡显存。张量并行把权重矩阵按行或列切成多份，让每个 GPU 只计算输出的一个切片。但前向传播时，下一层的输入需要看到完整的矩阵结果，因此必须把各卡的结果拼起来或加起来；反向传播时，梯度也需要跨卡求和再更新参数。所以通信不是“可选项”，而是切分后必然产生的“刚性成本”，躲不掉，只能想办法优化。

通信量可以用一条简单公式估算。设每个 GPU 上需要聚合的元素数为 M，并行度为 P，单次规约通信量约为：

老周把公式抄在本子上，叹了口气：既然躲不掉，就得算清楚这笔账——到底要搬多少砖、每次搬多久，才能决定这活儿值不值得多人干。

Q=2×M×P−1P\displaystyle Q = 2 \times M \times \frac{P-1}{P}
意思是：一次 All-Reduce 规约，每个 GPU 要收发的数据量约为它本地数据的 \(2(P-1)/P\) 倍。
  1. M 的含义M 是单个 GPU 上需要参与聚合的张量元素个数，比如某层输出张量大小为 batch×hidden，切分后每卡有 M/P 个元素。
    M=B×hM = B \times h
  2. P 的作用P 是张量并行度，即参与协作的 GPU 数量。P 越大，每卡分到的计算越少，但协作成本越高。
    P∈{2,4,8,… }P \in \{2, 4, 8, \dots\}
  3. 系数 (P-1)/P每个 GPU 需要从其他 P-1 个 GPU 获取数据，这些数据加起来占总数据量的比例。
    P−1P\frac{P-1}{P}
  4. 系数 2 的意义All-Reduce 不仅要“收”，还要“发”，数据在环形拓扑中绕一圈，发送量约为本地数据量的两倍。
    Q=2×M×P−1PQ = 2 \times M \times \frac{P-1}{P}

张量并行分片

怎么切墙？老周想出了两个方案：竖着切和横着切。竖着切时，每位师傅负责墙面的一竖条，砌好后把各段竖条并排拼成一面完整的墙——这叫“列并行”，对应集合通信里的 All-Gather（全收集拼接）。横着切时，每位师傅负责一横条，但为了保证上层砖能严丝合缝地叠上去，所有师傅必须把自己手里的部分砖块拿出来，相加成整砖后再用——这叫“行并行”，对应 All-Reduce（全规约求和）。

在实现中，列并行把权重矩阵 W 按列切成 P 份，每张卡持有 W 的一列切片，输入 X 完整复制到每张卡上，每卡算出的输出是完整输出的部分列。前向传播时需要用 All-Gather 把这些列拼成完整输出。行并行则把 W 按行切成 P 份，输入 X 也按列切成 P 份分发给各卡，每卡只得到部分和 \(X_i \times W_i\)，前向传播时必须用 All-Reduce 把所有部分和加起来。

这两种切法产生的通信量略有差别。设需要聚合的基础元素数为 M，并行度为 P：

老周点点头：横切虽然要多搬一次砖，但配合后面的激活函数和第二个线性层，反而能减少一次额外的拼接通信，实际工程里两种切法经常搭配使用。

Qcol=M×P−1P\displaystyle Q_{col} = M \times \frac{P-1}{P}
Qrow=2×M×P−1P\displaystyle Q_{row} = 2 \times M \times \frac{P-1}{P}
列并行做一次 All-Gather 只要拼数据；行并行做 All-Reduce 不仅要传所有数据，还要把结果求和并分发给所有人，通信量约为前者的两倍。
  1. M 的基础定义M 是输出张量的总元素数，例如 \(B \times h\)，B 是 token 总数，h 是隐藏维度。切分后每卡持有 M/P 个元素。
    M=B×hM = B \times h
  2. All-Gather 通信量列并行前向输出只需拼接。每个 GPU 把它的 M/P 份发给其他 P-1 个 GPU，所以总量是 \(M \times (P-1)/P\)。
    Qcol=M×P−1PQ_{col} = M \times \frac{P-1}{P}
  3. All-Reduce 通信量翻倍行并行输出需要求和，Ring 算法中数据块要绕环一周完成“传出去再收回来”两个方向，所以乘以 2。
    Qrow=2×M×P−1PQ_{row} = 2 \times M \times \frac{P-1}{P}

通信量计算

既然总要搬砖，就得算总账。老周让徒弟小李拿个本子，把每层墙要搬多少块砖记下来。小李发现，计算通信量不能只看一次操作，要顺着神经网络一层一层累加。

以 Transformer 的一个 MLP 层为例。设 B 是一次迭代的 token 总数（batch size × 序列长度），h 是隐藏维度。在大模型张量并行中，MLP 的两个线性层分别采用列并行与行并行，组合后每个 Transformer 层的前向和反向一共要做 4 次 All-Reduce（注意力模块 2 次，MLP 模块 2 次）。每次 All-Reduce 需要聚合的数据量约为 \(B \times h \times (P-1)/P\)。因此单个 Transformer 层在一次前后向传播中的通信量约为：

小李把本子递给老周：按这个公式，P=8 时每层要搬约 3.5 个 B×h 的数据量，P=2 时只搬约 2 个。多请人虽然算得快，但搬砖的总量也在涨。

Qlayer=4×B×h×P−1P\displaystyle Q_{layer} = 4 \times B \times h \times \frac{P-1}{P}
这个公式是估算通信量的主力公式：只要知道并行度 P、序列长度×批量大小 B、隐藏维度 h，就能快速算出每一层每步训练要搬多少元素。
  1. B 的定义B 代表一次前向/反向传播中处理的 token 总数，等于 batch_size 乘以序列长度。它决定每层输出张量有多少行。
    B=batch_size×seq_lenB = \text{batch\_size} \times \text{seq\_len}
  2. h 的定义h 是隐藏维度，即每层输出向量的长度。B×h 就是每层需要聚合的激活张量大小。
    h=hidden_sizeh = \text{hidden\_size}
  3. 因子 4 的来历一个 Transformer 层包含多头注意力和 MLP 两处张量并行，每处在一次前后向中要做 2 次 All-Reduce（前向一次、反向一次），所以总共 4 次。
    4=2(注意力+MLP)×2(前向+反向)4 = 2(\text{注意力} + \text{MLP}) \times 2(\text{前向+反向})
  4. 比例 (P-1)/P每次 All-Reduce 需要从其他 P-1 个 GPU 搬运的数据比例，随着 P 增大逐渐趋近于 1。
    P−1P→1(P→∞)\frac{P-1}{P} \to 1 \quad (P \to \infty)

通信时间模型

搬砖花的时间，不只是“路程”这么简单。老周发现，师傅在递砖前要先放下手里的活、走到交接点，这个固定准备动作叫“延迟”；然后才按每秒多少块的速度传，这叫“带宽”。如果每次都只递一块砖，来回走路的启动时间反而占大头。

通信时间可以用经典的“延迟带宽模型”描述。设每次消息传输的固定延迟为 α，传输单位数据耗时（带宽倒数）为 β，数据量为 M，并行度为 P。采用 Ring 环形 All-Reduce 时，数据块要绕环一周，总时间约为：

老周看着公式明白了：消息大时，第二项主导，带宽是关键；消息小时，第一项主导，再高的带宽也拯救不了被延迟拖慢的通信。真正的瓶颈藏在数据量和消息次数里。

Tallreduce=2(P−1)α+2(P−1)PβM\displaystyle T_{allreduce} = 2(P-1)\alpha + \frac{2(P-1)}{P}\beta M
第一项是延迟部分：环上每跳都有固定延迟，步数约 2(P-1)；第二项是带宽部分：总数据量 M 被拆成 P 份，每步传 M/P，但要走 2(P-1) 步。
  1. α 延迟项α 是发起一次消息传输的固定开销（微秒级），包括打包、握手、链路建立等，与数据量大小无关。
    α=latency\alpha = \text{latency}
  2. β 带宽项β 是传输单位数据所需时间，等于 1/带宽。数据量越大，这项占比越高。
    β=1bandwidth\beta = \frac{1}{\text{bandwidth}}
  3. 步数 2(P-1)Ring 算法中，每个数据块要经过 P-1 次转发，完成求和与分发还需要 P-1 次，合计 2(P-1) 步。
    2(P−1)2(P-1)
  4. 每步数据量 M/P总数据量被拆成 P 份，环上每个节点每步只传一份，所以每步传 \(M/P\)。
    MP\frac{M}{P}

并行度选择

老周开始纠结：到底请几位师傅最划算？人越多，每人砌的墙段越短，计算越快；可为了保证对齐，人越多，开黑会的时间也跟着变长。他掏出计算器，决定算一笔“投入产出比”。

关键指标是“有效算力利用率” η，它衡量 GPU 花在真实计算上的时间比例。设单卡计算时间为 \(T_{compute}\)，通信时间为 \(T_{comm}\)，则：

老周恍然大悟：P 不是越大越好。P 增大让计算时间按 1/P 缩小，但通信时间却在增长；一旦通信占比超过三四成，再增加并行度只会让总时间变长。此外，硬件互联带宽也决定了“安全 P 的上限”——如果卡间是 NVLink 高速互联，P=8 还很划算；如果跨节点走普通以太网，P=8 就是灾难。

η=TcomputeTcompute+Tcomm\displaystyle \eta = \frac{T_{compute}}{T_{compute} + T_{comm}}
因为张量并行中计算和通信在宏观上是串行的（除非做重叠优化），通信时间越长，GPU 真正算数的比例越低。η 越接近 1，并行效率越高。
  1. T_compute 单卡计算时间在理想切分下，单层计算量除以 P，再除以单卡算力。P 越大，每卡计算时间越短。
    Tcompute=FLOPsP×GPU_flopsT_{compute} = \frac{\text{FLOPs}}{P \times \text{GPU\_flops}}
  2. T_comm 通信时间用上一节的时间模型估算，包含延迟项和带宽项，随 P 增大而增加。
    Tcomm=2(P−1)α+2(P−1)PβMT_{comm} = 2(P-1)\alpha + \frac{2(P-1)}{P}\beta M
  3. η 的取值区间η 永远在 0 到 1 之间。当通信时间等于计算时间时，η = 0.5，意味着有一半时间在搬砖。
    η=11+Tcomm/Tcompute\eta = \frac{1}{1 + T_{comm}/T_{compute}}

通信优化招数

老周是个老匠人，总结出几招省时间的办法。第一招“边砌边听”——让一部分师傅继续干活，另一部分师傅去对砖缝，大家错开时间，这就叫计算通信重叠。第二招“攒砖一起搬”——不要每次递一块砖，把零碎小砖块捆成一大包再搬，减少传输次数，降低延迟项的影响。第三招“改传砖路线”——以前所有人跑回总库房汇总，现在让大家围成一圈挨个传，这就是 Ring All-Reduce；最后一招“精打细算”——把层归一化、Dropout 这些不依赖完整数据的计算也切到各卡上做，减少额外的激活集散，这叫序列并行。

计算通信重叠是收益最直观的一招。理想情况下，把当前层的通信和下一层的计算重叠起来，总时间不再是两者相加，而是取两者中的较大者：

老周很满意：只要调度得当，搬砖的时间几乎可以“藏”在砌墙的动作里。但越高级的调度对工程能力要求越高，所以还有最朴素的一招——先把方案算一遍，再动手。

Toverlap=max⁡(Tcompute, Tcomm)\displaystyle T_{overlap} = \max(T_{compute},\ T_{comm})
当通信完全被计算掩盖时，通信“免费”了。代价是需要更精细的流水调度，工程实现也更复杂。
  1. 重叠前的串行时间不重叠时，总时间是计算时间加通信时间，通信是明晃晃的额外开销。
    Tserial=Tcompute+TcommT_{serial} = T_{compute} + T_{comm}
  2. 重叠后的理想时间重叠后两部分同时进行，总时间由较慢的一方决定。
    Toverlap=max⁡(Tcompute, Tcomm)T_{overlap} = \max(T_{compute},\ T_{comm})
  3. 优化的启示想让重叠效果最好，应该让计算时间略大于通信时间，这样通信被完全隐藏。
    Tcompute≳TcommT_{compute} \gtrsim T_{comm}

工程实践要点

新工地开工前，老周总要拿出秒表和记录本：先测一测各个师傅到底花了多少时间在走路上，再对照图纸估算每层墙的理论搬运量，最后才决定用哪种切法、请几个人。这套方法放到真实的大模型训练中，就是性能分析加上理论估算。

实践中，首先用性能分析器（Profiler）看通信占比。PyTorch Profiler、NVIDIA Nsight Systems 都能给出每个 All-Reduce 耗时和 GPU 空闲率。如果通信占比超过 20%-30%，就要考虑调优。其次用公式做理论估算：代入并行度 P、隐藏维度 h、batch×seq_len 算出的 \(Q_{layer}\)，对比硬件带宽，判断瓶颈在延迟还是带宽。最后用框架内置优化兜底——Megatron-LM、PyTorch 的张量并行实现已默认开启通信计算重叠和高效的 NCCL 后端，直接使用比手写底层通信更稳妥。

老周在工地日志上写下三条铁律：先测后算，算完再切；P 要恰到好处，别贪多；优化优先选框架内置方案，实在不行才自己动手改通信。他把这些经验传给了徒弟，后来这支工程队砌墙又快又稳，再也没有出现过“人越多越慢”的尴尬局面。

AI 应用场景

千亿参数大模型训练中的 TP 选型

阶段：模型并行策略设计

解决的问题：训练 175B 参数模型时，单卡 80GB 显存放不下。传统做法是盲目把张量并行度开到 P=8，结果通信占比高达 60%，训练吞吐上不去。AI 工程师用每层通信量公式 \(4Bh(P-1)/P\) 估算各配置的通信占比，结合机内 NVLink 带宽，最终选择 TP=4 + 流水线并行 2 段 + 数据并行 8 路，吞吐提升约 30%。

具体案例：某公司在 A100 集群上训练 13B 模型，用公式算出 TP=8 时每层通信数据量约 3.5×B×h，而 TP=4 时约 3×B×h，通信时间降低约 30%，同时显存仍够用，最终训练效率显著提升。

在线推理服务的张量并行延迟优化

阶段：推理部署优化

解决的问题：张量并行推理时，batch 通常较小（如同时只有几十个请求），单条消息体很小，通信延迟占大头。传统做法只关注带宽，忽略了延迟项。工程师利用通信时间模型，把多次小 All-Reduce 合并成一次大通信，并开启计算通信重叠，首 token 延迟从 320ms 降到 240ms。

具体案例：某对话产品在 8 卡 A10 上部署 7B 模型，通过序列并行 + 合并梯度规约，把每 token 通信延迟降低约 25%，在线服务吞吐提升 18%。

多机多卡集群的通信瓶颈排查

阶段：性能调优

解决的问题：张量并行跨节点时，网络带宽远低于机内 NVLink，通信占比飙升至 70%。传统经验是“把卡数堆上去”，但 Profiler 显示瓶颈在网络跨节点通信。工程师调整并行策略，把张量并行限制在单机 4 卡内，跨节点改用数据并行，通信量下降一个数量级。

具体案例：某训练集群在 2 机 16 卡上训练 30B 模型，Profiler 显示跨节点 All-Reduce 耗时占 55%，改为机内 TP=4 + 跨机 DP=4 后，端到端吞吐提升 2.1 倍。

Python 演示

python26 行
import math def allreduce_time(M, P, alpha, bandwidth):    """Ring All-Reduce 通信时间：延迟项 + 带宽项，单位为秒"""    return 2 * (P - 1) * alpha + 2 * (P - 1) / P * M / bandwidth def layer_compute_time(tokens, hidden, gpu_flops):    """单个 Transformer MLP 层（两个线性层）的浮点运算量"""    flops = 16 * tokens * hidden * hidden    return flops / gpu_flops def analyze(P, tokens, hidden, alpha, bandwidth, gpu_flops):    """估算并行度 P 下，单个 MLP 层的计算/通信时间与通信占比"""    M = tokens * hidden    comm_s = allreduce_time(M, P, alpha, bandwidth)    compute_s = layer_compute_time(tokens, hidden, gpu_flops) / P    total_s = compute_s + comm_s    ratio = comm_s / total_s * 100    print(f"P={P:2d} | 计算 {compute_s*1000:8.2f} ms | 通信 {comm_s*1000:8.2f} ms | 通信占比 {ratio:5.1f}%")    return ratio if __name__ == "__main__":    print("张量并行 MLP 层通信开销模拟（tokens=4096, hidden=8192, A100 级）")    for p in [2, 4, 8, 16]:        analyze(p, tokens=4096, hidden=8192,                alpha=2e-6, bandwidth=300e9, gpu_flops=312e12)
目的：用公式模拟不同并行度 P 下的计算时间和通信时间，直观展示通信占比如何随 P 上升，帮助你先算账再选并行度。
  1. return 2 * (P - 1) * alpha + 2 * (P - 1) / P * M / bandwidth这就是 Ring All-Reduce 的时间模型：前一项是延迟，后一项是带宽传输。
  2. flops = 16 * tokens * hidden * hidden单个 MLP 层两个线性层的浮点运算量估算，作为计算时间的基础。
  3. compute_s = layer_compute_time(tokens, hidden, gpu_flops) / P理想情况下计算量被 P 张卡均分，计算时间近似线性下降。
  4. ratio = comm_s / total_s * 100通信占比是判断“是否该继续加 P”的关键指标，超过三成就该警惕。
  5. for p in [2, 4, 8, 16]:遍历不同并行度，让你一眼看到 P 从 2 到 16 时通信占比的变化趋势。

常见误区

误区显存不够就把张量并行度往上加，P=8 不够就 P=16，反正每张卡都能放下模型了，并行度越高训练越快。

正解P 越大，单卡计算量按 1/P 减少，但通信量却按 \((P-1)/P\) 趋近上限，延迟项 \(2(P-1)\alpha\) 还会随 P 线性增加。当通信占比超过计算收益时，加卡反而更慢。就像师傅越多，每人砌墙越轻松，但开会对齐的时间也越来越长，最后开会比干活还久。

为何常见：初学者直觉认为“人多力量大”，忽略了并行必然带来的协调成本，没有用通信占比去量化判断。

误区传 10GB 数据，带宽翻倍时间就减半，跟有多少张卡没关系，反正数据总量不变。

正解Ring All-Reduce 的时间包含延迟项和带宽项。即使带宽项随带宽翻倍减半，延迟项 \(2(P-1)\alpha\) 仍会随卡数增加而增长；数据块还要绕环多跳，实际经历的链路数是 P 的函数。带宽翻倍只解决了一半问题。

为何常见：把集合通信想成了简单的点对点传输，忽略了多卡协作中“多次启动、多次转发”的额外成本。

误区服务器内部有 NVLink，带宽几百 GB/s，张量并行通信根本不是问题，闭眼用大 P 就行。

正解NVLink 只解决单机内的带宽。张量并行一旦跨节点，走的是交换机或高速网络，带宽骤然下降一个数量级，延迟也更高。而且延迟项 α 与带宽无关，小块消息即使在高带宽环境下也会被启动延迟卡住。

为何常见：只盯着峰值带宽的数字，忽略了实际拓扑、消息大小和延迟对通信时间的双重影响。

误区反正都是把大家的数据汇总一遍，All-Gather 和 All-Reduce 的通信量应该差不多，优化时随便选一个就行。

正解All-Gather 只是把每卡的数据拼接分发，通信量约 \(M(P-1)/P\)；All-Reduce 需要把所有分片求和后再分发给每个人，Ring 算法中每个数据块要绕环一周，发送量约 \(2M(P-1)/P\)，接近两倍。选错通信原语，开销直接翻倍。

为何常见：没有区分“拼接后分发”和“求和后分发”在环形拓扑中实际的数据流动次数，低估了求和操作的额外开销。

面试题

Q1. 列并行（Column Parallel）的前向输出合并通常使用哪种集合通信？

单选题 · easy

  • A.All-Reduce 求和
  • B.All-Gather 拼接← 正确答案
  • C.Broadcast 广播
  • D.Reduce-Scatter 切片

答案：B。列并行把权重按列切开，每卡只算完整输出的一列切片，前向要做 All-Gather 把各列拼回完整矩阵。就像把墙竖着切成几段，砌完再把各段拼成一整面墙。

Q2. 行并行（Row Parallel）前向传播为什么需要 All-Reduce？

单选题 · easy

  • A.要把各卡输出拼接成完整矩阵
  • B.每卡只得到部分和需要相加← 正确答案
  • C.要把梯度广播给所有显卡
  • D.要把权重矩阵复制到每张卡上

答案：B。行并行中每个 GPU 算的是 \(X_i \times W_i\) 的部分积，只有把所有部分积相加才是完整输出，所以前向要做 All-Reduce 求和。就像横切墙时，每段砖都要叠在一起才能形成完整墙面。

Q3. Ring All-Reduce 中，传输的总数据量与并行度 P 的关系是？

单选题 · mid

  • A.与 P 成正比无限增长
  • B.约为 2M(P-1)/P 趋于饱和← 正确答案
  • C.恒等于单卡数据量 M
  • D.随着 P 增大反而减小

答案：B。Ring All-Reduce 的总数据量是 \(2M(P-1)/P\)，P 增大时它趋近于 2M，并不会无限增长。数据块绕环一周，收发各一次，所以系数 2 和 (P-1)/P 组合出饱和效果。

Q4. 通信时间 T = 2(P-1)α + 2(P-1)/P × βM 中，α 代表什么？

单选题 · mid

  • A.单位数据量的传输时间
  • B.一次消息传输的固定延迟← 正确答案
  • C.每张显卡的显存容量
  • D.并行度 P 的通信系数

答案：B。α 是每次消息传输的固定延迟，包括打包、握手、链路建立等开销，与数据量无关。它对应“师傅放下工具走到交接点的准备动作”，消息再小也要花这个时间。

Q5. 当单条消息很小、通信次数很多时，通信时间主要受哪一项主导？

单选题 · mid

  • A.带宽传输项
  • B.固定延迟项← 正确答案
  • C.GPU 计算能力
  • D.显存读写速度

答案：B。消息小时，带宽项 \(\beta M\) 很小，而每次通信的固定延迟 α 不变，N 次小通信就是 N×α。这好比每次只递一块砖，走路启动的时间远大于递砖本身的时间。

Q6. 张量并行度从 P=4 提到 P=8，通信占比通常如何变化？

单选题 · mid

  • A.必然大幅下降
  • B.大概率上升← 正确答案
  • C.完全保持不变
  • D.一定降为零

答案：B。通信量 \((P-1)/P\) 从 0.75 升到 0.875，而单卡计算量被削成原来的一半，计算时间减少、通信时间增加，通信占比通常上升。并行度不是越高越好，要结合计算通信比判断。

Q7. 判断一个张量并行配置是否值得，最核心的参考指标是？

单选题 · hard

  • A.单卡显存占用是否低于 90%
  • B.通信占比是否超过计算收益← 正确答案
  • C.GPU 利用率是否每小时满负荷
  • D.网卡带宽是否达到标称值

答案：B。显存放得下只是前提，GPU 利用率是结果而非原因。真正核心的是比较通信时间和节省的计算时间：当通信占比过高，说明并行带来的收益被协作成本吞噬，配置就不值得。就像师傅过多时，开会时间超过省下的砌墙时间。

Q8. 以下哪些手段可以有效降低张量并行通信开销？

多选题 · mid

  • A.无限增大并行度 P
  • B.计算与通信重叠← 正确答案
  • C.将多次小通信合并为一次大通信← 正确答案
  • D.使用高效的 Ring All-Reduce← 正确答案

答案：BCD。B 让通信隐藏进计算里，C 减少延迟项次数，D 降低带宽项消耗，都是有效优化手段。A 是反效果——P 越大通信占比越高，可能得不偿失。

Q9. 张量并行通信时间 T = 2(P-1)α + 2(P-1)/P × βM 中，影响总时间的因素有哪些？

多选题 · hard

  • A.网络延迟 α← 正确答案
  • B.消息总大小 M← 正确答案
  • C.单卡浮点算力
  • D.网络带宽倒数 β← 正确答案

答案：ABD。模型中的变量是 α（延迟）、M（数据量）、β（带宽倒数）以及 P（并行度）。单卡浮点算力影响的是计算时间而不是通信时间，因此不能入选。

Q10. 工程实践中，哪些工具或手段可以用来定位张量并行通信瓶颈？

多选题 · easy

  • A.NVIDIA Nsight Systems← 正确答案
  • B.PyTorch Profiler← 正确答案
  • C.文本编辑器
  • D.显卡超频软件

答案：AB。Nsight 和 PyTorch Profiler 能显示每个 All-Reduce 的耗时和 GPU 空闲率，是定位通信瓶颈的标准工具。文本编辑器不能分析性能，超频软件只能改变硬件频率，无法告诉你瓶颈在哪。