If you read one line: the choice between fal, Replicate, and Modal for serving a generative-media model isn't about the per-hour GPU rate — it's about how much of the stack each one hands you. fal hands you an optimized model plus a diffusion-tuned inference engine and can bill per output; Replicate hands you a packaged model behind one API (a catalog model or your own via cog) and bills per prediction-second; Modal hands you nothing above the GPU and lets you run arbitrary Python with true scale-to-zero. Match that abstraction to your workload and the price mostly takes care of itself.

The axis that actually separates them#

Every "serverless GPU pricing matrix" ranks these three on dollars per H100-hour. That comparison is nearly useless on its own, because the three platforms are selling different amounts of work. A lower posted rate on a platform that bills your idle time can cost more than a higher rate on one that bills per finished image. The question that predicts your bill and your engineering effort is: at what layer do you hand off?

Read top to bottom, that's a ladder from "results as a service" to "raw compute as a service." Your billing model, your cold-start behavior, and how much code you maintain all follow from where you stand on it.

fal: results as a service, priced per result#

fal specializes in generative media — image, video, and voice diffusion models — and runs them on a proprietary fal Inference Engine it says is materially faster for diffusion than a naive deployment. The practical consequence for a founder is the billing option nobody else really offers: you can pay per output. Model APIs are priced per generation — per image, or per second of video or audio — so you pay for a finished result, not for GPU wall-clock. fal also offers per-GPU-second billing on dedicated and serverless compute when you'd rather rent the hardware directly (fal compute pricing, model API pricing).

What it means: if 90% of your traffic is a mainstream media model — a Flux-family image model, a popular video or TTS model — fal is usually the fastest path to production and the easiest bill to reason about, because per-output pricing is only cheap when the model runs fast and fal has already done the "run it fast" part. The limit is the flip side of the abstraction: you're serving their optimized deployment of a supported model. When you need a model that isn't in the catalog, or your own custom pipeline around it, you've hit the ceiling.

Replicate: the catalog and the cog#

Replicate's pitch is breadth. It hosts a large public catalog of open models across every modality behind one consistent API, and its open-source packaging tool, cog, lets you wrap your own model in a container and publish it as an endpoint with one command. Billing is per second of prediction time, priced by the hardware the model runs on (Replicate pricing).

Here's the part that surprises people, straight from Replicate's own billing docs: **public models bill only the active time your request runs, but private and custom deployments usually run on dedicated hardware and bill setup, idle, and active time.** A low-traffic private model that sits waiting for requests is costing you money the whole time it's warm. That's not a gotcha they hide — it's the trade for not sharing a queue — but it changes the math completely versus a public model, and it's the single most common way a Replicate bill comes in higher than the per-second rate suggested.

What it means: reach for Replicate when you want the widest menu of ready models across modalities, or when you want to publish your own model publicly with the least ceremony. Watch the public-vs-private line item like a hawk: if your custom model has spiky, low-volume traffic, the idle billing on a dedicated private deployment can make a per-active-second platform like Modal cheaper.

Modal is not a model host — it's general serverless compute for Python. You write a function, decorate it with the GPU it needs, and Modal provisions the hardware on demand, runs your code, and scales to zero when the traffic stops. Billing is per active GPU-second (Modal pricing). Its headline engineering investment is cold starts: Modal has written publicly about using memory snapshots to make GPU scale-to-zero fast enough that spiky, bursty workloads don't eat a multi-second penalty on every cold request.

What it means: choose Modal when your workload is code, not a catalog entry — a custom or fine-tuned model, a multi-step pipeline (detect → generate → upscale → watermark), or anything with real pre- and post-processing you want to own. You get infrastructure control and honest per-active-second billing with true scale-to-zero, so an idle service costs nothing. The price of that control is that the packaging and inference optimization fal and Replicate hand you are now yours to build. Because you pay for every active second, a lazy loop or a model that loads its weights on every request is a line item, not just a latency bug.

The decision, in one pass#

And you don't have to marry one. The resilient pattern for a solo team is to serve the high-volume standard model on fal or Replicate, run the one exotic custom step on Modal, and put a fallback chain in front so a single provider's outage doesn't take your media feature offline. If your comparison is really about renting raw GPUs by the hour rather than serving a media model, that's a different shortlist — we sized up Modal vs Replicate vs RunPod vs Baseten on exactly that axis.

One caveat worth stating plainly: the exact per-hour and per-output numbers on all three move often. Treat any specific rate as a snapshot, price your actual workload against each billing model before you commit, and re-check the linked pricing pages — the structural differences above are what stay true.