GPU Serverless Billing and Hidden Costs

A request is not necessarily a billing session

A short HTTP request may run on an already warm worker, while another request may cause a new worker to load its environment and model. Several requests may share one worker lifetime. Apply a session minimum to the provider’s actual billing interval, not automatically to each request.

Runpod’s serverless pricing documentation describes worker startup, execution and idle time as billing components, with billed time rounded to seconds. That supports asking about these components; it does not supply a universal cold-start duration. Use a representative trace from your workload to estimate how often starts occur and how long workers remain paid after useful work finishes.

One transparent billing comparison

The GPU Burst Billing Calculator implements a specific rule: take useful execution plus billable startup and idle, apply a session minimum, then round up to whole billing increments. It models sequential sessions on one complete worker. A tariff with a different rounding convention needs a different calculation.

billed session seconds = ceil(max(minimum, work + startup + idle) / increment) * increment
burst cost = sessions * billed session seconds / 3,600 * worker hourly rate + extras
always-on cost = window hours * worker hourly rate + extras

Consider an original illustrative scenario with 1,000 sessions. Each session performs 20 useful seconds and incurs 30 billable startup seconds plus 10 billable idle seconds. With a 60-second minimum and one-second increments, the workload consumes 16.667 billable worker-hours but only 5.556 useful worker-hours. A hypothetical $3-per-hour rate plus $20 persistent costs yields $70. An equivalent worker at a hypothetical $2 per hour for 730 hours plus $20 extras costs $1,480.

The comparison assumes equivalent useful execution time and capability. It does not show that every provider starts in 30 seconds, that every tariff has a one-minute minimum, or that an autoscaler will produce precisely 1,000 sessions. The tool rejects sessions that cannot fit sequentially in the selected window; concurrent workers need an explicit extension or separate scenarios.

Persistent resources have a different clock

Stopping useful work does not necessarily stop every charge. Runpod’s Pod pricing documentation distinguishes running and stopped volume storage, and its network-volume documentation describes storage that has an independent lifetime and tiered pricing. Read each tier as specified rather than assuming a lower marginal tier applies retroactively to every stored byte.

A required account balance is also different from a billing minimum. The Pod documentation discusses having enough credit to deploy while separately describing billing intervals. Do not turn an account-funding requirement into a claimed minimum usage charge.

For your own comparison, keep provisioned storage, snapshots, public addresses, CPU/RAM supplements, data transfer, support and plan fees as separate inputs whenever they are billed separately. Modal’s pricing page presents distinct resource and plan components; a GPU-only rate is therefore not automatically a complete-worker total. Unknown charges belong in a review queue, not silently at zero.

Compare equivalent periods and risks

Use the same comparison window for compute and persistent extras. GB-month, GiB-month and an hourly disk meter need their actual unit definitions; 730 hours is a convenient scenario input, not the length of every month. For a setup charge, show the upfront cost and explain any amortization period rather than concealing it in a low hourly headline.

Spot interruptions, retries and checkpoint transfer add another source of paid nonproductive work. This calculator does not invent interruption probabilities. Enter observations in a separate scenario and keep on-demand and interruptible offers distinguishable in the GPU explorer.

Finally, use request economics when the decision is how much a completed inference request costs. Billing efficiency and serving efficiency answer different questions: a perfectly utilized worker can still be an expensive way to run a particular model.