4. 故障类型概览
在AI算力集群中，网络延迟故障的表现形式多种多样，但根源往往可以归纳为几大类。如果缺乏分类框架，排障时容易陷入“头痛医头”的被动局面——看到丢包就调流控，看到重传就换网线，结果问题反复出现。本章从工程实践出发，将延迟故障划分为硬件故障、配置错误、拥塞、路由问题四大类，并补充协议栈与驱动异常作为第五类常见诱因，为后续章节的定位方法建立统一的分类坐标系。
4.1 为什么需要分类：从现象到根因的映射
延迟指标（如RTT、P99时延）是最终结果，但导致该结果的路径却可能截然不同。例如，一条100μs的额外延迟，可能是光纤老化导致FEC纠错开销增加，也可能是ECMP哈希不均导致某条链路拥塞，还可能是路由表未更新导致报文绕行。没有分类框架时，工程师往往先怀疑物理层，再怀疑配置，排查顺序混乱，平均修复时间（MTTR）被显著拉长。
分类的核心价值在于建立“现象→类别→根因”的快速映射。当延迟异常出现时，首先根据特征（如是否伴随丢包、是否单点波动、是否与流量峰值相关）判断属于哪一大类，再在大类内使用针对性工具深挖。下图展示了五大故障类别及其典型特征、常见根因和初步判断线索：
4.2 硬件故障：物理层的隐性杀手
硬件故障是AI集群中最容易被误判为“软件问题”的延迟来源。以400G光模块为例，当激光器老化导致光功率从+2dBm降至-5dBm时，链路仍能维持“UP”状态，但误码率（BER）会从10⁻¹⁵劣化到10⁻⁹量级。此时FEC（前向纠错）持续工作，每纠正一个错误码字都会引入额外的处理延迟——实测中，RS-FEC(544,514)在纠错状态下的延迟可比无错状态增加80～150ns/跳，虽然单跳看似微小，但跨20跳的RoCEv2通信就会累积出微秒级延迟。
硬件故障的典型场景包括：
- 光模块/光缆劣化：表现为延迟缓慢爬升，伴随CRC错误计数增加。检查命令：
ethtool -S eth0 | grep crc，若CRC错误持续增长，基本可判定物理层问题。 - 端口/连接器接触不良：延迟呈间歇性尖峰，与振动或温度变化相关。常见于机柜顶部（TOR）交换机到服务器之间的跳线。
- PCB/芯片虚焊：在训练集群中表现为“幽灵延迟”——重启后消失，高负载下复现。这类问题最难定位，往往需要结合温度监测和长时间流量统计。
4.3 配置错误：人为因素的高发区
配置错误在AI集群中占比极高，尤其是在跨团队协作的场景下（网络团队配置交换机、平台团队配置宿主机、应用团队配置容器网络）。一个典型的案例是MTU不一致：交换机端口MTU设置为9000，而宿主机bond接口MTU仍为1500。此时大包（如RDMA Write）会被交换机丢弃，触发TCP或RoCE重传，延迟从正常的10μs飙升至毫秒级。
常见的配置错误包括：
| 配置项 | 错误示例 | 延迟影响 | 快速检查方法 |
|---|---|---|---|
| MTU | 交换机9000 / 主机1500 | 大包重传，延迟×100 | ping -M do -s 8972 |
| 流控（PFC） | 发送端开启，接收端关闭 | 缓冲区溢出丢包 | ethtool -a eth0 |
| EEE节能以太网 | 误开启 | 低流量时延迟+200μs | ethtool --show-eee eth0 |
| 速率/双工协商 | 强制100G vs 自协商 | 协商失败或降速 | ethtool eth0 |
配置错误的特征是“变更后出现”。如果延迟问题恰好发生在网络割接、驱动升级或容器平台更新之后，应优先怀疑配置漂移。建议建立配置基线库，每次变更前导出全量配置，变更后自动diff。
4.4 网络拥塞：动态资源竞争
拥塞是AI集群中最“公平”的延迟来源——它不针对特定链路，而是发生在流量汇聚点。在All-to-All通信模式下，多个GPU节点同时向同一组参数服务器发送数据，瞬间流量可能超过链路带宽的2～3倍，形成微突发（Microburst）。由于交换机缓冲区有限（通常8～16MB），微突发直接导致队列深度增长，延迟从微秒级跳到百微秒级。
拥塞的两种主要形态：
- 持久拥塞：流量长期超过链路容量，如多租户共享同一上行链路。表现为延迟持续偏高，队列深度稳定在较高水位。
- 瞬时拥塞（微突发）：毫秒级流量尖峰，监控系统往往抓不到（采样间隔1s会漏掉90%的微突发）。表现为应用层感知到延迟抖动，但交换机统计显示平均利用率仅40%。
拥塞的深层原因往往与ECMP哈希不均有关。例如，8条100G上行链路，由于哈希算法基于五元组，而AI流量大多使用相同的目的端口（如RoCEv2的UDP端口4791），导致流量集中在少数链路上。检查方法：登录交换机查看各成员链路的利用率，若偏差超过20%，则需要调整哈希种子或改用动态负载均衡。
4.5 路由问题：路径的隐形绕行
路由问题在AI集群中相对少见，但一旦发生，影响范围通常是整个租户或整个集群。典型场景包括：
- 路由黑洞：某台交换机路由表被错误清空，转发时查表失败直接丢弃。表现为特定目的网段“通一半”（部分路径正常，部分路径丢包）。
- 路由环路：BGP配置错误导致路由在两台交换机之间循环，TTL递减导致报文最终被丢弃。延迟表现为剧烈抖动，且traceroute会看到重复的跳数。
- 非对称路由：去程和回程路径不一致，在存在状态化防火墙或NAT时会导致报文被丢弃。AI集群中常见于多租户隔离场景。
路由问题的排查思路是“先看路径，再看表项”。使用traceroute -n确认实际转发路径，对比预期路径；登录沿途设备检查路由表（show ip route / show bgp summary），重点关注最近是否有路由抖动（flapping）记录。
4.6 协议栈与驱动异常：主机侧的隐形瓶颈
这一类别常被网络团队忽略，因为问题根源不在网络设备上，而在服务器的CPU/网卡驱动/内核协议栈中。AI集群大量使用RDMA（RoCEv2），其数据路径虽然绕过内核，但控制路径（建连、错误处理）仍依赖驱动和固件。
典型场景：某型号网卡在特定驱动版本下，当队列对（QP）数量超过512时，硬件中断处理出现瓶颈，导致延迟从5μs增加到50μs。另一个案例是中断合并（Interrupt Coalescing）配置过激进——网卡等待积累更多报文才触发中断，虽然降低了CPU占用，但将延迟从10μs拉高到100μs。
top查看软中断占用（si%），ethtool -S eth0查看rx_packets与rx_interrupts的比例，以及cat /proc/interrupts确认中断是否均匀分布在多个CPU核心上。AI集群中约15%的“网络延迟”问题实际是主机协议栈或驱动问题。
4.7 分类之外的交叉场景与排障优先级
实际故障往往不是单一类别，而是因果链。例如：光模块劣化（硬件）→ CRC错误增加 → 链路层重传 → 有效带宽下降 → 队列堆积（拥塞）→ 应用感知延迟飙升。如果只看到“拥塞”表象，可能会去调整流控或ECN阈值，但根本问题在硬件。因此，排障时应遵循以下优先级：
- 先物理层：检查光功率、CRC、FEC——排除成本最低，且一旦确认可快速更换。
- 再配置层：对比基线配置，检查MTU、流控、速率协商——变更管理记录是关键线索。
- 然后看流量：分析是否拥塞，区分持久/瞬时，检查ECMP均衡性。
- 接着查路由：确认路径正确性，排除黑洞/环路。
- 最后深挖主机：驱动、中断、卸载特性——需要跨团队协作。