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. Defaults trace to the numbers register (current as of 2026-08); 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 (20/20) · GPU TCO & $/GPU-hour (13/13) · 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 NVL7256 active / 72 installed GPUs · 16 stranded · 1 racks135 kW/rack · check cooling paths0.14 MW IT / 0.16 MW facility$9M program$6.11/active GPU-hr · $1.21/M tok owned at 70% productive utilization522 t CO₂/yr−13.6% equity IRR · Fails your debt covenant
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 (v5).

Size it

Cluster sizing — model to megawatts

56 active / 72 installed GPUs · 0.16 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 × 7
Installed GPUs / stranded slots72 / 16
Installed racks (72/rack)1
Facility draw on installed units at nominal rack TDP × PUE (not the OEM facility-design provision or transient peak)0.16 MW
Rental cost on active GPUs at the underwriting rate$204,400/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

$2.25M excl. servers
Facility (shell, electrical, cooling, land)$1.59M
Network & cluster infrastructure$0.66M
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

$6.11 / active GPU-hr · server ownership, energy and facility charge
Annual cost / active GPU$37,450
· Depreciation$22,320
· Energy$1,943
· Opex$8,928
· Facility charge$4,259
· Installed-to-active allocation1.286× across all four cost lines
Breakeven utilization vs contract rental86%

The facility charge puts space and power delivery into the owned cost, so it compares like-for-like with a rental rate that already includes them; energy is billed separately at PUE. Compare against the contract rate you would actually sign, not an on-demand list price. Ownership beats that rate only above the breakeven utilization computed from your own inputs — below it a debt-financed cluster bleeds cash → 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
Contract rental comparator4 $/GPU-hr

Illustrative server-ownership decision: assume $30,000 per installed GPU, three-year straight-line cost allocation, $1,000 annual energy, annual opex equal to 5% of purchase cost, and 1.25 installed GPUs per active GPU. Annual cost per active GPU is (30,000 / 3 + 1,000 + 1,500) × 1.25 = $15,625. At 50% productive use, divide by 4,380 hours: $3.57 per productive GPU-hour.

An assumed like-for-like $4/hour rental crosses that cost at 15,625 / (8,760 × 4) = 44.6% utilization. Above that utilization ownership is cheaper on these costs; below it rental is. With all other inputs fixed, five- and seven-year ownership lives reduce the result to $2.43 and $1.94/hour. These are life sensitivities, not evidence that the fleet earns for those periods. The facility charge is set to zero here to isolate the server; a rental rate includes powered, cooled space, so enter the facility's capital recovery per kW-month and reconcile services outside either quote before making a full-service purchase decision.

At 40% productive use, ownership costs $4.46 per productive GPU-hour and the assumed $4 rental wins. Change productive use, not the independent electrical-load assumption.

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

Inference cost per million tokens

$1.21 / M tokens owned · $1.42 rented
Owned capacity at 70% productive utilization$1.21/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. Prices enterprises paid for tokens fell ~$10 → ~$2.50/M in a year (Ramp spend data, Mar 2025), 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 power0.16 MW
Annual energy1,360 MWh
Annual energy cost$108,799
Annual water0.5 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

−13.6% equity IRR

This is the guide's default project, and on these inputs it loses money. One NVIDIA GB300 NVL72 rack ($8.5M with its share of the building) is rented on a 3-year take-or-pay contract at $5/GPU-hour, then re-let at the market rate, which the default assumes falls 15% a year. Debt coverage is 1.55× or better while the contract runs, then falls below the 1.35× covenant in year 4, after renewal. That is the result of the sourced default inputs, not an error. To see what makes the deal work, try a longer contract (hyperscaler anchor contracts run about 5 years), a higher rate or a lower server price → Ch 1.8.

Fails your debt covenant. The fleet earns for 5 years over a 5-year hold.

Project (unlevered) IRR−1.2%
Minimum DSCR during ownership0.87×
Average DSCR during ownership1.32×
Debt at COD (incl. $0.18M IDC)$5.28M
Equity funded (incl. $0.64M reserve)$4.05M
Project / equity NPV @ 10%−$1.91M / −$1.81M
Equity multiple0.66×

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

−3.40.7close 0: −$0.644Mbuild 1: −$3.402Mops 2: $0.742Mops 3: $0.729Mops 4: $0.714Mops 5: $0.014Mops 6: $0.478Mclose 0ops 3ops 6
Annual bridge ($M except DSCR). Cash flows include closing and exit; CSV retains unrounded values.
Lineclose 0build 1ops 2ops 3ops 4ops 5ops 6
Capital expenditure08.504—————
Debt drawn for capex05.102—————
IDC capitalized (average-balance allocation)00.179—————
Equity funding03.402—————
Reserve funding0.6440—————
Revenue——3.1543.1543.1541.9371.646
Operating cost——0.7880.7880.7880.4840.412
EBITDA——2.3652.3652.3651.4531.235
Tax depreciation——0.850.850.850.850.85
Levered cash tax——0.240.2540.2680.0920.063
Unlevered cash tax——0.3180.3180.3180.1260.081
Sustaining capital expenditure——0.0950.0950.0950.0580.049
Cash available for debt service——2.032.0172.0021.3021.122
Interest——0.370.3050.2370.1630.084
Principal——0.9180.9831.0511.1251.204
Debt service——1.2881.2881.2881.2881.288
Debt before exit payoff05.2814.3633.382.3291.2040
DSCR (ratio)——1.5761.5661.5541.0110.871
Operating equity cash flow——0.7420.7290.7140.014−0.166
Enterprise exit proceeds——00000
Exit debt payoff——00000
Reserve released——00000.644
Project cash flow0−8.5041.9521.9521.9521.2681.105
Equity cash flow−0.644−3.4020.7420.7290.7140.0140.478
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
Opex25 % of rev
Cash tax rate20 %
Tax depreciation life3.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.