Rendering turns a 3D scene into a finished image. On our server, three Blender scenes took median times of 5.5 s, 10.3 s and 8.9 s. We tested one RTX PRO 6000 Blackwell Max-Q using Blender 5.2.0 LTS and the Cycles renderer.
These are the results for monster, junkshop and classroom, respectively. Our benchmark methodology helps distinguish the timed computation stage from a complete job's turnaround. The exact settings and procedure for this short series remain below; we do not attribute later campaign rules to it.
What could you use a rendering server for?
Remote rendering can free up a designer's workstation while producing product visualisations, interiors or animation frames. Prepare the project in your own environment, transfer the required files to the server and start the computation. Retrieve the result afterwards; your local computer need not spend that whole period rendering.
This is most useful when it fits your workflow: the project can be transferred with its dependencies, and collecting results does not require constant manual attention. Access to a GPU does not itself provide a complete job-queue system, however. Launching jobs, organising files and checking outputs are part of preparing your own environment.
What do the reported seconds mean?
We timed the render call, including scene preparation performed within that step. Program startup, initial project loading, file transfers and saving the image were excluded. Each headline result is the middle of three measured times after a warm-up: the median.
In practice, two measurements are useful. One shows how quickly the selected rendering stage runs. The other covers the time from preparing a job to retrieving the finished file. Moving a large project or repeatedly starting the program can make that distinction important to the workflow.
Our results describe the first scope. They are not Blender Open Data scores, even though we used scenes from the official archive. They should not be compared directly with another benchmark's points or treated as a complete rendering service's turnaround time.
How should you check your own project?
A sample of real work is the best reference, using the same application version, resolution and quality settings. Check that the project includes all required files, then compare the finished images rather than only the completion message. For animation, include a more demanding passage instead of assuming that every frame will behave alike.
Changing quality changes the task. A shorter time at different settings does not isolate a hardware difference. Our scenes also differ in complexity and resolution: monster, junkshop and classroom provide three reference workloads, not three identical trials.
Record the Blender and driver versions, rendering method, resolution and sampling settings. A later repeat or comparison with another machine can then use the same project rather than an accidentally changed configuration.
Memory and the scope of this check
The card has 96GB of GPU memory, but these scenes did not test its full capacity: the highest observed reading across the series was approximately 8GiB. More memory does not automatically make every scene render faster. A more elaborate project needs its own check of memory requirements and behaviour during execution.
The series confirmed successful completion of three warm-ups and nine measured renders. It was a short measurement, not an overnight animation-rendering test. The use cases above are suggestions for using a server, not additional tests we performed.
The details below contain the settings and results; our AI and GPU glossary explains the basic terms. Explore the server offer or tell us about your rendering project.
Technical details
Results for the three scenes
These results cover three Cycles scenes rendered on one GPU.
| Scene | Resolution | Median of 3 runs | Fastest–slowest measured run |
|---|---|---|---|
| monster | 1024 × 1024 | 5.5 s | 5.5–5.6 s |
| junkshop | 2000 × 1000 | 10.3 s | 10.3–10.4 s |
| classroom | 1920 × 1080 | 8.9 s | 8.8–8.9 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. The operating system's cache was not flushed and could retain data from environment preparation. 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.
The launch mode matters too: --background --factory-startup --disable-autoexec, without executing scripts stored in the scene. We verified the required OptiX device and successful completion of every render call; the procedure did not switch automatically to CPU rendering.
OptiX: an important environment detail
OptiX needs the appropriate user-space libraries alongside a working GPU driver.
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.
Limits of the short rendering series
The final series took approximately 103 seconds and completed all three warm-ups and nine measured renders. We observed the GPU roughly once per second. All render calls completed successfully.
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.