Decision Tables & Calculators

This appendix is realized as a live, interactive tool in 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/water, rack-cooling feasibility, reliability requirements, site scoring, and the CFADS project-finance model — sharing one scenario, so a change to the rack, the power price or the utilization flows through every connected calculator (site scoring stands alone). What lives on this page is the reference layer around the tool: what each calculator computes, the assumptions baked into its formula, and the static tables that are more useful seen whole than queried one value at a time. The expensive decisions in this guide reduce to checks you can run. Does the named rack's heat split close 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 — an investment-grade triple-net lease and a short-lease colocation portfolio sit at very different rating thresholds? Each is a few lines of arithmetic, and getting it wrong at scoping time is how facilities end up mismatched to the revenue they were built to earn.

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, 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: rear-door exchangers carry a typical 30–40 kW rack and past 50 kW with active doors, while an HPE GB200 NVL72 at 132 kW puts 115 kW into liquid and leaves 17 kW on air — a rear door sees the air exhaust, not the 115 kW already assigned to cold plates. What kW cannot tell you is which of the remaining candidates closes for the named rack, 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 candidate, the evidence that rules it in.

The live tool takes two requirements — concurrent maintainability, and ride-through of one component fault — and deliberately fails closed on topology and cost: it reports the two requirements and the evidence a topology decision needs, and it does not pick a topology or price a premium, because the state list below is what does that. Project topology requires named maintenance and fault states, the exact affected path, transfer interruption, post-event loading, path and control independence, common-mode dependencies, a recovery SLO, and workload and contract consequences. The starting map is nonetheless simple, and the register supports it. Neither requirement leaves N on the table. Concurrent maintainability alone needs a path you can take out of service with the load held — N+1 components on dual distribution paths (one active), or a distributed-redundant block. Fault tolerance needs a second path that carries the load through a fault — 2N, 2(N+1), or a distributed block designed for it — and that step carries a ~25–40% whole-facility planning premium (single-source heuristic) over the concurrently maintainable design. Which topology inside the class, and what the premium is for your project, follows from the checklist: which paths each state takes out, how the load transfers, what survives, and what the contract charges for the difference. Carry the completed list to Chapter 12.1 for the topology and Chapter 12.5 for the number.

The levered-IRR / 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 EBITDA, discount the unlevered free cash flow to an NPV and unlevered IRR, then layer 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. Lower billable utilization or rental price reduces receipts against operating cash and scheduled debt payments. 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 high and low inputs against the displayed annual cash-flow bridge: which assumption — utilization, power price, GPU residual, depreciation life, contract tenor — moves the answer most. The bridge shows revenue, cash costs and taxes, CFADS, interest/principal, reserves, and equity cash; terminal proceeds and debt payoff remain separate. Enter a retained-fleet earning period and project covenant before reading its decision. Sustaining spend creates no replacement fleet: passing DSCR does not demonstrate that a later GPU refresh is funded. In the 2026 market, the dominant fork is contracted versus merchant, because it sets both the discount rate and the achievable gearing.