Where tensor-parallel inference hits the NVLink wall

2026-05-31 · GPU / distributed systems

Tensor parallelism splits each layer across GPUs, so every forward pass pays for an

all-reduce over the network fabric. On a single node that fabric is NVLink/NVSwitch — and

how close you get to its theoretical budget decides whether TP helps or hurts. This post

measures it on 4× H100 and explains where the wall is.

Repo with the full harness and CSVs:

nccl-collectives-bench.

What was measured

A bandwidth sweep (message size 8 B → 8 GB) of the three collectives that bound distributed

LLM work — all-reduce, all-gather, reduce-scatter — driving the canonical

nvidia/nccl-tests and adding a parser + analysis layer on top. The headline number:

• 
  All-reduce bus bandwidth ≈ 366 GB/s, about 77 % of the per-GPU NVLink uni-directional
  budget on this box. That 77 % is the practical ceiling TP communication runs into; the
  remaining gap is protocol overhead and the algorithm's traffic multiplier.


• Algorithm ranking at large messages: NVLS > Ring > Tree. NVLink SHARP (NVLS) offloads
  the reduction into the switch, which is why it pulls ahead once messages are big enough to
  amortise setup.


• A protocol study (Simple / LL / LL128) showing the small-message latency floor — the
  regime that actually matters for decode, where each token's all-reduce is tiny.

Why it matters for inference

Training all-reduces gradients on big tensors, so it lives in the bandwidth-bound regime

where 366 GB/s is good news. Decode is the opposite: one token at a time means small

messages, so you're pinned against the latency floor, not the bandwidth ceiling. That is the

real "TP wall" — past a certain TP degree, the per-token all-reduce latency dominates and

adding GPUs makes decode slower, not faster.

The repo also includes an eager-vs-CUDA-Graph comparison of that decode latency wall:

capturing the per-token step as a graph removes launch overhead that would otherwise be

indistinguishable from communication cost — a reminder to measure the right thing before

blaming the fabric.

Takeaway

"Use tensor parallelism" is not free advice. Measure the all-reduce on your fabric, know

your 77 %, and know that the number that decides decode latency is the small-message floor —

not the big-message bandwidth everyone quotes.

→ Methodology, raw CSVs, and the roofline analysis:

github.com/waynehacking8/nccl-collectives-bench