我第一次在香港的沙田机房部署大规模 AI 推理集群时，是凌晨三点。机房里冷气呼呼直吹，40U 的机柜里密密麻麻地塞满了 8 卡 A100 的 GPU 服务器，每台服务器都用 100GbE 光口直连 Spine-Leaf 结构的交换机。那天我们刚把第三批服务器上架完毕，夜深人静时只听到服务器风扇的轰鸣。

我们遇到的核心问题是：在大规模并行推理任务下，GPU 到 GPU 的跨节点数据传输成为瓶颈，尤其是模型参数和中间张量需要频繁交换。即便在 100GbE 环境下，TCP/IP 栈的开销和内核态上下文切换带来的延迟，让 GPU 算力经常空转，吞吐率上不去。

那时我意识到：必须引入 RDMA，让数据直接在用户态和 NIC 之间搬运，绕开内核，才能真正释放硬件性能。接下来就是几周血淋淋的机房调试和优化过程。

场景与问题分析

硬件与网络环境

机房位置：香港沙田

服务器规格：

• Dell R7525 / Supermicro 4029GP-T
• AMD EPYC 7742 ×2 / Intel Xeon 8358 ×2
• GPU：NVIDIA A100 80GB ×8
• NIC：Mellanox ConnectX-6 100GbE ×2

网络拓扑：

• Spine-Leaf 架构
• Arista 7060 系列交换机
• L2+L3 混合，RoCE v2 网络平面

存储与调度：Ceph + Slurm

在没有 RDMA 的情况下，跨节点数据传输走 TCP/IP：

• 推理任务切分到多节点时，中间结果和模型参数通过 NCCL over TCP 传输。
• CPU 内核态参与数据拷贝 + 内核网络协议栈开销。
• 延迟高，GPU 经常因等待数据而空闲。

我们实际测得的带宽利用率只有 6070Gbps，延迟在 3050μs 之间，远低于预期。

技术方案：在香港服务器环境下落地 RDMA

我选择基于 RoCE v2（RDMA over Converged Ethernet） 的方案，因为我们机房的 Spine-Leaf 网络是以太网架构，且需要支持大二层与 L3 跨节点通信。

1. RDMA 环境准备

(1) 驱动与固件

更新 Mellanox OFED 驱动（尽量用 NVIDIA 官方版本）：

# 在所有服务器上
wget https://www.mellanox.com/downloads/OFED/mlnx_ofed-5.9-0.5.6.0.tgz
tar -xvf mlnx_ofed-5.9-0.5.6.0.tgz
./mlnxofedinstall --add-kernel-support

确认固件支持 RoCE v2：

ibv_devinfo | grep -i "link_layer\|active_speed\|transport"

确保 link_layer: Ethernet 且支持 RoCE v2。

(2) RoCE v2 网络配置

配置 PFC（Priority Flow Control）：

# 配置交换机（Arista 示例）
interface Ethernet1
   priority-flow-control mode on
   priority-flow-control priority 3 enable

启用 ECN（Explicit Congestion Notification）以避免拥塞丢包：

# 在交换机全局启用 ECN
qos ecn

配置服务器 NIC：

# 为 RoCE 设置优先级和 DSCP
dcbtool sc eth0 pfc e:3 a:3

2. 推理框架与 RDMA 集成

我们主要使用 TensorRT Inference Server（Triton） 和 PyTorch 分布式推理：

NCCL + RDMA 支持：

export NCCL_IB_HCA=mlx5_0
export NCCL_NET_GDR_LEVEL=2
export NCCL_SOCKET_IFNAME=eth0
export NCCL_IB_GID_INDEX=3

GDR_LEVEL=2 让 GPU 直接通过 RDMA 发送内存数据。

多机推理启动：

torchrun --nnodes=8 --nproc_per_node=8 \
    --rdzv_backend=c10d --rdzv_endpoint=node0:29500 \
    inference.py

3. 关键优化与踩坑经历

(1) 低延迟调优

默认 MTU 是 1500，我们调到 9000 Jumbo Frame：

ifconfig eth0 mtu 9000 up

延迟降低约 10%。

调整 GID Index 避免路由导致的非最优路径：

ibv_devinfo | grep gid

最终锁定 GID 3 性能最佳。

(2) 遇到的问题

GPU RDMA Timeout

原因：交换机 ECN 配置不完整导致丢包。

解决：完善 PFC + ECN 配置，并通过 perfquery 验证无丢包。

多机 NCCL 初始化卡死

原因：节点间 IP 不一致 / RDMA 设备名冲突。

解决：统一 GID index，并在 /etc/hosts 固定内网 IP 映射。

实测效果

• 带宽利用率：从 70Gbps → 95Gbps
• 端到端延迟：从 40μs → 8~12μs
• 多节点推理吞吐提升：约 35%

经过 RDMA 优化后，GPU 几乎不再因数据等待而空转，整个香港机房的推理集群算力得到了真正释放。

经验技巧

在香港机房部署大规模 AI 推理时，RDMA 是解决跨节点延迟和带宽瓶颈的核心技术。实际落地的关键是：

• 驱动/固件/网络配置到位
• PFC+ECN 保证零丢包
• NCCL + GDR 直连 GPU 内存
• 结合 Jumbo Frame 和最优 GID 调优

在实操过程中，你会发现 RDMA 并不是“一装就快”，而是需要反复在机房里对交换机、NIC 和推理框架做微调，最终才能稳定跑出理想性能。