GPU rental guide
Renting a GPU is usually the fastest way to test an AI workload without buying a server. Start with memory and workload fit, compare the full provider bill, then launch the smallest instance that can produce a useful benchmark.
Provider rows on this page were last refreshed Aug 8, 2026. Rates and capacity change, so verify the final offer before starting a long run.
Short answer
Choose a GPU that fits the model, batch size, context length, or image workload; compare a hyperscaler, a specialized GPU cloud, and a marketplace; launch an on-demand instance; connect your environment and data; then monitor the complete cost. For a short or uncertain project, renting is usually more reversible than buying a server. For a workload that runs most hours for years, compare the same schedule with the GPU server cost guide before committing.
The most important number is not the advertised GPU-hour. Add storage, CPU and RAM, network transfer, idle time, spot interruptions, setup time, and any platform or support fees before choosing the cheapest option.
Use live data as a checkpoint
GPU rental prices vary by model, region, provider type, billing mode, and availability. The table below uses GPU Cost's current D1 pricing rows and shows the lowest tracked on-demand rate plus a simple 730-hour always-on checkpoint. It is a screening view, not a quote: it excludes storage, CPU, RAM, networking, taxes, platform fees, and the cost of interrupted or idle work.
| GPU | Lowest tracked rate | 730-hour checkpoint | Providers |
|---|---|---|---|
| RTX 309024 GB VRAM | $0.015/GPU-hour | $10.95/month | 3 |
| V10016 GB VRAM | $0.025/GPU-hour | $18.54/month | 3 |
| L422 GB VRAM | $0.032/GPU-hour | $23.65/month | 4 |
| RTX A400016 GB VRAM | $0.060/GPU-hour | $43.80/month | 4 |
| RTX 408015 GB VRAM | $0.098/GPU-hour | $71.69/month | 2 |
| RTX 30708 GB VRAM | $0.130/GPU-hour | $94.90/month | 1 |
| Tesla V10032 GB VRAM | $0.140/GPU-hour | $102.20/month | 5 |
| RTX 308010 GB VRAM | $0.170/GPU-hour | $124.10/month | 1 |
| RTX 3080 Ti12 GB VRAM | $0.180/GPU-hour | $131.40/month | 1 |
| V100 FHHL16 GB VRAM | $0.190/GPU-hour | $138.70/month | 1 |
| Tesla V10016 GB VRAM | $0.190/GPU-hour | $138.70/month | 1 |
| V100 SXM216 GB VRAM | $0.230/GPU-hour | $167.90/month | 1 |
Data refresh: Aug 8, 2026. For all provider rows and filters, open cloud GPU pricing; for utilization and overhead, use the GPU rental cost calculator. For a broader service-selection framework, read the cloud GPU rental guide.
Choose by workload, not by brand alone
Provider choice changes the operating experience as much as the GPU changes the compute. A marketplace may win on a short benchmark but lose if the host disappears, a volume is slow, or an interrupted job has to restart. A hyperscaler may cost more per hour but fit an existing VPC, IAM policy, data pipeline, or compliance process. Specialized GPU clouds sit between those extremes and often make the GPU workflow easier to repeat.
Hyperscalers
AWS, Azure, and Google Cloud integrate GPU instances with identity, networking, storage, and the rest of an enterprise cloud account.
Good fit: Best when compliance, data locality, existing contracts, or managed cloud services matter more than the lowest hourly rate.
Tracked examples: Google Cloud Platform · Amazon Web Services · Microsoft Azure · Oracle Cloud
Specialized GPU clouds
GPU-native providers focus on accelerated workloads and may offer better availability, simpler images, faster provisioning, or stronger multi-GPU options.
Good fit: Best when AI training, inference, or fine-tuning is the main job and you want a focused operating model.
Tracked examples: Genesis Cloud · RunPod · Datacrunch (Verda) · Genesis Cloud · CoreWeave
GPU marketplaces
Marketplaces aggregate hosts and listings, often exposing low rates with more variation in host quality, region, storage, and interruption risk.
Good fit: Best for experiments and price-sensitive workloads that can tolerate provider or host variability.
Tracked examples: Vast.ai · Massed Compute · Vast.ai · TensorDock
A repeatable launch path
Most overspending happens before the first useful result: the wrong VRAM tier, an always-on notebook, a missing volume, or a provider comparison that ignores network and restart costs. Use this sequence to keep the first experiment small and the decision reversible.
Write down model weights, precision, context length, batch size, KV cache, and headroom. A fast GPU that cannot fit the workload is not a bargain.
Check GPU variant, CPU, RAM, local disk, persistent storage, region, network, billing unit, and interruption policy before comparing rates.
Start on-demand with a small benchmark. Confirm the image, drivers, CUDA stack, volume mount, and data path before scaling up.
Record tokens per second, images per minute, training time, queue time, and failure rate. Peak FLOPS alone does not predict the bill.
Stop idle machines, set budget alerts, clean old volumes, and include transfer, retries, and support in the project estimate.
Match the GPU to the job
There is no universal best GPU. Start with the memory requirement and the time-to-result target, then compare the price of the smallest configuration that fits. A lower-cost GPU can be the right answer when it completes the job without swapping or excessive retries; a premium GPU can be cheaper when it finishes a long training run much faster.
| Workload | First checks | Typical rental direction | Watch out for |
|---|---|---|---|
| Development and small inference | VRAM, framework support, notebook startup | L4, L40S, RTX-class, or other mid-range option | Paying for a large data-center GPU while mostly idle |
| Image generation and rendering | VRAM, model compatibility, throughput, local NVMe | Consumer or workstation GPU when memory is sufficient | Storage, queue time, and egress for large assets |
| Fine-tuning | Model size, optimizer memory, batch size, checkpoint speed | A100/H100-class or a multi-GPU plan when the model requires it | Under-sizing memory and paying for repeated failed runs |
| Large-model training | Interconnect, node shape, network, checkpoint recovery | H100, H200, B200, or equivalent high-memory cluster | Comparing a single GPU-hour with a complete multi-GPU node |
| Bursty API inference | Request volume, cold-start tolerance, concurrency | Serverless GPU or autoscaled rental rather than 24/7 capacity | Warm workers, idle time, platform fee, and latency spikes |
Use the GPU pricing index to shortlist model-level rates, then validate the full configuration in the provider's own pricing page.
The number most comparison pages omit
Use the GPU-hour as a first filter, not the final answer. A training run that is 20% faster can be cheaper even with a higher hourly rate, while a cheap marketplace can become expensive when a job is interrupted, data is moved twice, or a volume stays attached for a month.
Persistent volumes, snapshots, object storage, and checkpoint copies can continue billing after the GPU is stopped.
An instance with a low GPU rate may require a larger host, and the complete machine price can change the comparison.
Moving datasets, model weights, and generated assets between regions or services can cost more than expected.
A notebook left running, a warm worker, or a capacity queue can turn a low list rate into a high cost per useful result.
Spot or interruptible capacity can be excellent for checkpointed jobs, but retries and lost progress belong in the budget.
Images, drivers, secrets, monitoring, backups, support, and incident time are part of the practical rental decision.
GPU rate × active time + storage + network + CPU/RAM + idle time + retries + platform/support feesWhen request traffic is intermittent, compare a continuously running instance with the serverless GPU pricing calculator. When the workload is stable for years, model ownership with the GPU server cost calculator.
Do not use a monthly GPU-hour total as the entire break-even model. Compare useful completed work over the same period, including power, cooling, staffing, downtime, resale value, storage, and cloud transfer. The GPU server cost guide explains the ownership side; this page focuses on how to make the first rental decision safely.
Define the model and VRAM requirement, compare a few providers, launch an instance, attach storage and code, run a short benchmark, and monitor the complete bill rather than only the GPU-hour.
Start with an on-demand benchmark, stop idle instances, compare storage and egress, and set a budget alert. Use spot capacity only when the job can checkpoint and recover.
The rate depends on the model and provider. Use the live table above as a starting checkpoint, then add storage, CPU/RAM, network, idle time, retries, and support. A 730-hour figure is an always-on baseline, not a recommendation.
The cheapest useful option depends on the completed workload. Marketplaces and spot listings can have low headline rates, while specialized clouds or hyperscalers may reduce queue time, failed runs, data movement, or operational work.
Choose the smallest GPU that fits memory and performance needs. A100 is mature and widely available, H100 and B200 suit higher-end training or inference, L40S is useful for inference and graphics, and RTX-class GPUs can be cost-effective when consumer memory is enough.
Yes, especially for experiments, variable traffic, and workloads that do not need a dedicated machine all day. For predictable request traffic, compare an always-on instance with serverless or autoscaled capacity.
You can when the training job checkpoints frequently and can resume after interruption. Include lost progress, restart time, data reloading, and availability risk in the effective cost.
Provider products, billing units, availability, and pricing change. Use these first-party destinations to verify the final offer after narrowing the workload and GPU:
These links are verification references, not a guarantee of availability or a recommendation that one provider is always cheapest. GPU Cost's live rows are a comparison starting point; confirm region, instance shape, storage, and billing terms before a long run.