Impacts of LLM Traffic on Peering Strategies#

Tomás Lynch (AS20473 — presents from his own network's experience)

• Why: GPU/LLM clusters create a new traffic-profile class that changes both DC fabric architecture and external interconnect economics — directly relevant to the PM's DC fabric and DC/WAN interconnect work, and a rare first-person operator account rather than a projection.
• What: How LLM traffic actually lands on a network. GPU clusters are built as two fabrics: a converged frontend leaf-spine (north-south inference and dataset-ingestion traffic, usually oversubscribed, 100GE/400GE at the edge) and a non-blocking backend leaf-spine (east-west training only), plus high-performance storage. The two LLM traffic classes behave oppositely: inference is low-volume, constant, bidirectional, geographically dispersed ("looks like traditional traffic" → latency-driven peering via IXPs and PNIs); dataset ingestion is massive, bursty, mostly inbound, concentrated — and it drives the 95^th-percentile transit bill (→ cost-driven strategy: rate-limit/schedule ingestion with customers, raise minimum commitments, add/rebalance transit, direct connects to GPU customers). GPU frontend traffic itself breaks the classic compute sinusoid: spiky outbound vs near-constant inbound.
• How: 24-hour traffic-graph comparisons of GPU vs traditional compute frontend patterns from the presenter's own network, then derived peering tactics per traffic class. Side observations: ingestion bursts can trip DDoS-detection thresholds (validate them), and mixed flow sizes make congestion management critical.
• Where applicable: Operators serving GPU/AI customers and DC providers designing frontend/backend fabric separation. The traffic-profile taxonomy generalizes; the numbers are one operator's network, so scale-dependence should be assumed.