Why hardware binds

The binding constraint — the boundary this site runs into first — is hardware, with a gap of 68.3 % ◌ derived. The runner-up is timeline at 50 % ◌ derived, a margin of 18.3 % ◌ derived.

The scarce thing here is the chips themselves: they are sold out far ahead, and new orders join a queue measured in months. The building and the power are ready before the silicon arrives, so the wait for hardware sets the pace of everything else.

Hardware binds at 68.3 % ◌ derived. The GPU allocation queue stands at 16 months ◌ derived. Fragmentation loss is 7.2 % ◌ derived and the efficiency erosion rate is 123.9 % ◌ derived; capacity exists on order books before it exists in racks.

In this market, supply and demand are in balance: the facility can serve its demand at target utilisation across the planning horizon. The constraint register files this state under the code R1 ◌ derived.

Constraints form a cascade: each solved constraint increases the load on the next boundary. If hardware were cured — more of it bought, built or approved — the demand it now holds back would flow through to the next limit in this site's ranking, and timeline would become the binding constraint. Curing a constraint moves the boundary; it does not remove it.

Sweat the current fleetRefresh each cycleRefresh blocked

Counterfactual, sweat versus refresh: at 80 kW ◌ derived design density no next chip generation is supportable — the nearest higher generation enters at 120 kW ◌ derived per rack. The refresh path holds the current generation and matches the sweat path over the analysis horizon; the facility supports 1 ◌ derived generation classes over 5 years ◌ derived.

Whether that is acceptable is a judgment this model does not make.

Adjust the assumptions in the constraints builder →