RunPod GPU pricing: Community Cloud vs Secure Cloud

Every GPU you rent runs in one of two environments, and the same card costs meaningfully more in one than the other. 

Community Cloud puts you on hardware from vetted third-party hosts across a distributed network. Secure Cloud puts you in data centre capacity RunPod operates itself, where availability is more predictable.

Here's the full RunPod GPU cloud pricing card, both tiers, verified 18 August 2026:

The premium column is mine, calculated from RunPod's two published rates. RunPod doesn't publish it, and the pattern in it is the most useful thing on this page.

How RunPod prices GPU configurations

RunPod prices the whole Pod spec, not just the GPU. That's the part most comparison tables miss, and it's why the same GPU name shows up at different prices across providers and inside RunPod itself.

Take the four separate 80GB SKUs on the card above. Ask for the RunPod A100 80GB price per hour and there are two answers, because A100 PCIe costs $1.39 on Secure Cloud and A100 SXM costs $1.59. The H100 80GB pair does the same thing at $2.89 and $3.29. Same memory, different price, because you're paying for the interconnect and the CPU and RAM bundled with it.

SXM variants use NVLink, which gives you far more bandwidth between GPUs and better multi-GPU scaling. PCIe variants cost less and move data more slowly. For single-GPU inference where you're not saturating the bus, PCIe is fine and you're overpaying for SXM. For distributed training across several cards, the SXM premium buys you real throughput, and paying 14% more to avoid a bandwidth bottleneck is an easy trade.

The vCPU and RAM allocations differ too, and RunPod publishes them next to each rate. An H100 PCIe comes with 16 vCPUs and 188GB of RAM. An A100 PCIe comes with 8 vCPUs and 117GB. If your pipeline does heavy CPU-side preprocessing, that gap matters as much as the GPU.

What about RunPod CPU pricing?

RunPod prices CPU pods per vCPU, and it doesn't publish the rates on its pricing page. You pick a CPU flavour and a vCPU count, and RunPod derives the memory from that flavour's RAM multiplier, so the vCPU is the billable unit. 

I want to be precise here because it's the one number in this article I can't pull from a rate card. RunPod's catalog API returns a price object per flavour with two fields, one for secure and one for serverless, and the documented example shows a Gen 3 Compute-Optimized flavour scaling from 2 to 32 vCPUs at 2.5GB of RAM per vCPU, priced at $0.04 per vCPU for secure and $0.03 for serverless.

That's an example payload in API docs, not a published price. For live CPU rates, call GET /v2/catalog/cpus or check the console during deployment. It's a strange gap in an otherwise transparent rate card, and if you're sizing a CPU-heavy preprocessing tier, don't plan around the docs example.

RunPod serverless pricing

RunPod Serverless bills per second of active execution and charges nothing while no request runs. Flex worker rates start at $0.58 an hour for a 16GB class GPU and reach $9.98 for a B300. That scale-to-zero behaviour is the entire reason to accept an active rate roughly 65% above the equivalent Pod.

Current serverless flex worker rates, verified 18 August 2026:

RunPod claims this saves you 25% over other serverless GPU providers on flex workers alone. Reservations exist for both active and flex workers at a discount, priced by talking to their sales team rather than published.

RunPod storage and network volume pricing

Storage is where RunPod bills quietly, and it's the section of the rate card most guides get wrong. There are four storage types, not two, and one of them behaves in the opposite direction to what most people assume.

Verified against RunPod's Pod pricing docs, 18 August 2026:

Read that first row carefully, because it's the opposite of what circulates online. Container disk costs you nothing once the Pod stops, since RunPod deletes it. Stopping a Pod doesn't leave a container disk quietly billing in the background, it destroys your data.

The cost controls RunPod gives you

RunPod ships three cost controls that barely get discussed, and all three change how you plan.

Your account carries a default spend limit of $80 an hour across all resources, raised only by contacting support. 

That's a real ceiling on a runaway script, and I'd guess most teams have never looked at it. Worth checking before you plan a large cluster job that would breach it.

RunPod charges nothing for data ingress or egress. Not a discounted rate, nothing. If you're moving model weights and datasets in and out repeatedly, that removes a line item that would dominate the same workload on a hyperscaler.

Storage isn't billed while the host machine is unavailable, so you're not paying for capacity you can't reach.

What RunPod actually costs per million tokens

Dollars per GPU-hour isn't the unit anyone budgets in. If you're serving inference, you care about cost per million tokens, and converting between the two takes one formula:

• Cost per million tokens = (1,000,000 / tokens per second) / 3,600 x hourly rate

• Serve a 70B model with vLLM at roughly 1,200 tokens a second and a million tokens takes about 0.23 GPU-hours. 

• On an H100 PCIe that's $0.46 per million tokens on Community Cloud and $0.67 on Secure. 

• Move the same workload to serverless at $4.79 an hour and it's $1.11.

Throughput dominates that result, which is the trap. A cheaper GPU that serves half the tokens per second costs you more per million, so the rate card alone can't tell you which card is cheapest for your model. 

Benchmark your own throughput before you optimize the hourly rate, and if you want to compare what different tools show you about that spend, we've reviewed the AI cost tracking tools worth using.

When RunPod pricing works best

RunPod isn't the cheapest or the simplest GPU cloud, and it's one of the most configurable. If you understand the meter, you can get real value out of it.

It works best in four situations:

• Bursty or variable workloads, where per-second billing means a short inference job or a testing environment costs what it used, not a rounded-up hour.

• Teams optimising for dollars per unit of throughput rather than for simplicity, who'll compare vCPU, RAM and VRAM configurations to find the cheapest viable spec.

• Teams that want current hardware without an enterprise contract. B300, H200 and RTX Pro 6000 all sit on the on-demand card with no minimum commitment.

• Teams already handling state persistence, with checkpoints going to network volumes or object storage, who can therefore tolerate interruptible capacity.

Scale here is real, for what it's worth. Civitai told RunPod it trains over 800,000 LoRAs a month on 500-plus concurrent GPUs, which is a useful reference point when you're wondering whether a platform will hold up.

What to do next

Pull the current rates yourself before you commit anything. RunPod's rate card moves, this one carries an August 2026 date, and any guide including this one is a snapshot.

Then do three things. Check your account's $80 hourly spend limit against the largest job you plan to run. Audit your volume disks for anything idle that's billing at $0.20 a gigabyte. And run the utilisation division on your inference endpoints before you assume serverless is the cheaper option, because the break-even sits lower than most teams expect.

If you're reselling that compute, the harder problem starts after the GPU bill arrives. Read the metering and credits documentation at docs.flexprice.io, or run the open source build yourself and see how the events land.