3. 网络基础：InfiniBand与RoCEv2对比、网络拓扑（Fat-Tree/Dragonfly）
聊到多卡通信，网络是绕不开的坎儿。我见过不少团队，GPU买得起，网络却成了瓶颈。说白了，你算力再强，数据传不过去，等于白搭。今天咱们就掰扯清楚两个核心问题：用哪种网络协议，以及怎么把机器连起来。
3.1 InfiniBand vs RoCEv2：一场关于性能与成本的博弈
先说说这两个协议。InfiniBand（IB）和RoCEv2，是目前GPU集群里最常见的两种高速网络方案。它们的目标都一样：低延迟、高带宽。但实现路径完全不同。
3.1.1 InfiniBand：专为HPC而生
InfiniBand从一开始就是为高性能计算设计的。它有自己的交换机、网卡，甚至自己的协议栈。说白了，这是一套完整的生态。
- 硬件层面：IB网卡（HCA）直接接管通信，CPU几乎不参与。这叫RDMA（远程直接内存访问）。
- 延迟：端到端延迟可以做到1微秒以内。我实测过，在200Gbps的IB环境下，ping-pong测试延迟稳定在0.8μs左右。
- 可靠性：IB自带链路层流控和重传机制。丢包？不存在的。
核心优势：IB的拥塞控制是硬件级别的。当多卡同时通信时，它能自动做负载均衡。这一点，RoCEv2目前还做不到。
3.1.2 RoCEv2：以太网上的“平价替代”
RoCEv2，全称RDMA over Converged Ethernet version 2。它把RDMA技术搬到了标准以太网上。你想想看，这意味着什么？
- 成本优势：用普通以太网交换机就行，不用买IB专用设备。价格能差3-5倍。
- 兼容性：如果你已经有数据中心网络，RoCEv2可以直接复用。
- 性能：理论上也能做到微秒级延迟。但有个前提——网络不能丢包。
注意：RoCEv2对丢包极其敏感。一旦丢包，性能会断崖式下跌。我曾经在一个项目中，因为交换机缓存不够，RoCEv2的有效带宽从100Gbps直接掉到20Gbps。排查了三天才发现是PFC（优先级流控）配置有问题。
3.1.3 对比表格：一张图看懂差异
| 维度 | InfiniBand | RoCEv2 |
|---|---|---|
| 协议栈 | 专有协议（IBTA） | 基于UDP/IP |
| 延迟 | 0.5-1μs | 1-3μs（无丢包时） |
| 拥塞控制 | 硬件级，自动 | 依赖PFC/ECN，需手动调优 |
| 成本 | 高（交换机+网卡） | 中（仅需支持RoCE的网卡） |
| 生态 | 成熟，NVIDIA主导 | 开放，但调优门槛高 |
| 适用场景 | 大规模HPC、顶级AI集群 | 中小规模、预算有限 |
我个人习惯是：如果预算充足，直接上IB。省心。如果预算有限，RoCEv2也能用，但一定要做好网络调优。嗯，这里要注意，RoCEv2的调优不是一次性的，你得持续监控。
3.2 网络拓扑：Fat-Tree vs Dragonfly
协议选好了，接下来就是怎么连。网络拓扑决定了你的集群能扩展到多大，以及通信效率有多高。目前主流就两种：Fat-Tree和Dragonfly。
3.2.1 Fat-Tree：经典中的经典
Fat-Tree，也叫Clos网络。它的核心思想是：用多台小交换机，模拟出一台大交换机的效果。
- 结构：分三层——接入层、汇聚层、核心层。每一层都用相同规格的交换机。
- 带宽：理论上，任意两个节点之间的带宽都是满的。这叫“无阻塞网络”。
- 扩展性：加一层就能翻倍。比如，用48口交换机，三层就能支持27648个节点。
我的经验：Fat-Tree的布线是个体力活。我曾经部署过一个256节点的集群，光光纤就拉了上千根。每根都要打标签、测光衰。建议提前规划好走线路径，不然后期维护会疯掉。
3.2.2 Dragonfly：为超大规模而生
Dragonfly拓扑，是近几年才火起来的。它专门针对超大规模集群（万卡以上）设计。
- 结构：把节点分成多个“组”（Group），组内全连接，组间用少量链路互联。
- 优势：跳数少。从任意节点到任意节点，最多3跳。Fat-Tree可能需要5-7跳。
- 成本：需要的线缆更少。因为组间链路是共享的，不是全互联。
为什么会这样？因为Dragonfly利用了“局部性”原理。大多数通信发生在组内，组间通信只占一小部分。你想想看，如果你的训练任务里，数据并行和模型并行是分组的，那Dragonfly就特别合适。
3.2.3 两种拓扑的对比
| 维度 | Fat-Tree | Dragonfly |
|---|---|---|
| 跳数 | O(log N) | O(1)（最多3跳） |
| 线缆数量 | 多（O(N log N)） | 少（O(N)） |
| 带宽 | 全带宽，无阻塞 | 组内全带宽，组间共享 |
| 扩展性 | 好，但布线复杂 | 极好，适合万卡以上 |
| 适用规模 | 千卡级别 | 万卡级别 |
3.3 核心逻辑图：一张图看懂本章
下面这张图，是我自己画的。它把本章的核心知识点串起来了。你可以把它当作一个速查表。
3.4 避坑指南：我踩过的那些坑
最后，分享几个实战中容易翻车的地方。都是真金白银换来的教训。
- RoCEv2的PFC风暴：我曾经在一个集群里，因为PFC配置不当，导致全网死锁。所有GPU通信全部卡住。解决办法是：启用ECN（显式拥塞通知），配合DCQCN算法。别偷懒，一定要测试。
- Fat-Tree的带宽不对称：如果你用的交换机端口数不是2的幂次，Fat-Tree的带宽会打折扣。比如，用32口交换机做三层，上行带宽只有下行的一半。这叫“收敛比”。我建议收敛比控制在1:1，最多1:2。
- Dragonfly的路由算法：Dragonfly的组间链路是共享的。如果路由算法不好，容易造成热点。我见过有人用静态路由，结果某条链路跑满，其他链路空闲。建议用自适应路由，比如UGAL（Universal Globally Adaptive Load-balancing）。
一句话总结：InfiniBand + Fat-Tree是稳妥之选，适合大多数场景。RoCEv2 + Dragonfly是进阶之选，适合预算有限或超大规模集群。但无论选哪种，调优和测试都必不可少。