Product guide · global comparator
Use the comparator to turn a broad GPU requirement into a reviewable shortlist. Filter the current source-backed catalog by the dimensions that actually constrain your purchase, model the GPU-hours you expect to consume, then verify price and availability evidence separately before treating any row as a procurement candidate.
Quick start
The order matters. Every extra filter should represent a real requirement, not a preference added after seeing a cheap row. That keeps the shortlist reproducible and reduces accidental apples-to-oranges comparisons.
1 · GPU
Select the GPU model required by the workload. If the exact accelerator is still undecided, use benchmarks or workload calculators first instead of forcing the market data to answer a performance question.
2 · Region
Choose the required named region when latency, data residency, networking, quota, or an existing architecture makes geography material. “Global / unspecified” means the source did not map the row to a named region; it is not a promise of worldwide capacity.
3 · Market
Choose on-demand or spot when the purchase model is fixed. Spot can have a lower published rate but adds interruption risk, so do not treat it as an interchangeable substitute for an on-demand workload without pricing the operational overhead.
4 · Availability
Use available, unavailable, limited, or not evidenced as an evidence filter. “Not evidenced” is deliberately different from unavailable: it means the catalog does not currently have qualifying independent availability evidence for that row.
5 · GPU-hours
The comparator multiplies the normalized USD/GPU-hour rate by your monthly GPU-hours. The default 160 hours is a planning scenario, not a universal month. Enter the workload horizon you expect to buy before comparing the resulting budget exposure.
6 · Sort
Sort by lowest or highest price, freshness, or provider. A lowest-price sort identifies a price floor inside the selected evidence boundary; it is not a recommendation and does not prove that capacity, support, networking, or workload fit are equivalent.
7 · Evidence
Use the official pricing source on the shortlisted row. Where a separate availability source exists, inspect that too. Confirm the provider page, exact product context, region, market type, billing unit, GPU count, and any terms that can change the invoice.
Filter reference
The controls narrow or reorder the existing comparable catalog. They do not create a new price, infer availability, or change the source evidence behind a row.
| Control | Use it when | Do not infer |
|---|---|---|
| GPU model | The accelerator family is part of the workload requirement. | That every variant or surrounding node configuration is equivalent. |
| Provider | You are validating one vendor or narrowing an approved-provider list. | That provider choice alone makes regions, support, or capacity equivalent. |
| Region | Deployment geography changes latency, residency, architecture, or feasibility. | That a listed regional price proves current regional stock. |
| Market | The workload requires on-demand or can tolerate spot interruption. | That spot and on-demand have the same operational risk. |
| Availability | You want to include or exclude rows by the independent availability evidence state. | That “not evidenced” means unavailable, or that an evidenced status reserves capacity. |
| GPU hours / month | You want the same usage horizon translated into compute spend for every matching row. | That storage, egress, support, taxes, minimums, or engineering overhead are included. |
| Sort | You want to order the filtered set by price, freshness, or provider. | That the first row is automatically the best deployment choice. |
Read the table correctly
A row combines commercial pricing context with normalized comparison fields and, where available, a separate capacity signal. Keep those layers distinct when you move the result into a spreadsheet, memo, procurement ticket, or architecture review.
Commercial source
The normalized rate exists to make offers comparable. The provider source remains where you confirm the original node price, billing unit, product context, region terms, and any commercial conditions that may have changed.
Normalized comparison
USD per GPU-hour makes node sizes comparable when the source price can be normalized by GPU count. Monthly cost applies your selected GPU-hours to that normalized rate so the same usage horizon can be compared across the filtered rows.
Capacity evidence
A qualifying availability signal can be product-, provider-, or region-scoped depending on the source. Read the displayed status, evidence scope, and observation date instead of treating the existence of a price as proof that the requested capacity can launch now.
Budget horizon
The monthly field is a scenario control. It answers “what would this published compute rate cost at the same number of billed GPU-hours?” It does not estimate utilization, queueing, idle time, retries, spot interruptions, storage, networking, or whether the workload can actually complete in that horizon.
Working-hour scenario
Useful as a simple planning baseline when one GPU is billed for roughly a working-month schedule. Replace it when your service, training job, or batch queue has a different duty cycle.
Continuous-month scenario
Useful for approximate 24/7 monthly compute exposure. It is still billed GPU time, not a statement that the provider guarantees one GPU continuously for the whole month.
Your scenario
If you know expected runtime, concurrency, throughput, utilization, or job volume, derive GPU-hours from those inputs in the relevant calculator and bring that figure back to the comparator.
Shareable analysis
The comparator can preserve the selected GPU, provider, region, market, availability state, GPU-hours, and sort order in the shareable URL. Use that link in a review or handoff so another person starts from the same scenario instead of rebuilding the filters from memory.
A shared link is stronger when the review also states why the GPU, region, market type, and availability boundary were selected. That separates real requirements from choices made after seeing the result.
The URL preserves the scenario, not the old market state. Reopen the comparison and official sources when the purchase is approved, because prices and availability evidence can change after the original review.
The public CSV and JSON are better when you need reproducible downstream analysis across many rows. Keep the source and evidence fields with any derived ranking or budget model.
Fail-closed behavior
The comparator does not keep ranking a stale snapshot as if it were current. When the runtime freshness boundary expires, interactive ranking and scenario controls are paused and the page is marked historical while the official evidence links remain available for manual verification.
Do
If a purchase cannot wait, validate the provider source directly and record that you stepped outside the current normalized snapshot.
Do not
A historical row can still be useful evidence, but the ordering and calculated scenario should not be presented as the current market decision until fresh catalog evidence is published again.
Next tool
The global database is a discovery and shortlist tool. Once the decision becomes about workload performance, historical timing, provider-specific breadth, or total infrastructure cost, move to the surface designed for that question instead of stretching one table beyond its evidence boundary.
Performance
Use verified benchmark evidence or workload pages when the cheapest GPU-hour may not produce the cheapest completed workload.
Scenario modeling
Use the calculator hub when you can supply workload-specific throughput, volume, GPU count, utilization, or ownership assumptions.
Timing
Use history when a single current snapshot is not enough and the decision depends on whether an observed rate or market level has moved over retained evidence.
Capacity
Use the evidence guide and data status when deployability matters more than the existence of a published commercial rate.
Ready to compare?
Open the current comparator, apply only the constraints your workload actually has, and verify the official sources before committing spend.