On our GPU server, the monster scene rendered in a median 5.54 seconds, junkshop in 10.34 seconds and classroom in 8.85 seconds. We used Blender 5.2.0 LTS, Cycles and the OptiX backend on one RTX PRO 6000 Blackwell Max-Q GPU. Each scene used 512 samples, one warm-up render and three measured repetitions.
These are our own render-call timing measurements, not official Blender Open Data scores. The scenes have different resolutions and complexity: one row is not the same workload as another. We publish settings and every repetition so the numbers have a clearly defined meaning.
Results for the three scenes
| Scene | Resolution | Median of 3 runs | Fastest–slowest measured run |
|---|---|---|---|
| monster | 1024 × 1024 | 5.54 s | 5.53–5.61 s |
| junkshop | 2000 × 1000 | 10.34 s | 10.26–10.42 s |
| classroom | 1920 × 1080 | 8.85 s | 8.76–8.86 s |
The range is the actual minimum and maximum of three measured runs, not a confidence interval or guaranteed performance for a future job. The warm-up is excluded from the median. Its result, individual measured repetitions and more precise values are available in the CSV and JSON downloads below.
Test configuration
| Component | State during the test |
|---|---|
| GPU | NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition, 96GB VRAM |
| Configured power limit | 300W, without manual overclocking |
| CPU | AMD EPYC 4565P, 16 cores / 32 threads |
| System RAM | 96GB |
| Operating system | Rocky Linux 10.2 |
| NVIDIA driver | 595.91.07 |
| Blender | 5.2.0 LTS, build fbe6228777e7 |
| Rendering compute | Cycles, OptiX, one GPU; the CPU render device disabled |
The highest observed GPU memory usage during the complete series was 8162MiB, approximately 8GiB. These three scenes therefore did not test utilisation of the GPU's full 96GB VRAM capacity. They also do not establish that every larger scene will fit in GPU memory.
What the reported time includes
We measured wall time around bpy.ops.render.render(write_still=False). This includes rendering and scene preparation and synchronisation, including BVH work. Disabling the CPU as a render device does not eliminate the CPU work needed to prepare a scene.
Blender startup, the initial .blend file load, saving an image and network transfer are outside this timing boundary. The result is therefore not the full turnaround time from uploading a project to downloading an output file. Those additional stages need their own measurements for that workflow.
Each scene ran in a separate Blender process. Within that process, we performed one complete warm-up render followed by three measured renders. We did not flush the operating system's cache, and a pilot had run before the final series. No other compute workload ran concurrently on the GPU, although unrelated model downloads could use CPU, network and storage resources.
Scenes and reproducible settings
The scenes came from Blender's official archive: monster, junkshop and classroom. We checked archive and application SHA-256 values against Blender Open Data metadata and the Blender 5.2.0 release checksums. Exact hashes are also included in our JSON.
Settings shared by all three scenes:
- Cycles, OptiX, only the selected GPU; the CPU is not a render device.
- 512 samples, with adaptive sampling and denoising disabled.
- Frame 1 selected first, then a fixed random seed of
0. - The scene's original width and height at 100% resolution scale.
- Persistent data, compositing and sequencer disabled.
- Original per-scene bounce settings; the exact values are recorded in JSON.
The original classroom scene has an animated seed setting. We therefore select the frame before setting the seed. We retained a pilot with the opposite operation order separately and did not include its numbers in the results above.
The launch mode matters too: --background --factory-startup --disable-autoexec, without executing scripts stored in the scene. We checked that every render call completed successfully. A run without the required OptiX device failed instead of automatically switching to CPU rendering.
OptiX: an important environment detail
The initial compute-oriented CUDA driver installation did not contain the OptiX libraries. A working nvidia-smi was therefore not sufficient to run this version of the test.
We used user-space libraries in exactly version 595.91.07, matching the running driver, from the official NVIDIA package. Its RPM signature was verified against an already installed NVIDIA signing key. We made the libraries available only to Blender from an isolated directory; we did not replace the global driver or firmware. The JSON includes the version, source and SHA-256 values without administrative paths.
This describes the environment we tested. It is not a claim that every clean CUDA installation includes all the components needed for OptiX rendering.
Temperature and the limits of this measurement
The final series took approximately 103 seconds and completed all three warm-ups and nine measured renders. GPU readings taken roughly once per second showed a maximum of 84°C, close to the conservative guard that would stop this test at 85°C. The starting temperature reading for the series was 55°C.
This describes a short run, not evidence of multi-hour thermal stability. Sampling can also miss shorter peaks between readings. Power telemetry in the JSON describes the GPU board, not the whole server's AC power draw.
Does this server fit your rendering workload?
The results provide a concrete reference for three disclosed scenes and settings. We do not automatically translate them into the duration of another project, the throughput of a complete animation or superiority over another provider. This is not an Eevee test, a CPU-rendering test or a test of maximum VRAM capacity.
For remote Blender rendering, describe the application version, engine, resolution, sample count, approximate scene memory usage and frame count. Those details make it possible to define a useful validation workload instead of choosing from a GPU name alone.
View the server offer, ask about your rendering project or read our testing methodology.