Network Topology and Collective Communication
Model communication cost and hardware topology
Trace communication through the physical cluster, derive latency and byte costs for collective algorithms, and diagnose NCCL execution from rank and topology evidence.
Consider one backward pass for a transformer trained on eight graphics processing units (GPUs). One central processing unit (CPU) process controls each GPU, while GPU kernels execute the backward operations that compute a local 256 MiB gradient tensor in the GPU's high-bandwidth memory (HBM). The optimizer cannot update the weights until the eight device-resident gradient copies have been combined. PyTorch therefore asks a communication library to sum the tensors across the participating GPU processes and to return the same sum to each process.
A learner can observe the communication in two places. A PyTorch Profiler capture records a timestamped event for the collective call on each process. NVIDIA Nsight Systems records the CUDA calls made by the process and the communication kernels that execute on each GPU stream. Such a timestamped record is called a trace. A horizontal bar in the trace represents an operation with a recorded start time and end time; the bar does not, by itself, explain which physical route carried the bytes or why the operation waited.
The 256 MiB payload can cross a direct GPU link, an on-board GPU switch, Peripheral Component Interconnect Express (PCIe) switches, a network interface card, and data-center fabric switches. Remote direct memory access (RDMA) lets a capable network device access registered GPU memory without staging the payload through an ordinary CPU buffer. The route depends on GPU placement, network-interface affinity, and the topology detected by the collective library. Competing transfers can share one link even when the application assigns different rank numbers to their endpoints.
This chapter connects the application request to that physical route. NCCL executes communication kernels on the GPU's streaming multiprocessors (SMs), so communication can compete with model kernels for GPU execution resources as well as memory bandwidth. The sections derive message startup and transfer time, follow the steps of common collective algorithms, and explain how the NVIDIA Collective Communications Library (NCCL) selects and executes a path. Each model ends with a measurement that can show whether the predicted route, byte count, or waiting time appears in the running job.
Prerequisites
- Chapter 1 definitions of latency and completed payload bytes per second
- Chapter 5 stream and event dependencies
- Ability to distinguish a process, GPU, PCIe link, network interface, and network switch
Learning objectives
- Follow one tensor from source GPU memory to destination GPU memory through a physical cluster route
- Fit and qualify a startup-plus-byte communication model
- Derive collective rounds and bytes and diagnose NCCL execution with cross-rank evidence
Study this chapter
- 13.1Network topology levelsBegin lesson →
Draw and test the physical route from one source GPU allocation through links, switches, and a network interface to one destination GPU allocation
- 13.2Latency–bandwidth communication modelsBegin lesson →
Use a message-size sweep to estimate startup seconds and seconds per payload byte, then identify where the two-term model stops fitting
- 13.3Collective communication algorithmsBegin lesson →
Simulate ring reduce-scatter and all-gather round by round and calculate sent, received, and reduced bytes per rank
- 13.4NCCL execution and diagnosisBegin lesson →
Separate rank-arrival skew, incompatible collective order, stream dependencies, and slow transfer using profiler events, NCCL logs, and health status
Extended exercises
Complete these projects after the lesson-level practice tasks. Each project combines several mechanisms from the chapter.
Collective simulator
Simulate four-rank ring reduce-scatter and all-gather on a vector with distinct values from every rank.
Evidence: A round-by-round rank table, verified final sum, dependent round count, and exact sent and received bytes per rank.
Topology model
Draw one multi-GPU server from a supported topology tool and predict fast and slow directed GPU pairs before benchmarking them.
Evidence: A source-to-destination route diagram and bidirectional peer measurements that support or reject each prediction.
Collective curve
Benchmark all-reduce from 1 KiB through at least 1 GiB on one declared process group and topology.
Evidence: Raw samples, completed payload bytes per second, piecewise startup-plus-byte fits, observed algorithm regimes, and explained residuals.
Sources and further reading
The lesson explanations synthesize primary papers and official references. Follow the originals for proofs, exact APIs, architecture details, and version-sensitive behavior.