Renderowanie zamienia scenę 3D w gotowy obraz. Na naszym serwerze trzy sceny Blendera renderowały się w medianie 5,5 s, 10,3 s i 8,9 s. Sprawdziliśmy je na jednej karcie RTX PRO 6000 Blackwell Max-Q, w Blenderze 5.2.0 LTS z silnikiem Cycles.
To wyniki scen monster, junkshop i classroom, w tej kolejności. Metodyka testów pomaga odróżnić czas samego etapu obliczeń od czasu całego zadania. Dokładne ustawienia i procedura tej krótkiej serii pozostają poniżej; nie przypisujemy jej zasad późniejszych kampanii.
Do jakich prac przydaje się taki serwer?
Zdalne renderowanie może odciążyć komputer grafika podczas przygotowywania wizualizacji produktu, wnętrza lub klatek animacji. Projekt przygotowujesz w swoim środowisku, przesyłasz potrzebne pliki na serwer i uruchamiasz obliczenia. Po zakończeniu odbierasz wynik, a lokalny komputer nie musi przez cały ten czas zajmować się renderowaniem.
Ma to sens przede wszystkim wtedy, gdy taki podział pasuje do organizacji pracy: projekt można przenieść razem z jego zależnościami, a odbiór wyników nie wymaga ciągłego ręcznego nadzoru. Sam dostęp do GPU nie tworzy jednak gotowego systemu kolejkowania zadań. Sposób uruchamiania, porządkowania plików i kontroli rezultatów jest częścią przygotowania własnego środowiska.
Co oznaczają podane sekundy?
Mierzyliśmy samo wywołanie renderowania wraz z przygotowaniem sceny potrzebnym w tym etapie. Nie wliczaliśmy uruchomienia programu, wczytania projektu ani przesyłania i zapisu plików. Każdy wynik to środkowy czas z trzech prób po rozgrzewce, czyli mediana.
W praktyce warto prowadzić dwa pomiary. Pierwszy odpowiada na pytanie, jak szybko działa wybrany etap renderowania. Drugi liczy czas od przygotowania zadania do odebrania gotowego pliku. Przy przenoszeniu dużego projektu albo częstym ponownym uruchamianiu programu różnica między nimi może mieć znaczenie dla organizacji pracy.
Nasze wyniki opisują pierwszy z tych zakresów. Nie są punktacją Blender Open Data, mimo że użyliśmy scen z oficjalnego archiwum. Nie należy ich więc zestawiać bezpośrednio z punktami innego benchmarku ani traktować jako czasu całej usługi renderującej.
Jak sprawdzić własny projekt?
Najlepszy punkt odniesienia to próbka rzeczywistej pracy, wykonana z tą samą wersją programu, rozdzielczością i ustawieniami jakości. Sprawdź, czy projekt ma wszystkie potrzebne pliki, a później porównaj gotowe obrazy, nie tylko komunikat o ukończeniu zadania. W przypadku animacji wybierz również bardziej wymagający fragment zamiast zakładać, że każda klatka będzie zachowywać się tak samo.
Zmiana jakości to zmiana zadania. Niższy czas przy innych ustawieniach nie pokazuje wyłącznie różnicy sprzętu. Nasze sceny również różnią się złożonością i rozdzielczością: monster, junkshop i classroom są trzema punktami odniesienia, a nie trzema identycznymi próbami.
Warto zapisać wersję Blendera i sterownika, wybrany sposób renderowania, rozdzielczość oraz ustawienia próbek. Dzięki temu późniejsze powtórzenie albo porównanie z inną maszyną będzie dotyczyło tego samego projektu, a nie przypadkowo zmienionej konfiguracji.
Pamięć i zakres tego sprawdzenia
Karta ma 96 GB pamięci GPU, ale te sceny nie sprawdzały jej pełnej pojemności: najwyższy zaobserwowany odczyt w całej serii wyniósł około 8 GiB. Duża pamięć nie oznacza automatycznie krótszego czasu każdej sceny. Przy bardziej rozbudowanym projekcie trzeba osobno sprawdzić jego wymagania i zachowanie podczas pracy.
Seria potwierdziła poprawne ukończenie trzech rozgrzewek i dziewięciu mierzonych renderów. Był to krótki pomiar, nie test całonocnego renderowania animacji. Wskazane zastosowania są propozycjami wykorzystania serwera, nie dodatkowymi wykonanymi testami.
Ustawienia i wyniki znajdziesz w szczegółach, a podstawowe pojęcia w słowniku AI i GPU. Sprawdź ofertę serwera lub opisz swój projekt renderujący.
Szczegóły techniczne
Wyniki trzech scen
Poniższe wyniki dotyczą trzech scen Cycles i jednej karty GPU.
| Scena | Rozdzielczość | Mediana z 3 prób | Najkrótsza–najdłuższa próba |
|---|---|---|---|
| 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 |
Zakres pokazuje rzeczywiste minimum i maksimum trzech mierzonych prób, nie przedział ufności ani gwarantowaną wydajność przyszłego zadania. Rozgrzewka nie wchodzi do mediany. Jej wynik, poszczególne powtórzenia oraz dokładniejsze wartości znajdują się w plikach CSV i JSON pod artykułem.
Konfiguracja testowa
| Element | Stan podczas pomiaru |
|---|---|
| GPU | NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition, 96 GB VRAM |
| Ustawiony limit mocy | 300 W, bez ręcznego podkręcania |
| Procesor | AMD EPYC 4565P, 16 rdzeni / 32 wątki |
| RAM systemowy | 96 GB |
| System | Rocky Linux 10.2 |
| Sterownik NVIDIA | 595.91.07 |
| Blender | 5.2.0 LTS, build fbe6228777e7 |
| Obliczenia renderujące | Cycles, OptiX, jedna karta GPU; urządzenie CPU wyłączone |
W czasie całej serii najwyższy odnotowany odczyt użycia pamięci GPU wyniósł 8162 MiB, czyli około 8 GiB. Te trzy sceny nie były więc testem wykorzystania pełnych 96 GB VRAM. Nie dowodzą też, że każda większa scena zmieści się w pamięci karty.
Co obejmuje podany czas
Mierzyliśmy czas ścienny wywołania bpy.ops.render.render(write_still=False). Obejmuje ono renderowanie oraz przygotowanie i synchronizację sceny, w tym struktury BVH. Wyłączenie CPU jako urządzenia renderującego nie usuwa pracy procesora potrzebnej do przygotowania sceny.
Poza tym czasem pozostają uruchomienie Blendera, początkowe wczytanie pliku .blend, zapis obrazu na dysk i transfer przez sieć. Nie jest to zatem całkowity czas od przesłania projektu na serwer do pobrania gotowego pliku. Dla takiego przepływu pracy trzeba dodatkowo zmierzyć odpowiednie etapy.
Każda scena działała w osobnym procesie Blendera. Wewnątrz procesu wykonywaliśmy jeden pełny render rozgrzewkowy, a następnie trzy mierzone rendery. Systemowa pamięć podręczna nie była czyszczona i mogła zawierać dane z przygotowania środowiska. GPU nie wykonywało równolegle innych obliczeń, choć niezależne pobieranie modeli mogło korzystać z procesora, sieci i dysku.
Sceny i ustawienia do odtworzenia
Sceny pochodzą z oficjalnego archiwum Blender: monster, junkshop i classroom. Archiwa i program sprawdziliśmy według SHA-256 z metadanych Blender Open Data oraz sum wydania Blender 5.2.0. Konkretne sumy plików są również w naszym JSON.
Ustawienia wspólne dla wszystkich scen:
- Cycles, OptiX, tylko wskazana karta GPU; CPU nie jest urządzeniem renderującym.
- 512 próbek, wyłączone adaptive sampling i denoising.
- Klatka 1, następnie ustawienie ziarna losowania
seed = 0. - Oryginalna szerokość i wysokość sceny, skala rozdzielczości 100%.
- Wyłączone persistent data, compositing i sequencer.
- Oryginalne ustawienia liczby odbić danej sceny; dokładne wartości zapisane w JSON.
Oryginalna scena classroom ma animowane ustawienie ziarna. Dlatego najpierw wybieramy klatkę, potem ustawiamy seed.
W odtwarzaniu testu ważny jest również sposób uruchomienia: tryb --background --factory-startup --disable-autoexec, bez wykonywania skryptów zapisanych w scenie. Sprawdzaliśmy dostępność właściwego urządzenia OptiX i poprawne zakończenie każdego renderowania; procedura nie przechodziła automatycznie na obliczenia CPU.
OptiX: istotny szczegół przygotowania środowiska
OptiX wymaga odpowiednich bibliotek użytkowych obok działającego sterownika GPU.
Użyliśmy bibliotek użytkowych dokładnie w wersji 595.91.07, zgodnej z działającym sterownikiem, z oficjalnego pakietu NVIDIA. Podpis RPM został zweryfikowany przy użyciu wcześniej zainstalowanego klucza NVIDIA. Biblioteki udostępniliśmy wyłącznie procesowi Blendera z osobnego katalogu; nie podmienialiśmy globalnego sterownika ani firmware. JSON zawiera wersję, źródło i sumy SHA-256, bez ścieżek administracyjnych.
To szczegół testowanego środowiska, nie deklaracja, że każda czysta instalacja CUDA zawiera komplet składników do renderowania OptiX.
Granice krótkiej serii renderowania
Końcowa seria trwała około 103 sekund i zakończyła wszystkie trzy rozgrzewki oraz dziewięć mierzonych renderów. Obserwowaliśmy GPU mniej więcej co sekundę. Wszystkie renderowania zakończyły się poprawnie.
To informacja o krótkim przebiegu, nie potwierdzenie wielogodzinnej stabilności termicznej. Próbkowanie może też pominąć krótsze szczyty między odczytami. Telemetria mocy w JSON dotyczy karty GPU, nie poboru całego serwera z gniazdka.