Cases2 cases

1 to 2 of 2

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
2. IL-0125 A GPU died about once a week during a 176B-parameter training run, and sometimes the job hung instead of exiting, so SLURM never restarted it

   BigScience2022

   Symptoms

   During BigScience's 176B-parameter multilingual training (tr11-176B-ml) on the Jean Zay cluster, launched on 2022-03-11, one of the GPUs died about once a week. Most of the time the SLURM job crashed and restarted automatically from the last checkpoint.

   Training job failureGPU unavailable

   Trigger

   A GPU on one of the training nodes failed during the run.

   Root cause

   Hardware failure

   Component

   NCCLPyTorchSlurm job scheduler

   Contributing factor

   Unreviewed defaultsLimited debug access

   Detection

   There was no automatic detection of a hung job; it was noticed only when someone watching the training saw that it was stuck.

   Remediation

   • raised checkpoint frequency to every 200 iterations and then to every 100 iterations (SAVE_INTERVAL=100)
   • set NCCL_ASYNC_ERROR_HANDLING=1 so NCCL problems crash the job instead of hanging it
   • added the srun options --wait=60 and --kill-on-bad-exit=1 after testing them on 2 nodes

   Lessons

   On a long run across hundreds of GPUs, a dead GPU every week is routine; what costs time is the case where a process crashes and the job hangs instead of exiting, because then nothing restarts it. Making NCCL errors fatal and having the scheduler end the whole step on a bad exit is meant to turn such a hang into a crash that the existing automatic restart handles; only the srun part was tested. Frequent checkpoints bound the loss per crash, at the price of save time for a 2.3TB checkpoint.

   View case

By root cause2