Distributed training spreads model computation or data across multiple GPUs or machines. It becomes useful when models or datasets exceed what one GPU can handle, and can improve training speed and hardware utilization. section 16.0 section 16.12
A distributed system contains processes identified by rank, with world size counting all processes. Processes communicate through a process group; a node is one machine, and local rank identifies a process within that machine. section 16.1.1
Common parallelism strategies divide different parts of training:
- Data parallelism replicates the model on each device, splits the data, and synchronizes gradients. section 16.12
- Model parallelism divides model parameters and computation across devices, while pipeline parallelism divides the model into sequential stages and processes concurrent microbatches. section 16.12
- Tensor parallelism partitions layers or tensors; fully sharded data parallelism shards model and data; n-dimensional parallelism combines several strategies. section 16.12
Figure 16.1 Single GPU training (left) vs. multi-GPU training (center) vs. training with multiple machines and multiple GPUs (right)
Compare single-GPU training with multi-GPU training on one machine and multi-machine training with multiple GPUs. section 16.1.1
A practical distributed job
A PyTorch training script initializes a process group, launches multiple processes—often with torchrun—and uses collective operations such as broadcast and allreduce to synchronize data and gradients. TorchTitan provides a minimal native-PyTorch example that can launch a large-language-model training job with one command. section 16.12 section 16.9
Multiple GPUs are typical, but the examples can also run on CPUs for experimentation. CPU runs may not provide meaningful speedups. Linux or macOS is recommended because PyTorch distributed APIs have limited Windows support. section 16.1.2





