Skip to main content
Applies to: Embedded ✅, Enterprise ✅ Resuming loads a StreamingDataset checkpoint saved by Checkpointing back into a fresh dataset and DataLoader, so a failed or restarted run picks up where it left off rather than rereading from the start. This page assumes the rank, world_size, num_splits and shuffle_seed terminology from Distributed Training.

Resuming on the same topology

load_state_dict() rejects a checkpoint whose num_splits or shuffle_seed differs from the new dataset. For an exact resume, also use the same table snapshot, epoch, shuffle, filter, and other data-selection settings, and keep world_size the same — changing it is a topology change, covered next. The number of DataLoader workers may still change as long as the batch-size divisibility constraints from Distributed Training hold.

Resuming Across Different Topologies

When training across ranks, each rank owns its own subset of splits and only its own splits have exact progress. To resume on a different world_size, collect the state_dict() from every rank of the previous run and merge them with StreamingDataset.merge_state_dicts before calling load_state_dict() on the new run. The merge is topology-agnostic: pass the full list of per-rank states in, and hand the identical merged dict to every rank of the resumed job, regardless of whether the topology grew, shrank, or stayed the same.

Next steps

Checkpointing

Save progress, including with multiple DataLoader workers.

Distributed Training

The rank, world size and split terminology resuming builds on.