CPU render farm: Warum CPU-Rendering 2026 das Cloud-Rendering weiterhin dominiert

Einführung

GPU-Rendering bekommt die Schlagzeilen. Jeder Hardware-Launch, jeder Benchmark-Vergleich, jedes Render-Engine-Update führt mit GPU-Zahlen. Und dennoch sind auf unserer Farm rund 70 % aller Render-Jobs CPU-basiert. V-Ray CPU, Corona Renderer, Arnold CPU — diese Engines verarbeiten den Großteil der Produktions-Frames in Architekturvisualisierung, Broadcast-Animation und VFX-Compositing.

Dieses Verhältnis ist kein Legacy-Artefakt. Es spiegelt echte technische Vorteile wider, die CPU-Rendering gegenüber GPU für bestimmte Workloads hat — Vorteile, die trotz der erheblichen Reifung der GPU-Engines nicht verschwunden sind. CPU-Rendering bietet Zugriff auf großen Arbeitsspeicher (96–256 GB pro Node in unserer Flotte), tiefe Plugin-Kompatibilität, deterministische Ausgabe und eine Kostenstruktur, die für große Animations-Batches vorhersehbar skaliert.

Dieser Leitfaden erklärt, warum CPU-Rendering 2026 das Rückgrat der Cloud-render-farms bleibt, welche Workflows am meisten von CPU profitieren, wie Sie Ihre Szenen für verteiltes CPU-Rendering optimieren und worauf Sie bei der Auswahl einer CPU-render-farm für Ihre Produktions-Pipeline achten sollten.

Warum CPU-Rendering in einer GPU-Welt weiterhin bestehen bleibt

Die Persistenz des CPU-Renderings hat nichts damit zu tun, dass Studios bei der Adaption neuer Technologie langsam wären. Es geht um drei strukturelle Vorteile, die GPU noch nicht vollständig überwunden hat.

Speicherkapazität. CPU-Rendering nutzt System-RAM — 96 GB bis 256 GB pro Node sind auf produktiven render farms Standard. GPU-Rendering ist durch VRAM eingeschränkt — selbst die NVIDIA RTX 5090 mit 32 GB bietet nur einen Bruchteil dessen, was System-RAM liefert. Für Archviz-Projekte mit Hunderten von hochauflösenden Texturen, schweren Displacement-Maps und Millionen von gescatterten Vegetations-Instanzen ist CPU oft die einzige Option, die keine Szenen-Optimierung erfordert, um in die Speichergrenzen zu passen.

Reife des Plugin-Ökosystems. Die CPU-Rendering-Pipeline wurde über zwei Jahrzehnte hinweg verfeinert. Plugins wie Forest Pack, RailClone, Phoenix FD, Anima und TyFlow wurden für CPU-Workflows entwickelt und optimiert. Ihre Geometrie-Ausgabe kann technisch zwar auf der GPU gerendert werden, der Speicher-Footprint komplexer Scatter (über 10 Millionen Instanzen) überschreitet jedoch häufig das VRAM. Auf CPU rendern diese Szenen ohne Modifikation.

Deterministisches, vorhersehbares Verhalten. CPU-Rendering liefert identische Ergebnisse unabhängig von der Maschine, auf der es läuft (bei identischer Engine-Version und identischen Einstellungen). Das ist für Animationen wichtig, bei denen Frame-zu-Frame-Konsistenz entscheidend ist — und es ist wichtig für die Kostenschätzung, weil CPU-Renderzeiten über ähnliche Szenen hinweg sehr gut vorhersehbar sind.

Welche Render-Engines 2026 CPU nutzen

Nicht alle Engines sind in ihrer CPU-Unterstützung gleich. Hier ist die aktuelle Landschaft:

Render-Engine	CPU-Rendering	GPU-Alternative	CPU bleibt bevorzugt, wenn …
V-Ray 7	Volle Unterstützung, stark optimiert	V-Ray GPU verfügbar	Szene überschreitet VRAM; Plugins hängen vom CPU-Pfad ab; Studio hat eine etablierte V-Ray-CPU-Pipeline
Corona Renderer	Volle Unterstützung, nur CPU	Keine GPU-Version	Immer — Corona ist ausschließlich CPU. Es gibt keine GPU-Alternative
Arnold	Volle Unterstützung	Arnold GPU verfügbar	Schwere VFX-Szenen mit komplexen Shadern; deterministische Ausgabe für Compositing notwendig
Blender Cycles	Volle Unterstützung	GPU von der Community bevorzugt	Szene überschreitet GPU-Speicher; CPU-optimierte Features wie Strand-Rendering werden genutzt
Houdini Mantra	Volle Unterstützung	Karma XPU (hybrid)	Legacy-Houdini-Pipelines; Szenen mit schwerer prozeduraler Geometrie. Hinweis: SideFX stellt auf Karma als primären Renderer um — Mantra wird weiterhin unterstützt, ist aber nicht mehr Standard

Die zentrale Beobachtung: Corona hat überhaupt keinen GPU-Pfad, was bedeutet, dass jeder Corona-Nutzer weltweit auf CPU rendert. Da Corona eine der dominierenden Archviz-Engines ist (neben V-Ray), macht allein dies einen erheblichen Anteil der CPU-render-farm-Workloads aus.

V-Ray bietet sowohl CPU- als auch GPU-Modi, aber viele Studios behalten CPU-Workflows bei, weil ihre bestehenden Szenenbibliotheken, Material-Setups und Plugin-Konfigurationen für CPU optimiert sind. Die Migration zu GPU ist nicht kostenlos — sie erfordert das Testen jeder Szene auf VRAM-Kompatibilität und potenziell den Neuaufbau von Materialien.

Wie eine CPU-render-farm funktioniert

Das Verständnis der Mechanik hilft Ihnen, Ihren Workflow zu optimieren und Kosten vorherzusagen.

Frame-Verteilung. Wenn Sie eine Animation an eine CPU-render-farm übermitteln, weist der Scheduler jeden Frame einer separaten Maschine zu. Eine 500-Frame-Animation, verteilt auf 200 Maschinen, bedeutet, dass 200 Frames gleichzeitig gerendert werden — etwa 2,5 Batches, um die Sequenz abzuschließen. Die Wand-Uhr-Zeit sinkt von potenziell Wochen auf einer einzelnen Workstation auf Stunden auf der Farm.

Pro-Frame-Rendering. Jede Maschine lädt Ihre Szenendatei, initialisiert die Render-Engine und berechnet alle Pixel für den ihr zugewiesenen Frame. In unserer Flotte führt jeder CPU-Node Dual Intel Xeon E5-2699 V4-Prozessoren aus — das sind 44 physische Kerne pro Maschine, die alle gleichzeitig an einem einzelnen Frame arbeiten. Je mehr Kerne pro Node, desto schneller wird jeder einzelne Frame fertig.

Standbild-Rendering. Für einzelne hochauflösende Stills (häufig in Archviz) unterstützen einige Farms Region-Rendering — die Aufteilung eines Frames in Tiles, die über mehrere Maschinen rendern, und anschließendes Compositing der Tiles zum endgültigen Bild. Das wird nicht universell unterstützt, kann jedoch die Bearbeitungszeit für Hero-Shots erheblich verkürzen.

Szenen-Abhängigkeiten. Die Farm benötigt Zugriff auf alles, was Ihre Szene referenziert: Texturen, Proxy-Dateien, Cache-Daten, GI-Maps. Verwaltete Farms übernehmen die Abhängigkeitssammlung über Upload-Tools, die Ihre Szene scannen und alle referenzierten Dateien paketieren. Fehlende Assets sind die häufigste Ursache für gescheiterte Farm-Renderings — und die am leichtesten vermeidbare.

Szenen für CPU-render-farms optimieren

Der Unterschied zwischen einer optimierten und einer nicht optimierten Szene auf einer CPU-Farm kann 2–5× bei den Render-Kosten ausmachen. Diese Optimierungen gelten für jede CPU-Render-Engine.

Textur-Management.

• Verwenden Sie Texturgrößen passend zur Kameradistanz. Eine 4K-Textur auf einem Objekt 50 Meter von der Kamera entfernt verschwendet RAM und Renderzeit — 1K oder 2K sehen auf dieser Distanz visuell identisch aus.
• Konvertieren Sie Texturen in gekachelte Formate (.tx für Arnold, .vrmap für V-Ray), wo unterstützt. Gekachelte Texturen laden nur die Bereiche, die für sichtbare Pixel benötigt werden.
• Auditieren Sie Ihre Texturbibliothek vor dem Upload. Wir sehen regelmäßig Projekte mit über 40 GB an Texturen, von denen 60 % im finalen Frame nie sichtbar sind.

Displacement und Subdivision.

• Displacement-Maps mit hohen Subdivision-Levels sind der größte einzelne Kostenmultiplikator in Archviz. Ein dichter Teppich mit 4 Subdivision-Leveln über eine große Bodenfläche kann die Frame-Renderzeit verdoppeln.
• Verwenden Sie distanzbasierte Subdivision, wo Ihre Engine das unterstützt. Objekte weit von der Kamera entfernt benötigen kein feines Displacement.
• Backen Sie Displacement in Geometrie für Objekte, die in jedem Frame einer Animation erscheinen — die einmaligen Bake-Kosten sind weitaus geringer als die Displacement-Neuberechnung 500 Mal.

Scatter-Optimierung.

• Forest Pack- und RailClone-Szenen mit Millionen von Instanzen verbrauchen enorme Mengen an RAM. Verwenden Sie distanzbasierten Dichte-Falloff: Objekte jenseits von 50 Metern Entfernung von der Kamera können auf 10–20 % Dichte fallen, ohne sichtbaren Unterschied.
• Proxy-Objekte reduzieren den Speicher pro Instanz. Konvertieren Sie detaillierte Meshes in V-Ray-Proxies oder Forest Pack Custom Objects.
• Für Animationen, bei denen sich die Kamera durch eine Landschaft bewegt, setzen Sie die Scatter-Dichte relativ zur Kameraposition, nicht zum Szenenzentrum.

GI und Sampling.

• Für Animationen können Sie die GI-Qualität oft um 30–50 % gegenüber den Einstellungen für Standbilder reduzieren. Bei 24–30 fps Wiedergabegeschwindigkeit ist Pro-Frame-Rauschen in der Bewegung unsichtbar.
• Verwenden Sie Light-Cache- oder Irradiance-Map-Modi, die vorberechnet und über Frames hinweg geteilt werden können — das vermeidet die GI-Neuberechnung von Grund auf bei jedem Frame.
• Zielen Sie auf die minimale Sample-Anzahl, die nach Denoising saubere Ergebnisse liefert. V-Rays integrierter Denoiser und Coronas Denoising erlauben niedrigere Sample-Anzahlen ohne sichtbaren Qualitätsverlust.

CPU-render-farm-Kosten: Was Sie erwarten können

Die Preisgestaltung von CPU-render-farms verwendet typischerweise ein GHz-Stunde-Modell: Sie zahlen für die gesamte CPU-Taktrate multipliziert mit der verbrauchten Zeit.

Wie GHz-Stunde-Preisgestaltung funktioniert:

Eine Maschine mit 44 Kernen, die mit 2,2 GHz läuft, bietet etwa 96,8 GHz an Rechenleistung. Wenn die Farm 0,004 $/GHz-Stunde berechnet und Ihr Frame auf dieser Maschine 10 Minuten benötigt:

96,8 GHz x (10/60) Std. x 0,004 $ = 0,065 $ pro Frame

Für eine 500-Frame-Animation: 500 x 0,065 $ = 32,50 $ insgesamt

Typische Kostenbereiche, die wir bei Produktionsjobs beobachten:

Workflow	Auflösung	Durchschn. Frame-Zeit	Kosten/Frame	Typisches Projekt
Archviz-Interior (V-Ray/Corona)	3000x2000	8–15 Min.	0,08–0,18 $	5–20 Ansichten
Archviz-Exterior (Vegetation)	4000x2250	15–30 Min.	0,18–0,40 $	5–15 Ansichten
Produkt-Visualisierung	4K	5–12 Min.	0,06–0,15 $	10–50 Frames
Broadcast-Animation (Arnold/V-Ray)	1920x1080	3–8 Min.	0,04–0,10 $	1.500–3.000 Frames
Character-Animation (Maya + Arnold)	1920x1080	10–25 Min.	0,12–0,32 $	2.000–5.000 Frames
Schwere VFX (Volumetrics, Partikel)	4K	20–45 Min.	0,25–0,60 $	500–2.000 Frames

Diese Zahlen stammen aus echten Jobs in unserer Flotte. Ihre tatsächlichen Kosten hängen von der Szenenkomplexität, den Render-Einstellungen, der Auflösung und der spezifischen Preisgestaltung der Farm ab. Für eine detaillierte Aufschlüsselung einschließlich GPU-Vergleich siehe unseren render-farm-Kosten-pro-Frame-Leitfaden.

Prioritätsstufen beeinflussen die Gesamtkosten, aber nicht die Pro-Frame-Compute-Kosten. Die meisten Farms bieten niedrige/Standard/hohe Priorität. Niedrige Priorität bedeutet, dass Ihr Job auf verfügbare Maschinen wartet, kostet jedoch 30–50 % weniger als Rush. Wenn Ihre Deadline es erlaubt, ist niedrige Priorität die kostengünstigste Option.

Eine CPU-render-farm auswählen: Worauf es ankommt

Nicht alle CPU-render-farms sind gleichwertig. Worauf Sie achten sollten:

Software- und Plugin-Unterstützung. Verifizieren Sie, dass die Farm Ihre exakte DCC-Version, Render-Engine-Version und kritischen Plugins unterstützt. „Wir unterstützen V-Ray" reicht nicht — Sie benötigen V-Ray 7.0.2 mit Forest Pack 8.x und RailClone 10.x. Verwaltete Farms pflegen spezifische Versionslisten; prüfen Sie diese vor dem Upload.

Kernanzahl und Node-Spezifikationen. Mehr Kerne pro Node bedeuten schnellere einzelne Frames. Eine Farm mit 44-Kern-Nodes rendert jeden Frame schneller als eine mit 16-Kern-Nodes — das ist wichtig für Single-Frame-Bearbeitungszeit und iteratives Testen. Fragen Sie nach dem tatsächlichen CPU-Modell, nicht nur „Hochleistungs-Server".

Maschinenverfügbarkeit. Eine Farm kann High-End-Hardware haben, aber begrenzte Kapazität. Während Spitzenzeiten (Quartalsende, Wettbewerbs-Deadlines) können Wartezeiten in die Höhe schnellen. Fragen Sie nach typischen Wartezeiten und ob die Farm gleichzeitige Node-Zuweisung für Ihren Job garantiert.

Lizenzierungsmodell. Schließt die Farm Render-Engine-Lizenzen im Preis ein, oder bringen Sie Ihre eigenen mit? Die meisten verwalteten Farms inkludieren V-Ray-, Corona- und Arnold-Lizenzen. Das ist ein erheblicher Kostenfaktor — Render-Engine-Lizenzen können beim separaten Kauf signifikante Kosten pro Node und Jahr verursachen (siehe Chaos-Preise für aktuelle V-Ray-Raten).

Upload und Abhängigkeitsverarbeitung. Wie verarbeitet die Farm Szenen-Abhängigkeiten? Eine gute verwaltete Farm bietet einen Uploader, der Ihre Szene auf externe Referenzen scannt und alles automatisch paketiert. Schlechte Abhängigkeitsverarbeitung bedeutet gescheiterte Renderings und verschwendete Credits.

Support-Qualität. Wenn Renderings fehlschlagen — und das werden sie irgendwann — wie schnell und wie technisch kompetent ist der Support? Ein Support-Team, das V-Ray-Light-Cache-Einstellungen oder die Arnold-TX-Texturkonvertierung versteht, ist mehr wert als eines, das aus einem generischen Troubleshooting-Skript abliest.

CPU-Rendering in Archviz: Der dominierende Anwendungsfall

Architekturvisualisierung macht den größten Anteil der CPU-render-farm-Nutzung aus, und die Gründe sind aufschlussreich.

Archviz-Szenen sind von Natur aus speicherintensiv. Ein typisches Wohninterieur enthält Hunderte texturierter Objekte — Möbel mit detaillierten Stofftexturen, Küchengeräte mit reflektierenden Materialien, Bodenbeläge mit Displacement-Maps, Vorhänge mit Translucency. Fügen Sie Außenansichten mit Forest Pack-Vegetation, Landschaftsgestaltung und Umweltelementen hinzu, und die Szenengrößen erreichen regelmäßig 30–60 GB an Daten.

Dieses Speicherprofil passt perfekt zu CPU und überschreitet häufig die GPU-VRAM-Grenzen. Ein Archviz-Studio, das mit V-Ray oder Corona arbeitet, übermittelt Szenen, die zuverlässig auf CPU-Nodes mit 128–256 GB RAM rendern. Dieselben Szenen könnten auf GPU fehlschlagen oder umfangreiche Optimierung erfordern, um in 32 GB VRAM zu passen.

Auch das Workflow-Muster ist CPU-freundlich: Archviz-Projekte benötigen typischerweise 5–20 Kameraansichten (Stills) plus gelegentlich eine Walkthrough-Animation. Die Pro-Frame-Kosten sind moderat, und die gesamten Projektbudgets liegen üblicherweise im Bereich von 50–300 $. Für Studios, die mehrere Projekte monatlich bearbeiten, ersetzt CPU-Cloud-Rendering die Notwendigkeit dedizierter lokaler Render-Hardware, die zwischen den Projekt-Deadlines untätig wäre. Für mehr zu Archviz-spezifischen Workflows siehe unseren render-farm-Leitfaden für Architektur-Studios.

CPU vs. GPU: Wann CPU die falsche Wahl ist

CPU-Rendering ist nicht immer die Antwort. Ehrlich zu seinen Grenzen zu sein, hilft Ihnen, bessere Entscheidungen zu treffen.

Wann GPU tatsächlich besser ist:

• Ihre Engine ist GPU-nativ. Redshift und Octane haben keinen CPU-Modus. Wenn Sie diese Engines nutzen, ist CPU-Rendering keine Option.
• Ihre Szenen passen mit Reserve in VRAM. Für Szenen unter 24 GB an Daten rendert GPU typischerweise 5–8× schneller pro Frame und kostet trotz höherer Stundenrate oft weniger pro Frame.
• Sie benötigen schnelle Iteration. Der Geschwindigkeitsvorteil der GPU ist beim Lookdev am wertvollsten — Dutzende von Test-Frames zum Feinabstimmen von Materialien und Beleuchtung rendern. 15 Minuten pro CPU-Test-Frame gegenüber 2 Minuten auf GPU summieren sich schnell.
• Sie machen Motion Design. Kurzform-Animationen mit stilisierten oder mittelkomplexen Szenen sind dort, wo die GPU-Kosteneffizienz ihren Höhepunkt erreicht.

Für einen detaillierten Vergleich beider Ansätze siehe unseren GPU-Rendering vs. CPU-Rendering-Leitfaden.

Das praktische Muster, das wir beobachten: Studios, die hauptsächlich in Archviz und VFX-Compositing arbeiten, bleiben bei CPU. Studios, die auf Motion Design und lookdev-intensive Workflows fokussiert sind, nutzen GPU. Studios, die beides machen, nutzen eine Farm, die beide Compute-Typen unterstützt.

Die Zukunft des CPU-Renderings

CPU-Rendering verschwindet nicht, aber seine Rolle entwickelt sich weiter.

VRAM wächst. Die 32 GB der RTX 5090 sind das Doppelte dessen, was die RTX 3090 bot. Zukünftige GPU-Generationen werden wahrscheinlich auf 48 GB oder mehr drängen. Mit wachsendem VRAM passen mehr Szenen, die derzeit CPU erfordern, auf GPU. Aber auch die Szenenkomplexität wächst — Artists füllen den verfügbaren Speicher, so dass sich die Zielmarke ständig verschiebt.

Hybrides Rendering reift. Der Hybrid-Modus von V-Ray 7 verteilt die Arbeit gleichzeitig über CPU und GPU auf derselben Maschine. Dieser Ansatz extrahiert maximale Hardware-Auslastung und verwischt die CPU/GPU-Grenze. Auf einer render farm könnte hybrides Rendering bedeuten, dass jeder Node sowohl CPU- als auch GPU-Compute zu Ihrem Job beisteuert.

Auch CPU-Architekturen verbessern sich. AMD EPYC- und Intel Xeon Scalable-Prozessoren fügen weiterhin Kerne hinzu und verbessern die Pro-Kern-Leistung. Ein moderner EPYC 9654 bietet 96 Kerne mit 3,55 GHz — etwa die doppelte Rechenleistung älterer Xeon E5 v4-Prozessoren. CPU-Rendering steht nicht still, während GPU voranschreitet.

Die Richtung von Corona zählt. Als reine CPU-Engine mit großer Nutzerbasis beeinflusst Coronas Roadmap direkt die Nachfrage nach CPU-render-farms. Sollte Chaos irgendwann eine GPU-Version ausliefern, würde das Workloads verschieben. Aber Stand 2026 gibt es keine angekündigte GPU-Roadmap für Corona — was bedeutet, dass CPU-Rendering auf absehbare Zeit garantiert essenziell bleibt.

Zusammenfassung

Faktor	Detail
Warum CPU bestehen bleibt	Speicher (96–256 GB RAM), Plugin-Ökosystem, deterministische Ausgabe, Kosten-Vorhersehbarkeit
Primäre Engines	V-Ray CPU, Corona (nur CPU), Arnold CPU, Cycles, Mantra
Dominanter Anwendungsfall	Archviz (speicherintensive Szenen, Forest Pack/RailClone), VFX-Compositing
Preismodell	GHz-Stunde — Zahlung für verbrauchte CPU-Compute-Zeit
Typische Kosten	0,04–0,60 $ pro Frame, abhängig von Komplexität und Auflösung
Wann CPU NICHT nutzen	GPU-native Engines (Redshift, Octane), Szenen unter 24 GB, Lookdev-Iteration
Trend	Wachsendes VRAM verschiebt einige Workloads zu GPU, aber die Szenenkomplexität wächst parallel

FAQ

Q: Was ist eine CPU-render-farm? A: Eine CPU-render-farm ist ein Netzwerk von Servern, die Prozessor-Kerne (CPUs) verwenden, um 3D-Szenen parallel zu rendern. Jeder Server hat typischerweise 16–96 Kerne, und die Farm verteilt Animations-Frames gleichzeitig über Hunderte von Maschinen. CPU-render-farms verarbeiten den Großteil der Cloud-Rendering-Workloads, insbesondere für V-Ray-, Corona- und Arnold-Projekte, bei denen Szenen mehr Speicher benötigen, als GPU-VRAM bietet.

Q: Ist CPU-Rendering 2026 noch relevant? A: Ja — CPU-Rendering verarbeitet 2026 nach unseren Betriebsdaten etwa 70 % der render-farm-Jobs. Corona Renderer ist nur CPU, V-Ray CPU bleibt der dominierende Modus für Archviz, und Arnold CPU ist Standard in VFX. GPU-Rendering wächst, hat aber CPU für speicherintensive oder plugin-lastige Workflows nicht ersetzt.

Q: Wie viel kostet CPU-Cloud-Rendering? A: Die meisten CPU-render-farms berechnen pro GHz-Stunde. Typische Pro-Frame-Kosten reichen von 0,04 $ für einfache Broadcast-Frames bis 0,60 $ für schwere 4K-VFX-Shots. Ein moderates Archviz-Interior bei 3000x2000 Auflösung kostet typischerweise 0,08–0,18 $ pro Frame. Die Gesamtprojektkosten hängen von Frame-Anzahl, Auflösung und Szenenkomplexität ab. Siehe unseren Kosten-pro-Frame-Leitfaden für detaillierte Preisgestaltung.

Q: Welche Render-Engines funktionieren auf CPU-render-farms? A: V-Ray (CPU-Modus), Corona Renderer, Arnold (CPU-Modus), Blender Cycles und Houdini Mantra unterstützen alle CPU-Rendering. Corona ist ausschließlich CPU — es hat keine GPU-Rendering-Option. V-Ray und Arnold unterstützen sowohl CPU- als auch GPU-Modi und geben Studios die Flexibilität, basierend auf den Szenenanforderungen zu wählen.

Q: Wie optimiere ich meine Szene für eine CPU-render-farm? A: Konzentrieren Sie sich auf drei Bereiche: Reduzieren Sie Texturgrößen für entfernte Objekte (1K–2K statt 4K für Objekte weit von der Kamera), senken Sie Displacement-Subdivision-Levels (verwenden Sie distanzbasierten Falloff) und optimieren Sie die Scatter-Dichte in Forest Pack oder RailClone (fallen Sie jenseits von 50 Metern Kameraentfernung auf 10–20 % Dichte). Diese drei Optimierungen allein können die Render-Kosten um 30–50 % reduzieren.

Q: Was ist der Unterschied zwischen einer verwalteten CPU-render-farm und einem DIY-Cloud-Setup? A: Eine verwaltete Farm installiert Ihre Render-Engine, Plugins und Lizenzen vor — Sie laden eine Szene hoch und erhalten fertige Frames. Ein DIY-Setup (AWS, Azure) gibt Ihnen rohe virtuelle Maschinen, in denen Sie alles selbst installieren. Verwaltete Farms sind einfacher und beinhalten Lizenzierung; DIY-Setups bieten mehr Kontrolle, erfordern aber Pipeline-Engineering-Ressourcen. Für einen tieferen Vergleich siehe unseren Leitfaden zu verwalteten vs. DIY-Cloud-Rendering.

Q: Wie viele CPU-Kerne benötige ich für Rendering? A: Mehr Kerne bedeuten schnellere einzelne Frames. Ein 44-Kern-Render-Node schließt einen Frame etwa 2,5× schneller ab als eine 16-Kern-Workstation. Auf einer Cloud-render-farm wählen Sie die Kernanzahl nicht direkt — Sie wählen, wie viele Maschinen (und mit welcher Priorität) Ihrem Job zugewiesen werden sollen. Die Gesamtkernanzahl der Farm bestimmt, wie viele Frames gleichzeitig rendern können.

Q: Sollte ich von CPU zu GPU-Rendering wechseln? A: Es hängt von Ihrer Engine und Szenenkomplexität ab. Wenn Sie Corona verwenden, haben Sie keine GPU-Option. Wenn Sie V-Ray oder Arnold nutzen und Ihre Szenen regelmäßig in 24–28 GB Daten passen, kann GPU-Rendering schneller und günstiger pro Frame sein. Wenn Ihre Szenen speicherintensiv sind (über 30 GB) oder auf CPU-optimierte Plugins mit großen Scattern angewiesen sind, bleibt CPU die praktische Wahl. Viele Studios nutzen beide — GPU für Iteration und Lookdev, CPU für finale Produktions-Renderings.