Blender render server: Cycles on a GPU machine with no screen

Which cards Cycles will use

Cycles renders on NVIDIA cards through CUDA or OptiX, and both require compute capability 5.0 or higher, per the Blender 5.2 LTS manual. OptiX also requires driver 575 or newer and uses the ray-tracing hardware in RTX cards. GPU-accelerated OpenImageDenoise starts at compute capability 7.0; below that, the OptiX denoiser still runs on the GPU of any card OptiX supports. The capability of each card comes from NVIDIA's own tables; the rows below are cards on our list.

AMD cards render through HIP, which the manual limits to RDNA1 and newer: Radeon RX 5000 to 9000 and Radeon Pro W6000/W7000. The Instinct MI50 and MI210 on our list are not in those families, so for Cycles pick NVIDIA.

Card memory sets the ceiling

The most common reason a scene renders on the CPU but not on the GPU is that it does not fit in card memory, the manual says. With CUDA, OptiX and HIP, Cycles then spills into system memory: slower, but usually still faster than a CPU render. A second card does not add capacity, since each GPU holds its own copy; NVIDIA cards linked with NVLink are the exception, through the Distribute Memory Across Devices preference.

• Figures from the manual's out-of-memory note. By that table, taking a texture from 8k to 4k frees three quarters of its memory.
• Lower Tile Size from the default 2048 to 1024 or 512 when memory runs short; the manual puts the cost at a small slowdown.
• Add --cycles-print-stats to a test render to log memory and time, then size the card from that log rather than from the file size.
• System RAM matters too: blender.org lists 8 GB minimum and 32 GB recommended, and the spill-over lands there.

Installing Blender on the server

1. Install the NVIDIA driver from the distribution's packages or NVIDIA, then confirm the card with nvidia-smi. For OptiX the driver must be 575 or later.
2. Download the official Linux build. The manual warns that some distribution packages ship without Cycles GPU support, and the official binary needs glibc 2.28 or newer.
3. Check the archive against the published checksum and extract it with tar; the manual says 7-zip extraction is not supported.
4. Run blender --version. A minimal server image can lack shared libraries the binary links against; install whatever the error names.

cd /opt
curl -LO https://download.blender.org/release/Blender5.2/blender-5.2.3-linux-x64.tar.xz
curl -LO https://download.blender.org/release/Blender5.2/blender-5.2.3.sha256
grep linux-x64.tar.xz blender-5.2.3.sha256 | sha256sum -c -
tar -xf blender-5.2.3-linux-x64.tar.xz
ln -s /opt/blender-5.2.3-linux-x64/blender /usr/local/bin/blender
blender --version

Run those as root or with sudo, since /opt and /usr/local/bin are system paths. Render as an ordinary user afterwards.

Rendering from the command line

-b runs Blender in the background with no interface, and the manual gives SSH as the typical remote shell for it. Arguments run in the order given, so set output path and format first and put -f or -a last. Cycles options come after a bare --.

# one still, frame 10, on every OptiX card in the machine
blender -b shot.blend -o //out/frame_##### -F OPEN_EXR -f 10 -- --cycles-device OPTIX

# frames 1-240 inside tmux, so a dropped SSH session does not stop the job
tmux new -s render
blender -b shot.blend -o //out/frame_##### -s 1 -e 240 -a -- --cycles-device OPTIX --cycles-print-stats

In the Cycles source, a device given with --cycles-device takes precedence over the scene's CPU/GPU setting and the saved preferences, and takes every card of that type whose driver qualifies. If none does, the render reports that no device of that type was found. CUDA is the other NVIDIA choice, and appending +CPU renders on processor and GPU together.

Flamenco for more than one machine

Flamenco is the render manager the Blender project supports: GPL 3.0, written in Go and SQLite, and used in production at Blender Studio. One Manager hands out tasks; each render machine runs a Worker. Its quickstart assumes a share mounted at the same path on every machine, with Blender installed in the same place everywhere.

• The Manager listens on one port, 8080 by default, for its web interface, API and Shaman file submission. listen accepts an address, so bind it to a private one.
• Sync services such as Syncthing or Dropbox are not supported as shared storage; Flamenco expects a file written by one Worker to be visible to the others at once, as on a NAS.
• A Worker renders on the GPU only when that machine's Blender preferences say so, and the scene must be saved with Device set to GPU Compute. The Flamenco FAQ also warns that --factory-startup in the Blender arguments resets rendering to the CPU. On a headless Worker, set the preference with Blender's Python.
• Flamenco splits a job by frames. A single still cannot be spread across Workers today.

# once per Worker: select OptiX, enable its cards, save the preferences
blender -b --python-expr "import bpy; p = bpy.context.preferences.addons['cycles'].preferences; p.compute_device_type = 'OPTIX'; p.refresh_devices(); [setattr(d, 'use', d.type == 'OPTIX') for d in p.devices]; [print(d.type, d.name, d.use) for d in p.devices]; bpy.ops.wm.save_userpref()"

# flamenco-manager.yaml, Manager on a private address only
listen: 10.8.0.1:8080
shared_storage_path: /srv/flamenco

# flamenco-worker.yaml on each render machine
manager_url: http://10.8.0.1:8080/
task_types: [blender, ffmpeg, file-management, misc]
oom_score_adjust: 500

Machines in different buildings need a private path between them for the Manager port and the share. A WireGuard tunnel is one way to build it; the 10.8.0.1 address above stands for that tunnel.

What the machine gives the render

Our GPU dedicated servers pass the whole card through to an OS you install yourself: no hypervisor, no vGPU profile, no scheduler queue. You pin the driver and the Blender release the project was tested against, and nothing upgrades them under you. You also get every core, all the memory, both disks, root, and the iLO or iDRAC console on a separate management network for the day a driver change takes the network down.

• Unmetered port (1 Gbps on most platforms, 500 Mbps on the Xeon E5-2600 v1/v2 builds): scene files in and EXR sequences out with no byte count.
• The workstation shelf on the GPU list is pitched at rendering; the GeForce shelf at batch rendering, where a flipped bit costs a retry.
• Entry builds carry 16 or 32 GB of RAM; the build-to-order configurator raises it for scenes that spill out of card memory.
• Five cities on our own network, AS19624, though not every card's platform is stocked in every city: multi-GPU and multi-node shows which city carries which platform, and the data centre map has a test IP for each.

When a monthly machine is the wrong tool

• One short deadline a year is better served by something billed per job. A monthly server pays off when frames go through it every week.
• With the card already installed in a racked server, delivery is about 30 minutes from approval; one fitted to order takes 4 to 24 hours. Order before the deadline, not on it.
• More than one card in a chassis is quoted by hand; see multi-GPU and multi-node for what each platform's PCIe lanes allow.
• This page covers Cycles. Other engines have their own requirements; check them before you order.