Removing the Spine Layer: How Does ZCube Interconnect 1,000-, 10,000-, and 100,000-GPU AI Clusters?
1ZCube Scale Depends on Switch Port Density, Number of Planes, and More
ZCube cannot place an unlimited number of switches in a single complete bipartite graph.
Its scale must be jointly governed by:
- switch radix
- the number of GPU downlinks, k
- the number of switches in each group, n/k
- port speed
- network planes
Scale can be extended with higher-capacity switches or by partitioning ZCube into more planes.
ZCube therefore does not scale like a conventional Clos fabric by continually adding Spine switches.
Instead, it scales by: adjusting k, increasing switch port density, adding independent network planes, and redesigning GPU and switch groups.
The mathematical expression for ZCube fabric scale is:
Assume a NIC has total bandwidth M (for example, 400 Gbps) that can be split into k ports. If a switch has n ports at bandwidth M, then the per-port bandwidth is B = M/k, and the number of physical ports supporting bandwidth B is P = n*M/B = n*k.
Maximum ZCube fabric scale (number of NICs): S = P^2/4 = (n*k)^2/4 k = 2, n = 4: S = 16 k = 2, n = 128: S = 16,384 k = 2, n = 256: S = 65,536 k = 4, n = 128: S = 65,536 k = 4, n = 256: S = 262,144
2What Is ZCube? Not a Switch Product, but a Network-System Design
ZCube is not the name of a particular switching ASIC. Nor is it a fixed switch model.
First and foremost, it is a: GPU-cluster network-topology and routing design.
A production deployment also requires:
- high-radix switches
- dual-port GPU NICs
- precise cabling rules
- dedicated routing policies
- a topology controller
- automated configuration generation
- cabling validation
- monitoring and fault handling
- coordination with communication libraries and schedulers
A topology diagram alone is therefore not enough to call a network ZCube. If it lacks:
- correct GPU-ID mapping
- single-rail / multi-rail access
- a complete bipartite graph
- a unique optimal path
- controller support and automated validation
it may simply be a non-standard network that resembles ZCube.
ZCube originated in research on automated topology optimization published at SIGCOMM 2025 and publicly disclosed a production deployment for a 1,000-GPU inference cluster in 2026.
ZCube's value lies not in any single cable, but in the system formed by topology, routing, cabling, the controller, and AI traffic.
3The Spine Layer Is Gone, but Its Core Network Functions Are Distributed Across the Switches
Without Spine switches, what supports the underlying interconnect of a GPU cluster? The answer comes down to five pillars. First, switch grouping All switches are divided into two equal-sized groups.
Second, complete bipartite interconnection Every switch in one group directly connects to every switch in the other.
Third, dual-port GPU access Each GPU/NIC connects to both switch groups at the same time.
Fourth, complementary single-rail and multi-rail mapping One port is organized by consecutive GPU ranges; the other is cross-organized by relative index.
Fifth, deterministic GPU-pair routing A unique optimal path is assigned to every GPU pair, reducing avoidable link contention.
ZCube removes the dedicated Spine layer, not the switching capability between devices.
A conventional Clos fabric centralizes the network core in the Spine layer; ZCube distributes access and transit functions across two switch groups.
Dual-port NICs are not merely active/standby connections; they provide two complementary views of GPU grouping simultaneously.
ZCube primarily reduces avoidable congestion caused by topology and path mapping; it cannot eliminate last-hop Incast.
NCCL remains responsible for orchestrating AllReduce, All-to-All, and other communications; ZCube places those communications on more appropriate physical paths.
The conventional Leaf-Spine approach is to:
- first provide many equal-cost paths
- then let ECMP distribute traffic as evenly as possible
ZCube instead:
- first understands GPU communication relationships
- then redesigns GPU access and switch interconnection
- gives each GPU pair a deterministic, short, low-contention path whenever possible
This is not simply about buying one fewer switch layer. It addresses a deeper question: Must AI-cluster networks continue to use Clos fabrics designed for general-purpose data centers?
As P/D disaggregation, KV Cache migration, MoE All-to-All, and long-context inference continually change traffic patterns, a network may no longer be able to serve as a generic pipeline alone.
It must begin to understand:
- how GPUs are grouped
- how requests are scheduled
- where KV data moves from and to
- which communications are regular
- which communications are dynamic
- which congestion can be prevented at the architectural level
That is what makes ZCube worthy of attention from AI-network engineers.
The Spine layer has not vanished into thin air.
Some of its original functions have been broken apart and re-embedded in: switch grouping, the complete bipartite graph, dual-port access, and GPU-pair routing.