Rendering wandelt eine 3D-Szene in ein fertiges Bild um. Auf unserem Server benötigten drei Blender-Szenen im Median 5.5 s, 10.3 s und 8.9 s. Getestet wurde eine RTX PRO 6000 Blackwell Max-Q mit Blender 5.2.0 LTS und dem Cycles-Renderer.
Die Ergebnisse gehören der Reihe nach zu monster, junkshop und classroom. Unsere Benchmark-Methodik hilft, die gemessene Rechenphase von der gesamten Bearbeitungsdauer zu unterscheiden. Die genauen Einstellungen und das Verfahren dieser kurzen Serie stehen weiter unten; Regeln späterer Testkampagnen werden ihr nicht nachträglich zugeschrieben.
Wofür lässt sich ein Rendering-Server nutzen?
Remote-Rendering kann die Workstation eines Designers entlasten, während Produktvisualisierungen, Innenräume oder Animationsbilder entstehen. Bereiten Sie das Projekt in Ihrer eigenen Umgebung vor, übertragen Sie die erforderlichen Dateien auf den Server und starten Sie die Berechnung. Laden Sie anschließend das Ergebnis herunter; Ihr lokaler Rechner muss nicht die ganze Zeit mit dem Rendering beschäftigt sein.
Das ist besonders sinnvoll, wenn es zu Ihrem Ablauf passt: Das Projekt lässt sich samt Abhängigkeiten übertragen, und das Einsammeln der Ergebnisse erfordert keine ständige manuelle Aufmerksamkeit. Der GPU-Zugriff allein liefert jedoch noch kein vollständiges System für Auftragswarteschlangen. Das Starten von Aufgaben, Organisieren von Dateien und Prüfen der Ergebnisse gehört zur Einrichtung Ihrer eigenen Umgebung.
Was bedeuten die angegebenen Sekunden?
Gemessen wurde der Renderaufruf einschließlich der darin ausgeführten Szenenvorbereitung. Programmstart, erstmaliges Laden des Projekts, Dateiübertragungen und Speichern des Bildes waren ausgeschlossen. Jedes hervorgehobene Ergebnis ist der mittlere Wert dreier Messungen nach einem Aufwärmlauf: der Median.
In der Praxis sind zwei Messungen hilfreich. Eine zeigt, wie schnell die gewählte Renderphase läuft. Die andere umfasst die Zeit von der Auftragsvorbereitung bis zum Abruf der fertigen Datei. Bei großen Projektübertragungen oder wiederholten Programmstarts kann diese Unterscheidung für den Ablauf wichtig sein.
Unsere Ergebnisse betreffen den ersten Umfang. Es sind keine Blender-Open-Data-Punktwerte, obwohl wir Szenen aus dem offiziellen Archiv verwendet haben. Sie sollten weder direkt mit Punkten eines anderen Benchmarks verglichen noch als gesamte Durchlaufzeit eines Rendering-Services verstanden werden.
Wie prüfen Sie Ihr eigenes Projekt?
Eine Probe realer Arbeit ist die beste Referenz, mit derselben Anwendungsversion, Auflösung und Qualitätseinstellung. Prüfen Sie, ob alle erforderlichen Dateien enthalten sind, und vergleichen Sie die fertigen Bilder statt nur der Abschlussmeldung. Nehmen Sie bei Animationen auch eine anspruchsvollere Passage auf, statt für jedes Bild dasselbe Verhalten anzunehmen.
Eine Qualitätsänderung verändert die Aufgabe. Eine kürzere Zeit mit anderen Einstellungen isoliert keinen Hardwareunterschied. Auch unsere Szenen unterscheiden sich in Komplexität und Auflösung: monster, junkshop und classroom liefern drei Referenzaufgaben, keine drei identischen Versuche.
Dokumentieren Sie Blender- und Treiberversion, Renderverfahren, Auflösung und Sampling-Einstellungen. Bei einer späteren Wiederholung oder einem Vergleich mit einem anderen Rechner kann dann dasselbe Projekt statt einer versehentlich veränderten Konfiguration verwendet werden.
Speicher und Umfang dieser Prüfung
Die Karte verfügt über 96GB GPU-Speicher, doch diese Szenen testeten nicht dessen volle Kapazität: Der höchste beobachtete Wert der Serie betrug etwa 8GiB. Mehr Speicher macht nicht automatisch jede Szene schneller. Ein aufwendigeres Projekt erfordert eine eigene Prüfung von Speicherbedarf und Ausführungsverhalten.
Die Serie bestätigte den erfolgreichen Abschluss von drei Aufwärmläufen und neun gemessenen Renderdurchläufen. Es war eine kurze Messung, kein über Nacht laufender Animationstest. Die oben genannten Anwendungsfälle sind Vorschläge für die Servernutzung, keine zusätzlich durchgeführten Tests.
Die folgenden Details enthalten Einstellungen und Ergebnisse; unser KI- und GPU-Glossar erklärt die Grundbegriffe. Serverangebot ansehen oder uns Ihr Rendering-Projekt beschreiben.
Technische Details
Ergebnisse für die drei Szenen
Diese Ergebnisse betreffen drei Cycles-Szenen, die auf einer GPU gerendert wurden.
| Szene | Auflösung | Median aus 3 Durchläufen | Schnellster–langsamster gemessener Durchlauf |
|---|---|---|---|
| monster | 1024 × 1024 | 5.5 s | 5.5–5.6 s |
| junkshop | 2000 × 1000 | 10.3 s | 10.3–10.4 s |
| classroom | 1920 × 1080 | 8.9 s | 8.8–8.9 s |
Die Spannweite gibt das tatsächliche Minimum und Maximum dreier Messläufe an, kein Konfidenzintervall und keine garantierte Leistung für einen künftigen Auftrag. Der Aufwärmlauf ist vom Median ausgeschlossen. Sein Ergebnis, die einzelnen Wiederholungen und genauere Werte stehen unten als CSV und JSON zum Download bereit.
Testkonfiguration
| Komponente | Zustand während des Tests |
|---|---|
| GPU | NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition, 96GB VRAM |
| Konfiguriertes Leistungslimit | 300W, ohne manuelles Übertakten |
| CPU | AMD EPYC 4565P, 16 Kerne / 32 Threads |
| System-RAM | 96GB |
| Betriebssystem | Rocky Linux 10.2 |
| NVIDIA-Treiber | 595.91.07 |
| Blender | 5.2.0 LTS, Build fbe6228777e7 |
| Renderberechnung | Cycles, OptiX, eine GPU; CPU als Rendergerät deaktiviert |
Die höchste beobachtete GPU-Speicherbelegung während der gesamten Serie betrug 8162MiB, also ungefähr 8GiB. Diese drei Szenen testeten somit nicht die volle VRAM-Kapazität der GPU von 96GB. Sie belegen auch nicht, dass jede größere Szene in den GPU-Speicher passt.
Was die angegebene Zeit umfasst
Wir haben die verstrichene Zeit rund um bpy.ops.render.render(write_still=False) gemessen. Das umfasst Rendering sowie Szenenvorbereitung und Synchronisierung einschließlich BVH-Arbeit. Die Deaktivierung der CPU als Rendergerät beseitigt nicht die für die Szenenvorbereitung erforderliche CPU-Arbeit.
Blender-Start, das erstmalige Laden der .blend-Datei, Speichern eines Bildes und Netzwerkübertragung liegen außerhalb dieser Messgrenze. Das Ergebnis ist daher nicht die vollständige Durchlaufzeit vom Hochladen eines Projekts bis zum Herunterladen einer Ausgabedatei. Diese zusätzlichen Phasen müssen für den jeweiligen Ablauf separat gemessen werden.
Jede Szene lief in einem separaten Blender-Prozess. Darin führten wir einen vollständigen Aufwärm-Renderdurchlauf und anschließend drei gemessene Durchläufe aus. Der Betriebssystemcache wurde nicht geleert und konnte Daten aus der Umgebungsvorbereitung enthalten. Auf der GPU lief keine andere Rechenaufgabe gleichzeitig; unabhängige Modelldownloads konnten jedoch CPU, Netzwerk und Laufwerke beanspruchen.
Szenen und reproduzierbare Einstellungen
Die Szenen stammen aus dem offiziellen Blender-Archiv: monster, junkshop und classroom. Wir prüften die SHA-256-Werte von Archiv und Anwendung anhand der Blender-Open-Data-Metadaten und der Prüfsummen der Blender-5.2.0-Veröffentlichung. Die exakten Hashwerte sind auch in unserem JSON enthalten.
Gemeinsame Einstellungen aller drei Szenen:
- Cycles, OptiX, nur die ausgewählte GPU; die CPU ist kein Rendergerät.
- 512 Samples, adaptives Sampling und Denoising deaktiviert.
- Zuerst Frame 1 auswählen, danach den festen Zufalls-Seed setzen auf
0. - Originalbreite und -höhe der Szene bei 100% Auflösungsskalierung.
- Persistente Daten, Compositing und Sequencer deaktiviert.
- Ursprüngliche Bounce-Einstellungen jeder Szene; die genauen Werte stehen im JSON.
Die ursprüngliche Classroom-Szene verwendet einen animierten Seed. Deshalb wählen wir den Frame vor dem Setzen des Seeds aus.
Auch der Startmodus ist relevant: --background --factory-startup --disable-autoexec, ohne in der Szene gespeicherte Skripte auszuführen. Wir prüften das erforderliche OptiX-Gerät und den erfolgreichen Abschluss jedes Renderaufrufs; das Verfahren wechselte nicht automatisch zum CPU-Rendering.
OptiX: ein wichtiges Umgebungsdetail
OptiX benötigt neben einem funktionierenden GPU-Treiber die passenden User-Space-Bibliotheken.
Wir verwendeten User-Space-Bibliotheken in exakt Version 595.91.07, passend zum laufenden Treiber, aus dem offiziellen NVIDIA-Paket. Die RPM-Signatur wurde mit einem bereits installierten NVIDIA-Signaturschlüssel geprüft. Wir stellten die Bibliotheken aus einem isolierten Verzeichnis nur Blender zur Verfügung; der globale Treiber und die Firmware wurden nicht ersetzt. Das JSON enthält Version, Quelle und SHA-256-Werte ohne administrative Pfade.
Dies beschreibt die getestete Umgebung. Es ist keine Behauptung, dass jede frische CUDA-Installation alle für OptiX-Rendering benötigten Komponenten enthält.
Grenzen der kurzen Render-Serie
Die endgültige Serie dauerte ungefähr 103 Sekunden und schloss alle drei Aufwärmläufe und neun gemessenen Renderdurchläufe ab. Wir beobachteten die GPU ungefähr einmal pro Sekunde. Sämtliche Renderaufrufe waren erfolgreich.
Dies beschreibt einen kurzen Lauf, keinen Nachweis mehrstündiger thermischer Stabilität. Zwischen den Abtastpunkten können zudem kurze Spitzen unbemerkt bleiben. Die Leistungstelemetrie im JSON beschreibt die GPU-Karte, nicht die Wechselstrom-Leistungsaufnahme des gesamten Servers.