Chapter 5.66 of 9 in this part

Capacity planning and forecasting

Forecasting dollars for AI is forecasting a moving target. Forecast capacity instead — and note that a commitment discount is really a utilisation threshold. At AWS's published 62.4% three-year discount, the committed rate is 37.6% of on-demand, so the machine has to be busy 37.6% of the time to break even.

6 min read·revised 2026-08-11

Most capacity plans for AI workloads are built in dollars, and dollars are the one quantity in this book that will not hold still. Every price in what an H100 hour costs has a capture date on it for exactly that reason. A twelve-month spend forecast built on today's rates is a forecast of two things at once — how much you will use, and what it will cost — and when it misses you cannot tell which half was wrong.

The fix is not a better model. It is a change of unit.

Forecast capacity, price it separately

Forecast in the units the workload actually consumes: GPU-hours by instance family, tokens per day by model tier, requests at peak concurrency, terabytes egressed. Then apply prices as a separate, dated layer on top.

This costs nothing and buys two things:

  1. A miss becomes diagnosable. Demand up 40% against a flat forecast is a product problem. Demand flat against a bill up 40% is a pricing or efficiency problem. One number conflates them; two numbers separate them.
  2. A price change becomes a re-run, not a re-forecast. When a vendor cuts rates — or you land the commitment below — you re-price the same capacity curve instead of rebuilding the plan.

The capacity layer is also the only layer you can act on. You cannot negotiate demand.

The number that actually decides the plan

Here is the part most plans get backwards. A commitment discount looks like a price decision. It is a utilisation decision, and the threshold is arithmetic you can do before any forecast exists.

From commitment maths: a p5.48xlarge is $55.04/hour on-demand in us-east-1, and the three-year All Upfront Savings Plan discount is 62.4%. So the committed rate is:

$55.04 × (1 − 0.624) = $20.69504/hour

Which means the committed rate is exactly 37.6% of the on-demand rate. And that gives the only capacity-planning number that matters at commitment time:

You must keep that capacity busy at least 37.6% of the hours you have committed to, or you would have been better off paying on-demand.

Not 80%. Not "high utilisation." 37.6% — for this instance, at this discount, on this term. The threshold is just the committed rate divided by the on-demand rate, so it moves with the discount: a smaller discount raises the bar, a larger one lowers it. Every row in the commitment-maths table has its own threshold, and it is one division away.

This reframes the conversation usefully. "Should we commit?" is unanswerable in the abstract. "Will this be busy more than 37.6% of the time for three years?" is a question an engineering team can actually argue about — and one where the honest answer is often "for year one, easily; for year three, we have no idea."

Which is the real argument for shorter terms and partial coverage, and it is an argument from arithmetic rather than from caution.

Three properties of AI demand that break the usual forecast

Traditional capacity planning assumes demand grows smoothly and hardware is fungible. Neither holds well here, and these are the failure modes worth planning around. This section is judgment drawn from the mechanics established earlier in the book, not measurement.

Demand is stepwise, not smooth. Inference load tracks feature launches and customer onboardings, which land discretely. A curve fitted to the last six months will miss the step, and the step is the thing that breaks you.

Unit cost falls under you, and unevenly. Everything in the cost levers, ranked is a lever that lowers cost per unit of the same demand. A forecast that assumes today's efficiency will overstate spend if the team ships quantization or better batching — and a team that has been promised a budget based on that forecast has just been handed a reason not to bother.

Capacity is not always purchasable at the moment you want it. Accelerator supply is quota- and allocation-gated in ways commodity CPU is not. The relevant planning variable is therefore lead time, not just cost: how long between deciding you need more and being able to run on it. Measure yours by observing it — it is a property of your account and your vendor, and no published figure substitutes for what you actually experienced last time you asked.

What a usable plan contains

A capacity plan that survives contact with a real quarter has four parts and fits on a page:

Component What it says Where it comes from
Capacity curve Units per month, by family Measured demand, plus known launches
Utilisation floor The break-even threshold per commitment Committed rate ÷ on-demand rate
Coverage split What share is committed vs on-demand vs spot The confidence you have in the trough
Lead time How long new capacity takes to land Your own observed history

Note what is absent: a single monthly dollar figure presented to two decimal places. That number will be produced by finance from the capacity curve and a price sheet, and it should be labelled with the date of the prices it used.

Cover the trough, not the peak

The coverage split is where the arithmetic above pays off. Commitments are cheapest when they are certainly used, and the only part of your demand that is certain is the part that never goes away.

So commit to the trough — the floor your usage does not fall below — and serve the peak from on-demand and spot. A commitment sized to the peak spends the year below its break-even threshold on the hours the peak is not there, which is most of them.

This is the same insight as the 37.6%, viewed from the other end: the question is never "how much do we use," it is "how much do we use at the quietest hour of the quietest week." Most teams have never measured that, and it is usually the single most valuable number a capacity exercise produces.

The honest limit of this chapter

The break-even arithmetic is exact and checkable — it is division on two figures this book has already sourced, and a verification script recomputes it. The demand-shape claims, the four-part plan, and the trough-coverage rule are judgment, not measurements. No vendor publishes data on forecast accuracy for AI workloads, and this book will not invent a figure for how often plans miss or by how much.

What survives without any of that judgment is the part worth carrying: a commitment discount is a utilisation threshold in disguise, and you can compute yours before you forecast anything.

Sources & methodcaptured 2026-08-11

Sources, captured 2026-08-11: rates and the 62.4% three-year All Upfront discount for p5.48xlarge are carried from commitment maths, where they are sourced from AWS's own price-list feeds (us-east-1, Linux, shared tenancy, captured 2026-08-08). The committed rate of $20.69504/hour, the 37.6% ratio, and the break-even threshold are computed by this book from those two published figures — $55.04 × (1 − 0.624), and $20.69504 ÷ $55.04 — and are verified independently in scripts/verify-capacity-planning.mjs against both derivation paths. The demand-shape observations, the plan structure, the lead-time guidance, and the trough-coverage rule are editorial judgment and are labelled as such in the text. No figure is asserted for forecast accuracy, for typical utilisation, or for lead times, because none is sourceable.

Want this done on your account rather than by you?

The handbook is the method, written out in full so you can run it yourself — that is the point of publishing it. If you would rather someone else did the first pass, the teardown is free and you keep the findings either way.