Modal vs Runpod: Serverless GPUs Compared

Modal is a Python-first serverless platform: you write a function, say which GPU it needs, and Modal runs it per second. Runpod rents GPU Pods you control and also has serverless workers. Modal's H100 SXM5 is about $3.95 an hour; Runpod's is $2.69 on Community Cloud and $3.99 on Secure Cloud. Pick Modal for code-defined bursts, Runpod for lower rates and full machines. Checked 31 October 2026. Affiliate links on this site go through /go/ and are marked sponsored.

The short version

You can see more providers at /compare/hosting/.

What each one is

Modal

Modal's docs describe running your code in the cloud without managing infrastructure. You decorate a Python function, for example @app.function(gpu="H100", image=image), and Modal puts your code in a container, runs it and scales containers up with traffic. The docs say you do not need to mess with Kubernetes, Docker or an AWS account. A valid payment method is needed to use a GPU. Beyond functions, it has Sandboxes for isolated container environments, Volumes, snapshots to cut cold starts, and GPU health and metrics. Our entry is Modal.

Runpod

Runpod is a platform for AI, machine learning and general compute. You rent GPU Pods billed per second, run serverless endpoints with flex and active workers, and attach network storage. Our entry is Runpod. For a detailed look at its price list and its marketplace rival, read Runpod vs Vast.ai.

The difference in one line: with Modal you hand over code and it finds machines; with Runpod you pick a machine and run what you like on it.

GPU prices

Modal prices per second. Converting to hours (multiply by 3,600) from its pricing page:

Runpod's A100 range spans PCIe at $1.19 and SXM at $1.39 on Community Cloud. The rows compare like with like only roughly, since Modal and Runpod package cards differently.

Two readings. On list price per GPU hour, Runpod Community Cloud is lower than Modal on every card both list, by roughly 30 percent on the H100 SXM ($2.69 against about $3.95) and by 40 to 55 percent on the L40S and A100. Runpod Secure Cloud is closer: its H100 SXM at $3.99 matches Modal's within a few cents, and its B200 at $7.99 is above Modal's about $6.25.

The second reading matters more: the price per hour is not the price per job. Modal bills while your function runs. A Pod bills while it exists. If your GPU sits idle between runs, the Pod costs more than its list price suggests.

CPU, memory and plans on Modal

Modal also bills CPU and memory per second. The CPU rate is $0.0000131 per physical core per second (a physical core equals two vCPUs, as AWS or GCP count them), with a minimum of 0.125 cores per container. Memory is billed per GiB per second, and each container requests at least 128 MiB. Sandboxes and Functions have different rates because Sandboxes are not preempted, and the docs say a 3x multiplier applies to CPU and memory list prices for non-preemptible resources. Functions can be preempted by default, though the docs say interruptions are rare.

Plans:

Modal also lists free compute credits for early-stage startups and up to $10,000 for graduate students, labs and researchers.

Runpod beyond the list price

Runpod bills Pods by the second for compute and storage, with no fees for data ingress and egress. Disk storage runs from $0.05 to $0.20 per GB a month by type, and network volumes are $0.07 per GB a month under 1 TB. Serverless workers carry container disk costs near $0.10 per GB a month. A default spend limit of $80 an hour applies across all resources. When your balance reaches $0, Pods stop, and those without a network volume are terminated with data lost.

Developer experience

Modal is code-first. Your image, GPU, secrets and schedule live in Python next to the function. Iteration is running a local command that executes remotely. The docs cover web endpoints, cron schedules, Volumes and memory snapshots that cut cold starts. If your team already writes Python services, there is little new to learn. If you use a language other than Python, check what is supported.

Runpod gives you more traditional control. A Pod is a container on a GPU host that you can open in a terminal or notebook, with templates for common frameworks. You decide what runs. That is better for long training jobs, exploratory work and custom setups, and worse for scaling a stateless API without effort. Its serverless product closes some of that gap with workers that scale to zero.

Cold starts and scaling

A serverless GPU function must start a container and load model weights before it answers. That delay is the cold start. Modal lists cold start performance and memory snapshots as features and its docs point to sub-second cold starts for some open-weight models. Runpod's serverless docs describe an idle timeout (default 5 seconds) before a worker scales down, and distinguish flex workers, which scale to zero, from active workers, which stay up.

If your API needs a response in under a second at any time, keep a warm worker. That costs money on both platforms.

Side-by-side facts

A worked example: a bursty inference API

Suppose an API serves a model on one H100 and gets real traffic for two hours a day, with nothing in between.

• Always-on Pod, Secure Cloud. 24 hours at $3.99 is $95.76 a day, whether or not anyone calls it.
• Always-on Pod, Community Cloud. 24 hours at $2.69 is $64.56 a day.
• Modal function, scaled to zero. Two busy hours at about $3.95 is $7.90 a day, plus time spent loading weights on each cold start.

The gap is huge when the GPU sits idle. It narrows if traffic is steady, and it reverses when the GPU is busy all day. Runpod's serverless workers can also scale to zero, so the fair comparison for a bursty API is Modal against Runpod Serverless, not against a Pod. The arithmetic above uses list rates and leaves out storage, egress and cold-start time, so treat it as the shape of the answer, not the answer.

What the code looks like

On Modal, the unit of deployment is a Python function with its hardware named in the decorator:

import modal

image = modal.Image.debian_slim().pip_install("torch", "transformers")
app = modal.App("demo", image=image)

@app.function(gpu="H100")
def generate(prompt: str) -> str:
    ...

The Modal docs show this style, and note that the GPU argument accepts names such as T4, L4, A10, L40S, A100, H100, H200 and B200, with :n appended for more than one GPU per container. On Runpod, you would pick a GPU in the console or API, choose a template, and run your own server inside the Pod, or package a handler for a serverless endpoint.

Who should pick which

A Python team shipping an inference API

Modal. You describe the model, GPU and scaling in code, and pay per second of use. Keep an eye on the premium over Runpod's list price.

A researcher training for days

Runpod, for the lower hourly rate and a machine you control. Save checkpoints to a network volume.

A startup with spiky traffic

Test both: Modal functions or Runpod Serverless flex workers. Measure cold start and cost per thousand requests with your model.

An agent builder who needs many isolated environments

Look at Modal Sandboxes first. Its pricing page has a Sandboxes section and its site highlights scaling them to large numbers. If you only need a few, any container will do.

A student

Modal's $30 a month free credit on Starter and the researcher credits are a good start. Runpod's cheap consumer cards are good for long tinkering.

Limits and gotchas

• Preemption. Modal Functions can be preempted by default. Non-preemptible resources cost 3x on CPU and memory.
• Pods keep billing. A forgotten Pod bills until you stop it.
• Data loss at zero balance. Runpod terminates Pods without a network volume.
• Lock-in. Modal's decorator style ties your code to its SDK. A Pod runs whatever you like.
• Egress. Modal includes allowances by plan. Check before you move big datasets.
• List versus real price. Compare cost per finished job, including idle time.

Break-even utilisation

The worked example above compares two extremes. This section finds the line between them for an H100 SXM, using the list prices in the table: about $3.95 an hour on Modal, and $2.69 or $3.99 an hour on Runpod.

An always-on Runpod Pod costs the same however busy it is. A Modal function costs only for the hours it runs. So Modal is cheaper while your GPU is busy for less than a certain share of the day.

Two cautions. The comparison ignores cold starts, because a function that loads weights on each start spends paid seconds doing it, and it ignores the Pod's idle risk, since a forgotten Pod bills until you stop it. It also assumes the work fits one card and that a request arrives only when the GPU is wanted. Real traffic is lumpier than a share of the day, so measure your own busy hours before you rely on the 68 percent line.

Three jobs, three bills

All figures use the list prices above and ignore storage, egress and your own time.

The training run favours the Pod, since the GPU is busy every hour and the lower rate wins. The bursty API favours scaling to zero by a wide margin, unless you also run a serverless endpoint on Runpod and let it scale down. The weekend experiment is cheap on both and favours whichever you already know how to use.

What the free credit buys

Modal's Starter plan gives $30 a month of free credit, which covers about 7.6 hours of H100 time at $3.95 an hour, or about 12 hours on an A100 80 GB at $2.50. The Team plan is $250 a month plus compute with $100 of free credit, so if you use all the credit, the plan costs a net $150 a month for its other features. Runpod's pricing page did not state a free tier in what we read, so we cannot compare the two on credit.

Questions people ask

Which is cheaper? On list price per GPU hour, Runpod Community Cloud, by roughly 30 percent on an H100. Per finished job, it depends on how busy the GPU is.

Do both scale to zero? Modal functions run only when called. Runpod's serverless workers can also scale down, and Pods keep billing until you stop them.

Which is easier for a Python team? Modal's decorator style keeps hardware, image and schedule in your code. Runpod gives you a container you control.

Our take

We think of Modal as a developer product that sells time saved, and Runpod as a rental shop that sells cheap GPUs. If your work is bursty and your team writes Python, Modal's per-second model and tooling often pay for the higher hourly rate. If your work is steady, or you want to control the machine, Runpod's lower rates win.

We did not run a workload on either for this page, and we make no claims about speed or reliability. The prices come from their pages on 31 October 2026. Neither platform's list price tells you the bill for your own traffic pattern, which is why the test matters. Do the one test that settles it: run your real job on both for an hour, divide the bill by the work done, and pick the lower number.

Related pages

• Runpod vs Vast.ai
• Runpod vs Lambda
• Cloud vs self-hosted AI
• Replicate