Build, buy, or rent - and who wrote the answer

The commonly cited break-even for owning GPUs rather than renting them is 50-70% sustained utilization. If your fleet runs above that band year-round, ownership wins; below it, rent. It is a clean rule, it is easy to remember, and every source we could find for it is a vendor.

That does not make it false. Vendors have the best telemetry in the industry and a real interest in being right about capacity. But it means the number is directional, not measurement. Treat it the way you would treat a supplier's own estimate of how much you should buy from them: useful input, not evidence.

Two practical consequences for you in a steering meeting:

• When someone puts a break-even threshold on a slide, ask for the source. If the answer is a vendor blog, the slide is a starting hypothesis, not a finding.
• Ask what utilization your organization actually sustains today, measured, not planned. Almost nobody knows, and that ignorance is usually the real decision blocker rather than the threshold itself.

Here is the single most useful thing in this session. Vendor break-even thresholds are almost always quoted against on-demand rental rates - the most expensive way anyone actually buys GPU capacity. Nobody running a sustained fleet pays on-demand for a year.

Re-run the same comparison against a committed rate and the ownership case degrades sharply. AWS's own Savings Plan feed (fetched 2026-08-07) prices p5.48xlarge at 3-year all-upfront as $2.587 per GPU-hour, against an on-demand rate of $6.88. That is a 62% reduction, and it applies to exactly the steady, high-utilization workload that ownership models are built to justify.

The point is not that reserved instances always win. The point is that almost no vendor analysis runs that comparison at all, and the omission is the tell. If someone shows you a build case and the rental column says on-demand, they have compared your best-case ownership scenario against the buyer's worst-case rental scenario.

The closest thing to an independent build-side number in circulation comes from SemiAnalysis, which prices a 1,024-GPU H100 cluster at roughly $35,375 to $39,750 of capex per GPU, all-in including network. Treat it as the best available anchor with a stated caveat: SemiAnalysis sells research to the industry it covers, which makes it independent-ish rather than independent.

Use it the way an auditor would use a comparable: as a sanity check on whatever number your own procurement process produces. If a build proposal lands far under that range, ask what has been left out of it - network fabric, power, cooling, and facility work are the usual omissions, and layer six of the stack is where they hide.

Two structural costs that rarely appear in a first-pass build case, both covered in detail in a4: per-installed-GPU software licensing, and the physical envelope. A DGX B300 draws roughly 14 kW in 10U. The facility constrains you long before the budget does, and facility work is a capital programme with its own timeline.

Read the middle two rows of that table together, because they are the whole lesson. In 2025, under the same generation of accelerators, in the same market, with roughly comparable engineering sophistication, Amazon shortened its useful-life estimate on a subset of equipment from six years to five, taking a $700M cut to operating income - and Meta extended its estimate.

Both disclosures are public and both are defensible. That is exactly why it matters. It is proof, from the two organizations best placed to know, that useful life is management judgement, not a physical constant. There is no correct answer waiting to be discovered by better analysis.

So the question in your own model is not "what is the right depreciation schedule?" It is:

• What schedule is this model using, and who chose it?
• What does the recommendation look like at both ends of the published range - three years and six?
• If the answer flips somewhere inside that range, the decision is being made by an accounting assumption rather than by an operational fact, and it should be escalated as such.

We are deliberately not settling this. A course that told you "use five years" would be adding a tenth captured source to a literature of nine.

Two of the six positions in the table come from parties with an obvious financial stake in the direction of their own argument. Nvidia, arguing four to six years, sells the hardware. Michael Burry, arguing two to three, held around $1.1B notional in put options while making the case.

The lazy move is to discard both. The better move is to notice that they bracket the range, and that the operators sitting inside that bracket - Nebius at four, Amazon at five, CoreWeave at six - land closer to each other than to either advocate. When interested parties on opposite sides define the outer bounds and disinterested-ish operators cluster in the middle, the middle is where your sensitivity analysis should live.

Carry the habit across to vendor selection generally. "Who benefits if I believe this?" is not cynicism, it is the same diligence you already apply to a supplier's delivery estimate.

The 95% number has been laundered into a permanent statistic in roughly twelve months, which is exactly how "85% of big data projects fail" happened a decade ago. This course refuses to cite that one at all, and the way to avoid repeating the mistake with NANDA is mechanical: state the sample size in the same breath as the number, every single time.

Say it like this: "MIT's NANDA study, which is 52 executive interviews, 153 leader surveys and 300 public deployments, found 95% of pilots showed no measurable P&L return." It takes four extra seconds and it does two things at once. It keeps you honest, and it signals to everyone in the room that you read the methodology - which is a more useful reputation than being the person with the scariest slide.

The buy-versus-build split deserves the same treatment, and it is the more actionable of the two findings. A roughly 67% success rate for specialist-vendor purchases against roughly one third of that for internal builds is a base rate. It is not a prohibition.

Build proposals fail in review for one of two reasons: the sponsor has never heard the base rate, or the sponsor has heard it and cannot articulate why this build is different. The first is fixable in a meeting. The second is the actual work.

Specific reasons a build can beat the base rate, each of which is checkable:

• No vendor fills the layer. Genuinely novel requirements exist. Most are not, but some are, and this is the strongest ground.
• The chokepoint must be yours. If a layer's narrow waist determines your regulatory position or your negotiating power, owning it is a strategic decision rather than a cost decision, and it should be argued that way.
• The economics genuinely invert at your volume. Provable with your own billing data, not with a vendor model.
• You already run and staff the capability. A team that has operated this class of system before is the single strongest predictor available.

If none of those four apply, you are betting against a published base rate with nothing specific to point at. That is worth knowing before the money is committed rather than eighteen months after.

The nine TCO analyses conclude "rent," meaning rent compute. The NANDA finding is about "buy," meaning purchase a finished capability from a specialist vendor. These get collapsed in conversation and they are different decisions on different layers.

Renting compute is a decision about layer six: capacity, utilization, and depreciation. Buying a capability is a decision about layers five, seven and eight: whether your organization builds the semantic layer, the gateway and the self-serve experience itself, or purchases products that fill those jobs. It is entirely coherent to rent all your compute and build your own semantic layer, or to own a GPU fleet and buy every application on top of it.

Session a6 turns this into a layer-by-layer sequencing decision. For now, hold the distinction: rent-versus-own is about the metal, buy-versus-build is about the capability, and the evidence bases for the two are completely separate.