Redshift Render Farm: guida al rendering GPU cloud per il 2026

Redshift è diventato uno degli engine su cui riceviamo il maggior numero di domande sulla nostra render farm. Si tratta di un renderer biased accelerato da GPU, progettato per la velocità in produzione, e gli artisti lo scelgono per tre ragioni ricorrenti: è costruito intorno alla scheda grafica, rimane prevedibile sotto scadenza e viene distribuito all'interno delle quattro applicazioni in cui la maggior parte dei nostri utenti già lavora — Cinema 4D, Maya, 3ds Max e Houdini.

Questa guida è un riferimento unico per eseguire Redshift su una render farm cloud, indipendentemente dall'applicazione in cui si costruisce la scena. Una render farm non cambia il modo in cui si illumina o si shadea un frame; cambia ciò che accade quando si avvia il rendering. Invece di una workstation impegnata a elaborare una sequenza durante la notte, molte macchine GPU si ripartiscono i frame in parallelo e li restituiscono in una frazione del tempo reale. I compromessi rilevanti — VRAM, licenze, trasferimento file e costi — sono gli stessi che la scena Redshift sia partita da Cinema 4D o da Houdini: è esattamente per questo che conviene trattare "Redshift su una render farm" come un unico argomento invece di quattro separati.

Flusso di rendering cloud Redshift — Cinema 4D, Maya, 3ds Max e Houdini alimentano un unico engine Redshift, poi le scene vengono caricate su un parco GPU che renderizza i frame in parallelo per il download

Perché Redshift esegue il rendering sulla GPU — e cosa significa su una render farm

Redshift è prima di tutto un renderer GPU. Utilizza i percorsi CUDA e OptiX della scheda grafica per tracciare i raggi, ed è questo a conferirgli la reattività interattiva che gli artisti gli riconoscono. Sulla nostra render farm, ogni job Redshift viene eseguito su un parco GPU dedicato basato su schede NVIDIA RTX 5090 con 32 GB di VRAM ciascuna. Eseguiamo Redshift in modalità GPU — è il percorso per cui il nostro hardware è configurato, ed è importante essere precisi su questo punto, perché il prodotto Redshift ha introdotto una modalità di rendering CPU nella versione 3.5. Sulla nostra render farm, Redshift è GPU-only; non esiste un percorso di rendering CPU. Se si è ottimizzata una scena per il backend CPU, è necessario validarla rispetto all'output GPU prima di eseguire una sequenza completa.

Questa progettazione GPU-first rende Redshift particolarmente adatto al rendering distribuito. I frame sono unità di lavoro indipendenti, quindi una sequenza che richiederebbe otto ore a una singola scheda può essere distribuita su molte schede e restituita molto prima. Il compito di una render farm è mantenere quelle schede alimentate, gestire le licenze e consegnare i frame — senza che sia necessario preoccuparsi delle macchine sottostanti.

Una render farm elimina anche il principale collo di bottiglia GPU per gli artisti che lavorano in solitaria: il numero di schede disponibili. In locale si esegue il rendering con una o due GPU nella propria workstation. Su una render farm, il vincolo si sposta da "quante schede possiedo" a "come confeziono la scena affinché le schede possano leggerla" — un problema molto più semplice da risolvere, che viene trattato nella sezione dedicata al workflow di seguito.

Redshift con quattro applicazioni: Cinema 4D, Maya, 3ds Max e Houdini

Redshift si comporta in modo coerente nelle diverse applicazioni host perché l'engine è lo stesso; ciò che cambia è il bridge plugin e il modo in cui ogni applicazione esporta i dati della scena. Supportiamo Redshift nei quattro DCC in cui i nostri utenti lo utilizzano di più:

• Cinema 4D. Redshift è strettamente integrato qui — è un prodotto Maxon, e Cinema 4D è un'applicazione Maxon, quindi il sistema dei materiali, la finestra di rendering e il sistema delle take sembrano nativi. Questa è la coppia Redshift più matura che vediamo, e quella con la più lunga storia di scene pronte per la render farm. Per un approfondimento specifico su Cinema 4D, si consulti la nostra guida alla render farm Redshift per Cinema 4D.
• Maya. Redshift per Maya è un'integrazione consolidata e testata in produzione, con pieno supporto per i rendering layer di Maya, gli AOV e il consueto workflow basato su nodi per i materiali. Le scene fanno riferimento a texture e cache tramite la struttura di progetto di Maya, quindi la principale considerazione per la render farm è assicurarsi che quei percorsi si risolvano correttamente una volta che i file lasciano la propria macchina.
• 3ds Max. L'integrazione con 3ds Max copre le impostazioni del renderer, il Material Editor e i render element attesi. Redshift è qui frequentemente usato insieme a plugin di scatter e proxy, quindi i proxy e i riferimenti esterni sono gli elementi da confezionare con cura.
• Houdini. Redshift in Houdini è l'opzione GPU che molti artisti abbinano a lavori di simulazione pesante e instancing, affiancandolo a Karma e Mantra. Se il proprio pipeline è incentrato su Houdini, la nostra pagina dedicata alla cloud render farm per Houdini offre una panoramica più ampia degli engine disponibili per quell'applicazione.

In tutte e quattro le applicazioni, la licenza del render engine è inclusa nel costo del rendering — non è necessario portare la propria licenza Redshift. In qualità di partner ufficiale Maxon, licenziamo Redshift (e il resto della linea Maxon) per l'uso di rendering sulla farm, il che consente all'engine di essere disponibile in ogni applicazione supportata senza alcuna configurazione da parte dell'utente. È possibile verificare direttamente lo status di partner nella directory partner di Maxon.

Cinema 4D, Maya, 3ds Max e Houdini che alimentano un unico engine Redshift su una render farm GPU, con la licenza Redshift inclusa nella tariffa di rendering

VRAM, out-of-core e scene di grandi dimensioni

Per il rendering GPU, la VRAM è il fattore che determina se una scena viene elaborata correttamente o si blocca. Redshift carica geometria, texture e altri dati della scena nella memoria della scheda; quando una scena rientra nella VRAM, la scheda opera a piena velocità. Il nostro parco GPU mette a disposizione di ogni job Redshift 32 GB di VRAM, sufficienti per un'ampia gamma di scene di produzione senza necessità di gestione speciale.

Quando i dati di una scena superano la VRAM disponibile, Redshift non si interrompe semplicemente — attiva la sua tecnologia out-of-core, paginando texture e geometria dalla memoria di sistema man mano che la scheda ne ha bisogno. Questa è la risposta onesta alla domanda "e la mia scena pesante?": Redshift può eseguire il rendering di scene più grandi della VRAM tramite out-of-core, con un certo onere sulle prestazioni, perché la scheda deve accedere a una memoria più lenta. Si tratta di una tecnica GPU, non di un trasferimento a un renderer CPU. In pratica, il modo per mantenere rapida una scena Redshift pesante è ridurre prima la pressione non necessaria sulla VRAM — dimensioni delle texture ragionevoli, proxy per la geometria ripetuta, e sfrondamento di ciò che è effettivamente nel frame — e lasciare che out-of-core assorba il resto.

Se si vuole valutare se i 32 GB della RTX 5090 siano sufficienti per il proprio lavoro specifico, il nostro approfondimento sulle prestazioni di rendering GPU cloud con RTX 5090 illustra il comportamento della scheda su scene reali.

Grafico dell'utilizzo della VRAM che cresce con la complessità della scena, superando la soglia dei 32 GB della RTX 5090 dove si attiva l'out-of-core di Redshift e il rendering prosegue sulla GPU con un certo onere sulle prestazioni

Render farm completamente gestita o noleggio diretto di una macchina GPU

Esistono due modi principali per eseguire il rendering di Redshift nel cloud, e la differenza è più rilevante della specifica hardware.

Il primo è il noleggio di infrastruttura: si affitta una macchina GPU remota, ci si connette tramite desktop remoto, si installano Redshift e l'applicazione host, si gestiscono le licenze, si copiano i file e si gestisce il rendering. Si riceve una macchina base e il pieno controllo, insieme a tutta la configurazione e la manutenzione che questo implica.

Il secondo è una render farm completamente gestita, che è il modo in cui operiamo. Si carica la scena, l'engine e le licenze sono già in uso, i frame vengono distribuiti sul parco GPU automaticamente e si raccoglie l'output. Non c'è alcun desktop remoto a cui accedere, niente da installare e nessuna licenza da attivare. Per un artista Redshift questo elimina le parti del rendering cloud che non hanno nulla a che fare con la creazione di immagini — ed è la principale differenza tra una render farm gestita e i noleggi GPU come servizio infrastrutturale (IaaS) che si possono avere già utilizzato. La nostra pagina dedicata alla Redshift cloud render farm è il punto di riferimento per chi vuole la versione sintetica.

Il modello più adatto dipende dal grado di controllo necessario sull'ambiente. Se si dispone di un plugin chain inusuale o di una build personalizzata, una macchina libera può essere lo strumento giusto. Per la maggior parte del lavoro Redshift — un'applicazione host standard, l'engine e la propria scena — una render farm gestita restituisce i frame con un onere operativo molto inferiore.

Quanto costa il rendering Redshift su una render farm

Il rendering GPU sulla nostra render farm è fatturato in base all'utilizzo, non con un piano mensile. L'unità è l'OctaneBench-ora (OBh) — una misura del lavoro GPU svolto — addebitata a una tariffa base di $0,003 per OBh. In termini pratici, una scheda RTX 5090 corrisponde a circa $5,20 per ora-scheda di rendering. Si paga per il tempo GPU che i frame effettivamente consumano, non per una licenza o un livello di abbonamento.

Alcuni dettagli che emergono spesso:

• La licenza è inclusa. La licenza Redshift è parte della tariffa di rendering. Lo stesso vale per gli altri engine che eseguiamo — non c'è una voce separata per la licenza da considerare nel budget.
• I crediti non scadono. Si ricarica un saldo crediti e lo si spende nei job; i crediti acquistati rimangono validi per quando si ha bisogno di usarli. I nuovi account iniziano anche con $25 di credito di prova per dimensionare un job reale prima di impegnarsi per una sequenza.
• Nessun livello. Ogni account esegue il rendering alla stessa tariffa basata sull'utilizzo. Non c'è alcun piano tra cui scegliere e nessuna funzionalità riservata a un livello superiore.

Per stimare un job, si prende il tempo che un frame richiede su una scheda comparabile, lo si moltiplica per il numero di frame e si applica la cifra per ora-scheda — distribuito su tutta la farm, il tempo reale si riduce drasticamente, ma le ore GPU fatturate rimangono approssimativamente le stesse del lavoro totale svolto. Il rendering di una ripresa di 10 secondi a 24 fps equivale a 240 frame; se ogni frame richiede quattro minuti a una scheda, si tratta di circa 16 ore-scheda di lavoro, ovvero nell'ordine di $83 alla tariffa pratica — restituiti in una piccola frazione di quel tempo reale perché i frame vengono elaborati in parallelo.

Esempio di calcolo dei costi per una ripresa di 240 frame: le ore-scheda fatturate sono le stesse su una singola scheda GPU e su una render farm da 24 schede, ma il tempo reale della farm è molto più breve

Scegliere Redshift, o un altro engine, per il lavoro

Redshift è una scelta forte quando si desidera la velocità GPU con la controllabilità di un renderer biased, e quando l'applicazione host è una delle quattro descritte sopra. Non è l'unica opzione, e parte di una scelta consapevole consiste nel sapere dove si colloca rispetto alle alternative.

• Rispetto ad Arnold, il compromesso è tra la velocità GPU biased e l'interattività di Redshift versus la reputazione di Arnold per un output unbiased e fisicamente fondato su CPU e GPU. Confrontiamo i due per il lavoro su render farm in Arnold vs. Redshift su una render farm.
• Rispetto a Octane, entrambi sono renderer GPU con filosofie di shading differenti e supporto alle applicazioni host diverso. Il nostro confronto tra Octane e Redshift illustra le differenze in pratica.

Una render farm non vincola a un solo engine — lo stesso modello di caricamento e rendering si applica agli altri engine che gestiamo — quindi la scelta dell'engine può restare una decisione creativa e di pipeline, non di hosting.

Il workflow di caricamento, rendering e download

Portare una scena Redshift sulla render farm segue gli stessi tre passaggi indipendentemente dall'applicazione host.

Caricamento. Si confeziona la scena con i relativi asset — texture, proxy, cache e riferimenti. Il caricamento via web non ha un limite rigido di dimensioni, anche se si consiglia di mantenere i singoli caricamenti sotto circa 300 GB; per dimensioni maggiori, SFTP o la nostra applicazione client offre un trasferimento riprendibile e parallelo. I formati archivio supportati sono tar, tar.gz e 7z; .zip non è supportato, quindi si riconfeziona o si trasferiscono i file non archiviati se questa è l'unica opzione disponibile. La causa più comune di un job GPU bloccato è un percorso di asset che si risolveva sulla propria workstation ma non una volta spostati i file, quindi è necessario raccogliere o ricollegare i riferimenti esterni prima del caricamento.

Rendering. Si invia il job e i frame vengono distribuiti sul parco GPU. Poiché i job Redshift sono qui esclusivamente su GPU, ogni frame viene assegnato a una RTX 5090 con i suoi 32 GB di VRAM, e out-of-core copre le scene che ne richiedono di più.

Download. I frame completati sono disponibili per il download via web, tramite SFTP o automaticamente attraverso l'applicazione client. L'output viene conservato per 45 giorni dopo il completamento di un job, dopodiché viene eliminato — è quindi necessario scaricarli tempestivamente o configurare il download automatico verso lo storage locale tramite l'applicazione client.

Una breve checklist prima di inviare un job Redshift

Completare questa lista richiede pochi minuti ed elimina quasi tutte le ragioni evitabili per cui un job restituisce risultati errati.

FAQ

Q: La render farm esegue il rendering di Redshift su GPU o su CPU? A: Solo su GPU. I nostri job Redshift vengono eseguiti su un parco NVIDIA RTX 5090 dedicato con 32 GB di VRAM per scheda. Redshift ha aggiunto una modalità CPU nella versione 3.5, ma sulla nostra render farm non esiste un percorso di rendering CPU per Redshift — se si è ottimizzata una scena per il backend CPU, è necessario validarla rispetto all'output GPU prima di procedere.

Q: Da quali applicazioni è possibile eseguire il rendering con Redshift? A: Cinema 4D, Maya, 3ds Max e Houdini. L'engine è lo stesso in tutte e quattro; cambia solo il bridge plugin dell'applicazione host e l'esportazione della scena. La licenza Redshift è inclusa nella tariffa di rendering in ogni caso.

Q: Cosa succede se la scena supera i 32 GB di VRAM? A: Redshift utilizza la tecnologia out-of-core per paginare texture e geometria dalla memoria di sistema quando una scena supera la VRAM disponibile. La scena continua a essere elaborata sulla GPU, con un certo onere sulle prestazioni. Ridurre le dimensioni delle texture e utilizzare i proxy mantiene più dati della scena nella VRAM e velocizza il processo.

Q: È necessaria una propria licenza Redshift? A: No. La licenza Redshift è inclusa nel costo del rendering. In qualità di partner ufficiale Maxon, licenziamo Redshift per l'uso di rendering sulla render farm, quindi è disponibile in ogni applicazione supportata senza nulla da attivare.

Q: Come viene calcolato il prezzo del rendering Redshift? A: Il rendering GPU è fatturato in base all'utilizzo a una tariffa base di $0,003 per OctaneBench-ora, che corrisponde a circa $5,20 per ora-scheda RTX 5090. Le licenze sono incluse, i crediti non scadono e i nuovi account iniziano con $25 di credito di prova per dimensionare un job reale.

Q: Come si portano scena e asset sulla render farm? A: Si carica la scena confezionata via web (nessun limite rigido di dimensioni; si consiglia di non superare circa 300 GB per caricamento), oppure si utilizza SFTP o l'applicazione client per trasferimenti più grandi o riprendibili. Usare archivi tar, tar.gz o 7z — .zip non è supportato — e raccogliere o ricollegare gli asset esterni prima del caricamento affinché i percorsi si risolvano sulla farm.

Q: Per quanto tempo vengono conservati i frame renderizzati? A: L'output viene conservato per 45 giorni dopo il completamento di un job, dopodiché viene eliminato automaticamente. Scaricare i frame via web, SFTP o tramite il download automatico dell'applicazione client entro tale termine, oppure configurare il download automatico per mantenere una copia locale.