My RTX 5090 Renders 5x Faster. Here’s Why I Still Use a Cheap 4060 in the render fleet.

Summary: I generate image-to-video (i2v) clips for a software project on a small consumer level GPU fleet: a flagship RTX 5090 and a cheap, always on RTX 4060. On a controlled raw render test the 5090 is about 5x faster per clip. But in a real overnight run where the two cards carried very different loads, their completion rates were only about 1.6x apart, and the 4060 finished a 74-clip batch in a reasonable 4.6 hours. Also, at the end of the article, a way to build a two-GPU or three-GPU render fleet that stays productive around the clock.

Last updated: July 25, 2026

---

Why two GPUs instead of one

The workload is short AI video clips: a still image goes in, a short animated clip (a few seconds in length) comes out, generated locally with WanGP image-to-video. A project can need hundreds of them, and they render in the background in a queue. Hardware (GPUs, RAM, etc.) is SO expensive right now that I try to utilize ANY existing hardware that I have before even considering buying something new.

The flagship is an RTX 5090 (32 GB). It is fast, but I do not leave it running all night, mostly for power, heat and longevity reasons. So the fleet has a second node that never sleeps: a plain RTX 4060 (8 GB) in an always on low-power draw PC. Both machines run the same i2v model and settings, so the app treats either node’s output as interchangeable. The cache is keyed on the full render recipe (model, prompt, seed, dimensions, frame count, steps, sampler, LoRAs), so a clip rendered on the cheap card is a cache hit for the fast one today. The render client just tries a list of nodes in order and takes the first that answers, so work falls over to the always on card automatically when the flagship is off.

The expensive card handles interactive and heavy design intensive work when it is on, and the cheap card quietly grinds the overnight and fall-back work the rest of the time.

NOTE: Likewise, if you are VRAM limited, rather than trying to load or swap multiple models (say both a ~6GB still generator and ~8GB video generator) for different tasks on the SAME GPU with limited VRAM, spread the models out over multiple renderfleet GPUs.

The numbers

Same clip type on both cards, in a controlled back-to-back test (1024×576, a light 41-frame / 4-step i2v clip, and a heavier 81-frame / 6-step clip with LoRAs), model loading times and many other factors play into these numbers so they are just meant as real world data points on how these batches ran in production environment:

I also frequently add in a cooldown period between clips b/c I generally prefer NOT to run my cards non-stop, so that cooldown applies equally to both the fast and the slow card which bring them a bit closer to parity.

The surprising part showed up in the overnight batch. This was an operations comparison, not an apples to apples benchmark: the 5090 was serving the batch AND live on-demand requests from the app at the same time, while the 4060 was dedicated to nothing but the batch. Under those unequal conditions:

Overnight run (mixed load)	RTX 5090 (32 GB)	RTX 4060 (8 GB)
Observed completion rate	~26 clips/hr	~16 clips/hr
What it was doing	batch + live requests	batch only (dedicated)
74-clip batch	n/a (interleaved)	4.6 hours

So the observed completion rate was only about 1.6x higher on the 5090, not 5x. 

Why the cheap card kept pace

The 4060 ran uncontended. Dedicated to the batch, no competing work, no stalls. Just render (~205 seconds) plus about 19 seconds of pipeline overhead per clip, over and over. Seventy-four clips at ~224 seconds each is 4.6 hours, almost exactly what it took. A cheap card with the whole GPU to itself delivers close to its steady rate, and predictably.

The flagship was doing double duty. Its controlled raw render was 42 seconds, but its observed rate during the mixed run was closer to 138 seconds per clip, because it was juggling the batch and live requests together, plus a slow tail where a handful of clips ran well past the average likely due to model loads etc. A single flagship serving mixed traffic gives back a real chunk of its raw advantage to contention and tail latency. The always on card, precisely because it is a boring dedicated worker, does not.

How to build a hybrid render fleet

The process is simple and it scales down all the way to a spare PC:

1. Pick one always on node. It does not need to be fast. It needs to be reachable anytime and have enough VRAM for whatever model you are using. A cheap current-gen card in a low-power box is ideal. Again, make sure the VRAM is enough for the model(s) you are running. There are some nice models that are VERY minimal in their VRAM needs (Z-Image Turbo for example) and even some video gen setups like Wan2GP that do quite well on fairly low-end hardware.
2. List the flagship first, the always on node as fallback. The render client tries nodes in a fixed order and takes the first that answers. The flagship wins when it is on; requests fall through to the always on node when it is not. No orchestration, no queue, just an ordered list. [feel free to adjust to more sophisticated fleet order if you are leaving them all on 24/7]
3. Keep the model and settings identical across nodes. Then either node’s output is interchangeable and a recipe-keyed cache stays consistent, so last night’s clip on the cheap card is today’s cache hit on the fast one.
4. Route heavy work separately. The ordered list gives you failover, not smart routing. For weight-based routing, send heavy or interactive jobs to the flagship explicitly and let the always on node own the light overnight batches. A dedicated cheap card at full utilization will not beat a flagship on throughput, but it narrows the gap substantially while costing far less to leave running.
5. Let the cheap node be the batch grinder. Overnight fill jobs are exactly what an always on 4060 or 5060 is good at, and it frees the flagship, and its power draw, to be off.

A third node

I am adding a third machine to the fleet, an older Windows laptop with an RTX 3070, for stills only. I am reserving it for source-still generation rather than video (I have not set up the video path on it b/c I feel it would be too slow and strenuous on the laptop). But putting it on stills duty allows the other machines to focus entirely on video when needed. That is the nice thing about a first-reachable node list: you extend it by appending one line, and you can bring in cheaper or older cards for the specific sub-tasks they are still good at. 

The bottom line

A cheap, dedicated, always on second GPU is worth more than its raw specs suggest, as long as the work you hand it is light and steady. It will not win a benchmark but it can complete unattended light batches predictably while the flagship is off or bust, and for an indie developer fleet, that availability is often worth more than peak speed. Build around availability first and raw speed second and match each node to the weight of the job. 💪💪

 

What are you stuck on?

Stuck on something with Claude, Claude Code, or an AI workflow? Send the question. I'll try to answer in a future post and link it here.

Your question

Name (optional)

Website

Send