GPU Render Server

What is a render server and who is it for?

Renting a render server means renting hardware to process your 3D scenes and animations on a remote server with a powerful graphics card. During rendering, your computer’s GPU runs at full load for hours, making it hard to keep modelling, editing or doing anything else; a render server takes on that load while you move on to the next scene.

A render server makes sense for:

• Architectural visualisation studios: interior and exterior images and virtual tours that must meet a delivery date
• Animation and motion graphics studios: animations and commercials with thousands of frames
• Product visualisation: product images from many angles and 360-degree spins for e-commerce
• Freelance 3D artists: extra power per project without investing in their own workstation
• Education and student projects: graduation projects and portfolio animations

This page focuses on topics specific to rendering workloads: which GPU memory a scene will fit into, which engines run on the GPU, how to render from the command line and how to move projects to the server. The GPU, system memory and disk values of each plan are listed in the package table on this page.

GPU rendering or CPU rendering?

With a suitable engine, GPU rendering usually finishes the same scene in noticeably less time than CPU rendering, but the whole scene must fit into the graphics card’s memory. CPU rendering can use all of the system memory, so it is preferred for very large scenes and for engines that run only on the processor.

If the engine you use runs only on the CPU, you do not need to pay for a GPU server; a VDS server or dedicated server with many dedicated cores will be more efficient. For engines that support both GPU and CPU (such as Cycles), the decision depends on whether the scene fits in VRAM. Some engines can keep part of the data in system memory when GPU memory runs out, but much of the speed gain is lost in that case.

How much VRAM does your scene need?

The VRAM a scene needs is decided mostly by textures, geometry density, volumetric effects and render resolution. The most reliable method is to measure GPU memory use while rendering a single frame of the scene on your own computer, then choose a server with headroom above that value.

• Textures: A single uncompressed 8K texture can take hundreds of megabytes; a scene with dozens of 8K textures easily reaches several gigabytes. Using lower-resolution textures for objects that look small on camera is the quickest saving.
• Geometry: Subdivision level and high-poly scanned models increase memory fast.
• Instancing: Adding repeated objects such as trees, grass and crowds as instances rather than copies reduces memory greatly.
• Volumetric effects: Smoke, fire and fog (OpenVDB) data needs gigabytes of memory at high resolution.
• Resolution and render passes: 4K or higher output and many render passes (AOVs) use extra memory.

The memory value shown in Blender’s status line during rendering and the nvidia-smi output on the server are the most practical ways to track real usage. The values in the table are a starting point; they do not replace your own measurement.

Which render engines run on a GPU server?

Blender Cycles, Redshift, Octane, V-Ray GPU and Arnold GPU are the main render engines that run on NVIDIA graphics cards with CUDA and, on RTX cards, OptiX. Blender’s real-time engine Eevee also uses the GPU, but may not run as smoothly as Cycles in a headless server environment; if you plan to use Eevee on the server, do a short test first.

The most frequently overlooked issue with commercial engines is licensing: your desktop licence usually covers only your own computer, and rendering on a server requires a separate render node licence. Check the engine’s licence terms before starting a project. Also verify the operating systems and minimum driver version the engine supports; some plugins run only on Windows. For the server’s operating system and image options, you can open a support ticket from the customer panel.

How do you render from the command line with Blender on a server?

With the -b (background) parameter, Blender runs without opening its interface and renders the scene from the command line; this is the standard way to use Blender on a render server. To use the GPU, you must specify the Cycles device type on the command line.

blender -b scene.blend -E CYCLES \
  -o //output/frame_#### -F PNG \
  -s 1 -e 250 -a -- --cycles-device OPTIX

• -E CYCLES: the render engine.
• -o //output/frame_####: the output path; // means the folder containing the blend file and #### the frame number.
• -F PNG: the output format; EXR is also preferred for intermediate output.
• -s and -e: start and end frame; -a starts the animation. Because Blender processes parameters in order, -a and -f must come last.
• --cycles-device OPTIX: OptiX on RTX cards, CUDA on other NVIDIA cards.

For a single frame, write -f 10 instead of -a. Start long renders in a tmux or screen session so they do not stop if the SSH connection drops. Make sure the Blender version on the server matches the version you prepared the scene in; different versions can produce different results. If you install the driver and CUDA layer yourself, install the NVIDIA driver and CUDA before Blender.

How do you move project files to the render server?

The safest way to move project files to the server is to gather all textures and linked files in a single folder with relative paths and transfer that folder via SFTP or rsync. If the scene is tied to absolute paths on your computer such as C:\Users\..., textures will not be found on the server and you will see pink (missing texture) surfaces in the render.

1. In Blender, make paths relative with File → External Data → Make Paths Relative, or embed textures in the blend file with Pack Resources.
2. Copy linked library files and simulation caches into the project folder.
3. Install the same versions of the add-ons you use in the server’s Blender.
4. Transfer the folder with rsync -avz --progress; if the connection drops, running the command again sends only the missing files.
5. Render a single test frame on the server and compare it with the local result, then start the animation.

In large projects, simulation caches can reach hundreds of gigabytes; NVMe storage matters both for reading after transfer and for writing frame output. For file transfer you can use FileZilla or WinSCP as an SFTP client and set up password-less connections with an SSH key.

How do you plan and distribute animation renders?

Rendering an animation as a frame-by-frame image sequence (PNG or EXR) rather than a video file lets you resume where you left off after an interruption and distribute frames across several GPUs or servers. If an animation rendered directly to MP4 is interrupted, you often have to start over.

• Resume where you left off: If you turn off Overwrite and turn on Placeholders in Blender’s output settings, completed frames are skipped, and running the same command in several processes shares the frames automatically.
• Persistent data: Cycles’ Persistent Data option keeps scene data in memory between frames, reducing reload time on each frame; it speeds up animations on systems with enough memory.
• Render farm: To distribute across several servers, you can use Flamenco, Blender’s official render farm manager; jobs are distributed to workers through a manager.
• Low quality first: Check camera moves and timing at low samples and resolution, and start the final render after approval.

Once frames are complete, you can convert them to video with FFmpeg, for example ffmpeg -framerate 25 -i frame_%04d.png -c:v libx264 -pix_fmt yuv420p film.mp4. On NVIDIA cards, the hardware encoder (NVENC) shortens encoding time.

How do you shorten render times?

The most effective ways to shorten render times are lowering the sample count together with a denoiser, adjusting light path limits to the scene, and reducing unnecessary geometry and textures. Before moving to a more powerful GPU, these settings often cut render time significantly.

1. Adaptive sampling and noise threshold: In Cycles, the Noise Threshold value stops sampling early in clean areas.
2. Denoiser: OptiX or OpenImageDenoise gives a clean image with fewer samples; test for flicker between frames in animations.
3. Light paths: Reduce reflection, refraction and indirect light bounce counts to what the scene really needs.
4. Caustics and volumes: Turn off caustics unless needed and increase the step size for volumetric effects.
5. Textures and geometry: Use the Simplify settings for objects far from the camera.
6. Region tests: Try settings on a small render region instead of the whole frame.

Do not change settings without measuring: note the time of the same frame after every change. Monitor whether GPU usage stays consistently high on the server with nvidia-smi; if the GPU is often idle, the bottleneck is on the disk, scene loading or the CPU side.

Can a render server be used for video encoding and post-processing?

Yes; besides 3D rendering, a GPU server can be used to turn image sequences into video, for batch video encoding and for post-processing steps that run from the command line. The hardware encoder (NVENC) on NVIDIA cards takes H.264 and HEVC encoding off the CPU and hands it to a dedicated unit on the graphics card, shortening encoding time for long videos.

Post-processing jobs that run efficiently on a server include:

• Video from frame sequences: Converting PNG or EXR sequences to the delivery format with FFmpeg; for NVENC, choose h264_nvenc or hevc_nvenc as the encoder.
• Batch conversion: Automatically producing web, social media and presentation versions of the same video at different resolutions and bitrates.
• Compositing with Blender: Processing render passes with Blender’s compositing nodes from the command line.
• Preview generation: Preparing low-resolution draft videos for client approval overnight.

Using editing and colour grading software that requires a graphical interface (for example DaVinci Resolve or Premiere Pro) on a remote server depends on licence terms, the operating system and remote desktop performance. For such interactive work, test the remote connection experience with a short trial first; for batch jobs that need no interface, the server is at its most efficient.

Rent a render server or buy a workstation?

Renting a render server makes more sense if your rendering needs are irregular and project-based, if your workstation is fine for modelling and editing but locks up during renders, or if you need temporary extra power around delivery dates. For studios that render heavily every day all year round, investing in their own hardware should be compared over the long term.

LIONFIN servers run in a data center with cold aisles kept at 18–24 °C and are monitored by a 24/7 NOC team, so hours of full-load rendering avoid the heat and noise problems of an office. Read more about our data center. The difference between a dedicated GPU server and an hourly cloud GPU is explained on the dedicated GPU server or cloud GPU page.

How do you keep client projects safe on a render server?

The foundation of protecting client projects on a render server is accessing the server only with SSH keys, transferring files over encrypted channels, separating user accounts and deleting data when the project ends. Architectural projects and unreleased product images are often covered by a non-disclosure agreement (NDA).

• Access: Disable password login and give each team member a separate user and SSH key.
• Transfer: Use SFTP or rsync over SSH instead of unencrypted protocols such as FTP.
• Firewall: Do not expose the web interfaces of managers such as Flamenco to the internet; access them through an SSH tunnel.
• Data lifecycle: After delivering the project, delete source files and intermediate output from the server and keep them only in your own archive.
• Backup: Render output can be regenerated but takes time; copy completed frame sequences to a second location before delivery.

At network level, the RouteFence firewall in the LIONFIN infrastructure filters DDoS attacks and 24/7 SOC monitoring tracks security events. If you also run language models on GPU hardware, see LLM server hosting.

What are the most common problems on a render server?

The most common problems on render servers are the GPU not being used, insufficient VRAM, missing textures and results that differ from the local computer. The first diagnostic step is to check GPU usage and memory occupancy with nvidia-smi during rendering.

• Rendering runs on the CPU: Blender’s GPU preference is stored in user preferences and does not carry over automatically in headless mode. Specify --cycles-device OPTIX or CUDA in the command and make sure the scene’s Device setting is GPU Compute.
• “Out of memory” / “System is out of GPU memory”: The scene does not fit in VRAM. Lower texture resolution, use instancing, limit subdivision with Simplify or move to a plan with more VRAM.
• Pink surfaces: Textures cannot be found; make paths relative or pack the textures.
• Image differs from the local result: The Blender or add-on version is different, or colour management settings have changed.
• Render stopped when SSH dropped: Start the process inside tmux or screen.
• GPU not visible: The driver is not loaded, or the driver module was not rebuilt after a kernel update; if nvidia-smi returns an error, reinstall the driver.

If the problem persists, adding your render command and the nvidia-smi output to your support request speeds up diagnosis.