사례2건

2건 중 1~2번째

1. IL-0426 64 GPU 학습이 3.5시간 뒤 멈췄고 30분 c10d 타임아웃이 지나도 끝나지 않았다

   Hugging Face2023

   증상

   8개 노드의 GPU 64개로 돌던 학습이 3.5시간쯤 지나 멈췄다. 메인 로그가 더는 써지지 않았고, 30분짜리 c10d 타임아웃이 지나도 작업이 중단되지 않고 계속 멈춰 있었다.

   학습 작업 실패NCCL 타임아웃

   촉발

   HPC 클러스터의 파일 시스템이 멈춰 응답하지 않게 됐다. 그때 node0 의 rank 0 프로세스가 로그를 쓰려고 부른 시스템 콜이 돌아오지 않았다.

   원인

   의존성 장애

   구성 요소

   공유 네트워크 파일 시스템PyTorch

   기여 요인

   디버그 접근 제한

   감지

   작성자가 마침 자리에 있다가 메인 로그가 더 써지지 않는 것을 보고 알아챘다. 파일 시스템이 원인이라는 것은 다음 날 시스템 관리자의 공지로 알았다.

   사례 보기
2. IL-0428 GPU 320~384개로 돌린 대형 모델 시험 학습이 멈추고 그때마다 노드가 내려갔다

   BigScience2022

   증상

   A100 GPU 320~384개로 돌린 대형 모델 시험 학습이 멈췄다. 몇몇 GPU 가 무작위로 응답하지 않았고 시스템 전체가 타임아웃이 날 때까지 멈춰 있었다. 멈출 때마다 노드 몇 대가 내려갔다.

   학습 작업 실패NCCL 타임아웃GPU 인식 불가노드 NotReady

   촉발

   100B 이상 모델을 20~40개 노드에 걸쳐 돌려 노드 사이 NCCL 트래픽이 어느 수준을 넘으면 멈춤이 시작됐다.

   원인

   unknown

   구성 요소

   NCCLPyTorch

   기여 요인

   디버그 접근 제한

   조치

   • `CUDA_LAUNCH_BLOCKING=1` 을 설정하자 멈춤이 사라졌다. 성능을 여러 번 확인해 보니 이 규모에서는 속도 저하가 거의 없었고, 팀은 이 우회책을 당분간 쓰기로 했다.

   교훈

   멈춘 프로세스가 어디서 멈췄는지 알려면 py-spy 로 모든 프로세스의 호출 스택을 뜨거나 파이썬 trace 모듈로 모든 호출을 기록할 수 있다. trace 를 켜면 속도는 느려졌지만 멈춤은 그대로 일어났다. 작성자는 trace 가 멈춘 프로세스를 디버깅하는 데 아주 쓸모 있었다고 봤다. 다만 처음부터 추적하면 데이터 로더와 준비 코드의 쓸모없는 기록까지 쌓이므로 `train_step` 바로 앞에서 추적을 시작하는 편이 나았다. 멈춘 작업을 살피는 두 번째 `srun` 에는 `--gres=gpu:0` 을 줘야 첫 `srun` 이 끝날 때까지 막히지 않는다. 먼저 `salloc` 으로 GPU 를 잡아 두면 SLURM 이 프로세스를 죽여도 그 노드에 들어갈 수 있다.

   사례 보기

원인별2