What Is Scale-Across Networking?

What is scale-across networking? Learn the four requirements for connecting data centers into one lossless GPU cluster, with WhiteFiber Continuum™.

WhiteFiber Infrastructure Team

15 min read

Published:

November 3, 2026

November 4, 2026

WhiteFiber Continuum scale-across networking

Table of Contents

    Scale-across networking connects two or more data centers so they behave as one network, with the ordered, lossless delivery a GPU cluster expects inside a single site. Scale-up grows a system inside a server or rack, and scale-out adds more racks inside one data center. Scale-across extends the same fabric to a second building.

    ‍

    It is easy to get wrong. Done badly, a cross-site cluster slows down, drops packets under load, or forces workarounds just to keep training jobs running. This post covers the four things our AI fabric provider says it takes to get it right, and how WhiteFiber Continuum™, built with DriveNets and WEKA, approaches each.

    ‍

    Why Distance Breaks a Normal AI Network

    ‍

    Inside a data center, GPU traffic crosses short links with microsecond-scale delays. Stretch the same traffic over tens of kilometers and two things change. Round-trip time rises: Continuum's 83 km span measures 0.9 ms. And far more data is in flight before any sender hears about congestion.

    ‍

    AI training is the worst case for this. Every GPU tends to finish a step and send gradients at the same moment, producing synchronized bursts. A network that treats each flow independently, or that has shallow buffers at the long link, turns those bursts into congestion and loss. RDMA is intolerant of both.

    ‍

    The Four Requirements

    ‍

    According to DriveNets, which provides the AI fabric layer for Continuum, successful scale-across networking comes down to planning ahead on four fronts:

    ‍

    1. The right buffering strategy – shallow buffers for intra-site connectivity, paired with deep buffers for the cross-site connection, so traffic bursts don't turn into congestion over distance
    2. Sufficient capacity between sites – preferably dark fiber, so there's no shared capacity or carrier-owned optical gear sitting inside the cluster's control plane
    3. A scheduler built for distribution – one that can spread and schedule workloads across the different physical systems, not just route between them
    4. Planning the whole system together – the fabric, inter-site network, scheduler, storage, and failure handling engineered as one system from the start, not stitched together after the fact

    Skip any one of these and a cross-site link stops behaving like a single cluster. It starts behaving like two clusters with a connection between them.

    ‍

    Scale-Across Networking Into Production

    ‍

    Continuum links WhiteFiber's QTS ATL1 (Atlanta) and QTS SUW1 (Suwanee) facilities, 83 kilometers apart, over 12 dark fiber strands leased from Zayo. A Ribbon Communications DWDM stack lights that fiber with 170 individual 800G ZR+ coherent optical channels.

    ‍

    The result, validated in production: 136 Tbps of aggregate bandwidth at 0.9 milliseconds of round-trip latency across the 83km span, within 8% of the physical limit for light in fiber over that distance.

    ‍

    The network fabric itself runs on DriveNets AI Fabric, built on Broadcom's Jericho3-AI and Ramon3 chipsets, using scheduled cell-based Ethernet rather than conventional hash-based load balancing. HBM-buffered leaf switches sit at the boundary between each site's internal fabric and the inter-site link. They're the deep-buffer layer DriveNets points to as essential: when every GPU finishes a training step and sends its gradients at once, these buffers absorb that burst before it can turn into congestion or packet loss, buying congestion-control signaling enough time to react.

    ‍

    On the storage side, WEKA NeuralMesh replicates data intelligently, pulling exactly what a job needs to the site where its GPU allocation lands, instead of keeping both sites in constant lockstep. Across both sites, 256 NVIDIA H200 GPUs per facility, 512 total, run active-active. Both sites carry live traffic at the same time, so there's no idle standby capacity and no failover delay.

    ‍

    Watch: DriveNets on What It Takes to Make Scale-Across Work

    ‍

    ‍

    DriveNets, which operates the network fabric layer for WhiteFiber Continuum, walks through what it takes to plan and deploy scale-across networking successfully. Watch here: WhiteFiber Continuum

    ‍

    In DriveNets' words: "You need to plan your network, for instance, with shallow buffer for the intra-site connectivity and deep buffer for the cross-site connectivity. You need to make sure you have sufficient capacity, preferably dark fibers between the systems, and you need to make sure you have a scheduler that can spread or schedule the workload across the different systems."

    ‍

    Across More Sites

    ‍

    Continuum runs on two sites today. WhiteFiber plans to add sites in a mesh or hub-and-spoke layout, which would let us combine smaller blocks of data center capacity into one fabric instead of depending on a single large campus.

    ‍

    The Jericho3-AI fabric is designed for clusters of up to 32,000 GPU endpoints, about 62 times today's 512. That is design capacity, not deployed or tested capacity. Broadcom's Jericho4 generation points to larger clusters, lossless RDMA beyond 100 km, and line-rate MACsec encryption on every port.

    ‍

    Who Needs Scale-Across Networking

    ‍

    Scale-across networking isn't the right fit for every AI infrastructure buyer. It tends to matter most for:

    ‍

    1. Frontier model labs and AI research teams whose training runs have outgrown a single site's power envelope
    2. GPUaaS and NeoCloud providers that want pooled capacity and an uptime story for their own customers without building multi-site engineering themselves.
    3. Regulated enterprises in finance and life sciences that need provable dual-site resiliency and jurisdictional data control, backed by facility-level certification
    4. Telco and edge operators looking to monetize existing distributed infrastructure, central offices and fiber investment, as GPU capacity
    5. Sovereign AI and government workloads that need compute to stay within national or jurisdictional borders without depending on a single site for critical workloads

    ‍

    ‍

    FAQ

    ‍

    What Is Scale-Across Networking?

    ‍

    Connecting two or more data centers so they behave as one network, with the same ordered, lossless delivery a GPU cluster expects within one site.

    ‍

    How Is Scale-Across Different from Scale-Up and Scale-Out?

    ‍

    Scale-up grows capability inside a server or rack, and scale-out adds more nodes inside one data center. Scale-across extends the fabric to additional data centers.

    ‍

    What Does Scale-Across Networking Require?

    ‍

    According to DriveNets: shallow buffers inside sites and deep buffers on the cross-site link, sufficient capacity (preferably dark fiber), a scheduler that can distribute workloads across sites, and planning all of it as one system.

    ‍

    How Does WhiteFiber Continuum Implement It?

    ‍

    Continuum connects two QTS facilities 83 kilometers apart using DriveNets AI Fabric for the network layer and WEKA NeuralMesh for data and storage, delivering 136 Tbps of aggregate bandwidth at 0.9 milliseconds of round-trip latency.

    ‍

    Is Data Sovereignty or Compliance Compromised?

    ‍

    No. Continuum is built to keep sensitive workloads within their originating jurisdiction even while failover and pooled AI compute happen across sites, so regulated enterprises get resilience without giving up data residency.

    ‍

    Is It Available Today?

    ‍

    Yes. WhiteFiber Continuum has been commercially available since September 23, 2026.

    ‍

    Can Scale-Across Networking Scale Beyond Two Sites?

    ‍

    Yes. The Jericho3-AI chipset underneath Continuum has headroom for a single cluster of up to 32,000 GPUs. Additional sites are expected to join in a hub-and-spoke or mesh configuration, using the same networking approach already in place. The limiting factor isn't the architecture. It's how many sites and how much power an organization is willing to wire together.

    ‍