사례2건

2건 중 1~2번째

1. 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 는 결함을 찾으면 곧바로 격리하고 다시 시작했으며, 깊은 원인 분석은 오프라인으로 미뤘다. 그러자 사람이 개입할 일이 없어져 수십 분 걸리던 일이 몇 초로 줄었다. 마지막 체크포인트 뒤에 잃는 시간을 줄이려면 체크포인트를 자주 저장해야 한다.

   사례 보기
2. IL-0249 공유 GPU 클러스터의 대규모 학습 작업이 멈추지 않은 채 느려지는 fail-slow 로 완료 시간이 평균 1.34배로 늘었다

   Alibaba Group2024

   증상

   학습 작업은 멈추지 않았지만 처리량이 떨어졌고, 그 작업이 쓰는 모든 GPU 의 SM 사용률이 같은 순간에 함께 떨어졌다. 이런 fail-slow 는 수십 초에서 열 시간 가까이 이어졌다.

   처리량 저하

   원인

   용량 한계

   구성 요소

   InfiniBand 패브릭GPU 하드웨어·메모리

   기여 요인

   장애 중첩모니터링 사각지대

   감지

   당시 현장에서는 fail-slow 를 사람이 손으로 찾았다. 조사에서는 프로브 작업이 실행 중에 성능 지표를 모아 연산과 통신 fail-slow 를 찾았고, 대규모 학습 작업의 한 달 치 기록은 연구자들이 손으로 살폈다. Meta 와 ByteDance 도 대규모에서는 fail-slow 를 찾기 어렵다고 보고했고, 다른 회사 엔지니어들의 의견도 같았다.

   조치

   • 당시 현장에서는 fail-slow 를 손으로 찾은 뒤 fail-stop 처럼 다뤄, 체크포인트를 남기고 학습 작업을 다시 시작하는 장애 조치로 대응했다.

   후속 조치

   • Falcon-Detect 를 만든다. Falcon-Detect 는 학습 프레임워크에 손대지 않고 워커마다 반복 시간을 추적한다. 시계열에서 변화 시점을 찾는 BOCD 알고리즘으로 반복이 길어진 시점을 찾고, 가벼운 프로파일링으로 의심되는 워커 그룹을 좁힌다. 그 뒤 학습을 잠깐 멈추고 벤치마크를 돌려 느린 GPU 와 링크를 찾아낸다.
   • Falcon-Mitigate 를 만든다. Falcon-Mitigate 의 대응은 네 단계다. 아무것도 하지 않기, 데이터 병렬 그룹 사이에서 micro-batch 다시 나누기, 병렬화 토폴로지를 바꿔 혼잡한 링크를 트래픽이 적은 그룹으로 옮기기, 체크포인트에서 재시작하기다. 비용이 낮은 단계부터 시작하고, fail-slow 가 이어지는데 지금 방법이 듣지 않으면 다음 단계로 넘어간다. 체크포인트에서 재시작하기는 마지막 수단이다.

   교훈

   fail-slow 는 대개 일시적이다. 연산 저하는 느린 GPU 나 CPU 경합에서 오고, 통신 저하는 주로 네트워크 혼잡에서 온다. 연산 fail-slow 는 짧고 드물지만 노드 사이 통신 fail-slow 는 더 잦고 오래 이어져 학습을 더 크게 늦춘다. 학습 규모가 커지면 여러 성능 문제가 동시에 생길 가능성이 커지고, 겹친 영향으로 학습이 90% 넘게 느려질 수 있다. fail-slow 는 대개 일시적이므로 체크포인트에서 재시작하는 fail-stop 대응은 지나치다. 어떤 대응이 맞는지는 fail-slow 가 얼마나 오래, 얼마나 심하게 이어질지에 달렸지만 이는 미리 알 수 없다.

   사례 보기

원인별2