Research-backed calculator guide
Cloud GPU Hourly Prices: Normalize Public GPU Rates Before You Choose a Provider
Compare cloud GPU hourly prices fairly by normalizing GPU count, billing mode, host resources, runtime, and extras before choosing a provider.
Quick answer
A cloud GPU hourly price comparison is only meaningful after every quote uses the same unit and operating assumption. Start with the same GPU model and memory class, then convert a multi-GPU host price to a per-GPU-hour figure:
normalized GPU rate = published host rate ÷ GPUs in the host
Next, label the billing mode: on-demand, spot or interruptible, reserved, or a cluster commitment. Finally, estimate the workload bill as GPU rate × GPU count × billed hours, then add the resources that the quote excludes or prices separately. A $3.99 H100 quote and a $49.24 eight-GPU H100 host are not comparable until the latter becomes $6.16 per GPU-hour. Both figures are vendor-published observations checked on 2026-11-02, not promises of future availability.
For a simple 160-hour, one-GPU comparison, the published examples in the ledger below produce about $638.40 at $3.99/GPU-hour and about $984.80 at a normalized $6.16/GPU-hour. Those are compute-only estimates. Storage, snapshots, data transfer, tax, setup time, idle time, minimum charges and failed provisioning can change the invoice.
The practical answer is therefore not “which provider is cheapest?” It is “which quote remains cheapest after the GPU, billing mode, region, capacity probability and workload overhead are normalized?” Use the Self-hosted GPU inference cost calculator when the decision is between a rented GPU and a fully loaded self-hosted inference design.
What the public price actually measures
Cloud GPU pricing pages use different meters. A vendor may show a price per GPU-hour, a complete virtual machine per hour, an eight-GPU host per hour, a spot bid, or a cluster commitment. Treating each number as the same unit creates a false comparison.
Lambda’s published instance card, for example, shows GPU-specific instance rates and the surrounding vCPU, RAM and storage configuration. Its displayed footnote says applicable sales tax, VAT or GST is extra. [1] Runpod separates Pods, Serverless and Clusters, so a Pod rate should not be substituted for a serverless inference-worker rate or a reserved multi-node quote. [2]
Google Cloud documents another important distinction: Compute Engine charges vCPUs, GPUs and memory resources, with a one-minute minimum and one-second increments after that. Its Spot prices and committed-use discounts are separate pricing modes with different interruption or commitment assumptions. [3] A public “hourly” number can therefore conceal a minimum billing unit or a discount obligation that matters for short jobs.
CoreWeave illustrates the host-normalization problem. Its North America table lists an eight-GPU HGX H100 system at $49.24 per hour and separately shows an inference single-GPU price of $6.16 per hour. Dividing the host quote by eight gives $6.155, which rounds to the displayed $6.16. [4] The same page also exposes spot figures and regional tables, so region and capacity class belong in the ledger.
A repeatable normalization method
Use this sequence for every candidate quote:
- Freeze the hardware target. Record GPU model, VRAM, form factor and GPU count. An H100 SXM, H100 PCIe and a sliced or MIG allocation may not deliver the same memory bandwidth or usable capacity.
- Capture the quote exactly. Save the vendor URL, checked date, currency, region, displayed unit, and whether the quote is on-demand, spot, interruptible or committed. Do not silently replace an unavailable figure with a nearby model.
- Convert the unit. For a host quote, divide by the number of GPUs. For a multi-GPU reservation, divide by the GPU count only when the reservation price is explicitly allocated that way. Keep a separate column for the original host quote so the conversion is auditable.
- Normalize time. Convert runtime into billed hours. For a 30-minute job with a one-hour minimum, use one billed hour. For per-second billing, use seconds only after checking the vendor’s minimum. Never use 720 hours as “monthly” utilization without saying that it is a 30-day, always-on assumption.
- Add attached resources. Include vCPU, RAM, local or persistent storage, snapshots, IP addresses, orchestration, container startup, and data transfer when they are not bundled. A low GPU rate can be offset by a required host or an egress-heavy workload.
- Model availability and interruptions. Spot or interruptible rates are conditional prices. Add checkpoint, restart and queue-time costs if a preemption would affect the workload. For interactive inference, a cheaper interruptible rate may be unusable even if its nominal GPU-hour is lower.
- Run a sensitivity check. Compare idle or warm-pool utilization, not just the ideal billed hours. Calculate at least a 25%, 50% and 80% utilization case for a service that must keep a GPU ready.
This method is deliberately slower than copying a “cheapest GPU” badge. It produces a rate that a finance or engineering reviewer can reproduce after the provider page changes.
Worked cost example
Assume a team needs one H100-class GPU for 160 billed hours in November. The team wants an on-demand comparison, not spot capacity, and it is comparing compute-only GPU charges before adding storage, egress, tax or support. The following vendor quotes were visible on 2026-11-02:
| Step | Published input | Normalization | Output for 160 hours |
|---|---|---|---|
| Lambda H100 SXM instance | $3.99 per GPU-hour | Already a per-GPU quote | $3.99 × 160 = $638.40 |
| Runpod H100 SXM Pod | $3.99 per hour shown for the GPU card | Treat as one GPU; verify selected cloud/region at deployment | $3.99 × 160 = $638.40 |
| CoreWeave HGX H100 host | $49.24 per host-hour for 8 GPUs | $49.24 ÷ 8 = $6.16/GPU-hour after rounding | $6.16 × 160 = $985.60 |
| CoreWeave inference single-GPU field | $6.16 per GPU-hour | Already a per-GPU quote; shown as a separate service field | $6.16 × 160 = $985.60 |
The first two rows are vendor-page observations, while the last two outputs are arithmetic based on the observed CoreWeave figures. The CoreWeave host division produces $6.155 before rounding, so calculating from the unrounded number gives $984.80; using the displayed $6.16 produces $985.60. That $0.80 difference is rounding, not a provider discount.
Now extend the same assumptions to a 720-hour month. Lambda’s compute-only estimate is $3.99 × 720 = $2,872.80. The unrounded CoreWeave host normalization is ($49.24 ÷ 8) × 720 = $4,431.60. Neither estimate is an invoice forecast. The comparison excludes CPU and RAM differentials, storage, network transfer, tax, deployment failures and any commitment or reservation requirement. Runpod states that Pods, Serverless and Clusters have different workload roles, so the Pod calculation should not be presented as the cost of a production Serverless endpoint. [2]
The example also demonstrates why a headline minimum is a weak decision rule. If a provider lists a cheap interruptible rate, it may be a valid batch-training option but not a valid always-on inference option. If a provider lists a host price, it may include eight GPUs and large amounts of RAM that a one-GPU job does not need. The correct comparison retains both the original quote and the normalized result.
When a lower hourly rate is not lower cost
Billing granularity. A nominal hourly price does not tell you whether a 12-minute experiment costs 12 minutes, 30 minutes or a full hour. Google Cloud’s documented one-minute minimum followed by per-second billing is a concrete example of why the minimum belongs in the model. [3]
Capacity and queue time. A rate is not useful if the requested GPU cannot be provisioned when the job starts. Add expected queue time or a fallback provider to a production capacity model. Do not convert a displayed listing into an availability guarantee.
Host shape. A host may bundle more CPU, RAM or local SSD than the workload requires. That bundle can be valuable for training but wasteful for a small inference service. Conversely, a low GPU-only figure may require paid system resources before the container can run.
Utilization. A warm GPU billed for 720 hours is different from a batch GPU billed for 160 hours. At 25% utilization, a $3.99 rate gives $3.99 × 180 = $718.20 for 30 days if the machine is started only during work windows, but a warm service can still incur the full $2,872.80. The right denominator is billed hours, not calendar hours.
Non-GPU line items. Storage, egress, image pulls, snapshots, control-plane charges, support and taxes may be material. Lambda explicitly flags applicable sales taxes outside the displayed rates. [1] Put each item in a separate line rather than hiding it in an arbitrary “20% overhead” factor.
For a broader workload view, compare this ledger with the Model pricing comparison when a hosted API could replace GPU rental, and use the RAG, embedding and vector database cost calculator if retrieval traffic contributes to the system’s cost. For a team evaluating build effort as well as run cost, the AI agent development cost estimator covers a different but related budget layer.
Run your scenario
Turn this framework into an editable estimate.
Use dated, source-linked assumptions and see cost per request, successful task and month.
FAQ
What is the cheapest cloud GPU hourly rate?
There is no durable universal winner. The lowest visible rate may be a different GPU, a marketplace listing, spot or interruptible capacity, a regional offer, a sliced allocation, or a promotional listing. Compare the same GPU model and VRAM, the same billing mode, and the same availability requirement. Treat a public rate as a dated quote, not a guarantee.
How do I compare H100 cloud hourly prices fairly?
Record whether the quote is H100 SXM or PCIe, its VRAM, GPU count, region, billing granularity and capacity mode. Convert multi-GPU hosts to per-GPU-hour only when the host price and GPU count are explicit. Then calculate billed hours and add CPU, RAM, storage, egress and tax. Keep the host quote beside the normalized number so reviewers can reproduce it.
Are spot or interruptible GPUs included in an on-demand comparison?
Not in the same row. Put spot or interruptible pricing in a separate scenario because the capacity can be reclaimed or the price can vary. Google Cloud describes Spot VMs as preemptible and separately documents committed-use discounts; those conditions change the economics and operational risk. [3] A batch workload with checkpointing may use that scenario, while an interactive service usually needs an on-demand or reserved assumption.
Does “per GPU-hour” include the complete server?
Not necessarily. Some pages publish a per-GPU rate for a defined instance, some publish a whole host, and some expose both. CoreWeave’s table shows the difference between an eight-GPU HGX H100 host and an inference single-GPU field. [4] Read the surrounding vCPU, RAM, storage and service notes before treating the number as fully loaded cost.
Should I multiply an hourly rate by 720 for monthly cost?
Only for an always-on 30-day assumption, and only if the provider bills continuously with no commitment or minimum mismatch. A workload that starts for 160 hours should use 160 billed hours. A service that must remain warm may use 720, but it should also model idle capacity and failover. Label the result as an estimate and list excluded charges.
How often should a cloud GPU comparison be refreshed?
Refresh it whenever a decision depends on the number, and record the checked date on every row. Marketplace supply, spot rates, regional capacity, taxes and provider catalogs change. This article’s values are observations from 2026-11-02; they are not a standing price list. Recheck the vendor page immediately before provisioning.
Limitations and exclusions
This comparison does not claim a provider is absent from the market, that a result is easy to rank for, or that a displayed price will produce traffic or savings. The search results included live directories, vendor rate cards, comparison posts, a marketplace page and a community discussion. Their formats and update schedules differ, and the search interface did not reliably expose ad labels; the SERP benchmark therefore excludes results that were clearly promotional where identifiable but records that limitation.
The worked table is intentionally narrow: one H100-class GPU, 160 billed hours, USD, on-demand-style comparison, no tax, storage, egress, orchestration or support. It does not benchmark tokens per second, latency, model quality, reliability, compliance, region-specific capacity or network topology. For production, collect a quote for the exact region and instance, run a short performance test, and reconcile the first invoice against the normalized ledger.
Primary sources checked
Pricing and product behavior can change. These sources support the time-sensitive claims in this guide; verify current provider terms before committing spend.