Appendix C
Decision Tables & Calculators
Most of the irreversible decisions in this guide reduce to a handful of arithmetic checks — cost per useful GPU-hour, cost per million tokens, the density that forces liquid, the redundancy tier the workload actually values, and whether a contracted cash flow can carry its debt. This appendix is the live calculator layer 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 the density→cooling verdict. They run entirely in your browser and nothing you type leaves the page.
- Use the static tables on this page for the numbers that do not change much: the density→cooling-cliff map (so you can read the whole curve at once, not one density at a time) and the redundancy-topology selector (which tier a workload justifies).
- 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.
- Sanity-check any single calculator result against the dated figures in Appendix D before you put it in a board deck — a back-of-envelope model is only as good as the vintage of the numbers you feed it.
This appendix is realized as a live, interactive tool in the site, not a wall of worked arithmetic. The four calculators — cluster TCO and cost per GPU-hour, inference cost per million tokens, PUE/WUE from measured loads, and the density→cooling-cliff verdict — 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 discipline these tools enforce is the one the rest of the guide keeps returning to: the expensive decisions are not opinions, they are checks. Is this rack density over the air-cooling cliff or under it? Does this workload value the nines a 2N plant buys, or is it checkpoint-tolerant and indifferent? 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 the arithmetic wrong at scoping time is how facilities end up mismatched to the revenue they were built to earn.
What each calculator computes
| Calculator | Inputs | Reads out | Key lever | Owning chapter |
|---|---|---|---|---|
| Cluster TCO & $/GPU-hr | GPU count, all-in $/GPU, kW/GPU, PUE, $/kWh, amortization yr, utilization %, opex % | All-in cost per useful GPU-hour + capex/energy/opex split | Utilization and amortization life (the depreciation lever) | Chapter 1.8 |
| Inference $/M-tokens | GPU $/hr, throughput (tok/s/GPU), sell price ($/M-tok) | Cost per million tokens + gross margin at your sell price | Throughput (tokens/sec/GPU) — batch, precision, model size | Chapter 10.11 |
| PUE / WUE | Total facility kW, IT/critical kW, annual water (m³) | PUE and WUE (L/kWh) from measured loads | Cooling modality (air vs liquid vs evaporative) | Chapter 15.1 |
| Density → cooling cliff | Rack density (kW/rack) | Which cooling modality the density forces | Rack density vs the ~41 kW air ceiling | Chapter 5.1 |
The two cost calculators chain together: the $/GPU-hr that falls out of the TCO model is the natural input to the inference token model. Run the cluster TCO first to get a defensible cost basis, then feed that figure (not a rental rate) into the $/M-tokens calculator to see whether your sell price actually clears margin. The PUE/WUE tool is the facility-efficiency counterpart — it takes the same kind of measured loads and returns the two metrics every operator is now reported on. The density tool is the fast pre-check: type your target rack density and it returns, in one line, whether that density commits you to liquid.
Density → cooling-cliff reference map
The single calculator answers one density at a time; this table is the whole curve, so you can see where your roadmap crosses each threshold. The cliff is a discontinuity, not a slope — air saturates near 41 kW/rack and there is no airflow trick that closes a 90 kW gap. The bands below mirror the live tool's verdict logic and the engineering in Chapter 5.1 (the density wall) and Chapter 5.4 (DLC).
| Rack density | Regime | Cooling modality | What it commits you to | Example hardware |
|---|---|---|---|---|
| < 15 kW | Comfortable air | Hot/cold-aisle containment | Raised floor or slab; CRAH/in-row; warm ASHRAE A1–A4 supply | Legacy enterprise / general compute |
| 15–40 kW | Air at the limit | Tuned containment, optional rear-door HX | Aggressive airflow management; RDHx as a bridge, no facility water at rack | HGX H100/B200 air-cooled (~40 kW) |
| 40–80 kW | The transition zone | RDHx / air-assisted liquid → DLC | Rear-door or AALC now; plan the path to direct-to-chip | Dense inference; bridge retrofits |
| 80–150 kW | Over the cliff | Direct-to-chip liquid (warm water) | Cold plates, in-rack manifolds, CDU, facility water loop, tight delta-T | GB200/GB300 NVL72 (~132–142 kW) |
| > 150 kW | Beyond air entirely | DLC mandatory + sidecar power | 800 VDC sidecar power; reinforced floor; immersion only in niches | Rubin VR200 (~190–230 kW); Kyber (~600 kW) |
Redundancy-topology selector
The second decision this appendix anchors is redundancy: how many nines the workload actually values, not how many the building can be made to deliver. Interruption tolerance is the lever. A synchronous training job already restarts from a checkpoint when any node fails, so spending on 2N facility power to prevent a restart is largely wasted; an always-on inference business breaches an SLA and loses revenue on every outage, so it justifies the premium. Use this selector to pick the tier the workload earns, then carry it to Chapter 12.2, which reframes the whole question as goodput versus facility availability.
| Topology | Availability (~hr/yr down) | Capital posture | Best-fit workload | Why |
|---|---|---|---|---|
| N (no redundancy) | Lowest | Cheapest | Batch inference; spot/curtailable training | Interruption-tolerant: queue-and-retry or checkpoint-and-resume absorbs failures |
| N+1 | Mid | Modest premium | Pre-training; post-training/RL | Checkpoint-tolerant jobs; spend the savings on goodput, not nines |
| 2N | High | Higher (redundant chain) | Online inference at scale; multi-tenant colo | No single point of failure; an outage is lost revenue and a breached SLO |
| Tier III (99.982%, ~1.6 hr) | ~1.6 hr/yr | Concurrently maintainable | Production inference; enterprise SLAs | Service any component without downtime; the common commercial baseline |
| Tier IV (99.995%, ~26 min) | ~26 min/yr | +20–40% over Tier III | Mission-critical, revenue-on-the-line serving | Fault-tolerant + concurrently maintainable; the maximum, rarely worth it for training |
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, with the DSCR (cash available for debt service ÷ debt service) sizing how much leverage the cash flow can carry. The output that matters is not a single IRR point estimate but the sensitivity tornado: 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.
| 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 |
Assumptions & caveats baked into the calculators
Back-of-envelope models are only as honest as their assumptions. The defaults here are deliberately simple, and a few simplifications matter:
- TCO is straight-line. The model amortizes capex evenly over the chosen life and applies opex as a flat percentage. It does not model GPU residual value, the depreciation debate (2–3 yr economic vs 5–6 yr book life), or financing cost — those live in the project-finance model and Chapter 1.8. Utilization is the single most sensitive input.
- Token economics assume steady-state throughput. The $/M-tokens figure is linear in tokens/sec/GPU, which is itself a function of model size, precision (FP16 vs FP8/FP4), batch size, and decode-vs-prefill mix. A reasoning model with long decode sequences will read very differently from the default. → Chapter 10.11.
- PUE/WUE are instantaneous, not annualized. The tool computes a point ratio from the loads you enter. Real reported PUE/WUE are annualized over a full climate cycle and move with outside-air temperature and load factor. → Chapter 15.1.
- The density verdict is a modality gate, not a full thermal design. It tells you which regime a density forces; it does not size CDUs, coolant flow, or delta-T. Those are engineered in Chapter 5.4.
- All figures are vintage-stamped. Hardware, pricing, and rates in 2026 move fast. Cross-check any load-bearing number against the dated register in Appendix D before you rely on it.