Composable racks, explained

A composable rack stops thinking in servers and starts thinking in pools. The words are new, but the idea is simple enough to hold in your head.

Pools

Everything in the rack falls into one of four pools: compute, accelerators, storage and network. Each pool is just a stock of capacity that any job can draw from, no matter which physical shelf it happens to sit on.

Nodes

A node is what you get when you describe the machine a job needs. Say how many CPU cores, how many accelerators, how much memory and storage, and the platform assembles that machine from the pools. It runs bare metal, so there is no hypervisor between your code and the hardware. When the job ends, the node dissolves and its parts return to the pools.

Slices

Sometimes a job needs less than a whole node. A slice carves an accelerator or a chunk of the fabric into a right-sized piece, so several jobs can share hardware without stepping on each other. Inference services, which rise and fall with traffic, are the classic case.

Compose for the job you have now. Give it back when it is finished.

The fabric

None of this works unless the pieces can talk to each other as if they were in the same chassis. That is the job of the interconnect: a dynamically reconfigurable fabric that carries the same model from a single rack to a full cluster, and on to the hyperscale tier. It is what turns a pile of parts into a machine.

Why it matters

Because the machine is described rather than bought, the cluster can follow the work. Training gets a large, tightly coupled node in the morning and the same hardware serves inference traffic in the afternoon. You spend less time stranding capacity and more time running models.