{"id":"IL-0478","org":"Amazon","date":"2026-05-18","docs":["https://github.com/amzn/fkat"],"title":{"en":"A failed GPU network adapter made NCCL silently reroute through GPU 0's adapter and slowed MoE training steps","ko":"GPU 한 개의 네트워크 어댑터가 고장 났는데 NCCL이 알림 없이 통신을 우회시켜 MoE 학습 스텝이 느려졌다"},"domain":["ai-infra","networking"],"impact":{"scope":"Large-scale MoE foundation model training: each training step about 0.3 s slower (8.7 s instead of 8.4 s)","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"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.","ko":"NCCL의 대체 경로는 작업 실패를 막지만 하드웨어 문제를 가린다. 짧게 도는 NCCL 테스트와 GPU burn-in은 기능의 정확성만 확인하므로, 점검을 통과한 노드도 실제 학습에서는 계속 뒤처질 수 있다. 동기화가 많은 MoE 학습에서는 1초도 안 되는 차이가 층과 스텝을 지나며 큰 효율 손실로 쌓인다. 그래서 학습 중에 성능을 보는 모니터링과, 노드를 다시 서비스에 넣기 전의 독립된 오프라인 검증이 함께 필요하다."},"related":[],"sources":[{"url":"https://arxiv.org/abs/2605.17879","kind":"paper","archived":"https://web.archive.org/web/20260608064905/https://arxiv.org/abs/2605.17879"}],"summary":{"en":"The Guard paper by Amazon's Store Foundational AI team describes straggler detection and node health management for large-scale training on clusters of thousands of GPUs in 8-GPU nodes, with NVLink inside nodes and external network cards between them. It calls machines that pass health checks for hard failures but run slower in real workloads grey nodes, and slow communication from a failed network adapter is one cause it describes. NCCL falls back to another GPU's adapter, usually GPU 0's, without a hardware alert; the job keeps running, but that adapter carries about double the traffic, each training step takes about 0.3 seconds longer, and resolving the degraded path brought step time from 8.7 s back to 8.4 s. In MoE models the delay comes back at every synchronization phase and adds up over training.\n\nGuard finds such nodes in two steps. Online monitoring, collected through NVIDIA DCGM and sidecar processes every 30 seconds to 1 minute, tracks GPU and network metrics including network device status, error counts and transmission rate, compares each node with its peers in the same job and treats training step time as the main signal; a node that deviates on several indicators for consecutive windows is removed from the healthy pool. An offline node sweep then runs single-node and multi-node workloads for 1–2 hours before the node may return, and misrouted traffic shows at once as higher latency or lower bandwidth even in a 2-node sweep. Nodes that fail the sweep stay quarantined for repair or re-imaging.","ko":"Amazon Store Foundational AI 팀의 대규모 학습 클러스터에서 NCCL은 GPU마다 전용 네트워크 어댑터를 배정해 쓴다. GPU 한 개의 어댑터가 고장 나면 NCCL은 하드웨어 고장 알림 없이 그 GPU의 통신을 다른 GPU의 어댑터, 보통 GPU 0의 어댑터로 우회시킨다. 논문의 표 1에서는 GPU7의 어댑터가 내려가 GPU7의 통신이 NIC 0으로 나갔다. 이 우회로 작업은 바로 실패하지 않았지만, 남은 어댑터의 트래픽이 사실상 두 배가 되어 유효 대역폭이 줄고 경로가 비대칭이 되었다.\n\nMoE 학습은 토큰 dispatch와 결과 combine에서 Expert 병렬 그룹 전체가 통신하므로, 한 노드의 느린 통신이 이 동기화 지점마다 병목이 된다. MoE 층이 32개인 모델이라면 이 지연이 층마다 쌓인다. 학습 스텝마다 약 0.3초가 늘었다. GPU burn-in과 NCCL 테스트는 기능의 정확성만 보고 우회를 허용하므로 이런 노드를 잡지 못했다. 그 노드는 표준 점검을 통과하면서도 실제 학습에서 다른 노드보다 뒤처졌다. 성능이 떨어진 통신 경로를 바로잡자 스텝 시간이 8.7초에서 8.4초로 줄었다. Amazon은 이런 노드를 찾으려고 학습 중의 온라인 모니터링과 오프라인 노드 스윕을 묶은 Guard를 만들었다."},"trigger":{"en":"The network adapter of one GPU on a node failed.","ko":"노드 안 GPU 한 개에 배정된 고대역폭 네트워크 어댑터가 고장 나 내려갔다."},"severity":"unknown","symptoms":["throughput-degraded"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"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.","ko":"하드웨어 고장 알림은 없었다. network packets transmitted 지표에서 남은 어댑터의 트래픽이 비정상적으로 높게 나타났고, GPU와 NIC의 배정을 보니 GPU7의 통신이 NIC 0으로 나가고 있었다."},"components":["nccl","network-link"],"root_cause":"hardware-failure","remediation":[{"text":{"en":"Resolved the degraded communication path, which brought training step time from 8.7 s back to 8.4 s","ko":"성능이 떨어진 통신 경로를 바로잡았고, 학습 스텝 시간이 8.7초에서 8.4초로 줄었다."}}],"action_items":[{"text":{"en":"Monitor each node's network device status continuously to find and isolate nodes whose traffic NCCL rerouted","ko":"네트워크 장치의 링크 상태를 계속 모니터링해, 성능 저하가 번지기 전에 영향받은 노드를 찾아 격리한다."}},{"text":{"en":"Remove a node flagged by online monitoring from the healthy node pool and schedule it for offline verification","ko":"온라인 모니터링이 표시한 노드는 정상 노드 풀에서 빼고 오프라인 검증 일정을 잡는다."}},{"text":{"en":"Run a multi-node sweep that stresses cross-node collective communication to expose degraded links and misrouted traffic","ko":"노드 사이 집합 통신에 부하를 거는 다중 노드 스윕을 돌려, 성능이 떨어진 링크와 통신 라이브러리의 우회를 찾는다."}},{"text":{"en":"Trigger node sweeps after anomalies found by online monitoring and after repairs, before a node re-enters production","ko":"모든 노드를 주기적으로 스윕하지 않고, 온라인 모니터링이 이상을 찾았을 때나 수리를 마친 뒤에 스윕을 실행한다."}}],"contributing":["monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"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.\n\nNCCL normally gives each GPU its own network adapter. When a GPU's adapter fails, NCCL sends that GPU's traffic through another GPU's adapter, typically GPU 0's; in the paper's Table 1, GPU7 expected NIC 7 but actually used NIC 0 (misrouted), with the status \"Faulty (adapter down)\". The remaining adapter then carried about double the network traffic, which lowered effective bandwidth and made routing asymmetric.\n\nThe slowdown was worst in Mixture of Experts (MoE) training, where token dispatch and result combination both communicate across the whole expert-parallel group, and in a model with 32 MoE layers the delay repeats in every layer. Because the rerouting keeps communication working, the node stays in the job and keeps lagging behind its peers.","ko":"대규모 MoE 학습의 스텝 시간이 약 0.3초 늘어 8.4초가 아닌 8.7초가 걸렸다. 하드웨어 고장 알림은 없었고, 노드는 표준 상태 점검을 통과했다.\n\nGPU마다 전용 네트워크 어댑터가 배정되어 있는데, GPU7의 어댑터가 내려간 뒤 GPU7의 통신이 GPU0의 어댑터로 나가고 있었다. 남은 어댑터에 부하가 몰려 network packets transmitted 지표에서 그 어댑터의 트래픽이 사실상 두 배로 늘었다.\n\nMoE 학습에서는 토큰 dispatch와 결과 combine 두 곳에서 Expert 병렬 그룹 전체가 통신하며 동기화한다. 한 노드가 제 성능을 못 내면 이 동기화 지점마다 병목이 생기고, MoE 층이 32개인 모델에서는 층마다 지연이 쌓인다.\n\nNCCL 테스트는 연결성을 우선해 이런 우회를 허용하므로, 우회 중인 노드도 테스트를 통과했다. 몇 초 동안만 도는 NCCL 테스트로는 줄어든 대역폭과 비대칭 경로가 드러나지 않았다."},"updated_at":"2026-11-14T12:34:12.428430Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0478","org_slug":"amazon"}