4. 拓扑感知调度的动机：通信瓶颈、负载不均衡、资源利用率问题

在多卡并行训练中，我们通常默认“把任务交给调度器，它就会把 GPU 用得很好”。但实际进入大规模多卡环境后，这一假设往往不成立。无论是数据并行、模型并行还是流水线并行，通信拓扑都会深刻影响端到端性能。本章从三个核心问题出发，说明为什么“只数 GPU 数量、不看卡间连接”的调度方式会带来严重性能损失，进而引出拓扑感知调度的必要性。

4.1 通信瓶颈：拓扑决定了通信的“实际带宽”

现代 GPU 服务器内部通常采用 NVLink + NVSwitch 的全互联结构，而跨节点通信则依赖 InfiniBand 或 RoCE 网络。两种链路的带宽差异巨大：以 NVIDIA A100 为例，单卡 NVLink 带宽约为 600 GB/s，而单条 InfiniBand HDR 仅为 12.5 GB/s（单向），差距接近 50 倍。即便使用多网卡绑定，跨节点带宽也远低于节点内带宽。

更关键的是，通信拓扑并非均匀的“全等图”。在一个 8 卡节点内，任意两卡之间通过 NVSwitch 可达，带宽一致；但在多节点集群中，不同节点对之间的物理距离、交换机层级、共享链路的拥塞程度各不相同。如果调度器不考虑这些差异，就可能出现以下情况：

• 将两个通信量极大的 rank 分配到不同节点，导致它们之间的梯度同步必须走跨节点网络，带宽骤降；
• 将多个高通信任务分配到同一台交换机的同一端口下，造成端口拥塞；
• 将需要频繁 AllReduce 的 8 卡训练任务拆到 2 个节点上，每个节点 4 卡，使得本来可以在节点内完成的通信被迫跨节点执行。

下面这张图展示了同一训练任务在两种调度策略下的通信路径差异：

上图中，左侧将 8 卡训练任务完整放置在一个节点内，AllReduce 通信全部经由 NVSwitch，延迟低、带宽高；右侧将任务拆到两个节点，每节点 4 卡，梯度同步必须反复穿越节点边界。实测中，对于 ResNet-50 这类通信占比约 15% 的模型，这种拆分可能导致训练吞吐下降 30% 以上；对于 GPT-3 这类通信占比超过 50% 的大模型，性能损失可达 2～3 倍。

4.2 负载不均衡：拓扑异构导致的“木桶效应”

集群中的 GPU 并非同质资源。即使型号相同，它们所处的拓扑位置也决定了其通信能力。例如，在一个 2 机 16 卡的环境中，GPU0～GPU7 位于节点 A，GPU8～GPU15 位于节点 B。如果调度器将某个并行组（如数据并行组）的 8 个 rank 分配为 GPU0～GPU3 + GPU8～GPU11，那么该组的 AllReduce 通信中，节点内部分（GPU0～GPU3）很快完成，但跨节点部分（GPU0 与 GPU8 之间）需要等待慢速链路，最终整体通信时间被最慢的跨节点链路拉长。

这种拓扑异构带来的负载不均衡，在流水线并行中更为明显。流水线各 stage 之间需要持续传递 activation 和 gradient，如果 stage 间的通信链路带宽不一致，那么高速链路上的 stage 会频繁等待低速链路上的数据到达，造成 GPU 空闲。下图展示了这种“木桶效应”：

负载不均衡的另一个来源是拓扑感知的缺失导致任务堆积。例如，某个节点内部 NVLink 全互联，可以高效支持 8 卡并行；但调度器可能因为“只看空闲 GPU 数量”而将多个小任务塞进同一节点，导致该节点的 NVSwitch 端口争用，而其他节点的 NVSwitch 完全空闲。这种资源碎片化使得集群整体利用率下降，但每个任务单独看又“似乎没有更好的选择”。

4.3 资源利用率问题：从 GPU 利用率到“有效算力”

传统调度器通常以 GPU 利用率（GPU Utilization） 作为核心指标。但 GPU 利用率高并不代表训练效率高——如果 GPU 在 90% 的时间里都在等待通信数据，它的“计算利用率”虽然高，但“有效算力输出”极低。更合理的指标是 MFU（Model FLOPs Utilization，模型浮点运算利用率），它衡量的是 GPU 实际完成的浮点运算占理论峰值的比例。

以下表格对比了不同调度策略下的资源利用效果：

调度策略	GPU 利用率	MFU	通信时间占比	有效训练吞吐
非拓扑感知（跨节点拆分）	92%	28%	~55%	低
拓扑感知（节点内聚合）	95%	52%	~18%	高（约 1.8×）
拓扑感知 + 通信计算重叠	97%	61%	~8%	最高（约 2.2×）

从表中可以看到，GPU 利用率差异不大（92% vs 95%），但 MFU 差异接近一倍。原因在于非拓扑感知调度下，GPU 虽然“忙”，但大量时间花在等待跨节点数据上，真正执行矩阵乘法的周期很少。因此，调度目标应从“让 GPU 忙起来”升级为“让 GPU 做有效计算”。

4.4 案例复盘：一个 16 卡 BERT 训练的调度失误

某团队在 2 节点（每节点 8×A100，NVLink 全互联）上训练 BERT-Large，使用数据并行 + 梯度累积。调度器按“空闲 GPU 优先”策略分配，结果如下：

初始分配：
  rank 0-3  → 节点 A（GPU0-3）
  rank 4-7  → 节点 B（GPU0-3）
  rank 8-11 → 节点 A（GPU4-7）
  rank 12-15→ 节点 B（GPU4-7）

实际通信模式：
  每个 rank 的梯度 AllReduce 需要跨节点交换
  通信量：每步约 1.2 GB（BERT-Large 参数 340M × 4 bytes × 2（梯度+优化器状态））
  跨节点带宽：实际测得 11 GB/s（受限于单网卡）
  节点内带宽：实测 450 GB/s（NVLink）

每步通信耗时：
  跨节点：1.2 GB / 11 GB/s ≈ 109 ms
  节点内：1.2 GB / 450 GB/s ≈ 2.7 ms
  差距：约 40 倍

训练开始后，团队发现 GPU 利用率显示 93%，但实际每秒处理样本数仅为预期的 60%。通过 nsys 性能分析发现，通信等待占据了每步耗时的 52%。后来将分配策略改为“按节点连续分配”：

优化后分配：
  rank 0-7  → 节点 A（全部 8 卡）
  rank 8-15 → 节点 B（全部 8 卡）

通信模式：
  每个数据并行组（8 rank）完全在节点内通信
  每步通信耗时：约 2.7 ms
  训练吞吐提升：1.7 倍

这个案例清楚地说明：GPU 数量相同、模型相同、超参相同，仅改变 rank 到物理 GPU 的映射关系，就能带来近 2 倍的性能差异。这种差异完全由通信拓扑决定，而传统调度器对此一无所知。

4.5 误区与复盘：为什么“看起来没问题”却性能差？

另一个误区是只关注通信量，不关注通信模式。例如，AllReduce 和 All-to-All 对拓扑的敏感度不同：AllReduce 可以通过 Ring 算法部分隐藏跨节点通信，但 All-to-All（如 MoE 模型中的 Token 分发）对拓扑极其敏感，因为每个 token 都可能需要跨节点传输。调度器必须了解模型使用的通信原语类型，才能做出正确的拓扑决策。

还有一个常见问题是静态调度 vs 动态迁移。有些团队认为“任务一旦启动就不能动”，因此放弃了拓扑优化的机会。实际上，现代调度器支持弹性训练，可以在检测到通信瓶颈时动态调整 rank 到 GPU 的映射，甚至迁移部分 worker。这需要调度器实时感知通信热点，而不仅仅是启动时做一次静态分配。

最后，不要忽视网络拓扑的层级性。集群通常采用 Leaf-Spine 架构，不同 Leaf 交换机下的节点之间的通信需要经过 Spine 交换机，带宽更低、延迟更高。拓扑感知调度不仅要考虑“节点内 vs 跨节点”，还要考虑“跨 Leaf vs 跨 Spine”。一个完整的拓扑描述应包含：

• GPU 到 NVLink/NVSwitch 的连接关系
• GPU 到网卡（HCA/NIC）的对应关系
• 节点到 Leaf 交换机的连接
• Leaf 到 Spine 的上行链路
• 不同路径的带宽和延迟矩阵