12. November 2026 · VRAMfarm-Team
Blender auf einer gemieteten GPU rendern: Cycles headless, mehrere Maschinen, Octane, Redshift
Der Kunde will bis morgen früh 240 Frames eines Kameraflugs durch einen Innenraum. Jeder Frame braucht auf Ihrer RTX 3070 zu Hause 4 Minuten, der Job also 16 Stunden, und Sie haben 10. Auf gemieteten Karten dauern dieselben Frames auf einer RTX 4090 etwa 1,5 Minuten pro Stück, und auf vier Server verteilt ist die ganze Sequenz in weniger als zwei Stunden fertig, für ungefähr dasselbe Geld wie auf einer einzigen Karte. Blenders Cycles eignet sich gut dafür: Es läuft über die Kommandozeile, braucht keine Lizenz und nutzt NVIDIAs OptiX-Raytracing auf jeder RTX-Karte.
Welche Karte: RT-Kerne zählen mehr als das Rechenzentrums-Label
Cycles mit OptiX nutzt für das Raytracing die RT-Kerne der RTX-Karten. Die großen Rechenzentrums-GPUs (A100, H100, H200, B200) haben überhaupt keine RT-Kerne. Cycles läuft trotzdem darauf, aber eine RTX 4090 rendert denselben Frame schneller, zu einem Bruchteil des Stundenpreises. Zum Rendern schauen Sie sich die RTX- und L-Serie an.
| Karte | VRAM | RT-Kerne | Hinweise zum Rendern |
|---|---|---|---|
| RTX 3090 | 24 GB | 2. Generation | Günstig pro Stunde, etwa halb so schnell wie eine 4090 |
| RTX 4090 | 24 GB | 3. Generation | Der Standard: schnell und breit verfügbar |
| RTX 5090 | 32 GB | 4. Generation | Etwa ein Drittel schneller als eine 4090, 8 GB mehr |
| RTX A6000 | 48 GB | 2. Generation | Große Szenen mit dem Tempo einer 3090 |
| L40S | 48 GB | 3. Generation | Große Szenen fast mit dem Tempo einer 4090 |
| RTX PRO 6000 | 96 GB | 4. Generation | Sehr große Szenen, Tempo einer 5090 |
| A100, H100 | 80 GB | keine | Teuer fürs Rendern; meiden, außer der Speicher erzwingt es |
Die Verhältnisse sind grob. Der Benchmark Blender Open Data listet für die meisten dieser Karten gemessene Werte je Blender-Version, das ist der beste Vergleich. Setzen Sie den Wert dann ins Verhältnis zum Stundenpreis auf unserer Preisseite: Bei langen Jobs über Nacht gewinnt pro Frame oft die 3090, bei knapper Deadline die 4090 und die 5090.
Wie viel VRAM eine Szene braucht
Cycles braucht auf der GPU die ganze Szene im Grafikspeicher: Geometrie, die Beschleunigungsstruktur (BVH), Texturen und die Framebuffer. Passt sie nicht, kann Cycles einen Teil der Daten in den Arbeitsspeicher verlagern, aber das Rendern wird dann stark langsamer, und sehr große Szenen scheitern ganz.
Ein paar Anhaltspunkte:
- Produktaufnahmen, Motion Graphics, einfache Innenräume: 2–8 GB. Jede Karte im Katalog.
- Detaillierte Architekturvisualisierung mit 4K-Texturen: 8–20 GB. Karten mit 24 GB.
- Gestreute Vegetation, große Außenszenen, viele 8K-Texturen: 20–45 GB. Eine unkomprimierte 8K-Textur mit Alphakanal hat in 8 Bit etwa 256 MB, in Float das Vierfache; fünfzig davon summieren sich schnell. Karten mit 48 GB.
- Szenen in Filmgröße, riesige instanzierte Menschenmengen oder Wälder: 48–96 GB. RTX PRO 6000.
Um Ihren eigenen Wert zu kennen, rendern Sie einen Frame auf Ihrem Computer und lesen den Spitzenverbrauch in der Statusleiste ab, oder Sie rendern einen Testframe auf dem Server und beobachten dabei nvidia-smi. Vereinfachen Sie dort, wo es nichts kostet: Texturen für entfernte Objekte brauchen selten 8K, und die Begrenzung der Texturgröße in Cycles (Render Properties → Simplify) zeigt schnell, wie viel das spart. Der VRAM-Ratgeber wendet dieselbe Logik auf KI-Modelle an.
Die Szene auf den Server bringen
Eine .blend-Datei, die zu Hause einwandfrei rendert, scheitert auf einem Server oft, weil sie auf Texturen unter C:\Users\... verweist. Vor dem Hochladen:
- File → External Data → Make Paths Relative, dann Pack Resources, um die Texturen in die .blend-Datei zu packen. Oder Sie lassen sie in Ordnern neben der Datei, mit relativen Pfaden, und zippen den ganzen Projektordner.
- Simulationen backen (Flüssigkeiten, Stoff, Partikel, Caches von Geometry Nodes), und zwar zu Hause, und die Cache-Ordner mitschicken. Ein Server simuliert nicht neu, was er nicht findet.
- Add-ons prüfen. Add-ons, die beim Rendern gebraucht werden, müssen auch im Blender auf dem Server installiert sein. Die meisten Szenen brauchen keine.
- Die Ausgabe in der Datei festlegen: Format (PNG oder OpenEXR für späteres Compositing), Auflösung, Samples, Frame-Bereich. Schalten Sie für Animationen Persistent Data ein (Render Properties → Performance): Cycles behält die Szene dann zwischen den Frames geladen.
Laden Sie die ZIP-Datei über den Upload-Button von Jupyter hoch, mit scp/rsync über SSH (Anleitung für den SSH-Schlüssel), oder legen Sie sie in Ihren eigenen Cloud-Speicher und laden sie auf dem Server mit wget oder rclone herunter. Bei mehreren Maschinen ist die letzte Variante am einfachsten: Jeder Server holt sich denselben Link. Downloads zählen als Traffic zum Tarif der Maschine, den Sie vor dem Start sehen.
Blender installieren und über die Kommandozeile rendern
Starten Sie einen leeren Server PyTorch + Jupyter; dass PyTorch dabei ist, spielt keine Rolle. Öffnen Sie ein Terminal in Jupyter oder über SSH. Installieren Sie die wenigen Systembibliotheken, die Blender erwartet, und laden Sie dann dieselbe Blender-Version herunter, die Sie zu Hause nutzen (kopieren Sie den Linux-Link von 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
Meldet Blender beim Start eine fehlende .so-Datei, installieren Sie das genannte Paket und versuchen es erneut. Speichern Sie dann Folgendes als /workspace/gpu.py. Das Skript stellt Cycles auf OptiX um, auf jeder GPU der Maschine, egal was in der .blend-Datei steht:
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"
Rendern Sie die 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
Die Reihenfolge ist wichtig: Das Python-Skript sowie die Optionen für Ausgabe, Start und Ende müssen vor -a stehen. Das Log zeigt zuerst die Geräte an. Ist kein OptiX-Gerät aufgeführt, sieht der Container die OptiX-Bibliothek nicht; ändern Sie dann "OPTIX" an beiden Stellen in "CUDA". CUDA ist auf RTX-Karten langsamer als OptiX, funktioniert aber überall. Ein einzelner Frame mit -f 1 statt -a ist ein guter Test vor dem kompletten Durchlauf.
nohup hält das Rendern am Laufen, wenn Sie den Browser schließen oder die Verbindung verlieren. Ein laufendes Rendering hält die GPU beschäftigt, der Leerlaufschutz stoppt es also nicht. Ist der letzte Frame geschrieben, wird die GPU ruhig: Ohne Verbindung bekommen Sie nach etwa zwei Stunden eine Leerlaufwarnung, und eine Stunde später speichert der Server /workspace (samt Frames) und stoppt. Günstiger ist es, ihn selbst zu stoppen, sobald die Frames heruntergeladen sind.
Mehrere Maschinen für eine Deadline
Cycles rendert Frames unabhängig voneinander, die einfachste Farm ist also ein aufgeteilter Frame-Bereich:
| Server | Bereich im Befehl |
|---|---|
| 1 | -s 1 -e 60 |
| 2 | -s 61 -e 120 |
| 3 | -s 121 -e 180 |
| 4 | -s 181 -e 240 |
Vier ist auch die Höchstzahl an Servern, die ein Konto gleichzeitig betreiben kann. Starten Sie alle mit demselben Kartenmodell, damit sie gemeinsam fertig werden, richten Sie jeden gleich ein (ein kurzes Shell-Skript, das Sie in jedes Terminal einfügen, erspart Fehler) und starten Sie jeden mit seinem eigenen Bereich. Wenn alle fertig sind, zippen Sie auf jedem /workspace/render, laden die Dateien herunter und legen die Frames in einen Ordner. Ihr Schnittprogramm oder der Video Sequencer von Blender setzt sie zusammen.
Vier Server kosten an GPU-Zeit etwa so viel wie ein Server, der alle Frames rendert, plus die Einrichtungsminuten auf jedem (Blender-Download, Upload der Szene, etwa 10 Minuten) und das Minimum von 15 Minuten pro Start. Sie zahlen etwas mehr und sind viermal so schnell fertig. Für größere oder regelmäßige Jobs startet, listet und stoppt die VRAMfarm-API Server aus einem Skript, sodass ein Render-Skript seinen eigenen Server stoppen kann, sobald der letzte Frame geschrieben ist.
Octane und Redshift: mit eigener Lizenz
Beide laufen auf gemieteten NVIDIA-Karten, sind aber anders als Blender kommerzielle Renderer, und um die Lizenz kümmern Sie sich selbst. Wir stellen für keinen der beiden Lizenzen bereit.
OctaneRender (OTOY) rendert nur auf der GPU und läuft unter Linux. Sie melden sich auf jedem Server mit Ihrem OTOY-Konto an, und Ihre Abo-Stufe bestimmt, wie viele GPUs gleichzeitig rendern dürfen; prüfen Sie das, bevor Sie vier Maschinen starten. Ob eine Lizenz auf gemieteter Hardware genutzt werden darf, regeln die Bedingungen von OTOY, lesen Sie sie also für Ihren Tarif nach. Die Blender-Edition von Octane ist ein eigener Blender-Build mit eigener Einrichtung; wie Sie damit über die Kommandozeile rendern, steht in der Dokumentation von OTOY.
Redshift (Maxon) wird über Ihr Maxon-Konto lizenziert, ein Platz pro gleichzeitig rendernder Maschine. Auf einem Headless-Linux-Server melden Sie sich mit dem Kommandozeilen-Lizenztool von Maxon an. Gerendert wird mit redshiftCmdLine und exportierten .rs-Szenendateien oder über den Batch-Renderer der Host-Anwendung (Houdini, Maya oder der Kommandozeilen-Renderer von Cinema 4D). Prüfen Sie die aktuellen Bedingungen von Maxon für Render-Nodes, bevor Sie einen Job auf mehreren Maschinen planen.
Für beide gelten zwei praktische Punkte. Installieren Sie die Version, die zu Ihrer lokalen passt, damit die Szene gleich rendert. Und prüfen Sie vor dem Start die Treiberversion der Maschine, denn GPU-Renderer verlangen einen Mindesttreiber; worauf Sie achten müssen, erklärt der Ratgeber zu CUDA und Treibern. Werkzeuge, die einen Desktop brauchen, etwa der Unreal Editor oder die Oberfläche von DaVinci Resolve, passen schlecht zu Headless-Servern und sind hier nicht behandelt.
Kosten pro Frame: vor dem Mieten ausrechnen
Die Formel ist einfach: Stundenpreis × Minuten pro Frame ÷ 60. Schwierig sind die Minuten pro Frame, also messen Sie sie: Rendern Sie Frame 1 auf dem gemieteten Server und multiplizieren Sie. Ein Teststart kostet mindestens das Minimum von 15 Minuten, mit der Einrichtung etwas mehr.
Unser Beispiel mit 240 Frames, bei 1,5 Minuten pro Frame auf einer RTX 4090:
- Ein Server: 240 × 1,5 = 360 Minuten, plus 10 Minuten Einrichtung: etwa 6 Std. 10 Min., 3,64 €, fertig nach etwa sechs Stunden.
- Vier Server: 60 × 1,5 = 90 Minuten pro Server, plus 10 Minuten Einrichtung: je 100 Minuten, insgesamt 6 Std. 40 Min., 3,94 €, fertig in weniger als zwei Stunden.
- Auf einer RTX 3090 mit etwa 3 Minuten pro Frame, ein Server: etwa 12 Std. 10 Min., 3,65 €, wenn die Deadline das zulässt.
Dazu kommt Traffic für Szene und Frames zum Tarif der Maschine. Die Frames sind oft der größere Teil: 240 Frames OpenEXR in 1080p können mehrere Gigabyte groß sein.
Um die Minuten pro Frame zu senken, sind die üblichen Stellschrauben in Cycles weniger Samples mit Denoising (OptiX oder OpenImageDenoise), Adaptive Sampling, Persistent Data für Animationen und weniger Light-Path-Bounces, wo die Szene sie nicht braucht. Testen Sie das an Frame 1, bevor Sie die Farm starten, denn jede gesparte Sekunde wird mit 240 multipliziert.