Appendix C

Decision Tables & Calculators

The irreversible decisions in this guide reduce to a handful of arithmetic checks; this appendix is the live calculator layer that runs them, plus the static reference tables that anchor it.

What you'll decide here

Use the live Calculators for the numbers that change with your inputs—TCO and $/GPU-hr, inference $/M-tokens, PUE/WUE, and preliminary rack-cooling feasibility. They run entirely in your browser and nothing you type leaves the page.
Use the static tables for the evidence that each candidate requires: the rack-cooling feasibility matrix and the redundancy outcome matrix. Neither is a density or workload-label lookup.
Treat every default in the calculators as a placeholder, not a recommendation — replace it with your own quoted capex, contracted power price, measured throughput, and real utilization before you trust an output.
Carry the outputs back to the chapter that owns the decision: the TCO/token math to Chapter 1.8, the project-finance ratios to Chapter 2.5, the cooling verdict to Chapters 5.1 and 5.4, and the redundancy choice to Chapter 12.2.
Validate any calculator result against the named equipment schedule, project conditions, and dated figures in Appendix D before using it in a decision—the model is a screening tool, not equipment qualification.

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, redundancy topology, site scoring, and the CFADS project-finance model. All run in your browser with editable inputs, so the right way to "read" them is to open the tool and put your own numbers in. What lives on this page is the surrounding reference layer: what each calculator computes, the assumptions and caveats baked into its formula, and the static tables that are more useful seen whole than queried one value at a time.

The expensive decisions here are checks you can run, not opinions. Which cooling candidates close for this named rack after its heat split/flux, airflow/inlet limits, water conditions, room rejection, climate, service/redundancy case, and refresh tail are entered? Which named maintenance and fault states must retain service, what interruption and recovery does the workload tolerate, and does the incremental value of a duplicated path beat checkpoint, replica, or fleet-level alternatives? Can a contracted cash flow service its debt at the coverage ratio a lender will accept? 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.

What each calculator computes

Calculator input and output reference

Calculator	Inputs · unit · allowed range · default	Outputs	Shared-scenario connection	Owning chapter
Cluster sizing — model → MW Key lever: Peak demand, throughput assumption, and serving headroom	Model size (`params`) · B params · 0.1–100,000 · default 70 Bytes / param (`bytes`) · bytes · 0.01–16 · default 1 KV cache / token (`kvKb`) · KB · 0–100,000 · default 330 Context length (`ctx`) · tok · 1–10,000,000 · whole number · default 32000 Concurrent requests / replica (`conc`) · requests · 1–1,000,000 · whole number · default 64 Activation + framework overhead (`ovh`) · % · 0–500 · default 15 HBM per GPU (`hbm`) · GB · 1–10,000 · default 186 Peak demand (`demand`) · tok/s · 1–1,000,000,000,000 · default 50000 Throughput / replica (`tput`) · tok/s · 1–1,000,000,000,000 · default 11200 Serving capacity (`util`) · % · 1–100 · default 70 Qualified GPUs / replica (`replicaGpus`) · GPUs · 1–10,000 · whole number · default 8 GPUs / rack (`perRack`) · GPUs · 1–10,000 · whole number · default 72 Purchase quantum (`purchaseQuantum`) · GPUs · 1–10,000 · whole number · default 72 GPU TDP (`tdp`) · W · 1–10,000 · default 1200 Host overhead (`host`) · × GPU TDP · 0.1–10 · default 1.528 PUE (`pue`) · ratio · 1–2.5 · default 1.15 Rental price (`price`) · $/GPU-hr · 0–1,000 · default 18.77	VRAM / replica GPUs / replica Replicas Active GPUs Installed GPUs Stranded GPUs Installed racks Facility design draw Fractional fleet rental	Connected 17/17 · all fields	Chapters 9.7 / 10.11
Build cost — $/MW capex Key lever: IT MW, scope boundary, and regional multiplier	IT capacity (`mw`) · MW · 0.001–100,000 · default 0.132 Facility, land & utility works (`facility`) · $M/MW · 0.01–100 · default 11.8 Network & cluster infra (excl. servers) (`fitout`) · $M/MW · 0.01–100 · default 4.9 Project-priced facility premium (`premium`) · % · 0–200 · default 0 Regional multiplier (`region`) · × · 0.1–10 · default 1	Facility capex Network & cluster infra Total (excl. servers) $/W excl. servers	Connected 4/5 Local only: premium	Chapter 2.5
Training run — cost & time Key lever: MFU × goodput and cluster size	Model size (`params`) · B params · 0.1–100,000 · default 70 Training tokens (`tokens`) · T tokens · 0.001–1,000,000 · default 15 Peak per GPU (`pflops`) · PFLOPS · 0.001–1,000 · default 2.5 MFU (`mfu`) · % · 1–100 · default 40 Cluster size (`gpus`) · GPUs · 1–10,000,000 · whole number · default 10000 Goodput (`goodput`) · % · 1–100 · default 90 Rental price (`price`) · $/GPU-hr · 0–1,000 · default 18.77 GPU TDP (`tdp`) · W · 1–10,000 · default 1200 Host overhead (`host`) · × GPU TDP · 0.1–10 · default 1.528 PUE (`pue`) · ratio · 1–2.5 · default 1.15 Power price (`power`) · $/kWh · 0–10 · default 0.08 Grid carbon (`co2`) · gCO₂/kWh · 0–10,000 · default 384	Wall-clock GPU-hours Rental cost Energy CO2	Connected 12/12 · all fields	Chapter 12.2
Project finance — CFADS, DSCR & IRR Key lever: Revenue ramp, leverage, and rate	Total capex (`capex`) · $M · 0.01–10,000,000 · default 5.382408 Construction period (`constructionYears`) · yr · 0–20 · default 2 Debt / leverage (`leverage`) · % · 0–100 · default 60 Interest rate (`rate`) · % · 0–100 · default 7 Debt term (`term`) · yr · 1–100 · default 10 DSRA (`dsraMonths`) · mo · 0–120 · default 6 Grace period (`graceYears`) · yr · 0–99 · default 0 Revenue (stabilized) (`revenue`) · $M/yr · 0–10,000,000 · default 6.445468 Ramp to stabilized (`rampYears`) · yr · 0–50 · default 2 Revenue growth (`revGrowth`) · %/yr · -100–100 · default -15 Opex (`opex`) · % of rev · 0–100 · default 25 Sustaining capex (`sustaining`) · % of rev · 0–100 · default 3 Cash tax rate (`taxRate`) · % · 0–100 · default 21 Tax depreciation life (`deprLife`) · yr · 1–100 · default 10 Hold period (`hold`) · yr · 1–100 · default 7 Exit multiple (`exitMult`) · × EBITDA · 0–100 · default 12 Discount rate (`discount`) · % · 0–100 · default 10	Equity IRR Project IRR Min DSCR (CFADS) Equity ($M) NPV ($M) Equity NPV ($M) Equity multiple	Connected 17/17 · all fields	Chapter 2.5
GPU TCO & $/GPU-hour Key lever: Owned-use utilization and depreciation life	Server cost (`serverCost`) · $ · 0–100,000,000 · default 3178008 GPUs / server (`gpus`) · GPUs · 1–10,000 · whole number · default 72 Depreciation life (`years`) · yr · 0.25–20 · default 3 GPU TDP (`tdp`) · W · 1–10,000 · default 1200 Server overhead (`host`) · × GPU TDP · 0.1–10 · default 1.528 PUE (`pue`) · ratio · 1–2.5 · default 1.15 Power price (`power`) · $/kWh · 0–10 · default 0.08 Owned-use utilization (`util`) · % · 1–100 · default 70 Installed / active allocation (`installedPerActive`) · × · 1–100 · default 1.285714 Opex (`opexPct`) · %/yr · 0–100 · default 8 Rental comparator (`rental`) · $/GPU-hr · 0–1,000 · default 18.77	$/active GPU-hr Annual cost/active GPU Depreciation Energy Opex Breakeven utilization vs rental	Connected 11/11 · all fields	Chapter 1.8
Inference $/M tokens Key lever: Throughput assumption and owned-use utilization	Rented node cost (`rentalPerHr`) · $/hr · 0–1,000,000 · default 150.16 Owned node calendar cost (`ownedPerHr`) · $/hr · 0–1,000,000 · default 23.156524 Throughput (`tps`) · tok/s · 1–1,000,000,000 · default 11200 Owned-use utilization (`util`) · % · 1–100 · default 70	$/M tokens — rented capacity $/M tokens — owned capacity	Connected 4/4 · all fields	Chapter 10.11
Facility energy & water Key lever: IT load, PUE, and WUE	IT load (`it`) · MW · 0–100,000 · default 0.132 PUE (`pue`) · ratio · 1–2.5 · default 1.15 Power price (`power`) · $/kWh · 0–10 · default 0.08 WUE (`wue`) · L/kWh IT · 0–100 · default 0.4	Facility draw Annual energy Annual energy cost Annual water	Connected 4/4 · all fields	Chapter 15.1
Rack cooling feasibility Key lever: Named equipment heat split and the complete facility envelope	Current rack power (screening input) (`rack`) · kW/rack · 1–1,000 · default 132 Upper roadmap rack power (screening input) (`future`) · kW/rack · 1–1,000 · default 132 Heat captured to liquid (`liquid`) · % of rack heat · 0–100 · default 87 Qualified airflow/inlet envelope proven? (`airflow`) · No / Yes · default Yes Rack water connection available? (`water`) · No / Yes · default Yes Rear-door system qualified? (`rdhx`) · No / Yes · default No Room residual-air capacity (`residual`) · kW/rack · 0–1,000 · default 20	Current rack heat Liquid heat Residual air heat Preliminary cooling feasibility	Connected 2/7 Local only: liquid, airflow, water, rdhx, residual	Chapter 5.4
Reliability requirements Key lever: Complete state-and-path design basis	Concurrent maintainability required? (`cm`) · No / Yes · default Yes Ride through one component failure? (`fault`) · No / Yes · default No	Concurrent-maintenance requirement Single-component-fault requirement Topology decision Required project evidence	Connected 2/2 · all fields	Chapter 12.1
Site-scoring playbook Key lever: Kill gates before the weighted score	Power availability / speed-to-MW (`power`) · /10 · 0–10 · default 7 Interconnect & permitting (`interconnect`) · /10 · 0–10 · default 6 Power price / PPA (`price`) · /10 · 0–10 · default 6 Land & expandability (`land`) · /10 · 0–10 · default 7 Water & climate (`water`) · /10 · 0–10 · default 6 Incentives / tax (`incentives`) · /10 · 0–10 · default 5	Site score Assessment	Independent 0/6 Local judgment inputs; not inferred from the project scenario	Chapter 3.13

Use the shared-scenario connection column to identify which project assumptions carry into each calculator. Local-only inputs require an independent project value.

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-cooling feasibility reference matrix

Rack kW is a screening input, not a cooling verdict. Freeze the named OEM operating envelope, heat flux, liquid heat-capture fraction and residual room-air load; then test airflow and pressure capability, inlet limits, TCS/FWS interfaces, climate and water constraints, redundancy, serviceability, and the future equipment tail. Two racks at the same kW can therefore require different systems. The table below is the selection checklist behind the engineering in Chapter 5.1 and Chapter 5.4; it is not a universal density threshold map.

Rack cooling feasibility matrix

Candidate	Required evidence and facility conditions	Decision boundary
Qualified air-only	0% liquid capture; named airflow, pressure, inlet and containment envelope closes through the roadmap case	Air-only remains feasible inside that declared envelope
Rear-door-assisted air	Air path plus qualified rear door, rack water, door heat-capture duty and room residual-heat path	RDHx may be feasible; rack kW alone does not establish it
Direct liquid + residual air	Named liquid heat fraction, supported TCS/FWS/CDU path, and residual room heat within the redundancy-case limit	DLC is feasible for the named equipment and facility envelope
No closing envelope	Any required equipment, airflow, water, residual-air, service or roadmap condition fails	Change the envelope or density; do not force a technology from kW alone

Rack kW is not a selector. The same density can support different systems when the named equipment heat split, airflow/inlet envelope, rack water, rear-door qualification, residual room heat, climate/rejection, redundancy, serviceability, or roadmap case changes.

Redundancy-topology selector

The live tool captures two useful requirements — concurrent maintainability and ride-through of one component fault — but fails closed on topology and cost. 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. Until that evidence closes, the tool does not select N, N+1, distributed-redundant, 2N, a Tier, or a premium. Carry the quantified state and workload consequences to Chapter 12.5.

Reliability topology design-basis requirements

Required project input	What must be specified before topology selection
Named maintenance and fault states	Enumerate each planned-maintenance isolation and unplanned-fault state by subsystem.
Exact affected path	Identify the source-to-load power, cooling, network, fuel, and control path affected in each state.
Transfer interruption	State whether transfer is open or closed transition and the maximum interruption at the protected load.
Post-event loading	Show surviving-path and component loading, including derating, overload duration, and reserve margin.
Path and control independence	Prove physical, electrical, mechanical, and control independence through the declared state.
Common-mode dependencies	Declare shared switchgear, controls, auxiliaries, fuel, water, rooms, routes, vendors, and operator actions.
Recovery SLO	Define detection, isolation, restart or failover, restoration, and return-to-normal deadlines.
Workload and contract consequence	Quantify lost work, degraded capacity, request or job impact, revenue loss, and contractual remedy for each state.

Concurrent-maintenance and single-component-fault choices remain useful requirement inputs, but they do not select N, N+1, distributed-redundant, 2N, a Tier, or a premium. Price candidate designs only after this evidence closes.

Project-finance model: the ratios that gate a deal

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. The output that matters is the sensitivity tornado, not a single IRR point estimate: which assumption — utilization, power price, GPU residual, depreciation life, contract tenor — moves the answer most. In the 2026 market, the dominant fork is contracted versus merchant, because it sets both the discount rate and the achievable gearing.

Project-finance terms and 2026-typical ranges

Term	What it measures	Contracted (offtake-backed)	Merchant (uncontracted)	Note
DSCR (min)	CFADS ÷ debt service — the coverage cushion	~1.20–1.45x	~1.75–2.00x	Revenue risk sets the floor; hyperscaler-grade leases compress it toward ~1.32x
Gearing (debt %)	Debt as share of capital stack	Higher (offtake supports leverage)	Lower (equity-heavy)	Contract quality directly enables debt capacity
Discount rate / WACC	Hurdle the cash flows must clear	Lower (investment-grade backstop)	Higher (price + offtake risk)	Bifurcation of cost of capital is the 2026 market inflection
Unlevered IRR / NPV	Project return before financing	Set by capex, utilization, price	Same drivers, wider band	The sensitivity tornado lives here
Levered IRR	Equity return after debt	Amplified by cheap, deep debt	Thinner debt → less amplification	The headline equity number; sensitive to rate and depreciation

Coverage and leverage ranges are 2026 practitioner figures; data-center debt is increasingly secured against contracted capacity, not unsecured corporate balance sheets. Sources: GreenBridge Infrastructure; Percepture AI Investor Playbook; Morgan Stanley / JPMorgan issuance estimates, 2026.

~$0.74/GPU-hr

TCO at 2048-GPU scale, 90% utilization; ~$1.03 small clusters (build-up cost, not rental) (contested — single-source)

2025SemiAnalysis, 'How much do GPU clusters really cost'register ↗

~$1.90/M tok

self-hosted inference (8x H100 @ ~$19.20/hr, Llama-70B FP16); market avg fell ~$10 → ~$2.50/M in a year

2025Spheron register ↗

30–40 kW typical RDHx; >50 kW with active fans; not a universal limit

SemiAnalysis/nVent cited RDHx range: 30–40 kW typical and >50 kW with active rear-door fans; verify the named door/rack and facility envelope

Feb 2025SemiAnalysis, Datacenter Anatomy Part 2 – Cooling Systems, 13 February 2025; RDHx discussion citing nVent register ↗

132 kW nominal TDP: 115 kW liquid + 17 kW air

NVIDIA GB200 NVL72 by HPE: 132 kW nominal rack TDP, with 115 kW liquid and 17 kW air heat-removal duties

2025HPE, NVIDIA GB200 NVL72 by HPE data sheet register ↗

PUE 1.05–1.15

direct-to-chip liquid design band (legacy air 1.4–1.6; two-phase immersion 1.01–1.10)

2025SemiAnalysis / Uptime Institute register ↗

~70%

breakeven utilization for a debt-financed neocloud cluster; below it the unit economics invert (contested — single-source)

2026AM Compute (2026; single-source unit-economics model)register ↗

1.20–2.00x

minimum DSCR band — ~1.20–1.45x contracted vs ~1.75–2.00x merchant

2026Transparency Analytics register ↗

~25–40% facility

capital premium for Tier IV (fault-tolerant) over Tier III (concurrently maintainable)

May 2024Savills register ↗

Assumptions that control the calculator results

Back-of-envelope models are only as honest as their assumptions:

TCO is straight-line. It amortizes capex evenly, allocates installed units to active units, and applies opex as a flat percentage. Owned-use utilization is the cost denominator; billable capacity factor is separate.
Token economics start from a guide assumption. Rented and owned $/M-token outputs use the same throughput and owned-use utilization. Replace throughput with a steady-state measurement from the same hardware, model, precision, context, batch/concurrency, latency target, and replica boundary. There is no sell-price or gross-margin model.
PUE and WUE are planning inputs. The tool annualizes IT load at 8,760 hours; it does not infer PUE/WUE from metered facility loads or model seasonal load/weather variation.
Cluster sizing separates quantities. Active GPUs follow workload demand; installed GPUs round up to the purchase quantum, and the stranded remainder is reported rather than absorbed.
Cooling is an envelope check. Rack kW is one input alongside the named liquid/residual heat split, qualified airflow/inlet and rear-door conditions, water availability, room residual capacity, climate/rejection, redundancy, serviceability, and the future density tail.
Reliability inputs are requirements only. The two outcome choices do not predict availability, select a topology, or supply a premium. The build-cost premium is an explicit local input from a priced, like-for-like project comparison.

The TCO, $/GPU-hr, and $/M-token economics are derived in full in Chapter 1.8, with the procurement fork they price in Chapter 1.6 and metric definitions in Chapter 0.3. The levered-IRR / project-finance model is the companion to Chapter 2.5; insurance and risk transfer sit alongside it in Chapter 2.6. The rack-cooling selection envelope is engineered in Chapter 5.1, product-qualified RDHx/AALC paths in Chapter 5.3, and DLC for profiles requiring source capture in Chapter 5.4. Fabric oversubscription (the networking-taxonomy companion) is in Chapter 8.5; inference serving economics in Chapter 10.11. The redundancy selector connects to the goodput-vs-availability rethink in Chapter 12.2 and the quantitative reliability model in Chapter 12.5. Efficiency metrics are in Chapter 15.1. Every figure on this page is dated and sourced in Appendix D.

Cite this chapter

Fehn, J. (2026). Decision Tables & Calculators (Chapter C). The Definitive Guide to AI Data Centers. https://aidatacenterguide.com/appendix-appendices-and-reference-data/c-decision-tables-and-calculators (accessed 2026-08-28).

@misc{aidc-C,
  author       = {Fehn, Jacob},
  title        = {Decision Tables & Calculators (Chapter C)},
  howpublished = {The Definitive Guide to AI Data Centers},
  year         = {2026},
  url          = {https://aidatacenterguide.com/appendix-appendices-and-reference-data/c-decision-tables-and-calculators},
  note         = {Accessed 2026-08-28}
}

Spotted an error? Suggest an edit