The short version: serverless GPU compute is cheaper whenever your GPU would sit idle more than about a third of the time — which covers almost every early-stage, bursty, or human-facing workload. Once you're saturated, a dedicated GPU wins. Everything below is the arithmetic behind that sentence, the September 2026 prices, and the cold-start tax nobody quotes you up front.
Serverless GPU compute means you deploy a container or a function, the platform puts it on a GPU only while a request is actually running, bills you by the second of that active time, and scales the whole thing to zero when no traffic is in flight. An idle service costs $0. A dedicated GPU is the opposite deal: you rent the card and hold it 24/7, paying for every hour whether it's doing work or not. That single difference — idle time is free vs. idle time is billed — is the entire decision.
The crossover, in one line#
The whole cheaper-or-not question is one number — your utilization — and the arithmetic is quick. A dedicated on-demand H100 pod runs about $2.89/hour, billed for all 730 hours a month (≈ $2,110), busy or not. A serverless H100 costs more per active hour (about $3.95 on Modal) but $0 while idle. Divide $2,110 by $3.95 and you break even near 530 active hours — about 70% of the month. Below that, serverless is cheaper; above it, the dedicated card is, and the spikier your traffic the more lopsided it gets (a service busy two hours a day costs ~$240/month serverless versus $2,110 dedicated).
That break-even is the entire decision, and it deserves more than a paragraph: our companion piece on serverless GPU vs dedicated instances works the duty-cycle math against reserved and committed capacity in full. For the dedicated side of the ledger, what it actually costs to rent an H100, H200, or B200 has the current floors, and how to actually pick a GPU cloud covers the always-on providers. This piece is about the layer above that decision: which serverless providers exist, what they charge, and how they differ.
The September 2026 price table#
The serverless field has stopped being interchangeable. Per active H100-hour, cheapest to priciest, with the tradeoff each one is really selling:
- Beam — ~$3.20/hr. The cold-start specialist: warm pools bring the first response down to about 2 seconds. Pick it when latency is the KPI.
- Modal — ~$3.95/hr ($0.001097/sec). The developer experience leader. The GPU behaves like a decorated Python function, with volumes, secrets, and scheduled jobs built in; image snapshots keep cold starts around 2–4 seconds.
- RunPod Serverless (Flex) — ~$4.55/hr. The cheapest control. You bring raw Docker and get the least lock-in; cold endpoints boot in ~5–8 seconds, which "active workers" shrink for a fee. If you know GPU ops, this usually wins on total cost.
- Replicate — ~$5.49/hr ($0.001525/sec). The least effort. Push a model, get an API — the fastest path to serving a public model, at roughly the highest per-hour rate.
- Baseten — ~$6.50/hr per dedicated replica ($0.108/min). Polished production serving with real autoscaling. It offers scale-to-zero, but its own docs recommend keeping a minimum of two replicas warm in production for reliability — which quietly turns it back into an always-on bill. Read the fine print before you count on the zero.
Once you've settled on serverless and need to choose between them on more than price, our head-to-head — Modal vs Replicate vs RunPod vs Baseten — argues that the packaging format (a Python decorator, Cog, Truss, or raw Docker) is the choice that actually follows you for years, not the per-second rate.
The cold-start tax#
The number the pricing pages bury is the cold start: after a replica scales to zero, the next request has to schedule a GPU, restore your container, and load model weights into VRAM before it can answer. In September 2026 that's roughly 2 seconds on Beam's warm pools and Modal's snapshots and 5–8 seconds on a cold RunPod endpoint, with weight-loading time growing with model size.
That tax is invisible for batch scoring and background jobs, tolerable for an async API, and brutal for a human waiting on a response. Every fix costs money and partially unwinds the scale-to-zero savings: keep a replica warm, pay for a provider with fast snapshot restores, or pre-warm around predictable traffic. Budget the cold start honestly — it's the difference between "serverless is free while idle" and "serverless is free while idle and my first user waits eight seconds."
The decision, compressed#
- Spiky, bursty, early-stage, or human-facing traffic → serverless. You're paying for seconds of work, not idle hours.
- Cold start unacceptable and traffic steady → keep replicas warm, or move to a dedicated GPU.
- Utilization consistently above ~70% → a dedicated GPU is cheaper; stop paying the serverless premium.
- Long training runs → dedicated or spot capacity, never serverless — a training job never goes idle, so there's no scale-to-zero to save you.
Serverless GPU compute is the correct default for almost everything you'll ship early, precisely because early traffic is lumpy and the idle hours are free. The day your dashboards show a GPU that's busy most of the day is the day to graduate to a card of your own — and not a day before.



