AI Infrastructure Is Not Traditional Peering

Traditional peering solved a different problem. It connected eyeball networks to content networks. Traffic flowed north–south. A user clicked something, and a server responded. The pattern was request-and-response, short-lived, and mostly predictable. Capacity planning followed clean growth curves, and upgrades were reactive but manageable.

That model worked because the application layer behaved in a way the network could easily support. Caches reduced load. CDNs pushed content closer to users. Oversubscription was acceptable because not everyone clicked at once. The network absorbed bursts without needing to be perfectly balanced at all times.

Traffic Patterns Changed First

AI workloads do not behave like web traffic. There is no clean “user → server → response” loop. Instead, you have clusters of GPUs exchanging data constantly. Training jobs move data laterally across nodes. Inference clusters pull and push state depending on the model architecture and load.

This creates a heavy east–west traffic pattern.

It is not just volume. It is a sustained volume. Once a training job starts, it does not trickle. It runs hot for hours or days. During synchronization events, traffic spikes hard and fast. Gradient exchanges, checkpoint saves, and parameter updates all hit the network at once.

This is not bursty in the traditional sense. It is bursty on top of an already high baseline utilization. That distinction matters. Traditional networks rely on idle capacity to absorb bursts. AI networks often have no idle state.

This Is Infrastructure Traffic, Not User Traffic

Calling this “content” traffic misses the point. AI traffic is closer to storage replication or HPC cluster communication than anything in the consumer internet space. It is infrastructure talking to infrastructure. That means the tolerance for latency and packet loss changes.

In web traffic, a dropped packet is noise. TCP recovers. The user never notices. In AI training, packet loss can slow convergence or trigger retransmissions across thousands of nodes. Small inefficiencies compound fast. Latency variance matters as much as raw latency. Jitter becomes a real problem.

This forces a different design mindset. You are not optimizing for user experience at the edge. You are optimizing for deterministic performance inside the fabric.

Density Beats Reach

Traditional peering emphasized reach. More networks. More routes. More geographic spread. Success meant you could get closer to users and reduce transit cost. AI flips that priority.

The key metric is density. How much compute can you interconnect at high speed, with low and consistent latency, in a confined footprint. It is less about how many networks you can reach and more about how tightly you can couple the ones that matter. You are building a fabric, not a mesh of loosely connected peers.

High radix switching, deep buffers, and predictable forwarding paths become critical. Oversubscription ratios that worked for internet traffic start to fail. You cannot assume traffic will average out. It often aligns and peaks together.

Capacity Planning Looks Different

In traditional environments, you could plan upgrades based on utilization trends. You watched 95th percentile, added headroom, and scheduled upgrades before congestion became visible. AI does not give you that luxury.

A single new training workload can change your traffic profile overnight. Bringing a new cluster online can double east–west demand instantly. Checkpoint events can saturate links that looked fine minutes earlier. Capacity planning becomes scenario-based instead of trend-based.

You need to ask:

• What happens when two large training jobs sync at the same time?
• What happens when storage replication overlaps with model updates?
• What happens when a cluster fails and traffic shifts?

If your answer is “we’ll see,” you are already behind.

Interconnection Points Become Compute Adjacency Points

An internet exchange used to be a place to hand off traffic efficiently. Keep costs down. Reduce hops. Improve performance for users. In AI, the exchange point becomes something else.

It becomes a place where compute ecosystems meet. Where GPU clusters, storage systems, model providers, and data pipelines interconnect directly. The goal is not just efficient routing. The goal is minimizing distance between dependent systems. You are not just exchanging routes. You are enabling workflows.

This is where the concept of “AI gravity” shows up in real terms. Workloads pull toward locations where the network can sustain their demands. Once enough compute and data exist in one place, everything else follows.

Why Legacy Design Starts to Break

Legacy interconnection design assumes diversity smooths traffic. Many users, many destinations, uneven demand. That assumption no longer holds.

AI workloads are coordinated. They move in lockstep. When one part of the system scales, the rest often scales with it. This creates correlated demand, which is the worst case for a network designed around statistical multiplexing.

You start to see:

• Hot links that stay hot
• Buffers that never drain
• Microbursts that turn into sustained congestion
• Latency spikes during synchronization windows

Throwing more 100G ports at the problem helps, but it does not solve the underlying issue. The topology and traffic engineering model have to change.

What This Means in Practice

If you are building or operating infrastructure for AI, a few things become non-negotiable.

First, reduce unnecessary hops. Every hop adds latency and potential contention. Keep critical paths short and predictable.

Second, design for worst-case concurrency, not average utilization. Assume multiple high-intensity events will overlap.

Third, prioritize east–west capacity inside your footprint. North–south still matters, but it is no longer the dominant factor.

Fourth, treat interconnection as part of the compute stack. It is not a separate concern. It directly impacts training time, cost, and model performance.

Finally, stop thinking in terms of “internet traffic” versus “private traffic.” AI blurs that line. What matters is whether the network can sustain the workload.

The Bottom Line

Traditional peering optimized for delivering content to users. AI infrastructure optimizes for moving data between machines. That shift sounds subtle, but it changes everything.

If the network cannot keep up, the GPUs sit idle. And idle GPUs are the most expensive problem you can have.