You already have the only number that matters: how many seconds one frame takes. Everything else is arithmetic — plus two costs nobody warns you about, both measured below.
| Pure render time | — |
| Your machine is busy for | — |
| Electricity, at 400 W | — |
| Split across 4 machines | — |
| Split across 20 machines | — |
| Split across 40 machines | — |
The split rows assume every extra machine renders at the same speed as yours, so what you are seeing is the effect of parallelism alone — not a faster card. Each machine also pays its own six-minute start-up, which is why forty of them stop helping on short jobs.
Before Cycles renders anything on a GPU it compiles kernels for your exact scene and card. That happens once, and it is invisible in every render-time estimate you will read — including the one you make by timing a single frame.
Measured on our own machines, first frame against a warm one:
| Scene | First frame | Warm frame | Penalty |
|---|---|---|---|
| Blender 4.5 splash | 43 s | 5 s | 8.6× |
| Lone Monk | 381 s | 113 s | 3.4× |
| Fishy Cat | 15 s | 6 s | 2.3× |
| Classroom | 11 s | 8 s | 1.4× |
| Archviz interior | 88 s | 87 s | 1.0× |
If you timed one frame of a scene like the splash and multiplied by 900, you overestimated the job by a factor of eight. If you timed the archviz interior, you were exactly right. There is no way to tell which case you are in without rendering twice — so time the second frame, never the first.
Rendering frames 1–100 in one command is not the same as running one hundred single-frame commands, even though the pixels come out identical. Each launch reloads the scene and, on some hardware, pays the kernel compile again.
Four frames, RTX 5090, same scenes, two ways of asking:
| Scene | One launch per frame | One launch, whole range | Saved |
|---|---|---|---|
| Interior, 368 MB | 203 s | 160 s | 21 % |
| Pavillon, 25 MB | 31 s | 29 s | 6 % |
| Classroom, 70 MB | 24 s | 23 s | 4 % |
The heavier the scene, the more the per-launch overhead costs you. If you drive Blender from a script or a queue manager, give it ranges, not single frames.
Card comparisons are usually quoted as one number — “the 5090 is 1.5× faster”. On our own runs the ratio moved between 1.2× and 2.7× depending on the scene, which is why we stopped quoting a single figure. Warm frame, seconds:
| Scene | RTX 4090 | RTX 5090 | RTX A6000 |
|---|---|---|---|
| Classroom | 9 | 7 | 20 |
| Blender benchmark | 45 | 29 | — |
| Archviz interior | 92 | 52 | 112 |
| Lone Monk | 116 | 82 | 318 |
Lone Monk on an A6000 takes 2.7× longer than on a 4090; the archviz interior takes only 1.2× longer. Memory bandwidth, shader complexity and how much of the scene fits in VRAM all move that number around. Take any single-figure speed claim — ours included — as a starting point, not an answer.
Frames render independently, so an animation splits across machines almost perfectly — almost. Every machine you add has to start up, load the scene and compile kernels before it renders anything, and that cost is paid on every machine, not once. It is the reason the calculator above stops improving as you add more.
For a job of a few minutes, four machines beat one and forty are pointless — you would spend the whole render warming up. For a job of several hours, the warm-up disappears into the noise and the split is nearly linear. The crossover is the only interesting question, and the calculator answers it for your numbers rather than in general.
Rushframe rents GPUs by the second, splits your animation across as many as your deadline needs, and gives you a fixed price before you pay anything. We render three real frames from your scene first — free — so the estimate comes from your file rather than from a table like the one above.
See what your job would cost →Render one frame from the middle of your animation. The
render window shows Time: in the header when it finishes.
Use that. Avoid the first frame you render after opening the file —
it carries the kernel compile.
Roughly, for path tracing — 4K is about four times the pixels of 1080p and lands near four times the time. Sampling and denoising settings move it more than resolution does, which is why we ask you to measure rather than calculate from settings.
Noise falls with the square root of samples: going from 128 to 512 costs four times the render and halves the noise. Adaptive sampling and a denoiser usually buy more than raw samples do.
For many shots, yes — it is fast enough on your own machine that sending it anywhere costs more time than it saves. The measurements on this page are all Cycles on GPU.