Quick Answer: A fat-tree for AI training is a Clos-style fabric that keeps the same bisection bandwidth as you move up from server links toward the spine, so many GPU nodes can talk east-west without a thin choke at the core. In practice it is a leaf-spine (and sometimes a third tier) whose uplink capacity is provisioned to match the downlink, not a marketing name for any Ethernet closet.
Fat-tree topology architecture is a hierarchical training network that fattens core links so the tree does not starve the leaves. Classic campus trees get thinner toward the root. A fat-tree is built so that a large all-reduce does not serialize on a single skinny uplink.

Network and training owners should use the term only when they can point at oversubscription ratios. This page defines the shape. It is not an InfiniBand-versus-Ethernet buyer guide and not a failure story about an undersized fabric.
What makes a tree “fat”?
| Layer |
Role in training |
Fat-tree intent |
| Leaf or top-of-rack |
Connects NIC ports on GPU servers |
Server-facing bandwidth is the budget you must not strand |
| Spine or aggregation |
Connects leaves so racks can reach each other |
Uplinks from each leaf should match the server-facing sum you care about |
| Optional core / super-spine |
Joins pods in a large hall |
Pod-to-pod bisection stays in the same design conversation |
If each leaf has 12.8 Tb/s of server ports and 3.2 Tb/s of spine ports, you have a tree. You do not have a fat-tree for that leaf. Training collectives that cross racks will feel the 4:1 cut. People still call that a leaf-spine. The word “fat” is doing no work.
How does training traffic use the shape?
Multi-node training sends a lot of east-west traffic: all-reduce, parameter gather, and pipeline activations. Those flows are many-to-many, not a user-to-app north-south pattern. A fat-tree gives those flows more than one path and enough core capacity that ECMP or fabric routing can spread them.
The topology does not choose InfiniBand or RoCEv2. Either RDMA transport can sit on a fat-tree, a rail-optimized variant, or an oversubscribed clos. Transport and topology are different layers. So is NVLink inside a node, which never sees the tree.
Rail-optimized designs are cousins, not aliases. They align NICs and switches so a collective’s rails stay on predictable planes. You can have rails on a fat-tree, and you can have a fat-tree without a rail story. Do not treat the names as interchangeable in a design review.
What the name does not guarantee
It does not guarantee lossless behavior. It does not guarantee that your job launcher binds the right NIC. It does not guarantee that storage traffic stays off the training plane. An undersized or misrouted fat-tree still idle-waits GPUs. The architecture is a capacity shape, not a performance warranty.
It also does not tell you how many racks you can grow before you add a tier. That is a scaling worksheet. When the worksheet says the spine will oversubscribe, you are leaving fat-tree intent even if the drawing still looks like a diamond.
Dedicated halls make the drawing easier to keep honest because the fabric has one job. One mention of high-performance AI networking is enough: review the topology and the oversubscription numbers together, not the word “fat” alone.
FAQ
Is a two-switch lab a fat-tree?
Only in a trivial sense. Two nodes through one pair of switches can be fully connected without a tree story. The term starts to matter when several leaves must cross a spine and you have to decide whether that spine is as wide as the leaves. Do not use the word to decorate a POC.
How is this different from “the network is undersized”?
Undersized is a diagnosis that the offered collective load exceeds a cut. Fat-tree is a target shape that tries to keep those cuts wide. You can still undersize a fat-tree by buying the wrong uplink ratio. Keep the definition and the failure mode on separate pages.
Does fat-tree replace InfiniBand?
No. InfiniBand is a fabric technology. Fat-tree is how layers of switches are sized and wired. You can build an InfiniBand fat-tree or an Ethernet Clos that aims at the same bandwidth idea. Choosing RoCEv2 versus InfiniBand is a different comparison.
Why do diagrams look like a diamond, not a tree?
Because a Clos or leaf-spine drawing places spines in a row above leaves. The historic “tree” name survives from the idea of links getting fatter toward the root. If your diagram shows a thin root, it is a tree in the campus sense, not the training sense.
What should a design review ask?
Ask for the oversubscription ratio at each tier, the number of rails, where storage joins, and a collective baseline on the longest path. If the answers are only “we use fat-tree,” the review is not done. Topology is a number plus a drawing, not a slogan.
Summary
Fat-tree topology architecture for training is a Clos-style fabric that keeps bisection bandwidth wide as traffic leaves the rack. The word is only honest when uplink capacity matches the leaf bandwidth you care about. It is not a transport, not NVLink, and not a guarantee against an undersized cut.
When you review a dedicated training hall, pair this definition with the numbers on AI networking rather than treating “fat-tree” as a feature checkbox.