
Render farm CPU: perché il rendering CPU continua a dominare il cloud rendering nel 2026
Panoramica
Introduzione
Il rendering GPU fa notizia. Ogni lancio hardware, ogni confronto di benchmark, ogni aggiornamento di motore di rendering si apre con i numeri della GPU. Eppure, nella nostra render farm, circa il 70% di tutti i lavori di rendering è basato su CPU. V-Ray CPU, Corona Renderer, Arnold CPU — questi motori elaborano la maggior parte dei frame di produzione nella visualizzazione architettonica, nell'animazione broadcast e nel compositing VFX.
Questa proporzione non è un'eredità del passato. Riflette reali vantaggi tecnici che il rendering CPU offre rispetto alla GPU per carichi di lavoro specifici — vantaggi che non sono scomparsi nonostante la significativa maturazione dei motori GPU. Il rendering CPU offre accesso a grandi quantità di memoria di sistema (96-256 GB per nodo nella nostra flotta), compatibilità profonda con i plugin, output deterministico e una struttura di costi che scala in modo prevedibile per grandi batch di animazione.
Questa guida spiega perché il rendering CPU rimane la spina dorsale delle render farm cloud nel 2026, quali flussi di lavoro traggono maggior beneficio dalla CPU, come ottimizzare le scene per il rendering CPU distribuito e cosa considerare nella scelta di una render farm CPU per la pipeline di produzione.
Perché il rendering CPU persiste in un mondo GPU
La persistenza del rendering CPU non dipende dalla lentezza degli studi nell'adottare nuove tecnologie. Dipende da tre vantaggi strutturali che la GPU non ha ancora pienamente colmato.
Capacità di memoria. Il rendering CPU utilizza la RAM di sistema — 96 GB a 256 GB per nodo è lo standard nelle render farm di produzione. Il rendering GPU è limitato dalla VRAM — anche la NVIDIA RTX 5090 con 32 GB fornisce solo una frazione di ciò che offre la RAM di sistema. Per i progetti archviz con centinaia di texture ad alta risoluzione, mappe di displacement pesanti e milioni di istanze di vegetazione distribuite, la CPU è spesso l'unica opzione che non richiede ottimizzazione della scena per rientrare nei limiti di memoria.
Maturità dell'ecosistema di plugin. La pipeline di rendering CPU è stata raffinata in due decenni. Plugin come Forest Pack, RailClone, Phoenix FD, Anima e TyFlow sono stati costruiti e ottimizzati per i flussi di lavoro CPU. Sebbene il loro output geometrico possa tecnicamente essere renderizzato su GPU, l'impronta di memoria di scatter complessi (oltre 10 milioni di istanze) eccede spesso la VRAM. Su CPU, queste scene renderizzano senza modifiche.
Comportamento deterministico e prevedibile. Il rendering CPU produce risultati identici indipendentemente dalla macchina su cui viene eseguito (a parità di versione del motore e impostazioni). Questo conta per l'animazione, dove la coerenza frame-per-frame è critica — e conta per la stima dei costi, perché i tempi di rendering CPU sono altamente prevedibili tra scene simili.
Quali motori di rendering usano la CPU nel 2026
Non tutti i motori sono uguali nel supporto CPU. Ecco il panorama attuale:
| Motore di rendering | Rendering CPU | Alternativa GPU | CPU ancora preferita quando… |
|---|---|---|---|
| V-Ray 7 | Supporto completo, altamente ottimizzato | V-Ray GPU disponibile | La scena supera la VRAM; i plugin dipendono dal percorso CPU; lo studio ha una pipeline V-Ray CPU consolidata |
| Corona Renderer | Supporto completo, solo CPU | Nessuna versione GPU | Sempre — Corona è esclusivamente CPU. Nessuna alternativa GPU esiste |
| Arnold | Supporto completo | Arnold GPU disponibile | Scene VFX pesanti con shader complessi; output deterministico richiesto per il compositing |
| Blender Cycles | Supporto completo | GPU preferita dalla comunità | La scena supera la memoria GPU; utilizzo di funzionalità ottimizzate per CPU come il rendering di strand |
| Houdini Mantra | Supporto completo | Karma XPU (ibrido) | Pipeline Houdini legacy; scene con geometria procedurale pesante. Nota: SideFX sta migrando verso Karma come renderer principale — Mantra continua a essere supportato ma non è più il predefinito |
L'osservazione chiave: Corona non ha alcun percorso GPU, il che significa che ogni utente Corona nel mondo renderizza su CPU. Poiché Corona è uno dei motori archviz dominanti (insieme a V-Ray), da solo rappresenta una quota significativa dei carichi di lavoro delle render farm CPU.
V-Ray offre sia modalità CPU che GPU, ma molti studi mantengono flussi di lavoro CPU perché le loro librerie di scene esistenti, le configurazioni dei materiali e le configurazioni dei plugin sono ottimizzate per CPU. La migrazione a GPU non è gratuita — richiede di testare ogni scena per la compatibilità VRAM e potenzialmente ricostruire i materiali.
Come funziona una render farm CPU

Diagramma di una render farm CPU che distribuisce un lavoro da un file di scena attraverso un nodo manager a otto server worker e verso un output composito
Comprendere la meccanica aiuta a ottimizzare il flusso di lavoro e a prevedere i costi.
Distribuzione dei frame. Quando si invia un'animazione a una render farm CPU, lo scheduler assegna ciascun frame a una macchina separata. Un'animazione di 500 frame distribuita su 200 macchine significa che 200 frame renderizzano simultaneamente — circa 2,5 batch per completare la sequenza. Il tempo wall-clock scende da potenzialmente settimane su una singola workstation a ore sulla render farm.
Rendering per frame. Ogni macchina carica il file di scena, inizializza il motore di rendering e calcola tutti i pixel per il frame assegnato. Nella nostra flotta, ogni nodo CPU esegue processori Dual Intel Xeon E5-2699 V4 — vale a dire 44 core fisici per macchina, tutti che lavorano simultaneamente su un singolo frame. Più core per nodo, più rapidamente ogni singolo frame viene completato.
Rendering di immagini fisse. Per still ad alta risoluzione singoli (comuni in archviz), alcune render farm supportano il rendering per regione — suddividere un frame in tile che renderizzano su più macchine, per poi comporre i tile nell'immagine finale. Non è universalmente supportato, ma può ridurre significativamente i tempi di consegna per gli hero shot.
Dipendenze della scena. La render farm necessita di accesso a tutto ciò che la scena referenzia: texture, file proxy, dati di cache, GI map. Le render farm completamente gestite gestiscono la raccolta delle dipendenze attraverso strumenti di upload che scansionano la scena e impacchettano tutti i file referenziati. Gli asset mancanti sono la causa più comune di rendering falliti in render farm — e la più prevenibile.
Ottimizzare le scene per le render farm CPU
La differenza tra una scena ottimizzata e una non ottimizzata su una render farm CPU può essere di 2-5× sul costo di rendering. Queste ottimizzazioni si applicano a qualsiasi motore di rendering CPU.
Gestione delle texture.
- Usa dimensioni di texture appropriate alla distanza dalla camera. Una texture 4K su un oggetto a 50 metri dalla camera spreca RAM e tempo di rendering — 1K o 2K è visivamente identico a quella distanza.
- Converti le texture in formati tiled (.tx per Arnold, .vrmap per V-Ray) dove supportato. Le texture tiled caricano solo le porzioni necessarie per i pixel visibili.
- Verifica la libreria delle texture prima dell'upload. Vediamo regolarmente progetti con oltre 40 GB di texture in cui il 60% non è mai visibile nel frame finale.
Displacement e subdivision.
- Le mappe di displacement con alti livelli di subdivision sono il maggiore moltiplicatore singolo di costo in archviz. Un tappeto denso con 4 livelli di subdivision su una grande area di pavimento può raddoppiare il tempo di rendering per frame.
- Usa subdivision basata sulla distanza dove il motore lo supporta. Gli oggetti lontani dalla camera non necessitano di displacement fine.
- Esegui il bake del displacement in geometria per oggetti che appaiono in ogni frame di un'animazione — il costo singolo di bake è di gran lunga inferiore al ricalcolo del displacement 500 volte.
Ottimizzazione dello scatter.
- Le scene Forest Pack e RailClone con milioni di istanze consumano enormi quantità di RAM. Usa un falloff di densità basato sulla distanza: gli oggetti oltre 50 metri dalla camera possono scendere al 10-20% di densità senza differenze visibili.
- Gli oggetti proxy riducono la memoria per istanza. Converti mesh dettagliate in V-Ray proxy o Forest Pack custom object.
- Per animazioni in cui la camera si muove attraverso un paesaggio, imposta la densità di scatter relativa alla posizione della camera, non al centro della scena.
GI e sampling.
- Per l'animazione, spesso è possibile ridurre la qualità GI del 30-50% rispetto alle impostazioni per immagini fisse. A 24-30 fps di riproduzione, il rumore per frame è invisibile in movimento.
- Usa modalità light cache o irradiance map che possono essere pre-calcolate e condivise tra i frame — questo evita di ricalcolare la GI da zero a ogni frame.
- Punta al numero minimo di sample che produce risultati puliti dopo il denoising. Il denoiser integrato di V-Ray e il denoising di Corona consentono conteggi di sample più bassi senza perdita visibile di qualità.
Costo della render farm CPU: cosa aspettarsi
La tariffazione delle render farm CPU utilizza tipicamente un modello GHz-ora: si paga per la velocità di clock totale della CPU moltiplicata per il tempo consumato.
Come funziona la tariffazione GHz-ora:
Una macchina con 44 core a 2,2 GHz fornisce circa 96,8 GHz di compute. Se la render farm addebita $0,004/GHz-ora e il frame impiega 10 minuti su quella macchina:
96,8 GHz x (10/60) h x $0,004 = $0,065 per frame
Per un'animazione di 500 frame: 500 x $0,065 = $32,50 in totale
Intervalli di costo tipici osservati nei lavori di produzione:
| Flusso di lavoro | Risoluzione | Tempo medio per frame | Costo/frame | Progetto tipico |
|---|---|---|---|---|
| Archviz interno (V-Ray/Corona) | 3000x2000 | 8-15 min | $0,08-$0,18 | 5-20 angoli |
| Archviz esterno (vegetazione) | 4000x2250 | 15-30 min | $0,18-$0,40 | 5-15 angoli |
| Visualizzazione prodotto | 4K | 5-12 min | $0,06-$0,15 | 10-50 frame |
| Animazione broadcast (Arnold/V-Ray) | 1920x1080 | 3-8 min | $0,04-$0,10 | 1.500-3.000 frame |
| Animazione di personaggio (Maya + Arnold) | 1920x1080 | 10-25 min | $0,12-$0,32 | 2.000-5.000 frame |
| VFX pesante (volumetrici, particelle) | 4K | 20-45 min | $0,25-$0,60 | 500-2.000 frame |
Questi numeri provengono da lavori reali sulla nostra flotta. I costi reali dipendono dalla complessità della scena, dalle impostazioni di rendering, dalla risoluzione e dalla tariffazione specifica della render farm. Per una scomposizione dettagliata che include il confronto con la GPU, consulta la nostra guida al costo per frame della render farm.
I livelli di priorità influenzano il costo totale ma non il costo compute per frame. La maggior parte delle render farm offre priorità bassa/standard/alta. Priorità bassa significa che il lavoro attende macchine disponibili, ma costa il 30-50% in meno rispetto alla priorità urgente. Se la scadenza lo consente, la priorità bassa è l'approccio più conveniente.
Scegliere una render farm CPU: cosa conta
Non tutte le render farm CPU sono equivalenti. Ecco cosa valutare:
Supporto software e plugin. Verifica che la render farm supporti la versione esatta del DCC, la versione del motore di rendering e i plugin critici. «Supportiamo V-Ray» non è sufficiente — serve V-Ray 7.0.2 con Forest Pack 8.x e RailClone 10.x. Le render farm gestite mantengono liste di versioni specifiche; controllale prima dell'upload.
Conteggio core e specifiche del nodo. Più core per nodo significa frame individuali più veloci. Una render farm che esegue nodi a 44 core renderizza ogni frame più rapidamente di una con nodi a 16 core — il che conta per il turnaround single-frame e i test iterativi. Chiedi il modello CPU effettivo, non solo «server ad alte prestazioni».
Disponibilità delle macchine. Una render farm può avere hardware di fascia alta ma capacità limitata. Durante i periodi di picco (fine trimestre, scadenze di concorsi), i tempi di coda possono aumentare. Chiedi i tempi di coda tipici e se la render farm garantisce l'allocazione simultanea dei nodi per il tuo lavoro.
Modello di licenza. La render farm include licenze di motore di rendering nel prezzo, oppure le porti tu? La maggior parte delle render farm gestite include licenze V-Ray, Corona e Arnold. Questo è un fattore di costo significativo — le licenze dei motori di rendering possono aggiungere un costo importante per nodo all'anno se acquistate separatamente (consulta prezzi Chaos per le tariffe V-Ray attuali).
Upload e gestione delle dipendenze. Come gestisce la render farm le dipendenze della scena? Una buona render farm gestita fornisce un uploader che scansiona la scena alla ricerca di riferimenti esterni e impacchetta tutto automaticamente. Una cattiva gestione delle dipendenze significa rendering falliti e crediti sprecati.
Qualità del supporto. Quando i rendering falliscono — e prima o poi falliranno — quanto velocemente e quanto tecnicamente competente è il supporto? Un team di supporto che comprende le impostazioni light cache di V-Ray o la conversione di texture TX di Arnold vale più di uno che legge da uno script di troubleshooting generico.
Rendering CPU in archviz: il caso d'uso dominante
La visualizzazione architettonica rappresenta la quota più grande dell'utilizzo delle render farm CPU, e le ragioni sono istruttive.
Le scene archviz sono per natura intensive in memoria. Un interno residenziale tipico include centinaia di oggetti texturizzati — mobili con texture di tessuto dettagliate, elettrodomestici da cucina con materiali riflettenti, pavimentazioni con mappe di displacement, tende con traslucenza. Aggiungi viste esterne con vegetazione Forest Pack, paesaggistica ed elementi ambientali, e le dimensioni della scena raggiungono regolarmente 30-60 GB di dati.
Questo profilo di memoria si adatta perfettamente alla CPU e supera spesso i limiti di VRAM della GPU. Uno studio archviz che lavora con V-Ray o Corona invia scene che renderizzano in modo affidabile su nodi CPU con 128-256 GB di RAM. Le stesse scene potrebbero fallire su GPU o richiedere un'ottimizzazione estesa per rientrare in 32 GB di VRAM.
Anche il pattern di flusso di lavoro è CPU-friendly: i progetti archviz necessitano tipicamente di 5-20 angoli camera (still) più occasionalmente un'animazione walkthrough. Il costo per frame è moderato, e i budget totali di progetto cadono di solito nell'intervallo $50-$300. Per studi che gestiscono più progetti mensili, il cloud rendering CPU sostituisce la necessità di hardware di rendering locale dedicato che resterebbe inattivo tra le scadenze di progetto. Per maggiori informazioni sui flussi di lavoro specifici di archviz, consulta la nostra guida render farm per studi di architettura.
CPU vs GPU: quando la CPU è la scelta sbagliata
Il rendering CPU non è sempre la risposta. Essere onesti riguardo ai suoi limiti aiuta a prendere decisioni migliori.
Quando la GPU è genuinamente migliore:
- Il motore è GPU-nativo. Redshift e Octane non hanno una modalità CPU. Se usi questi motori, il rendering CPU non è un'opzione.
- Le scene rientrano in VRAM con margine. Per scene sotto i 24 GB di dati, la GPU renderizza tipicamente 5-8× più velocemente per frame e spesso costa meno per frame nonostante tariffe orarie più alte.
- Hai bisogno di iterazione rapida. Il vantaggio di velocità della GPU è più prezioso durante il lookdev — renderizzare dozzine di frame di test per affinare materiali e illuminazione. Aspettare 15 minuti per frame di test CPU contro 2 minuti su GPU si accumula rapidamente.
- Stai facendo motion design. L'animazione in formato breve con scene stilizzate o di complessità moderata è dove l'efficienza di costo della GPU raggiunge il picco.
Per un confronto dettagliato dei due approcci, consulta la nostra guida rendering GPU vs rendering CPU.
Il pattern pratico che osserviamo: gli studi che lavorano principalmente in archviz e compositing VFX restano su CPU. Gli studi focalizzati su motion design e flussi di lavoro intensivi in lookdev usano GPU. Gli studi che fanno entrambi usano una render farm che supporta entrambi i tipi di compute.
Il futuro del rendering CPU
Il rendering CPU non sta scomparendo, ma il suo ruolo si sta evolvendo.
La VRAM sta crescendo. I 32 GB della RTX 5090 sono il doppio di quanto offriva la RTX 3090. Le generazioni GPU future spingeranno probabilmente verso 48 GB o oltre. Man mano che la VRAM cresce, più scene che attualmente richiedono CPU si adatteranno alla GPU. Ma anche la complessità delle scene cresce — gli artisti riempiono la memoria disponibile, quindi l'obiettivo continua a spostarsi.
Il rendering ibrido sta maturando. La modalità ibrida di V-Ray 7 distribuisce il lavoro tra CPU e GPU simultaneamente sulla stessa macchina. Questo approccio estrae il massimo utilizzo dell'hardware e sfuma la divisione CPU/GPU. Su una render farm, il rendering ibrido potrebbe significare che ogni nodo contribuisce sia con compute CPU che GPU al tuo lavoro.
Anche le architetture CPU stanno migliorando. I processori AMD EPYC e Intel Xeon Scalable continuano ad aggiungere core e a migliorare le prestazioni per core. Un EPYC 9654 moderno fornisce 96 core a 3,55 GHz — circa il doppio del compute dei vecchi processori Xeon E5 v4. Il rendering CPU non sta fermo mentre la GPU avanza.
La direzione di Corona conta. Come motore solo-CPU con una vasta base di utenti, la roadmap di Corona ha un impatto diretto sulla domanda di render farm CPU. Se Chaos eventualmente rilasciasse una versione GPU, sposterebbe carichi di lavoro. Ma al 2026, non c'è alcuna roadmap GPU annunciata per Corona — il che significa che il rendering CPU è garantito come essenziale nel prevedibile futuro.
Riepilogo
| Fattore | Dettaglio |
|---|---|
| Perché la CPU persiste | Memoria (96-256 GB RAM), ecosistema di plugin, output deterministico, prevedibilità dei costi |
| Motori principali | V-Ray CPU, Corona (solo CPU), Arnold CPU, Cycles, Mantra |
| Caso d'uso dominante | Archviz (scene pesanti in memoria, Forest Pack/RailClone), compositing VFX |
| Modello di tariffazione | GHz-ora — pagamento per il tempo di compute CPU consumato |
| Costo tipico | $0,04-$0,60 per frame in base a complessità e risoluzione |
| Quando NON usare la CPU | Motori GPU-nativi (Redshift, Octane), scene sotto i 24 GB, iterazione di lookdev |
| Tendenza | La crescita della VRAM sposta alcuni carichi su GPU, ma la complessità delle scene cresce in parallelo |
FAQ
Q: Cos'è una render farm CPU? A: Una render farm CPU è una rete di server che utilizza core di processore (CPU) per renderizzare scene 3D in parallelo. Ogni server ha tipicamente 16-96 core, e la render farm distribuisce i frame di animazione su centinaia di macchine simultaneamente. Le render farm CPU gestiscono la maggior parte dei carichi di lavoro di cloud rendering, specialmente per progetti V-Ray, Corona e Arnold dove le scene richiedono più memoria di quanta ne fornisca la VRAM della GPU.
Q: Il rendering CPU è ancora rilevante nel 2026? A: Sì — il rendering CPU gestisce circa il 70% dei lavori di render farm nel 2026, in base ai nostri dati operativi. Corona Renderer è solo CPU, V-Ray CPU resta la modalità dominante per archviz, e Arnold CPU è lo standard in VFX. Il rendering GPU sta crescendo ma non ha sostituito la CPU per i flussi di lavoro intensivi in memoria o ricchi di plugin.
Q: Quanto costa il cloud rendering su CPU? A: La maggior parte delle render farm CPU addebita per GHz-ora. I costi tipici per frame vanno da $0,04 per semplici frame broadcast a $0,60 per shot pesanti di VFX 4K. Un interno archviz moderato a risoluzione 3000x2000 costa tipicamente $0,08-$0,18 per frame. I costi totali di progetto dipendono dal numero di frame, dalla risoluzione e dalla complessità della scena. Consulta la nostra scomposizione del costo per frame per tariffazione dettagliata.
Q: Quali motori di rendering funzionano sulle render farm CPU? A: V-Ray (modalità CPU), Corona Renderer, Arnold (modalità CPU), Blender Cycles e Houdini Mantra supportano tutti il rendering CPU. Corona è esclusivamente CPU — non ha opzione di rendering GPU. V-Ray e Arnold supportano sia modalità CPU che GPU, dando agli studi la flessibilità di scegliere in base ai requisiti della scena.
Q: Come ottimizzo la scena per una render farm CPU? A: Concentrati su tre aree: riduci le dimensioni delle texture per oggetti distanti (1K-2K invece di 4K per oggetti lontani dalla camera), abbassa i livelli di subdivision del displacement (usa falloff basato sulla distanza) e ottimizza la densità di scatter in Forest Pack o RailClone (scendi al 10-20% di densità oltre i 50 metri dalla camera). Queste tre ottimizzazioni da sole possono ridurre il costo di rendering del 30-50%.
Q: Qual è la differenza tra una render farm CPU gestita e un setup cloud DIY? A: Una render farm gestita preinstalla motore di rendering, plugin e licenze — carichi una scena e ricevi i frame finiti. Un setup DIY (AWS, Azure) ti dà macchine virtuali grezze dove installi tutto da solo. Le render farm gestite sono più semplici e includono il licensing; i setup DIY offrono più controllo ma richiedono risorse di ingegneria di pipeline. Per un confronto più approfondito, consulta la nostra guida cloud rendering gestito vs DIY.
Q: Di quanti core CPU ho bisogno per il rendering? A: Più core significa frame individuali più veloci. Un nodo di rendering a 44 core completa un frame circa 2,5× più velocemente di una workstation a 16 core. Su una render farm cloud, non scegli direttamente il numero di core — scegli quante macchine (e a quale priorità) assegnare al tuo lavoro. Il numero totale di core della render farm determina quanti frame possono renderizzare simultaneamente.
Q: Dovrei passare dal rendering CPU al GPU? A: Dipende dal motore e dalla complessità della scena. Se usi Corona, non hai un'opzione GPU. Se usi V-Ray o Arnold e le tue scene rientrano regolarmente in 24-28 GB di dati, il rendering GPU può essere più veloce ed economico per frame. Se le scene sono intensive in memoria (oltre 30 GB) o si basano su plugin ottimizzati per CPU con grandi scatter, la CPU resta la scelta pratica. Molti studi usano entrambi — GPU per iterazione e lookdev, CPU per i rendering di produzione finali.
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.

