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.
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.
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 |
|---|---|---|---|---|
| 1m | Loading… |
Loading… |
Loading… |
Loading… |
| 3m | Loading… |
Loading… |
Loading… |
Loading… |
| 6m | Loading… |
Loading… |
Loading… |
Loading… |
| 12m | Loading… |
Loading… |
Loading… |
Loading… |
Per-GPU side-by-side: the Kalshi-derived mid from gsh_60d_trend_projection against independently verified rows from provider_forward_pricing, one column per tenor (1m / 3m / 6m / 12m). Each cell pulls live DB data; missing cells render the data pending chip so no fabricated number lands on the page.
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. The side-by-side matrix below the ladder shows the same data per row, listing each verified provider against the Kalshi-derived mid so buyers can compute the basis without spreadsheet work.