12 November 2026 · VRAMfarm team

Blender rendering on a rented GPU: Cycles headless, several machines, Octane and Redshift

The client wants 240 frames of an interior flythrough by tomorrow morning. Each frame takes 4 minutes on your RTX 3070 at home, so the job needs 16 hours and you have 10. On rented cards the same frames take about 1.5 minutes each on an RTX 4090, and split across four servers the whole sequence is done in under two hours, for roughly the same money as rendering it on one card. Blender’s Cycles is a good fit for this: it runs from the command line, needs no licence, and uses NVIDIA’s OptiX ray tracing on any RTX card.

Which card: RT cores matter more than the datacenter badge

Cycles with OptiX uses the RT cores on RTX cards for ray tracing. The big datacenter GPUs (A100, H100, H200, B200) have no RT cores at all. Cycles still runs on them, but an RTX 4090 renders the same frame faster at a fraction of the price per hour. For rendering, look at the RTX and L-series cards.

The ratios are rough. The Blender Open Data benchmark lists measured scores for most of these cards in each Blender version, which is the best way to compare. Then compare the score with the price per hour on our pricing page: the 3090 often wins per frame for long overnight jobs, the 4090 and 5090 when the deadline is close.

How much VRAM a scene needs

Cycles on the GPU needs the whole scene in video memory: geometry, the acceleration structure (BVH), textures and the frame buffers. If it doesn’t fit, Cycles can move some data into system RAM, but rendering slows down sharply, and very large scenes fail outright.

Some reference points:

• Product shots, motion graphics, simple interiors: 2–8 GB. Any card in the catalogue.
• Detailed archviz with 4K textures: 8–20 GB. 24 GB cards.
• Scattered vegetation, large exteriors, many 8K textures: 20–45 GB. An uncompressed 8K texture with alpha is about 256 MB in 8-bit and four times that in float, so fifty of them add up quickly. 48 GB cards.
• Film-scale scenes, huge instanced crowds or forests: 48–96 GB. RTX PRO 6000.

To know your number, render one frame on your own computer and read the peak memory in the status bar, or render one test frame on the server while watching nvidia-smi. Simplify where it is cheap: textures for distant objects rarely need 8K, and Cycles’ texture size limit (Render Properties → Simplify) is a quick test of how much it saves. The VRAM guide covers the same logic for AI models.

Getting the scene onto the server

A .blend file that renders perfectly at home often fails on a server because it points to textures on C:\Users\.... Before uploading:

1. File → External Data → Make Paths Relative, then Pack Resources to put textures into the .blend. Or keep them in folders next to the file, with relative paths, and zip the whole project folder.
2. Bake simulations (fluids, cloth, particles, geometry nodes caches) at home, and include the cache folders. A server will not re-simulate what it can’t find.
3. Check add-ons. Render-time add-ons must also be installed in Blender on the server. Most scenes need none.
4. Set the output in the file: format (PNG or OpenEXR for compositing later), resolution, samples, frame range. For animations, switch on Persistent Data (Render Properties → Performance): Cycles then keeps the scene loaded between frames.

Upload the zip through Jupyter’s upload button, with scp/rsync over SSH (SSH key guide), or put it in your own cloud storage and download it on the server with wget or rclone. For several machines the last option is easiest: every server fetches the same link. Downloads count as traffic at the machine’s rate, which you see before launch.

Installing Blender and rendering from the command line

Start an empty PyTorch + Jupyter server; it doesn’t matter that it comes with PyTorch. Open a terminal in Jupyter or over SSH. Install the few system libraries Blender expects, then download the same Blender version you use at home (copy the Linux link from blender.org):

apt-get update && apt-get install -y xz-utils libxrender1 libxi6 libxkbcommon0 \
  libxxf86vm1 libxfixes3 libsm6 libgl1 libegl1
cd /workspace
wget <Linux link for your Blender version from blender.org/download>
tar -xf blender-*-linux-x64.tar.xz && mv blender-*-linux-x64 blender

If Blender complains about a missing .so file on start, install the package it names and try again. Then save this as /workspace/gpu.py. It switches Cycles to OptiX on every GPU in the machine, whatever the .blend file says:

import bpy
prefs = bpy.context.preferences.addons["cycles"].preferences
prefs.compute_device_type = "OPTIX"
prefs.get_devices()
for d in prefs.devices:
    d.use = d.type == "OPTIX"
    print("device:", d.name, d.type, d.use)
bpy.context.scene.cycles.device = "GPU"

Render the animation:

cd /workspace/project
nohup /workspace/blender/blender -b scene.blend --python /workspace/gpu.py \
  -o /workspace/render/frame_#### -s 1 -e 240 -a > /workspace/render.log 2>&1 &
tail -f /workspace/render.log

The order matters: the Python script and the output, start and end options must come before -a. The log prints the devices first. If no OptiX device is listed, the container can’t see the OptiX library; change "OPTIX" to "CUDA" in both places. CUDA is slower than OptiX on RTX cards but works everywhere. Rendering a single frame with -f 1 instead of -a is a good test before the full run.

nohup keeps the render going when you close the browser or lose the connection. An active render keeps the GPU busy, so idle protection doesn’t stop it. Once the last frame is written, the GPU goes quiet: with nothing connected, you get an idle warning after about two hours, and an hour later the server saves /workspace (frames included) and stops. Stopping it yourself as soon as the frames are downloaded is cheaper.

Several machines for one deadline

Cycles renders frames independently, so the simplest farm is a split frame range:

Four is also the most servers one account can run at a time. Launch them on the same card model so they finish together, run the same setup on each (a short shell script you paste into each terminal saves mistakes), and start each with its own range. When they finish, zip /workspace/render on each, download, and drop the frames into one folder. Your editor or Blender’s video sequencer assembles them.

Four servers cost about the same in GPU time as one server doing all the frames, plus the setup minutes on each (Blender download, scene upload, about 10 minutes) and the 15-minute minimum per launch. You pay a little more to finish four times sooner. For bigger or regular jobs, the VRAMfarm API starts, lists and stops servers from a script, so a render script can stop its own server the moment its last frame is written.

Octane and Redshift: bring your own licence

Both run on rented NVIDIA cards, but unlike Blender they are commercial renderers, and the licence is yours to arrange. We don’t provide licences for either.

OctaneRender (OTOY) is GPU-only and runs on Linux. You sign in with your OTOY account on each server, and your subscription tier decides how many GPUs can render at once; check before you start four machines. OTOY’s terms decide whether a licence can be used on rented hardware, so read them for your plan. Octane’s Blender edition is a separate Blender build with its own setup; follow OTOY’s documentation for rendering it from the command line.

Redshift (Maxon) is licensed through your Maxon account, one seat per machine rendering at a time. On a headless Linux server you sign in with Maxon’s command-line licensing tool. Rendering itself goes through redshiftCmdLine with exported .rs scene files, or through the host application’s batch renderer (Houdini, Maya, or the Cinema 4D command-line renderer). Check Maxon’s current terms for render nodes before planning a multi-machine job.

Two practical points apply to both. Install the version that matches your local one, so the scene renders the same. And check the machine’s driver version before launch, because GPU renderers require a minimum driver; the CUDA and driver guide explains what to look for. Tools that need a desktop, such as the Unreal Editor or DaVinci Resolve’s interface, are a poor fit for headless servers and are not covered here.

Cost per frame: work it out before you rent

The formula is simple: price per hour × minutes per frame ÷ 60. The hard part is minutes per frame, so measure it: render frame 1 on the server you rented and multiply. A test launch costs at least the 15-minute minimum, a little more with the setup.

Our 240-frame example, at 1.5 minutes per frame on an RTX 4090:

• One server: 240 × 1.5 = 360 minutes, plus 10 minutes of setup: about 6 h 10 min, €3.64, finished in about six hours.
• Four servers: 60 × 1.5 = 90 minutes each, plus 10 minutes of setup: 100 minutes each, 6 h 40 min in total, €3.94, finished in under two hours.
• On an RTX 3090 at about 3 minutes per frame, one server: about 12 h 10 min, €3.65, if the deadline allows it.

Add traffic for the scene and the frames at the machine’s rate. Frames are often the larger part: 240 frames of 1080p OpenEXR can be several gigabytes.

To lower the minutes per frame, the usual Cycles levers are fewer samples with denoising (OptiX or OpenImageDenoise), adaptive sampling, Persistent Data for animations, and lower light-path bounces where the scene doesn’t need them. Test them on frame 1 before launching the farm, because every saved second is multiplied by 240.