In the physics of data centers, the most critical number is the **Switch Radix** ($R$). Radix refers to the number of high-speed ports available on a single ASIC. Because every hop in a network adds latency and every cable adds cost, the goal of any topology is to connect the maximum number of GPUs with the minimum number of hops.

For a standard 3-tier **Fat-Tree** (also known as a non-blocking Folded Clos network), the maximum number of endpoints ($N$) that can be supported is determined by the switch radix:

If we use a current-generation switch with a radix of **64** (typical for 51.2T ASICs like Tomahawk 5), we can support:

Engineering a 64K cluster is a "moonshot" exercise. The number of links ($L$) scales linearly with the number of GPUs, but the complexity of managing those links—and the cost of the transceivers—scales with the number of switch tiers.

Collective Map: All-Reduce vs. All-to-All

Not all AI communication patterns are equal. The choice between Fat-Tree and Dragonfly depends heavily on which collective communication primitives your training library (NCCL, RCCL) uses:

• **All-Reduce**: Typically implemented as a "Ring" or "Recursive Doubling" algorithm. This pattern is relatively friendly to Fat-Trees because it can be localized. If your job fits within a single Rack (8-16 GPUs) or a single Leaf group, the traffic never hits the Core.
• **All-to-All**: Commonly used in **MoE (Mixture of Experts)** models. Here, every GPU sends unique data to every other GPU. This is the ultimate stress test. In an MoE model with 32K experts, the network bisection bandwidth *is* the model's bottleneck. Dragonfly topologies often struggle here unless the adaptive routing can predict the experts' data-shuffling pattern.

This structure creates a **Hierarchical Topology**. Inside a group, every switch is connected to every other switch (Intra-group). Externally, every group is connected to every other group (Inter-group).

The maximum number of groups ($g_{max}$) is determined by the number of global links: $ah + 1$. This allows a Dragonfly to scale to massive port counts with only a **diameter of 3** (maximum 3 hops between any two nodes).

In a Fat-Tree, routing is "Easy." Because the bandwidth is uniform and the network is non-blocking, a simple **ECMP (Equal Cost Multi-Path)** hash is sufficient to distribute traffic. If two paths exist, they are mathematically equivalent in performance.

In a Dragonfly, this assumption breaks. If you use standard shortest-path routing (ECMP) on a Dragonfly, certain global links will become "Hotspots" while others sit idle. To achieve theoretical bisection bandwidth, Dragonfly requires **Adaptive Routing**, specifically **UGAL (Universal Global Adaptive Load-balanced)** routing.

**UGAL** dynamically chooses between MIN and VLB for every flow. It monitors the occupancy of its local output queues. If the direct path is congested, it "paints" the traffic through a random intermediate group.

At 32K GPUs, networking power consumption becomes a thermal bottleneck. A single 800G OSFP transceiver consumes between **14W and 18W**. In a 3-tier Fat-Tree with 160,000 optics, the network alone consumes over **2.5 Megawatts** of power—not for compute, but simply for moving photons between racks.

This "Power Tax" is why Dragonfly is gaining traction: it physically removes the middle tier of switches and optics, effectively deleting 30% of the entire network's power footprint.