사례1건

1건 중 1~1번째

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

   Shanghai AI Laboratory2024

   증상

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

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

   원인

   하드웨어 고장

   구성 요소

   GPU 하드웨어·메모리NCCL학습 데이터 로더오브젝트 스토리지데이터센터 전력·냉각

   기여 요인

   –

   감지

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

   조치

   • 기존 LLM 프레임워크에 자동 복구가 없어 개발자가 끊긴 학습 작업을 손으로 다시 시작했다. 개발자들은 사전 학습을 제때 끝내려고 돌아가며 당직을 섰다. 작업은 마지막 체크포인트에서 다시 시작했다.
   • 123B 모델 학습에서 프레임워크를 고치고 체크포인트 저장 간격을 줄였다. 작업을 끝내기 전에 그때까지의 학습 결과를 저장하는 기능도 넣어 롤백으로 잃는 학습 진행을 줄였다.
   • 클러스터의 냉각 능력을 높여 과열로 생기던 NVLinkError 와 ECCError 를 크게 줄였다.
   • 자주 나는 NVLinkError 를 빨리 풀려고 두 단계 NCCL 테스트를 썼다. 먼저 모든 노드를 두 대씩 묶어 allgather 를 돌렸다. 그다음 실패한 묶음의 노드를 정상 노드와 다시 묶어 allgather 를 돌려 결함 노드를 찾고 격리했다.
   • 사전 학습 프레임워크가 loss spike 를 잡으면 더 앞의 정상 체크포인트에서 다시 시작하고 그 뒤의 데이터 배치를 건너뛰었다.
   • InternEvo V2 코드에서 Python 가비지 컬렉터 인터페이스로 가비지 컬렉션 시점을 직접 정했다. rank 마다 가비지 컬렉션 간격을 고정해 시점이 무작위로 몰리지 않게 했다.
   • num_worker=0 으로 설정하고 dataloader 의 가비지 컬렉션을 켜서 Dataloader Worker Killed 를 피했다.

   후속 조치

   • 장애 진단에 지금 쓰는 GPT-4 를 자체 LLM 으로 바꿀 계획이다.
   • 인프라를 업그레이드하면서 특히 NIC 를 개선하고, 더 큰 규모의 사전 학습을 위해 컴퓨팅 클러스터를 넓힌다.

   교훈

   인프라 장애가 가장 큰 피해를 냈다. 장기 사전 학습 작업에서 흔한 인프라 장애는 학습 효율을 크게 떨어뜨린다. 그래서 빠르게 진단하고 복구하는 것이 학습 효율을 높이는 데 결정적이다. 오류 없이 멈추는 작업과 사람이 손으로 재시작하는 부담을 보면, 문제가 있는 작업을 스스로 찾아 바로잡는 장애 처리 시스템이 필요하다. 실패한 작업의 로그를 규칙과 정규식으로 거르는 흔한 방법은 오류 로그가 너무 다양하고 복잡해 자주 틀렸다. 오류 문구가 없거나 여러 오류가 함께 찍히는 경우가 많아, 모든 경우를 규칙으로 맞추는 것은 현실적이지 않았다. GPU 온도가 높게 나타난 것은 클러스터 냉각 시스템을 개선해야 한다는 뜻이었다.

   사례 보기

원인별1