사례2건

2건 중 1~2번째

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 온도가 높게 나타난 것은 클러스터 냉각 시스템을 개선해야 한다는 뜻이었다.

   사례 보기
2. IL-0525 Equinix 암스테르담 전원 점검 중 업링크가 하나뿐인 스위치가 꺼져 OpenStreetMap.org 가 7시간 27분 멈춤

   OpenStreetMap Foundation2022

   증상

   2022년 6월 11일 20:18 UTC 부터 OpenStreetMap.org 에 접속할 수 없었다. Equinix 가 암스테르담 데이터센터 AM6 의 전원 A 계통 점검을 시작하고 18분 뒤였고, 암스테르담에 있는 www, API, wiki, planet 서비스가 모두 인터넷과 끊겼다.

   네트워크 도달 불가서비스 중단

   촉발

   2022년 6월 11일 20:00 UTC 에 Equinix 가 암스테르담의 OpenStreetMap 서버에 전원을 대는 전원 A 계통의 5년 주기 점검을 시작했다.

   원인

   하드웨어 고장

   구성 요소

   네트워크 스위치데이터센터 전력·냉각

   기여 요인

   단일 장애점디버그 접근 제한모니터링 사각지대

   조치

   • 운영 팀은 더블린으로 페일오버하거나 업링크를 Switch-2 로 옮기지 않고 Equinix 전원 점검 시간이 끝날 때까지 기다렸다. 장애는 6월 12일 03:45 UTC 에 끝났다.

   후속 조치

   • 진행 중인 장애를 알리는 데 걸리는 시간을 줄인다. 장애 알림은 https://twitter.com/OSM_Tech 로 낸다.
   • 스위치의 PSU 와 팬 상태를 모니터링하고 알림을 건다.
   • Cisco SG550X-48 스위치 Switch-1, Switch-2 와 Cisco Redundant Power System 을 이중 전원을 갖춘 Juniper EX4300 스위치로 바꾼다. 부품 공급 부족으로 설치가 늦어졌고, 2022년 7월 19일 기준 모든 부품이 현장에 도착해 설치를 기다린다.
   • 이중 전원을 받는 대역 외 접속 장비인 4G 모뎀 시리얼 콘솔 서버를 암스테르담에 둔다. 2022년 6월 20~22일 현장 방문 때 설치를 마쳤다.
   • 이중 업링크를 설치한다. 2022년 7월 19일 기준 아직 설치되지 않아 운영 팀이 계속 챙기고 있다.
   • 지금은 실수하기 쉬운 수동 절차인 사이트 페일오버를 더 쉽고, 손이 덜 가고, 덜 위험하게 만든다.
   • 운영 SRE 를 위한 당번 호출 시스템을 들인다. 2022년 7월 19일 기준 업체와 협상 중이다.
   • 한 사람이 24시간 내내 당번을 설 수 없으므로 장기적으로 SRE 팀을 늘린다.
   • 전원, 네트워크, 상위 링크, 서비스 장애에 대비한 장비 페일오버 시험을 계속하고 정식 절차로 만든다.

   사례 보기

원인별1