In short. RunPod pricing is usage-based. Pods bill per second and stop costing money when you terminate them, but volume storage keeps billing per GB per month, at a higher rate once the pod is stopped, and serverless workers bill for every second they stay warm. RunPod documents no ingress or egress fees. The model is cheap for short bursts and expensive for anything that runs most of the day.
Per-second billing is a real advantage when your GPU work is spiky. Fine-tune a model on Tuesday, run nothing on Wednesday, pay for Tuesday. The trouble starts when people price a steady workload the same way, multiply an hourly rate by the hours they think they will use, and then find the invoice higher than the estimate. The gap comes from the things that bill while the GPU is doing nothing. Here is how the model is put together, and where a fixed monthly cost overtakes it.
How RunPod pricing works
RunPod pricing is consumption-based, charged against a prepaid credit balance rather than a monthly bill. You add funds, and compute and storage draw down against them per second as you use them. Nothing is reserved for you by default, and nothing is refunded for capacity you booked and did not use, because you never booked any.
Compute comes in two shapes. Pods are persistent GPU containers you start, use, and terminate yourself, billed for every second they exist in a running state. Serverless endpoints wrap a container behind an API and scale workers up when requests arrive. Flex workers scale to zero between jobs. Active workers stay running around the clock and skip the cold start, which is faster and bills every hour they stay up. For the current structure of both, RunPod documents them at Pods pricing and Serverless pricing.
The GPU rate itself depends on which fleet you land in. Secure Cloud runs in T3/T4 data centers. Community Cloud runs on peer-to-peer providers and is aimed at cost-sensitive work, with variable reliability, which matters more for a 40-hour training run than for a 10-minute inference test. Pods are on-demand only: RunPod retired spot pods, and savings plans can no longer be purchased.
Two things make the model genuinely attractive. Billing granularity is per second rather than per hour, so a six-minute job costs six minutes. And RunPod documents no data transfer fees in either direction, which differs from hyperscaler GPU instances that meter outbound traffic per GB.
Storage is where the model stops being pay-per-use in any intuitive sense. Container disk is erased when you stop a pod and costs nothing after that. Persistent volume storage keeps billing, and RunPod charges a stopped volume at twice the per-GB rate it charges while the pod runs. Stopping a pod that holds 200 GB of model weights starts a higher recurring charge at the moment you stop the machine, and it runs until you delete the volume.
What adds up beyond the hourly rate
The hourly GPU rate is one line on a RunPod invoice, and the rest comes from categories that are easy to leave out of an estimate. The table below lists what to account for before comparing a per-second rate against a monthly one.
| Cost category | What triggers it | Why estimates miss it |
|---|---|---|
| GPU compute | Every second a pod is in a running state | Usually the only line people estimate |
| Data transfer | Moving data into or out of the platform | RunPod documents no fee, so the line is usually zero, but check large cross-region moves |
| Volume storage, running | Persistent disk attached to a live pod | Sized for the largest model you might load, not the one you use |
| Volume storage, stopped | The same disk after you stop the pod | Billed at twice the per-GB rate it costs while running |
| Network volume | Shared storage mounted across pods | Bills hourly rather than per second, and keeps billing while pods are stopped |
| Serverless warm time | Idle timeout after a request completes | The worker shows as running and bills as running |
| Active serverless workers | Workers held permanently online | Deliberately 24/7, so the per-second model no longer saves anything |
| Serverless cold starts | A worker loading its model, or pulling its image if the host does not have it yet | Cold-start time bills as running time |
The last row catches teams that let serverless workers scale to zero. Billing starts when a worker starts, so the time your handler spends loading a model into GPU memory is billed, and so is an image pull when the image is not yet on the host. Spread that across many short jobs and the warm-up becomes a line item. Startup overhead is the tax you pay for not keeping anything running, and it scales with how often you start things.
When a dedicated GPU VPS costs less over time
A dedicated GPU VPS costs less than RunPod once your GPU is busy for more hours per month than the flat monthly price divided by the hourly rate for a comparable card. A GPU VPS is a virtual server with a dedicated GPU, billed at a fixed monthly rate regardless of how hard you run it. That division is the whole comparison. Run it with current rates rather than remembered ones, because both numbers move. Above the break-even line the fixed cost keeps winning, since every additional hour on the VPS is free.
Utilization is the variable that decides it, and most teams underestimate their own. An inference endpoint that answers requests during European business hours needs to be warm for nine hours a day, five days a week, which is around 195 hours a month before you count the warm-up time between requests. A model you are actively fine-tuning over a sprint keeps the GPU busy just as steadily. Genuinely spiky work looks like a weekly batch job or an experiment you run twice and abandon, and for that RunPod is the cheaper answer by a wide margin.
RunPod is best for: short training runs, one-off experiments, workloads that need a specific high-end GPU for a few hours, and teams that want to test three GPU models before committing to one. Not ideal for: anything that needs to stay warm, long-running services, or workloads where the monthly spend has to be predictable before the month starts.
A dedicated GPU VPS is best for: inference endpoints that serve traffic on a schedule, self-hosted LLM deployments behind an internal tool, ongoing fine-tuning work, and any case where finance wants one number rather than a usage report. Not ideal for: occasional experiments, workloads that need a GPU class the provider does not offer, or bursts that exceed a single machine.
The Contabo GPU VPS sits in the fixed-cost category. It gives you root access to a virtual server with a dedicated NVIDIA RTX PRO 6000 Blackwell GPU, passed through over PCIe with 96 GB of VRAM, alongside 18 vCPUs and 96 GB of RAM. Inbound traffic is unmetered and outbound traffic is unlimited under a fair use policy, so there is no per-GB egress line at all. The invoice reads the same whether the card runs at 5% or 95%.
One honest caveat before you switch. A GPU VPS does not scale to zero, and it does not scale up either. If your load doubles, you buy a second machine rather than letting a scheduler handle it. Reading a RunPod review or a provider comparison will not settle the cost question for you, because the answer turns on a number only you have, which is how many GPU hours a month your workload actually consumes. Measure that over two normal weeks, then do the division.
FAQ: RunPod pricing
Is RunPod cheaper than a dedicated GPU server?
RunPod is cheaper for low utilization and more expensive for high utilization. Because it bills per second, a workload using a GPU for 40 hours a month almost always costs less on RunPod than a dedicated server rented for the full month. The crossover sits where the fixed monthly price divided by the hourly rate equals your actual monthly GPU hours. Measure yours, then divide.
Does RunPod charge for idle time?
RunPod charges for some idle states and not others. A serverless worker inside its idle timeout window still shows as running and still bills, even with no requests in flight. A worker that has fully scaled down is not billed. Storage is the real idle charge, since volumes keep billing after you stop the pod attached to them.
What’s the cheapest way to test a workload before committing?
Run the workload on a per-second platform first and measure how many GPU hours it actually consumes over two normal weeks. That measurement, not a rate card, tells you which pricing model fits. Keep the test short, delete volumes you are not using, and record cold-start time separately, because billed warm-up time distorts small-sample estimates more than anything else.
Does RunPod charge for data transfer?
RunPod documents no fees for data ingress or egress, which sets it apart from hyperscaler GPU instances that meter outbound traffic per GB. The Pods pricing and billing pages state it without qualification, though RunPod’s own comparison articles hedge it for intra-platform transfers, so confirm the terms if you regularly move large datasets. For most inference and fine-tuning work, transfer is not a cost line you need to model.
