{"id":"IL-0249","org":"Alibaba Group","date":"2024-10-16","docs":[],"title":{"en":"Large training jobs on a cluster of over 10,000 GPUs slowed for tens of seconds to nearly ten hours without crashing","ko":"공유 GPU 클러스터의 대규모 학습 작업이 멈추지 않은 채 느려지는 fail-slow 로 완료 시간이 평균 1.34배로 늘었다"},"domain":["ai-infra","networking"],"impact":{"scope":"Training jobs on a shared production GPU cluster: slower iterations and longer job completion time, more than 50% longer for 20% of the large jobs inspected","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Fail-slows are usually transient and come from computation, through slow GPUs or CPU contention, or from communication, mostly network congestion. Computation fail-slows are rarer and shorter and cost less, while cross-node communication fail-slows are more common, last longer and slow training more. As training grows, several performance problems are more likely to occur at once, and together they can slow training by more than 90%.","ko":"fail-slow 는 대개 일시적이다. 연산 저하는 느린 GPU 나 CPU 경합에서 오고, 통신 저하는 주로 네트워크 혼잡에서 온다. 연산 fail-slow 는 짧고 드물지만 노드 사이 통신 fail-slow 는 더 잦고 오래 이어져 학습을 더 크게 늦춘다. 학습 규모가 커지면 여러 성능 문제가 동시에 생길 가능성이 커지고, 겹친 영향으로 학습이 90% 넘게 느려질 수 있다. fail-slow 는 대개 일시적이므로 체크포인트에서 재시작하는 fail-stop 대응은 지나치다. 어떤 대응이 맞는지는 fail-slow 가 얼마나 오래, 얼마나 심하게 이어질지에 달렸지만 이는 미리 알 수 없다."},"related":[],"sources":[{"url":"https://arxiv.org/abs/2410.12588","kind":"paper","archived":"https://web.archive.org/web/20261024122401/https://arxiv.org/abs/2410.12588"}],"summary":{"en":"The production cluster studied has more than 4,000 nodes and over 10,000 GPUs, about 1,800 NVIDIA H800 and 2,600 A100, on a spine-leaf RoCE network with up to 4×200/400 Gbps for A100/H800 nodes and NVSwitch inside each node. It runs large training jobs on more than 1,000 GPUs, online and offline inference, recommendation model jobs and short spot jobs for debugging. Hybrid-parallel training synchronises at every iteration, so a single slow GPU or link slows the whole job. These failures, called fail-slows or stragglers, do not stop the job the way fail-stops such as GPU hangs and runtime crashes do. Because production workloads could not be instrumented, the authors measured fail-slows with small probe training jobs, submitted repeatedly as spot workloads that landed on random nodes next to production jobs, and by inspecting by hand a one-month trace of jobs that used at least 512 GPUs.\n\nComputation fail-slows were rare and short: 6 of 392 single-node jobs, 4 from CPU contention and 2 from GPU degradation, lasting about 10 minutes and adding 11.79% to job completion time. Communication fail-slows, mostly network congestion on a link, were common and longer: 43 of 107 four-node jobs, 42 from network congestion and 1 from CPU contention, lasting about 24 minutes and adding 15.45%. Among the 27 large jobs from July 2024, 16 slowed down, 13 from network congestion and 3 from network and GPU problems together, for 72 minutes on average and 34.59% longer job completion time; there was no CPU contention because those jobs ran alone on their nodes. Across all of them, fail-slows delayed the average job completion time by 1.34×.\n\nThe usual practice was to find fail-slows by hand and handle them like fail-stops with checkpoint-and-restart, which takes much time and work; dumping a GPT2-100B checkpoint takes nearly 100 minutes, longer than the mean fail-slow in this cluster. The authors built Falcon. Falcon-Detect hooks NCCL calls through LD_PRELOAD to infer each worker's iteration time, flags slow iterations with Bayesian online change-point detection plus a check that discards changes under 10%, profiles communication groups to find suspicious ones, and briefly pauses training to run GEMM and peer-to-peer link tests. Falcon-Mitigate escalates from doing nothing to redistributing micro-batches, then adjusting the parallel topology, and as a last resort checkpoint-and-restart. Falcon-Detect diagnosed 498 of 499 probe jobs correctly, and on a 64-GPU job with injected fail-slows Falcon reduced the slowdown by 60.1%.","ko":"Alibaba Group 과 홍콩과기대 연구자들은 노드 4,000대 이상, 이기종 GPU 10,000장 이상이 있는 공유 운영 클러스터에서 fail-slow 를 조사했다. fail-slow 는 학습이 멈추는 fail-stop 과 달리, CPU, GPU, 통신 링크가 동작은 하지만 자원 경합, thermal throttling, 전원, 네트워크 혼잡으로 성능이 떨어지는 장애다. 최신 대규모 학습은 반복이 끝날 때마다 동기화하므로 구성 요소 하나가 느려지면 학습 전체가 느려진다. 클러스터에는 NVIDIA H800 약 1,800장과 A100 2,600장이 있다. 노드는 spine-leaf 구조의 RoCE 네트워크로 연결되고, A100 과 H800 노드는 최대 4×200/400 Gbps 대역폭을 쓴다. 연구자들은 운영 작업을 직접 계측할 수 없었다. 그래서 같은 작은 학습 작업을 spot 작업으로 반복 제출해 프로브로 썼고, GPU 512장 이상을 쓰는 대규모 학습 작업의 한 달 치 기록을 손으로 살폈다.\n\n단일 노드 프로브 작업 392개 중 6개가 연산 fail-slow 를 겪었다. 4개는 CPU 경합, 2개는 GPU 성능 저하 때문이었다. 이 fail-slow 는 평균 약 10분 이어졌고 작업 완료 시간을 11.79% 늘렸다. 노드 4개짜리 프로브 작업 107개 중 43개가 fail-slow 를 겪었다. 1개는 CPU 경합, 42개는 네트워크 혼잡 때문이었다. 이 fail-slow 는 평균 약 24분 이어져 완료 시간을 15.45% 늘렸다. 2024년 7월에 제출된 GPU 512~1024장짜리 학습 작업 27개 중 16개가 fail-slow 를 겪었다. 평균 지속 시간은 72분이었고, 평균 완료 시간이 34.59% 늘었다. 이 중 20% 는 50% 넘게 늦어졌다. 13개는 네트워크 혼잡이, 나머지는 네트워크와 GPU 저하가 함께 원인이었다. 학습 노드를 단독으로 썼기 때문에 CPU 경합은 없었다.\n\n연구자들은 fail-slow 가 대개 일시적이고 연산 저하와 통신 저하에서 온다고 정리했다. 연산 저하는 느린 GPU 나 CPU 경합에서, 통신 저하는 주로 네트워크 혼잡에서 왔다. 연산 fail-slow 는 짧고 드물어 성능 저하가 작지만, 노드 사이 통신 fail-slow 는 더 잦고 오래 이어져 학습을 크게 늦췄다. 학습 규모가 커질수록 여러 성능 문제가 겹칠 가능성이 높아지고, 겹치면 학습이 90% 넘게 느려질 수 있다. 당시 현장에서는 fail-slow 를 손으로 찾아 fail-stop 처럼 체크포인트에서 재시작했다. 연구자들은 이 방식에 품과 시간이 많이 든다고 보고 Falcon 을 만들었다."},"trigger":null,"severity":"unknown","symptoms":["throughput-degraded"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"The authors found fail-slows with small probe training jobs that tracked their own performance at runtime, and by inspecting by hand a one-month trace of large training jobs.","ko":"당시 현장에서는 fail-slow 를 사람이 손으로 찾았다. 조사에서는 프로브 작업이 실행 중에 성능 지표를 모아 연산과 통신 fail-slow 를 찾았고, 대규모 학습 작업의 한 달 치 기록은 연구자들이 손으로 살폈다. Meta 와 ByteDance 도 대규모에서는 fail-slow 를 찾기 어렵다고 보고했고, 다른 회사 엔지니어들의 의견도 같았다."},"components":["infiniband","gpu-hardware"],"root_cause":"capacity","remediation":[{"text":{"en":"Found fail-slows by hand and handled them as fail-stops with checkpoint-and-restart","ko":"당시 현장에서는 fail-slow 를 손으로 찾은 뒤 fail-stop 처럼 다뤄, 체크포인트를 남기고 학습 작업을 다시 시작하는 장애 조치로 대응했다."}}],"action_items":[{"text":{"en":"Detect fail-slows at runtime from iteration times and locate the slow GPUs and links with Falcon-Detect","ko":"Falcon-Detect 를 만든다. Falcon-Detect 는 학습 프레임워크에 손대지 않고 워커마다 반복 시간을 추적한다. 시계열에서 변화 시점을 찾는 BOCD 알고리즘으로 반복이 길어진 시점을 찾고, 가벼운 프로파일링으로 의심되는 워커 그룹을 좁힌다. 그 뒤 학습을 잠깐 멈추고 벤치마크를 돌려 느린 GPU 와 링크를 찾아낸다."}},{"text":{"en":"Mitigate fail-slows with Falcon-Mitigate, escalating from cheap strategies to checkpoint-and-restart only if the slowdown persists","ko":"Falcon-Mitigate 를 만든다. Falcon-Mitigate 의 대응은 네 단계다. 아무것도 하지 않기, 데이터 병렬 그룹 사이에서 micro-batch 다시 나누기, 병렬화 토폴로지를 바꿔 혼잡한 링크를 트래픽이 적은 그룹으로 옮기기, 체크포인트에서 재시작하기다. 비용이 낮은 단계부터 시작하고, fail-slow 가 이어지는데 지금 방법이 듣지 않으면 다음 단계로 넘어간다. 체크포인트에서 재시작하기는 마지막 수단이다."}}],"contributing":["overlapping-failures","monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"On a shared production cluster of over 10,000 GPUs, large hybrid-parallel training jobs kept running but slowed down, sometimes for hours, without crashing. Among 27 jobs of 512 to 1024 GPUs each submitted in July 2024, 16 slowed this way for 72 minutes on average, and their job completion time grew by 34.59% on average.\n\nSlow computation showed as falling training throughput together with falling GPU SM utilization. In one single-node probe job, throughput dropped twice, at 22 and 55 minutes, by up to 21.6%, and SM utilization fell on all four GPUs at once; a matrix computation test run during the slowdown found no GPU degradation, and the cause was a surge of high-CPU jobs on the same node that lowered the training job's CPU satisfaction rate. In another job, all four GPUs were under-utilized for the first 10 minutes because GPU0 ran 20% slower than the others at an unusually high temperature of nearly 70°C.\n\nSlow communication was more common and lasted longer. In one four-node probe job, throughput fell from 0.57 to 0.41 iterations/s at t=90 minutes and to 0.31 iterations/s at t=265, and SM utilization dropped on all 8 GPUs at once although the GPUs were healthy; the slowdown matched a surge of congestion notification packets (CNPs) reported by the NICs. Inter-node RDMA was the least stable path, with a latency coefficient of variation of 0.29, against 0.09 for the PCIe switch and 0.02 or less for NVLink/NVSwitch and copies inside a GPU.\n\nAt scale the causes compounded. In one 1024-GPU job, network congestion at t=62 minutes cut throughput by 80%, GPU thermal throttling at about t=80 while the congestion continued brought throughput down to 10% of normal, and from t=120 another congestion lasting about two hours cut it by 85%. In the one-month trace of large jobs, 20% of the jobs were delayed by more than 50%, and across the study the slowdowns lasted from tens of seconds to nearly ten hours.","ko":"학습 작업은 멈추지 않았지만 처리량이 떨어졌고, 그 작업이 쓰는 모든 GPU 의 SM 사용률이 같은 순간에 함께 떨어졌다. 이런 fail-slow 는 수십 초에서 열 시간 가까이 이어졌다.\n\nCPU 경합 사례에서는 단일 노드 작업이 22분과 55분에 두 번 느려져 성능이 최대 21.6% 떨어졌고, GPU 네 장의 SM 사용률이 동시에 내려가 GPU 가 느려진 것처럼 보였다. 작업을 멈추고 행렬 연산으로 GPU 성능을 재 보니 떨어진 것이 없었다. 느려진 시점은 같은 노드에서 CPU 를 많이 쓰는 작업이 갑자기 늘어난 시점과 겹쳤다. 학습 작업이 필요한 CPU 를 충분히 받지 못해 CPU 시간이 늘고 처리량이 줄었다.\n\nGPU 성능 저하 사례에서는 작업이 처음 10분 동안 느려졌고 GPU 네 장 모두 사용률이 낮았다. 프로파일링하자 GPU0 이 다른 GPU 보다 20% 느렸고 온도가 70°C 가까이로 유난히 높았다. 온도가 오른다고 늘 성능 문제가 생기지는 않으므로, 이 경우는 하드웨어 문제일 수 있었다. 이런 문제의 발생률은 약 0.5% 였다.\n\n네트워크 혼잡 사례에서는 노드 4개에 걸친 작업이 90분과 265분에 느려져 처리량이 0.57 iterations/s 에서 0.41 로, 다시 0.31 iterations/s 로 떨어졌다. GPU 여덟 장은 정상이었지만 SM 사용률이 동시에 내려갔다. NIC 가 보고한 혼잡 알림 패킷 CNP 가 급증한 시점은 학습이 느려진 시점과 강한 상관을 보였다. 통신 구성 요소 중 노드 사이 RDMA 링크의 지연 변동 계수가 0.29 로 가장 컸다.\n\nGPU 1024장 규모에서는 두 종류의 저하가 겹쳤다. 한 작업은 62분에 심한 네트워크 혼잡으로 처리량이 80% 줄었고, 혼잡이 이어지던 80분 무렵 GPU thermal throttling 이 더해져 처리량이 정상의 10% 까지 떨어졌다. 120분부터는 다른 심한 혼잡이 약 두 시간 이어져 처리량이 다시 85% 줄었다."},"updated_at":"2026-11-14T12:33:49.729899Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0249","org_slug":"alibaba-group"}