Cost per usable image: the only generation metric worth tracking

Ask an operator what their generation costs are and you will usually get a number per image, or a monthly GPU bill. Both are easy to obtain and neither tells you anything useful, because they measure output rather than usable output.

A pipeline that produces a hundred images an hour of which four are publishable is dramatically more expensive than one producing forty an hour of which thirty are publishable, on identical hardware and with an identical monthly bill. Cost per usable image is the metric that captures that, and it is the one worth optimising.

cost_per_usable = (hourly_rate / images_per_hour) / keeper_rate

where:
  hourly_rate     = published GPU rate, or your amortised own-hardware cost
  images_per_hour  = measured throughput of YOUR pipeline at YOUR settings
  keeper_rate      = share of generations you would actually publish (0–1)

Everything interesting is in keeper_rate.

The point of this example is the ratio, not the absolute figures. The throughput and keeper rates below are illustrative inputs, deliberately chosen to show what the arithmetic does.

The untuned pipeline looks better on the metric most people report. It generates faster and each generation is cheaper. On the metric that matters it is more than eight times worse, and the shortfall lands on the input you cannot buy more of: the hours you spend reviewing output.

Per-image API pricing is attractive at low volume: no setup, no idle cost, no maintenance. Its problem is that it scales linearly forever, while a rented GPU has a fixed hourly cost regardless of how many images you extract from it.

1. 01

   Find your monthly usable-image requirement

   Count what you publish across the feed, the paywall, pay-per-view sets and off-platform promotion. Count it over a real week; recalling it from memory is where this calculation usually goes wrong.

2. 02

   Price that volume at API rates

   Multiply by the per-image price, then divide by your keeper rate. The keeper rate applies to API generation too, and people routinely forget it there.

3. 03

   Price the same volume as GPU hours

   Usable images required, divided by usable images per hour, times the hourly rate. Add setup and maintenance time at whatever you value your hour at.

   Gotcha — Include the hours you spend maintaining the pipeline. This is where own-hardware and rented-GPU comparisons usually cheat.

4. 04

   Compare, then re-run it in three months

   The crossover moves as your volume grows and your keeper rate improves. A decision that was right at 200 images a month is often wrong at 2,000.

The number is worthless if you estimate it, because everyone estimates it generously. Measure it once properly and you will have the single most useful figure in your production model.

1. 01Generate a batch of at least 200 images at your normal settings. Do not curate the prompt list for the test.
2. 02Review every one against your actual publication standard, not a relaxed one. Identity drift, hands, artefacts, framing, age ambiguity: all rejections.
3. 03Divide keepers by total. That is your keeper rate.
4. 04Log it with the date and the pipeline version. When you change a model, a LoRA or a sampler, re-measure. This is your regression test.