Cases1 case

1 to 1 of 1

1. IL-0023 A training run crashed with an NCCL timeout after one InfiniBand port went down once and recovered

   Databricks2026

   Symptoms

   Seven hours into a distributed training run on Databricks AI, the job failed with an NCCL timeout.

   Training job failureNCCL timeoutLink flapping

   Trigger

   A single InfiniBand port used for RDMA NCCL collectives went down once and recovered.

   Root cause

   Dependency failure

   Component

   NCCLInfiniBand fabricPyTorch

   Contributing factor

   Monitoring blind spotUnreviewed defaults

   Detection

   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.

   Remediation

   • Tuned the NCCL_IB_TIMEOUT defaults to be more resilient to short port-down windows
   • Used the port-down signal to crash the job and restart it from a checkpoint instead of waiting for the watchdog
   • Fed the investigation into gpu-monitor, whose RDMA fabric port-down check is thresholded on cumulative downtime rather than flap count

   Action items

   • Tune the NCCL_IB_TIMEOUT defaults to be more resilient
   • Crash and restart the job from a checkpoint on the port-down signal instead of leaving GPUs idle until the watchdog fires
   • Threshold RDMA fabric port-down detection on cumulative downtime, not flap count, in gpu-monitor

   Lessons

   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.

   View case

By root cause1