{"id":"IL-0421","org":"Alibaba Group","date":"2025-05-23","docs":["https://pytorch.org/docs/stable/elastic/agent.html"],"title":{"en":"Errors, mostly GPU faults, crashed Alibaba LLM training jobs as NCCL errors; a job lost 31.19% of its time in June 2023","ko":"Alibaba 의 LLM 학습 클러스터에서 GPU 결함을 비롯한 오류로 작업이 거듭 죽어 2023년 6월 한 작업이 시간의 31.19% 를 잃었다"},"domain":["ai-infra"],"impact":{"scope":"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","users":"Alibaba's customers training LLMs, including an internal customer","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Most crash causes are confined to specific nodes or devices, so isolating the faulty component quickly and restarting, while leaving root cause analysis for offline work, removes most of the error-induced downtime. Because synchronous training makes many different faults look like the same communication error, diagnosis has to use the regular rhythm of the workers at synchronisation points rather than the error message, and frequent checkpoints matter because error rates in large clusters are high.","ko":"작업을 죽인 오류의 대부분은 특정 노드나 장치에 국한되어 있어서, 결함 부품만 격리하면 다수의 오류에 대처할 수 있었다. 분산 학습은 데이터 병렬 묶음 안의 계산 비용이 고르고 이터레이션마다 동기화하므로, 이 성질을 이용하면 결함 노드를 자동으로 찾을 수 있다. Alibaba 는 결함을 찾으면 곧바로 격리하고 다시 시작했으며, 깊은 원인 분석은 오프라인으로 미뤘다. 그러자 사람이 개입할 일이 없어져 수십 분 걸리던 일이 몇 초로 줄었다. 마지막 체크포인트 뒤에 잃는 시간을 줄이려면 체크포인트를 자주 저장해야 한다."},"related":[],"sources":[{"url":"https://arxiv.org/abs/2406.04594","kind":"paper","archived":"https://web.archive.org/web/20260310105341/https://arxiv.org/abs/2406.04594"}],"summary":{"en":"The paper by Alibaba engineers describes C4, a system deployed in Alibaba's production AI training clusters, whose nodes have 8 NVIDIA H800 GPUs and 8 BlueField-3 NICs with two bonded 200Gbps ports each on a 3-tier Clos fat-tree network, running Megatron-LM and DeepSpeed. Training runs in bulk synchronous mode, so an error in any worker blocks the others and crashes the whole job, which then restarts from its last checkpoint; the paper states that high-end GPUs show high error rates, and that without efficient detection and diagnosis tools about 30% of the team's time went into error detection, diagnosis, isolating defective nodes and restarting, leaving 70% for computing. The measurements come from the crash causes of one 4,096-GPU job over one month and from historical job logs of an internal customer's 2400-GPU job before (June 2023) and after (December 2023) C4's fault detection was deployed.\n\nIn June 2023, GPU-related errors (ECC errors, NVLink errors and CUDA errors) caused 12.53% of that job's total downtime, about two thirds of the diagnosis and isolation overhead, in which ECC/NVLink errors took 8.34%, CUDA errors 4.19%, CCL timeouts 3%, ACK timeouts 1.8% and unknown causes 2.29%. Post-checkpoint loss was high because users had set infrequent checkpoints, not expecting high error rates in a large cluster. Alibaba allocates 64 backup GPUs on 8 servers for every 1024 GPUs on 128 servers, and improved cooling with higher fan speeds and better air conditioning. C4D, the detection part of C4, extends Alibaba's collective communication library ACCL to record communicator, operation and transport-layer timings; a central master compares workers at synchronisation points to find hangs and slow communication or computation, tells the job steering service to isolate the faulty nodes and restart from the latest valid checkpoint, and hands the event to offline root cause analysis.\n\nBy December 2023 the job's error-induced downtime had fallen to 1.16%: diagnosis and isolation to 0.73%, post-checkpoint loss to 0.23% after users began checkpointing every 10 minutes, detection to 0.05% and re-initialisation to 0.15%. C4D found faults within tens of seconds, though isolating nodes and restarting still took minutes. GPU-related errors became 3.2 times less frequent and the time they cost fell 41.8 times, other errors fell 3.4 times in frequency and 16.5 times in time, and the average error rate fell 3.33 times after the most vulnerable components were identified and enhanced over the six months. C4D has limited ability to detect errors during job initialisation, before collective communication starts.","ko":"Alibaba 의 AI 클러스터에서는 같은 작업의 GPU 들이 학습 스텝마다 기울기, 파라미터, 활성값을 주고받으며 동기화한다. 그래서 어느 워커 하나에서 예외가 나도 뒤따르는 워커가 막혀 작업 전체가 죽는다. 작업은 마지막으로 유효한 체크포인트에서 전체를 다시 시작해야 했다. Alibaba 의 경험으로는 고성능 GPU 제품일수록 오류율이 높았고, 규모가 커질수록 작업이 죽을 가능성이 커졌다. 효율적인 감지와 진단 도구가 없을 때는 시간의 약 30% 를 오류 감지, 시스템 진단, 결함 노드 격리, 프로세스 재시작에 썼다.\n\n내부 고객이 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 를 차지했다.\n\nAlibaba 는 C4 를 만들었다. C4 의 한 부분인 C4D 는 Alibaba 의 통신 라이브러리 ACCL 을 고쳐 집합 통신 연산과 메시지 완료 시각을 기록한다. 워커들은 같은 주기로 돌며 동기화 지점에서 만나므로, C4D 는 이 점을 이용해 늦거나 멈춘 워커를 찾아낸다. 이상이 보이면 작업 관리 서비스가 문제 노드를 격리하고 가장 최근의 유효한 체크포인트에서 작업을 다시 시작한다. 근본 원인 분석은 오프라인으로 미룬다. C4D 를 배포한 뒤인 2023년 12월에는 오류로 잃은 시간이 1.16% 로 약 30배 줄었다. 오류 감지와 결함 부품 특정은 수십 초로 줄었지만 노드를 격리하고 작업을 다시 시작하는 데는 여전히 몇 분이 걸렸다. 사용자는 10분마다 체크포인트를 저장하게 되었고, 여섯 달 동안 가장 취약한 부품을 찾아 보강해 평균 오류율이 3.33배 줄었다."},"trigger":null,"severity":"unknown","symptoms":["training-job-failed","nccl-timeout","gpu-unavailable"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Before C4D, users found crashes through NCCL errors and could stay unaware of a stalled job for up to 30 minutes until the PyTorch elastic agent killed it; C4D later detects hangs and slowdowns from collective communication timings within tens of seconds.","ko":"사용자는 작업이 죽은 뒤 대부분 \"NCCL Error\" 로만 오류를 봤고, 오류가 난 뒤에도 작업이 멈춘 줄 바로 알지 못했다. PyTorch 작업은 elastic agent 가 프로세스를 죽일 때까지 최대 30분 동안 멈춰 있을 수 있었다. 원인을 찾고 결함 노드를 가려내는 일은 사람이 직접 했다. C4D 를 배포한 뒤에는 C4 에이전트가 학습 워커의 상태를 중앙 마스터로 보내고, 마스터가 워커끼리 비교해 이상을 수십 초 안에 찾았다."},"components":["gpu-hardware","nccl","pytorch"],"root_cause":"hardware-failure","remediation":[{"text":{"en":"Allocated 64 backup GPUs on 8 servers for every 1024 GPUs on 128 servers, so that parallel training on any 128 servers of the 136-server pool keeps the same communication and performance","ko":"GPU 1,024개, 곧 서버 128대마다 백업 서버 8대, 곧 백업 GPU 64개를 더 두었다. 그래서 서버 136대 풀 안의 어느 128대로도 같은 통신과 성능으로 학습을 이어 갈 수 있었다."}},{"text":{"en":"Deployed C4D to detect faulty nodes automatically, isolate them and restart the job from the most recent valid checkpoint","ko":"C4D 가 이상을 찾으면 작업 관리 서비스가 문제 노드를 격리하고 가장 최근의 유효한 체크포인트에서 작업을 다시 시작했다. 같은 이벤트를 백그라운드 근본 원인 분석 시스템으로 보내 오프라인으로 진단했다."}},{"text":{"en":"Saved checkpoints more often, every 10 minutes, to cut the work lost after each crash","ko":"고성능 인프라를 활용해 체크포인트를 더 자주 저장하게 했고, 사용자는 10분마다 체크포인트를 저장할 수 있게 되었다. 마지막 체크포인트 뒤에 잃는 시간이 33배 줄었다."}},{"text":{"en":"Enhanced cooling with higher fan speeds and better air conditioning to keep GPUs from overheating","ko":"GPU 과열을 막으려고 팬 속도를 높이고 공조를 개선해 냉각을 강화했다."}},{"text":{"en":"Identified and enhanced the most vulnerable components of the system, lowering the average error rate 3.33 times","ko":"여섯 달 동안 시스템에서 가장 취약한 부품을 찾아 보강했고, 평균 오류율이 3.33배 줄었다."}}],"action_items":[{"text":{"en":"Take load variation into account in C4D for more precise slow detection","ko":"전문가 병렬처럼 워커 사이의 부하가 고르지 않은 경우에도 느린 워커를 정확히 찾도록 C4D 에 부하 변동을 반영한다."}}],"contributing":["monitoring-blind-spot","assumption-unverified"],"recurrence_of":null,"symptoms_text":{"en":"Large LLM training jobs on Alibaba's AI clusters crashed again and again and had to restart from the last valid checkpoint. One of the largest jobs, on 4,096 GPUs in a newly deployed cluster, crashed 40 times in one month, and most crashes reached users only as \"NCCL Errors\".\n\nThe error users saw rarely named the cause. When a hardware problem in one GPU crashed one worker process, its peers got no acknowledgment for the messages they had sent to it and the communication library raised error code 12, the same code that network disconnections, container evictions after memory overflows or user code errors such as tensor size mismatches also produce. Behind the 40 crashes were ECC/NVLink errors (27.5%), ACK timeouts (27.5%), NCCL timeouts (20%), CUDA errors (12.5%) and other causes shown to users as a network error (12.5%); about 82.5% of the errors were confined to specific nodes or single devices.\n\nThe time went into finding the bad node rather than the crash itself. Identifying the cause and locating the defective node by hand took hours or even days in a cluster with thousands of GPUs. Users were also not told right away that a job had stalled: a PyTorch job could hang for up to 30 minutes until the elastic agent killed its processes. In June 2023, a 2400-GPU job training a 175 billion parameter GPT model lost 31.19% of its time to errors: 19.65% to diagnosis and isolation, 7.53% to work done after the last checkpoint, 3.41% to detecting the crash and 0.6% to re-initialisation.","ko":"GPU 수천 개로 도는 LLM 학습 작업이 자주 죽었고, 사용자 눈에는 원인 대부분이 \"NCCL Error\" 로만 보였다. 새로 배포한 클러스터에서 GPU 4,096개를 쓰는 대표 작업은 한 달에 40번 죽었다.\n\n그 40번을 원인별로 나누면 ECC/NVLink 오류 27.5%, ACK timeout 27.5%, NCCL timeout 20%, CUDA 오류 12.5%, 그 밖의 원인 12.5% 였다. 앞의 넷은 사용자에게 NCCL Error 로 보였고 마지막은 Network Error 로 보였다. 오류의 약 82.5% 는 특정 노드나 장치 하나에 국한되었다.\n\nGPU 하드웨어 문제로 워커 프로세스 하나가 죽으면, 그 워커에게 메시지를 보낸 이웃 워커가 응답을 받지 못해 통신 라이브러리가 오류 코드 12 를 냈다. 같은 오류 코드는 네트워크가 끊겼을 때, 메모리가 넘쳐 컨테이너가 축출되었을 때, 사용자 코드에서 텐서 크기가 맞지 않았을 때도 났다. 증상이 비슷해서 사람이 직접 원인을 찾고 결함 노드를 가려내는 데 몇 시간에서 며칠이 걸렸다.\n\n오류가 난 뒤에도 사용자는 작업이 멈춘 줄 바로 알지 못했다. PyTorch 작업은 elastic agent 가 프로세스를 죽일 때까지 최대 30분 동안 멈춰 있을 수 있었다."},"updated_at":"2026-11-14T12:34:07.171607Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0421","org_slug":"alibaba-group"}