What One AI-Staged Room Actually Costs to Render: The GPU Math Behind Per-Image Pricing

CasaNova Labs, an AI studio for real estate imagery, breaks down the true GPU cost of rendering AI-staged rooms, revealing that per-image pricing in production is dominated by model loading, idle VRAM, and discarded renders rather than raw compute. The company explains that while a single SDXL render may cost only a fifth of a cent in pure GPU time, real costs can be several times higher due to cold starts and warm-pool tuning, making fixed per-image pricing a more predictable alternative for developers.

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 https://casanovalabs.com , 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 workhorse for photoreal room generation is an SDXL-class latent diffusion model. Per the SDXL technical report https://arxiv.org/abs/2307.01952 , 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. 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: 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. 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: 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. 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 https://casanovalabs.com/en/pricing is a fixed figure per render rather than a metered GPU bill you cannot forecast, and why the virtual staging https://casanovalabs.com/en/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.