The billing unit is only the first layer
Providers may publish per-GPU-hour, per-instance-hour or other rates. Before comparing them, the tool should determine whether the units describe equivalent hardware and configuration.
A rate without configuration metadata should be treated as incomplete rather than silently normalized.
GPU model and node design must be explicit
H100, H200 and B200 systems differ in accelerator generation and can appear inside different node designs. NVIDIA's reference architecture shows how these GPUs operate within larger systems that include CPUs, memory, high-speed networking and storage.
The comparator should therefore expose node-level fields wherever the provider publishes them.
Region and commitment change the price
Cloud rates can vary by region and by on-demand, reserved or committed usage. Promotional or spot-style rates should be separated from standard prices because they represent different availability and risk.
Currency should also be explicit. Where taxes or ancillary charges are excluded, the page should say so.
Availability is a separate dimension
A low price with no capacity is not actionable. Provider availability may change more quickly than published list prices and may differ by region.
The tool should distinguish 'price observed' from 'capacity confirmed' unless the underlying data source supports both.
Total workload cost may differ from hourly GPU cost
Storage, networking, data transfer, CPU/RAM allocation, cluster efficiency and job duration can materially affect the final bill. The pricing comparator should therefore avoid presenting hourly price as a complete TCO measure.
Where possible, users should be routed to the ROI calculator for broader economics.
Freshness is part of the methodology
Every rate should include a source, extraction date and last-verified date. Stale rates should be flagged or removed rather than presented as current.
A historical dataset can still be valuable, but it must be labeled as historical.
Current pricing snapshot and normalization example
Pricing is a dated observation, not a permanent ranking. Lambda's pricing page currently lists self-serve one-GPU H100 SXM at $4.29 per GPU-hour and one-GPU B200 SXM6 at $6.99 per GPU-hour, with applicable sales tax/VAT/GST excluded. AWS Capacity Blocks publishes different effective per-accelerator rates depending on GPU generation, instance shape, region and reservation structure. These examples show why provider pricing must be normalized before comparison. Lambda pricing; AWS Capacity Blocks pricing. Verified 5 September 2026.
| Provider / offer | GPU | Configuration context | Published rate | Important qualification |
|---|---|---|---|---|
| Lambda self-serve instance | H100 SXM 80 GB | 1 GPU; 26 vCPUs; 225 GiB RAM; 2.75 TiB SSD | $4.29/GPU-hour | Taxes excluded; self-serve availability is first-come. |
| Lambda self-serve instance | B200 SXM6 180 GB | 1 GPU; 26 vCPUs; 360 GiB RAM; 2.75 TiB SSD | $6.99/GPU-hour | Taxes excluded; self-serve availability is first-come. |
| AWS Capacity Blocks | H100 | p5 family; rate varies by region and reservation | See current provider page | Capacity Block pricing is reservation-based and changes with supply/demand. |
| AWS Capacity Blocks | B200 | p6-b200 family; 8 accelerators per instance | See current provider page | Per-instance and per-accelerator rates vary by region. |
Why the table does not declare a cheapest provider: Lambda's self-serve instance and AWS Capacity Blocks are not the same commercial product. A defensible comparison must account for commitment, node shape, region, taxes, network, storage, availability and workload performance before converting an hourly rate into a recommendation.
Information-gain contribution: this page preserves the full context around the number. That makes the price more reusable for search and AI answers because the entity, GPU model, commercial scope, time context and source remain attached to the claim.
How to extend this pricing reference into a full comparator
The next dataset layer should store one row per provider, GPU, configuration, region and commercial term. That row should include currency, billing unit, tax treatment, ancillary-charge status, source URL, extraction date and last verification date. This makes each observation independently auditable.
Normalization should be conservative. A one-GPU self-serve instance should not be ranked directly against a multi-week 64-GPU cluster commitment unless the interface clearly labels the difference. The comparator can allow users to filter by GPU and commercial model first, then compare only the rows that remain meaningfully comparable.
Availability should be tracked separately from price. A provider may publish a rate while capacity is constrained, or sell capacity through a sales process without a public inventory signal. Separating these fields prevents a price table from implying purchasability that has not been verified.
- Provider and offer
- GPU and node configuration
- Region
- Commercial term
- Currency and unit
- Taxes/ancillary charges
- Source and verification time
- Availability state
Freshness rule for every price row
Every price observation should be treated as F2 data. Store the source URL, extraction date, last verification date, currency, billing unit, region, configuration and commitment basis. If a provider changes the commercial structure, preserve the old row only as clearly historical data.
This approach supports both users and future AI citation measurement because a cited price can be traced back to the exact offer and date rather than floating as an unattributed number.
Evidence and decision notes
The following sources are used as evidence anchors for the decision points on this page. Each source answers a different part of the question, so figures should be interpreted within the source’s geography, date, methodology and scope.
| Evidence anchor | What it supports on this page |
|---|---|
| AWS EC2 Capacity Blocks pricing | Shows current H100, H200 and B200 pricing by region and product, and states that reservation prices are updated with supply and demand. |
| AWS Capacity Blocks pricing and billing documentation | Explains that Capacity Block prices depend on supply and demand at purchase time and are charged under a specific reservation model. |
| NVIDIA HGX AI Factory overview | Provides the system context needed to avoid treating GPU model as the only performance or cost variable. |
Implementation and Decision Guidance
- Compare equivalent GPU and node configurations.
- State region, currency and commitment type.
- Timestamp every price.
- Separate observed price from confirmed availability.
- Do not equate hourly rate with total workload cost.
Frequently Asked Questions
Why do GPU cloud prices differ so much?
Hardware generation, node design, region, contract structure, provider capacity and ancillary services all affect pricing.
Can I compare per-instance-hour with per-GPU-hour?
Only after normalizing the number and type of GPUs and the rest of the node configuration.
Does the cheapest rate mean lowest total cost?
No. Performance, utilization, storage, networking and other charges can change total workload cost.
How often should prices be updated?
As often as practical for the intended use, with a visible timestamp on each observation.
Should unavailable capacity be listed?
It can be listed as a price observation, but availability status must be distinguished clearly.