How to choose a GPU cloud provider

Choose the GPU your workload needs first, then compare providers on the price of that exact GPU and pricing type, not on headline rates. The cheapest listed GPU-hour is often not the lowest total cost: billing increments, storage that keeps billing while an instance is stopped, egress, tax, capacity and whether a price is interruptible or a marketplace floor all change the bill. Shortlist two or three providers that have the GPU in the region you need, estimate a full month, test before you commit, and keep your images and data portable so you can switch later.

• Match the GPU variant, not just the name: SXM and PCIe versions of the same GPU differ in bandwidth and multi-GPU scaling.
• Compare like with like: on-demand, spot, serverless and marketplace prices are different products.
• Price the whole month: storage, egress, tax and billing increments can outweigh a small hourly difference.
• Check capacity and terms: availability, rental limits and support differ more than list prices.
• Keep an exit path: your own container image and data you can move make switching providers cheap.

The workload decides the GPU, and the GPU decides which providers are even in the running. A model that fits in one card’s memory needs one GPU with enough VRAM and memory bandwidth. Training, or serving a model split across several GPUs, also needs fast links between them. Size the memory first (our VRAM guide shows the arithmetic), then pick the GPU model, and only then compare providers.

Check the exact variant, not just the name

GPU names hide differences that change performance. NVIDIA sells the H100 as an SXM module with NVLink at 900 GB/s between GPUs, and as PCIe-based cards whose host link is PCIe Gen5 at 128 GB/s [1]. Our GPU catalog lists 3.35 TB/s of memory bandwidth for the 80 GB SXM version and 2.00 TB/s for the 80 GB PCIe version. A listing that only says “H100” is not enough to compare prices: ask which form factor, how much memory, and how the GPUs in a multi-GPU instance are connected.

Answer four questions before you open a single pricing page:

• How much GPU memory does the model need at your context length and batch size?
• Does one job span several GPUs? Then interconnect (NVLink, InfiniBand) matters as much as the card.
• Is the work interactive, where latency counts, or batch, where only throughput per dollar counts?
• How many hours per month will the GPUs actually run?

Providers sell the same GPU under different pricing types, and the types are different products. Comparing an interruptible or marketplace price with another provider’s on-demand list price makes the first look cheaper than it is.

Normalise to one GPU-hour

Some providers only rent whole nodes, typically eight GPUs. We divide the node price by the number of GPUs and keep the node size in the record, so every price below is USD per single GPU-hour. In the current dataset, 30 of 63 priced on-demand offers are multi-GPU configurations, such as eight-GPU nodes, and appear below at their per-GPU price.

So which GPU cloud is cheapest? It depends on the GPU and the pricing type, which is why the table keeps them apart. For every GPU in the catalog, the GPU cloud comparison lists each provider’s offers with their source and verification date, and GPU pages such as H100 hosting prices, L40S hosting and RTX 4090 cloud narrow it to one card.

Hourly price × hours is only the compute line of the bill. Five other items regularly outweigh a small difference in the hourly rate:

• Billing increment. Per-second billing charges a 10-minute test as 10 minutes; hourly billing can round it up to a full hour.
• Storage that keeps billing. Volumes and disks are usually still charged while an instance is stopped, sometimes at a different rate, and a temporary disk can be erased when it stops. Check both before you leave machines parked.
• Running out of credit. On a prepaid account, an empty balance can stop your machines or API access, and an instance without persistent storage can lose its data when it stops. Set a top-up or an alert.
• Egress. Moving model outputs, checkpoints or datasets out of a provider can cost per GB, or nothing at all, depending on the provider.
• Tax. Check whether a price includes VAT or sales tax for your country. Prices in our dataset exclude tax unless the record says otherwise.

Put the hours, GPU count and storage you expect into the GPU cost calculator to see a month at every provider with a verified price, with the formula and inputs shown.

A low rate is worth nothing if the GPU is not available where and when you need it. Providers rarely publish live stock, and capacity for the newest GPUs is often limited or gated behind a sales conversation. On our pages, availability is shown as Limited when the provider states waiting times or restricted access, and as Not verified when it publishes nothing.

Rental terms matter too. Spot and marketplace capacity can end before your job does, and some offers have a maximum rental duration. Long training runs need a provider and pricing type that cannot end under you.

• Which regions list the GPU, and are they in the jurisdiction your data has to stay in?
• How many GPUs can you start at once without asking for a quota increase?
• Can you reserve capacity for a launch or a training run, and on what terms?
• Is the GPU self-serve, or does it need a sales conversation and a contract first?
• What happens to your data and running jobs during maintenance?

If data has to stay in the EU, start from the GDPR AI hosting checklist before comparing prices.

Developer time is part of the cost. Two providers with the same GPU can differ by hours of setup and a lot of operational risk.

1. Write down the GPU model and variant, GPU count, memory need, region and expected hours per month.
2. Filter providers that list that GPU with a verified price, for example on H100 hosting or the GPU cloud comparison.
3. Estimate a full month, storage and egress included, with the GPU cost calculator.
4. Put the two or three best candidates side by side in the comparison.
5. Run a short paid test on your own workload: measure throughput per dollar, time to first token, disk speed and time to start.
6. Keep an exit path: store weights and data where you control them, and avoid features you could not replace.

We re-check prices against the providers’ own pages and show the verification date next to every figure; the methodology explains how.

Moving a GPU workload is mostly work you could have avoided on day one. Before you depend on a provider, check that you could leave it:

1. Package the runtime as an image you control. vLLM publishes an official image, vllm/vllm-openai on Docker Hub, that runs its OpenAI-compatible server [2]. Building on a public image like it, rather than on a provider-only template, keeps the same setup runnable elsewhere.
2. Record what each template does. A one-click template is an image plus a start command, ports, environment variables and a volume mount. Write them down, so you can rebuild the setup on another provider.
3. Keep weights and data where you can move them. Provider volumes are usually tied to one region or data centre, data does not sync between them by itself, and copying it out takes time and egress. Keep a backup of anything critical outside the provider’s volumes.
4. Budget the move. Egress for the data you take out (see the table in section 3), plus the time to rebuild images and upload weights again.
5. Benchmark before you switch traffic. The same GPU name can perform differently at another provider, because of the variant, the interconnect or the storage behind it.
6. Check account limits first. Quotas, spend limits and regional capacity decide how fast you can scale on the new provider.

Every provider profile lists its closest alternatives, for example Lambda alternatives, Hyperstack alternatives and Nebius alternatives.