Choosing a card for image and video models.

What each model needs

Start with the difference that decides everything else. A language model carries a key/value cache that grows with every token of context, which is why the same 70B model can ask for 40 GB or 140 GB depending on how much conversation you keep. A diffusion model has no cache at all. It reads a prompt, denoises a latent for a fixed number of steps, and forgets. The weights are therefore very nearly the whole memory question, and the answer does not move when your prompts get longer.

Weights plus a 15% runtime margin for activations, the CUDA context and allocator fragmentation — the same margin the configurator applies, so you can check these against it. There is no context column because there is nothing to put in it.

Two lines in that table are worth stopping on, because they are exactly where a purchase goes wrong.

What each card holds

Every single-card machine we rent, and the best precision each one holds for the two demanding models. The bandwidth column is there for the next chapter; read it after you have read that one.

Green is the reference weights, amber is quantised. Quantising a diffusion model is not the free lunch it is for a language model: the same prompt and seed give a visibly different image, usually a slightly softer one. It is a good trade at FP8 and a judgement call at 4 bits.

Read from the bottom of the price column and the picture is blunt. NVIDIA L4, at $125 a month, is the cheapest machine we rent that holds FLUX.1 dev at all — in FP8. The cheapest that holds it at full BF16 is NVIDIA RTX A6000, at $286. Video at full precision starts on that same card.

The column everyone reads wrong

Here is the part that separates image work from everything else on this site, and it is the reason the cheapest card in that table is a trap.

When a language model generates a token, it reads every active weight out of memory once, does a small amount of arithmetic with each one, and writes a single token. It does that again for the next token, and the next. The card spends its life waiting for the memory bus, which is why our throughput estimates for language models are essentially bandwidth divided by weights read, and why the bandwidth column is the one that matters on a serving guide.

A diffusion step does not look like that. The same weights are applied to a latent tensor twenty to fifty times over, and each pass does a great deal of arithmetic per byte fetched. The weights stay resident; the work is convolutions and attention over a small tensor. That flips the constraint: an image model is bound by tensor throughput, not by the memory bus. Three things follow, and all three cost money if you get them wrong.

Bandwidth per dollar is a proxy — a rough one — for the class of card you are looking at, and in our catalogue it ranks NVIDIA RTX 5090 and NVIDIA RTX 4090 first and second by a wide margin. That is not a coincidence and it is not a bargain we are talking you into: they are the parts designed for exactly this kind of arithmetic, and they are near the bottom of our price list because the market prices them against gaming, not against training clusters.

Resolution, batch and video

The weights are fixed. What moves is the working set, and it moves with pixels rather than with parameters. The latent itself is negligible — it is the activations passing through the network at that resolution that fill the card.

latent_elements = (H / 8) * (W / 8) * C * batch
# C = 4 latent channels on SDXL, 16 on SD 3.5 and FLUX.

# 1024x1024, batch 1, SDXL:
128 * 128 * 4 * 1     = 65,536 elements   = 128 KB in FP16

# 2048x2048, batch 4, SDXL:
256 * 256 * 4 * 4     = 1,048,576         = 2 MB in FP16

# The latent is never the problem. The activations that pass through the
# network at that resolution are, and they scale by the SAME factor:
# doubling the edge quadruples the pixel count, and roughly quadruples
# the working set. Batch multiplies it linearly on top.

Three practical consequences, in the order you will meet them:

1. The peak is usually the VAE decode, not the sampling loop. Decoding expands the latent back to full resolution in one pass, and that single moment is what triggers the out-of-memory error at the very end of a job that had been running fine for a minute. Tiled decoding fixes it and costs a little time.
2. Batching is how you use a big card. If the model leaves you 20 GB spare, four images at once is a far better use of it than one image with headroom — the weights are read once for the whole batch, which is the one place a diffusion pipeline does behave like a bandwidth-bound job.
3. Video adds a dimension, not a percentage. Wan 2.1 video 14B generates a block of frames together, so frames multiply the same working set that height and width already multiply. It is why a 14-billion-parameter video model asks for a much larger card than a 12-billion-parameter image model, and why the weight table above understates it more than any other row.

Getting ComfyUI up

ComfyUI is one of the images we can have written to the machine before it is delivered, which makes this section optional. If you would rather build it yourself, it is a container and a tunnel.

$ ssh root@203.0.113.42
$ nvidia-smi --query-gpu=name,memory.total --format=csv

# Checkpoints, LoRAs, ControlNets and VAEs on the fast local NVMe.
# This directory is the reason you are renting by the month.
$ mkdir -p /scratch/comfy/models
$ df -h /scratch

$ docker run -d --name comfy --restart unless-stopped \
    --gpus all --ipc=host \
    -v /scratch/comfy:/data \
    -p 127.0.0.1:8188:8188 \
    your-comfyui-image --listen 0.0.0.0 --port 8188

# From YOUR machine, not the server: a tunnel, then a local browser tab.
$ ssh -N -L 8188:127.0.0.1:8188 root@203.0.113.42
# http://127.0.0.1:8188

What a month buys

The reason image work suits a monthly machine is not the price of the GPU. It is the library. A serious ComfyUI install is a few hundred gigabytes of checkpoints, LoRAs, ControlNets, upscalers and VAEs that you have curated and do not want to fetch again.

That is the column to compare, and it is the one hourly platforms leave out of the headline. There the disk is a separate line item, priced per gigabyte per month, and it keeps billing while the instance is stopped — or you delete it, and re-download several hundred gigabytes the next time you sit down to work.

Which is the same trap the hourly break-even describes, in the shape it takes for image work. Per-second billing looks safe because you can stop the instance, and nobody stops it, because stopping it means losing the library. The honest question is not "how many hours will I generate" but "how many hours will this machine need to exist" — and for anyone with a curated model directory the answer is all of them. Payment is one transfer in crypto, there is no setup fee, and we did not ask who you are: the prompts, the LoRAs you trained and the client work you have not shipped yet stay on a machine only you have root on.

When not to rent a card

We would rather you did not rent one of these and regret it, so here are the cases where the answer is no.

Everywhere else — a library you have built, a pipeline you keep changing, batch jobs that run overnight, or work that simply should not leave your own disk — a dedicated card by the month is the cheaper and the calmer arrangement. The configurator will tell you, for every node in the catalogue, whether the model you have in mind fits on one card before you pay anything.