DEV Community: 600me

The H100 Rental Trap: Why $2.13 per GPU-Hour Is Not the Price You Pay

600me — Sun, 18 Oct 2026 14:35:56 +0000

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.

The 403 Tax: What Anti-Bot Protection Really Does to Your Scraping Bill

600me — Sun, 18 Oct 2026 14:35:52 +0000

The crawl finished at 06:00. The job log says 100,000 requests. The dataset has 68,000 usable rows, 22,000 challenge pages, and 10,000 timeouts. The invoice counts 100,000 requests plus every retry, every JavaScript render, and every premium-proxy attempt.

That gap between requests sent and pages usable is the 403 tax. It is invisible on a pricing page, and it is the number that decides whether a scraping API is cheap or expensive.

This is a cost-first teardown of the problem. I use the normalized plan inputs published on scrape.mybskm.top, walk through the arithmetic, and then show a two-hour pilot that produces a better buying decision than any vendor comparison table.

The invoice counts attempts, not answers

A scraping API is not a bandwidth pipe. It is a request orchestrator: it chooses an IP, opens a TLS session, may execute JavaScript, may solve or wait out a challenge, and may retry. Every one of those steps can consume a credit.

That is why two providers can both advertise "$49 per month" and produce very different bills. The useful unit is not the request. It is the usable page: a response that contains the fields your pipeline needs, at the time you need them.

A 200 response with a Cloudflare interstitial is a failure. A 403 with a valid cached copy may still be a success if your pipeline is allowed to use the cache. A timeout after 30 seconds may have consumed a credit even though it produced nothing. Your accounting has to follow the output, not the status code.

A residential IP is not a Turnstile pass

Cloudflare, DataDome, and Akamai do not make a single decision. They combine signals:

IP reputation and ASN type.
TLS fingerprint and HTTP/2 settings.
Header order and browser fingerprint.
Cookie and challenge-token state.
Request rate, navigation pattern, and mouse or keyboard behavior.

A residential IP helps with the first signal. It does not automatically produce a valid Turnstile token. Turnstile requires JavaScript execution in a browser-like environment, and that execution is usually billed at a higher credit multiplier. DataDome and Akamai apply similar layered checks.

This is the practical reason "just buy residential proxies" often disappoints. You can move the IP and still fail the browser and token checks. A managed scraping API bundles the browser, the proxy, and the retry logic, but it charges for all three.

The credit multiplier is the real price list

The public calculator normalizes four providers to a common baseline. The inputs below were observed on 2026-10-17. They are planning baselines, not fresh vendor quotes, and the site explicitly labels them that way.

API (baseline input)	Plan	Included credits	Cost / credit	10k @ 1 credit	10k @ 5 credits	10k @ 25 credits
ZenRows	$49	250,000	$0.000196	$1.96	$9.80	$49.00
ScrapingBee	$49	150,000	$0.000327	$3.27	$16.33	$81.67
ScraperAPI	$49	100,000	$0.000490	$4.90	$24.50	$122.50
Crawlbase	$29	not specified	n/a	n/a	n/a	n/a

The formula is simple:

cost per request = plan price / included credits * credits per request

At one credit per request, the difference between the cheapest and most expensive normalized option is $2.94 per 10,000 requests. At 25 credits per request, it is $73.50. The multiplier, not the plan price, controls the spread.

Crawlbase is deliberately left as n/a. Its supplied baseline does not state the included paid request volume, so the $2.90 per 10,000 estimate cannot be converted into a per-credit rate. Treating it as comparable would be a spreadsheet error dressed up as analysis.

Retry amplification: the line item finance never sees

Suppose you need 100,000 URLs. Thirty percent hit a challenge or a 403. A naive retry policy tries each failed URL three times. You now bill:

70,000 non-challenged attempts + 30,000 challenged URLs * 3 attempts = 160,000 billed attempts

If every attempt costs one credit, the allocated cost at the normalized rates is:

Billing assumption	Billed credits	ZenRows	ScrapingBee	ScraperAPI
1 credit per attempt	160,000	$31.36	$52.27	$78.40
5 credits per challenged retry	520,000	$101.92	$169.87	$254.80

The second row is the important one. It assumes 70,000 clean requests at one credit and 30,000 challenged requests at three attempts times five credits. That is 520,000 credits for a job that "only" had 100,000 URLs.

These are allocated plan costs, not necessarily the provider's overage price. Overage rates can be higher, and plans may throttle or block before overage. The point is directional: a retry policy without a credit budget is an open-ended invoice.

Cost per 1,000 usable pages

The metric to put in the budget is:

cost per 1,000 usable pages =
  (cost per credit * credits per attempt) / usable yield * 1,000

Using the normalized rates and an explicit 70% yield assumption:

API	$ / 1k attempts (1 credit)	$ / 1k usable at 70%, 1 credit	$ / 1k usable at 70%, 5 credits
ZenRows	$0.196	$0.280	$1.400
ScrapingBee	$0.327	$0.467	$2.333
ScraperAPI	$0.490	$0.700	$3.500

Seventy percent is an assumption, not a measurement. It is there to make the arithmetic visible. If the supplied baseline success rates of 98.5%, 97.8%, and 96.5% held, the one-credit numbers would be $0.199, $0.334, and $0.508 per 1,000 usable pages. Those rates are supplied planning inputs, not independent target measurements, so your own pilot still decides.

The 5-credit column is the part most teams miss. A provider with a lower per-credit price can lose on a target that forces JavaScript rendering on every request. The opposite is also true: a provider with a higher per-credit price can win if it avoids retries and returns clean data on the first attempt.

A two-hour pilot that beats any comparison table

You do not need a 10,000-request benchmark to make a good decision. You need a representative sample, a definition of usable, and honest accounting.

Pick 200 URLs. Stratify by template, not by random pages. Include the pages that produce the most revenue or the most support tickets.
Define usable before you run. A product page is usable only if the price, currency, and availability fields are present. A listing page is usable only if it returns the expected number of items. Hash the relevant fragment, not the whole HTML, so rotating ads do not create false negatives.
Run three times. Morning, midday, and evening in the target geography. Use the same session settings and the same timeout. Record status, latency, bytes, and credits consumed.
Count retries as cost. If your client retries three times, the pilot must record three attempts. Otherwise the result is a demo, not an economic measurement.
Compute the useful number. Cost per 1,000 usable pages, not cost per request. Add the engineering time spent on the integration.

A minimal standard-library probe looks like this:

import hashlib
import json
import time
import urllib.request

TARGET = "https://example.com/product/123"
MARKER = "Add to cart"

def probe(url):
    request = urllib.request.Request(
        url, headers={"User-Agent": "cost-pilot/1.0"})
    started = time.perf_counter()
    with urllib.request.urlopen(request, timeout=30) as response:
        body = response.read()
        status = response.status
    return {
        "status": status,
        "seconds": round(time.perf_counter() - started, 3),
        "usable": MARKER.encode() in body,
        "sha256": hashlib.sha256(body).hexdigest()[:16],
    }

print(json.dumps(probe(TARGET)))

Run that through your provider's endpoint and through a direct baseline. The direct baseline tells you what the target does without a proxy. The provider result tells you what you are buying. If the direct baseline is already 95% usable, a managed API may still be worth it for maintenance and IP rotation, but you should price it as an operational convenience, not as a magic bypass.

What I would do with a $49 budget

Start with the free trial, not the annual plan. Run the 200-URL pilot. Measure usable yield and credits per usable page. Then decide whether the problem is IP reputation, browser execution, or your own parser.

Three rules have saved me more money than any vendor comparison:

Cache before you crawl. A page that has not changed does not need a new credit.
Use the official API when one exists. It is usually cheaper, more stable, and less likely to trigger a challenge than scraping the HTML.
Set a retry budget. If a URL fails three times, park it and alert. Infinite retries convert a temporary block into a permanent cost.

The conclusion that survives contact with production

The cheapest scraping API is not the one with the lowest sticker price. It is the one with the lowest cost per usable page at your target, your geography, and your required freshness.

That number depends on three variables you control: the credit multiplier of the request mode, the yield of the target, and the retry policy. A provider that looks 60% cheaper per credit can be 2.5x more expensive per usable page once rendering is included. A provider that looks expensive can win if it returns clean data on the first attempt.

Run the arithmetic before you run the invoice. The calculator and the underlying baseline are public:

Scraping API cost calculator: scrape.mybskm.top
Residential proxy economics: proxy.mybskm.top
Methodology and data: GitHub repository

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. The baseline figures are supplied planning inputs, not independently measured target results or current vendor quotes. Verify current pricing and terms with each provider before purchasing.

Data note: Normalized plan inputs observed 2026-10-17T12:39:14Z. Success rates and 10k estimates are supplied baselines, and performance was not independently measured. HTTP 200 is not proof of bypass success.