28 — Value: rent vs own, $/Mtok, joules per token, and what the corpus can actually rank

The value: wave left its findings in gotcha records, where each one answers one narrow question. Read together they say something none says alone: most "which is the best value" questions are not answerable from this corpus yet, and the ones that are answerable are dominated by join rules, not by hardware. This doc is the map.

0. The short form

question	answer in the corpus	record
cheapest $/Mtok to rent, by model class	answerable within the aggregate (batched) population only	The corpus prices 221 cloud rows but only one is a per-user figure, so the two populations cannot be compared - and spot is 35-43% off while capacity-block is 49% MORE than on-demand
is spot a budget number?	no — the headline discount is a ceiling, and spot is excluded from committed-use discounts	'Up to 90-91% off' is a ceiling across all SKUs, the published grid is a regional floor, and spot is explicitly excluded from committed-use discounts - so no blended spot rate exists
what does owning cost over three years?	computable; electricity is a minor line	Owned-hardware TCO is computable and electricity is only 8-20% of it over three years; rent-vs-own break-even is NOT computable, because no accelerator in this corpus has both a priced rental row and a local decode benchmark
rent vs own break-even	not computable — no accelerator has both a priced rental row and a batch-matched local benchmark	same record
cheapest usable VRAM	only five accelerators can be ranked at all, and the ranking is dominated by which model each was measured on	Cheapest-per-GB VRAM is not value: two join artifacts produced a 60x and an 80x false ranking, and the real answer is that only five accelerators in this corpus can be ranked at all
joules per token	4.11 to 20.53 J/tok on comparable single-device batch-1 rows	Joules per token across the corpus spans 4.11 to 20.53 on comparable batch-1 rows, but three rows had to be excluded - an unsourced figure, three multi-GPU runs charging one card's TDP, and a batch-2048 row whose real batch is 16x larger than batch 1
should I buy at all?	a genuine community split, settled by usage pattern and data control, not by $/token	Genuinely divided, recorded as a split: whether to buy inference hardware at all is settled only by usage pattern, and price-per-token arguments are explicitly rejected by the local-hardware camp

1. Renting: the price is not one number

The cost tool (08-cost-per-token.md, tools/cost_per_token.py) joins supply prices to benchmark throughput. Before trusting any row, four traps apply:

Shape. The same GPU differs about 2x per-GPU between an 8-GPU and a 1-GPU shape; record the per-GPU rate, the shape's GPU count and the node rate it came from (A per-GPU-hour rate is not a comparable number until you also know which instance shape it came from - the same GPU differs 2x per-GPU between an 8-GPU and a 1-GPU shape).
Tier. Spot ran 34.9% under on-demand on H100 SXM and 43.0% under on H200 SXM, while capacity-block cost 148.7% / 149.6% of on-demand — capacity-block buys reserved capacity, not cheaper tokens (The corpus prices 221 cloud rows but only one is a per-user figure, so the two populations cannot be compared - and spot is 35-43% off while capacity-block is 49% MORE than on-demand).
Token-API tiers. One provider's own page shows up to 8x between tiers and context bands for the same model; store provider, model version, tier, context band, cache state and date (Quoting a per-token API price without naming the tier and the context band is meaningless - the same model and the same tokens differ by up to 8x on one provider's own page).
The bill beside the GPU. An Azure Ultra disk at 28,000 GiB is about $4.59/h, 37% of the $12.29 H100-hour it is attached to (An Azure Ultra managed disk at 28,000 GiB costs about $4.59/hour - 37% of the $12.29 H100-hour it is attached to, so a durable-disk inference node is never priced by its GPU rate).

And one population trap: of the cloud rows the tool prices, only one is a per-user figure; the rest are batched aggregates. The two cannot be ranked against each other (The corpus prices 221 cloud rows but only one is a per-user figure, so the two populations cannot be compared - and spot is 35-43% off while capacity-block is 49% MORE than on-demand). Where the price itself comes from matters too: vendor rate tables are often JavaScript-rendered, so the pricing API is the only reproducible surface (The provider's marketing page is static HTML but its actual rate table is JavaScript-rendered or JSON-only - the API is the only reproducible surface, and the table is the only one that goes stale silently).

2. Owning: capex dominates

The TCO model in Owned-hardware TCO is computable and electricity is only 8-20% of it over three years; rent-vs-own break-even is NOT computable, because no accelerator in this corpus has both a priced rental row and a local decode benchmark uses the cheapest non-cloud supply record per card, electricity at $0.0891/kWh from Cost to RUN, not to buy: US average industrial electricity price, 8.91 cents/kWh trailing-12-months to July 2026 (EIA Electric Power Monthly Table 5.3); 8.13 was the CY2024 figure, card TDP plus a stated 120 W host allowance, and a 3-year horizon. Its conclusion: electricity is 15-20% of three-year cost for the ~$2,000 cards and under 5% for the $12,000-and-up cards, and a 450 W vs 300 W card differs by about $76/yr at 30% load. Power decides thermals, noise and circuit capacity, not value.

3. Energy: comparable rows are rare

The joules-per-token record keeps only single-device, batch-1, sourced rows — nine of them — and excludes an unsourced figure, multi-GPU runs charged against one card's TDP, and a batch-2048 row (Joules per token across the corpus spans 4.11 to 20.53 on comparable batch-1 rows, but three rows had to be excluded - an unsourced figure, three multi-GPU runs charging one card's TDP, and a batch-2048 row whose real batch is 16x larger than batch 1). No vendor publishes J/tok, and TDP-based estimates carry a 30-50% error (No vendor publishes joules-per-token for inference: the only way to get it is to measure it yourself or estimate from TDP and throughput, and the estimation error is 30-50% because TDP is a thermal ceiling not a power measurement and throughput depends on batch size, sequence length and model).

4. The join rules that make any of this valid

From Cheapest-per-GB VRAM is not value: two join artifacts produced a 60x and an 80x false ranking, and the real answer is that only five accelerators in this corpus can be ranked at all, after two join artefacts produced 60x and 80x false rankings:

Rule A — a supply price attaches to the item its price_basis names, not to every accelerator the page mentions.
Rule B — a per-card tok/s is the denominator of every value figure; a cluster, RPC or multi-host figure must not be filed under one card's accelerator_ids.

The cost tool's own rule is the same idea for GPU counts: a divisor must appear verbatim in the benchmark's unit or methodology (check_evidence(), see 26-known-defects.md D2).

5. What the records cannot answer

Rent-vs-own break-even. Needs one same-accelerator pair — a priced cloud row and a batch-matched local benchmark — or an explicit aggregate-to-per-user conversion. Neither exists (Owned-hardware TCO is computable and electricity is only 8-20% of it over three years; rent-vs-own break-even is NOT computable, because no accelerator in this corpus has both a priced rental row and a local decode benchmark). This is the single highest-value benchmark to add.
Local value ranking across models. The five rankable accelerators (eight rows) were each measured on different models, so cross-card comparison is not a value finding. The table itself now lives in Cheapest-per-GB VRAM is not value: two join artifacts produced a 60x and an 80x false ranking, and the real answer is that only five accelerators in this corpus can be ranked at all with the unit stated correctly — dollars per 1000 tok/s of decode throughput, lower is better — after the "tok/s per $1000" mislabel recorded in 26-known-defects.md was fixed on 2026-10-12, along with the over-attributed prices the table still quoted.