사례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-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 고장 때 잃는 학습 시간과 저장에 드는 시간을 견주어 정해야 한다.

   사례 보기

원인별2