Incident Library
Applied filters ComponentSlurm job schedulerSymptomTraining job failureFactorUnreviewed defaultsClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases1 case

1 to 1 of 1

  1. 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.

    Trigger

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

    Root cause
    Component
    Contributing factor
    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.

Check your cluster for this

This case involves NCCL and PyTorch. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.

By root cause1