4. 关键性能指标定义与解读
在 AI 集群中，网络性能诊断的难点不在于“有没有指标”，而在于“指标之间如何互相解释”。单看带宽利用率 80% 可能很正常，但如果同时出现 PFC 暂停帧激增、ECN 标记比例上升、GPU 利用率周期性掉坑，那这条链路很可能已经进入拥塞—反压—降速的恶性循环。本节把 AI 集群最常用的九类指标放在同一条因果链上，说明每个指标“量的是什么、正常范围怎么判断、异常时指向哪里”。
一、基础三件套：带宽、时延、抖动
带宽分三个层次：链路物理带宽（如 400Gb/s）、有效吞吐（实际传输的 bit/s）、以及应用层有效载荷带宽。AI 训练中真正关心的是有效吞吐，因为 NCCL 的 AllReduce 会叠加协议头、重传和同步开销。判断依据：若链路利用率长期低于 60% 而 GPU 利用率也不高，瓶颈可能在计算或存储；若链路接近 100% 且 PFC/ECN 同时上升，瓶颈在网络。
时延在 AI 集群中通常拆成三段：端点处理时延（网卡、协议栈）、链路传播时延（约 5ns/m 光纤）、排队时延。排队时延是拥塞的直接产物，也是抖动的主要来源。诊断时优先看 P99 而非平均值，因为 AllReduce 的完成时间由最慢的那条流决定。
抖动是时延的方差。在 RoCEv2 无损网络中，抖动放大往往先于丢包出现：当交换机队列开始堆积，同一流的报文到达间隔被拉长，NCCL 的 ring/tree 算法会因等待最慢分片而空转。经验上，若 P99 时延是 P50 的 5 倍以上，就应检查 ECN 与 PFC 配置。
二、丢包率：无损网络里的“隐形杀手”
RoCEv2 依赖无损链路，任何丢包都会触发重传，而重传在 AI 训练中代价极高。丢包率通常用 rx_discards、tx_discards、out_of_buffer 等计数器衡量。判断标准：在无损网络中，持续丢包率应接近 0；若出现非零丢包，优先排查 MTU 不一致、PFC 未生效、或链路误码。注意，丢包率低不代表没问题——PFC 和 ECN 正是为了避免丢包而引入的“代价机制”。
三、PFC 暂停帧与 ECN 标记：一对“刹车与油门”
PFC（Priority Flow Control）是链路级的反压机制：当交换机某优先级队列超过阈值，向下游发送 PAUSE 帧，要求对端暂停发送。PFC 暂停帧计数（rx_pause、tx_pause）反映的是“已经堵到必须刹车”。少量 PFC 可接受，但持续增长意味着拥塞扩散，甚至可能引发 PFC 风暴和死锁。
ECN（Explicit Congestion Notification）是端到端的拥塞信号：交换机在队列超过阈值时标记 IP 头 ECN 位，接收端通过 CNP 通知发送端降速。ECN 标记比例（ecn_marked / 总包数）反映“提前预警”的频率。理想状态是 ECN 先动、PFC 后动；若 PFC 先于 ECN 大量出现，说明 ECN 阈值设置过高或未启用。
四、拥塞控制窗口：从 DCQCN 到端到端速率
RoCEv2 常用 DCQCN 拥塞控制。发送端维护一个拥塞窗口（cwnd）和速率（rate），收到 CNP 后按乘性降速，随后加性恢复。窗口大小直接决定单流吞吐：窗口过小则带宽跑不满，窗口过大则队列堆积。诊断时关注 cwnd 的波动幅度——若频繁大幅抖动，说明 ECN 标记过于激进或 RTT 估计不准。
五、GPU 利用率与网络相关性：把两条曲线叠起来看
GPU 利用率（sm__cycles_active 或 nvidia-smi 的 util）单独看没有意义。真正有价值的是把 GPU 利用率曲线与网络吞吐、PFC、ECN 曲线放在同一时间轴上对比：
- GPU 利用率周期性掉坑，同时网络吞吐也掉坑 → 网络拥塞导致通信等待；
- GPU 利用率掉坑但网络吞吐平稳 → 瓶颈在计算、数据加载或同步；
- GPU 利用率高但网络吞吐低 → 计算密集，网络不是瓶颈；
- GPU 利用率与 PFC 暂停帧同步上升 → 反压已经传导到计算侧。
下面这张图把九类指标组织成一条从“链路负载”到“GPU 表现”的因果链，并标出每类指标的典型观察点和异常指向。
六、实操：如何把指标串起来看
假设一个 8 节点、每节点 8 张 400Gb/s 网卡的集群，运行 175B 模型训练。采集窗口 10 秒，观察到以下示例数据（均为教学假设值）：
| 指标 | 正常参考 | 本次观测 | 指向 |
|---|---|---|---|
| 链路带宽利用率 | 70%～90% | 95% | 接近饱和 |
| P99 时延 | < 50μs | 180μs | 排队严重 |
| 抖动（P99-P50） | < 20μs | 120μs | 队列不稳定 |
| 丢包率 | ≈ 0 | 0.001% | 已出现重传 |
| PFC 暂停帧 | 接近 0 | 持续增长 | 反压已触发 |
| ECN 标记比例 | 1%～5% | 18% | 拥塞预警频繁 |
| cwnd | 稳定 | 大幅抖动 | 降速恢复反复 |
| GPU 利用率 | > 90% | 72% 周期性掉坑 | 通信等待 |
判读顺序：先看 GPU 利用率是否与网络吞吐同步掉坑，确认网络是瓶颈；再看 PFC 与 ECN 谁先动。本例中 ECN 标记 18% 且 PFC 持续增长，说明 ECN 阈值可能偏高，队列已经堆到触发 PFC 才被标记。调整方向：降低 ECN 标记阈值（例如从 60% 队列降到 40%），让 ECN 更早介入，减少 PFC 触发；同时检查是否有单条流或单个节点成为热点，必要时用 perftest 或 ib_write_bw 做点对点基线测试。
七、指标采集与观察建议
在 NVIDIA 集群中，常用采集路径包括：网卡侧 ethtool -S 查看 rx_pause、tx_pause、rx_discards；交换机侧通过 show interface counters 或 telemetry 流式采集 ECN/PFC 计数；GPU 侧用 DCGM 采集 sm__cycles_active。建议统一时间戳，把三类数据对齐到同一时间轴，才能做相关性判断。采集频率建议 1 秒，训练任务启动后至少观察 5 分钟，覆盖 warmup 和稳态两个阶段。
最后强调一个原则：任何单一指标都不能直接下结论。带宽高可能是好事，也可能是拥塞前兆；PFC 为 0 可能是健康，也可能是阈值失灵。把带宽、时延、抖动、丢包、PFC、ECN、cwnd、GPU 利用率放在同一条因果链上交叉验证，才能从“看到异常”走到“定位原因”。