AI 网络中的链路可靠性与监测
一次训练任务是跨数千块 GPU 的同步计算:每一次集合操作都要等待最慢的链路。一个抖动的光模块不只是让一台服务器慢一点点——它会拖慢整个任务,一旦彻底失效,任务就要从上一个检查点重新开始。因此光模块不再只是一个部件,而成了一项可靠性预算。本页介绍故障发生的数学模型、能够预测问题的指标、组网如何监测和隔离坏链路,以及能压低故障率的运维做法。
为什么一条链路影响这么大
| 事件 | 对训练任务的影响 |
|---|---|
| 链路抖动(数秒) | 集合操作超时或重试;单步耗时飙升;用 NCCL/RCCL 时,足够长的停滞会中止任务 |
| 链路降速/降宽 | 每一次 all-reduce 都被它拖慢;整个集群吞吐量降到该链路的份额 |
| pre-FEC 误码率升高,但尚无不可纠错错误 | 目前还没有影响——但余量已经耗尽;下一个较热的下午它就会开始抖动 |
| 不可纠错的 FEC 错误 | 丢包 → RDMA 重传风暴 → 停滞 |
| 硬故障 | 从检查点重启任务:整个集群损失几分钟到一小时的算力 |
一个千卡 GPU 任务从检查点重启的代价以 GPU 小时计;这个数字才是应该拿来和更好的光模块、更好的 QA 成本作比较的。
故障的算法
光模块可靠性通常用 FIT(每 10⁹ 器件小时的失效数)或 MTBF 表示。
| 假设 | 数值 |
|---|---|
| 组网中的光端口数 | 4 000(一个 1 024-GPU 两层集群) |
| 每端口 FIT(成熟的 400G 光模块,散热良好) | 200–500 |
| 预期每月硬故障数 | 4 000 × 350 × 10⁻⁹ × 720 h ≈ 1 |
| 实际观测到的链路抖动率 | 比硬故障高 5–20 倍——脏污、余量不足、热问题、固件 |
因此硬故障是罕见且可预测的;抖动和劣化链路才是主要问题,而且大多可以预防——这正是监测和 QA 能够回本的原因。
能预测问题的指标
| 指标 | 来源 | 健康范围 | 应对 |
|---|---|---|---|
| 每通道 pre-FEC 误码率 | CMIS VDM;主机 FEC 计数器 | < 10⁻⁷ | > 10⁻⁶ 且上升;> 10⁻⁵ 安排更换 |
| FEC 不可纠错码字数 | 主机 | 0 | 任何增量都是一次事件 |
| 每通道符号错误数 | 主机(以太网)/ perfquery(IB) | 均衡,接近零 | 某一通道明显偏高 |
| 每通道 接收光功率 相对基线 | DDM | 与首日相差 1 dB 以内,各通道间相差 2 dB 以内 | 相对基线 −2 dB |
| 发射偏置电流趋势 | DDM | 平稳 | 相对基线 +15–20 %(发射偏置电流与激光器老化) |
| 模块温度 | DDM | < 60 °C | > 65 °C 或比相邻模块高 +10 °C |
| eSNR(CMIS) | VDM | > 18–20 dB | 某一通道下降 |
| 每端口链路抖动次数 | 交换机日志、组网管理系统 | 0 | 任何数值 |
| 协商速率/宽度 | 交换机 / ibstat | 满速 | 低于额定值 |
定义和格式见:VDM 与 FEC 指标、 监测。
监测架构
| 组网 | 采集方式 | 工具 |
|---|---|---|
| InfiniBand | 子网/组网管理器轮询每个端口的计数器及线缆 EEPROM/DDM | UFM 类管理器、ibdiagnet、mlxlink -m |
| 以太网(RoCE) | 以 10–60 秒周期通过 gNMI/OpenConfig 流式传输光模块和 FEC 状态;SNMP 作为回退 | gnmic → Prometheus/Grafana、厂商遥测(用工具读取 DDM) |
| 主机侧 | 网卡计数器:重传、CNP、乱序;NCCL/RCCL 日志中的超时 | node exporter |
| 任务侧 | 单步耗时方差、慢节点检测 | 训练框架指标 |
把三者关联起来看:14:05 的单步耗时突增、14:04 leaf 7 通道 3 上的 pre-FEC 误码率异常、机柜 12 的模块温度峰值,三者合在一起就是一份完整的诊断。
隔离与处置
- 自动禁用端口/绕行:当不可纠错错误或抖动次数超过阈值时——组网管理器和网络操作系统都支持链路错误策略;自适应路由会同时把流量绕开劣化链路。
- 如果问题出在网卡端口,就排空该节点;把任务调度绕开它。
- 上台架检测模块:身份信息、每通道 DDM 与首日基线对比、校验和、固件版本(光模块检测、DDM)。
- 在归咎于模块之前,先清洁并重新检查两端的 MPO——脏污是最常见的原因(物理不匹配)。
- 更换并观察:如果错误跟着模块走,就返厂维修;如果错误留在端口,就检查笼子、光纤和对端。
能降低故障率的做法
| 做法 | 效果 |
|---|---|
| 进料检验和老化(负载和温度下 24–72 小时) | 在故障到达任务之前排除早期失效 |
| 首日建立每通道 DDM 基线 | 把绝对精度(±3 dB)变成精确的差值 |
| 保持模块 < 60 °C——风道、正确使用带散热片/平顶 OSFP、进风口不被遮挡 | 温度每降 10 °C 寿命翻倍 |
| 每次对接都清洁连接器;未用端口加防尘帽 | 大多数抖动都是脏污引起的 |
| 模块和主机固件保持最新 | 修复 CMIS 互操作问题(CMIS 问题) |
| 每层使用同质、已验证的光模块 | 减少主机/模块 DSP 互操作方面的意外 |
| 备件比例 3–5 %,已老化并建立基线 | 更换时不会引发第二次事件 |
| 每周趋势复查 | 按计划更换老化的激光器,而不是等故障发生 |
技术走向
更高的每通道速率(200G/通道、1.6T)进一步压缩了余量;线性(LPO)和 共封装光学取消了 DSP 及其监测功能——把误码率的可见性推到主机侧—— 同时承诺更少的元件和更少的发热(调制与 DSP、AI 中的光模块)。无论用哪种模块,原则不变:建立基线、监测差值、根据趋势采取行动。
在 CodingBox 中
CodingBox 是这个闭环中台架侧的一环:进料检验和老化读数、按序列号存入 代码数据库的首日每通道基线,以及对拔下模块的事后读取——身份信息、固件、校验和与 DDM 都与自身历史记录比对——使 RMA 决策建立在数据之上,而不是端口的最后一条日志记录上。