← Concept library

Applied LLMs

InfiniBand and Inter-Node Networking

InfiniBand provides low-latency, high-bandwidth RDMA links between GPU nodes, and understanding its topology and collective communication patterns is essential for diagnosing and eliminating the network bottleneck in large-scale training.

intermediate · 8 min read · Premium

A single H100 GPU delivers roughly 3.35 TFLOPS of FP64 throughput but connects to the rest of the cluster through a wire rated at perhaps 200 Gbps. When you are synchronising gradients across thousands of such cards, the arithmetic units often idle, waiting for bytes to arrive. Inter-node networking is not a footnote to the accelerator story; for many workloads it is the binding constraint.

What InfiniBand actually is

InfiniBand (IB) is a switched-fabric interconnect standard defined by the InfiniBand Trade Association. Unlike Ethernet, which was designed for bursty packet traffic with loose latency guarantees, IB was engineered from the start for consistent sub-microsecond latency and deterministic throughput.

Each generation roughly doubles the per-4x-link signalling rate:

Generation Year Per-4x bandwidth
EDR 2014 100 Gbps
HDR 2018 200 Gbps
NDR 2022 400 Gbps

The adapter latency drops from about 5 microseconds for early SDR hardware to under 0.6 microseconds for HDR. That sub-microsecond latency is not marketing; it matters for small-message collectives where synchronisation round trips dominate.

The defining feature is RDMA (Remote Direct Memory Access). With RDMA, a NIC can read from or write to a remote node's pinned memory without involving the remote CPU. The initiating CPU posts a work request; the hardware completes the transfer; a completion queue entry signals done. CPU overhead per transfer collapses from O(bytes) to O(1) for large payloads. This is why IB and its Ethernet cousin RoCE (RDMA over Converged Ethernet) dominate AI training clusters: gradient tensors can be moved peer-to-peer at wire speed without paying kernel overhead on every packet.

Fat-tree topology and why it matters

The physical switching architecture determines whether bandwidth compounds or contends.

A fat-tree builds a multi-root tree where each layer of switches has more upward-facing ports than the layer below it, guaranteeing full bisection bandwidth: any communication pattern between equal-sized halves of the cluster is served at full line rate simultaneously. In a two-layer fat-tree, leaf switches connect directly to servers; spine switches connect leaf switches to one another. The DeepSeek Fire-Flyer cluster, for example, uses a two-layer fat-tree with Mellanox QM8700 switches (40 ports at 200 Gbps each), and found this was significantly cheaper than the three-layer topology typical of larger DGX-based deployments while still providing adequate bandwidth for their workloads.

The alternative, cheaper topology is multi-rail with oversubscription: each server has multiple NICs attached to different switches, but total uplink bandwidth is smaller than total downlink bandwidth. This is fine if you can co-schedule communicating nodes on the same leaf pod. When they span pods, bandwidth is reduced and latency spikes.

A practical design choice: multi-rail with eight 200 Gbps NICs per server (as used in the MegaScale deployment at ByteDance) provides both redundancy and aggregate bandwidth without requiring a three-layer fabric, provided ECMP (Equal-Cost Multi-Path) hashing is tuned to avoid hot-spot collisions.

Keep reading with Pro.

You're reading the preview. Unlock the full concept plus the library, study plans, the AI mentor, and daily emails.

Sign in to save and react.
Share Copied