Turkey (Türkçe) 
Rendering an animation or an architectural visualization on your own computer makes that computer effectively unusable while the job runs. During a three-hour render you can hardly open a browser or do other work, and if you close the lid or the machine sleeps, the render is left half finished. Moving rendering to a separate GPU server solves this: the job runs in the background on the server, you keep using your computer, the server is on around the clock and the graphics card is dedicated entirely to rendering. In this guide we explain step by step how to render from the command line on a GPU server with Blender's Cycles engine, the difference between OptiX and CUDA, how to split frames across two graphics cards and how to turn the output into a video.
The advantage of rendering on a server is not only that it frees your computer. First, continuity: a monthly rented GPU server also works on weekends and at night; you can start the render queue in the evening and collect the results in the morning. Second, hardware: you can use a card that is stronger or has more VRAM than your home computer without having to buy one. Third, scalability: when the work grows, adding a second server or a dual-card package is the simplest way to build a small render farm. Fourth, isolation: a job running on the server does not affect your daily working environment.
This approach makes sense for people with regular, long render jobs. If you will render a short scene once or twice a year, hourly cloud services or your own computer may be enough. You can find a comparison of the options in our RTX 5090 rendering guide.
Cycles can use the graphics card in two main ways. OptiX takes advantage of the ray tracing cores in RTX series cards and is usually faster than CUDA in Cycles; it also provides the OptiX denoising option. CUDA also works on older cards without ray tracing cores but is slower on the same scene. On an older generation card such as the Tesla P40, you can use only CUDA.
| Card | VRAM | Note for Cycles |
|---|---|---|
| RTX 5060 | 8 GB | OptiX; simple and medium scenes, limited texture size |
| RTX 5060 Ti | 16 GB | OptiX; balanced for most architectural visualization and animation |
| Tesla P40 | 24 GB | CUDA only; large scenes fit but it is slower than RTX cards |
| RTX 5090 | 32 GB | OptiX; the most comfortable option for dense scenes and high resolution |
| Dual card packages | 16 / 32 GB per card | Split the animation across two cards to shorten the time |
VRAM is the critical limit in rendering: the scene's geometry, textures and effects must fit in the card's memory. If they do not, Cycles may fail, or it may move some data to system memory and slow down noticeably. That is why a card with more VRAM is the easiest way to avoid a trap with heavily textured scenes. New generation cards such as the RTX 50 series need a current Blender version; older versions may not recognize the new architecture.
First update the server, install the NVIDIA driver and verify the card with nvidia-smi. Our Ubuntu 24.04 guide shows the driver steps:
sudo apt update && sudo apt -y upgrade
sudo ubuntu-drivers install
sudo rebootAfter the reboot, install the tools needed for rendering. tmux keeps the job running even when the connection drops; ffmpeg turns frames into a video; rsync is for file transfer:
sudo apt -y install tmux ffmpeg rsyncThe easiest way on Ubuntu is the snap package. Alternatively, you can download the Linux archive from Blender's official site and extract it into a directory; with that method it is easy to pin a specific version:
sudo snap install blender --classic
blender --versionIf you choose the archive method, some libraries may be needed to run without an interface:
sudo apt -y install libxi6 libxxf86vm1 libxfixes3 libxrender1 libgl1 libxkbcommon0 libsm6The simplest way to confirm that Cycles sees your card is to render a small frame and look at the device used in the log; we will do that in the next step.
The most common mistake when rendering on a server is missing files: if textures and linked files point to paths on your own computer, they cannot be found on the server and the scene renders with pink textures. There are three ways to prevent this. In Blender you can pack external data (Pack Resources) from the File menu before saving, which embeds textures in the .blend file. Alternatively, you can make paths relative (starting with //) and carry the textures in the same folder tree as the scene. Third, you can gather the scene and all its dependencies in one folder and transfer it to the server as it is.
Also set the render options in the Blender interface before sending the file to the server: the Cycles engine, sample count, resolution, denoising and output format are saved with the file. The command on the server only says which frames to run on which device. Transfer the file to the server with rsync:
rsync -avP project/ user@server-address:~/render/project/First render a single frame to confirm everything works. The part after the -- marker carries Cycles-specific options; this marker is required for the command to work correctly:
cd ~/render/project
blender -b scene.blend -E CYCLES -o //output/frame_#### -F PNG -f 1 -- --cycles-device OPTIXIn the command, -b selects running without an interface, -E CYCLES the engine, -o the output path, -F the format and -f 1 only the first frame. On a card that does not support OptiX, such as the Tesla P40, write CUDA instead of OPTIX. In the output you see the device Blender used; look for your card's name there. If the single frame came out well, start the whole animation. The frame range is set by -s and -e, and -a runs the animation:
tmux new -s render
blender -b scene.blend -E CYCLES -o //output/frame_#### -F PNG -s 1 -e 250 -a -- --cycles-device OPTIX 2>&1 | tee render.logBecause you run the command inside tmux, the job continues even if your connection drops. To leave the session press Ctrl+B and then D; to return use tmux attach -t render. You can follow progress with tail -f render.log.
A physical GPU server for rendering
From the RTX 5060 Ti to the RTX 5090, with single and dual card packages, the graphics card is reserved for you alone. In our Istanbul data center with full root access and fast NVMe storage.
Browse GPU server packagesIf you have a dual-card server, you can split the animation into two halves and give each half to one card. The CUDA_VISIBLE_DEVICES environment variable decides which card is visible. In two separate tmux windows, or in the background, run these commands:
CUDA_VISIBLE_DEVICES=0 blender -b scene.blend -E CYCLES -o //output/frame_#### -F PNG -s 1 -e 125 -a -- --cycles-device OPTIX
CUDA_VISIBLE_DEVICES=1 blender -b scene.blend -E CYCLES -o //output/frame_#### -F PNG -s 126 -e 250 -a -- --cycles-device OPTIXBecause each card processes different frames, the total time drops by roughly half and the output files merge in the same folder with the same numbering. The good side of this method is that it needs no data transfer between cards; scaling is nearly linear. With the same logic you can distribute frame ranges to many servers. Rendering a single frame with two cards together may not give the same gain, depending on the scene and settings, which is why frame splitting is preferred for animations.
If you will render several scenes in sequence, a simple shell loop is enough. The script processes each scene in the folder in turn and keeps a separate log for each:
#!/bin/bash
for f in ~/render/queue/*.blend; do
name=$(basename "$f" .blend)
blender -b "$f" -E CYCLES -o "//output/${name}_####" -F PNG -a -- --cycles-device OPTIX > "$HOME/render/log-${name}.txt" 2>&1
doneYou can run the script inside tmux and leave. When you come back in the morning, every scene's frames and logs are ready. If one scene fails, its log file shows the reason; the other scenes still continue.
Joining the frames into a video on the server with ffmpeg greatly reduces the amount of data you have to download. For a standard, widely compatible output:
ffmpeg -framerate 24 -i output/frame_%04d.png -c:v libx264 -pix_fmt yuv420p video.mp4Ubuntu's ffmpeg package may also include a hardware encoder; check with ffmpeg -encoders | grep nvenc. If present, an encoder such as h264_nvenc speeds up encoding with the help of the graphics card. To download the result to your own computer:
rsync -avP user@server-address:~/render/project/video.mp4 ./You can also shorten the time considerably without changing the card. First, set the sample count to suit the scene: when denoising is on, a high sample count is not needed and the time drops noticeably. Cycles' adaptive sampling also saves time by spending fewer samples on clean regions. Second, do not leave light bounce counts higher than necessary; for most scenes the defaults are enough. Third, in animations the "Persistent Data" option keeps scene data in memory between frames and avoids reloading it on every frame. Fourth, with the "Simplify" settings you can limit texture size and subdivision level, lowering both time and VRAM use. Finally, do a test render at low resolution and a low sample count first; if the settings are right, start at full quality. That way a job that runs until morning is not wasted because of a wrong setting.
While the render runs, run nvidia-smi in another window: if GPU utilization stays above 90 percent, the card is working at full load. If utilization is very low, the bottleneck is elsewhere, usually a slow disk or a scene being prepared on the processor side. If VRAM looks full, the scene is at its limit; you may need to shrink textures, switch off objects that are not visible or choose a card with more VRAM.
nvidia-smi output and that the Blender version supports your card.tmux, the process may have stopped when the connection dropped; always use tmux next time.If your render load is regular, meaning a workflow that fills the queue several days every week, a fixed monthly rental gives a predictable cost; you do not have to count hours. If your workflow fluctuates, try a month on a small package first and measure your real render times, then scale up. Once you know your render time, you can also work out how much a dual-card package or a separate second server would shorten your delivery time. In earlier guides we also covered CPU-heavy rendering with a Ryzen render server; if your scene suits GPU rendering, a graphics card server gives much faster results.
Need a custom setup for your render queue?
For several servers or a dual-card configuration, fill in the quote form.
Go to the GPU server quote formCan I run Blender on a server with no screen?
Yes. Blender runs without an interface (in the background) with the -b flag, and the Cycles engine uses the graphics card directly. That is why rendering from the command line on a server is a common method.
What is the difference between OptiX and CUDA?
OptiX uses the ray tracing cores on RTX series cards and is usually faster than CUDA in Cycles. On older cards without ray tracing cores, such as the Tesla P40, only CUDA can be used.
How much VRAM do I need for rendering?
It depends on the size of the scene's geometry, textures and effects. Simple scenes render with 8 GB; for heavily textured and complex scenes, 16 to 32 GB of VRAM is safer. If memory is not enough, Cycles may fail or slow down.
Do two graphics cards halve the render time?
If you split an animation across two cards, the total time drops by roughly half because each card processes different frames. Rendering a single frame with two cards may not give the same gain, depending on the scene and Blender settings.
Which Blender version should I use for RTX 50 series cards?
New generation cards need a current Blender version; older versions may not recognize the new architecture. After installation, confirm that Cycles lists your card.
How do I get the output when rendering finishes?
You can download the frames to your own computer with rsync or scp. Joining the frames into a video on the server with ffmpeg also reduces the amount of data you need to download.
Does the job stop if my SSH connection drops during rendering?
A job started with tmux or nohup keeps going even if the connection drops. That is why you should always run long renders inside a tmux session.
