How to compare Blender render farms
By Superluminal Engineering
A practical checklist for comparing onboarding, queue time, rendering, failures, output quality, delivery, and actual project cost.
Published 2026-07-29 · Updated 2026-07-29
A useful render-farm test answers a production question: which service can take this Blender project, return the required original files by the deadline, and do it at an acceptable cost?
That is a bigger question than which GPU finishes one benchmark frame fastest. It includes preparation, upload, queues, Blender startup, scene loading, output delivery, retries, support, and the final charge.
Use more than one Blender scene
Blender workloads behave differently, so a useful test suite needs several scene types:
- a familiar public scene for easy reproduction;
- a dependency-heavy project with linked libraries, UDIMs, image sequences, caches, fonts, IES, and OSL;
- a multi-frame animation that reveals parallelism and slow outlier frames;
- a short Eevee sequence where repeated setup matters;
- a longer Cycles scene where GPU compute and memory dominate;
- a multilayer EXR scene with passes, compositing, color management, and Cryptomatte; and
- an add-on case with permission to redistribute and run the package.
Blender Open Data is excellent for comparing devices on Blender’s own benchmark scenes. We use it as hardware context, not as a substitute for testing the complete farm workflow.
Freeze the important settings
Every provider should receive the same scene package and output target. Record the exact Blender patch, render engine, device mode, frame range, samples, resolution, denoiser, compositor, color configuration, output format, add-ons, environment requirements, and caches.
If a provider requires a scene change or conversion, record it. That may be a reasonable part of its service, but it changes the user experience and sometimes the result. A support engineer fixing a project can be a strength; it should simply remain visible in the comparison.
End-to-end benchmark clock
Each phase remains separate so a fast renderer cannot hide slow onboarding or failed delivery.
- 01 · Account and project readiness
Time registration, verification, installation, environment configuration, scene validation, and required support contact.
- 02 · Transfer and queue
Measure bytes, transfer duration, retries, queue entry, allocation, and the first provider-side project activity.
- 03 · Prepare, render, and write
Separate dependency staging, Blender startup, frame render, denoise, compositing, file writing, and provider postprocessing.
- 04 · Verify and download
Check completion, failed frames, retries, output hashes, declared image tolerance, download time, and actual recurring-price invoice.
Time the whole job
The timer should follow the user’s real journey:
- account and application ready;
- scene scan and packaging;
- upload complete;
- job accepted;
- worker assigned and runtime ready;
- Blender and scene ready;
- frame rendering;
- output writing and postprocessing;
- first useful preview;
- original files available;
- download complete; and
- required files checked.
These stages should stay separate where possible. A provider can render quickly but deliver slowly, or create a preview quickly while the original EXR remains unavailable. Both details matter to an artist.
Count failures and recovery
Failed work is part of the workflow, not an inconvenient row to delete. Keep failed attempts, retries, timeouts, wrong outputs, missing files, user corrections, provider support, and duplicate work in the timeline.
A completed status is not enough on its own. The required frames must exist, open correctly, contain the expected layers or channels, and match the project’s acceptance rule. For deterministic files that can mean hashes; for rendered images it may mean dimensions, channel structure, metadata, finite values, selected pixel checks, and a visual comparison.
The local-versus-farm output guide covers those checks in more detail.
Compare prices on the same basis
Render farms use GPU-hours, machine-hours, GHz-hours, credits, subscriptions, exact quotes, and community points. Preserve each provider’s native unit, then compare the final cost of delivering the same accepted output by the same deadline.
Use normal recurring terms rather than making a winner from a one-time bonus. Keep taxes, storage, transfer, plug-in licenses, billable setup, failed work, and operator time visible where they apply. For a remote workstation, include the time spent installing and troubleshooting while the machine is billable.
The render-farm pricing comparison includes a worksheet for this.
Scenes and workflows worth testing
A single easy scene cannot represent real Blender production.
| Criterion | What it isolates | What to check | Important confounder |
|---|---|---|---|
| Official component scenes | Cycles device throughput under known Blender content | Exact build, device, samples, repetitions, raw timing | Does not measure service onboarding, transfer, queue, or output delivery |
| Dependency asset zoo | Linked libraries, UDIMs, VSE media, IES, OSL, sequences, and caches | Manifest, missing-file report, logs, and output hashes | Provider policies and add-on licensing may limit a nominally valid scene |
| Production animation | Multi-frame parallelism, startup overhead, variance, retries, and delivery | Stage-by-stage timing, every output, final cost, and each rerun | Capacity and queue conditions vary by time and region |
| Output-equivalence scene | EXR layers, passes, color management, compositor, and denoise behavior | Local and farm outputs with hashes and declared pixel tolerance | Bitwise equality may be inappropriate across device or library changes |
Repeat enough to see variation
One successful run is useful for onboarding but weak for speed or reliability. Repeated runs show normal variation in queueing, initialization, frame time, upload, and recovery.
Report the number of runs, median, slow tail, range, failures, and any excluded run with the reason. Alternate provider order where possible so network or cache warming does not always favor the same service. Separate cold starts from warm runs instead of averaging them into one unclear number.
Publish the result artists care about
The main result should be easy to read:
- Did every required output arrive?
- How long did the complete job take?
- What did it cost?
- How much artist time did it require?
- Which failures happened, and how were they recovered?
- Did the original output meet the project requirements?
Supporting details can include stage timing, hardware, logs, file checks, screenshots, and downloads for anyone who wants to investigate further.
Superluminal publishes this test design and is one of the services it can be used to compare. The rules therefore stay the same whether a result favors us or another provider. Our first public scene is the CC0 Classroom project in the Blender 5.1 test plan.