사례2건

2건 중 1~2번째

1. IL-0023 InfiniBand 포트 하나가 한 번 내려갔다 복구되면서 7시간째 돌던 학습 작업이 NCCL 타임아웃으로 죽었다

   Databricks2026

   증상

   Databricks AI 의 한 학습 작업이 시작 7시간 만에 NCCL 타임아웃으로 실패했다.

   학습 작업 실패NCCL 타임아웃링크 플래핑

   촉발

   RDMA NCCL 집합 통신에 쓰던 InfiniBand 포트 하나가 한 번 내려갔고, 다시 올라오기까지 NCCL_IB_TIMEOUT 보다 오래 걸렸다.

   원인

   의존성 장애

   구성 요소

   NCCLInfiniBand 패브릭PyTorch

   기여 요인

   모니터링 사각지대기본 설정 방치

   감지

   학습 작업이 시작 7시간 만에 NCCL 타임아웃으로 죽으면서 드러났다. 연속 헬스 체크가 InfiniBand 포트 플래핑을 감시하고 있었지만, 포트가 한 번만 내려갔다 올라와서 임계값에 걸리지 않았다. 원인은 작업이 죽은 뒤 조사로 찾았다.

   조치

   • NCCL_IB_TIMEOUT 기본값을 짧은 포트 다운을 더 잘 견디도록 조정했다.
   • 워치독을 기다리지 않고, 포트 다운 신호가 오면 작업을 종료한 뒤 체크포인트에서 다시 시작하게 했다.
   • 이번 조사를 gpu-monitor 에 반영했다. gpu-monitor 의 RDMA 패브릭 포트 다운 점검은 플랩 횟수가 아니라 누적 다운 시간을 기준으로 한다.

   후속 조치

   • NCCL_IB_TIMEOUT 기본값을 더 잘 견디도록 조정했다.
   • 워치독이 터질 때까지 GPU 를 놀리지 않고, 포트 다운 신호가 오면 작업을 종료한 뒤 체크포인트에서 다시 시작하게 했다.
   • gpu-monitor 에서 RDMA 패브릭 포트 다운 감지를 플랩 횟수가 아니라 누적 다운 시간 기준으로 잡게 했다.

   교훈

   NCCL 타임아웃을 PyTorch 워치독 값으로만 생각하면 안 된다. InfiniBand 전송 계층의 NCCL_IB_TIMEOUT 은 기본값이 실제로 약 7초로, 대부분의 팀이 생각하는 것보다 훨씬 짧다. 이 값이 먼저 터지면 워치독 설정과 관계없이 작업이 죽는다. 링크 상태를 볼 때도 플랩 횟수가 아니라 누적 다운 시간을 봐야 한다. 한 번뿐인 긴 플랩도 며칠짜리 학습을 죽일 수 있다.

   사례 보기
2. 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 는 재현성을 지키려고 아주 단순한 일도 한 번에 하나씩만 바꿨다. 외부 도구를 들이거나 새 사람이 합류하면 그쪽이 내놓은 주장을 다시 확인했고, 다음 단계가 그 결과에 기댈 때는 특히 그렇게 했다. 고장은 고르게 나지 않고 소수의 문제 기계에 몰리므로, 그때그때 고장 나는 기계를 하나씩 고치기보다 믿을 수 있는 기계 묶음을 키우는 편이 낫다.

   사례 보기

원인별1