Cases1 case
1 to 1 of 1
IL-0478A failed GPU network adapter made NCCL silently reroute through GPU 0's adapter and slowed MoE training stepsAmazon2026- Symptoms
In Amazon's large-scale foundation model training, training steps took about 0.3 seconds longer (8.7 s instead of 8.4 s) when a node had a GPU whose network adapter had failed. No hardware failure alert fired, and standard node checks such as GPU burn-in and short NCCL tests rarely catch such nodes.
- Trigger
The network adapter of one GPU on a node failed.
- Root cause
- Component
- Contributing factor
- Detection
No hardware alert or standard health check showed the fault. It showed as slower training steps, in the per-node network device status and transmission rate that Guard monitors, and as elevated latency or reduced bandwidth in a 2-node sweep.
- Remediation
- Resolved the degraded communication path, which brought training step time from 8.7 s back to 8.4 s
- Action items
- Monitor each node's network device status continuously to find and isolate nodes whose traffic NCCL rerouted
- Remove a node flagged by online monitoring from the healthy node pool and schedule it for offline verification
- Run a multi-node sweep that stresses cross-node collective communication to expose degraded links and misrouted traffic
- Trigger node sweeps after anomalies found by online monitoring and after repairs, before a node re-enters production
- Lessons
NCCL's transparent rerouting keeps both the job and NCCL tests working while it hides a failed adapter, so checks that verify functional correctness do not find the node. Amazon relies on performance-aware monitoring during training, with step time as the main signal, and on offline verification under realistic load before nodes return to service.
This case involves NCCL and NIC, cable and switch port link. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.