The Definitive Guide toAI Data Centers
Ask the GuideAboutAccount

Calculators

Open models for the numbers that decide an AI build — one project, worked end to end: size the cluster, price the build, cost the runtime, then see if the finance closes. The defaults describe a 100 MW GB300 campus, current as of 2026-09: each field says where its value comes from, and many trace to the numbers register. Start from a preset or change them to your case, then save, share a permalink, or export to CSV.

Shared starting assumptions
Connected fields: Cluster sizing — model → MW (19/19) · Build cost — $/MW capex (4/5) · Training run — cost & time (12/12) · Project finance — CFADS, DSCR & IRR (23/23) · GPU TCO & $/GPU-hour (14/14) · Inference $/M tokens (4/4) · Facility energy & water (5/5) · Rack cooling check (3/9) · Redundancy options (2/7). Independent: Site-scoring playbook (0/6; local judgment inputs).
Workload
Commercial boundary: the billable factor drives rental revenue (a take-or-pay reservation bills every reserved hour of every installed GPU in the rack, because the contract rents the whole rack; a merchant fleet bills only the active GPUs' hours it sells; stranded GPUs stay a cost in the unit-cost view); productive utilization drives owned/rented unit-cost comparisons. They are parallel analytical cases, not additive hour buckets or a hybrid allocation.
Hardware generation
1400 W · 288 GB HBM · 72/rack · 135 kW/rack · 2.5 PFLOPS dense · 72-GPU indivisible SKU minimum · on-demand list ~$18/GPU-hr (context only; revenue and comparators use the underwriting rate)
Performance profile: llama-3.3-70b · fp8 · 32,000 context · 64 batch/concurrency · guide assumption (11,200 tok/s); substitute a measured value from this exact profile
Facility & location
Financing & schedule
NVIDIA GB300 NVL7253,064 active / 53,064 installed GPUs · 0 stranded · 737 racks135 kW/rack · check cooling paths99.5 MW IT / 114.4 MW facility$6,268M program$5.63/active GPU-hr · $1.12/M tok owned at 70% productive utilization384,888 t CO₂/yr4% equity IRR · Misses your equity return hurdle
All assumptions are the guide defaults (as of 2026-09). Everything runs in your browser — the share link carries the scenario in the URL fragment (never sent to a server); only an explicit Save stores it to your account, versioned (v6).

Size it

Cluster sizing — model to megawatts

53,064 active / 53,064 installed GPUs · 114.4 MW at nominal TDP × PUE
VRAM per replica (weights 70 + KV 676 GB, +15% overhead)858 GB
Qualified GPUs per replica → replicas for demand (VRAM floor 3)8 × 6,633
Installed GPUs / stranded slots53,064 / 0
Installed racks (72/rack)737
Facility draw on installed units at nominal rack TDP × PUE (not the OEM facility-design provision or transient peak)114.42 MW
Rental cost on active GPUs at the underwriting rate$193,683,600/mo

The MW figure is for energy and cost, at nominal TDP. Electrical design uses your rack's facility design power and transient peak (GB300 NVL72: 135 kW nominal, up to 142 kW facility basis, 155 kW peak) — three different numbers, never interchangeable → Ch 7.2. VRAM sets only a minimum. Enter a replica size you have tested for your model, runtime, hardware, context and batch size; it need not be a power of two. Purchase quantum is the smallest unit you can buy or contract, and does not follow from rack density. Facility design power follows installed units, while rental cost follows the active fractional fleet. At long context the KV cache can dominate VRAM → Ch 9.7.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Model size70 B params
Bytes / param1 bytes
KV cache / token330 KB
Context length32000 tok
Concurrent requests / replica64 requests
Activation + framework overhead15 %
HBM per GPU288 GB
Peak demand50000 tok/s
Throughput / replica11200 tok/s
Serving capacity70 %
GPUs / replica8 GPUs
GPUs / rack72 GPUs
Purchase quantum72 GPUs
GPU TDP1400 W
Host overhead1.3393 × GPU TDP
PUE1.15 ratio
Underwriting rental rate18 $/GPU-hr

Illustrative purchase decision: assume a 70-billion-parameter model at one byte per parameter, 330 KB of KV cache per token, 32,000-token context, 64 concurrent requests and 15% framework overhead. Memory is (70 + 330 × 32,000 × 64 / 1,000,000) × 1.15 = about 858 GB per replica. Assume 288 GB per GPU and an eight-GPU replica you have tested: the three-GPU memory floor does not replace that qualification.

Assume 50,000 output tokens/s peak demand, 11,200 tokens/s per replica and 70% serving capacity. Round 50,000 / (11,200 × 0.70) up to seven replicas: 56 active GPUs. A 72-GPU purchase unit gives 72 installed GPUs, 16 stranded slots and one 72-GPU rack. At an assumed 135 kW nominal rack input and PUE 1.15, the nominal facility screen is about 155 kW. Fractional rental at an assumed $18/GPU-hour costs $1,008/hour for the active fleet.

Assume a $1,100/hour active-fleet rental allowance. The seven-replica case fits. Above 7 × 11,200 × 0.70 = 54,880 output tokens/s, demand needs an eighth replica: at 60,000 tokens/s, 64 active GPUs cost $1,152/hour and exceed the allowance, while the same 72-GPU purchase unit still fits. Acquire the exact serving qualification before committing the purchase.

Guide derivation. Method and handoff: Chapter 1.7 — The Requirements-and-Consequences Matrix.

Rack cooling check

Direct liquid + room air carries this 135 kW rack
Which cooling path carries the rack, today and at the roadmap rack
PathToday (135 kW)Roadmap (228 kW)
Air onlyNot applicable: 121.5 kW of this rack's heat must go to liquidNot applicable: 205.2 kW of this rack's heat must go to liquid
Air + rear doorNot applicable: 121.5 kW of this rack's heat must go to liquidNot applicable: 205.2 kW of this rack's heat must go to liquid
Direct liquid + room airWorks: liquid 121.5 kW, room 13.5 kW of its 20 kWFails: residual air 22.8 kW exceeds the room's 20 kW
Direct liquid + rear doorNot applicable: no rear door enteredNot applicable: no rear door entered
Heat to liquid / to room air, today121.5 / 13.5 kW
CDU flow for the liquid share at OCP's 1.25–2.0 L/min per kW152–243 L/min per rack
Coolant reaching the rack (facility water + CDU approach)35 °C against the rack's 45 °C limit
Roadmap rackNothing carries the 228 kW roadmap rack: residual air 22.8 kW exceeds the room's 20 kW

How this works: liquid heat is rack power times the liquid share, and the room's air takes the rest, through a rear door if you have one. The coolant reaching the rack is the facility water plus the CDU approach, and it must not be warmer than the rack allows → Ch 5.6. Flow uses OCP's PG25 guideline of 1.25–2.0 L/min per kW of liquid heat, which keeps the coolant rise near 7.5–12 °C → Ch 5.11. This is a screen: before you buy, get the rack maker's flow, pressure and fluid limits and check the room's airflow at the rack → Ch 5.4, Ch 5.3.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Rack power132 kW/rack
Heat captured to liquid87 % of rack heat
Room air capacity per rack20 kW/rack
Rear-door capacity0 kW/rack
Facility water to the CDU, hottest day30 °C
CDU approach5 K
Warmest coolant the rack accepts45 °C
Roadmap rack power132 kW/rack
Roadmap heat captured to liquid87 % of rack heat

Decide whether a GB200 NVL72-class rack fits this hall. Assume 132 kW per rack with 87% of the heat going to liquid (HPE's split), a room that can take 20 kW of air per rack, 30 °C facility water on the hottest day, a CDU with a 5 K approach and a rack that accepts coolant up to 45 °C. Liquid heat is 132 × 0.87 = 114.84 kW, and the room takes the other 17.16 kW, inside its 20 kW. The coolant reaches the rack at 30 + 5 = 35 °C, under the 45 °C limit, so direct liquid with room air works. At OCP's 1.25–2.0 L/min per kW, the CDU must deliver about 144–230 L/min to this rack.

Raise the hottest-day facility water to 41 °C: the coolant arrives at 46 °C and the liquid path fails. The crossover is 40 °C facility water at a 5 K approach; a CDU with a 3 K approach moves it to 42 °C. Get the rack maker's flow curve and pressure limits before you order.

Primary method: ASHRAE Handbook (2023), Applications ch. 20 — thermal paths and CDUs. Method and handoff: Chapter 5.6 — CDUs & the Secondary Loop.

Build it

Build cost — capex per megawatt

$1.66B excl. servers
Facility (shell, electrical, cooling, land)$1,174M
Network & cluster infrastructure$488M
Intensity, servers excluded$16.7/W

Benchmarks: JLL global-average shell/core ≈ $11.3M/MW (50 MW single-tenant, air-cooled; liquid +10%); Epoch's 1 GW model runs facility+land+utility ~$11.8M/MW and network ~$4.9M/MW, with servers ~$21.2M/MW on top → ~$38B/GW up-front. Electrical dominates the facility split → Ch 2.5, Ch 1.8.

Scope & how the benchmarks reconcile

This models construction-period capex excluding the server fleet. The benchmarks, reconciled on Epoch AI's May-2026 1 GW model: $11.3M/MW is JLL's global-average shell-and-core (air-cooled, 50 MW single-tenant; liquid cooling adds ~10%); Epoch's facility + land + utility works line is ~$11.8M/MW and its network and cluster infrastructure ~$4.9M/MW; servers — GPUs included — add ~$21.2M/MW, which is how a 1 GW campus reaches ~$38B up-front. Electrical systems are 45–70% of construction cost (as of 2026 → register). The server fleet is deliberately outside this calculator — the TCO model owns it, and adding it here would double-count.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
IT capacity10 MW
Facility, land & utility works10 $M/MW
Network & cluster infra (excl. servers)4 $M/MW
Project-priced facility premium20 %
Regional multiplier1.1 ×

Illustrative capital scope: assume 10 MW of usable IT capacity, facility/land/utility works at $10 million per MW, network infrastructure at $4 million per MW, a quoted 20% facility premium and a 1.10 regional factor. Facility cost is 10 × 10 × 1.20 × 1.10 = $132 million. Network cost is 10 × 4 × 1.10 = $44 million. The total is $176 million, or $17.60 per IT watt, excluding servers.

An illustrative $180 million allowance for those same two scopes passes with $4 million remaining. Raising only the facility premium to 25% raises the total to $181.5 million and fails. The topology drawing and supplier scope establish the premium; the reliability requirement buttons do not price it. Add the server purchase once in the shared program capital model.

The facility-premium crossover is 23.6%: (180 − 44) / (10 × 10 × 1.10) − 1. Above it, reduce scope or raise the same-scope capital allowance.

Guide derivation. Method and handoff: Chapter 2.5 — Project Finance & Capital Formation (Mechanics).

Site-scoring playbook

64 / 100 · Workable with mitigation

Kill gates come first: power or interconnect at ≤2, or water or land/zoning at ≤1, disqualifies a site no matter how the weighted score averages out. This is an illustrative weighting template: power availability carries the most weight, and the 0–10 scores are your judgment calls, so record the evidence behind each one. Adjust the weights and add a latency gate for inference workloads before ranking real candidates → Ch 3.13.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Power availability / speed-to-MW7 /10
Interconnect & permitting6 /10
Power price / PPA6 /10
Land & expandability7 /10
Water & climate6 /10
Incentives / tax5 /10

Decide whether candidate A merits the next diligence spend. Assume judgment scores of 7, 6, 6, 7, 6 and 5 for power, interconnect, price, land, water and incentives. The displayed rubric weights those axes 30%, 20%, 15%, 15%, 10% and 10%. These are an illustrative investment preference, not executed agreements or measurements. The weighted trace is (7×30 + 6×20 + 6×15 + 7×15 + 6×10 + 5×10) / 10 = 63.5/100: “Workable with mitigation.”

Advance A to evidence collection under this rubric; hold a site commitment until the service date, land rights, thermal/water design and workload latency are settled (Chapter 3.13). Change the power score to 2: the score becomes 48.5 and the power kill gate disqualifies A. The crossover is power ≤2, regardless of incentives. Reallocate diligence to a candidate with a viable power path.

Guide derivation. Method and handoff: Chapter 3.13 — Market Clusters & the Site-Scoring Playbook.

Redundancy options compared

3N/2 meets your requirements with the fewest modules: 6, 1.5× N

N = 800 kW ÷ 200 kW, rounded up = 4 modules.

Each option sized for this load
OptionModules× NLoad per moduleRides through a module failureService a module liveService a path liveSurvives losing a pathSurvives a failure during serviceModelled downtime
N41×100%nonononono140 h a year
N+151.25×80%yesyesnonono2.8 h a year
2N82×50%yesyesyesyesno2.2 h a year
2(N+1)102.5×40%yesyesyesyesyes3 s a year
3N/261.5×67%yesyesyesyesno1.7 h a year
4N/382×50%yesyesyesyesno3.3 h a year

Concurrent maintainability means you can service any module or path with the load held; it needs a second path, so N+1 on one shared path does not qualify (losing that bus drops the load) → Ch 0.5. Module count tracks equipment cost only: distribution, transfer switches and controls are extra, and 3N/2 and 4N/3 need more of them → Ch 12.1. The downtime column is a screening model: modules fail independently at your rate, each path or block has one repair crew, the paths share nothing and every transfer works. Shared buses, controls and common causes usually set real downtime, so read these hours as a floor → Ch 12.5.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Load to protect800 kW
Module size200 kW
Failures per module per year4.38 per yr
Repair time per failure8 h
Distribution paths for N and N+1one
Concurrent maintainability required?yes
Ride through one module failure?yes

Decide how much plant to buy for an 800 kW load from 200 kW modules when the owner wants both concurrent maintainability and ride-through of one module failure. N is 800 ÷ 200 = 4 modules. With one shared distribution path, N+1 rides through a module failure but cannot keep the load up while that path is serviced, so it fails the maintainability requirement. Of the options that meet both, 3N/2 needs the fewest modules: three blocks of two, 6 modules or 1.5× N, each module 67% loaded. 2N needs 8 and 2(N+1) needs 10. At Chapter 12.5's illustrative power-path rates (one failure per 2,000 hours, 8 h repair), 3N/2 models about 1.7 hours of downtime a year before shared causes.

Add a standby distribution path for maintenance: N+1 now meets both requirements with 5 modules, 1.25× N. The trade is a second path and its transfer equipment against one fewer module, so price both before you choose, and prove the transfer works in commissioning.

Guide derivation. Method and handoff: Chapter 0.5 — Reliability, Redundancy & Availability: The Design-Basis Primer.

Run it

Training run — time, cost, energy & CO₂

8.1 days · $9.7M rental
Compute (6·P·T)6.3×10²⁴ FLOPs
GPU-hours1.94M
Facility energy (incl. host + PUE)4,193 MWh (~$0.34M)
Emissions at 384 gCO₂/kWh1,610 t CO₂

MFU and goodput compound: a 40% MFU × 90% goodput scenario yields 36% of peak theoretical FLOPs as committed training work, by the definitions you use. Treat 90% versus 96% only as an illustrative sensitivity; measure your own fleet, job and time window, then find where the lost time went before blaming checkpointing or node cordoning → Ch 12.2.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Model size70 B params
Training tokens15 T tokens
Peak per GPU2.5 PFLOPS
Cluster size10000 GPUs
MFU40 %
Goodput90 %
Rental rate18 $/GPU-hr
GPU TDP1200 W
Host overhead1.5 × GPU TDP
PUE1.2 ratio
Power price0.08 $/kWh
Grid carbon400 gCO₂/kWh

Illustrative dense-model run: assume 70 billion parameters, 15 trillion training tokens, 10,000 GPUs at 2.5 dense PFLOPS each, 40% MFU and 90% goodput. Define MFU on productive compute time so goodput does not deduct the same lost time twice. Training work is 6 × 70 billion × 15 trillion = 6.3 × 10²⁴ FLOPs. Effective rate is 10,000 × 2.5 × 10¹⁵ × 0.40 × 0.90 = 9 × 10¹⁸ FLOP/s. The run takes 700,000 seconds, or 8.10 days and about 1.94 million GPU-hours.

At an assumed $18/GPU-hour, rental is $35 million. With assumed 1.2 kW GPU power, a 1.50 total-IT multiplier and PUE 1.20, constant-power energy is 4,200 MWh: $336,000 at $0.08/kWh and 1,680 tonnes at 400 gCO₂/kWh. Do not add electricity to rental when the rental already includes it.

The run passes an illustrative nine-day deadline. At 80% goodput it takes 9.11 days and fails. Change the training-work model for sparse or non-dense workloads; the screening formula does not qualify model placement or convergence.

The nine-day deadline requires at least 81.0% goodput: 6.3 × 10²⁴ / (10,000 × 2.5 × 10¹⁵ × 0.40 × 9 × 86,400). Below that, reserve more capacity or move the deadline.

Primary method: Kaplan et al. (2020), §2.1 — 6N training FLOPs per token. Method and handoff: Chapter 12.2 — The AI-Cluster Reliability Rethink: Goodput vs Facility Availability.

GPU TCO & cost-per-GPU-hour

$5.63 / active GPU-hr · server ownership, energy and facility charge
Annual cost / active GPU$34,543
· Capital recovery at 7.3%$21,350
· Energy$1,511
· Opex$6,944
· Facility charge$4,738
Owned vs contract rental, per calendar GPU-hr$3.94 vs $5: owning is 21% cheaper
Per productive GPU-hr at 70% use$5.63 owned vs $7.14 rented

A reserved contract bills every hour, used or not, so owning and renting are compared per calendar hour and utilization moves both by the same factor: it cannot flip the answer. What flips it is the contract rate, the server price, the life and the cost of capital. The facility charge and the cost of capital put space, power delivery and a return on the money into the owned cost, because a rental rate already includes all three; energy is billed separately at PUE. An on-demand list price is a different product and not this comparator → Ch 1.8.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Server cost240000 $
GPUs / server8 GPUs
Depreciation life3 yr
GPU TDP1000 W
Server power multiplier1 × GPU TDP
PUE1 ratio
Annual-average IT load100 % of nominal
Power price0.1142 $/kWh
Owned-use utilization50 %
Installed / active allocation1.25 ×
Opex5 %/yr
Facility / colocation charge0 $/kW-month
Cost of capital8 %/yr
Contract rental rate4 $/GPU-hr

Illustrative server-ownership decision: assume $30,000 per installed GPU recovered over three years at an 8% cost of capital, $1,000 annual energy, annual opex equal to 5% of purchase cost, and 1.25 installed GPUs per active GPU. The capital-recovery factor at 8% over three years is 0.3880, so capital costs 30,000 × 0.3880 = $11,641 a year. Annual cost per active GPU is (11,641 + 1,000 + 1,500) × 1.25 = $17,676, or $2.02 per calendar GPU-hour.

An assumed $4/hour contract rental bills every hour, used or not, so compare it per calendar hour: owning costs $2.02 against $4.00 and is about 50% cheaper. At 50% productive use both double per useful hour ($4.04 owned, $8.00 rented); utilization cannot flip the answer under a reserved contract. With the cost of capital at zero the capital line falls to $10,000 and owning looks cheaper still, which is why the rental side, which pays the lessor’s return, must be met by a return on the owned side. The facility charge is set to zero here to isolate the server; enter the facility’s capital recovery per kW-month for a full comparison.

At a $1.90 contract rate, renting is about 6% cheaper: $2.02 owned against $1.90. The contract rate, server price, life and cost of capital move the answer; productive use does not.

Guide derivation. Method and handoff: Chapter 1.8 — Business Models, Economics & ROI.

Inference cost per million tokens

$1.12 / M tokens owned · $1.42 rented
Owned capacity at 70% productive utilization$1.12/M tokens
Rented capacity at the same 70% productive utilization$1.42/M tokens

Compare ownership and rental on the same throughput and productive-use denominator. Owned node cost is the calendar-hour allocation of capex, energy, and opex; rented node cost is the capacity held for that hour. Ramp's token-price index fell from $1.15 to $0.68 per million tokens between March and September 2026 (Ramp AI Index, 9 Sep 2026), so underwrite inference revenue with a price-decline curve → Ch 1.8.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Rented node cost20 $/hr
Owned node calendar cost10 $/hr
Throughput1000 tok/s
Owned-use utilization50 %

Illustrative serving case: assume one tested node produces 1,000 useful output tokens/s within the declared latency target and runs productively 50% of each paid hour. Useful output is 1,000 × 3,600 × 0.50 = 1.8 million tokens/hour. Assumed rental of $20/hour costs $11.1 per million output tokens; an assumed owned calendar cost of $10/hour costs $5.56 per million.

Against an illustrative $6 per million output-token cost allowance, ownership passes and rented capacity fails. At 40% productive use the owned cost rises to $6.94 and also fails. Keep the model, precision, prompt/output mix, batching, latency target and cost boundary identical; prompt tokens and cached tokens do not silently enter this output denominator.

The owned case crosses the $6 allowance at 46.3% productive utilization: 10 / (1,000 × 3,600 × 6 / 1,000,000).

Guide derivation. Method and handoff: Chapter 1.8 — Business Models, Economics & ROI.

Facility energy & water

Average facility power114.4 MW
Annual energy1,002,313 MWh
Annual energy cost$80,185,010
Annual water348.6 M L

Annual energy uses nominal IT power × the average load you enter × energy-weighted PUE × 8,760. Site water uses IT energy × WUE. Cooling technology does not determine PUE; use plant curves and weather/load bins → Ch 15.1.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Nominal installed IT power10 MW
Annual-average IT load60 % of nominal
PUE1.2 ratio
Power price0.08 $/kWh
WUE0.4 L/kWh IT

Illustrative annual operating case: assume 10 MW nominal installed IT power, 60% annual-average load, energy-weighted PUE 1.20, electricity at $0.08/kWh and site-water WUE 0.40 L/kWh of IT energy. Average IT power is 6 MW; annual IT energy is 6 × 8,760 = 52,560 MWh. Facility energy is 63,072 MWh, costing $5,045,760. Site water is 52,560 × 1,000 × 0.40 = 21,024,000 litres.

Against an illustrative $5.2 million annual electricity allowance, this case passes with $154,240 remaining. The allowance crosses at 61.8% average load. Holding all other assumptions constant at 100% nominal operation raises electricity cost to $8,409,600 and fails that allowance. Productive utilization alone does not change either energy case; change the average-load assumption when the load study changes.

Guide derivation. Method and handoff: Chapter 15.1 — Efficiency Metrics: PUE, WUE, ERF, REF & the Post-PUE Metric Stack.

Fund it

Project finance — CFADS, DSCR, IRR

4% equity IRR

This is the guide's default project: a 99 MW campus of 737 NVIDIA GB300 NVL72 racks ($6.3B with the building), rented on a 5-year take-or-pay contract at $5/GPU-hour. Debt coverage stays at 1.59× or better against the 1.35× covenant. The equity return, 4%, is below the 10% hurdle. The server price drives it most: the default uses about $6.25M per rack, from one report citing anonymous sources, while Morgan Stanley puts the GB300 rack bill of materials near $4.0M. Try that, a 3-year contract or no contract from the presets in Project assumptions → Ch 1.8.

Misses your equity return hurdle. The fleet earns for 5 years over a 5-year hold.

Project (unlevered) IRR6.3%
Minimum DSCR during ownership1.59×
Average DSCR during ownership1.61×
Debt at COD (incl. $263M IDC)$4,024M
Equity funded (incl. $491M reserve)$2,998M
Project / equity NPV @ 10%−$594.07M / −$521.21M
Equity multiple1.17×

The model keeps the original fleet for the whole hold. Revenue is flat for the take-or-pay contract term; at renewal the fleet re-lets at the rate the revenue-growth trend has reached since the stabilized year. Sustaining spend is a cash cost and buys no replacement fleet; tax life only sets deductions. A refresh needs a separately funded second fleet. Exit proceeds are your exit multiple times final-year EBITDA, with remaining debt repaid at exit. Taxes use illustrative straight-line depreciation, an interest shield and a zero floor, with no NOL carryforwards or working-capital model. DSCR = CFADS ÷ scheduled interest and principal during ownership; exit debt payoff is shown separately. Loan covenants use their contract definitions. One entered rate discounts both project and equity cash flows. IDC uses a simple average-balance estimate allocated evenly across construction years → Ch 2.5, Ch 1.8.

Annual cash-flow bridge

−1,253.51,069.2close 0: −$490.677Mbuild 1: −$1,253.504Mbuild 2: −$1,253.504Mops 3: $624.194Mops 4: $613.908Mops 5: $602.903Mops 6: $591.127Mops 7: $1,069.204Mclose 0ops 3ops 7
Annual bridge ($M except DSCR). Cash flows include closing and exit; CSV retains unrounded values.
Lineclose 0build 1build 2ops 3ops 4ops 5ops 6ops 7
Capital expenditure03,133.7613,133.761—————
Debt drawn for capex01,880.2571,880.257—————
IDC capitalized (average-balance allocation)0131.618131.618—————
Equity funding01,253.5041,253.504—————
Reserve funding490.67700—————
Revenue———2,324.2032,324.2032,324.2032,324.2032,324.203
Operating cost———564.872564.872564.872564.872564.872
EBITDA———1,759.3321,759.3321,759.3321,759.3321,759.332
Tax depreciation———1,077.3981,077.3981,077.3981,077.3981,077.398
Levered cash tax———84.05794.342105.348117.124129.724
Unlevered cash tax———143.206143.206143.206143.206143.206
Sustaining capital expenditure———69.72669.72669.72669.72669.726
Cash available for debt service———1,605.5491,595.2631,584.2581,572.4821,559.882
Interest———281.662232.684180.277124.20264.201
Principal———699.692748.671801.078857.153917.154
Debt service———981.355981.355981.355981.355981.355
Debt before exit payoff02,011.8744,023.7493,324.0562,575.3851,774.308917.1540
DSCR (ratio)———1.6361.6261.6141.6021.59
Operating equity cash flow———624.194613.908602.903591.127578.527
Enterprise exit proceeds———00000
Exit debt payoff———00000
Reserve released———0000490.677
Project cash flow0−3,133.761−3,133.7611,546.3991,546.3991,546.3991,546.3991,546.399
Equity cash flow−490.677−1,253.504−1,253.504624.194613.908602.903591.1271,069.204
Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Total capex100 $M
Construction period0 yr
Debt / leverage50 %
Interest rate0 %
Debt term4 yr
Revenue (stabilized)40 $M/yr
Ramp to stabilized0 yr
Revenue-linked opex25 % of rev
Cash tax rate20 %
Tax life — building and plant3.5 yr
Sustaining capex0 % of rev
Revenue growth0 %/yr
Hold period4 yr
Exit multiple0 × EBITDA
NPV discount rate / equity hurdle10 %
DSRA0 mo
Grace period0 yr
Fleet earning period4 yr
Lender's minimum DSCR1.5 ×

Illustrative retained-fleet case, all amounts in $M: assume capex 100, immediate operation, debt 50 at zero interest amortized over four years, revenue 40/year, opex 25% of revenue, cash tax 20%, tax depreciation over 3.5 years, no sustaining spend, no growth, four-year hold, zero exit proceeds and no reserve. Assume the original fleet supports all four earning years. These tax and earning periods are independent assumptions.

Closing equity is 50. Annual EBITDA is 30. Tax depreciation is 28.5714 in years 1–3 and 14.2857 in year 4, totaling 100. Cash tax is 0.2857 in years 1–3 and 3.1429 in year 4. Annual principal is 12.5; minimum DSCR is 26.8571 / 12.5 = about 2.15. Equity cash flow is 17.2143 in years 1–3 and 14.3571 in year 4. At a 10% hurdle, equity NPV is −50 + Σ[17.2143 / 1.1ᵗ, t=1…3] + 14.3571 / 1.1⁴ = about 2.62.

The case passes the assumed 1.50 covenant and positive-NPV hurdle. A covenant of 2.20 fails. Without an earning period the return is not decided; a tax depreciation schedule does not supply that evidence. The bridge shows the complete annual lines, including zero terminal proceeds.

Primary method: Microsoft NPV — end-of-period cash flows and initial investment. Method and handoff: Chapter 2.5 — Project Finance & Capital Formation (Mechanics).

Then turn the sizing into dates: the lead-time planner reverse-schedules every long-lead PO from your ready-for-service target.