Intel Layer — Forward Pricing Ladder

GPU forward pricing as a 1m / 3m / 6m / 12m ladder across B200, H200, H100, and A100.

Spot tells you what a GPU hour costs right now. Forward pricing tells you what the market — or a given provider — implies about what that hour will cost at the 1-month, 3-month, 6-month, and 12-month horizon. This page lays both signals side-by-side as an explicit four-row ladder so procurement and finance teams can sanity-check reservation and capital plans against last-verified DB rows.

Two data conventions on one ladder

Most buyers who think about forward prices for compute start with the prediction-market signal — Kalshi-listed GPU contracts — and stop there. That signal is useful but not enough: prediction markets imply a market-clearing rate, not a rate any provider will actually quote you. We pair the Kalshi-derived mid with provider-native forward quotes (hourly rates a provider publishes for a 1m, 3m, 6m, or 12m commit) so the same ladder shows both signals.

Both layers render under the same explicit as-of stamp. Provider rows only appear if a row in provider_forward_pricing has verified_at set; otherwise the cell reads data pending instead of inventing a number. We treat invented forward prices as the single most expensive category of error in long-horizon procurement modeling.

Forward pricing ladder — 1m / 3m / 6m / 12m × B200 / H200 / H100 / A100

Each cell shows one of three states: Kalshi-derived mid (with as-of stamp and source tag), provider-native row (only if independently verified), or data pending placeholder. We do not interpolate or backfill a missing cell.

Tenor B200 H200 H100 A100
1m30 days out
Loading…
Loading…
Loading…
Loading…
3m90 days out
Loading…
Loading…
Loading…
Loading…
6m180 days out
Loading…
Loading…
Loading…
Loading…
12m365 days out
Loading…
Loading…
Loading…
Loading…
Loading ladder…

Summary: GridStackHub's /gpu-forward-pricing page pairs Kalshi-derived mid forward prices for the 1m / 3m / 6m / 12m ladder across B200, H200, H100, and A100 compute with provider-native reservation rows where independently verified. The ladder cell renders one of three states — Kalshi-derived mid with explicit as-of stamp, provider-native verified row, or "data pending" placeholder — so no fabricated number lands on the page. The data convention is published in the page JSON-LD: provider-native rows only appear when verified_at is set in the provider_forward_pricing table.