{"id":"IL-0023","org":"Databricks","date":"2026-07-01","docs":["https://pytorch.org/blog/flight-recorder-a-new-lens-for-understanding-nccl-watchdog-timeouts/"],"title":{"en":"A training run crashed with an NCCL timeout after one InfiniBand port went down once and recovered","ko":"InfiniBand 포트 하나가 한 번 내려갔다 복구되면서 7시간째 돌던 학습 작업이 NCCL 타임아웃으로 죽었다"},"domain":["ai-infra"],"impact":{"scope":"One training run, which crashed seven hours in","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"For training impact the signal that matters is cumulative port downtime, not the number of flaps: one long enough flap can crash a multi-day run. NCCL_IB_TIMEOUT, with an effective default of about seven seconds, decides the outcome long before the PyTorch watchdog timeout does. Health checks need to cover the whole node lifecycle: active checks before workloads start, passive checks for silent degradation under load, and periodic multi-node NCCL fabric checks in between.","ko":"NCCL 타임아웃을 PyTorch 워치독 값으로만 생각하면 안 된다. InfiniBand 전송 계층의 NCCL_IB_TIMEOUT 은 기본값이 실제로 약 7초로, 대부분의 팀이 생각하는 것보다 훨씬 짧다. 이 값이 먼저 터지면 워치독 설정과 관계없이 작업이 죽는다. 링크 상태를 볼 때도 플랩 횟수가 아니라 누적 다운 시간을 봐야 한다. 한 번뿐인 긴 플랩도 며칠짜리 학습을 죽일 수 있다."},"related":["IL-0025"],"sources":[{"url":"https://www.databricks.com/blog/how-we-keep-gpus-reliable-across-databricks-ai","kind":"blog","license":"unknown","archived":"http://web.archive.org/web/20261022003233/https://www.databricks.com/blog/how-we-keep-gpus-reliable-across-databricks-ai"}],"summary":{"en":"Databricks describes this incident in a post on how it keeps GPUs reliable across its AI platform. A training run failed with an NCCL timeout seven hours in, and the cause was one InfiniBand port used for RDMA NCCL collectives that had gone down once and come back.\n\nThe crash came down to which of two NCCL timeouts fires first. The PyTorch NCCL watchdog timeout, set with init_process_group(timeout=...), kills a hung collective after a configurable time, typically 10 minutes. Lower in the stack, NCCL_IB_TIMEOUT at the InfiniBand transport layer controls how long a connection waits for a downed port to recover before tearing the connection down; with retries its effective default is roughly seven seconds, much shorter than most teams realise. Once the port-down window exceeded that, the connection was gone and the collective was already dead regardless of the watchdog setting, and by the time the watchdog noticed the hang the run was bound to crash.\n\nDatabricks tuned its NCCL_IB_TIMEOUT defaults to be more resilient, and uses the same port-down signal to crash the job and restart it from a checkpoint instead of leaving GPUs idle until the watchdog fires. Its gpu-monitor service, which runs on every GPU node, thresholds RDMA fabric port-down detection on cumulative downtime rather than on the number of flaps, because one long enough flap can crash a multi-day run just as repeated flaps over hours can.","ko":"Databricks 는 GPU 신뢰성 글에서 최근 장애 하나를 소개했다. 한 학습 작업이 시작 7시간 만에 NCCL 타임아웃으로 죽었고, 조사 결과 RDMA NCCL 집합 통신에 쓰던 InfiniBand 포트 하나가 한 번 내려갔다가 복구된 것이 원인이었다.\n\n작업이 죽은 이유는 두 NCCL 타임아웃 중 어느 쪽이 먼저 터지느냐에 있었다. 흔히 이야기하는 것은 PyTorch 의 NCCL 워치독 타임아웃이다. 이 값은 init_process_group(timeout=...) 으로 정하고, 멈춘 집합 통신을 보통 10분 뒤에 죽인다. 그보다 훨씬 먼저 터지는 것이 InfiniBand 전송 계층의 NCCL_IB_TIMEOUT 이다. 이 값은 내려간 포트가 돌아오기를 얼마나 기다린 뒤 연결을 끊을지 정하는데, 재시도까지 계산하면 기본값이 실제로 약 7초다. 포트가 한 번 내려가 있는 시간이 이보다 길면 연결이 끊기고 집합 통신은 그 자리에서 죽는다. PyTorch 워치독 타임아웃을 얼마로 잡았든 상관없고, 워치독이 멈춤을 알아챌 때는 작업이 이미 죽을 수밖에 없는 상태다.\n\nDatabricks 는 학습에 영향을 주는 신호가 플랩 횟수가 아니라 누적 다운 시간이라고 정리했다. 충분히 긴 플랩 한 번이 몇 시간에 걸친 반복 플랩처럼 며칠짜리 학습을 죽일 수 있다. 그래서 Databricks 는 NCCL_IB_TIMEOUT 기본값을 더 잘 견디도록 조정했다. 또 같은 포트 다운 신호를 받으면 작업을 바로 종료하고 체크포인트에서 다시 시작하게 해, 워치독이 터질 때까지 GPU 가 놀지 않게 했다. gpu-monitor 의 연속 점검은 RDMA 포트 다운을 누적 다운 시간 기준으로 감지한다."},"trigger":{"en":"A single InfiniBand port used for RDMA NCCL collectives went down once and recovered.","ko":"RDMA NCCL 집합 통신에 쓰던 InfiniBand 포트 하나가 한 번 내려갔고, 다시 올라오기까지 NCCL_IB_TIMEOUT 보다 오래 걸렸다."},"severity":"unknown","symptoms":["training-job-failed","nccl-timeout","link-flapping"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"The training job crashed with the NCCL timeout. The continuous health checks, which watched InfiniBand port flapping by count, had not flagged the single flap.","ko":"학습 작업이 시작 7시간 만에 NCCL 타임아웃으로 죽으면서 드러났다. 연속 헬스 체크가 InfiniBand 포트 플래핑을 감시하고 있었지만, 포트가 한 번만 내려갔다 올라와서 임계값에 걸리지 않았다. 원인은 작업이 죽은 뒤 조사로 찾았다."},"components":["nccl","infiniband","pytorch"],"root_cause":"dependency-failure","remediation":[{"text":{"en":"Tuned the NCCL_IB_TIMEOUT defaults to be more resilient to short port-down windows","ko":"NCCL_IB_TIMEOUT 기본값을 짧은 포트 다운을 더 잘 견디도록 조정했다."}},{"text":{"en":"Used the port-down signal to crash the job and restart it from a checkpoint instead of waiting for the watchdog","ko":"워치독을 기다리지 않고, 포트 다운 신호가 오면 작업을 종료한 뒤 체크포인트에서 다시 시작하게 했다."}},{"text":{"en":"Fed the investigation into gpu-monitor, whose RDMA fabric port-down check is thresholded on cumulative downtime rather than flap count","ko":"이번 조사를 gpu-monitor 에 반영했다. gpu-monitor 의 RDMA 패브릭 포트 다운 점검은 플랩 횟수가 아니라 누적 다운 시간을 기준으로 한다."}}],"action_items":[{"text":{"en":"Tune the NCCL_IB_TIMEOUT defaults to be more resilient","ko":"NCCL_IB_TIMEOUT 기본값을 더 잘 견디도록 조정했다."}},{"text":{"en":"Crash and restart the job from a checkpoint on the port-down signal instead of leaving GPUs idle until the watchdog fires","ko":"워치독이 터질 때까지 GPU 를 놀리지 않고, 포트 다운 신호가 오면 작업을 종료한 뒤 체크포인트에서 다시 시작하게 했다."}},{"text":{"en":"Threshold RDMA fabric port-down detection on cumulative downtime, not flap count, in gpu-monitor","ko":"gpu-monitor 에서 RDMA 패브릭 포트 다운 감지를 플랩 횟수가 아니라 누적 다운 시간 기준으로 잡게 했다."}}],"contributing":["monitoring-blind-spot","default-config-unchanged"],"recurrence_of":null,"symptoms_text":{"en":"Seven hours into a distributed training run on Databricks AI, the job failed with an NCCL timeout.\n\nIn distributed training almost every underlying fault, whether a GPU degrading or falling off the bus, an RDMA fabric problem, an I/O hang or a CPU-side rank diverging from the others, looks the same from the job's side: every rank blocks on the same collective until the NCCL watchdog kills the job, and the logs show the NCCL watchdog timeout message. That message says almost nothing about the root cause, and the stack trace only shows the symptom.\n\nThe investigation found that a single InfiniBand port used for RDMA NCCL collectives had gone down once and recovered, and never flapped again. The continuous health checks did monitor InfiniBand port flapping, but a single isolated flap does not normally indicate an unhealthy port, so it did not trip the threshold and nothing had flagged it.","ko":"Databricks AI 의 한 학습 작업이 시작 7시간 만에 NCCL 타임아웃으로 실패했다.\n\n분산 학습 작업이 죽으면 원인이 무엇이든 로그에는 거의 항상 NCCL 워치독 타임아웃 메시지가 남는다. 모든 랭크가 같은 집합 통신에서 막히고, 워치독이 결국 작업을 죽인다. 타임아웃 메시지만으로는 근본 원인을 거의 알 수 없다. 스택 트레이스에도 증상만 보이므로, 엔지니어는 하드웨어, 패브릭, 파일 시스템, 소프트웨어 계층을 차례로 거슬러 올라가며 원인을 찾아야 한다.\n\n조사해 보니 RDMA NCCL 집합 통신에 쓰던 InfiniBand 포트 하나가 한 번 내려갔다가 복구됐다. 그 뒤로 그 포트가 다시 내려갔다 올라오는 플래핑은 없었다. 연속 헬스 체크가 InfiniBand 포트 플래핑을 감시하고 있었지만, 이 플랩만으로는 임계값에 걸리지 않았다. 플랩 한 번은 보통 포트가 고장 났다는 신호로 보지 않기 때문이다."},"updated_at":"2026-11-10T00:00:37.661207Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0023","org_slug":"databricks"}