Training and Inference Systems › Distributed Training and Sequence Parallelism
World Models HandbookAll chapters Training and Inference Systems › Distributed Training and Sequence ParallelismOne section · Sections in this chapter2 / 8 ↓
Reading tools Definitions & inline links
Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.
Article links
Make inline references clickable
Distributed training is the collection of techniques that allow one logical model to be trained using the memory and compute of many accelerators. It exists for two reasons that should be kept separate in your head, because they call for different remedies and are often confused with one another:
- Memory capacity: Parameters, gradients, optimizer state, activations and the input batch must fit. Two fp32 Adam moment tensors for a billion parameters occupy 8 GB decimal, excluding step counters and any master-weight copy. That is not the entire training footprint. Dtypes, optimizer variants and sharding determine what each rank actually stores.
- Throughput and wall-clock: Even when everything fits, dividing work can reduce completion time. A hypothetical day-long run that finishes in one hour across thirty-two workers has a 24-fold speedup, not ideal 32-fold scaling. Throughput affects experiment iteration and cost; under a fixed deadline or budget it can also determine whether a run is feasible.
The distinction matters because the two problems have different fixes. You should identify which tensors cause the memory limit. Tensor and pipeline parallelism partition model computation. Sharded data parallelism can instead partition optimizer states, gradients and parameters while retaining data-parallel work assignment, as described in ZeRO. Activation checkpointing trades recomputation for activation memory. Adding fully replicated data-parallel workers does not reduce the replicated parameter or optimizer footprint.
Trajectory length creates another possible memory limit. As an illustrative input, a five-minute video at 30 Hz contains 9,000 frames; a simulated trajectory could instead contain 10,000 transitions. These are examples, not typical training-window sizes. Partitioning only the batch still leaves each assigned sequence on its device. For suitable architectures, context partitioning distributes token positions and their attention work, while some frameworks use sequence parallelism for selected activation storage alongside tensor parallelism. Neither term licenses ignoring temporal dependencies. We will make those meanings explicit below.
Data Parallelism and Gradient Synchronization
A simple baseline is fully replicated data parallelism: every device holds a full copy of the model, receives its assigned minibatch, computes gradients locally, and then synchronizes gradients before the optimizer step. Mathematically, if worker has local loss computed from its own shard of the global batch, the goal is that every worker takes the same step using the global gradient
where:
- : the global gradient estimate, the average of the per-worker gradients
- : the number of workers sharing the global batch
- : the local loss computed by worker from its own shard of the global batch
- : the gradient of worker 's local loss with respect to the parameters
- : the model parameters, identical on every worker before the optimizer step
The gradient exchange operation is called all-reduce: every rank contributes a local gradient and receives the reduced result. In ordinary replicated data parallelism, matching initial parameters, optimizer state, hyperparameters and update order let ranks apply the same synchronized update. Gradient synchronization does not synchronize arbitrary mutable model state or repair differing optimizer state. PyTorch DDP organizes synchronization into gradient buckets; it is not necessarily one collective per whole step.
For a loss that is the mean of independent per-example terms, equal-size shards justify the displayed unweighted mean. Unequal shard sizes require weights proportional to the number of contributing examples or valid tokens, with matching loss normalization. This is a mathematical equivalence, not a promise of bitwise equality: floating-point reduction order changes rounding, and batch-dependent operations such as local BatchNorm can change the computation itself. Learning-rate and batch-size choices still require validation rather than following automatically from distribution.
Two details decide efficiency. First, a billion fp32 gradient entries occupy 4 GB decimal locally; this is a payload size, not the bytes sent over the network. For the ideal ring algorithm below, each rank transmits bytes for gradient payload . Other algorithms and compression change that count. Second, bucketing can overlap ready gradient reductions with remaining backward computation. Whether overlap hides much communication depends on bucket readiness, compute duration and network contention; a large model is not enough to guarantee it. Profile the particular encoder and dynamics workload.
Stochastic latent variables add a gradient-estimation question, not a requirement that data-parallel ranks sample identical latents. Independent random streams allow independent draws across ranks; after gradient reduction, parameters can still receive the same update. If the sampling distribution depends on parameters, differentiating a sampled value is not automatically an unbiased estimator. Valid pathwise or score-function estimators need their respective assumptions; straight-through estimators may be biased. Stochastic computation graphs make these dependencies explicit. Sharing seeds can correlate estimates and may increase or decrease variance depending on covariance; it does not generally buy lower variance. Replacing a sampled latent by its mean generally changes a nonlinear stochastic objective, although special cases such as affine costs can agree. Treat mean substitution as a modeling choice rather than a synchronization fix.
Tensor Parallelism, Pipeline Parallelism, and Their Costs
When layer or model storage exceeds one device's capacity, model-parallel schemes are possible remedies alongside state sharding or offload. Two useful families are:
- Tensor parallelism (TP): partition operations inside a layer. For a column-partitioned matrix in , rank computes the output-feature shard . Reconstructing requires concatenation, implemented by an all-gather when every rank needs the full output. A compatible next layer can consume the shards without gathering them first. In a row-partitioned multiply, each rank instead computes a contribution to the same output entries, and the contributions must be summed, for example with an all-reduce or a reduce-scatter. Megatron's linear-layer implementation makes this distinction explicit. Sharding reduces local weight storage, but layer-internal communication can become latency-critical. Its collective count and overlap depend on shard layouts, scheduling and kernels, not simply the number of layers. Fast links are valuable where communication is exposed; profiling determines the useful rank count.
- Pipeline parallelism (PP): consecutive layer blocks are assigned to stages, and independent microbatches flow through them. One stage can process a later microbatch while the next processes an earlier one. Filling and draining leave idle stage slots. For an ideal balanced forward pipeline with stages, microbatches, equal-duration stage work, no communication overhead and no overlap between separate batches, each stage does active slots within elapsed slots. Its idle fraction is
where:
- : the number of pipeline stages (each stage is a contiguous block of layers on its own device)
- : the number of microbatches into which each global batch is split
- : idle slots for an individual stage over the complete forward schedule; the split between filling and draining depends on the stage's position
At fixed , increasing makes this ideal idle fraction approach zero. It does not eliminate real communication, imbalance or memory costs. Training adds backward work and may use a different schedule, so apply the formula only to a schedule for which its slot accounting holds. The conveyor-belt intuition is useful: more independent items amortize startup and teardown, provided stations can process them at compatible rates.
For a large video encoder, tensor parallelism may address a layer-size limit; deep stacks can provide pipeline partitions. Rollout training still needs a workload trace before choosing either. A temporal transition is not necessarily an optimizer update or synchronization boundary: a learner can form one loss from an entire batch of imagined trajectories. Independent environments or particles can supply microbatches, but causal dependencies inside each trajectory remain. When utilization is poor, measure stage imbalance, communication, memory and schedule bubbles. Larger independent batches are one possible remedy, not a guaranteed cure or a requirement of all imagination-based training.
Sequence Parallelism for Long-Horizon Rollouts
Long-context training can exceed activation memory even when parameters fit. Partitioning known token positions distributes some of that storage and computation. The relevant length is the actual training context, not the total duration of the source video or a hypothetical imagination horizon. Tokens, frames and environment steps are different units, and there is no family-wide rule that world models use longer contexts than language models. The key question is which operations can be distributed without changing the computation.
The semantics differ by architecture. For a recurrent state-space model with hidden state , the recurrence
where:
- : the hidden state at time
- : the hidden state at the previous time step
- : the input at time
- : the deterministic state-transition function (the recurrent core)
has a causal dependency: a shard needs the preceding shard's final state. For an arbitrary nonlinear recurrent core, computing each chunk from zero and combining its final states cannot reconstruct the true trajectory. Parallel scans require a compact associative representation of transition composition. For example, input-conditioned affine maps compose as ; whether that representation is efficient depends on matrix structure and whether coefficients can be computed without the previous state. This does not establish an efficient scan for a nonlinear Dreamer-style recurrence. Such a model can batch independent episodes or particles while preserving time order within each trajectory; time partitioning needs actual boundary states, recomputation or an explicitly approximate training scheme.
For a transformer world model, context parallelism partitions token positions. In Ring Attention, queries stay on their owning device while key/value blocks circulate. Blockwise attention combines partial results using online softmax statistics rather than materializing the full attention matrix. Causal masks prevent attending to future positions. Dense attention still has quadratic total arithmetic, while token storage is distributed and temporary score memory is bounded by the chosen block size. Long-context attention over already available inputs does not remove autoregressive dependencies when generating new trajectory tokens. NVIDIA also distinguishes sequence parallelism from context parallelism: the former in Megatron shards selected activations alongside tensor parallelism, while the latter partitions the input context and attention work.
For an ordinary sequential diffusion or flow sampler, each solver step consumes the previous step's state. Assigning successive dependent steps to different devices therefore requires transfers at their boundaries, not necessarily a global collective. One exact baseline keeps solver steps ordered while distributing within-step spatial-temporal token work. Independent samples can also be batched. Alternative parallel or approximate solvers require their own convergence and quality analysis; the sequential dependency alone does not prove that every other distributed schedule is inefficient.
Let's compare the communication patterns to build intuition:
- Replicated data parallel: gradient-bucket collectives per synchronized backward pass, with payload proportional to gradient entries; overlap depends on the workload.
- Tensor parallel: layer-internal gathers, reductions or scatters, determined by partition layout. Count each collective's payload and rounds over the actual forward/backward schedule; some dependencies expose latency while others can overlap work.
- Pipeline parallel: point-to-point activation transfers at stage boundaries for each microbatch, with gradient transfers in backward. For stages and microbatches, the basic forward schedule has boundary transfers; their byte counts depend on the boundary tensors. More microbatches create overlap opportunities but do not guarantee hidden traffic.
- Ring context parallel attention: an ideal unpruned forward sweep over ranks can visit all KV blocks with sends per rank, without a final return exchange. Each block has size proportional to , so this schedule transmits per-rank KV entries proportional to , linear in total tokens , not quadratic. Here is the combined key/value width. Count the actual implementation's exchanges: the paper's Appendix A forward loop also exchanges after the last computation, making sends. Backward communication and causal pruning need separate accounting.
These patterns trade bytes, synchronization frequency and dependency placement. There is no universal ranking in which data parallelism always moves the most bytes or tensor parallelism always moves less. Model width, context length, microbatch size and rank count determine the comparison. Ring attention's quadratic arithmetic and linear per-rank forward KV traffic are different quantities; chunking bounds working memory rather than converting quadratic network traffic into linear traffic.
Large-model systems can combine several parallelism axes. A combination of data, tensor and pipeline parallelism is often termed 3D parallelism; an additional context or other partition introduces another axis, but these names do not define one mandatory world-model recipe. The mixture depends on interconnect, tensor shapes, sequence length and the measured schedule. A useful heuristic is to put the most exposed communication on the fastest available links. Data-parallel reductions can span slower links when enough backward work or gradient accumulation amortizes their cost; short synchronized updates can be latency-sensitive too.
An Illustrative Model of Gradient Sync Cost
To build intuition about gradient synchronization, consider an idealized ring all-reduce. A reduce-scatter phase and an all-gather phase each take rounds, with bytes sent per rank in each round. This gives the following communication-only model for :
where:
- : the time to complete the all-reduce collective with workers
- : latency per communication round in seconds
- : the per-byte transfer cost of the interconnect
- : gradient bytes held by each rank before the collective
- : worker count; a one-worker job has no synchronization, so
This derivation counts transmitted bytes and rounds, not reduction arithmetic, contention, or compute/communication overlap. Ring algorithms are analyzed by Patarasuk and Yuan (2009). The values below are hypothetical, not measurements of a GPU cluster. Holding global work fixed, we assume computation takes seconds per worker and add the unoverlapped synchronization time. The byte-transfer term approaches as workers increase, while the round-latency term grows.
import time
import numpy as np
import torch
import torch.nn as nn
import torch.nn.functional as F
# Hypothetical ring communication model; no cluster is benchmarked.
ALPHA = 40e-6 # 40 microseconds
BETA = 0.6e-9 # 0.6 ns per byte
PARAMS = 100e6 # 100M-parameter model
BYTES_PER_PARAM = 4 # fp32 gradients
GRAD_BYTES = PARAMS * BYTES_PER_PARAM # 400 MB gradient
worker_counts = np.array([1, 2, 4, 8, 16, 32, 64, 128, 256])
sync_times = (
2 * (worker_counts - 1) * ALPHA
+ 2 * (worker_counts - 1) / worker_counts * BETA * GRAD_BYTES
)
compute_per_worker = (
3.0 / worker_counts
) # total 3 seconds of work, split evenly
eff_ratio = compute_per_worker / (compute_per_worker + sync_times)workers | sync ms | compute s | efficiency
1 | 0.000 | 3.0000 | 100.00%
2 | 240.080 | 1.5000 | 86.20%
4 | 360.240 | 0.7500 | 67.55%
8 | 420.560 | 0.3750 | 47.14%
16 | 451.200 | 0.1875 | 29.36%
32 | 467.480 | 0.0938 | 16.70%
64 | 477.540 | 0.0469 | 8.94%
128 | 486.410 | 0.0234 | 4.60%
256 | 498.525 | 0.0117 | 2.30%The table starts at 100% compute efficiency for one worker, because no collective is needed. Efficiency then decreases in this strong-scaling model because per-worker computation shrinks, but the communicated gradient does not shrink to zero. Efficiency is the fraction of the modeled step spent computing, not a measured utilization or a direct speedup. Actual hardware may use other collective algorithms and overlap; those must be profiled rather than inferred from this toy.
The toy identifies a conditional bottleneck: when exposed synchronization takes longer than local computation, it occupies most of the modeled step. A rollout's individual temporal transitions need not each trigger a collective. Larger independent batches, gradient accumulation or better overlap can improve the computation-to-communication ratio, subject to memory and learning constraints. Check actual optimizer boundaries and traces rather than infer synchronization frequency from rollout length alone.
The modeled efficiency ratio shows the communication penalty as fixed global work is divided among more workers.
