Self-hosted or API: the real cost of running adult image generation

The build-versus-buy conversation for image generation usually opens with an hourly GPU price and ends there. That number is real, and it is also the smallest line in the budget. Everything expensive about a self-hosted pipeline is the part that does not appear on a rental invoice.

What self-hosting genuinely involves

A working pipeline is a graph of models, custom nodes and weights — and every one of those is a version that can move underneath you. A node pack updates and a parameter changes meaning. A base model is replaced and your carefully tuned presets shift character. None of this is exotic; it is Tuesday. The engineering cost is not building the pipeline once, it is keeping the output stable while the ecosystem under it moves.

Then there is capacity. Generation is bursty by nature: evenings and weekends spike, weekday mornings are dead. Sizing for the peak means paying for idle silicon most of the week. Sizing for the average means your users queue exactly when they care most. Autoscaling GPUs is possible, but a cold worker has to load tens of gigabytes of weights before it can serve anything, so scaling up is measured in minutes rather than seconds.

The costs that never make the spreadsheet

• On-call. A GPU box that dies at 03:00 on a Saturday is somebody's night, and image generation is a night-and-weekend workload by nature.
• Storage and retention. Inputs and outputs accumulate on disk, and quietly become a liability nobody is deleting.
• Model drift. Regression-testing prompt presets after an upgrade is real work that has to be redone every upgrade.
• Queue engineering. Backpressure, retries, deduplication and recovery after a crash are the same problems whether you rent the GPU or not.
• Security. A GPU host with an open inference port is an attractive target, and the software involved is not written with hostile internet exposure in mind.

Where self-hosting genuinely wins

This is not a one-sided argument. Run your own pipeline when the pipeline is the product — when you are training or fine-tuning your own models, when the exact graph is your differentiator, or when regulation obliges you to keep processing inside infrastructure you control. Steady, high, predictable volume also shifts the maths: a saturated GPU running around the clock is cheaper per image than a per-call price.

The pattern to be suspicious of is the middle: moderate volume, spiky demand, a small team, and a pipeline that is a means rather than an end. That combination pays the full operational cost of self-hosting while capturing almost none of its benefits.

Where an API wins

An API converts a capacity problem into a line item. There is no idle silicon, no cold-start engineering, no upgrade weekend, no on-call rotation for hardware. Your integration becomes four HTTP calls, and the volume question becomes somebody else's operational problem.

It also compresses time to market from weeks to an afternoon. For a feature you are still validating, that matters more than unit economics: shipping in a day and learning that users do not want it is a far cheaper outcome than discovering the same thing after provisioning a GPU fleet.

A decision that takes five minutes

1. Is the pipeline itself your product? If yes, build.
2. Is your volume high, steady and predictable enough to keep a GPU genuinely saturated? If yes, building starts to pay.
3. Do you have someone who will own GPU on-call, and do they know it? If not, buy.
4. Are you still validating the feature? Buy now, revisit once the demand curve is real.

The hybrid nobody mentions

These are not exclusive. A common and sensible arrangement is an API for the unpredictable public-facing traffic, with owned hardware absorbing a stable internal baseline. It also removes the migration cliff: keeping your integration behind one HTTP boundary means moving between the two later is a configuration change, not a rewrite.

Frequently asked