If you have run a diffusion model locally, the marginal cost of one image feels like zero. The model is already in memory, the GPU is already warm, and you just call pipe(prompt) again. That intuition is what makes teams underestimate the real number when they move the same feature into a product. The per-image cost in production is dominated by things the notebook hides: the seconds you pay for a GPU that is loading a model, the VRAM you rent whether or not a request is in flight, and the renders you throw away.
We build CasaNova Labs, an AI studio for real estate imagery, so this arithmetic is our unit economics. Here is how it actually breaks down, with numbers you can plug your own rates into.
The model is bigger than people remember
The workhorse for photoreal room generation is an SDXL-class latent diffusion model. Per the SDXL technical report, its UNet has around 2.6 billion parameters, roughly three times the UNet of Stable Diffusion 1.5, and it renders natively at 1024x1024. In half precision that weight sits at about 10 GB of VRAM before you add anything, and a real staging pipeline adds plenty: a ControlNet to keep the room geometry, an inpainting pass to swap furniture without touching the walls, sometimes an upscaler on top.
So the first cost is not compute, it is the size of the box you have to rent. You cannot serve a 10 to 14 GB working set on a small GPU. You are renting an A10G, an L4, or an A100-class card, and you are renting it for the whole time the process is alive, not only while a request runs.
Cold starts are the line item nobody budgets for
Loading a multi-gigabyte checkpoint from disk into VRAM is not instant. Depending on where the weights live and how fast the storage is, moving 10-plus GB into the GPU takes on the order of seconds to tens of seconds. If you run serverless GPU inference and let workers scale to zero to save money, every request that lands on a cold worker pays that penalty before it renders a single pixel.
This is the tradeoff that quietly sets your cost floor:
- Keep a worker warm and you pay for idle GPU time between requests.
- Let it scale to zero and your tail latency spikes, and you burn GPU seconds re-loading the model instead of rendering.
Neither option is free, and the cheaper one depends entirely on your request pattern. Bursty, unpredictable traffic (which is exactly what a listing-editing tool sees) is the worst case for both.
The arithmetic, with a rate you can change
Take the compute itself. A 1024x1024 SDXL render at around 30 steps is a few seconds of GPU time on a mid-range card, call it 4 seconds for a round number, more with ControlNet and an upscale pass. Now assume a GPU that costs 2 dollars an hour. That is:
2 dollars / 3600 seconds = 0.00056 dollars per GPU-second
4 seconds x 0.00056 = 0.0022 dollars of pure compute per image
A fifth of a cent. That is the number that makes AI rendering look almost free, and it is the number demos quote. It is also fiction as a unit cost, because it ignores everything around the render:
- Cold-start seconds amortized across real, bursty traffic.
- Idle GPU time when you keep workers warm to hide those cold starts.
- Retries and rejects. Diffusion is stochastic; some fraction of outputs miss and get re-rolled, and you pay full compute for images a human never keeps.
- Storage and egress for the input photo, the output, and usually several intermediate variants.
Depending on how warm you run and how often you retry, the real cost per delivered image can land several times higher than the raw compute line. The exact multiple is the entire engineering problem, and it is why serious inference platforms bill by the GPU-second rather than by the image: the per-image number is not stable enough to quote until you have absorbed all of the above.
Why this maps onto build versus buy
If you are adding an AI image feature to your own product, this is the honest tradeoff. Running it yourself means you own the warm-pool tuning, the autoscaling, the retry logic, and a GPU bill that is mostly idle time and cold starts rather than the four seconds of actual rendering. That is real, ongoing engineering, not a weekend integration.
The alternative is to let someone who has already amortized that infrastructure across many tenants absorb it, and pay a flat, predictable number per delivered image. That predictability is the product. It is why our per-image pricing is a fixed figure per render rather than a metered GPU bill you cannot forecast, and why the virtual staging itself is priced by the finished photo, not the compute behind it.
The takeaway is not that one path always wins. It is that the demo number, a fifth of a cent, is never the number you ship on. Before you decide to run diffusion inference in-house, price the cold starts and the idle time, not the render. That is where the cost actually lives.
Top comments (0)