Incident Library
적용된 필터 원인의존성 장애증상학습 작업 실패기여 요인기본 설정 방치모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

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

사례1건

1건 중 1~1번째

  1. 증상

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

    촉발

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

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

    학습 작업이 시작 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초로, 대부분의 팀이 생각하는 것보다 훨씬 짧다. 이 값이 먼저 터지면 워치독 설정과 관계없이 작업이 죽는다. 링크 상태를 볼 때도 플랩 횟수가 아니라 누적 다운 시간을 봐야 한다. 한 번뿐인 긴 플랩도 며칠짜리 학습을 죽일 수 있다.

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

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

원인별1