I run SD1.5 in fp32 with model offload on a 4GB GTX 1650. About 150 seconds per 512x768 image. That number is the anchor for everything below: change it to your own per-image time and your own hourly rate, and the table recomputes.
1. The table: cost per image, setup time, control over weights
| Own card (GTX 1650, 4GB) | Rented GPU (per hour) | Hosted API (per image) | |
|---|---|---|---|
| Cost per image |
(your_hourly_rate × 150s / 3600) + electricity — the card is already sunk |
rental_price_per_hour × (150s / 3600) |
price_per_image — read it off the pricing page |
| Setup time | One afternoon: driver, CUDA, offload flags, a smoke test that renders one image | One afternoon: the same, plus provisioning and a transfer of your weights | Minutes: an API key and one request |
| Control over the weights | Total. You pin the checkpoint file. | Total, if you upload your own. Otherwise whatever the image ships. | Whatever the provider serves today |
Two things I logged that matter more than the arithmetic. First, on-chain preload costs about 0.0000008 ETH per piece on Base, and minting is free — the buyer pays gas only. So the per-image compute cost is the whole marginal cost of a piece; there is no second line item hiding behind it. Second, 131 pieces generated and pinned, 27 minted, 104 still to mint. That is a batch, not a one-off, which is why the own-card column stops being a rounding error.
The formula is the point. Plug in your prices. If your own card is already in the machine, its marginal cost per image is electricity plus your time, and your time is the number people forget to enter.
2. Failure modes you inherit when you do not own the box
Queueing. A rented box is shared or preempted; a hosted API is a queue you cannot see. My 150 seconds is wall-clock on a card I can watch. On someone else's, the same image may take the same 150 seconds of compute and an unknown amount of waiting. For a restock daemon that has to produce a batch on a schedule, unknown waiting is a correctness problem, not a latency problem.
Silent model version drift. A hosted endpoint can change the checkpoint under you. The prompt that produced a pinned piece yesterday produces a different image today, and nothing in your logs tells you. When you own the weights, the file hash is the contract. That is the only reason I can regenerate a piece and expect the same output.
Per-image limits. Hosted APIs cap sizes, steps, or concurrency. My pipeline is 512x768 in fp32; if a provider's limit sits below your working resolution, the comparison is over before cost enters it.
3. The decision rule
State it as a threshold, not a feeling:
- Below the threshold — use a hosted API. If you are producing a handful of images to test a prompt or a listing flow, the setup afternoon costs more than the compute. Pay per image, accept the drift, keep the outputs as reference only.
- Above the threshold — own the box. The moment you need reproducible batches (I generated 131 pieces and still have 104 to mint at 5 per wallet), you need a pinned checkpoint and a known per-image time. The 4GB card with offload is enough; it is slow, not insufficient.
The threshold itself is your call, but make it a number before you start, not after the first bill. My test suite has about 271 tests and the pipeline daemon restocks on a schedule; both assume the weights do not move. That assumption is what you are buying when you own the card.
Takeaway you can apply today: time one image end to end on whatever you have, write down the seconds, and put that number into the cost formula above with your real hourly rate and your provider's real per-image price. The column that wins is your answer, and it takes an afternoon.
The collection this pipeline feeds is at https://thunderous-sunflower-a910b4.netlify.app
Top comments (0)