
Redshift Render Farm: Guida 2026 al Cloud Rendering GPU
Panoramica
Redshift è un motore di rendering biased accelerato via GPU — sulla nostra farm, e su ogni render farm che conosciamo, funziona esclusivamente su hardware GPU, senza alcun percorso di rendering CPU. Gli artisti lo scelgono in Cinema 4D, Maya, 3ds Max e Houdini per gli stessi tre motivi: è costruito attorno alla scheda grafica, resta prevedibile sotto scadenza, e viene distribuito all'interno delle applicazioni già usate dalla maggior parte delle pipeline di produzione. Redshift è anche un motore comune per shot di veicoli e prodotti; la nostra guida render farm per il rendering automotive copre questo carico di lavoro su una farm GPU.
Questa guida è un riferimento unico per eseguire il rendering di Redshift su una render farm cloud, indipendentemente da quale delle quattro applicazioni utilizzi per costruire le proprie scene. Una render farm non cambia il modo in cui si illumina o si shada un frame; cambia ciò che accade quando si avvia il rendering. Invece di una singola workstation che macina una sequenza durante la notte, molte macchine GPU prendono in carico i frame in parallelo e li restituiscono in una frazione del tempo reale. I compromessi che contano — VRAM, licenze, trasferimento file e costo — sono gli stessi indipendentemente dal fatto che la scena Redshift sia nata in Cinema 4D o in Houdini, ed è esattamente per questo che conviene trattare "Redshift su una farm" come un unico argomento anziché quattro argomenti separati.

Flusso di cloud rendering Redshift — Cinema 4D, Maya, 3ds Max e Houdini alimentano un unico motore Redshift, poi le scene vengono caricate su una flotta GPU che esegue il rendering dei frame in parallelo per il download
Perché Redshift esegue il rendering su GPU — e cosa significa su una farm
Redshift è prima di tutto un motore GPU. Utilizza i percorsi CUDA e OptiX della scheda grafica per tracciare i raggi, il che gli conferisce la sensazione interattiva che gli artisti associano a questo motore. Sulla nostra farm, ogni job Redshift viene eseguito su una flotta GPU dedicata basata su schede NVIDIA RTX 5090 con 32 GB di VRAM ciascuna. Eseguiamo Redshift in modalità GPU — è il percorso per cui il nostro hardware è predisposto, ed è importante essere precisi al riguardo, perché il prodotto Redshift ha anche acquisito una modalità di rendering CPU nella versione 3.5. Sulla nostra farm, Redshift è GPU-only; qui non esiste alcun percorso di rendering CPU per esso. Se ha ottimizzato una scena per il backend CPU, pianifichi di validarla rispetto all'output GPU prima di avviare una sequenza lunga.
Questo design GPU-first è ciò che rende Redshift adatto in modo naturale al rendering distribuito. I frame sono unità di lavoro indipendenti, quindi una sequenza che richiede otto ore su una scheda può essere distribuita su molte schede e restituita molto prima. Il compito di una farm è mantenere quelle schede alimentate, risolvere le licenze e consegnare i frame — nulla di tutto ciò dovrebbe richiedere di pensare alle macchine sottostanti.
Una render farm elimina anche il collo di bottiglia GPU più comune per gli artisti singoli: il numero di schede. In locale, si esegue il rendering con una o due GPU nel proprio case. Su una farm, il vincolo si sposta da "quante schede possiedo" a "come impacchetto la scena affinché le schede possano leggerla" — un problema molto più facile da risolvere, e che trattiamo nella sezione sul workflow più avanti. Se è curioso di sapere quanto renda davvero una seconda (o ventesima) scheda in pratica, il nostro benchmark di scaling multi-GPU misura direttamente i tempi di rendering a 1 GPU rispetto a 2 GPU, anziché presupporre uno scaling lineare.
Redshift su quattro applicazioni: Cinema 4D, Maya, 3ds Max e Houdini
Redshift si comporta in modo coerente tra le applicazioni host perché il motore è lo stesso; ciò che cambia è il plugin ponte e il modo in cui ogni applicazione esporta i dati della scena. Supportiamo Redshift nei quattro DCC in cui i nostri clienti lo utilizzano maggiormente:
- Cinema 4D. Redshift è integrato in modo stretto qui — è un prodotto Maxon, e Cinema 4D è un'applicazione Maxon, quindi il sistema dei materiali, la render view e il sistema dei take risultano nativi. Questo è l'abbinamento Redshift più maturo che vediamo, ed è quello con la storia più lunga di scene pronte per la farm. Per un approfondimento specifico su Cinema 4D — comprese le specificità del workflow motion-design che vanno oltre quanto copre questa guida cross-DCC — veda la nostra guida Redshift render farm per Cinema 4D.
- Maya. Redshift per Maya è un'integrazione consolidata e testata in produzione, con pieno supporto per i render layer di Maya, gli AOV e il consueto workflow dei materiali basato su nodi. Le scene fanno riferimento a texture e cache attraverso la struttura di progetto di Maya, quindi la considerazione principale per la 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 che ci si aspetterebbe. Redshift qui viene spesso usato insieme a plugin di scatter e proxy, quindi i proxy e i riferimenti esterni sono gli elementi da impacchettare con attenzione.
- Houdini. Redshift in Houdini è l'opzione GPU che molti artisti abbinano a lavori pesanti di simulazione e instancing, affiancandosi a Karma e Mantra. Se la sua pipeline è Houdini-first, la nostra pagina Houdini cloud render farm copre il quadro più ampio del motore per quell'applicazione.
In tutte e quattro, la licenza del motore di rendering è inclusa in ciò che si paga per il rendering — non viene chiesto di portare una propria licenza Redshift. In qualità di partner Maxon ufficiale, concediamo in licenza Redshift (e il resto della linea Maxon) per uso di rendering sulla farm, il che è ciò che consente al motore di essere disponibile in ogni applicazione supportata senza alcuna configurazione da parte propria. È possibile verificare quello stato di partner direttamente nella directory partner di Maxon.

Cinema 4D, Maya, 3ds Max e Houdini che alimentano tutti un unico motore 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 numero che decide se una scena viene renderizzata senza problemi o si blocca. Redshift carica geometria, texture e altri dati della scena nella memoria della scheda; quando una scena rientra, la scheda lavora a pieno regime. La nostra flotta GPU offre a ogni job Redshift 32 GB di VRAM su una NVIDIA RTX 5090, il che copre un'ampia gamma di scene di produzione senza gestione speciale.
Quando i dati di una scena superano la VRAM disponibile, Redshift non si limita a fallire — passa alla propria tecnologia out-of-core, paginando texture e geometria dalla memoria di sistema man mano che la scheda ne ha bisogno. Questa è la risposta onesta a "cosa succede con la mia scena pesante": Redshift può eseguire il rendering di scene più grandi della VRAM tramite out-of-core, con un certo costo in termini di prestazioni, perché la scheda deve accedere a memoria più lenta. È una tecnica GPU, non un passaggio di consegne a un motore CPU — il frame viene comunque calcolato sulla RTX 5090, semplicemente con un accesso alla memoria più lento per la porzione che non rientra nei 32 GB della scheda. In pratica, il modo per mantenere veloce una scena Redshift pesante è ridurre prima la pressione inutile sulla VRAM — dimensioni ragionevoli delle texture, proxy per la geometria ripetuta, e la rimozione di ciò che non è effettivamente in inquadratura — e lasciare che l'out-of-core assorba il resto.
Se sta valutando se i 32 GB della RTX 5090 sono un margine sufficiente per il suo lavoro specifico, il nostro approfondimento sulle prestazioni di cloud rendering GPU della RTX 5090 illustra come si comporta la scheda su scene reali, e il nostro benchmark di scaling multi-GPU mostra cosa comporta realmente l'aggiunta di una seconda scheda per il tempo reale su una scena comparabile.

Grafico dell'utilizzo VRAM in aumento con la complessità della scena, che supera la linea dei 32 GB della RTX 5090 dove entra in gioco l'out-of-core di Redshift e continua il rendering sulla GPU con un certo costo in termini di prestazioni
Servizio completamente gestito vs. noleggiare una macchina GPU in autonomia
Esistono due modi generali per eseguire il rendering di Redshift nel cloud, e la differenza conta più della scheda tecnica dell'hardware.
Il primo è il noleggio di infrastruttura, in cui si noleggia una macchina GPU remota, ci si connette tramite desktop remoto, si installano Redshift e l'applicazione host in autonomia, si gestisce la licenza, si copiano i propri file e si gestisce il rendering. Si ottiene una macchina nuda e il pieno controllo, insieme a tutta la configurazione e la manutenzione che ciò comporta.
Il secondo è una farm completamente gestita, che è il modo in cui operiamo. Si carica la propria scena, il motore e le licenze sono già predisposti, i frame vengono distribuiti sulla flotta GPU — schede RTX 5090, 32 GB di VRAM ciascuna — e si raccoglie l'output. Non c'è alcun desktop remoto in cui accedere, nulla da installare, e nessuna licenza da attivare. Per un artista Redshift questo elimina le parti del cloud rendering che non hanno nulla a che fare con la creazione delle immagini — ed è la principale cosa che distingue una farm gestita dai noleggi GPU infrastructure-as-a-service che si potrebbero aver usato in precedenza. La nostra pagina Redshift cloud render farm è il posto da indicare a un collega che vuole la versione breve.
Il modello più adatto dipende da quanto controllo si necessita sull'ambiente. Se si ha una catena di plugin inusuale o una build su misura, una macchina grezza può essere lo strumento giusto. Per la maggior parte del lavoro con Redshift — un'applicazione host standard, il motore e la propria scena — una farm gestita restituisce i frame con molto meno overhead.
Quanto costa il rendering Redshift su una farm
Il rendering GPU sulla nostra farm viene fatturato in base all'utilizzo anziché 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 effettivamente consumato dai propri frame, non per una postazione o un livello di abbonamento.
La stessa fatturazione a ora-GPU si applica ai job Octane; la nostra guida Octane render cloud farm copre come vengono eseguite le scene Octane sulla flotta.
Alcuni dettagli specifici che tendono a emergere:
- La licenza è inclusa. La licenza Redshift fa parte della tariffa di rendering. Lo stesso vale per gli altri motori che eseguiamo — non c'è una voce di licenza separata da mettere a budget.
- I crediti non scadono. Si ricarica un saldo di crediti e lo si spende sui job; i crediti pagati restano validi per quando servono. I nuovi account partono anche con 25 $ di credito di prova per dimensionare un job reale prima di impegnarsi in una sequenza.
- Nessun livello. Ogni account esegue il rendering alla stessa tariffa basata sull'utilizzo. Non c'è alcun piano da scegliere e nessuna funzionalità bloccata dietro un livello superiore.
Per stimare un job, si prenda il tempo che un frame richiede su una scheda comparabile, lo si moltiplichi per il proprio numero di frame, e si applichi la cifra dell'ora-scheda — distribuito sulla flotta il tempo reale si comprime, ma le ore-GPU fatturate restano approssimativamente uguali al lavoro totale svolto. Il rendering di uno shot di 10 secondi a 24 fps corrisponde a 240 frame; se ogni frame richiede quattro minuti su una scheda, sono circa 16 ore-scheda di lavoro, ossia nell'ordine di 83 $ alla tariffa pratica — restituiti in una piccola frazione di quel tempo reale perché i frame vengono eseguiti in parallelo su più schede RTX 5090 anziché mettersi in coda su una sola.

Esempio di costo elaborato per uno shot 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 motore, per il lavoro
Redshift è una scelta forte quando si desidera la velocità della GPU con la controllabilità di un renderer biased, e quando la propria applicazione host è una delle quattro sopra indicate. Non è l'unica opzione, e parte dello scegliere bene consiste nel sapere dove si colloca rispetto alle alternative.
- Contro Arnold, il compromesso è la velocità e l'interattività GPU-biased di Redshift contro la reputazione di Arnold per un output unbiased, fisicamente fondato, su CPU e GPU. Confrontiamo i due per il lavoro su farm in Arnold vs. Redshift su una render farm.
- Contro Octane, entrambi sono motori GPU con filosofie di shading e supporto per applicazioni host differenti. Il nostro confronto Octane vs. Redshift analizza in dettaglio come differiscono in pratica.
- Contro Cycles, il motore integrato di Blender, il confronto riguarda meno il GPU-only contro il CPU-only e più l'ecosistema — Cycles funziona sia su CPU sia su GPU a seconda delle esigenze della scena, mentre Redshift sulla nostra farm è GPU-only su tutti e quattro i DCC supportati.
Una render farm non vincola a un unico motore — lo stesso modello di caricamento-e-rendering si applica agli altri motori che eseguiamo — quindi la scelta del motore può restare una decisione creativa e di pipeline anziché una decisione di hosting.
Il workflow di caricamento, rendering e download
Portare una scena Redshift sulla farm segue gli stessi tre passaggi indipendentemente dall'applicazione host.
Caricamento. Impacchetti la propria scena con i suoi asset — texture, proxy, cache e riferimenti. Il caricamento via web non ha un limite di dimensione rigido, sebbene suggeriamo di mantenere i singoli caricamenti sotto circa 300 GB; per qualsiasi cosa più grande, SFTP o la nostra applicazione client offrono un trasferimento parallelo e ripristinabile. I formati di archivio supportati sono tar, tar.gz e 7z; .zip non è supportato, quindi ricomprima o trasferisca i file non archiviati se è l'unica opzione disponibile. La causa più comune di un job GPU bloccato è un percorso asset che si risolveva sulla propria workstation ma non più una volta spostati i file, quindi raccolga o ricolleghi i riferimenti esterni prima di caricare.
Rendering. Invii il job e i frame vengono distribuiti sulla flotta GPU. Poiché qui i job Redshift sono GPU-only, ogni frame finisce su una RTX 5090 con i suoi 32 GB di VRAM, e l'out-of-core copre le scene che ne richiedono di più.
Download. I frame completati sono disponibili per il recupero via web, via SFTP, o automaticamente tramite l'applicazione client. L'output viene conservato per 45 giorni dopo il completamento di un job, dopodiché viene cancellato — quindi scarichi tempestivamente o lasci che l'applicazione client scarichi automaticamente sul proprio storage locale.
Una breve checklist prima di inviare un job Redshift
| Verifica | Perché conta |
|---|---|
| Asset esterni raccolti o ricollegati | I percorsi non risolti sono la causa principale dei job GPU bloccati |
| Dimensioni delle texture e proxy sensate | Mantiene la scena entro la VRAM e fuori dall'out-of-core dove possibile |
| Percorso di output e AOV impostati | Evita di dover ripetere il rendering per un passaggio mancante |
| L'archivio è tar, tar.gz o 7z | .zip non è supportato in fase di caricamento |
| Intervallo di frame e step corretti | Si paga per i frame necessari, non per quelli extra |
| Un frame di prova renderizzato per primo | 25 $ di credito di prova sono sufficienti per confermare le impostazioni prima della sequenza completa |
Lavorare su questa lista richiede pochi minuti ed elimina quasi ogni motivo evitabile per cui un job torna sbagliato.
FAQ
Q: Redshift è GPU-only su una render farm? A: Sulla nostra farm, sì — ogni job Redshift viene eseguito sulla GPU, nello specifico su schede NVIDIA RTX 5090 con 32 GB di VRAM ciascuna, senza alcun percorso di rendering CPU. Il prodotto Redshift ha aggiunto una modalità CPU a partire dalla versione 3.5, ma quella modalità non è ciò che viene eseguito qui; il nostro hardware e la nostra pipeline sono predisposti per il rendering Redshift GPU-only. Se ha ottimizzato una scena rispetto al backend CPU altrove, la validi rispetto all'output GPU prima di avviare una sequenza completa.
Q: Quanto costa una render farm Redshift? A: Sulla nostra farm, il rendering GPU viene fatturato in base all'utilizzo a 0,003 $ per OctaneBench-ora, il che corrisponde a circa 5,20 $ per ora-scheda RTX 5090. La licenza Redshift è inclusa in quella tariffa — non c'è alcuna tariffa di licenza separata — e i crediti non scadono mai. I nuovi account partono con 25 $ di credito di prova, sufficiente per dimensionare un job reale prima di impegnarsi in un rendering completo.
Q: La farm esegue il rendering di Redshift su GPU o su CPU? A: Solo GPU. I nostri job Redshift vengono eseguiti su una flotta dedicata di NVIDIA RTX 5090 con 32 GB di VRAM per scheda. Il prodotto Redshift ha aggiunto una modalità CPU nella versione 3.5, ma sulla nostra farm non esiste alcun percorso di rendering CPU per Redshift — se ha ottimizzato una scena per il backend CPU, la validi prima rispetto all'output GPU.
Q: Da quali applicazioni posso eseguire il rendering con Redshift? A: Cinema 4D, Maya, 3ds Max e Houdini. Il motore è lo stesso in tutte e quattro; cambiano solo il plugin ponte e l'esportazione della scena dell'applicazione host. La licenza Redshift è inclusa nella tariffa di rendering in ogni caso.
Q: Cosa succede se la mia 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 viene comunque renderizzata sulla GPU, con un certo costo in termini di prestazioni. Ridurre le dimensioni delle texture e usare i proxy mantiene più parte della scena residente in VRAM e veloce.
Q: Ho bisogno di una licenza Redshift personale? A: No. La licenza Redshift è inclusa in ciò che si paga per il rendering. In qualità di partner Maxon ufficiale, concediamo in licenza Redshift per uso di rendering sulla farm, quindi è disponibile in ogni applicazione supportata senza nulla da attivare da parte propria.
Q: Come viene definito il prezzo del rendering Redshift giorno per giorno, e ci sono livelli? A: Non ci sono livelli di piano — ogni account esegue il rendering alla stessa tariffa basata sull'utilizzo descritta sopra. La licenza è inclusa in quella tariffa per ogni motore che eseguiamo, non solo Redshift, quindi non c'è alcuna voce separata da mettere a budget indipendentemente da quale delle quattro applicazioni supportate si utilizzi per il rendering.
Q: Come carico la mia scena sulla farm, e per quanto tempo vengono conservati i frame dopo?
A: Carichi la scena impacchettata via web (nessun limite di dimensione rigido; suggeriamo meno di circa 300 GB per caricamento), oppure usi SFTP o l'applicazione client per trasferimenti più grandi o ripristinabili. Usi archivi tar, tar.gz o 7z — .zip non è supportato — e raccolga o ricolleghi gli asset esterni prima di caricare in modo che i percorsi si risolvano sulla farm. Una volta renderizzati i frame, l'output viene conservato per 45 giorni dopo il completamento del job, poi viene cancellato automaticamente — scarichi via web, SFTP, o tramite il download automatico dell'applicazione client prima di allora, oppure configuri il download automatico per mantenere una copia locale.
About Thierry Marc
3D Rendering Expert with over 10 years of experience in the industry. Specialized in Maya, Arnold, and high-end technical workflows for film and advertising.



