训练一个大模型，就像为一千位客人办一场千人盛宴。一台顶级 GPU 充其量是一位厨艺高超的厨师，但一个人绝对完成不了整场宴席。于是，我们要把几百位厨师组织起来：先设计厨房布局（架构拓扑），再规划传菜路线（通信协议），然后确定分工方式（并行策略），最后还要准备“厨师突然晕倒”的应急方案（故障恢复）。有的后厨由总厨集中指挥，每位厨师把半成品端到总厨面前，由总厨统一调配再分发——这叫参数服务器架构；有的后厨建了一条环形传菜台，每道菜沿台子依次传递、互相品尝调味——这叫全对全架构。选哪种布局、用什么速度的传菜通道、怎么分工、出了岔子怎么救场，正是本文要讲透的四件事。读完这篇文章，你就能理解为什么大模型训练需要成百上千张显卡协同，以及这些显卡之间究竟如何“对话”。

岗位关联

学完本文，你将理解 AI 大厂动辄上千张显卡是如何协作的，“多卡训练”不再是黑盒——这是进入大模型工程领域的第一块敲门砖。

目录
  1. 可视化演示
  2. 架构拓扑设计
  3. 并行策略
  4. 集合通信原语
  5. 高速互联技术
  6. 训练框架集成
  7. 故障与弹性扩展
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

多机多卡分布式训练架构是大规模AI模型训练的基础设施，需要在节点间协调数据传输、梯度同步和故障恢复等核心环节。... 切换模式查看不同维度。

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

多机多卡训练：核心原理 动态展示关键流程与数据流动 交互控件调节参数实时渲染 f(x) = transform(x) 核心概念的可视化呈现

架构拓扑设计

办宴席第一件事是画厨房布局。经典方案有两种：一种是大饭店的总厨制——所有厨师把半成品端到总厨面前，总厨调配好再分发回去，这位总厨就是“参数服务器”；另一种是环形传菜台——没有总厨，每位厨师把自己的一份菜沿台子传给下一位，传一圈后人人都尝遍所有味道，这是“全对全”的雏形。前者在图上呈星型，后者呈环形，两者构成了分布式训练最基本的两种拓扑。

在分布式训练中，参数服务器架构会安排一个专门的节点保存全局模型参数（菜谱），各计算节点每轮向它提交梯度（口味调整建议），它更新参数后再广播回去。全对全架构则取消中央节点，让所有节点直接交换数据，最终每张卡都拿到一份完全一致的全局梯度。早期的工业系统偏好前者，而如今千卡级大模型集群几乎都转向了后者。

两种架构的核心差异在于通信量。设有 N 个计算节点、模型参数大小为 P，参数服务器每轮要处理 N 份参数的上传和下载，服务器网卡成为不可避免的瓶颈；而环形拓扑下，通信量几乎与节点数无关，这正是它能支撑千卡集群的原因。参数服务器的通信时间可写为：

所以，大型后厨往往不设“总厨”，而是让环形传菜台转起来：传一圈的时间只由菜量和传菜速度决定，跟厨师人数关系不大。理解了这一点，你就明白了为什么现代千卡训练几乎都采用环形全对全架构——它把“人多添乱”变成了“人多力量大”。

TPS=N×PB\displaystyle T_{\text{PS}} = \frac{N \times P}{B}
公式解读：N 台机器要把各自那一份大小为 P 的模型全部汇总到服务器，而服务器带宽 B 是固定的，所以通信时间正比于机器数量——总厨再能干，也扛不住一千个人同时挤到窗口前交材料。
  1. N（计算节点数量）参与训练的显卡或服务器数量。每多一台机器，总厨那里就多一份要处理的参数，时间线性增长——人越多，总厨面前越拥挤。
    N×P\displaystyle N \times P
  2. P（模型参数总量）模型全部权重的大小（字节数）。参数越多，每轮要搬运的材料越沉，传得越慢——宴会菜品越精细，备料越耗时。
    P=参数量×每参数字节数\displaystyle P = \text{参数量} \times \text{每参数字节数}
  3. B（服务器带宽）参数服务器网卡每秒能传输的字节数。带宽越大，瓶颈越低，但受硬件成本限制——总厨的传菜窗口再宽也终究有限。
    N×PB\displaystyle \frac{N \times P}{B}

并行策略

厨房布局定好后，接着决定怎么分工。三种基本分工：数据并行——每个厨师拿同一本菜谱，各自做一整桌菜，最后对口味；模型并行——一道佛跳墙太大，一锅炖不下，几个人分部位同时炖，最后组装；流水线并行——切菜的只管切菜、炒菜的只管炒菜，像工厂流水线一样接力完成。

数据并行是最常见的策略：每张卡保存一份完整模型，各自处理不同的数据批次，每轮结束后同步梯度。模型并行则把模型切成多份分布到不同卡上，适合单个模型大得放不进一张卡的情形。流水线并行把神经网络按层切段，每张卡负责若干层，数据像流水一样依次流过各段。大规模训练往往把三者组合成“混合并行”，例如 GPT 系列常用的 3D 并行。

流水线并行看似高效，却有一个“气泡”问题——微批次在流水线上流动时，前段和后段会出现空窗期。设流水线有 p 个阶段、n 个微批次，气泡占比为：

就像流水线餐厅不会让整个后厨只有两三道菜在流动，实际工程中会把训练数据切成成百上千个微批次，让每一段流水都有人干活，把“气泡”压到最低。选择哪种并行策略，本质就是给不同的菜品选择最合适的分工方式。

αbubble=p−1p+nmicro−1\displaystyle \alpha_{\text{bubble}} = \frac{p - 1}{p + n_{\text{micro}} - 1}
公式解读：气泡就像流水线上“有人闲着等活”的时间比例。阶段数越多、微批次越少，空闲比例越高；把微批次切得足够细，流水线被填满，气泡占比就趋近于零。
  1. 分子 p-1第一个微批次完成全部 p 个阶段之前，流水线后端“空转”的累计时段。
    p−1\displaystyle p - 1
  2. 分母 p+n_micro-1n 个微批次全部流完整个管线总共需要的时间段数。
    p+nmicro−1\displaystyle p + n_{\text{micro}} - 1
  3. 趋于 0 的条件当微批次数量远大于阶段数时，气泡占比接近 0——流水线被填充得满满当当。
    lim⁡nmicro→∞αbubble=0\displaystyle \lim_{n_{\text{micro}} \to \infty} \alpha_{\text{bubble}} = 0

集合通信原语

无论怎么分工，每个厨师都要在开饭前“对口味”——大家交换做菜心得，统一成一套最终菜谱。这套“对口味”的动作，在分布式训练里叫集合通信。其中最核心的动作，是把所有人的梯度汇总并求平均，再发回给每个人，这就是 AllReduce（全量归约）。

集合通信原语是构建并行训练的基本积木：Broadcast 把一份数据发到所有节点（把秘方发给每个人）；AllReduce 把所有节点的数据汇总后广播回去（品尝所有人做的菜并统一评分）；Reduce-Scatter 把数据分成块，每个节点汇总其中一块（每个人负责统计一道菜的平均分）；AllGather 再把所有块聚齐（把统计结果拼成完整评分表）。环形 AllReduce 正是由后两步拼接而成的。

环形 AllReduce 的高明之处在于通信量与节点数基本无关。设模型大小 P、带宽 B、节点数 N，通信时间为：

想象一场 1000 人的宴会：如果用总厨收集菜品，总厨要尝 1000 盘菜，累到腿软；而在环形传菜台上，每个人只和邻居交换“半份菜”，绕一圈就能让所有人掌握全部味道。这正是 AllReduce 的精髓——把“全员开会”变成“局部八卦、全网同步”。

TAllReduce=2(N−1)N×PB\displaystyle T_{\text{AllReduce}} = \frac{2(N-1)}{N} \times \frac{P}{B}
公式解读：当 N 很大时，2(N-1)/N ≈ 2，通信时间约等于“两倍模型大小 ÷ 带宽”，与 N 几乎无关——这就是为什么一千张卡也能高效地同步梯度。
  1. 系数 2(N-1)/N环形结构下，每个节点需要发送和接收约两轮数据，但每轮只传输全部数据的 (N-1)/N 份额。
    2(N−1)N\displaystyle \frac{2(N-1)}{N}
  2. P/B传输一份完整模型所需的时间，P 是梯度总字节数，B 是单向链路带宽。
    PB\displaystyle \frac{P}{B}
  3. 极限行为节点数 N 越大，该系数越接近 2，说明环形拓扑扩展性极好——传菜台再长，菜绕一圈的时间也不受桌子大小影响。
    lim⁡N→∞2(N−1)N=2\displaystyle \lim_{N \to \infty} \frac{2(N-1)}{N} = 2

高速互联技术

分工和传菜方案都定了，但菜从 A 台传到 B 台走哪条路、路有多宽，直接决定宴席快慢。后厨里有三种路：普通传菜电梯（PCIe）、贵宾秘密通道（NVLink）、跨楼层超级走廊（InfiniBand），以及高性价比的共享车道（RoCE）。

在服务器内部，GPU 之间通过 PCIe 总线和 NVLink 互联：PCIe 是通用标准，速度适中，适合所有设备；NVLink 是英伟达的专用高速互联，带宽数倍于 PCIe，用于卡间高吞吐通信。跨服务器时，机房常用 InfiniBand 或 RoCE 组网，两者都支持 RDMA（远程直接内存访问），绕开 CPU 和操作系统拷贝，大幅降低延迟。此外，服务器内部的 GPU 还常按“立方体”“轨道”等拓扑排列，以最大化局部带宽。

集群整体吞吐能力很大程度上由“对分带宽”决定——把网络切成两半，跨过切面的链路带宽总和。全对全通信的耗时近似为：

请记住“热菜走电梯、贵客走秘密通道”的比方：NVLink 负责卡间“贴耳交谈”，InfiniBand 负责机房间“跨楼传菜”。通道选错了，菜凉了，宴席也就慢了。

Tall-to-all=N×Deach2×Bbisection\displaystyle T_{\text{all-to-all}} = \frac{N \times D_{\text{each}}}{2 \times B_{\text{bisection}}}
公式解读：N 个节点都要给其他节点发数据，所有跨半区流量挤在“对分带宽”这条窄路上。对分带宽越大，整体通信越快——厨房的传菜通道越宽，宴席速度越快。
  1. N×D_each（总数据量）每个节点发送的数据量为 D_each，N 个节点总共发出 N×D_each 字节。
    N×Deach\displaystyle N \times D_{\text{each}}
  2. 2×B_bisection（有效对分带宽）对分带宽是横穿切割面的链路带宽之和，数据双向流动时有效容量约为其 2 倍。
    2×Bbisection\displaystyle 2 \times B_{\text{bisection}}
  3. 工程启发提升对分带宽（部署更多 IB 链路、优化网络拓扑）是提升集群通信能力最直接的手段。
    Tall-to-all∝1Bbisection\displaystyle T_{\text{all-to-all}} \propto \frac{1}{B_{\text{bisection}}}

训练框架集成

布局、分工、传菜都设计好之后，还需要一位“总调度”把所有人指挥起来。训练框架就是这位总调度，它把通信细节封装成简单指令，让普通工程师像调用“炒菜”命令一样启动分布式训练，而不用自己手写 AllReduce、进程组管理等底层逻辑。

主流集成方案中，PyTorch DDP（Distributed DataParallel）是当前事实标准：它自动把模型包装成分布式，在反向传播完成后自动触发梯度同步；Horovod 则与框架无关，从 TensorFlow 到 PyTorch 都能接入。两者底层都依赖 NCCL（NVIDIA Collective Communications Library）这类集合通信库来执行 AllReduce。框架作为“控制面”负责初始化、同步和容错，NCCL 作为“数据面”负责实际的高效数据传输，二者各司其职。

框架集成好坏的关键指标是“扩展效率”——加了 N 张卡，实际提速与理论提速的比例：

好的总调度会让厨师们“边端菜边备菜”，把通信藏在计算背后，让传菜时间不再单独占用人手。PyTorch DDP 之所以流行，正是因为它把这种重叠机制自动化了——你只管写普通训练代码，它负责让千百张卡默契配合。

E=11+TcommTcalc\displaystyle E = \frac{1}{1 + \frac{T_{\text{comm}}}{T_{\text{calc}}}}
公式解读：E 越接近 1，说明加卡的收益越接近理想。通信时间与计算时间的比值越大——开会时间超过做菜时间——扩展效率就越低。
  1. T_calc（计算时间）每轮迭代中 GPU 做前向与反向计算的时间，也就是真正“做菜”的时间。
    Tcalc\displaystyle T_{\text{calc}}
  2. T_comm（通信时间）梯度同步、参数广播等花费的时间，也就是“对口味”的时间。
    Tcomm\displaystyle T_{\text{comm}}
  3. 比值影响若通信时间占计算时间的一半，扩展效率就只有 2/3。工程上通过梯度压缩、通信计算重叠、梯度累积等手段压低这个比值。
    TcommTcalc→0⇒E→1\displaystyle \frac{T_{\text{comm}}}{T_{\text{calc}}} \to 0 \Rightarrow E \to 1

故障与弹性扩展

千人宴席最怕什么？某个厨师突然晕倒。成熟的后厨早就备好了两手：一是随时“留备份菜谱”（检查点）；二是“弹性排班”，临时少几个人也能照样开席（弹性训练）。

千卡集群中，故障是常态而非意外。检查点（Checkpoint）定期把模型权重、优化器状态等保存到持久化存储，崩溃后从最近存档恢复；故障恢复机制负责检测宕机节点并重启训练；弹性训练则更进一步，允许节点动态加入或退出，集群规模可动态伸缩。这些机制共同保证了长时间训练的可靠性。

为什么千卡集群“天天出毛病”？因为同步训练中只要有一张卡出问题，整体就要停下来等它。设单张卡的平均无故障时间（MTTF）为 MTTF_node，N 张卡集群的整体平均无故障时间为：

真正的大规模训练不是“每次都顺顺利利”，而是“随时准备好重来”。成熟的训练平台会把检查点、容错和弹性调度做成基础设施——就像大酒店的后厨不仅厨艺高超，更有一套应对突发状况的预案。

MTTFcluster=MTTFnodeN\displaystyle MTTF_{\text{cluster}} = \frac{MTTF_{\text{node}}}{N}
公式解读：节点越多，整个系统“不挂”的时间越短。假设单卡平均 4 万小时不坏（约 4.5 年），1000 卡集群平均每 40 小时就要面对一次故障——所以检查点不是可选项，而是必需品。
  1. MTTF_node（单卡平均无故障时间）一张显卡平均能连续工作多久才出一次故障。
    MTTFnode\displaystyle MTTF_{\text{node}}
  2. 除以 N（规模效应）只要 N 张卡中任何一张故障，整轮训练就中断，故障概率随规模线性叠加。
    MTTFnodeN\displaystyle \frac{MTTF_{\text{node}}}{N}
  3. 工程意义N 越大，越要缩短检查点间隔、加上自动恢复和弹性伸缩，否则训练永远在“跑两步、停一步”。
    检查点开销≪MTTFcluster\displaystyle \text{检查点开销} \ll MTTF_{\text{cluster}}

AI 应用场景

千卡级大模型预训练平台

阶段：模型训练 / 大规模并行训练

解决的问题：单机训练一个万亿参数模型需要数百年，传统方式在算力、显存、带宽三重维度都无法支撑；AI 用“数据并行 + 模型并行 + 流水线并行”的 3D 混合并行，把训练时间压缩到几个月，并且通过 Ring-AllReduce 让通信量不再随卡数爆炸。

具体案例：某大厂训练 700 亿参数大模型，使用 1024 张 A100，通过 PyTorch DDP + NCCL + InfiniBand 组网，采用每 5 分钟一次的检查点策略，集群月度可用训练时长达到 99.2%。任何一张卡故障，系统都能在 10 分钟内自动恢复并从最近存档继续。

推荐系统大规模排序模型训练

阶段：数据准备与模型更新

解决的问题：推荐系统的 CTR 预估模型每天面对几十亿样本、TB 级特征，特征极度稀疏且模型需要高频更新；传统单机无法容纳，参数服务器架构则天然适配稀疏特征——每台 worker 只拉取自己需要的特征参数，总厨只更新热门部分，兼顾效率与带宽。

具体案例：某短视频平台的广告推荐模型采用参数服务器架构部署在数百台机器上，白天用弹性训练应对流量高峰（动态扩缩容），夜间用全量数据离线更新模型，模型每天迭代一次，线上 CTR 提升约 8%。

中小团队多机多卡微调大模型

阶段：模型微调 / 迁移学习

解决的问题：中小团队买不起千卡集群，但可以用 4-8 张消费级显卡做多机数据并行微调；AI 通过 Ring-AllReduce 让通信量只跟模型大小有关、与机器数无关，配合梯度压缩与通信计算重叠，让“小集群”也能微调百亿参数模型。

具体案例：一家 AI 创业公司用 4 台 8 卡服务器（共 32 张 RTX 4090）微调 70 亿参数开源模型，借助 PyTorch DDP 和 DeepSpeed ZeRO，训练速度比单机提升约 20 倍，成本仅为云上大集群的十分之一。

Python 演示

python45 行
import numpy as np  def parameter_server_sync(grads):    """方式一: 参数服务器汇总平均, 然后广播回各 worker"""    return np.mean(grads, axis=0)  def ring_allreduce_sync(grads):    """方式二: 环形 AllReduce(教学简化版, 单进程模拟并行传递效果)    分片轮转累加后再广播, 通信量约为 2 倍模型大小    """    world_size = len(grads)    # 每个 worker 把本地梯度切成 world_size 块    pieces = [np.array_split(g, world_size) for g in grads]    # Reduce-Scatter: 每个节点负责汇总一个分片的全局和    reduced = [        np.sum([pieces[w][i] for w in range(world_size)], axis=0)        for i in range(world_size)    ]    # AllGather: 把每个分片的平均值拼回完整梯度    reduced_avg = [r / world_size for r in reduced]    return np.concatenate(reduced_avg)  def main():    rng = np.random.default_rng(42)    world_size = 4    model_size = 8    # 模拟 4 个 worker 各自算出的本地梯度    grads = [rng.normal(size=model_size) for _ in range(world_size)]     ps_avg = parameter_server_sync(grads)    ring_avg = ring_allreduce_sync(grads)    true_avg = np.mean(grads, axis=0)     print("参数服务器结果:", np.round(ps_avg, 6))    print("Ring AllReduce :", np.round(ring_avg, 6))    print("直接全局求平均:", np.round(true_avg, 6))    print("结果一致:", np.allclose(ps_avg, ring_avg)          and np.allclose(ps_avg, true_avg))  if __name__ == "__main__":    main()
目的：用 4 个模拟 worker 的梯度数据，分别演示“参数服务器”和“环形 AllReduce”两种梯度同步方式，并验证两者结果与全局求平均完全一致。
  1. np.array_split(g, world_size)把每个 worker 的梯度切成 N 块，模拟环形算法中“分片传输”的数据分块。
  2. np.sum([pieces[w][i] for w in range(world_size)], axis=0)Reduce-Scatter 的核心：每个节点负责汇总所有人在第 i 块的全局和。
  3. reduced_avg = [r / world_size for r in reduced]求平均后得到每个分片的全局平均梯度。
  4. np.concatenate(reduced_avg)AllGather 的收尾：把各分片拼回完整梯度向量。
  5. np.allclose(ps_avg, ring_avg)校验参数服务器与环形 AllReduce 结果一致，证明两种架构在数学上等价。
  6. world_size = 4模拟 4 台机器（4 个 worker），对应正文中的节点数 N。

常见误区

误区“我买了 8 张卡，把 batch 分成 8 份丢上去，速度应该就是原来的 8 倍吧？”

正解通信开销、同步等待和负载不均会让加速比大打折扣。每轮迭代都要做梯度同步，通信时间占比越大，扩展效率越低。8 卡实际往往只有 5-6 倍加速，如果模型小、通信频繁，甚至可能更慢。这就像给一个 5 分钟就能做完菜的小厨房硬塞 8 个厨师——互相递菜的时间比做菜还长。

为何常见：直觉上认为并行就是把活平分，忽略了“对答案”（梯度同步）的时间成本，只有亲手跑过大规模实验才会体会到这条曲线的残酷。

误区“每张卡有自己的数据，各跑各的，最后把模型合并起来不就行了吗？”

正解如果各练各的，每张卡的模型早就分道扬镳了，最后根本合不到一起。数据并行要求每一步都做梯度同步（AllReduce），确保所有卡用完全一致的平均梯度更新参数。这相当于每炒一道菜都要大家尝一口、调成同一口味，而不是各做各的、最后端出八种味道。

为何常见：把“数据并行”的字面意思理解成了“独立训练”，忽略了分布式训练中“同步一致性”这个核心前提。

误区“AllReduce 不就是有一台中央服务器把梯度收上去求平均、再发回来吗？”

正解这是参数服务器（PS）架构，不是 AllReduce 的本质。AllReduce 强调去中心化，通过环形、树形或双二叉树等拓扑让数据在节点间流动，没有单点瓶颈。环形 AllReduce 通信量约 2P，与节点数几乎无关；而 PS 的通信量是 N×P，节点越多越慢。两者是不同世界的两种架构。

为何常见：初学者先接触了参数服务器，容易把“汇总再广播”的直觉套到 AllReduce 头上，忽略了环形流动的巧妙设计。

误区“反正现在 NVLink 和 InfiniBand 带宽都很大，随便插上就能跑得快。”

正解千卡集群的对分带宽决定扩展上限。如果网络拓扑设计不合理，即使单条链路带宽很高，跨区域流量也会在少数链路上拥塞，全对全通信时间急剧上升。NVLink 只是解决了服务器内部“贴耳交谈”，机房间仍然依赖胖树、Torus 等拓扑规划。小规模实验看不出问题，不代表拓扑不重要。

为何常见：小集群实验时通信量小，拓扑瓶颈不明显，容易以局部经验推断全局。

误区“检查点不就是保存模型参数吗？删掉它还能省点磁盘空间。”

正解分布式训练中，检查点要保存模型权重、优化器状态、学习率调度器状态，甚至随机数生成器状态；同时要保证多机间保存的“一致性”——所有节点必须保存同一时刻的快照。集群规模越大，检查点的设计越关键。千卡集群平均每 40 小时就会遇到一次故障，没有检查点，几天训练直接付之东流。

为何常见：单机训练时“保存模型”看起来很简单，让人低估了分布式场景中一致性与恢复的复杂性。

面试题

Q1. 数据并行训练中，每轮迭代结束后最核心的步骤是什么？

单选题 · easy

  • A.保存模型检查点
  • B.同步梯度更新参数← 正确答案
  • C.重启整个训练任务
  • D.重新划分训练数据

答案：B。数据并行要求每张卡在各自数据上算出梯度后，先做全局梯度同步（AllReduce），拿到一致的平均梯度再更新参数。保存检查点是周期性的辅助操作，重启与重划分数据更不是每轮该做的事。就像每炒一道菜都要尝一口统一口味，而不是各做各的。

Q2. 环形 AllReduce 的通信量大约是模型大小的多少倍？

单选题 · easy

  • A.约 0.5 倍
  • B.约 2 倍← 正确答案
  • C.约 N 倍
  • D.约 N 平方倍

答案：B。环形 AllReduce 通信量为 2(N-1)/N × P，当节点数 N 很大时趋近 2P，即约两倍模型大小，与节点数几乎无关。这正是它支撑千卡集群的核心原因——传菜台再长，菜绕一圈的时间并不随厨师人数增加。

Q3. 以下哪些属于集合通信原语？

多选题 · mid

  • A.AllReduce← 正确答案
  • B.Broadcast← 正确答案
  • C.Flatten
  • D.AllGather← 正确答案

答案：ABD。AllReduce（全量归约）、Broadcast（广播）、AllGather（全收集）都是集合通信原语；Flatten 只是把多维张量拉平的操作，属于张量形状变换，不属于集合通信。可以把原语理解为厨房里的标准动作：发秘方、尝口味、拼结果，每个动作都有固定套路。

Q4. 参数服务器架构的主要瓶颈在哪里？

单选题 · mid

  • A.GPU 算力不足
  • B.服务器带宽与内存← 正确答案
  • C.训练数据加载速度
  • D.磁盘存储 I/O 性能

答案：B。N 个 worker 都要向参数服务器上传梯度、下载新参数，总通信量约 N×P，服务器的网卡带宽和内存成为中心瓶颈。GPU 算力是计算侧的事，数据加载和磁盘 IO 不是这种架构的固有瓶颈。总厨再快，也架不住一千人同时递材料。

Q5. 流水线并行中的“气泡”指的是什么？

单选题 · mid

  • A.显存不足的报错
  • B.阶段间的空转等待← 正确答案
  • C.网络丢包的缺失
  • D.梯度噪声的干扰

答案：B。气泡指流水线首尾阶段没有满负荷运转的空窗期，占比为 (p-1)/(p+n_micro-1)。它是流水线并行的固有开销，对显存和网络错误不适用。这和工厂流水线上第一个工位做完之前、最后一个工位只能干等是同一个道理。

Q6. 关于 NVLink 与 PCIe，下列说法正确的是？

单选题 · mid

  • A.NVLink 带宽更高← 正确答案
  • B.PCIe 带宽更高
  • C.NVLink 仅跨机房
  • D.两者没有本质差别

答案：A。NVLink 是英伟达专用卡间高速互联，带宽数倍于 PCIe，用于服务器内部 GPU 之间高速通信；它不用于跨机房（跨机房用 InfiniBand/RoCE）。这就像贵宾秘密通道比普通传菜电梯快得多，但只覆盖小范围。

Q7. 千卡级集群训练中，降低通信开销的常用手段有哪些？

多选题 · hard

  • A.梯度压缩与量化← 正确答案
  • B.通信与计算重叠← 正确答案
  • C.增大批量减少同步← 正确答案
  • D.训练期间关闭检查点

答案：ABC。梯度压缩/量化减少传输数据量，通信计算重叠把传输藏在计算背后，增大批量则降低同步频率，三者都是成熟的降通信手段。关闭检查点虽然省了额外开销，却会让故障恢复无从谈起，属于因噎废食。

Q8. 检查点（Checkpoint）的主要作用是什么？

单选题 · easy

  • A.提升 GPU 利用率
  • B.训练中断后恢复← 正确答案
  • C.加快梯度计算
  • D.降低通信延迟

答案：B。检查点定期保存模型、优化器状态等，训练崩溃后从最近存档恢复现场。它不改变计算速度、通信速度和 GPU 利用率，而是为“重来”兜底。就像后厨留备份菜谱，厨师晕倒了还能照着备份继续做。

Q9. 单卡 MTTF 为 40000 小时，1000 卡集群的整体 MTTF 约为多少？

单选题 · hard

  • A.40000 小时
  • B.1000 小时
  • C.40 小时← 正确答案
  • D.4 小时

答案：C。MTTF_cluster = MTTF_node / N = 40000 / 1000 = 40 小时。同步训练中任何一张卡故障都会中断全局，所以节点越多，集群无故障时间越短。这也解释了为什么千卡训练必须把检查点和自动恢复做成基础设施——不是“万一出错”，而是“随时出错”。

Q10. PyTorch DDP 中的梯度同步发生在什么时候？

单选题 · mid

  • A.前向传播开始之前
  • B.反向传播完成后更新前← 正确答案
  • C.整个训练任务结束后
  • D.数据加载阶段之前

答案：B。DDP 在反向传播完成后、参数更新之前自动触发 AllReduce，确保每张卡用一致的梯度更新参数。它不是在前向之前（那时还没有梯度），也不是等整个任务结束（那模型早就分叉了）。这就是“每炒完一道菜都要先统一口味再端出去”。