—
cheapest platform / month—RunPod / month
—Baseten / month
—Modal / month
Cost spread — same nominal $/hour GPU rate
—
Billing breakdown, by platform
Same inputs as above, applied through each platform's distinct billing logic. Billed units/day is the raw quantity each platform actually charges for — seconds for RunPod and Modal, minutes for Baseten.
Monthly cost by cold-start rate (traffic burstiness)
Same duration, rate and buffer inputs as above, swept across cold-start rate — how spread out your requests are. The highlighted row is closest to your current cold-start rate input. Watch how the cheapest platform can change as traffic gets burstier.
| Cold-start rate | RunPod / month | Baseten / month | Modal / month | Cheapest |
|---|
How this connects to other tools
This calculator prices one specific, narrow question: for BURSTY, low-QPS inference traffic, how does the same nominal $/GPU-hour rate turn into very different real bills depending on a platform's billing mechanics — per-second, per-minute-rounded, or per-second-plus-keep-warm-buffer. It deliberately does not model flat-rate, high-utilization GPU rental, where you're paying for continuous hours regardless of request pattern — for that framing, see the GPU Cloud Cost Calculator and the GPU Rental Cost Calculator, which both treat GPU cost as $/hour × hours used. This tool exists precisely because that flat-rate math breaks down for sporadic, cold-start-prone workloads — an internal tool called a few hundred times a day behaves nothing like a busy API pinning a GPU at high utilization, and the billing shape difference between platforms only shows up once you model cold starts and idle time explicitly rather than assuming a flat rate times hours.
How this calculator works
The Serverless GPU Platform Billing Calculator splits your daily traffic into two buckets using the cold-start rate: cold requests (requests per day × cold-start rate) are ones that arrive after the container has scaled to zero and must pay the full cold-start duration plus the warm inference duration; warm requests (the remainder) hit an already-loaded container and only pay the inference duration. Each platform then applies its own billing logic to those two buckets. RunPod bills per-second for every second the container is active — cold or warm — so its daily bill is simply total active seconds ÷ 3,600 × your GPU hourly rate. Baseten bills per-minute and rounds every single invocation up to the next full minute, so even a 3-second warm call and an 11-second cold call each consume one full billed minute; its daily bill is total billed minutes ÷ 60 × the hourly rate. Modal bills per-second like RunPod for the actual compute, but adds the keep-warm idle buffer as extra billed seconds on every warm request — the container stays alive and billing for that buffer window so the next request can skip its own cold start.
The number worth watching is the monthly cost spread between the cheapest and most expensive platform — in the calculator's own worked default (200 requests/day, 3s warm, 8s cold-start, 40% cold-start rate, $2.49/hr) that spread is roughly 9-10x between RunPod and Baseten, at the exact same nominal hourly GPU rate. That gap is not a pricing trick — it's what happens when a workload's typical call duration (a few seconds) collides with a billing granularity built for longer jobs (a full minute). The shorter and more sporadic your calls, the more this shape matters more than the sticker $/hour rate. This tool models the MECHANICS documented publicly by these kinds of platforms — per-second billing, per-minute rounding, keep-warm buffers — as an approximation to show the shape of the difference; always check current vendor pricing pages before committing, since exact rates and rounding rules can change.
Frequently asked questions
Why does Baseten cost more than RunPod for the same GPU?
Not because the underlying GPU rate is different — in this comparison both are billed at the same $/hour — but because of how each platform rounds the clock. RunPod's serverless billing is per-second: you pay for exactly the seconds the container is active, cold-start load time included, and nothing more. Baseten bills per-minute and rounds every invocation UP to the next full minute. A warm 3-second inference call still gets billed as a full 60-second minute, and an 11-second cold-start call gets billed as that same full minute too, because both round up to 1. For a bursty, low-QPS workload where most individual calls are only a few seconds long, that rounding is brutal: you're effectively paying for 15-20x more compute time than you actually used on every single call. The gap isn't a pricing gimmick, it's pure minute-granularity rounding applied to very short jobs, and it compounds every time the workload is this short and this frequent.
What is a 'cold start' and why does it cost money?
A serverless GPU platform doesn't keep a container running (and billing you) when nothing is happening — it scales the container down to zero after a period of inactivity to save you money on idle time. The tradeoff is that the next request after a scale-to-zero has to wait for a brand-new container to spin up: pull the container image, load the model weights onto the GPU, initialize the runtime, and only then start actual inference. That load process is the "cold start," and on GPU-hosted LLM or inference workloads it commonly takes several seconds to tens of seconds, because model weights can be gigabytes and moving them onto GPU memory isn't instant. Crucially, that loading time isn't free compute time being donated to you — the GPU is fully allocated and billing during it on every platform modeled here, exactly like it would be during actual inference. So every cold-start request effectively costs you the cold-start seconds PLUS the actual inference seconds, and the more spread out (bursty) your traffic is, the more of your requests hit a cold container instead of a still-warm one, and the more of your total bill is pure loading overhead rather than useful compute.
Should I use a keep-warm buffer for my inference workload?
It depends on whether you're optimizing for latency or for cost, and those two goals pull in opposite directions for bursty traffic. A keep-warm buffer (modeled here as Modal's approach) holds the container alive and loaded for a window after each request finishes, so if the next request arrives inside that window it skips the cold start entirely and responds fast. That's a real user-experience win for latency-sensitive traffic. But you are paying full GPU-active pricing for every idle second the container sits there waiting, whether or not another request ever arrives in time — the calculator's Modal model adds the idle buffer as billed seconds on every request that benefits from a warm container. For very sporadic traffic — long, unpredictable gaps between calls — that idle time is mostly wasted money, because the buffer expires before the next request shows up anyway and you paid for it for nothing. Keep-warm buffers make the most economic sense when request gaps cluster just inside the buffer window; for truly random or rare traffic, eating the occasional cold start is usually cheaper than paying to keep a GPU warm on the off chance the next call arrives soon.
Is per-second or per-minute GPU billing better for bursty traffic?
For bursty, short-duration traffic, per-second billing is almost always better, and the shorter your typical inference call is relative to a minute, the bigger the advantage. Per-minute billing that rounds up (like Baseten's model here) charges a full minute no matter whether the actual compute took 3 seconds or 55 seconds — the billing granularity is coarser than the workload, so short calls get taxed the hardest in percentage terms. Per-second billing (like RunPod's and Modal's active-compute portion here) charges close to exactly what was used, so a 3-second call costs roughly a twentieth of a 60-second call instead of the same amount. The one place per-minute billing stops being a clear disadvantage is when your typical call duration is already close to or above a minute — the rounding waste shrinks toward zero as call length approaches the billing granularity. For an internal tool or sporadic API called a few hundred times a day with multi-second responses, minute-rounded billing can easily turn out to be an order of magnitude more expensive than per-second billing at the identical nominal hourly GPU rate.