Spine-less ZCube: Why Is It Both Cheaper and Faster?

1Without a Spine Layer, How Are Switch and Port Counts Calculated?

ZCube does not reduce switch count by magic. It reallocates the port budget.

n = number of GPUs/NICs k = number of GPUs connected to each switch For dual-port NICs, the total number of switches is:

2n / k

Each switch group contains:

n / k switches

Each switch needs two types of ports:

The first type is GPU/NIC-facing access ports, numbering approximately:

k

The second type is inter-group ports connecting every switch on the opposite side, numbering approximately:

n / k

If all links use the same rate, the following simplified constraint applies:

k + n/k ≤ available switch ports

This equation reveals the essence of ZCube.

If k is too large: each switch requires many GPU access ports.

If k is too small: more switches are needed, and each switch must connect to more switches on the opposite side.

With corresponding dual-port NIC rates and port-breakout assumptions, a single layer of 51.2T switches can build a flat network connecting 16,384 400G NICs. Larger deployments can use higher-capacity chips or additional network planes. Actual scale is affected by per-port speed, breakout configuration, and the uplink/downlink bandwidth ratio; it cannot be inferred from the label “51.2T” alone.

ZCube does not eliminate the need for ports; it converts ports once reserved for Leaf-Spine connectivity into GPU-access and inter-group bipartite-interconnect ports.

2Why Can It Save on Switches and Optical Transceivers?

This removes the need to procure a separate switch layer devoted solely to transit. At the same time, network diameter is shortened from a typical three-switch cross-Leaf path to at most two switches.

With the same GPUs, servers, software stack, and applications, capital expenditure on switches and optical transceivers was approximately 33% lower than in the original Clos/ROFT design.

ZCube's cost advantage comes from removing the dedicated transit layer and reorganizing ports, not from switches and optical transceivers suddenly becoming free.

3Why Can Performance Improve with One Fewer Switch Layer?

But the primary logic behind ZCube's performance gains is not merely one fewer hop.

More importantly, it: reduces structural hotspots.

If the original network has many idle links but several key Leaf/Spine queues remain congested, increasing aggregate bandwidth does not solve the problem. ZCube rearranges GPU access relationships and GPU-pair paths so traffic uses links across the entire fabric more evenly.

A production report released on May 20, 2026 states that, in a 1,000-GPU GLM-5.1 coding-inference cluster, keeping GPUs, the software stack, and applications unchanged while changing only the network architecture increased average GPU inference throughput by more than 15% and reduced TTFT P99 by 40.6%. These are measurements from that specific production environment and do not imply identical gains for every workload.

Why can TTFT improve? In P/D disaggregation: Prefill generates the KV Cache. Decode can continue generating only after KV migration is complete.

If KV transfer is blocked on a hotspot link, the first token must wait. When network tail latency falls, TTFT P99 can naturally improve.

The GPUs and model may be unchanged while tokens arrive faster simply because the KV Cache is no longer blocked on the wrong network path.

4Physically Flatter, but Potentially More Complex to Operate

Do not assume that ZCube is easier to deploy simply because it has no Spine layer.

The ZCube production report explicitly notes that Clos cabling, IP-address planning, routing policies, and switch configurations could not be directly reused. The deployment team therefore developed the ZCube Controller, a data-center layout-design tool, and a cabling-correctness validator to generate configurations automatically and verify connections.

What does this show? ZCube's advantages depend on one condition: the topology must be wired correctly.

Misconnecting one Leaf-Spine cable in a conventional Clos fabric may cost one equal-cost path.

ZCube moves network complexity from the number of tiers to topology accuracy and automated control.

5Without Conventional Rails, How Should NCCL Understand This Network?

ZCube uses a hybrid of single-rail and multi-rail access. But it is unlike conventional ROFT, where: each NIC permanently corresponds to a symmetric rail isolated from the others.

This raises an important question: How should NCCL view these NICs?

According to NCCL documentation, NCCL_CROSS_NIC behavior depends on whether the network is rail-optimized. NCCL attempts to use the same NIC between nodes to accommodate architectures where each NIC connects to a different network rail.

ZCube's physical network is no longer a set of simply symmetric rails.

This is an engineering inference based on NCCL rail behavior and ZCube's hybrid access model. Whether a production implementation must modify NCCL topology files, environment variables, or upper-layer scheduling policies depends on the actual software integration.

ZCube does not remove NCCL's rail concept; it requires communication libraries to reinterpret which NIC corresponds to which type of physical path.

6When a Switch or Link Fails, Is ZCube More Fragile than Clos?

Dual-port NICs provide every GPU with two switch access points.

Physically, this means that if a NIC-port link or an access switch fails, a GPU may still remain reachable through its other port. The complete bipartite graph also provides abundant connections between the groups. But this must be interpreted carefully: the existence of an alternate physical path does not guarantee a seamless application failover.

Dual ports and the bipartite graph provide the foundation for fault tolerance; true application continuity also requires routing, the transport layer, and communication libraries to work together.

In summary: ZCube is not simply about "removing the Spine." It converts ports used for Leaf-Spine transit into GPU access and inter-group bipartite interconnects. In a specific deployment, this cut switch and optical-transceiver costs by about 33%, raised inference throughput by more than 15% in a 1,000-GPU GLM-5.1 cluster, and reduced TTFT P99 by 40.6%. The price of removing a tier is greater dependence on accurate topology and automated operations, and it does not solve endpoint Incast. It is not a universal answer, but an exchange of deterministic paths for lower cost and latency.