Cos'è una GPU render farm? Come funziona e quando usarla

Introduzione

Una GPU render farm è un insieme di computer costruiti attorno a schede grafiche dedicate al rendering, collegati tra loro da un job scheduler e da uno storage condiviso, così che molti frame vengano renderizzati in parallelo. In Super Renders Farm ne gestiamo una accanto a una flotta CPU molto più grande, e le domande che gli artisti ci pongono sono sempre le stesse: com'è diversa dalla CPU farm, com'è diversa dalle due schede aggiuntive nella propria workstation, e quanto costa concretamente un'ora-scheda?

Questa guida risponde a queste domande dal lato operativo. Spiega cosa sia realmente una GPU render farm, come i componenti si integrano — nodi, scheduler, asset sync, consegna degli output — dove una GPU farm vale davvero il suo costo rispetto a una CPU farm o a un rig locale multi-GPU e dove invece non lo vale, quali motori di rendering appartengono a questo tipo di infrastruttura, e come funziona la matematica di fatturazione prima di affidarle una scadenza. È scritta per artisti e studi che vogliono capire il meccanismo prima di valutare un qualsiasi servizio, incluso il nostro.

Cos'è realmente una GPU render farm

Togliendo il linguaggio di prodotto, una GPU render farm è composta da tre sistemi che lavorano insieme:

• Nodi di rendering. Macchine la cui potenza di rendering proviene da una o più GPU dedicate al rendering piuttosto che da core CPU. La capacità di calcolo della scheda e la sua memoria VRAM definiscono il carico che ciascun nodo può sostenere.
• Uno scheduler di job. Software che accetta i job inviati, li suddivide in task per frame, assegna i task ai nodi liberi e compatibili, riprova in caso di errori e riporta i progressi. Ogni farm ne ha uno; lo si nota quasi esclusivamente quando funziona male.
• Storage condiviso e asset sync. Uno strato comune che contiene la scena, ogni texture e cache a cui fa riferimento, e l'output renderizzato — così che qualsiasi nodo possa occuparsi di qualsiasi frame senza che la workstation locale sia coinvolta.

Ciò che rende la farm una farm GPU non è una preferenza hardware. Sono i motori di rendering che serve: Redshift, Octane, V-Ray GPU e Cycles di Blender su GPU eseguono tutti il loro path tracing sulla scheda grafica, quindi la farm che li supporta deve essere costruita attorno alle schede piuttosto che ai core.

Lo stesso hardware è disponibile in due modelli di servizio molto diversi. Una GPU render farm gestita (managed) segue un flusso di upload-rendering-download: si confeziona una scena, la pipeline della farm la sincronizza, la renderizza con licenze engine in pool e restituisce i frame — senza sessioni di desktop remoto né installazioni software dal lato dell'utente. La GPU IaaS, al contrario, affitta macchine virtuali GPU grezze: ci si connette in remoto, si installano il DCC e il motore, si portano le licenze e si gestiscono le macchine in autonomia. Entrambi sono GPU render farm nel senso hardware; operativamente sono prodotti diversi con modalità di errore diverse.

Questo articolo si concentra sui concetti. Per specifiche di servizio — specifiche dei nodi, copertura dei motori, tariffe attuali — la pagina dedicata alla GPU cloud render farm contiene quelle informazioni.

Come funziona una GPU render farm: nodi, scheduler e asset sync

Architettura GPU render farm — una workstation artistica che carica una scena confezionata tramite asset sync nello storage condiviso, uno scheduler che distribuisce i frame su una flotta di nodi GPU, e i frame completati che fluiscono verso lo storage di output per il download.

Un job di rendering percorre quattro fasi, e la maggior parte dei problemi si verificano ai confini tra l'una e l'altra.

Confezionamento e upload. Il file di scena è la parte minore. Una scena di produzione fa riferimento a texture, cache di simulazione, proxy e dati di plugin distribuiti su drive di progetto, e ogni dipendenza deve viaggiare con essa. Il problema più comune al primo job è un asset referenziato da un percorso locale che esiste sulla macchina dell'artista e in nessun altro posto — il frame viene renderizzato, ma una texture non si risolve. Un buon tooling della farm raccoglie le dipendenze al momento dell'invio e valida i percorsi prima che qualsiasi nodo spenda tempo sul job. In Super Renders Farm, l'asset sync è anche incrementale: alla seconda sottomissione viaggiano solo i file modificati, il che fa la differenza tra un re-upload di 40 minuti e uno di 40 secondi quando si itera su una scadenza.

Coda e dispatch. Lo scheduler suddivide un'animazione in task per frame (o per chunk di frame) e li assegna in base alla disponibilità dei nodi, alla compatibilità VRAM e alla versione del motore. Riaccoda i frame da un nodo che va in crash, isola un nodo che continua a fallire e tiene occupato il resto della flotta. È la parte della farm che si affitta senza mai vedere — ed è la ragione principale per cui una farm si comporta diversamente da un insieme di VM in affitto.

Esecuzione sul nodo. Ogni nodo carica le versioni esatte del motore e dei plugin a cui il job è stato agganciato, controlla una licenza di rendering dall'inventario in pool della farm, carica i dati della scena nella memoria GPU, renderizza i frame assegnati e scrive gli output e i log nello storage condiviso. I watchdog intercettano i frame che si bloccano invece di fallire, il che è importante sui motori GPU dove un overflow di memoria può bloccare un processo invece di terminarlo.

Output e consegna. I frame completati arrivano nello storage di output e vengono restituiti tramite interfaccia web, SFTP o client desktop. Gli output non rimangono lì per sempre — sulla nostra farm la finestra di retention è di 45 giorni dal completamento del job — quindi la consegna è parte della pipeline, non un ripensamento.

GPU render farm vs CPU render farm

I due tipi di farm si distinguono prima per compatibilità con i motori e poi per hardware.

È il motore a decidere, non la farm. Se il progetto viene renderizzato in Redshift o Octane, è un job GPU; se viene renderizzato in Corona o in modalità CPU di V-Ray, è un job CPU. Si sceglie il motore per ragioni creative e di pipeline, e il motore sceglie il tipo di farm. Per un approfondimento a livello di motore su questa scelta, esiste una guida separata sul rendering GPU vs rendering CPU — questo articolo riguarda invece l'aspetto della farm attorno al motore.

I modelli di memoria differiscono per natura. Un nodo GPU opera all'interno della VRAM della propria scheda — 32 GB sulle schede RTX 5090 della nostra flotta GPU. Un nodo CPU opera all'interno della RAM di sistema, e i nostri nodi CPU dual-Xeon arrivano a 96–256 GB. Le funzionalità out-of-core dei moderni motori GPU possono trasferire parte dei dati di texture e geometria nella memoria di sistema a un costo in termini di prestazioni, ma la VRAM rimane il tetto pratico per la complessità della scena nel lavoro GPU. Le scene archviz molto pesanti con vegetazione scatter massiva, o le scene VFX con volumetrici profondi, spesso restano sulle CPU farm proprio per questa ragione.

Le affermazioni sulla velocità richiedono contesto. Su scene che si adattano comodamente alla VRAM, un motore GPU solitamente consegna un frame in meno tempo reale per nodo rispetto a quanto impiega un motore CPU a renderizzare un frame paragonabile. Questa è un'affermazione per singolo nodo, non un verdetto sulle farm: una flotta CPU con 20.000+ core offre throughput attraverso pura ampiezza parallela, e l'economia per frame dipende dalla tariffa per unità di lavoro, non da quale silicio sia di moda. Entrambi i modelli sono tariffati in base al lavoro che svolgono.

Il mix di job è più orientato alla CPU di quanto il clima di mercato suggerisca. Circa il 70% dei job sulla nostra farm viene ancora renderizzato su motori CPU — V-Ray CPU, Corona, Arnold — con il lavoro GPU su Redshift, Octane e V-Ray GPU che costituisce la parte crescente restante. Una GPU render farm non è il successore di una CPU farm; è la sorella che serve una diversa famiglia di motori.

GPU render farm vs rig locale multi-GPU

Il confronto più interessante per molti artisti non è con le CPU farm ma con il rig sotto la scrivania. La versione onesta ha vantaggi da entrambe le parti.

Dove le schede locali vincono. Il lookdev interattivo. Quando si calibrano materiali e illuminazione, la latenza del ciclo di risposta conta più del throughput, e una scheda nella propria macchina restituisce il feedback in pochi secondi. Nessuna farm cambia questo, e un operatore di farm che afferma il contrario sta cercando di vendere qualcosa. Le schede locali vincono anche quando l'utilizzo è genuinamente costante — hardware che renderizza frame di produzione per la maggior parte delle ore di quasi tutti i giorni ammortizza il proprio costo in capitale in un modo che l'hardware a utilizzo saltuario non riesce a fare.

Dove la farm vince. Ampiezza su richiesta. Una workstation contiene due, forse quattro schede; una farm mette a disposizione una dozzina di schede in parallelo per un singolo fine settimana senza che si debbano possedere per i tre anni nel mezzo. Il rendering di animazioni in frame finale è parallelizzabile in modo banale — 300 frame distribuiti su molte schede senza stato condiviso — che è esattamente la forma per cui una farm è costruita. C'è anche la contesa: i frame in rendering sulla propria workstation bloccano le stesse schede necessarie per il lookdev del prossimo shot, quindi le settimane di scadenza si trasformano in rendering notturno e lavoro nei momenti di pausa. E c'è la fisica poco glamour di alimentazione, calore e rumore che i box multi-GPU impongono a una piccola sala studio.

Il pattern che vediamo operativamente. Gli studi tendono ad arrivare a un approccio ibrido: schede locali per l'iterazione, farm per i frame finali e per le due settimane all'anno in cui tutto è in scadenza contemporaneamente. Un piccolo team di motion design si è unito a noi dopo una settimana di consegna in cui due schede locali hanno girato ininterrottamente e l'animazione ha comunque mancato la scadenza; lo stesso job distribuito su nodi della farm è stato completato durante la notte. La lezione non è che il loro hardware fosse inadeguato — è che la capacità di picco è una commodity diversa dalla capacità posseduta. Sul nostro sito è disponibile un'analisi dei costi per un artista indipendente di una workstation singola RTX 5090 vs cloud rendering che illustra la matematica sul lato del possesso.

GPU Farm, CPU Farm, GPU IaaS o rig locale: confronto diretto

Le quattro opzioni rispondono a problemi diversi. La tabella seguente è il confronto che facciamo ai nuovi clienti, con i compromessi lasciati intatti — comprese le righe in cui una farm gestita non è la risposta giusta. Per come la categoria cloud farm si inserisce nel panorama del rendering, si veda cos'è una cloud render farm.

Quali motori di rendering si adattano a una GPU render farm

Una GPU farm deve il suo nome ai motori che esegue, quindi l'identità del motore è la lente giusta per l'intera categoria.

Tre note operative si collegano a questa tabella. Prima, il matching della versione è imprescindibile: un nodo della farm deve eseguire le versioni esatte di motore e plugin contro cui la scena è stata creata, per questo il tooling di invio della farm aggancia le versioni per job invece di sperare che coincidano. Seconda, le licenze fanno parte della questione del motore — su una farm gestita, le licenze di rendering per Redshift, Octane, V-Ray, Corona e Arnold sono in pool e incluse nella tariffa, e partnership ufficiali con Maxon e Chaos garantiscono quella licenza dal nostro lato. Cycles non ha alcun costo di licenza, essendo open source sotto l'ombrello di Blender. Su GPU IaaS, ogni licenza è un problema da gestire autonomamente per macchina.

Terza, la VRAM è la specifica da verificare prima di qualsiasi numero sulle prestazioni. Una scheda che renderizza velocemente ma non riesce a contenere la scena non renderizza nulla. Pubblichiamo dati misurati sulle prestazioni di cloud rendering RTX 5090 su V-Ray GPU, Redshift e Octane proprio perché il comportamento per motore a dimensioni di scena reali dice più di qualsiasi numero di picco sintetico.

Quanto costa il rendering GPU su una farm

La fatturazione di una GPU farm ha un problema di normalizzazione da risolvere: un'ora-scheda non significa nulla su generazioni di hardware miste a meno che non sia ancorata a prestazioni misurate. L'ancora comune è OctaneBench, il benchmark pubblico GPU di OTOY — il punteggio di un nodo esprime quanto lavoro di rendering consegna effettivamente per ora, e la fatturazione si misura su quello.

Sulla nostra farm la tariffa GPU è di $0,003 per OctaneBench-ora, il che corrisponde a circa $5,20 per ora-scheda su un nodo RTX 5090. A titolo di confronto, il rendering CPU si misura a $0,004 per GHz-ora al livello di priorità base (i livelli di priorità vanno da $0,004 a $0,016), con un server dual-Xeon che arriva a circa $2 per server-ora. Unità diverse, stesso principio: si paga per il lavoro consegnato, non per il tempo in cui una macchina esiste semplicemente.

Ecco il metodo di stima che raccomandiamo, applicato a uno scenario concreto: un'animazione Redshift da 300 frame che si renderizza a circa 4 minuti per frame su una singola scheda di classe RTX 5090. Il calcolo totale è 300 × 4 = 1.200 minuti-scheda, ovvero 20 ore-scheda, indipendentemente da quante schede condividano il lavoro:

Questa tabella è la cosa più utile da capire riguardo all'economia della farm: a un determinato livello di tariffa, l'ampiezza parallela acquista tempo di consegna, non un conto più salato. Il job costa quello che costa il lavoro; le schede decidono solo se lo si ottiene stanotte o giovedì.

I numeri vanno trattati come metodo, non come preventivo. I tempi per frame variano lungo una sequenza, la stima assume parallelismo per frame (un'animazione, non un singolo fotogramma enorme), e il tempo reale del frame di test è l'input che conta. Renderizzare due o tre frame rappresentativi prima, poi moltiplicare — questa abitudine intercetta sia le sorprese di budget sia quelle da asset mancanti prima che costino qualcosa.

Come valutare una GPU render farm

I criteri seguenti sono quelli che distinguono le farm in pratica — sono le domande che porremmo a qualsiasi fornitore, incluso noi stessi:

• VRAM per scheda, per iscritto. Il modello della scheda e la sua memoria, più dati di prestazione misurati per il proprio motore — non una generica affermazione di velocità.
• Copertura esatta di versione di motore e plugin. Le proprie versioni, agganciate per job, non "versioni correnti supportate."
• Gestione delle licenze. Incluse nella tariffa, o a proprio carico? La risposta ridefinisce il costo orario reale.
• Forma del flusso di lavoro. Upload-rendering-download gestito, o VM con desktop remoto? Si sceglie quello che il proprio team riesce a gestire alle 23:00 la notte di una scadenza.
• Comportamento dell'asset sync al secondo invio. Sincronizzazione dei soli file modificati, o re-upload completo per ogni iterazione? Questo determina come si sente concretamente l'iterazione.
• Prevedibilità dei costi. Tariffe pubblicate in un'unità dichiarata, e un modo per stimare dai frame di test prima di impegnare la sequenza.
• Retention dell'output e gestione dei dati. Conoscere la finestra (la nostra è di 45 giorni) e pianificare la consegna all'interno del calendario.
• Supporto durante le finestre di rendering. I rendering falliscono alle 3 di notte; il supporto live 24/7 vale più di una coda di ticket risposta in orario d'ufficio.

Gestiamo l'infrastruttura di rendering in Super Renders Farm dal 2010, sia la flotta CPU sia la flotta GPU RTX 5090, e il pattern che si conferma è questo: le farm che servono bene gli artisti sono quelle che pubblicano la propria meccanica — tariffe, motori, VRAM, comportamento della sync — e permettono di verificare i calcoli autonomamente. Una GPU render farm non è magia. È uno scheduler, un insieme di schede molto capaci e uno strato di sincronizzazione, gestiti con cura in modo che la scadenza non dipenda dalle due schede sotto la scrivania.

FAQ

Q: Cos'è una GPU render farm? A: Una GPU render farm è un cluster di nodi di rendering costruiti attorno a schede grafiche dedicate al rendering, coordinati da un job scheduler e dallo storage condiviso in modo che molti frame vengano renderizzati in parallelo per motori GPU-native come Redshift, Octane, V-Ray GPU e Cycles. Super Renders Farm, ad esempio, abbina una flotta GPU RTX 5090 a un flusso di lavoro gestito di upload-rendering-download, in modo che i job girino senza sessioni di desktop remoto o configurazione manuale delle licenze.

Q: Qual è la differenza tra una GPU render farm e una CPU render farm? A: Il motore con cui viene renderizzato il progetto decide quale tipo di farm è necessario: Redshift, Octane, V-Ray GPU e Cycles GPU girano su GPU farm, mentre Corona, Arnold e V-Ray CPU girano su CPU farm. La differenza hardware ne consegue — i nodi GPU sono limitati dalla VRAM (32 GB per scheda sulla nostra flotta) mentre i nodi CPU dispongono di RAM di sistema molto più ampia, per questo le scene pesanti in memoria restano spesso sulle CPU farm.

Q: Una GPU render farm è più veloce di una workstation locale multi-GPU? A: Per scheda singola, no — un nodo della farm con la stessa scheda renderizza un frame in circa lo stesso tempo della propria workstation. La differenza è nell'ampiezza parallela e nella contesa: una farm può mettere dieci o più schede su un'animazione contemporaneamente mentre le schede locali rimangono libere per il lookdev, quindi la sequenza finisce durante la notte invece di impegnare la workstation per giorni.

Q: Posso renderizzare Blender EEVEE su una GPU render farm? A: Solitamente no — EEVEE è il motore di rasterizzazione in tempo reale di Blender e si comporta diversamente dai path tracer offline sui nodi farm headless, quindi il supporto per esso varia ed è spesso assente. Sulla nostra farm, il rendering Blender gira solo su Cycles; non eseguiamo EEVEE, e si raccomanda di confermare il supporto del motore con qualsiasi fornitore prima di pianificare un progetto attorno ad esso.

Q: Come viene fatturato l'utilizzo di una GPU render farm? A: La maggior parte delle GPU farm misura OctaneBench-ore normalizzate per benchmark in modo che un'unità di fatturazione equivalga a un'unità di lavoro di rendering misurato; OctaneBench è l'ancora pubblica comune. Sulla nostra farm la tariffa è di $0,003 per OctaneBench-ora — circa $5,20 per ora-scheda su un nodo RTX 5090 — e il totale per un job dipende dalle ore-scheda di lavoro, non da quante schede lo condividono.

Q: Devo avere le mie licenze per il motore di rendering per usare una GPU render farm? A: Su una GPU render farm gestita, no — le licenze di rendering per motori come Redshift, Octane e V-Ray sono in pool sulla farm e incluse nella tariffa, e Cycles è open source senza alcuna licenza. Su noleggi GPU IaaS si portano e gestiscono le proprie licenze per macchina, il che rappresenta una reale differenza di costo e amministrazione da calcolare nel preventivo.

Q: Quanta VRAM hanno i nodi di una GPU render farm? A: Varia in base alla farm e alla generazione di schede, quindi si raccomanda di verificare il modello specifico della scheda piuttosto che accettare una generica affermazione; i nostri nodi GPU montano schede RTX 5090 con 32 GB di VRAM ciascuna. La VRAM è il tetto pratico per la complessità della scena nel rendering GPU — le funzionalità out-of-core possono trasferire alcuni dati alla memoria di sistema a un costo in termini di prestazioni, ma una scena che supera genuinamente la VRAM appartiene a una CPU farm.

Q: Devo avere accesso al desktop remoto per usare una GPU render farm? A: Non su una farm gestita — il flusso di lavoro è upload, rendering, download: si confeziona una scena, la farm la sincronizza e la renderizza, e si recuperano i frame completati. Le sessioni di desktop remoto sono il modello operativo dei noleggi GPU IaaS, dove si amministrano le macchine in autonomia, e questa distinzione è la linea pratica più chiara tra i due tipi di servizio.