Incident Library
  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례3건

3건 중 1~3번째

  1. 증상

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

    촉발

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

    원인
    구성 요소
    기여 요인
    감지

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

  2. 증상

    96개 노드에서 돌던 GLM-130B 사전 학습이 2022년 5월과 6월 내내 노드 고장, GPU 누락, 연결 끊김으로 여러 번 멈췄다. 2022-05-30 에는 재시작이 데이터 로딩에서 멈춰 더 나아가지 않았다.

    촉발

    학습 중에 계산 노드가 고장 나거나 연결이 끊기거나 GPU 를 잃었고, 2022-05-30 재시작 때는 Lustre 파일 시스템 오류가 났다.

    원인
    구성 요소
    기여 요인
    –
    감지

    처리량 저하는 학습 flops 가 127T 로 전보다 낮은 것을 보고 알아챘다. Lustre 파일 시스템 오류는 재시작이 데이터 로딩에서 멈춘 것을 보고 찾아냈다. n30039 는 GPU 가 없다고 스스로 보고했다.

    조치
    • 노드가 고장 날 때마다 마지막으로 저장한 step 에서 학습을 다시 시작했다.
    • 체크포인트 저장 간격을 500 step 에서 100 step 으로 줄였다. 500 step 은 너무 길었다.
    • 다른 노드 풀로 옮겨 15600 step 에서 다시 시작했다.
    • 교체해 넣은 n30076 에 알 수 없는 오류가 있다고 보고 16600 step 부터 이 노드를 뺐지만, 처리량은 달라지지 않았다.
    • 2.3T 텍스트 말뭉치를 백업 디스크에서 파일 시스템으로 다시 복사했고, 며칠이 걸렸다.
  3. 증상

    Philly 클러스터의 딥러닝 학습 작업이 에포크를 일정 수 마친 뒤 모델 체크포인트를 만들지 못하고 실패했다. 실패는 작업이 오래 돈 뒤에 났고, 실패까지 걸린 실행 시간의 중앙값이 181.67분이었다.

    촉발

    체크포인트를 만들 때 HDFS 에서 일시적인 오류가 나거나 HDFS 네임노드가 복구 중이었다.

    원인
    구성 요소
    기여 요인
    –
    감지

    실패한 작업은 스케줄러가 정해진 횟수만큼 다시 실행했고, 계속 실패하면 unsuccessful 로 표시했다. 연구진은 실패한 작업의 stdout 과 stderr 로그에서 230개가 넘는 규칙으로 실패 원인의 시그니처를 찾아 이 오류를 가려냈다.

    교훈

    논문은 HDFS 같은 클러스터 구성 요소 때문에 난 실패가 학습 과정의 훨씬 뒤에서 나타난다고 정리했다. 모델 체크포인트 오류와 MPI 런타임 실패는 드물지만 오래 실행된 뒤에 나타나 실패를 알아채기까지 걸린 시간의 큰 몫을 차지했다. 논문은 학습 작업이 남기는 오류 메시지를 실시간으로 분류하고, 실패 종류에 따라 재시도 횟수 같은 스케줄링 값을 작업마다 바꾸는 시스템이 쓸모 있다고 했다. 예를 들어 잘못된 입력 같은 실패는 재시도를 멈추고, 네트워크 타임아웃은 계속 재시도한다.

내 클러스터에도 있는지 확인하기

이 3건에서 가장 많이 나오는 구성 요소: 공유 네트워크 파일 시스템, GPU 하드웨어·메모리. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별2