03 AI 网络运维

学习目标：能解释 AI 集群为什么依赖高速网络；能从运维视角说清 RDMA / InfiniBand / RoCEv2 的区别与选型；能做 RoCE 无损网络的 PFC/ECN 配置检查与丢包定位；能用 nccl-tests 打带宽基线、用 NCCL 环境变量把通信走对网卡；能区分一个"训练变慢"是网络问题还是计算问题。 重点度：需要会（运维核心技能，AI Infra SRE 高频排障场景）

概述#

AI 集群和普通 Web 集群最大的运维差异，就在网络。普通业务集群里网络是"够用就行"，AI 训练/推理集群里网络是第一性能瓶颈之一——一次配错 PFC、走错网卡，整个训练的吞吐能直接砍半甚至挂死。

text
运维要理解的核心事实：
  AI 集群的网络不是"传数据"，是"参与计算"。
  GPU 算得再快，只要跨卡/跨机通信慢，整个作业就被拖到通信的速度。

作为运维/SRE，你不需要会写 NCCL、不需要会实现集合通信算法。你需要会的是：

看懂网络架构（IB 还是 RoCE、SM 在哪、GID 怎么配）
把无损网络配对、监控住（PFC/ECN 一旦漂移就丢包）
用标准工具打基线、定位"是网络慢还是算得慢"
训练卡住/变慢时，能快速判断问题在网络侧还是计算侧

本章全部是运维视角。

一、AI 集群为什么离不开高速网络#

训练：all-reduce 每步搬 TB 级数据#

数据并行（DP）训练里，每个 step 结束后所有 GPU 要把梯度做一次 all-reduce 求和。梯度的大小约等于模型参数量：

text
一个 70B 模型，梯度 ≈ 140GB（fp16）
1024 卡训练，每个 step 都要 all-reduce 这个量级的数据
→ 每步跨网络搬运的总流量是 TB 级
→ 一天几十万个 step，网络一刻不停

如果网络带宽不够或有丢包，GPU 就会空等通信——算力再强也发挥不出来。这就是为什么万卡集群标配 400Gbps/800Gbps 的 IB 或 RoCE。

推理：TP 跨卡 + PD 分离传 KV#

大模型推理同样吃网络：

张量并行（TP）：一个大模型切到多张卡上，每次前向都要跨卡通信（all-reduce / all-gather）。TP 通常走机内 NVLink，但 TP 域跨机时就吃网络。
PD 分离（Prefill/Decode Disaggregation）：把 Prefill 阶段和 Decode 阶段拆到不同 GPU 组，Prefill 算完的 KV Cache 要通过网络传给 Decode 节点。KV 动辄几 GB，传输慢就直接拉高首 token 延迟（TTFT）。vLLM/Dynamo 这类框架用 NIXL 等做 KV 传输，底层依赖 RDMA。

运维结论：训练看总带宽和无损，推理 PD 分离看点对点低延迟传输。两者都对网络零容忍。

二、RDMA / InfiniBand / RoCEv2（运维视角）#

为什么要 RDMA#

传统 TCP/IP 走内核协议栈，每个包都要 CPU 拷贝、上下文切换，延迟高、CPU 占用高。RDMA（Remote Direct Memory Access） 让网卡直接读写远端内存，绕过内核和 CPU（kernel bypass + zero copy），这才撑得起 GPU 之间的高频大流量通信。

RDMA 有两条主流落地路线：

维度	InfiniBand（IB）	RoCEv2
本质	专用网络（自有物理层+协议栈）	在以太网上跑 RDMA（UDP 封装，端口 4791）
无损保障	协议内建 credit-based 流控，天生无损	需要手工配 PFC + ECN 才无损
可路由	需要 SM 管理	走标准 L3，可跨子网路由
交换机	专用 IB 交换机（Mellanox/NVIDIA）	标准以太网交换机（支持无损特性即可）
运维复杂度	SM 一配好基本省心，但生态封闭	配置项多、易漂移，但用标准以太网设备、成本低
典型选型	大规模训练专网、追求确定性	已有以太网基础设施、成本敏感、复用运维栈

运维选型一句话：追求"开箱无损、稳定"选 IB；追求"复用以太网、成本低、生态开放"选 RoCE，但要接受 PFC/ECN 的调优和踩坑成本。

InfiniBand 运维：子网管理器（SM）是核心#

IB 网络必须有一个 Subnet Manager（SM） 在跑，它负责给每个端口分配 LID、计算路由表、管理整个子网拓扑。SM 挂了，网络虽然已建立的连接还在，但拓扑变更（加节点、链路抖动）就无法处理。

SM 可以跑在交换机上（硬件 SM）或主机上（opensm）。生产建议开主备 SM。
常用排查命令（运维必备）：

bash
ibstat            # 查看本机 HCA 端口状态、速率、LinkUp/Down
ibstatus          # 端口物理/逻辑状态、速率（如 400Gb/s）
iblinkinfo        # 全网链路拓扑与速率，找降速链路（本该 400G 却跑在 100G）
ibdiagnet         # 全网健康诊断，报告坏链路、误码、SM 状态
perfquery         # 查端口错误计数器（symbol error、link recovery）
sminfo            # 确认 SM 是否在跑、主 SM 是谁

IB 高频故障：链路"协商降速"（400G 掉到 200G/100G，多半是光模块/线缆问题）、误码率高（ibdiagnet 报 symbol errors）、SM 主备切换异常。

RoCEv2 运维：无损是"配"出来的#

RoCE 把 RDMA 跑在以太网上，而 RDMA 对丢包极其敏感（丢一个包可能触发 go-back-N 重传，性能雪崩）。以太网默认是"尽力而为、允许丢包"的，所以 RoCE 必须把网络配成无损——这是 RoCE 运维的头等大事，下一节详述。

三、RoCE 无损网络运维（重点踩坑区）#

无损靠三件套：PFC（流控）+ ECN（拥塞标记）+ DCQCN（拥塞控制算法）。

PFC（Priority Flow Control，802.1Qbb）#

PFC 的作用是"缓冲区快满时，给上游发 PAUSE 帧，让它先别发"，从而不丢包。它是按优先级暂停的（8 个优先级队列），只暂停 RoCE 流量，不影响其他业务。

配置要点（主机侧 + 交换机侧必须一致）：

text
给 RoCE 流量打上 DSCP（常用 DSCP 26），映射到某个优先级队列（常用 priority 3）
主机 NIC 侧：把该优先级开启 PFC（mlnx_qos / lldptool）
交换机侧：同一个优先级开 PFC，配好 buffer/headroom
端到端每一跳（网卡→ToR→Spine→ToR→网卡）优先级和 PFC 配置必须完全一致

PFC 经典踩坑：

配置不一致 → 丢包：只要有一跳没开 PFC 或优先级映射错了，拥塞时那一跳就丢包，RDMA 性能瞬间崩。这是 RoCE 最常见的"配不好就丢包→性能崩"事故。
PFC 死锁 / PFC 风暴：PAUSE 帧循环传播，导致大片网络停摆。大规模 RoCE 要评估无死锁路由。
headroom 不足：链路长、速率高时 buffer 预留不够，PAUSE 还没生效就已经丢了。

ECN + DCQCN（拥塞控制）#

光靠 PFC 不够——PFC 是"急刹车"，频繁 PAUSE 会引发拥塞扩散。ECN 让交换机在队列开始堆积（还没满）时给数据包打标记，接收端回一个 CNP（Congestion Notification Packet），发送端据此主动降速（这套算法就是 DCQCN）。

text

理想状态：ECN 先温和降速（主力），PFC 只作为最后的防丢包兜底（很少触发）
配坏的状态：ECN 不生效 → 全靠 PFC 疯狂 PAUSE → 吞吐抖动、延迟飙高

ECN 配置的是交换机队列的 WRED/ECN 门限（Kmin/Kmax）：队列长度到 Kmin 开始按概率打标，到 Kmax 全部打标。门限设太高 ECN 来不及、设太低误伤正常流量。

监控丢包与拥塞（运维日常）#

RoCE 无损"配好"不等于"永远好"，固件升级、加节点、线缆老化都可能让它漂移，必须持续监控：

网卡侧（ethtool -S <iface> 关键计数器）：

text
rx_prio3_pause / tx_prio3_pause     # PFC PAUSE 帧收发数（priority 3）
                                    # 持续增长 = 网络在频繁流控，有拥塞
np_ecn_marked_roce_packets          # 被 ECN 标记的包数（拥塞信号）
rx_pause_ctrl_phy                   # 物理层 PAUSE
out_of_buffer / rx_discards         # buffer 不足丢包 → 无损没配好的直接证据！
roce_slow_restart / packet_seq_err  # RDMA 重传相关，暴涨=有丢包

交换机侧：每端口的 PFC PAUSE 计数、ECN 标记计数、队列深度、discard/drop 计数（无损网络里 RoCE 队列的 drop 应该恒为 0，一旦非 0 就是事故）。

告警规则建议：out_of_buffer 或 RoCE 队列 discard 非零 → 立即告警；PAUSE 帧速率突增 → 拥塞告警；packet_seq_err 增长 → 有丢包重传。

四、NCCL 通信排障（运维高频）#

NCCL 是 NVIDIA 的集合通信库，几乎所有 PyTorch 多卡/多机训练底层都走它。运维不需要改 NCCL 代码，但必须会用它自带的工具和环境变量排障。

nccl-tests：打带宽基线#

排障第一步永远是"先量一个基线"。nccl-tests 是官方压测工具：

bash
# 单机 8 卡 all-reduce 带宽测试
./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8

# 多机（配合 mpirun / torchrun 起多进程）
mpirun -np 16 -H node1:8,node2:8 ./build/all_reduce_perf -b 8 -e 8G -f 2

看输出的两个带宽：

algbw（算法带宽）：应用视角的吞吐
busbw（总线带宽）：这个才是判断网络健康的关键，反映实际链路利用

参考基线（记住数量级即可）：机内 NVLink（H100）busbw 可达数百 GB/s；跨机 400Gbps IB/RoCE 单口理想约 45–50 GB/s。实测远低于基线，就说明网络或配置有问题（走错网卡、没启 GPUDirect、无损没配好）。

NCCL_DEBUG：看它到底走了哪条路#

bash
export NCCL_DEBUG=INFO          # 打印初始化时选的网卡、通道、拓扑（最常用）
export NCCL_DEBUG=WARN          # 只看警告和错误
export NCCL_DEBUG_SUBSYS=INIT,NET,GRAPH   # 细分子系统日志

NCCL_DEBUG=INFO 的日志会告诉你：选中了哪块 HCA、用没用 GPUDirect RDMA、构建了什么通信拓扑（Ring/Tree）。排障基本从读这段日志开始。

把通信"走对网卡"（最常见的配置类故障）#

多网卡机器上，NCCL 可能默认选了管理网口（1G/10G 的 eth0）而不是 400G 的 RDMA 网卡，结果通信慢几十倍。关键环境变量：

bash
# 选对 RDMA/IB 网卡（用 ibstat 看到的设备名）
export NCCL_IB_HCA=mlx5_0,mlx5_1,...      # 指定用哪些 HCA，别让它乱选
export NCCL_SOCKET_IFNAME=eth0            # 控制/bootstrap 通道走哪个网口
                                          # （注意：这是控制面，不是数据面）
# RoCE 场景必配：GID index 要选对（RoCEv2 通常是某个特定 GID）
export NCCL_IB_GID_INDEX=3                # 选错 GID → 连不上或走了 RoCEv1
# GPUDirect RDMA 相关
export NCCL_NET_GDR_LEVEL=PIX             # 控制何时启用 GDR

GPUDirect RDMA（GDR）：让网卡直接读写 GPU 显存，不经过 CPU 内存中转，是跨机训练的关键加速。运维要确认：内核加载了 nvidia-peermem（或旧的 nv_peer_mem）模块；NCCL_DEBUG=INFO 日志里能看到 [GPU Direct RDMA] Enabled。没启用时通信会绕道 CPU，带宽大打折扣。

五、网络导致的性能问题定位：是网络还是计算？#

训练变慢/推理跨节点慢，第一件事是分清瓶颈在网络还是在计算，否则方向全错。

判断方法#

text
1. 看 GPU 利用率曲线（DCGM: SM active / GPU util）
   - GPU 长时间跑满 → 大概率是计算瓶颈，不是网络
   - GPU 周期性掉到 0 或很低（等通信）→ 通信瓶颈嫌疑大

2. 看 nccl-tests 基线
   - 单机 NVLink 带宽正常、跨机带宽远低于基线 → 网络问题
   - 单机就慢 → 不是网络，是计算/NVLink/显存

3. 看 profiler（PyTorch Profiler / Nsight Systems）
   - 时间线里通信算子（ncclAllReduce）占比高、GPU 在等 → 通信 bound
   - 计算 kernel 占满、通信能重叠掉 → 计算 bound

4. 看是否"木桶效应"——某个 rank 慢拖垮全体（straggler）
   - all-reduce 是同步的，一个慢节点让所有卡陪等

straggler（慢节点）定位#

万卡训练里，单个慢 GPU/慢链路会拖垮整个作业。定位思路：

逐节点跑 nccl-tests / DCGM diag，找出带宽或算力异常的节点
看单卡指标：某卡 SM 频率被降（掉频/过热）、ECC 错误、NVLink 掉链路、HCA 降速
网络侧：某条链路协商降速（iblinkinfo）、某端口 PAUSE/discard 异常

实战#

实战一：多机训练"通信慢/卡住"的网络侧排查#

现象：单机训练正常，一上多机就慢得离谱，或直接卡死（NCCL timeout / watchdog）。

排查顺序：

text
1. 先看走没走对网卡
   NCCL_DEBUG=INFO 起训 → 日志确认选中的是 mlx5 RDMA 网卡还是 eth0 管理口
   → 走错了就用 NCCL_IB_HCA / NCCL_SOCKET_IFNAME 显式指定

2. 打基线
   跨机 all_reduce_perf → busbw 是不是接近理论值
   → 远低于基线 → 网络/GDR/无损问题；接近基线 → 不是网络

3. 确认 GPUDirect RDMA
   日志找 [GPU Direct RDMA] Enabled；没有 → 查 nvidia-peermem 模块

4. RoCE 场景查无损
   两侧 ethtool -S 看 out_of_buffer / discard / seq_err → 非零说明丢包
   查 GID index（NCCL_IB_GID_INDEX）选错会连不上或走错版本

5. "卡住"（hang）专项
   - NCCL timeout 报错里看是哪个 rank 卡住
   - 该 rank 是不是 crash 了 / OOM 了（一个 rank 挂，其他 rank 集合通信永远等）
   - 网络分区？PFC 死锁？用 py-spy dump / gdb 看进程栈
   - 集合通信参数不一致（不同 rank 传的 shape/dtype 不一致也会 hang）

实战二：RoCE 丢包定位#

现象：训练能跑但吞吐抖动大、周期性变慢，nccl busbw 忽高忽低。

text
1. 网卡计数器扫一遍（每个训练节点）
   ethtool -S <iface> | grep -E "pause|ecn|discard|out_of_buffer|seq_err"
   → out_of_buffer / rx_discards 非零 = 无损没配好，正在丢包（实锤）
   → seq_err 增长 = 有丢包触发 RDMA 重传

2. 判断是 PFC 没配对还是 ECN 没配对
   → PAUSE 帧疯狂增长但仍丢包 → PFC 门限/headroom 不足或某跳没配
   → 完全没有 PAUSE、直接 discard → 某跳压根没开 PFC / 优先级映射错

3. 端到端逐跳查一致性
   网卡 DSCP→优先级映射、每台交换机对应优先级的 PFC 开关和 buffer
   → 找出"链路上没对齐的那一跳"

4. 交换机侧确认
   RoCE 队列 discard 计数（无损网络这里必须恒为 0）
   ECN 标记计数、队列深度是否长期高位

5. 兜底手段
   临时把该链路/该作业隔离，替换可疑光模块/线缆，复测 nccl busbw 恢复

小结#

AI 网络运维的核心，是理解"网络参与计算"这个前提，然后把三件事做扎实：

text
懂架构   → RDMA 为什么必须；IB（SM 管理，开箱无损）vs RoCE（以太网跑 RDMA，需手工无损）
配无损   → RoCE 的 PFC + ECN + DCQCN，端到端每一跳配一致，否则丢包性能崩
会排障   → nccl-tests 打基线 + NCCL_DEBUG 看路径 + 环境变量走对网卡 + GDR

运维四条铁律：

先打基线再谈快慢：nccl-tests 的 busbw 是网络健康的标尺，脱离基线的"感觉慢"没意义。
走对网卡是第一位：多网卡机器上 NCCL 选错网口是最高频的低级故障，NCCL_DEBUG=INFO + NCCL_IB_HCA 解决大半。
RoCE 无损要持续监控：out_of_buffer / discard / PAUSE 帧计数进 Prometheus，非零即告警——配好不等于永远好。
分清网络 vs 计算再动手：看 GPU 利用率曲线和 profiler，别把计算瓶颈当网络问题瞎调。

下一章进入 智算平台运维与资源治理——K8s GPU 调度运维、配额与碎片治理、万卡可见性与变更管理、GPU 利用率与成本治理、训练/推理混部潮汐调度。