Two different questions
Raw GPU speed vs production throughput
We keep these measurements separate. Blender Open Data measures raw Cycles performance. Our multi-frame benchmark measures how efficiently the render service processes consecutive frames from the same scene.
Total score from Classroom, Junkshop and Monster on the official benchmark.
Median of 20 matching RTX 5090 + Blender 5.2 + Linux + OptiX submissions in our September 16 snapshot.
Combined Blender render time in our four-scene 10-frame Persistent Data A/B test.
Open Data submissions are submissions, not guaranteed unique physical GPUs. The official benchmark and the production runtime benchmark answer different questions and should not be combined into one score.
Production multi-frame A/B
Same scenes, same RTX 5090, one runtime change
Each scene was rendered as an identical 10-frame Blender 5.1.1 Cycles/OptiX job. The controlled variable was Cycles Persistent Data: disabled for the baseline and enabled for the optimized run.
| Scene | Persistent Data off | Persistent Data on | Time reduction | Throughput |
|---|---|---|---|---|
| BMW | 19.597 s | 14.017 s | 28.5% | 1.40× |
| Classroom | 58.339 s | 50.068 s | 14.2% | 1.17× |
| Junkshop | 80.445 s | 34.347 s | 57.3% | 2.34× |
| Monster | 38.055 s | 24.658 s | 35.2% | 1.54× |
Combined Blender render time across all four 10-frame tests. That is 73.35 seconds saved, or 37.3% lower total render time. Results are scene-dependent; this is not a guaranteed percentage for every Blender project.
Why it helps
Persistent Data avoids rebuilding everything between frames
For eligible multi-frame jobs, Blender can keep reusable Cycles scene data in memory between frames. That means later frames may avoid part of the setup work paid by the first frame. The gain depends heavily on what changes from frame to frame and how expensive scene setup is.
The clearest example in our test was Junkshop. The first frame still paid the normal setup cost, while later frames dropped to roughly 2.83 seconds each in our direct 10-frame test. Classroom improved more modestly. This is exactly why we publish a range rather than a single universal speed claim.
Safety and execution policy
Only enabled where it can help
GPU Render Studio enables Persistent Data for multi-frame animation work and keeps it off for single-frame stills. Long Render chunks also use it within each multi-frame chunk. The setting is applied in memory for execution; customer scene quality settings are not rewritten and the uploaded .blend file is not saved with the change.
We verified the production worker path, single-frame path and Long Render chunk path before rollout. The production worker retained OptiX, progress reporting, output packaging and wall-time billing.
Methodology
How the numbers were measured
- GPU: NVIDIA GeForce RTX 5090, 32 GB class VRAM.
- Production Blender runtime: Blender 5.1.1, Cycles, OptiX.
- Multi-frame A/B scenes: BMW, Classroom, Junkshop and Monster.
- Each A/B run used the same 10-frame scene copy and the same GPU backend.
- Persistent Data was the intended controlled variable between the off and on runs.
- Production E2E validation used the real GPU Render Studio worker and isolated test Redis state.
- Official Blender Open Data comparison used a September 16, 2026 snapshot filtered to RTX 5090 + Blender 5.2 + Linux + OptiX + single compute device + complete Classroom/Junkshop/Monster results.
What this means for customers
More useful than quoting a GPU model alone
An RTX 5090 is fast, but animation throughput also depends on how the renderer is operated. Our goal is to measure the actual uploaded project, use an execution path suited to Blender multi-frame work, and show the expected time and exact price before the full render is approved.
Upload a Blender scene for a measured estimate
Benchmark results describe these measured test scenes and configurations. Your scene can be faster or slower depending on geometry, textures, sampling, effects, compositing, frame-to-frame changes and other workload characteristics.