An eight-hour H100 fine-tune looks like a $21.52 line item at $2.69 per GPU-hour. Then you discover the cheapest listing is a two-GPU bundle, the dataset sits in storage for a week, the job checkpoints twice, and the instance is interrupted at hour six. The bill is not $21.52, and the headline rate was never the price.
This is a practical teardown of GPU cloud pricing using live catalogue rates observed on 2026-10-17. The point is not that one provider is always cheaper. The point is that the advertised GPU-hour is a component price, and your budget needs the fully loaded number.
What the advertised rate includes
Most GPU marketplaces quote compute only:
- The GPU and its host memory.
- The container or VM while it is running.
- Sometimes local disk, sometimes not.
- Sometimes network, sometimes not.
Storage, egress, taxes, idle time, and restart overhead are usually separate. Multi-GPU offers may require you to rent the whole bundle even if your job can only use one GPU. Community or interruptible capacity may be cheaper because the inventory is not reserved and can disappear.
That is why a rate table is a starting point, not a budget. The useful unit is cost per useful GPU-hour: the total bill divided by the GPU-hours that actually produced work you can keep.
What the market actually listed on 2026-10-17
The public GPU index samples RunPod's catalogue and Vast.ai's verified on-demand bundles. These are live catalogue observations, not negotiated quotes. Inventory is not guaranteed, and storage and network are extra.
| Provider | GPU | Tier | $ / GPU-hour | 100 GPU-hours | Bundle constraint |
|---|---|---|---|---|---|
| RunPod | H100 SXM 80GB | Community | $2.690 | $269.00 | Single GPU |
| RunPod | H100 SXM 80GB | Secure | $3.990 | $399.00 | Single GPU |
| Vast.ai | H100 SXM 80GB | Verified on-demand | $2.134 | $213.40 | 2-GPU bundle at $4.269/hour |
| RunPod | H100 PCIe 80GB | Community | $1.990 | $199.00 | Single GPU |
| RunPod | H100 PCIe 80GB | Secure | $2.890 | $289.00 | Single GPU |
| Vast.ai | H100 PCIe 80GB | Verified on-demand | $2.268 | $226.80 | 2-GPU bundle at $4.537/hour |
| RunPod | A100 80GB SXM | Community | $1.390 | $139.00 | Single GPU |
| RunPod | A100 80GB SXM | Secure | $1.790 | $179.00 | Single GPU |
| Vast.ai | A100 80GB SXM | Verified on-demand | $1.056 | $105.60 | Single GPU |
| RunPod | A100 80GB PCIe | Community | $1.190 | $119.00 | Single GPU |
| RunPod | A100 80GB PCIe | Secure | $1.790 | $179.00 | Single GPU |
| Vast.ai | A100 80GB PCIe | Verified on-demand | $1.001 | $100.10 | 2-GPU bundle at $2.002/hour |
| RunPod | RTX 4090 24GB | Community | $0.340 | $34.00 | Single GPU |
| RunPod | RTX 4090 24GB | Secure | $0.890 | $89.00 | Single GPU |
| Vast.ai | RTX 4090 24GB | Verified on-demand | $0.429 | $42.90 | 2-GPU bundle at $0.857/hour |
Two things stand out. First, the H100 SXM spread between the cheapest verified listing and the secure RunPod listing is $1.856 per GPU-hour, or 87% more for the secure tier. Second, the cheapest headline rate on the board is not always the cheapest job, because of the bundle minimum.
The two-GPU minimum is a commitment
Take an eight-hour fine-tune that fits on one H100 SXM.
At RunPod's community rate, the compute cost is:
8 hours * $2.69 = $21.52
At Vast.ai's H100 SXM rate, the listing is a two-GPU bundle at $4.269 per hour. If the job cannot use the second GPU, you still pay for it:
8 hours * $4.269 = $34.15 for 16 GPU-hours
You paid for 16 GPU-hours to do 8 GPU-hours of useful work. The effective cost is $4.269 per useful GPU-hour, not $2.134. The bundle is only a discount if you can run two single-GPU jobs in parallel or split the workload across both cards.
That is the first rule of GPU shopping: a two-GPU minimum is not a lower price, it is a larger commitment. Compare the smallest rentable unit, not the per-GPU rate.
Community versus Secure is not a 10% upsell
The tier names vary, but the trade-off is consistent: community or interruptible capacity is cheaper because the provider does not reserve it; secure or on-demand capacity costs more because it is isolated and more likely to stay up.
The observed premiums are large:
| GPU | Community / standard | Secure / reserved | Premium |
|---|---|---|---|
| H100 SXM 80GB | $2.690 | $3.990 | +48.3% |
| A100 80GB SXM | $1.390 | $1.790 | +28.8% |
| RTX 4090 24GB | $0.340 | $0.890 | +161.8% |
A 48% premium on an H100 is $1.30 per GPU-hour. On a 100-hour job, that is $130. Whether it is worth it depends on what a lost hour costs you.
If the job checkpoints every 15 minutes and can resume automatically, community capacity can be a rational choice. If the job is a deadline-bound inference service or a multi-day training run without checkpointing, the secure tier may be cheaper than the recovery work. The premium buys availability and isolation, not necessarily raw speed.
Utilization is the multiplier that never appears in the rate
You do not pay for useful GPU-hours. You pay for billed GPU-hours. If the GPU is waiting on data loading, a stuck download, or a serial preprocessing step, you still pay.
For 100 useful GPU-hours:
| Utilization | Billed GPU-hours | Vast.ai H100 SXM at $2.134 | RunPod Community H100 SXM at $2.690 |
|---|---|---|---|
| 100% | 100.0 | $213.40 | $269.00 |
| 80% | 125.0 | $266.75 | $336.25 |
| 60% | 166.7 | $355.67 | $448.33 |
At 60% utilization, the effective cost of a useful H100 SXM hour is $3.56 on the cheaper listing and $4.48 on the more expensive one. Neither number appears on the pricing page.
This is where data engineering matters more than GPU shopping. A fast NVMe path, a pre-tokenized dataset, and a loader that keeps the GPU fed can be worth more than a $0.50 rate difference. Measure tokens per second or images per second on your actual pipeline, not just the GPU model.
What 100 GPU-hours actually cost
On paper, Vast.ai's H100 SXM listing is $55.60 cheaper than RunPod's community listing for 100 GPU-hours:
$269.00 - $213.40 = $55.60
That is a 20.7% saving. Now add one operational incident. A 45-minute interruption at a $65 per hour engineering cost is $48.75. That single incident consumes 88% of the saving. Two incidents and the cheaper listing is more expensive.
The arithmetic is not an argument against the cheaper listing. It is an argument for checkpointing, monitoring, and a restart budget. If your job can tolerate interruption and you have automated recovery, the saving is real. If every failure requires a human, the saving is a subsidy for your future self.
Storage and egress can add smaller but real amounts. Using explicit assumptions of $0.10 per GB-month for storage and $0.05 per GB for egress, a 500GB dataset kept for seven days costs about $11.67, and 200GB of egress costs about $10.00. Those are illustrative rates, not quotes. The point is to put them in the model instead of discovering them on the invoice.
The only number to put in the budget
Use this formula:
effective $ / useful GPU-hour =
(hourly rate * billed hours + storage + egress + restart cost)
/ useful GPU-hours
Example: 100 useful hours on the Vast.ai H100 SXM listing at 80% utilization.
billed hours = 100 / 0.80 = 125
compute = 125 * $2.134 = $266.75
storage + egress + restart = $15 + $10 + $20 = $45
total = $311.75
effective rate = $311.75 / 100 = $3.12 per useful GPU-hour
The headline rate was $2.134. The budget number is $3.12, about 46% higher. Run the same calculation for the secure tier and for your own utilization. The ranking can change.
A decision guide that survives real workloads
| Workload | Sensible first test | Why |
|---|---|---|
| Single 8-hour fine-tune | RunPod Community H100 SXM or A100 80GB | No bundle minimum; $21.52 or $11.12 for eight hours at observed rates |
| Long, checkpointable batch | Vast.ai verified on-demand | Lowest observed $/GPU-hour, but budget restarts and verify the bundle |
| Production inference | Secure or on-demand with capacity | Availability and isolation matter more than a $0.50 difference |
| Multi-GPU training | Compare bundle price and interconnect | A two-GPU bundle can fit, but verify NVLink and topology |
| Cost-sensitive small models | RTX 4090 24GB | Lowest $/hour, but 24GB VRAM is not an H100 substitute |
The RTX 4090 row is a reminder that the cheapest GPU-hour is not always the right GPU-hour. If the model does not fit in 24GB, a $0.34 rate is irrelevant. If it does fit, the same 100 GPU-hours cost $34 on RunPod Community versus $269 on H100 SXM. The workload decides.
What I would do with a $200 budget
Do not start with 100 GPU-hours. Start with 20 to 40 GPU-hours on the smallest rentable unit that fits the model. Measure throughput, not just latency to first token. Checkpoint every 15 minutes. Log the cost per useful GPU-hour, including storage and egress.
Then compare the effective rate, not the advertised rate. A provider that is 20% cheaper per GPU-hour but interrupts twice as often may lose. A provider that is 20% more expensive but keeps the GPU fed may win.
The public index and the underlying observations are here:
- GPU cloud price index: gpu.mybskm.top
- Pricing methodology: GitHub repository
- Scraping API cost calculator: scrape.mybskm.top
Disclosure: Some outbound links on this page are affiliate links. If you buy a service through them, I may earn a commission at no extra cost to you. Rates are catalogue observations, not quotes, and inventory changes. Verify current pricing, storage, egress, and interruption policy with the provider before committing budget.
Data note: GPU rates observed 2026-10-17T12:50:44Z from RunPod's GraphQL catalogue and Vast.ai's bundles API. Secure and community availability is not guaranteed. Storage, network, taxes, and restart overhead are excluded from the headline rates.
Top comments (2)
The "cost per useful GPU-hour" framing is the part most people skip, and it's the only number that survives contact with a real bill. Two line items I'd add to your fully-loaded total: cold-start time and data-in. On a lot of marketplaces the clock starts when the instance is allocated, not when your job starts — so a 4-minute image pull on a fat CUDA container is billed at the H100 rate before you've run a single step, and it recurs on every interruption/resume. And egress gets the attention, but ingress latency hurts too: if your dataset lives in object storage and the box has a slow mount, you pay premium GPU-hours to sit idle waiting on I/O. On interruptible/community tiers we found the real tax wasn't the lower reliability per se, it was checkpoint-and-resume overhead — frequent checkpointing to survive preemption eats both time and storage. Did you track allocation-to-first-step time separately in your samples? That gap is where the "headline rate" lie compounds fastest.
The spread between community listings and on-demand is effectively the price of an unhedged call option. When an operator rents interruptible capacity, they are selling the marketplace the right to reclaim silicon on zero notice whenever a higher-margin buyer appears.
The reason that discount looks appealing on a spreadsheet and fails in execution is the convexity of interruption cost. On an uncheckpointed eight-hour run, getting preempted at hour seven does not cost one-eighth of the budget. It destroys seven hours of paid compute, storage, and egress for an realized output of zero. Unless checkpoint frequency is calibrated so the resume interval is shorter than the hazard rate of preemption, the expected cost per completed run blows out past the on-demand reservation price.
The multi-GPU bundle requirement creates a similar balance sheet distortion. When a marketplace forces a single-card fine-tune into a two-accelerator node, the second GPU is pure deadweight loss unless tensor parallel throughput offsets the inter-card communication overhead. If the model does not scale linearly across the link, the effective cost per useful token easily doubles before accounting for I/O wait.