Incident Library
적용된 필터 증상학습 작업 실패기여 요인디버그 접근 제한모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

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

사례2건

2건 중 1~2번째

  1. 증상

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

    촉발

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

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

    자동으로 알려 주는 수단이 없었다. 학습이 멈춰도 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. 증상

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

    촉발

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

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

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

    조치
    • 고장 난 노드를 교체했고, 나중에는 스크립트로 교체했다.
    • 메모리 오류를 찾으려고 GPU burn-in 테스트를 넣었다.
    • InfiniBand 테스트를 자동화했다.
    • train.log 를 모니터링했다.
    • 클라우드 업체의 Python API 를 디버깅해, 재시작 때 멈추던 체크포인트 다운로드 문제에 당장 쓸 만한 해결책을 찾았다.
    후속 조치
    • 가장 흔한 문제를 다루는 런북과 도구를 만들고, 다른 사람들도 온콜에 참여하게 했다.
    교훈

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

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

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

원인별2