사례10건

10건 중 6~10번째

1. IL-0025 H100 4,088개 클러스터를 구축하는 동안 InfiniBand 배선 오류, 링크 플래핑, GPU 와 PCIe 하드웨어 결함이 학습을 멈추거나 늦췄다

   Imbue2024

   증상

   Imbue 는 H100 GPU 4,088개를 서버 511대에 나눠 담은 클러스터를 베어 메탈부터 구축하고 그 위에서 70B 모델을 학습했다. 처음 마주친 것은 장비 자체였다. 서버의 약 10% 가 주로 물리적 문제로 부팅되지 않았고, InfiniBand 네트워크를 관리하는 Unified Fabric Manager, 줄여서 UFM 은 처음에 스위치 320대를 하나도 찾지 못했다.

   링크 플래핑NCCL 타임아웃처리량 저하GPU 인식 불가학습 작업 실패

   촉발

   새로 들인 H100 4,088개 클러스터를 베어 메탈 상태에서 처음 구축하면서, 잘못 설계된 InfiniBand 배선과 불량 하드웨어, 펌웨어, 드라이버 문제가 차례로 드러났다.

   원인

   의존성 장애

   구성 요소

   InfiniBand 패브릭NCCLGPU 드라이버PyTorch

   기여 요인

   미검증 가정모니터링 사각지대부분 배포

   감지

   UFM 경고, 호스트 헬스 체크, DCGM 과 Prometheus 지표, 학습 중 MFU 와 NCCL 워치독 오류로 문제를 알아챘다. InfiniBand 포트 문제는 포트를 실제로 쓸 때만 드러나서, 모든 포트에 부하를 거는 번인 작업을 만들어 더 효율적으로 찾았다. 멈춤을 일으킨 호스트는 특정 로그를 남기지 않은 호스트를 찾는 방식으로 가려냈다. 팀은 배치마다 순간 MFU 를 살펴보고, MFU 가 떨어지는 곡선 모양으로 문제 종류를 구분했다.

   조치

   • 고장 난 기계를 찾는 점검을 자동화하고, 일부 기계는 Dell 에 돌려보내 다시 시험받게 했으며 데이터센터 직원에게 티켓을 올렸다.
   • GPU 와 내부 PCIe 케이블을 다시 장착했고 펌웨어 업그레이드를 적용했다.
   • 온도 값을 틀리게 만든 NVIDIA 드라이버를 이전 버전으로 내렸다.
   • InfiniBand 패브릭의 최상위 계층을 하나의 네트워크로 다시 배선하고, 배선이 설계와 맞는지 확인하는 점검을 추가했다.
   • 경고를 내는 포트를 청소하고 다시 꽂았고, 그래도 경고가 남은 트랜시버는 껐다.
   • 모든 InfiniBand 포트에 번인 작업을 돌려, 버티지 못한 포트를 껐다.
   • 커널 모듈을 추가하고 PCIe ACS 를 꺼서 GPUDirect RDMA 를 켰다.
   • 자동 가비지 컬렉션을 끄고 모든 호스트에서 정해진 간격으로 가비지 컬렉션을 돌렸다.

   후속 조치

   • 호스트가 학습에 쓸 만한지 예 또는 아니오로 답하는 헬스 체크를 만들었다. GPU, 디스크 공간, Docker, dmesg, iDRAC, 디스크, InfiniBand, NVLink, GDR, VBIOS, Flint, PSB 점검이 들어 있고, iDRAC 과 PSB 점검을 뺀 나머지를 공개했다.
   • 오류와 멈춤 주변의 로깅을 늘린 NCCL 패치를 공개했다.
   • GPU 스트레스 테스트와 NVLink, InfiniBand 네트워크 테스트를 공개했다.
   • UFM 이벤트 로그를 파싱해 어떤 네트워크 포트를 꺼야 할지 정하는 스크립트를 공개했다.
   • 모든 InfiniBand 링크를 쓰게 하는 번인 작업을 만드는 스크립트를 공개했다.
   • 학습이 죽으면 헬스 체크를 통과한 기계로 마지막 체크포인트부터 자동으로 다시 시작하게 했다.
   • 경고가 나서 꺼 둔 트랜시버를 교체품이 오면 바꾼다.

   교훈

   대형 GPU 클러스터에서는 연결 하나만 조금 불안해도 전체 학습이 느려질 수 있다. Imbue 는 학습에 필요한 것보다 10-20% 많은 기계를 두면 고장 난 기계를 쉽게 바꿔 다시 시작할 수 있다고 정리했다. 학습 중 겪는 문제는 모두 다시 일어나므로, 겪은 하드웨어와 소프트웨어 장애마다 테스트와 자동 처리를 만들 가치가 있다. 알아보기 어려운 오류 메시지마다 그 오류를 읽기 쉽게 만드는 도구를 만드는 것도 마찬가지다. Imbue 는 재현성을 지키려고 아주 단순한 일도 한 번에 하나씩만 바꿨다. 외부 도구를 들이거나 새 사람이 합류하면 그쪽이 내놓은 주장을 다시 확인했고, 다음 단계가 그 결과에 기댈 때는 특히 그렇게 했다. 고장은 고르게 나지 않고 소수의 문제 기계에 몰리므로, 그때그때 고장 나는 기계를 하나씩 고치기보다 믿을 수 있는 기계 묶음을 키우는 편이 낫다.

   사례 보기
2. IL-0021 GKE 의 COS 노드가 NVIDIA GPU 드라이버를 403 Forbidden 으로 받지 못해 새로 만든 GPU 노드를 쓸 수 없었다

   Google Cloud2024

   증상

   2024-03-12 US/Pacific 08:00 부터 GKE 에서 Container-Optimized OS 를 쓰는 GPU 노드가 일부 NVIDIA GPU 드라이버를 받지 못했다. 새로 만들거나 다시 만든 노드는 GPU 드라이버가 작동하지 않았고, 그 드라이버를 쓰는 워크로드가 돌지 못했다.

   GPU 인식 불가노드 NotReady

   원인

   의존성 장애

   구성 요소

   GPU 드라이버노드 운영체제 이미지노드 풀

   기여 요인

   자동화 증폭

   감지

   보고서는 Google 이 장애를 어떻게 알아챘는지 적지 않았다. GKE 사용자는 GPU 노드에서 드라이버를 설치할 때 "Failed to download GPU driver installer, status: 403 Forbidden" 오류를 보고 이 장애를 알아볼 수 있었다.

   조치

   • GPU 드라이버 다운로드를 시도하는 자동 노드 재생성을 멈췄다.
   • 드라이버를 공급하는 파트너와 함께 스토리지 버킷 접근 문제를 해결했다.

   교훈

   상태 페이지 보고서는 교훈이나 후속 조치를 적지 않았다.

   사례 보기
3. IL-0135 UPS 를 바이패스 모드로 둔 정기 점검 중 전원이 예비 전원으로 넘어가면서 데이터센터 한 열이 정전됐고, 그 열의 GPU VM 이 모두 꺼졌다.

   Crusoe Cloud2023

   증상

   2023년 11월 15일 20:31 UTC 에 us-northcentral1 리전 데이터센터의 한 열에서 정전이 나 그 리전 VM 의 일부가 꺼졌다. 상태 페이지는 us-northcentral1-a 의 일부 VM 을 쓸 수 없다고 알렸다.

   GPU 인식 불가서비스 중단

   촉발

   UPS 를 바이패스 모드로 두고 정기 점검을 하던 중, 점검과 관계없는 이유로 전원이 주 전원에서 예비 전원으로 넘어갔다.

   원인

   의존성 장애

   구성 요소

   데이터센터 전력·냉각

   기여 요인

   단일 장애점장애 중첩

   감지

   정전은 20:31 UTC 에 났고, 21:07 UTC 에 상태 페이지가 us-northcentral1-a 의 일부 VM 을 쓸 수 없다고 처음 알렸다. 21:31 UTC 에는 영향받은 VM 을 찾아냈다고 올렸다.

   조치

   • 팀이 정전으로 영향받은 VM 을 찾아냈다.
   • 전원이 돌아온 뒤 영향받은 VM 을 차례로 재시작했고, 마지막 VM 은 11월 16일 00:20 UTC 에 다시 켜졌다.

   후속 조치

   • 앞으로 점검할 때 고객에게 영향이 갈 가능성을 최소로 줄이도록 UPS 점검 표준 운영 절차를 검토한다.
   • 앞으로 짓는 데이터센터에는 UPS 를 이중으로 둔다.
   • 장애가 났을 때 평균 해결 시간인 MTTR 을 더 줄이도록 복구 절차를 계속 개선한다.

   교훈

   UPS 를 바이패스 모드로 둔 점검 시간에는 그 열에 전원 전환을 받아 줄 장치가 없다. 하나뿐인 UPS 가 점검 중일 때 다른 이유로 전원이 바뀌자 열 전체가 꺼졌고, 그래서 Crusoe 는 새 데이터센터에 이중 UPS 를 두기로 했다.

   사례 보기
4. IL-0125 Jean Zay 에서 진행한 176B 다국어 모델 학습에서 GPU 가 고장 나도 학습 작업이 끝나지 않고 멈춰 버려 SLURM 이 작업을 자동으로 재시작하지 못했다.

   BigScience2022

   증상

   tr11-176B-ml 학습에서는 대략 일주일에 한 번 GPU 하나가 죽는 하드웨어 문제가 생겼다. 대부분은 SLURM 작업이 자동으로 재시작돼 잃는 학습이 최대 3시간에 그쳤다. 하지만 가끔은 프로세스가 죽었는데도 학습이 멈춘 채 끝나지 않았다.

   학습 작업 실패GPU 인식 불가

   촉발

   Jean Zay 노드의 GPU 하나가 하드웨어 고장으로 죽었는데, 프로세스가 죽은 뒤에도 학습 작업이 종료되지 않고 멈췄다.

   원인

   하드웨어 고장

   구성 요소

   NCCLPyTorchSlurm 작업 스케줄러

   기여 요인

   기본 설정 방치디버그 접근 제한

   감지

   자동으로 알려 주는 수단이 없었다. 학습이 멈춰도 SLURM 작업이 끝나지 않았기 때문에, 누군가 학습을 지켜보다가 알아채야 했다.

   조치

   • 체크포인트 저장 간격을 200 이터레이션으로, 이어서 100 이터레이션으로 줄였다. 설정 값은 SAVE_INTERVAL=100 이다.
   • NCCL_ASYNC_ERROR_HANDLING=1 을 설정해 브로드캐스트 멈춤 같은 NCCL 문제가 생기면 학습이 강제로 죽게 했다.
   • 노드 2개에서 새 작업을 띄우고 프로세스 하나를 손으로 죽여 약 5분 뒤 SLURM 이 작업 전체를 끝내는 것을 확인한 뒤, srun 에 --wait=60 과 --kill-on-bad-exit=1 을 더했다.

   교훈

   Jean Zay 의 SLURM 에는 이미 KillOnBadExit=1 같은 설정이 있었으므로, 실제로 더해진 것은 NCCL_ASYNC_ERROR_HANDLING=1 하나였다. 노드 2개 시험은 새 srun 옵션만 확인했고, 재현하기 까다로운 NCCL 멈춤은 시험하지 못했다. 작성자는 다음 하드웨어 고장 때 제대로 동작하는지 지켜보기로 했다. 체크포인트 저장 간격은 GPU 고장 때 잃는 학습 시간과 저장에 드는 시간을 견주어 정해야 한다.

   사례 보기
5. IL-0126 OPT-175B 학습이 클라우드 노드의 ECC 메모리 오류, 같은 결함을 안고 돌아온 교체 노드, 멈추는 체크포인트 다운로드 때문에 2주 동안 40번 넘게 재시작했다.

   Meta AI2021

   증상

   2021년 11월 17일 업데이트 이후 2주 동안 175B 실험은 하드웨어, 인프라, 학습 안정성 문제로 40번 넘게 재시작했다. 재시작의 대부분은 하드웨어 결함 때문이었고, 노드가 ECC 오류로 내려가면 실험이 멈췄다. 이런 하드웨어 문제 때문에 실험은 하루 중 아무 때나 몇 시간씩 멈췄다.

   학습 작업 실패GPU 인식 불가

   촉발

   노드가 ECC 메모리 오류로 내려가는 하드웨어 결함이 되풀이됐다.

   원인

   의존성 장애

   구성 요소

   GPU 하드웨어·메모리NCCLInfiniBand 패브릭오브젝트 스토리지

   기여 요인

   여유 용량 부재디버그 접근 제한런북 부재

   감지

   이 2주 동안 팀은 train.log 모니터링, 메모리 오류를 찾는 GPU burn-in 테스트, InfiniBand 자동 테스트를 넣었다.

   조치

   • 고장 난 노드를 교체했고, 나중에는 스크립트로 교체했다.
   • 메모리 오류를 찾으려고 GPU burn-in 테스트를 넣었다.
   • InfiniBand 테스트를 자동화했다.
   • train.log 를 모니터링했다.
   • 클라우드 업체의 Python API 를 디버깅해, 재시작 때 멈추던 체크포인트 다운로드 문제에 당장 쓸 만한 해결책을 찾았다.

   후속 조치

   • 가장 흔한 문제를 다루는 런북과 도구를 만들고, 다른 사람들도 온콜에 참여하게 했다.

   교훈

   이 규모로 학습할 때는 하드웨어 장애 대응을 자동화해야 한다. 밑단 하드웨어를 직접 통제할 수 없는 클라우드에서는 인프라 불안정에 늘 대비해야 한다.

   사례 보기

원인별5