{"id":"IL-0239","org":"Shanghai AI Laboratory","date":"2024-04-03","docs":["https://github.com/InternLM/AcmeTrace","https://github.com/InternLM/InternEvo"],"title":{"en":"LLM pretraining jobs on Shanghai AI Laboratory's A100 clusters kept failing midway, mostly from NVLink and GPU errors","ko":"LLM 개발 클러스터 Acme 의 Seren 과 Kalos 에서 사전 학습 작업이 하드웨어, 네트워크, 프레임워크 오류로 자주 실패해 학습 진행을 잃었다"},"domain":["ai-infra"],"impact":{"scope":"Pretraining jobs on Seren and Kalos failed or stalled and lost progress back to the last checkpoint; infrastructure failures took over 82% of the GPU time of failed jobs, and about 40% of all jobs failed","users":"LLM developers at Shanghai AI Laboratory","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Infrastructure failures are rare by count but cost the most GPU time, so diagnosing them and recovering quickly matters most for training efficiency. Matching error logs with regular-expression rules alone is often inaccurate because the logs are diverse and one failure can print several errors. Jobs that stall without an error or that are paused for loss spikes waste resources until someone looks, which calls for a failure-handling system that finds and fixes faulty jobs by itself.","ko":"인프라 장애가 가장 큰 피해를 냈다. 장기 사전 학습 작업에서 흔한 인프라 장애는 학습 효율을 크게 떨어뜨린다. 그래서 빠르게 진단하고 복구하는 것이 학습 효율을 높이는 데 결정적이다. 오류 없이 멈추는 작업과 사람이 손으로 재시작하는 부담을 보면, 문제가 있는 작업을 스스로 찾아 바로잡는 장애 처리 시스템이 필요하다.\n\n실패한 작업의 로그를 규칙과 정규식으로 거르는 흔한 방법은 오류 로그가 너무 다양하고 복잡해 자주 틀렸다. 오류 문구가 없거나 여러 오류가 함께 찍히는 경우가 많아, 모든 경우를 규칙으로 맞추는 것은 현실적이지 않았다. GPU 온도가 높게 나타난 것은 클러스터 냉각 시스템을 개선해야 한다는 뜻이었다."},"related":[],"sources":[{"url":"https://arxiv.org/abs/2403.07648","kind":"paper","archived":"https://web.archive.org/web/20260807112554/https://arxiv.org/abs/2403.07648"}],"summary":{"en":"Acme's Seren (2,288 GPUs, scheduler built on Slurm) and Kalos (2,416 GPUs, scheduler built on Kubernetes) clusters have nodes with 8 NVIDIA A100-SXM 80GB GPUs linked by NVLink and NVSwitch and 200Gbps HDR InfiniBand between nodes, and they are used to develop LLMs from 7B to over 123B parameters with the InternEvo framework. The paper classifies job failures from runtime logs into infrastructure, framework and script failures. Script and framework errors are the most numerous but happen early and are fixed by changing code or configuration; infrastructure failures happen midway through long pretraining jobs, can hit one job several times, and need careful diagnosis that often ends in maintaining or replacing hardware, which makes restarts expensive. About 40% of all jobs fail, and jobs that complete use only 20-30% of GPU resources. Evaluation jobs rarely fail: only 6.7% of evaluation tasks in Kalos hit an error and none hit a GPU or NVLink failure. After the overheating seen in July 2023 the team improved the cluster's cooling, and such failures became much less frequent.\n\nAt first developers took turns on call and restarted failed pretraining jobs by hand, each restart going back to the last checkpoint; for the 104B model, reloading checkpoints cost much training progress, and for the 123B model a month later the team saved checkpoints more often and let jobs terminate gracefully, saving their state before they stopped. The team then built a fault-tolerant pretraining system: asynchronous checkpointing that copies model state to host memory and persists it from a separate thread, cutting checkpoint overhead by 3.6-58.7 times; failure diagnosis that compresses logs with regular-expression filter rules written by an LLM agent and then finds the root cause with predefined rules or, failing those, with GPT-4 over a vector store of logs; and recovery that, for NVLink errors, runs a two-round NCCL allgather test on pairs of nodes to find and cordon faulty nodes, and, for a loss spike, restarts from an earlier healthy checkpoint and skips the following data batches. The failure diagnosis system reduced manual intervention by around 90%. For the framework problems, the team fixed garbage collection to set intervals on each rank and avoided the dataloader leak by setting num_worker=0 and enabling garbage collection in the dataloader.","ko":"Shanghai AI Laboratory 는 자기 GPU 데이터센터 Acme 의 LLM 개발 클러스터 Seren 과 Kalos 에서 2023년 3월부터 8월까지 여섯 달 동안 모은 작업 기록을 분석했다. 두 클러스터는 GPU 를 각각 2,288장, 2,416장 갖췄다. 노드 안에서는 NVIDIA A100-SXM 80GB 여덟 장이 NVLink 와 NVSwitch 로 이어졌고, 노드 사이는 200Gbps HDR InfiniBand 로 이어졌다. 스케줄러는 Seren 에서는 Slurm 위에, Kalos 에서는 Kubernetes 위에 있었다. 장애 분석에는 Kalos 의 작업 32,500개와 Seren 의 사전 학습 작업 675개의 로그를 썼다. 규칙과 LLM 을 함께 쓰는 진단 시스템으로 오류를 뽑은 뒤 사람이 확인했다.\n\n장애는 인프라, 프레임워크, 스크립트로 나뉘었다. 프레임워크와 스크립트 오류는 대부분 작업 초기에 나서 설정이나 코드를 고쳐 풀었다. 인프라 장애는 실패한 작업 수의 11% 에 불과했지만 GPU 시간의 82% 넘게 차지했다. 이런 작업은 대개 GPU 를 많이 쓰는 장기 사전 학습이었고, 같은 작업이 하드웨어 장애를 여러 번 겪었다. 대표적인 것은 GPU 의 CUDAError 와 ECCError, NVLinkError, 그리고 NCCLRemoteError 와 S3StorageError 같은 네트워크 문제였다. 원인을 찾으려면 꼼꼼한 진단이 필요했다. 결함 있는 하드웨어를 고치거나 바꾸는 일도 잦아 재시작 비용이 컸다. Kalos 에서 7B 모델을 학습하면 통신 최적화로 GPU 가 거의 쉬지 않아 과열되었다. 서버실 온도가 약 5°C 올랐고, NVLinkError 나 ECCError 가 났다. 이런 작업의 대부분은 2023년 7월에 있었다. 팀이 냉각 능력을 높이자 이런 장애가 크게 줄었다. 지표 보고와 로깅 같은 보조 서비스의 네트워크가 불안정해 ConnectionError 와 NetworkError 도 많이 났다. Kalos 의 평가 작업은 6.7% 만 오류를 냈고 GPU 나 NVLink 장애는 한 건도 없었다. 논문은 평가 작업이 짧아 GPU 와 NVLink 에 부담이 적은 것을 그 이유로 짐작했다.\n\n기존 LLM 프레임워크에는 자동 복구가 없어 개발자가 돌아가며 당직을 서면서 끊긴 작업을 손으로 다시 시작했다. 다시 시작하면 마지막 체크포인트로 돌아갔다. 104B 모델의 초기 학습에서는 체크포인트를 불러오는 과정에서 학습 진행을 많이 잃었다. 한 달 뒤 123B 모델에서는 체크포인트 저장 간격을 줄이고 작업을 끝내기 전에 결과를 저장하는 기능을 넣어 롤백 손실이 줄었다. 팀은 이어서 내결함성 사전 학습 시스템을 만들었다. 이 시스템은 비동기 체크포인트로 저장 부담을 줄인다. 로그를 압축한 뒤 규칙과 LLM 으로 근본 원인을 진단한다. NVLinkError 같은 인프라 장애가 나면 두 단계 NCCL 테스트로 결함 노드를 찾아 격리하고, 적절한 체크포인트에서 자동으로 다시 시작한다. 진단 시스템은 사람의 개입을 약 90% 줄였다. 논문의 부록 B 는 가비지 컬렉션 때문에 처리량이 떨어진 문제와, num_worker>0 인 PyTorch dataloader 의 메모리 누수로 Dataloader Worker Killed 가 난 문제를 푼 경험을 적었다."},"trigger":null,"severity":"unknown","symptoms":["training-job-failed","gpu-unavailable","nccl-timeout","training-divergence"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Failures were found in the framework's runtime logs, later by a diagnosis system that combines rules with an LLM; the pretraining framework detects loss spikes automatically. Jobs that stalled without an error were noticed only when users inspected them by hand.","ko":"팀은 실행 로그의 stdout 과 stderr, Prometheus 와 NVIDIA DCGM, IPMI 에서 15초 간격으로 모은 하드웨어 모니터링 데이터로 장애를 살폈다. 규칙과 LLM 을 함께 쓰는 진단 시스템이 실행 로그에서 오류를 뽑았고, 사람이 그 결과를 확인하고 바로잡았다. loss spike 는 사전 학습 프레임워크가 자동으로 잡았다. 오류 없이 멈춘 작업은 사용자가 직접 들여다보고서야 알았다."},"components":["gpu-hardware","nccl","training-dataloader","object-storage","datacenter-facility"],"root_cause":"hardware-failure","remediation":[{"text":{"en":"Restarted interrupted pretraining jobs by hand from the last checkpoint, with developers on call in turn","ko":"기존 LLM 프레임워크에 자동 복구가 없어 개발자가 끊긴 학습 작업을 손으로 다시 시작했다. 개발자들은 사전 학습을 제때 끝내려고 돌아가며 당직을 섰다. 작업은 마지막 체크포인트에서 다시 시작했다."}},{"text":{"en":"Saved checkpoints at shorter intervals and let jobs terminate gracefully to keep their current state","ko":"123B 모델 학습에서 프레임워크를 고치고 체크포인트 저장 간격을 줄였다. 작업을 끝내기 전에 그때까지의 학습 결과를 저장하는 기능도 넣어 롤백으로 잃는 학습 진행을 줄였다."}},{"text":{"en":"Improved the cluster's cooling after GPU overheating caused NVLink and ECC errors","ko":"클러스터의 냉각 능력을 높여 과열로 생기던 NVLinkError 와 ECCError 를 크게 줄였다."}},{"text":{"en":"Found faulty nodes with a two-round NCCL allgather test and cordoned them off","ko":"자주 나는 NVLinkError 를 빨리 풀려고 두 단계 NCCL 테스트를 썼다. 먼저 모든 노드를 두 대씩 묶어 allgather 를 돌렸다. 그다음 실패한 묶음의 노드를 정상 노드와 다시 묶어 allgather 를 돌려 결함 노드를 찾고 격리했다."}},{"text":{"en":"Restarted from an earlier healthy checkpoint and skipped the following data batches after a loss spike","ko":"사전 학습 프레임워크가 loss spike 를 잡으면 더 앞의 정상 체크포인트에서 다시 시작하고 그 뒤의 데이터 배치를 건너뛰었다."}},{"text":{"en":"Fixed the garbage collection interval on each rank in InternEvo V2","ko":"InternEvo V2 코드에서 Python 가비지 컬렉터 인터페이스로 가비지 컬렉션 시점을 직접 정했다. rank 마다 가비지 컬렉션 간격을 고정해 시점이 무작위로 몰리지 않게 했다."}},{"text":{"en":"Set num_worker=0 and enabled garbage collection in the dataloader to stop the memory leak","ko":"num_worker=0 으로 설정하고 dataloader 의 가비지 컬렉션을 켜서 Dataloader Worker Killed 를 피했다."}}],"action_items":[{"text":{"en":"Move failure diagnosis from GPT-4 to Shanghai AI Laboratory's own LLMs","ko":"장애 진단에 지금 쓰는 GPT-4 를 자체 LLM 으로 바꿀 계획이다."}},{"text":{"en":"Upgrade the infrastructure, with a particular focus on the NICs, and expand the computing cluster for larger-scale pretraining","ko":"인프라를 업그레이드하면서 특히 NIC 를 개선하고, 더 큰 규모의 사전 학습을 위해 컴퓨팅 클러스터를 넓힌다."}}],"contributing":[],"recurrence_of":null,"symptoms_text":{"en":"Over six months from March to August 2023, LLM pretraining jobs on the Seren and Kalos clusters of Shanghai AI Laboratory's Acme datacenter, 4,704 A100 GPUs in total, failed again and again partway through and had to be restarted from the last checkpoint. Jobs that failed on infrastructure problems were only 11% of failed jobs by count but used over 82% of the GPU time of failed jobs.\n\nThe failures showed in the runtime logs (stdout and stderr) of the LLM framework. Among infrastructure failures, NVLink Error occurred 54 times, with an average GPU demand of 800, an average time to failure of 868.1 minutes and 30.25% of failed GPU time, and took 95.6 minutes on average to restart; CUDA Error 21 times (15.77%); Node Failure, meaning errors from unclear hardware problems, 16 times (14.30%); ECC Error 12 times (11.00%); Network Error 12 times (4.53%) with an average restart time of 592.1 minutes; Connection Error 147 times (3.44%); S3 Storage Error 10 times (2.12%); NCCL Timeout Error 6 times (0.50%); and NCCL Remote Error 3 times (0.15%). Logs of pretraining jobs reach hundreds of MBs, and one failure can print several errors at once: a job could fail with NCCLTimeoutError, CUDAError and several kinds of RuntimeError when the root cause was the CUDAError.\n\nJobs also had to be restarted for loss spikes, a sudden rise in a training loss that had been falling and that does not recover for some time, and for training that got stuck: some jobs stalled on infrastructure problems without printing any error and were found only when users inspected them by hand. Training 7B models in Kalos tended to overheat GPUs and cause NVLinkError or ECCError; the server room temperature rose by about 5°C during these runs, most of which took place in July 2023, the hottest month on record. Many ConnectionError and NetworkError failures came from auxiliary services for metric reporting, logging, monitoring and alerting that the framework connects to.\n\nTwo framework problems also had to be troubleshot. In LLM jobs written in Python, irregular slowdowns cut the average throughput per step by 2-3 times in severe cases, and Linux perf showed the garbage collection function list_traverse taking 30% of each step. A Dataloader Worker Killed error appeared on average 27 hours after a task started, from a gradual memory leak in PyTorch's dataloader with num_worker>0.","ko":"Shanghai AI Laboratory 의 LLM 개발 클러스터 Seren 과 Kalos 에서 장기 사전 학습 작업이 오류로 끝나거나, 손실이 갑자기 올라 돌아오지 않거나, 오류 없이 멈춰 섰다. 작업을 다시 시작하면 마지막 체크포인트로 돌아가 그 뒤의 학습 진행을 잃었다. 전체 작업의 약 40% 가 실패로 끝났다.\n\n인프라 장애는 실행 로그에 NVLink Error, CUDA Error, Node Failure, ECC Error, Network Error, Connection Error, S3 Storage Error, NCCL Timeout Error, NCCL Remote Error 로 나타났다. NVLink Error 는 54건이었다. 이 오류는 작업당 평균 GPU 800개를 쓰는 작업에서 났고, 실패한 작업의 GPU 시간 중 30.25% 를 차지했다. CUDA Error 는 21건에 15.77%, Node Failure 는 16건에 14.30%, ECC Error 는 12건에 11.00% 였다. Node Failure 는 원인이 분명하지 않은 하드웨어 문제로 생겨 따로 분류하지 못한 오류였다. 인프라 장애는 실패한 작업 수의 11% 였지만 실패한 작업의 GPU 시간에서는 82% 넘게 차지했고, 다시 시작하는 데 걸린 시간도 길었다. Network Error 는 다시 시작하기까지 평균 592.1분이 걸렸다.\n\n프레임워크와 스크립트 오류는 주로 작업 초기에 나서 작업이 금방 끝났다. 프레임워크 쪽은 Dataloader Killed, Attribute Error, Out of Memory Error, Runtime Error, Assertion Error, Value Error, Zero Division Error, Model Loading Error, Dataset Loading Error 였다. 스크립트 쪽은 File Not Found Error 568건, Type Error 620건, OS Error 266건, Key Error 260건, Import Error, Index Error, Name Error, Syntax Error, Permission Error, Argument Error, Called Process Error 였다.\n\n로그만으로는 근본 원인을 가리기 어려웠다. 사전 학습 작업의 로그 파일은 대부분 학습 지표 기록이라 수백 MB 에 이르렀다. 오류 문구가 따로 없거나 여러 오류가 함께 찍히기도 했다. 예를 들어 한 작업은 NCCLTimeoutError, CUDAError, 여러 종류의 RuntimeError 를 함께 남기고 실패했지만 근본 원인은 CUDAError 였다.\n\nKalos 에서 7B 모델을 학습하면 GPU 가 과열되어 NVLinkError 나 ECCError 가 나곤 했다. 이 모델들을 학습할 때 서버실 전체 온도가 약 5°C 올랐다. 이런 작업의 대부분은 기록상 가장 더웠던 2023년 7월에 있었다. GPU 메모리 온도는 대체로 GPU 코어 온도보다 높았고, 부하가 큰 일부 GPU 는 65°C 를 넘었다.\n\n지표 보고, 로깅, 모니터링, 알림을 맡는 외부 보조 서비스는 네트워크가 불안정하면 타임아웃되거나 실패해 학습을 늦추거나 끊었다. ConnectionError 와 NetworkError 의 상당수가 이 보조 서비스에서 나왔다.\n\n어떤 작업은 인프라 문제로 오류 메시지 없이 멈춰 있었다. 이런 작업은 사용자가 직접 들여다본 뒤에야 처리되어 자원을 크게 낭비했다. 사용자가 loss spike 같은 성능 이상을 보고 매개변수를 고치려고 작업을 멈추는 일도 잦았다.\n\n오래 도는 사전 학습 작업에서는 Dataloader Worker Killed 오류가 났다. 이 오류는 작업 시작 뒤 평균 27시간 만에 나왔다. Python 으로 짠 LLM 작업에서는 성능이 불규칙하게 떨어지기도 했다. 심하면 스텝당 평균 처리량이 2분의 1에서 3분의 1 수준으로 떨어졌다. Linux perf 로 보니 가비지 컬렉션의 list_traverse 함수가 스텝당 실행 시간의 30% 를 썼다."},"updated_at":"2026-11-14T05:53:45.819714Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0239","org_slug":"shanghai-ai-laboratory"}