Fault tolerance and elastic training#
Large-scale jobs run for days across thousands of GPUs, where hardware faults, NIC flaps, and node loss are routine. This guide covers the mechanisms Primus exposes to survive and recover from failures: graceful exit + checkpoint-based resume, Megatron’s fault-tolerance package and in-process restart, and TorchTitan’s torchft-based elastic training. Parameters are grounded in primus/configs/modules/megatron/trainer_base.yaml, primus_megatron_module.yaml, and primus/configs/modules/torchtitan/pre_trainer.yaml.
The foundation of all recovery is checkpointing—read Checkpoint management first.
1. The recovery model#
There are three layers, from simplest to most advanced:
Checkpoint + restart—periodically save state; on failure, relaunch the job and resume from the last checkpoint. Works on every backend; relies on the scheduler (Slurm
--requeue, Kubernetes restart policy) to relaunch.Graceful exit—detect a signal or time/iteration budget, save a final checkpoint, and exit cleanly so the restart resumes with no lost work.
In-job fault tolerance / elastic—detect a failed rank and restart in-process (Megatron) or continue with a reduced/replaced replica group (TorchTitan + torchft) without tearing down the whole job.
2. Graceful exit and auto-resume (Megatron)#
Controls in trainer_base.yaml let a run stop cleanly at a boundary so the next launch resumes seamlessly:
Parameter |
Default |
Purpose |
|---|---|---|
|
|
Install a signal handler that saves a checkpoint and exits gracefully on SIGTERM (e.g. Slurm preemption). |
|
|
Exit (after saving) once the job has run this many minutes—useful to fit scheduler time limits. |
|
|
Exit after this many iterations. |
|
|
Enable ADLR auto-resume integration. |
|
|
Iterations between auto-resume checks. |
Primus-level continuation (primus_megatron_module.yaml):
Parameter |
Default |
Purpose |
|---|---|---|
|
|
Automatically continue from the latest checkpoint in the experiment’s save directory on relaunch. |
|
|
Disable the final end-of-run checkpoint save (leave |
Pattern: enable exit_signal_handler + exit_duration_in_mins (or rely on preemption signals), set a reasonable checkpoint save_interval, and turn on auto_continue_train so requeued jobs pick up where they left off.
3. Megatron fault-tolerance package and in-process restart#
Megatron integrates an optional fault-tolerance package and in-process restart (trainer_base.yaml):
Parameter |
Default |
Purpose |
|---|---|---|
|
|
Enable the Megatron fault-tolerance package (rank monitoring / heartbeat). |
|
|
Auto-calculate fault-tolerance timeouts from observed step times. |
|
|
Run the workload inspector server for health/diagnostics. |
|
|
Restart failed ranks in process to avoid a full job teardown. |
In-process restart reduces recovery time by re-initializing the process group and reloading state without re-scheduling the whole allocation. Combine with frequent checkpoints so the restarted ranks have a recent resume point.
4. Numerical safety nets (Megatron)#
Detecting corruption early prevents wasted compute and divergence (trainer_base.yaml):
Parameter |
Default |
Purpose |
|---|---|---|
|
|
Abort/handle on NaN/Inf in loss or gradients. |
|
|
Detect anomalous loss spikes. |
|
|
Detect abnormally large gradients. |
|
|
Reduce batch size when needed instead of failing. |
These don’t recover from hardware faults but stop a corrupted run before it pollutes downstream checkpoints.
5. Elastic training with torchft (TorchTitan)#
TorchTitan supports semi-synchronous, replica-based fault tolerance via torchft. Configured under fault_tolerance: in primus/configs/modules/torchtitan/pre_trainer.yaml:
Parameter |
Default |
Purpose |
|---|---|---|
|
|
Enable torchft fault tolerance. |
|
|
Process group backend for fault-tolerance coordination. |
|
|
Coordination timeout (ms). |
|
|
This replica’s ID. |
|
|
Number of replica groups ( |
|
|
Minimum replicas required to keep training. |
|
|
Semi-synchronous algorithm (e.g. DiLoCo-style), |
With replica groups, the loss of one replica can be tolerated as long as min_replica_size is still satisfied—training continues while the failed replica recovers/rejoins, rather than crashing the whole job.
Install the optional dependencies before enabling (requirements-torchft.txt):
pip install -r requirements-torchft.txt # torchft-nightly + OpenTelemetry exporters
TorchTitan also exposes communication timeouts under comm: (init_timeout_seconds: 300, train_timeout_seconds: 100) that govern how long collectives wait before declaring a fault.
6. Scheduler integration#
In-job mechanisms still need the scheduler to relaunch on full-job failure:
Slurm—submit with
--requeueso preempted/failed jobs are re-queued; pair withexit_signal_handlerto checkpoint on SIGTERM. See Deployment.Kubernetes—use a restart policy / operator that recreates pods; mount checkpoint storage on a shared/persistent volume.
Shared checkpoint storage—all ranks must read the same checkpoint directory after relaunch (NFS, Lustre, or object storage). See Checkpoint management.
7. Recommended setup#
Always checkpoint—set a
save_intervalmatched to your mean-time-between-failures; use async/distributed checkpointing to keep overhead low.Exit cleanly—
exit_signal_handler: true(+exit_duration_in_minsfor time-boxed allocations).Resume automatically—
auto_continue_train: true(Megatron) and--requeue(Slurm).Reduce recovery time at scale—
enable_ft_package+inprocess_restart(Megatron) or torchft replica groups (TorchTitan).Guard numerics—keep
check_for_nan_in_loss_and_gradon; consider spiky/large-grad checks for unstable configs.