Pipeline parallelism trains a model that cannot fit on one GPU by partitioning its sequential layers into stages on multiple devices. It improves on naive model parallelism: rather than letting stages wait for one batch to traverse the entire network, it keeps stages working concurrently on different pieces of that batch. section 4.1 section 4.4.2
Figure 4.8 (a) An example neural network with sequential layers is partitioned across four accelerators. Fk is the composite forward computation function of the kth cell. Bk is the backpropagation function, which depends on both Bk+1, from the upper layer, and Fk. (b) The naive model parallelism strategy leads to severe under utilization due to the sequential dependency of the network. (c) Pipeline parallelism divides the input minibatch into smaller microbatches, enabling different accelerators to work on different microbatches simultaneously. Gradients are applied synchronously at the end. (Source: figure 2, “GPipe: Easy Scaling with Micro-Batch Pipeline Parallelism,” Huang et al., 2019, arXiv:1811.06965)
The pipeline timeline contrasts sequential stage idleness with microbatches flowing through partitioned layers concurrently; gradients are applied synchronously after the minibatch. section 4.4.2
Start by splitting a neural network into sequential subnetworks and assigning each to a GPU. Divide each input minibatch into smaller microbatches. While an earlier stage processes a later microbatch, downstream stages process earlier ones, overlapping forward and backward work across the available accelerators. This raises device utilization and training throughput compared with sequential model parallelism. section 4.1 section 4.4.2
Pipeline parallelism is appropriate when its capacity benefit outweighs its implementation and operational cost:
- Use it when the whole neural network exceeds the memory of a single device; data parallelism cannot resolve model-size memory limits because every worker needs a complete model copy. section 4.2.1 section 4.4.2
- Prefer data parallelism when the model fits on one GPU and the main problem is training time, because it requires fewer code changes and is easier to understand and debug. section 4.1 section 4.4.3
- Plan the partitioning per model architecture. Converting single-device code requires splitting the network, placing subnetworks on devices, and transferring intermediate outputs; no general splitting method is provided. section 4.1 section 4.4.2
Two-stage transformer deployment
A multi-machine training setup can initialize remote communication, divide transformer encoder layers across two GPUs, and construct a pipeline over those partitions. The training system must provide each worker with its identity and group settings, including worker address, process ID, GPU ID, and group size. section 4.4.2 section 4.4.3
Pipeline code is usually written by data scientists, while platform engineering automates its execution. A training service can allocate workers, establish interworker communication, distribute code and initialized parameters, and pursue high GPU utilization. Because distributed training depends on every worker, monitoring, failover, and recovery are required to limit the cost of a worker failure. section 4.4.3
Treat pipeline parallelism as a specialized response to model capacity, not the default distributed-training option. Begin on one machine; move to distributed training for long-running large-data workloads, choose data parallelism when possible, and choose a pipeline when the model itself cannot load on one GPU. section 4.4.3 section 4.5



