GUIDE · EXISTING AI HALLS
Nameplate megawatts are not useful AI compute
Vincenzo Grimaldi · · founder-led, pilot-stage practice
THE SHORT ANSWER
The number of AI racks an existing hall can run is the smallest of a series of limits, one per stage between the utility connection and the rack, plus a few pass-or-fail gates. The contracted megawatts are only the first stage. In a hall built for lower density the smallest limit is usually a component nobody quoted when the capacity was sold, and it can be zero racks until that component is replaced.
The method
- For each constraint, work out how many racks of the target platform it permits, from the hall’s own ratings, the platform’s published rack power and the redundancy the hall keeps.
- Treat a pass-or-fail gate (can one rack position be fed at all? can the cooling architecture take this platform?) as zero racks until it passes.
- Take the minimum. That constraint binds; the others have headroom.
- Relieve the binding constraint, price and date the relief, and solve again. Repeating this is the headroom ladder.
Counts are floored to whole racks, never rounded up. Each relation is public on its own page; start from the constraint reference. A figure’s evidence class travels with it, and a result carries the weakest class that went into it (how the classes work).
Capacity is the smallest of a series, not the first number on the contract.
- 01electrical
What the grid agreement lets you import, and what holds in contingency.
- 02electrical
Often the longest lead time on the ladder.
- 03electrical
Protected load, after redundancy is kept.
- 04electrical
Pooled across runs unless the layout forbids it.
- 05electrical
Binds at rack one, not at scale.
- 06thermal
Duty at your site's conditions, not a reference case.
- 07thermal
Heat the plant can reject and the flow the loop can carry.
- 08physical
What the slab holds and the positions left.
- 09physicalUseful AI compute
Racks that run, at the density they are asked to run at.
The engine solves thirteen such constraints together, names the one that binds first, and then relieves it and solves again: the headroom ladder. Nameplate megawatts and useful delivered compute differ by whatever the weakest stage costs.
Worked example: a synthetic reference hall
This is the engine’s published reference hall. It is synthetic: invented to demonstrate the method, not a customer asset, and every figure below is modelled or assumed unless its basis says otherwise. The grid agreement is 12 MW contracted (14 MVA firm), the site peak is 7.4 MW and the existing IT load 4.9 MW. The target platform is gb300_nvl72, in the scenario “Hybrid DLC on retained plant, grid only”.
As found, the hall carries 0 racks, bound by Rack feed / tap-off rating. After the costed ladder it carries 26, bound next by grid_firm_capacity.
| Constraint | Racks permitted | Basis (evidence class in brackets) |
|---|---|---|
| Rack feed / tap-off ratingGATE | 0 | platform needs 205 [174–236] A (E0) per rack; installed tap-offs rated 63 A (E5) |
| Residual air load removal per rackGATE | 0 | 13.5 [10.6–21.3] kW (E0) of air-side load per rack against 9 kW (E3) the hall can remove per position |
| Transformer capacity | 7 | 1,330 [845–1,810] kW (E3) usable after redundancy and derating |
| UPS capacity (protected load) | 8 | 1,100 kW (E0) of protected-load headroom after N+1 redundancy |
| Busway ampacity | 12 | 8 run(s) at 400 A derated to 0.8 -> 1,720 kW (E0); this ASSUMES a rack's load can be shared across runs (A and B feeds): if each rack is fed from one run, declare lv.rack_feed_topology = single_run and whole racks are counted run by run |
| Chilled-water plant capacity | 14 | 1,900 kW (E3) of plant headroom against 135 [132–142] kW (E0) per rack — full rack load (rack heat rejected into the existing plant) |
| CDU capacity (derated to site water temperature) | 22 | 2,700 [2,070–2,970] kW (E0) usable against 122 [112–131] kW (E0) of liquid load per rack; 24 [21–26] degC (E0) approach available |
| Firm supply (grid import + behind-the-meter) | 26 | 4,600 kW (E3) of firm-supply headroom at PUE 1.3 [1.22–1.4] |
| Hydraulic flow capacity | 69 | 9,000 l/min (E3) available against 130 [120–140] l/min (E0) per rack (~1.45 l/min/kW at 10 K delta-T) |
| Available rack positions | 180 | 180 of 560 positions available in DH-02 |
Source: the engine’s published model pack (schema gridforge/model-pack/2, generated 2026-09-14). Constraints the pack does not express as a count: Floor loading, Cooling architecture per-rack capability, Achievable facility water temperature. The full document is on the worked-example page.
Read the table from the top: whichever row holds the smallest number sets the hall’s capacity, however large the contracted figure and however many racks the other rows would allow. That is why the same hall can hold 12 MW of contract and run 0 racks.
Why total power cannot answer the question
Dividing usable power by rack power gives how many racks you could feed if power were the only limit. It says nothing about whether any one position can be fed. The figure below applies the public rack-feed relation to a second, invented hall: with 63 A tap-off units no rack above about 41 kW can be fed, so the count is zero there even though total power would allow dozens.
Total power says how many racks you could feed. It does not say whether you can feed one.
- By power alone (usable kW ÷ rack kW)
- With 63 A tap-off units
- With 250 A tap-off units
Synthetic hall: 2400 kW usable IT power, 120 free rack positions, 400 V three-phase, power factor 0.95. The figures are invented to make one point and describe no real hall. The relation is I = P ÷ (√3 · V · pf). Modelled (E1); nothing here is measured. The engine solves thirteen constraints together, so a real hall’s curve is never this simple.
The plotted values, as a table
| Rack kW | By power alone | 63 A | 250 A |
|---|---|---|---|
| 10 | 240 | 120 | 120 |
| 15 | 160 | 120 | 120 |
| 20 | 120 | 120 | 120 |
| 25 | 96 | 96 | 96 |
| 30 | 80 | 80 | 80 |
| 35 | 68 | 68 | 68 |
| 40 | 60 | 60 | 60 |
| 45 | 53 | 0 | 53 |
| 50 | 48 | 0 | 48 |
| 55 | 43 | 0 | 43 |
| 60 | 40 | 0 | 40 |
| 65 | 36 | 0 | 36 |
| 70 | 34 | 0 | 34 |
| 75 | 32 | 0 | 32 |
| 80 | 30 | 0 | 30 |
| 85 | 28 | 0 | 28 |
| 90 | 26 | 0 | 26 |
| 95 | 25 | 0 | 25 |
| 100 | 24 | 0 | 24 |
| 105 | 22 | 0 | 22 |
| 110 | 21 | 0 | 21 |
| 115 | 20 | 0 | 20 |
| 120 | 20 | 0 | 20 |
| 125 | 19 | 0 | 19 |
| 130 | 18 | 0 | 18 |
| 135 | 17 | 0 | 17 |
| 140 | 17 | 0 | 17 |
| 145 | 16 | 0 | 16 |
| 150 | 16 | 0 | 16 |
What this does not cover
- It is a screening method, not a design, an approval or a statement that a hall can be loaded. Protection, commissioning, structural survey and the utility’s own conditions are outside it.
- The reference hall is synthetic and the models have not been calibrated against measured data from a real hall: the calibration ledger is empty (see the evidence page).
- Where an input is not supplied, a labelled library default is used and listed in a data request. A missing value is never treated as zero and never produces a date.
- Lead times and costs are ranges from a reference library until a supplier quotation replaces them. They are not commitments.
- Time to Power sells no equipment. Relief options are modelled so a buyer can compare them, not offered for sale.
Run it on your own hall
- Free capacity checkFree, no card
Seven numbers you already know, free. It names the constraint likely to bind first and what it had to assume.
- Density Screen€4,500
5 working days from a complete intake
One hall, with the first six rungs of the ladder and the inputs nobody has measured.