Decision Tables & Calculators

This appendix is a live tool on the site, not a wall of worked arithmetic. The suite is ten calculators: cluster sizing, GPU TCO and cost per GPU-hour, inference cost per million tokens, training-run cost, build cost per megawatt, facility energy and water, rack cooling, redundancy, site scoring, and the CFADS project-finance model. They share one scenario, so a change to the rack, the power price or the utilization flows through every connected calculator. Site scoring stands alone. This page holds the reference layer around the tool: what each calculator computes, the assumptions behind its formula, and the static tables that read better whole than queried one value at a time.

The expensive decisions in this guide reduce to checks you can run. Does the heat split of the rack you are buying work on air, on a rear door, or only on direct liquid? Which maintenance and fault states must the facility ride through, and is a second full path worth more than a faster checkpoint? Can a contracted cash flow service its debt at the coverage its lease profile has to clear? A long-term triple-net lease with no recontracting risk and a short-lease colocation portfolio sit at very different rating thresholds. Each check is a few lines of arithmetic.

The token-cost check shows how far an answer moves with its inputs. Spheron's published case, Llama-3.1-70B in FP16 on one 8×H100 node at $2.40/GPU-hr serving about 2,800 tokens/s (April 2026), works out to about $1.90 per million tokens. Price the node instead at the September 2026 on-demand H100 median from GetDeploying, $3.50/GPU-hr, and that throughput comes to about $2.80 per million. Spheron reports that FP8 roughly doubles throughput at the same hourly price, which roughly halves the cost. Measure throughput on your own model, precision and batch size before you trust any of these numbers.

The TCO model supplies the owned node calendar-cost basis used by the token model. The token calculator compares rented and owned $/M-tokens on the same guide throughput assumption and owned-use utilization. It has no sell-price input and no margin output. The facility energy/water calculator takes IT MW (nominal), the annual-average load as a % of nominal, PUE, power price, and WUE as inputs, then returns facility MW, annual MWh, annual energy cost, and annual litres. Cluster sizing reports active, installed, and stranded GPUs separately so fractional demand is never mistaken for purchasable rack capacity.

Rack kW is the screening input, and it narrows the field fast. SemiAnalysis reports 30–40 kW for a typical rear door and more than 50 kW once fans are active. Vendors rate each door by model, at the water and air conditions they specify (Chapter 5.3): nVent's passive 800 mm door has no fans of its own, so the servers' fans must push air through it, and its rating falls from 38 kW with 14 °C water and 24 °C air to 34 kW with 24 °C water and 27 °C air. An HPE GB200 NVL72 at 132 kW puts 115 kW into liquid and leaves 17 kW on air, and a rear door sees only that air exhaust, not the 115 kW already assigned to cold plates. What kW cannot tell you is which remaining path works for the rack you are buying, because two racks at the same draw split their heat differently. The matrix below is the checklist behind Chapter 5.1 and Chapter 5.4: for each cooling path, what has to be true for it to work.

The redundancy calculator sizes N, N+1, 2N, 2(N+1), 3N/2 and 4N/3 for one load from equal modules. For each option it reports the installed modules and their multiple of N (a proxy for equipment cost, not for distribution, transfer or controls), the load on each module, whether the option rides through a module failure, whether a module or a path can be serviced with the load held, whether it survives losing a path or a failure during service, and a modelled annual downtime. It then names the option with the fewest modules that meets your two requirements: concurrent maintainability and ride-through of one module failure. The downtime uses Chapter 12.5's k-of-n method with one repair crew per path or block and assumes independent modules, paths that share nothing and transfers that always work, so read it as a floor. Savills (May 2024) passes on one source's rule of thumb, from Dgtl Infra, that building and fitting out a Tier IV facility can cost 25–40% more than Tier III; price your own option from its bill of materials. Before you buy, name the maintenance and fault states the load must survive, the exact path each one takes out, the transfer interruption, the load on what survives, how independent the paths and controls really are, what they share, the recovery time, and what each state costs the workload and the contract. The list below is that evidence; carry it to Chapter 12.1.

The levered-IRR and project-finance model is the companion to Chapter 2.5. Its mechanics are a standard infrastructure pro-forma. Build a contracted (or merchant) revenue line, subtract opex to reach EBITDA, discount the unlevered free cash flow to an NPV and unlevered IRR, then layer on the debt structure to solve for levered IRR. The DSCR (cash available for debt service ÷ debt service) sizes how much leverage the cash flow can carry. When billable utilization or the rental price drops, receipts fall but scheduled debt payments do not. The model treats opex as a percentage of revenue, so if your staff, lease and maintenance costs are mostly fixed, coverage drops faster in practice than the model shows.

Use Chapter 1.8’s matched ownership/rental cash-flow case for the capacity commitment, then Chapter 2.5’s DSCR case for the funding bridge. A procurement saving does not establish debt coverage. Build the sensitivity ranking by running a high and a low value of each input through the annual cash-flow bridge and seeing which moves the answer most. Test billable utilization, the rental rate and how it re-contracts, power price, depreciation life, contract tenor and exit multiple. The model has no input for GPU resale value; it keeps the fleet until the end of its declared earning life. The bridge shows revenue, cash costs and taxes, CFADS, interest and principal, reserves, and equity cash. Terminal proceeds and debt payoff stay separate.

Enter a retained-fleet earning period and a project covenant before reading the decision. Sustaining spend creates no replacement fleet, so passing DSCR does not show that a later GPU refresh is funded. Contracted or merchant revenue, counterparty quality, CFADS and collateral limits together decide how much debt the project can carry and what its capital costs (Chapter 2.5).