Incident Library

IL-0421 Alibaba Group · 2025-05-23 (게시일)ai-infra

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

Alibaba 의 AI 클러스터에서는 같은 작업의 GPU 들이 학습 스텝마다 기울기, 파라미터, 활성값을 주고받으며 동기화한다. 그래서 어느 워커 하나에서 예외가 나도 뒤따르는 워커가 막혀 작업 전체가 죽는다. 작업은 마지막으로 유효한 체크포인트에서 전체를 다시 시작해야 했다. Alibaba 의 경험으로는 고성능 GPU 제품일수록 오류율이 높았고, 규모가 커질수록 작업이 죽을 가능성이 커졌다. 효율적인 감지와 진단 도구가 없을 때는 시간의 약 30% 를 오류 감지, 시스템 진단, 결함 노드 격리, 프로세스 재시작에 썼다.

내부 고객이 GPU 2,400개로 한 달 넘게 돌리는 1,750억 파라미터 GPT 학습 작업의 기록을 보면, 2023년 6월에 오류로 잃은 시간이 전체의 31.19% 였다. 진단과 격리가 19.65% 로 가장 컸는데, 원인을 정확히 찾는 데 몇 시간에서 며칠이 걸렸기 때문이다. 진단과 격리 시간 안에서는 ECC/NVLink 오류가 8.34%, CUDA 오류가 4.19%, CCL 타임아웃이 3%, ACK 타임아웃이 1.8%, 원인 미상이 2.29% 였다. 두 번째는 마지막 체크포인트 뒤에 날아간 계산으로 7.53% 였는데, 사용자가 대규모 클러스터의 높은 오류율을 예상하지 못하고 체크포인트를 드물게 잡았기 때문이다. 오류 감지에 3.41%, 재초기화에 0.6% 가 들었다. GPU ECC 오류, NVLink 오류, CUDA 오류 같은 GPU 결함은 전체 다운타임의 12.53% 였고, 전체 부담의 약 2/3 를 차지했다.

Alibaba 는 C4 를 만들었다. C4 의 한 부분인 C4D 는 Alibaba 의 통신 라이브러리 ACCL 을 고쳐 집합 통신 연산과 메시지 완료 시각을 기록한다. 워커들은 같은 주기로 돌며 동기화 지점에서 만나므로, C4D 는 이 점을 이용해 늦거나 멈춘 워커를 찾아낸다. 이상이 보이면 작업 관리 서비스가 문제 노드를 격리하고 가장 최근의 유효한 체크포인트에서 작업을 다시 시작한다. 근본 원인 분석은 오프라인으로 미룬다. C4D 를 배포한 뒤인 2023년 12월에는 오류로 잃은 시간이 1.16% 로 약 30배 줄었다. 오류 감지와 결함 부품 특정은 수십 초로 줄었지만 노드를 격리하고 작업을 다시 시작하는 데는 여전히 몇 분이 걸렸다. 사용자는 10분마다 체크포인트를 저장하게 되었고, 여섯 달 동안 가장 취약한 부품을 찾아 보강해 평균 오류율이 3.33배 줄었다.

심각도
–
영향 범위
LLM training jobs crashed and restarted from checkpoints; one 2400-GPU job lost 31.19% of its time to errors in June 2023, and one 4,096-GPU job crashed 40 times in a month
영향 사용자
Alibaba's customers training LLMs, including an internal customer
지역
–
감지까지
–
복구까지
–

증상

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

그 40번을 원인별로 나누면 ECC/NVLink 오류 27.5%, ACK timeout 27.5%, NCCL timeout 20%, CUDA 오류 12.5%, 그 밖의 원인 12.5% 였다. 앞의 넷은 사용자에게 NCCL Error 로 보였고 마지막은 Network Error 로 보였다. 오류의 약 82.5% 는 특정 노드나 장치 하나에 국한되었다.

GPU 하드웨어 문제로 워커 프로세스 하나가 죽으면, 그 워커에게 메시지를 보낸 이웃 워커가 응답을 받지 못해 통신 라이브러리가 오류 코드 12 를 냈다. 같은 오류 코드는 네트워크가 끊겼을 때, 메모리가 넘쳐 컨테이너가 축출되었을 때, 사용자 코드에서 텐서 크기가 맞지 않았을 때도 났다. 증상이 비슷해서 사람이 직접 원인을 찾고 결함 노드를 가려내는 데 몇 시간에서 며칠이 걸렸다.

오류가 난 뒤에도 사용자는 작업이 멈춘 줄 바로 알지 못했다. PyTorch 작업은 elastic agent 가 프로세스를 죽일 때까지 최대 30분 동안 멈춰 있을 수 있었다.

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

원인

원인 하드웨어 고장

구성 요소 GPU 하드웨어·메모리NCCLPyTorch
기여 요인 모니터링 사각지대미검증 가정
촉발
–

감지

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

조치

후속 조치

교훈

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

출처

참고 문서

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: GPU 하드웨어·메모리, NCCL, PyTorch. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.