Interconnect12 min read8 sections2,262 words

NVLink vs PCIe P2P: The Multi-GPU LLM Inference Showdown

Real bandwidth numbers, latency profiles, and scaling efficiency for 70B/405B/671B models on H100, H200, B200, and RTX 5090 clusters.

Published May 27, 2026
TL;DR
  • NVLink delivers 900 GB/s (H100) vs PCIe Gen5 x16 at 64 GB/s, a 14x raw bandwidth advantage that directly impacts tensor-parallel inference throughput.
  • For batch sizes <= 1 (latency-sensitive), NVLink reduces all-reduce time by 60-80% vs PCIe P2P, translating to 1.5-2x tokens/sec on 70B models.
  • PCIe P2P with NVSwitch (e.g., H100 HGX) scales better than NVLink rings but still 2-3x slower than NVLink fully connected topologies for large tensor-parallel groups.
  • On consumer GPUs (RTX 4090, 5090), PCIe P2P is the only option; use tensor parallelism with 4 GPUs max before communication overhead kills scaling.
  • For inference serving (batch size 32+), PCIe P2P becomes viable if KV-cache compression and FlashAttention-2/3 are used, reducing communication volume by 4-8x.
01

The Interconnect Divide: Why It Matters for LLM Inference

When you run a 70B parameter model across multiple GPUs, every single token generation requires multiple all-reduce operations across the tensor-parallel (TP) group. In a typical transformer layer with TP, each GPU holds a shard of the weight matrices. The forward pass for one token involves: a linear layer compute, an all-reduce to sum partial results across GPUs, then the next linear layer. For a 70B model with 80 layers, that's roughly 160 all-reduce calls per token. At 30 tokens/s, that's 4800 all-reduce ops per second. The interconnect bandwidth and latency directly determine how fast those collective operations complete.

NVLink (NVIDIA's high-bandwidth, low-latency GPU-to-GPU interconnect) offers up to 900 GB/s bidirectional per GPU on H100 (18 NVLink bridges at 50 GB/s each). PCIe Gen5 x16, by contrast, provides 64 GB/s bidirectional. That's a 14x raw bandwidth gap. But the story is more nuanced: PCIe P2P (peer-to-peer) allows direct GPU-to-GPU DMA without host memory staging, reducing latency compared to going through the CPU. However, even with P2P, PCIe still suffers from higher latency (1-2 microseconds vs NVLink's 0.2-0.5 microseconds) and lower sustained throughput due to protocol overhead.

For LLM inference, the critical metric is not just peak bandwidth but the time to complete an all-reduce on a tensor of size proportional to the hidden dimension. For a 70B model with hidden size 8192, each all-reduce moves roughly 64 KB per GPU (in FP16). At 900 GB/s, that's 71 nanoseconds; at 64 GB/s, it's 1 microsecond. When you multiply by 160 per token, the difference becomes 11.4 microseconds vs 160 microseconds per token. At 30 tokens/s, the PCIe system spends 4.8 ms per token on communication vs 0.34 ms for NVLink, a 14% overhead vs 1% overhead. This is the fundamental reason why NVLink-equipped systems dominate latency-sensitive inference benchmarks.

python
# Approximate all-reduce time for a single layer (FP16, hidden_dim=8192, 4 GPUs)
import numpy as np

tensor_size_bytes = 8192 * 8192 * 2  # 134 MB (full QKV projection), actually per GPU shard is smaller
# But typical all-reduce on activations: batch=1, seq=1, hidden=8192 => 16 KB per GPU
shard_bytes = 16 * 1024  # 16 KB

nvlink_bw = 900e9  # 900 GB/s
pcie_bw = 64e9     # 64 GB/s
nvlink_lat = 0.5e-6  # 0.5 us
pcie_lat = 1.5e-6    # 1.5 us

# ring all-reduce time = 2 * (N-1)/N * (size / bw) + latency overhead
# For 4 GPUs: factor = 2 * 3/4 = 1.5
nvlink_time = 1.5 * (shard_bytes / nvlink_bw) + nvlink_lat
pcie_time = 1.5 * (shard_bytes / pcie_bw) + pcie_lat

print(f"NVLink all-reduce: {nvlink_time*1e6:.2f} us")
print(f"PCIe P2P all-reduce: {pcie_time*1e6:.2f} us")
print(f"Ratio: {pcie_time/nvlink_time:.1f}x")
Note

The above calculation assumes ideal bandwidth utilization, which PCIe rarely achieves due to protocol overhead and congestion. Real-world PCIe P2P all-reduce is often 2-3x slower than the raw bandwidth suggests.

03

PCIe P2P: When and How It Works (and When It Doesn't)

PCIe Peer-to-Peer (P2P) allows a GPU to directly read or write to another GPU's memory over the PCIe bus without going through the host CPU or system RAM. This is enabled by the PCIe BAR (Base Address Register) mapping and requires that both GPUs are on the same PCIe root complex (i.e., same CPU socket) and that the platform supports P2P (most modern server platforms do). On consumer platforms (e.g., Z790 with two GPUs), P2P may work if both GPUs are connected to the CPU's PCIe lanes directly (x16/x16), but if one GPU goes through a chipset (PCH), P2P is disabled.

For LLM inference, PCIe P2P is the only option for multi-GPU setups without NVLink. On the RTX 4090 and RTX 5090, you can use tensor parallelism via PyTorch's DistributedDataParallel or custom all-reduce kernels (e.g., NCCL). However, the bandwidth is limited to PCIe Gen4 x16 (32 GB/s) or Gen5 x16 (64 GB/s). For a 4-GPU RTX 5090 system, the PCIe Gen5 x16 provides 64 GB/s per direction, but the actual all-reduce throughput is typically 40-50 GB/s due to protocol overhead.

The key insight: PCIe P2P is viable for inference when the batch size is large enough that compute time dominates communication. For batch size 32 with a 70B model, the compute time per layer is around 2-3 ms, while the all-reduce time is about 0.1 ms (PCIe), so communication is only 3-5% overhead. For batch size 1, compute per layer is ~0.3 ms, and communication is ~0.1 ms, 25% overhead. This is why NVLink matters most for latency-sensitive applications (chat, real-time) and less for high-throughput batch serving.

Tools like vLLM and TensorRT-LLM automatically select the best communication backend. vLLM uses NCCL (NVIDIA Collective Communications Library) which supports NVLink, PCIe P2P, and InfiniBand. You can force a backend with NCCL_P2P_DISABLE=1 to simulate PCIe-only mode for benchmarking.

bash
# Check PCIe P2P support and topology
nvidia-smi topo -m

# Force NCCL to use PCIe only (disable NVLink and P2P)
export NCCL_P2P_DISABLE=1
export NCCL_NVLS_DISABLE=1
export NCCL_SHM_DISABLE=1  # disable shared memory

# Run vLLM with PCIe-only backend
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Meta-Llama-3-70B \
  --tensor-parallel-size 4 \
  --dtype bfloat16 \
  --max-model-len 4096
05

Software Stack: NCCL, CUDA-Aware MPI, and Custom Collectives

The performance of NVLink vs PCIe P2P is not just hardware, the software stack matters enormously. NCCL (NVIDIA Collective Communications Library) is the de facto standard for multi-GPU communication in LLM inference. NCCL supports NVLink, PCIe P2P, InfiniBand, and shared memory. It automatically selects the fastest path based on topology. However, NCCL's all-reduce algorithm for ring topologies (common on PCIe) has a bandwidth bottleneck: the ring all-reduce achieves at most 1/(N-1) of the per-link bandwidth for large messages. For 4 GPUs, that's 1/3 of the 64 GB/s PCIe bandwidth, i.e., ~21 GB/s effective. NVSwitch with tree all-reduce achieves nearly full bandwidth (800+ GB/s).

For PyTorch users, torch.distributed.all_reduce uses NCCL by default. TensorRT-LLM uses custom fused kernels that combine the all-reduce with the preceding linear layer's output (fused all-reduce). This reduces the number of kernel launches and improves utilization. vLLM also uses NCCL but with custom attention kernels (PagedAttention) that reduce communication volume.

For AMD GPUs (MI300X), the equivalent is RCCL (ROCm Collective Communications Library), which supports Infinity Fabric. RCCL's performance is comparable to NCCL for up to 4 GPUs but lags for 8+ GPUs due to less optimized tree algorithms.

For Apple Silicon (M3 Ultra), there is no PCIe P2P or NVLink equivalent, the UltraFusion interconnect (2.5 TB/s) connects two M3 Max dies, but for multi-Mac setups, Thunderbolt 5 (80 GB/s) is the only option, which is far slower than even PCIe Gen4. MLX and MLC-LLM handle this with model parallelism (pipeline parallelism) rather than tensor parallelism.

A critical detail: NCCL's NVLink detection relies on the nvidia-fabricmanager service. If this service is not running (common in Docker containers), NVLink may fall back to PCIe P2P silently. Always verify with nvidia-smi nvlink -s.

bash
# Check NVLink status and bandwidth
nvidia-smi nvlink -s

# Check NCCL topology
python -c "import torch; print(torch.cuda.nccl.version())"

# Force NCCL to use NVLink (disable PCIe)
export NCCL_P2P_DISABLE=0
export NCCL_NVLS_ENABLE=1

# Run a simple all-reduce benchmark
python -c "
import torch
import torch.distributed as dist
dist.init_process_group(backend='nccl')
rank = dist.get_rank()
world_size = dist.get_world_size()
tensor = torch.randn(1024, 1024, device='cuda')
dist.all_reduce(tensor)
print('All-reduce done')
"
08

Practical Recommendations: Which Interconnect for Your Use Case

1. Latency-sensitive chat applications (batch size 1-4): Use NVLink (SXM or NVLink bridges). The 2-3x tokens-per-second improvement over PCIe P2P is critical for real-time user experience. H100 SXM5 or RTX 5090 with NVLink bridge (4 GPUs max) is ideal.

2. High-throughput batch serving (batch size 32+): PCIe P2P on RTX 5090 or H100 PCIe is cost-effective. Use tensor parallelism with 4 GPUs, and consider quantization (AWQ 4-bit) to reduce compute time. The throughput difference vs NVLink is only 20-30%.

3. Training vs inference: For training, NVLink is non-negotiable due to the massive gradient communication (all-reduce of full gradients every step). PCIe P2P would be 5-10x slower for training. For inference, the communication volume is smaller (activations only), so PCIe is more viable.

4. Large models (405B+): You need 8+ GPUs. NVSwitch is essential for scaling TP beyond 4 GPUs. PCIe P2P with 8 GPUs suffers from ring all-reduce inefficiency (effective bandwidth drops to 1/7 of per-link). Consider pipeline parallelism with PCIe if you must.

5. Budget builds: 2x RTX 5090 with NVLink bridge (128 GB/s) is a sweet spot for 70B models. Total cost ~$5,000. Use vLLM with tensor-parallel-size 2 and FlashAttention-2. Expect 25-30 tps (batch 1).

6. Apple Silicon: M3 Ultra with UltraFusion (2.5 TB/s) is effectively a single GPU for inference. No need for NVLink or PCIe. But you are limited to 192 GB unified memory, which caps model size at ~150B parameters (FP16). For larger models, you need discrete GPUs.

7. AMD MI300X: Infinity Fabric provides NVLink-like performance for up to 4 GPUs. For 8 GPUs, the mesh topology is less efficient than NVSwitch, but still better than PCIe. Use ROCm 6.0+ and RCCL for best performance.

Tip

Always benchmark your specific workload. The theoretical numbers are guidelines, but real-world performance depends on model architecture, batch size, quantization, and software versions. Use vLLM's benchmark script or a custom script with torch.distributed.

Pitfalls and common misconceptions

  • 1Misconception: PCIe P2P and NVLink are interchangeable for tensor parallelism. Reality: NVLink is 14x faster in raw bandwidth and 3-5x faster in effective all-reduce throughput for small messages (16 KB). For large batches, the gap narrows but still exists.
  • 2Pitfall: Using PCIe P2P with 8 GPUs on a dual-socket server. The two sockets are connected via UPI (Intel) or Infinity Fabric (AMD), which adds latency and reduces bandwidth. GPUs on different sockets communicate through the CPU interconnect, which is slower than PCIe P2P within a socket. Use nvidia-smi topo -m to check and avoid cross-socket communication if possible.
  • 3Misconception: NVLink bridges on RTX 5090 provide 900 GB/s like H100. Reality: RTX 5090 has only 2 NVLink links (128 GB/s total), not 18. It's still faster than PCIe Gen5 (64 GB/s) but not by the same margin as H100.
  • 4Pitfall: Forgetting to enable NVLink in BIOS or driver. On some motherboards, NVLink bridges are disabled by default. Check nvidia-smi nvlink -s to verify links are active. Also ensure the nvidia-fabricmanager service is running.
  • 5Misconception: Quantization reduces communication volume. Reality: Quantization reduces model weights (which are static) but activations remain FP16 (or FP8). The all-reduce in TP operates on activations, so communication volume is unchanged. However, quantization reduces compute time, making communication a larger relative overhead.
References

Further reading

Affiliate disclosure: Hardware references in this article may link to Amazon via our Associate tag fredoline-20. As an Amazon Associate, MyAIHardware.com earns from qualifying purchases at no extra cost to you. Citations and primary sources (papers, vendor docs, repos) are non-affiliate. See About / disclosures for the full policy.

Stay Ahead of the AI Curve

Get weekly AI hardware news, benchmark updates, and deals in your inbox. Founding-subscriber list, be one of the first.

&check; No spam&check; Weekly digest&check; Unsubscribe anytime