DriveNets has taken multi-site AI networking from lab demo to commercial reality, fusing two WhiteFiber H200 GPU clusters 52 miles apart into one logical supercluster — a development UK buyers wrestling with grid constraints should read closely.
View the data behind this chart
| Traditional | Federated Model | Key Benefit | |
|---|---|---|---|
| Site Diversity | Compromise | Resilience Feature | Predictable Connect |
| Existing Estate | Full Site Refresh | Extend Useful Life | Add GPU Capacity |
| Capacity Refresh | Power Ceiling Limit | Reassess Timing | New Calculus |
| Software/Licensing | Single Site Focus | Span Physical Sites | Account for Workloads |
What actually happened
On 9 July 2026, DriveNets announced the industry's first commercially deployed long-distance "scale-across" AI network, built with WhiteFiber under the banner Project Redwood. The DriveNets AI Fabric connects two separate WhiteFiber data centres, each housing H200 GPU clusters, located 52 miles apart, and operates them as a single logical GPU supercluster rather than two independent environments.
Validated performance figures are specific: 111.2 Tbps of bandwidth between the sites with 0.9ms of guaranteed latency. DriveNets says testing compared rack-to-rack performance within a single site against rack-to-rack performance across the two locations; the press release does not itself disclose the comparative results, stating only that the findings are detailed in DriveNets' own white paper — an unlinked, vendor-produced document that has not been independently reviewed. The underlying hardware is DriveNets' 9300F, 5300R and 5301R switches, running Fabric Scheduled Ethernet (FSE) with cell-based load balancing, end-to-end Virtual Output Queuing and deep-buffer interconnect designed to absorb the synchronised traffic bursts typical of AI training runs.
Why UK buyers should care about power, not just performance
The commercial case here is not really about raw bandwidth — it's about what geographically distributed clustering unlocks for site selection. AI infrastructure buildouts are increasingly capped by the power and space available at a single facility rather than by compute availability. In the UK, grid connection queues and constrained capacity around London and the South East are widely reported industry challenges for data centre operators — general trade-press commentary rather than a claim specific to DriveNets — and a proven architecture that lets a GPU cluster span two sites without sacrificing performance is directly relevant against that backdrop.
For colocation providers and hyperscaler tenants planning UK footprints, scale-across networking means capacity decisions no longer have to be "find one enormous site with enough power" — they can become "find two or more adequately powered sites and federate them." That reframes site selection, lease negotiation and even capital planning through an IT finance calculator around a federated model rather than a single mega-campus.
The networking problem this actually solves
DriveNets is explicit that stretching a cluster across distance is harder than laying a cable between buildings. Inter-site links typically carry less bandwidth than the fabric inside either facility, and AI training traffic arrives as a handful of very large, synchronised flows rather than many small steady ones — a pattern that conventional load-balancing and buffering, built for general data centre traffic, weren't designed to absorb. Without purpose-built congestion management, latency spikes and packet loss stall jobs and leave GPUs idle on both sides of the link.
This is the practical reason UK infrastructure buyers should treat scale-across as an architecture decision, not just a procurement line item. If you're specifying GPU racks via an HPE server configurator, a Dell server configurator or a Lenovo server configurator, the interconnect strategy behind those racks now matters as much as the compute spec itself.
Implications for UK colocation and hyperscaler procurement
For UK colocation operators and enterprise buyers, a commercially proven multi-site fabric changes several assumptions worth testing with vendors during 2026 planning cycles:
- •Site diversity can now be pitched as a resilience feature rather than a networking compromise, since DriveNets claims lossless, predictable connectivity between sites.
- •Existing estate and refurbished servers may extend useful life longer if newer GPU capacity can be added at a second site instead of forcing a full-site refresh.
- •Capacity refresh timing should be reassessed using a server end-of-life checker, since federated clusters change the calculus on when a single facility's power ceiling actually forces a decision.
- •Software and licensing strategy around virtualised infrastructure, including any move covered by our look at VMware alternatives, should account for workloads that may now span physically separate sites.
Reading the vendor claims with a healthy filter
It's worth separating DriveNets' factual disclosure from its marketing framing. The company states this is the first commercial deployment of its kind, and DriveNets CEO Ido Susan is quoted saying, "Together with WhiteFiber, we have taken scale-across from concept to commercial reality, showing that two remote data centers can perform as a single high-performance supercluster." That's a vendor's characterisation of its own milestone, not independent third-party benchmarking, and UK buyers evaluating similar deployments should ask any prospective supplier for their own validation methodology and site-specific test data before committing capacity plans to a federated model.
For teams starting to model what this means for their own estate, the practical next step is usually a conversation grounded in current server configuration and site power realities — worth raising directly with a specialist via talk to a Servnet engineer or through general server configuration planning before assuming a federated build is right for a given workload.