4、网络压测基础：IB网络与RoCEv2对比、带宽测试（ib_write_bw）、延迟测试（ib_send_lat）

4.1 为什么网络压测这么重要？

做GPU集群的人都知道，网络是命脉。我见过太多团队，GPU卡买得挺贵，结果一跑分布式训练，通信瓶颈直接把算力打回原形。说白了，你花了几百万买的A100，最后利用率只有30%，问题八成出在网络上。

网络压测，就是提前把这条命脉摸清楚。我个人习惯，新集群上线前，第一件事不是跑AI训练，而是先跑网络压测。为什么？因为网络问题一旦埋下，后期排查成本极高。你想想看，一个千卡集群，光找一根坏线就能让你崩溃。

4.2 IB网络 vs RoCEv2：到底选哪个？

这个问题我几乎每次培训都会被问到。先给结论：没有绝对的好坏，只有适不适合你的场景。

对比维度	InfiniBand (IB)	RoCEv2
协议栈	原生IB协议，零拷贝	基于UDP封装，依赖RDMA
延迟	极低（<1μs）	较低（1-3μs）
带宽	高（HDR 200Gbps+）	高（100Gbps+）
拥塞控制	硬件级，成熟	依赖DCQCN，调参复杂
成本	高（专用交换机+线缆）	低（标准以太网）
生态兼容	需要IB网卡和交换机	主流网卡都支持

我在项目中遇到过一件事：某客户为了省钱，全上了RoCEv2。结果跑大模型训练时，每过几分钟就出现一次通信抖动，训练效率直接腰斩。后来排查发现，是交换机缓冲区太小，加上DCQCN参数没调好。折腾了两周，最后还是换了IB。

但反过来，如果你的场景是推理服务，对延迟不那么敏感，RoCEv2完全够用。说白了，IB是「省心但费钱」，RoCEv2是「省钱但费人」。

我的建议：

训练集群（尤其是大模型）：优先选IB，省下的调试时间比硬件差价值钱
推理集群或中小规模：RoCEv2性价比更高
混合部署：可以IB做训练网络，RoCEv2做存储网络

4.3 带宽测试：ib_write_bw 实战

带宽测试，说白了就是看你的网络能跑多快。我常用的工具是 ib_write_bw，它是Mellanox OFED自带的测试工具，专门测RDMA写操作的带宽。

先看基本用法。假设你有两台机器，IP分别是192.168.1.1和192.168.1.2：

# 在服务端（192.168.1.1）启动
ib_write_bw -d mlx5_0 -p 18515

# 在客户端（192.168.1.2）启动
ib_write_bw -d mlx5_0 -p 18515 192.168.1.1

这里 -d mlx5_0 指定网卡设备，-p 指定端口。跑完之后，你会看到类似这样的输出：

#bytes     #iterations    BW peak[MB/sec]    BW average[MB/sec]   MsgRate[Mpps]
65536      5000           12500.0            12480.5              0.191

嗯，这里要注意：单线程测试往往跑不满带宽。为什么？因为单线程的CPU处理能力有限。我习惯的做法是：

先用单线程测，确认基本连通性
再用多线程（-t 4 或 -t 8）测，看能不能接近理论带宽
最后用双向测试（--bidirectional），模拟真实训练场景

避坑指南：

我曾经遇到过一个问题：单线程带宽只有理论值的30%，但多线程能跑满。排查了半天，发现是NUMA绑定问题。网卡插在CPU0的PCIe槽上，但测试进程跑在CPU1上，跨NUMA访问导致性能暴跌。解决方案很简单：用 numactl --cpunodebind=0 绑定CPU。

还有一个常见坑：MTU设置。IB默认MTU是4096，但有些交换机配置了2048。如果两端MTU不一致，带宽会直接砍半。我建议测试前先确认：

# 查看当前MTU
ibv_devinfo -d mlx5_0 | grep MTU

# 设置MTU（需要root）
echo 4096 > /sys/class/infiniband/mlx5_0/ports/1/gid_attrs/ndev/0/mtu

4.4 延迟测试：ib_send_lat 实战

带宽重要，延迟同样重要。尤其是在AllReduce这类同步通信中，延迟直接决定了集群的扩展效率。

ib_send_lat 是测延迟的标准工具。用法和带宽测试类似：

# 服务端
ib_send_lat -d mlx5_0 -p 18516

# 客户端
ib_send_lat -d mlx5_0 -p 18516 192.168.1.1

输出示例：

#bytes #iterations    t_min[usec]    t_max[usec]  t_typical[usec]
2       1000          0.85           2.34         0.92

这里 t_typical 就是典型延迟。对于IB网络，2字节消息的延迟通常在1μs以内。如果超过2μs，就要警惕了。

我个人习惯，延迟测试要分三种场景：

空载延迟：只有测试流量，看硬件极限
背景流量下的延迟：同时跑带宽测试，模拟真实训练场景
长距离延迟：跨交换机、跨机柜测试，看网络拓扑设计是否合理

注意：

延迟测试的结果受很多因素影响：

CPU频率缩放（建议关闭省电模式）
中断亲和性（确保中断绑定到测试CPU）
网卡固件版本（不同版本延迟差异可达20%）

我曾经踩过一个坑：某批次网卡固件有bug，导致延迟从0.9μs飙升到3.5μs。升级固件后恢复正常。所以，测试前先确认固件版本。

4.5 本章知识体系

下面这张图，是我自己总结的网络压测知识体系，你可以把它当作一个检查清单：

这张图的核心逻辑很简单：从选型开始，到测试执行，再到问题排查，最后形成最佳实践。每一步都有坑，但只要你按这个流程走一遍，网络压测基本不会出大问题。

4.6 小结

网络压测不是跑一遍就完事的事。我个人习惯，每次集群扩容、网络拓扑变更、固件升级后，都会重新跑一遍全套测试。保留基线数据，下次出问题时才能快速定位。

记住一句话：网络压测省下的时间，会在你排查故障时加倍还给你。

实用小贴士：

测试结果建议保存到文件，方便对比：

ib_write_bw -d mlx5_0 -p 18515 192.168.1.1 | tee bw_test_$(date +%Y%m%d).log

想要更多资料，联系可可