Incident Library

IL-0239 Shanghai AI Laboratory · 2024-04-03 (게시일)ai-infra

LLM 개발 클러스터 Acme 의 Seren 과 Kalos 에서 사전 학습 작업이 하드웨어, 네트워크, 프레임워크 오류로 자주 실패해 학습 진행을 잃었다

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 을 함께 쓰는 진단 시스템으로 오류를 뽑은 뒤 사람이 확인했다.

장애는 인프라, 프레임워크, 스크립트로 나뉘었다. 프레임워크와 스크립트 오류는 대부분 작업 초기에 나서 설정이나 코드를 고쳐 풀었다. 인프라 장애는 실패한 작업 수의 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 에 부담이 적은 것을 그 이유로 짐작했다.

기존 LLM 프레임워크에는 자동 복구가 없어 개발자가 돌아가며 당직을 서면서 끊긴 작업을 손으로 다시 시작했다. 다시 시작하면 마지막 체크포인트로 돌아갔다. 104B 모델의 초기 학습에서는 체크포인트를 불러오는 과정에서 학습 진행을 많이 잃었다. 한 달 뒤 123B 모델에서는 체크포인트 저장 간격을 줄이고 작업을 끝내기 전에 결과를 저장하는 기능을 넣어 롤백 손실이 줄었다. 팀은 이어서 내결함성 사전 학습 시스템을 만들었다. 이 시스템은 비동기 체크포인트로 저장 부담을 줄인다. 로그를 압축한 뒤 규칙과 LLM 으로 근본 원인을 진단한다. NVLinkError 같은 인프라 장애가 나면 두 단계 NCCL 테스트로 결함 노드를 찾아 격리하고, 적절한 체크포인트에서 자동으로 다시 시작한다. 진단 시스템은 사람의 개입을 약 90% 줄였다. 논문의 부록 B 는 가비지 컬렉션 때문에 처리량이 떨어진 문제와, num_worker>0 인 PyTorch dataloader 의 메모리 누수로 Dataloader Worker Killed 가 난 문제를 푼 경험을 적었다.

심각도
–
영향 범위
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
영향 사용자
LLM developers at Shanghai AI Laboratory
지역
–
감지까지
–
복구까지
–

증상

Shanghai AI Laboratory 의 LLM 개발 클러스터 Seren 과 Kalos 에서 장기 사전 학습 작업이 오류로 끝나거나, 손실이 갑자기 올라 돌아오지 않거나, 오류 없이 멈춰 섰다. 작업을 다시 시작하면 마지막 체크포인트로 돌아가 그 뒤의 학습 진행을 잃었다. 전체 작업의 약 40% 가 실패로 끝났다.

인프라 장애는 실행 로그에 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분이 걸렸다.

프레임워크와 스크립트 오류는 주로 작업 초기에 나서 작업이 금방 끝났다. 프레임워크 쪽은 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 였다.

로그만으로는 근본 원인을 가리기 어려웠다. 사전 학습 작업의 로그 파일은 대부분 학습 지표 기록이라 수백 MB 에 이르렀다. 오류 문구가 따로 없거나 여러 오류가 함께 찍히기도 했다. 예를 들어 한 작업은 NCCLTimeoutError, CUDAError, 여러 종류의 RuntimeError 를 함께 남기고 실패했지만 근본 원인은 CUDAError 였다.

Kalos 에서 7B 모델을 학습하면 GPU 가 과열되어 NVLinkError 나 ECCError 가 나곤 했다. 이 모델들을 학습할 때 서버실 전체 온도가 약 5°C 올랐다. 이런 작업의 대부분은 기록상 가장 더웠던 2023년 7월에 있었다. GPU 메모리 온도는 대체로 GPU 코어 온도보다 높았고, 부하가 큰 일부 GPU 는 65°C 를 넘었다.

지표 보고, 로깅, 모니터링, 알림을 맡는 외부 보조 서비스는 네트워크가 불안정하면 타임아웃되거나 실패해 학습을 늦추거나 끊었다. ConnectionError 와 NetworkError 의 상당수가 이 보조 서비스에서 나왔다.

어떤 작업은 인프라 문제로 오류 메시지 없이 멈춰 있었다. 이런 작업은 사용자가 직접 들여다본 뒤에야 처리되어 자원을 크게 낭비했다. 사용자가 loss spike 같은 성능 이상을 보고 매개변수를 고치려고 작업을 멈추는 일도 잦았다.

오래 도는 사전 학습 작업에서는 Dataloader Worker Killed 오류가 났다. 이 오류는 작업 시작 뒤 평균 27시간 만에 나왔다. Python 으로 짠 LLM 작업에서는 성능이 불규칙하게 떨어지기도 했다. 심하면 스텝당 평균 처리량이 2분의 1에서 3분의 1 수준으로 떨어졌다. Linux perf 로 보니 가비지 컬렉션의 list_traverse 함수가 스텝당 실행 시간의 30% 를 썼다.

증상 학습 작업 실패GPU 인식 불가NCCL 타임아웃학습 발산과 손실 급등

원인

원인 하드웨어 고장

구성 요소 GPU 하드웨어·메모리NCCL학습 데이터 로더오브젝트 스토리지데이터센터 전력·냉각
기여 요인 –
촉발
–

감지

팀은 실행 로그의 stdout 과 stderr, Prometheus 와 NVIDIA DCGM, IPMI 에서 15초 간격으로 모은 하드웨어 모니터링 데이터로 장애를 살폈다. 규칙과 LLM 을 함께 쓰는 진단 시스템이 실행 로그에서 오류를 뽑았고, 사람이 그 결과를 확인하고 바로잡았다. loss spike 는 사전 학습 프레임워크가 자동으로 잡았다. 오류 없이 멈춘 작업은 사용자가 직접 들여다보고서야 알았다.

조치

후속 조치

교훈

인프라 장애가 가장 큰 피해를 냈다. 장기 사전 학습 작업에서 흔한 인프라 장애는 학습 효율을 크게 떨어뜨린다. 그래서 빠르게 진단하고 복구하는 것이 학습 효율을 높이는 데 결정적이다. 오류 없이 멈추는 작업과 사람이 손으로 재시작하는 부담을 보면, 문제가 있는 작업을 스스로 찾아 바로잡는 장애 처리 시스템이 필요하다.

실패한 작업의 로그를 규칙과 정규식으로 거르는 흔한 방법은 오류 로그가 너무 다양하고 복잡해 자주 틀렸다. 오류 문구가 없거나 여러 오류가 함께 찍히는 경우가 많아, 모든 경우를 규칙으로 맞추는 것은 현실적이지 않았다. GPU 온도가 높게 나타난 것은 클러스터 냉각 시스템을 개선해야 한다는 뜻이었다.

출처

참고 문서

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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