사례2건

2건 중 1~2번째

1. IL-0478 GPU 한 개의 네트워크 어댑터가 고장 났는데 NCCL이 알림 없이 통신을 우회시켜 MoE 학습 스텝이 느려졌다

   Amazon2026

   증상

   대규모 MoE 학습의 스텝 시간이 약 0.3초 늘어 8.4초가 아닌 8.7초가 걸렸다. 하드웨어 고장 알림은 없었고, 노드는 표준 상태 점검을 통과했다.

   처리량 저하

   촉발

   노드 안 GPU 한 개에 배정된 고대역폭 네트워크 어댑터가 고장 나 내려갔다.

   원인

   하드웨어 고장

   구성 요소

   NCCLNIC·케이블·스위치 포트 링크

   기여 요인

   모니터링 사각지대

   감지

   하드웨어 고장 알림은 없었다. network packets transmitted 지표에서 남은 어댑터의 트래픽이 비정상적으로 높게 나타났고, GPU와 NIC의 배정을 보니 GPU7의 통신이 NIC 0으로 나가고 있었다.

   조치

   • 성능이 떨어진 통신 경로를 바로잡았고, 학습 스텝 시간이 8.7초에서 8.4초로 줄었다.

   후속 조치

   • 네트워크 장치의 링크 상태를 계속 모니터링해, 성능 저하가 번지기 전에 영향받은 노드를 찾아 격리한다.
   • 온라인 모니터링이 표시한 노드는 정상 노드 풀에서 빼고 오프라인 검증 일정을 잡는다.
   • 노드 사이 집합 통신에 부하를 거는 다중 노드 스윕을 돌려, 성능이 떨어진 링크와 통신 라이브러리의 우회를 찾는다.
   • 모든 노드를 주기적으로 스윕하지 않고, 온라인 모니터링이 이상을 찾았을 때나 수리를 마친 뒤에 스윕을 실행한다.

   교훈

   NCCL의 대체 경로는 작업 실패를 막지만 하드웨어 문제를 가린다. 짧게 도는 NCCL 테스트와 GPU burn-in은 기능의 정확성만 확인하므로, 점검을 통과한 노드도 실제 학습에서는 계속 뒤처질 수 있다. 동기화가 많은 MoE 학습에서는 1초도 안 되는 차이가 층과 스텝을 지나며 큰 효율 손실로 쌓인다. 그래서 학습 중에 성능을 보는 모니터링과, 노드를 다시 서비스에 넣기 전의 독립된 오프라인 검증이 함께 필요하다.

   사례 보기
2. IL-0421 Alibaba 의 LLM 학습 클러스터에서 GPU 결함을 비롯한 오류로 작업이 거듭 죽어 2023년 6월 한 작업이 시간의 31.19% 를 잃었다

   Alibaba Group2025

   증상

   GPU 수천 개로 도는 LLM 학습 작업이 자주 죽었고, 사용자 눈에는 원인 대부분이 "NCCL Error" 로만 보였다. 새로 배포한 클러스터에서 GPU 4,096개를 쓰는 대표 작업은 한 달에 40번 죽었다.

   학습 작업 실패NCCL 타임아웃GPU 인식 불가

   원인

   하드웨어 고장

   구성 요소

   GPU 하드웨어·메모리NCCLPyTorch

   기여 요인

   모니터링 사각지대미검증 가정

   감지

   사용자는 작업이 죽은 뒤 대부분 "NCCL Error" 로만 오류를 봤고, 오류가 난 뒤에도 작업이 멈춘 줄 바로 알지 못했다. PyTorch 작업은 elastic agent 가 프로세스를 죽일 때까지 최대 30분 동안 멈춰 있을 수 있었다. 원인을 찾고 결함 노드를 가려내는 일은 사람이 직접 했다. C4D 를 배포한 뒤에는 C4 에이전트가 학습 워커의 상태를 중앙 마스터로 보내고, 마스터가 워커끼리 비교해 이상을 수십 초 안에 찾았다.

   조치

   • GPU 1,024개, 곧 서버 128대마다 백업 서버 8대, 곧 백업 GPU 64개를 더 두었다. 그래서 서버 136대 풀 안의 어느 128대로도 같은 통신과 성능으로 학습을 이어 갈 수 있었다.
   • C4D 가 이상을 찾으면 작업 관리 서비스가 문제 노드를 격리하고 가장 최근의 유효한 체크포인트에서 작업을 다시 시작했다. 같은 이벤트를 백그라운드 근본 원인 분석 시스템으로 보내 오프라인으로 진단했다.
   • 고성능 인프라를 활용해 체크포인트를 더 자주 저장하게 했고, 사용자는 10분마다 체크포인트를 저장할 수 있게 되었다. 마지막 체크포인트 뒤에 잃는 시간이 33배 줄었다.
   • GPU 과열을 막으려고 팬 속도를 높이고 공조를 개선해 냉각을 강화했다.
   • 여섯 달 동안 시스템에서 가장 취약한 부품을 찾아 보강했고, 평균 오류율이 3.33배 줄었다.

   후속 조치

   • 전문가 병렬처럼 워커 사이의 부하가 고르지 않은 경우에도 느린 워커를 정확히 찾도록 C4D 에 부하 변동을 반영한다.

   교훈

   작업을 죽인 오류의 대부분은 특정 노드나 장치에 국한되어 있어서, 결함 부품만 격리하면 다수의 오류에 대처할 수 있었다. 분산 학습은 데이터 병렬 묶음 안의 계산 비용이 고르고 이터레이션마다 동기화하므로, 이 성질을 이용하면 결함 노드를 자동으로 찾을 수 있다. Alibaba 는 결함을 찾으면 곧바로 격리하고 다시 시작했으며, 깊은 원인 분석은 오프라인으로 미뤘다. 그러자 사람이 개입할 일이 없어져 수십 분 걸리던 일이 몇 초로 줄었다. 마지막 체크포인트 뒤에 잃는 시간을 줄이려면 체크포인트를 자주 저장해야 한다.

   사례 보기

원인별1