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. Provider names and source labels come from the imported row metadata; missing source metadata is shown as Source unavailable. 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… |
Choose a GPU and, if useful, a provider. We’ll notify you when the tracked forward rate changes so your reservation planning stays current.
Compare verified provider-native rates for the same GPU model, region, and commitment term. Estimated monthly cost assumes 730 hours per month.
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). The B200, H100, and A100 panels also include a dedicated Inference price (per 1M tokens) column that stacks the four derived values beside their matching hourly rates. Each cell pulls live DB data; missing cells render the data pending chip so no fabricated number lands on the page.
All rates are point-in-time snapshots, not live quotes. For provider rows, captured_at is the provider source-capture time, distinct from verified_at, which records independent verification. The displayed source label is derived from the imported source_url hostname; Fresh means up to 7 days old from capture, Recent means up to 30 days old from capture, and values older than 30 days are Stale and should be rechecked directly with the provider before procurement. Missing or invalid capture timestamps stay visible with a neutral Capture time unavailable badge and are never classified as fresh or stale. Missing, blank, malformed, or unsupported source URLs show Source unavailable and are never rendered as links.
Provider-native forward rows appear only after independent verification; otherwise the cell remains data pending. Kalshi-derived values use the 60-day GridStackHub spot trend (gsh_60d_trend_projection) when the live Kalshi feed is unreachable from the sandbox. Inference values assume 70B-parameter open-weights inference at FP16/BF16, batch=8, sequence=2048, with GPU-specific throughput of H100 2,400, A100 600, and B200 5,800 tokens/sec; the formula is $/hr ÷ (tokens/sec × 3,600) × 1,000,000. H200 is intentionally not shown in the inference column.
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. The inference column adds a derived $/M tokens reading reconciled to the /blog/h100-vs-a100-inference-cost matrix for the top-3 SKUs (H100, A100, B200); H200 is intentionally out of scope.
captured_at is the provider source-capture time, distinct from verified_at, which records independent verification. Fresh means up to 7 days old from capture, Recent means up to 30 days old from capture, and values older than 30 days are Stale and should be rechecked directly with the provider before procurement. Missing or invalid capture timestamps show Capture time unavailable and are never classified as fresh or stale.
$/hr ÷ (tokens/sec × 3,600) × 1,000,000. H200 is intentionally excluded from the inference column.