AI data centres need connectivity, but networks do not replace capacity

The rapid growth of AI workloads is driving a shift in data center strategies, moving from simple capacity expansion to network optimization. This change emphasizes high-performance interconnection and low-latency networking, as critical factors for supporting dense computing clusters and real-time data exchange.

• IOWN Global Forum and DE-CIX argued that AI will put more weight on distributed sites and low-latency interconnection. These are industry proposals from organisations promoting optical networking and exchange services, not proof that capacity has ceased to matter.
• AI performance depends on several different networks: accelerator links, the data-centre fabric, inter-data-centre transport and user-facing routing. Bandwidth, congestion, path diversity, power and compute capacity must be measured together.

The reported event was a pair of industry arguments

The 25 March IT Brief report named two proponents that the old article omitted. Masahisa Kawashima of NTT and the IOWN Global Forum proposed distributing compute across smaller sites connected by high-bandwidth, low-latency optical networks and matched to regional energy. DE-CIX chief executive Ivo Ivanov argued that training tends to favour concentrated compute while some latency-sensitive inference should sit closer to users.

Both propositions deserve examination, not automatic promotion to market fact. IOWN develops photonics-based architectures; DE-CIX sells interconnection. Their statements explain the commercial and technical thesis behind distributed infrastructure. They do not show that all training is becoming geographically distributed, that all inference belongs at the edge, or that a network can turn distant capacity into a single cluster without workload penalties.

“Connectivity” covers at least three different control surfaces

Inside an accelerator system, scale-up links join processors and memory. Inside a data centre, a scale-out fabric carries collective training traffic, storage reads, checkpoints and service requests among racks. Between sites, data-centre interconnect carries replication or distributed jobs over longer paths. Beyond that, peering and transit route inference requests between users, clouds and applications. A high line rate at one layer cannot compensate for congestion, oversubscription or an outage at another.

Meta's production account shows what the intra-site problem entails: a specialised RoCE fabric, non-blocking design, topology-aware scheduling, load balancing and routing were needed to support distributed training at scale. Google's 2025 Jupiter paper likewise treats machine-learning traffic as one of several workloads a data-centre fabric must support. These are operational implementations at two hyperscalers, not evidence that every operator should copy one topology.

The release of Ultra Ethernet Specification 1.0 is another useful signal. Its work on congestion control, multipathing, ordering and retransmission shows that adding faster ports is not enough. It is a specification and ecosystem milestone; it does not prove deployment, interoperability or application performance in a particular facility.

Capacity means usable paths, not advertised port speed

For synchronous training, a slow or congested path can leave accelerators waiting during collective operations. Useful measures include bisection bandwidth, oversubscription, fabric utilisation, packet loss, retransmissions and tail completion time—not just 400 or 800 gigabits per second on a port. Inference can involve many short requests, but latency sensitivity varies: interactive control may benefit from proximity, while batch inference can favour centralised utilisation and cost.

Routing determines how that capacity is used. RFC 7938 documents BGP with Clos topologies and equal-cost multipath in large data centres, including convergence and failure considerations. ECMP can spread flows over available paths; it does not by itself eliminate collisions, congestion hotspots or slow recovery. Operators still need telemetry, congestion control, capacity engineering and tested failure handling.

Distance remains a workload constraint

IOWN published a proof of concept in which storage and GPU compute were separated over a 40-kilometre all-photonics link for a UNet3D medical-imaging training task. That is concrete evidence that one defined workload can operate across that link. It is not a benchmark for every model, collective pattern, distance or failure condition, and it does not make propagation delay disappear.

Cross-site designs also add optical paths, routers, protection switching, distributed storage, scheduling and operational coordination. They may improve access to land, energy or resilience, but they can introduce new failure domains and data-sovereignty constraints. The comparison must be with the full cost and performance of a concentrated alternative, not with an idealised “unified fabric”.

Energy and network location are coupled

The network thesis is partly a response to power scarcity. In its base case, the IEA projects global data-centre electricity use at about 945 TWh in 2030, just under 3% of global electricity consumption. It also notes that accelerated servers drive much of the increase and that power-system infrastructure generally takes longer to plan and build than a data centre. These are modelled projections with sensitivity cases, not guaranteed demand.

Moving workloads to another site helps only if electricity, grid connection, cooling, fibre routes and compute are available there at the required time. Renewable generation is variable, while training jobs, inference demand and network capacity have their own schedules. Distribution can relieve one constrained location but may require duplicated equipment and additional transport energy.

What would demonstrate a real shift

Evidence should connect claims to deployments: named multi-site workloads, measured job-completion and tail latency, DCI utilisation, route convergence, packet loss, cost per completed job, energy source and curtailment, grid-connection time, service availability and customer adoption. Interconnection-provider capacity growth is relevant, but it cannot attribute traffic growth to AI without workload data.

The defensible conclusion is that connectivity has become part of usable compute capacity. It does not replace megawatts, accelerators, storage or local fabric. Training, inference and replication require different placements, and the winning design will depend on measured workload and regional constraints rather than a universal move from “scale” to “connectivity”.