通信基础：多卡通信的硬件拓扑与通信原语

各位同学，咱们今天聊聊多卡通信的底子。说实话，很多做分布式训练的同学，一上来就调框架、改代码，结果性能上不去，卡在通信瓶颈上。我当年也踩过这个坑——调了三天三夜，最后发现是拓扑没搞对。嗯，咱们先把地基打牢。

一、硬件拓扑：你的卡是怎么连在一起的？

多卡通信，说白了就是显卡之间怎么「说话」。不同的连接方式，决定了通信的带宽和延迟。我个人习惯把主流拓扑分成三类：

• NVLink：NVIDIA 的亲儿子，带宽极高，延迟极低。DGX 系列机器里常见。
• PCIe：通用接口，带宽相对有限，但兼容性好。家用机、服务器都有。
• InfiniBand：跨节点通信的王者，专门为高性能计算设计。集群里常见。

你想想看，如果你的 8 张卡全走 PCIe 交换机，那通信带宽就是共享的。而 NVLink 是点对点直连，每对卡之间都有独立通道。我在项目中遇到过，同样的 AllReduce 操作，NVLink 比 PCIe 快了将近 5 倍。这不是玄学，是物理决定的。

二、通信原语：卡之间到底在传什么？

多卡训练时，每张卡算完自己的梯度，需要汇总。这个「汇总」的过程，就是通信原语干的活。常用的有三个：

1. AllReduce

最常用的原语。每张卡把自己的数据发出去，最后每张卡都拿到所有卡的汇总结果。说白了就是「大家都有份」。

举个例子：4 张卡，每张卡有一个数 [1, 2, 3, 4]，AllReduce 求和后，每张卡都得到 [10]。

2. AllGather

每张卡把自己的数据广播给所有人，最后每张卡都拥有完整的数据集。注意，这里不做规约（求和/求平均），只是收集。

还是 4 张卡，每张卡有 [a, b, c, d] 中的一份，AllGather 后每张卡都有 [a, b, c, d]。

3. ReduceScatter

这个稍微复杂一点。先做规约（比如求和），再把结果分散到各张卡上。每张卡只拿到一部分结果。

4 张卡，每张卡有 4 个元素。ReduceScatter 后，卡 0 拿到所有卡的第 0 个元素之和，卡 1 拿到第 1 个元素之和，以此类推。

三、性能特征：为什么有的快有的慢？

同样是 AllReduce，不同拓扑、不同数据量下，性能差异巨大。我整理了一张表，方便你对照：

通信原语	带宽利用率	延迟敏感度	适用场景
AllReduce	高（Ring 算法可达 90%+）	中	梯度同步
AllGather	中（约 50%-70%）	高	参数收集
ReduceScatter	高（约 80%+）	低	梯度规约+分片

为什么会这样？因为 AllReduce 的 Ring 算法把通信和计算重叠了，带宽利用率自然高。而 AllGather 需要多次点对点通信，延迟累积明显。

四、知识体系总览

下面这张图，是我自己画的。它把硬件拓扑和通信原语的关系串起来了。你看一眼，心里就有谱了。

嗯，这张图你看懂了吗？硬件拓扑是「路」，通信原语是「车」。路宽车好，才能跑得快。反过来，路窄车再好也白搭。

五、实战中的选择建议

最后，我结合自己的项目经验，给你几个实用建议：

1. 单机多卡：优先用 NVLink。如果只有 PCIe，尽量用 ReduceScatter + AllGather 的组合，别直接用 AllReduce。
2. 多机多卡：跨节点必须用 InfiniBand 或 RoCE。别指望走以太网，延迟会让你崩溃。
3. 数据量小（< 1MB）：别用 Ring AllReduce，用 Tree AllReduce 或者直接 Broadcast。延迟优先。
4. 数据量大（> 100MB）：用 Ring AllReduce，带宽利用率高。我习惯把数据切成多个 chunk，流水线式传输。

好了，这一章就到这里。通信基础是后面所有融合优化的前提。你把这些搞明白了，后面讲算子融合、通信计算重叠的时候，才能跟得上。