第四章：集群网络配置——InfiniBand vs RoCE、网络拓扑设计、IPoIB配置、RDMA验证、多机通信测试
说到GPU集群，很多人第一反应是显卡型号、显存大小。但我得说一句大实话：网络才是集群的命脉。你想想看，几百张卡一起干活，数据传不过去，再强的算力也是白搭。今天咱们就聊聊集群网络配置，这活儿我干了好几年，踩过的坑能写本书。
4.1 InfiniBand vs RoCE：选型背后的门道
先说说两个主流方案。InfiniBand（IB）和RoCE（RDMA over Converged Ethernet），说白了都是做RDMA（远程直接内存访问）的。但它们的脾气秉性完全不同。
核心区别一句话总结：IB是专车，RoCE是拼车。专车贵但稳，拼车便宜但得看路况。
我在项目中遇到过这样的场景：某客户预算有限，硬要用RoCE跑大模型训练。结果呢？网络抖动导致训练频繁中断，最后算下来总成本反而更高。所以我的建议是——训练场景无脑选IB，推理场景可以妥协RoCE。
| 特性 | InfiniBand | RoCE |
|---|---|---|
| 延迟 | 亚微秒级（0.5-1μs） | 微秒级（1-3μs） |
| 带宽 | 单端口200/400Gbps | 取决于以太网（100/200/400G） |
| 拥塞控制 | 硬件级，天生自带 | 依赖DCQCN等软件方案 |
| 成本 | 高（交换机+线缆贵） | 相对低（复用以太网生态） |
| 生态兼容 | 需要专用驱动（MLNX_OFED） | 标准以太网驱动即可 |
我的经验：如果你做的是8卡以内的单机训练，RoCE完全够用。但一旦超过16卡，尤其是跨机AllReduce通信，IB的优势就体现出来了。我曾经帮一个客户从RoCEv2迁移到IB，训练吞吐直接提升了30%。
4.2 网络拓扑设计：胖树还是Dragonfly？
拓扑设计这事儿，说白了就是决定卡和卡之间怎么连。最常见的两种：Fat-Tree（胖树）和Dragonfly+（蜻蜓）。
胖树结构，我习惯叫它「分层堆叠」。每一层带宽逐级收敛，但保证任何两点之间都有多条路径。适合中小规模集群（256卡以内）。
Dragonfly+呢？它是把交换机分成多个组，组内全互联，组间少量连接。这种设计在大规模集群（上千卡）时优势明显，跳数少、延迟低。
我的建议：128卡以内用胖树，简单好维护。超过128卡，尤其是做GPT级别的大模型训练，Dragonfly+是更优解。我曾经在512卡集群上对比过，Dragonfly+的AllReduce耗时比胖树少了40%。
4.3 IPoIB配置：让IB网卡像以太网一样用
IPoIB（IP over InfiniBand），说白了就是在IB网络上跑IP协议。为什么要这么做？因为很多应用层工具（比如SSH、NFS）只认IP地址，不认IB的LID地址。
配置步骤其实不复杂，但有几个坑我得提醒你：
# 1. 加载IB驱动（以Mellanox ConnectX-6为例）
modprobe ib_ipoib
modprobe mlx5_ib
# 2. 查看IB设备
ibstat
# 输出示例：
# CA 'mlx5_0'
# Port 1: 状态: Active
# 物理状态: LinkUp
# LID: 0x2
# 速率: 200 Gbps (HDR)
# 3. 配置IPoIB接口（持久化配置）
cat /etc/sysconfig/network-scripts/ifcfg-ib0
# 内容：
# DEVICE=ib0
# TYPE=InfiniBand
# ONBOOT=yes
# BOOTPROTO=static
# IPADDR=10.0.0.1
# NETMASK=255.255.0.0
# CONNECTED_MODE=yes # 重要！使用连接模式性能更好
# 4. 重启网络服务
systemctl restart network
我曾经踩过的坑：CONNECTED_MODE这个参数，默认是no（数据报模式）。如果你不做修改，IPoIB的吞吐会惨不忍睹。我记得有一次部署，忘了改这个参数，结果带宽只有标称值的1/10。排查了整整一天才发现是这个问题。
4.4 RDMA验证：确认你的网络真的在跑RDMA
配置完了，怎么确认RDMA真的在工作？我一般用三板斧：
- ib_write_bw：测带宽
- ib_read_lat：测延迟
- ibv_devinfo：看设备状态
# 在服务端启动
ib_write_bw -d mlx5_0 -p 18515
# 在客户端连接（假设服务端IP是10.0.0.1）
ib_write_bw -d mlx5_0 -p 18515 10.0.0.1
# 输出示例（正常情况）：
# #bytes #iterations BW peak[MB/sec] BW average[MB/sec] MsgRate[Mpps]
# 65536 5000 24576.34 24512.87 0.374
# 检查是否真的走了RDMA（而不是TCP回退）
ibv_devinfo -d mlx5_0 | grep -i "link_layer"
# 输出应为：link_layer: InfiniBand
关键指标：对于HDR（200Gbps）IB网卡，单流带宽应该在23-24 GB/s左右（扣除协议开销）。如果低于20 GB/s，说明配置有问题，或者链路质量不佳。
4.5 多机通信测试：从单机到集群的最后一公里
单机测完了，接下来就是多机。这一步最容易出幺蛾子。我习惯用NCCL（NVIDIA Collective Communications Library）的测试工具来验证。
# 安装NCCL测试工具
git clone https://github.com/NVIDIA/nccl-tests.git
cd nccl-tests
make
# 双机AllReduce测试（节点1）
./build/all_reduce_perf -b 8 -e 128M -f 2 -g 8 -t 1 -n 100 \
-c 0 -w 10 --iters 100
# 节点2（需要同时启动，通过SSH同步）
# 注意：需要确保两台机器的IB网络互通
# 可以用ping测试IPoIB地址
ping -c 3 10.0.0.2
# 如果ping不通，检查：
# 1. IPoIB接口是否up
# 2. 子网管理器（opensm）是否运行
# 3. 防火墙是否放行IB端口
测试结果怎么看？我一般关注两个指标：
- Algo带宽：算法层面的带宽，通常比总线带宽低一些
- Bus带宽：实际总线带宽，这个应该接近理论值
我的经验：如果多机测试发现带宽上不去，90%的原因是子网管理器（Subnet Manager）没配好。IB网络不像以太网那样自协商，必须有一个节点运行opensm。我习惯在管理节点上跑opensm，并配置成主备模式。
# 启动子网管理器（主节点）
opensm -g 0x2 -p 0 -B
# 检查子网管理器状态
ibstat | grep -i "sm"
# 输出：SM: 是 (LID 0x1)
# 备节点配置（故障切换）
opensm -g 0x3 -p 0 -B -R
注意：子网管理器挂了，整个IB网络就会瘫痪。我曾经在凌晨3点被电话叫醒，就是因为生产环境的opensm进程挂了，所有训练任务全部卡死。从那以后，我强制要求所有集群必须配置主备SM。
好了，网络配置这块就聊到这儿。记住一句话：网络是集群的血管，血管堵了，心脏再强也没用。下一节咱们聊聊存储配置，那个坑更多...