O Que É uma Render Farm? O Guia Completo para Artistas 3D

O que é uma render farm?

Uma render farm é um conjunto de computadores ligados em rede -- chamados render nodes -- que trabalham em conjunto para processar trabalhos de renderização 3D. Em vez de depender de uma única estação de trabalho para calcular cada frame de uma animação ou cada tile de uma imagem de alta resolução, uma render farm distribui essas tarefas por dezenas, centenas ou até milhares de máquinas em simultâneo.

O conceito é simples: a renderização é computacionalmente dispendiosa, e um único frame de uma visualização arquitectónica fotorrealista ou de um plano de VFX pode demorar entre minutos e horas numa única máquina. Multiplique isso por milhares de frames numa sequência de animação, e estamos a falar de dias ou semanas de renderização contínua numa estação de trabalho. Uma render farm comprime esse prazo ao dividir o trabalho por muitas máquinas a funcionar em paralelo.

Operamos uma render farm desde 2010, e nesse tempo o princípio fundamental não mudou. O que evoluiu foi a escala, o ecossistema de software em torno dela e a acessibilidade. As render farms costumavam ser algo que apenas grandes estúdios de VFX conseguiam construir e manter. Hoje, as render farms na nuvem tornaram o mesmo poder de computação acessível a freelancers, pequenos estúdios e estudantes a trabalhar em projetos pessoais.

O significado de render farm vai além do hardware em si. Uma render farm moderna inclui o hardware (nós CPU e GPU), o software de gestão de renderização que organiza e distribui trabalhos, a infraestrutura de armazenamento que guarda ficheiros de cena e frames de saída, e a rede que une tudo. Compreender cada um destes componentes ajuda a avaliar se uma render farm -- e que tipo -- se adequa ao fluxo de trabalho pretendido.

Como funciona uma render farm?

A um nível geral, todas as render farms seguem o mesmo fluxo de trabalho: um trabalho entra, é dividido em tarefas mais pequenas, essas tarefas são distribuídas pelos nós disponíveis, cada nó renderiza a sua parte atribuída, e os resultados são recolhidos.

Eis uma descrição mais detalhada do que acontece nos bastidores:

Submissão da cena. Empacota-se a cena 3D -- incluindo geometria, texturas, materiais, iluminação e definições de renderização -- e envia-se para a farm. Na nossa farm, isto normalmente envolve o upload de um pacote de projeto através de uma interface web ou plugin de desktop. O sistema da farm valida a cena para detetar recursos em falta (texturas, proxies, ficheiros de cache) antes de a renderização começar.

Análise do trabalho e divisão em tarefas. O gestor de renderização analisa o trabalho submetido e divide-o em tarefas individuais. Numa animação, cada frame torna-se normalmente uma tarefa. Numa única imagem de alta resolução, a imagem pode ser dividida em regiões (frequentemente chamadas buckets ou tiles), e cada região torna-se uma tarefa. Alguns motores de renderização tratam desta divisão internamente; outros dependem do gestor de renderização.

Distribuição de tarefas. O gestor de renderização atribui tarefas aos nós disponíveis com base na prioridade, requisitos de hardware (CPU vs GPU) e posição na fila. Gestores de renderização modernos utilizam algoritmos de agendamento sofisticados -- podem priorizar trabalhos urgentes, encaminhar trabalho específico de GPU para nós GPU e reatribuir tarefas dinamicamente se um nó falhar ou ficar disponível.

Renderização. Cada nó carrega a cena, aplica as definições de renderização atribuídas e calcula a sua porção da saída. A renderização CPU utiliza tipicamente motores como V-Ray, Corona ou Arnold, executando cálculos em todos os núcleos CPU disponíveis. A renderização GPU utiliza motores como Redshift, Octane ou V-Ray GPU, aproveitando o poder de processamento paralelo das placas gráficas.

Recolha de resultados e saída. Assim que todas as tarefas são concluídas, os frames renderizados ou tiles de imagem são montados e disponibilizados para download. Verificações de controlo de qualidade -- como verificar a continuidade de frames em animações ou detetar artefactos de renderização -- podem acontecer automaticamente ou manualmente nesta fase.

Todo o processo é orquestrado por um gestor de renderização -- software como Thinkbox Deadline, Royal Render ou Pixar Tractor. O gestor de renderização é o cérebro da operação: acompanha cada tarefa, gere falhas (re-agendando frames com erros), gere prioridades entre múltiplos utilizadores e projetos, e disponibiliza painéis de monitorização para acompanhar o progresso em tempo real.

Para uma análise técnica mais aprofundada de cada etapa do pipeline -- algoritmos de fila de trabalhos, distribuição de cenas, recuperação de falhas de nós e verificação de qualidade -- consulte o nosso guia sobre como funcionam as render farms.

Tipos de render farms

Existem três grandes categorias de render farms, cada uma com compromissos distintos em termos de custo, controlo e complexidade.

Render farms auto-construídas (locais). Esta é a abordagem tradicional: adquire-se hardware, configura-se a rede e o armazenamento, instala-se software de gestão de renderização e mantém-se tudo internamente. Estúdios como Pixar, ILM e Weta operaram historicamente farms locais massivas com milhares de nós.

As vantagens são o controlo total sobre a seleção de hardware, configuração de software e segurança de dados. As desvantagens são significativas: elevado investimento de capital inicial (um nó capaz começa em torno de $3.000-$5.000, e são necessários muitos), custos contínuos com eletricidade, refrigeração, manutenção e pessoal de TI, além da realidade de que a farm fica inativa entre projetos. Para uma análise mais aprofundada dos compromissos financeiros, consulte a nossa análise de custo total: construir vs. nuvem.

Render farms na nuvem. As render farms na nuvem fornecem recursos de computação remota a pedido -- carrega-se a cena, esta é renderizada no hardware do fornecedor e paga-se por utilização. Esta categoria cresceu substancialmente na última década. As farms na nuvem eliminam o investimento de capital e os custos de hardware inativo, mas introduzem custos de renderização por trabalho e exigem o upload de ficheiros de cena potencialmente grandes pela internet.

As render farms na nuvem apresentam-se em diferentes modelos, o que importa bastante para o fluxo de trabalho. Para uma explicação detalhada, consulte o nosso guia sobre render farms na nuvem. Os dois modelos principais são:

• Farms totalmente geridas tratam de tudo -- instalação de software, compatibilidade de plugins, licenciamento e suporte técnico. Carrega-se uma cena e recebem-se os frames de volta. Este é o modelo que operamos na Super Renders Farm, com mais de 20.000 núcleos CPU e uma frota GPU com NVIDIA RTX 5090 (32 GB VRAM). Para compreender como as farms totalmente geridas diferem das opções self-service, escrevemos um guia dedicado sobre render farms totalmente geridas.
• Farms Infrastructure-as-a-Service (IaaS) dão acesso remoto ao hardware (frequentemente via ambiente de trabalho remoto), cabendo ao utilizador instalar e configurar tudo. Isto proporciona mais controlo mas exige mais conhecimento técnico.

Render farms híbridas. Alguns estúdios mantêm uma pequena farm local para o trabalho do dia-a-dia e escalam para uma render farm na nuvem durante períodos de pico -- prazos apertados, grandes sequências de animação ou múltiplos projetos em simultâneo. Esta abordagem híbrida equilibra o controlo e o baixo custo por trabalho do hardware local com a elasticidade dos recursos na nuvem.

Quem utiliza render farms?

As render farms servem uma vasta gama de indústrias e escalas de projeto:

Indústria	Caso de uso típico	Motores de renderização comuns
Visualização arquitectónica	Imagens de alta resolução e animações walkthrough para imobiliário e design de interiores	V-Ray, Corona
Cinema e VFX	Planos de efeitos visuais, sequências animadas	Arnold, V-Ray, Redshift
Estúdios de animação	Produção de séries, curtas-metragens, animação longa-metragem	Arnold, V-Ray, Redshift
Motion design	Gráficos para broadcast, comerciais, sequências de títulos	Redshift, Octane, Cinema 4D nativo
Visualização de produto	Renders fotorrealistas de produto, turntables 360 graus	V-Ray, Corona, KeyShot
Cinemáticas de jogos	Cutscenes e trailers pré-renderizados	V-Ray, Arnold, Unreal (offline)
Académico e pessoal	Filmes de estudantes, peças de portfólio, projetos pessoais	Cycles (Blender), Arnold, V-Ray

O fio condutor é que todos estes fluxos de trabalho envolvem tarefas de renderização que excedem o que uma única estação de trabalho consegue produzir num prazo razoável. Um arquiteto freelancer a renderizar uma animação walkthrough de 30 segundos em resolução 4K pode enfrentar mais de 40 horas de tempo de renderização na sua estação de trabalho. Numa render farm com 100 nós, esse mesmo trabalho pode ficar concluído em menos de uma hora.

Na nossa farm, cerca de 70 % dos trabalhos são baseados em CPU -- principalmente V-Ray e Corona para visualização arquitectónica -- com os restantes 30 % a utilizar motores GPU como Redshift e Octane. Isto reflete o padrão mais amplo da indústria: a renderização CPU permanece como o cavalo de batalha do trabalho de produção, enquanto a renderização GPU cresce rapidamente em motion design e fluxos de trabalho de lookdev.

Renderização CPU vs. renderização GPU numa farm

Compreender a diferença entre renderização CPU e GPU é importante ao escolher uma render farm, porque nem todas as farms suportam ambas de forma igual.

Renderização CPU executa-se no processador central de cada nó. Motores como V-Ray (modo CPU), Corona e Arnold são os mais comuns. A renderização CPU lida com cenas complexas com elevadas contagens de geometria, displacement pesado e cálculos de iluminação sofisticados de forma fiável. A maior parte da renderização de produção -- especialmente em archviz e VFX -- ainda funciona em CPU. Numa farm, a renderização CPU escala linearmente: 100 nós com 44 núcleos cada proporcionam 4.400 núcleos a trabalhar em paralelo.

Renderização GPU executa-se na placa gráfica (GPU). Motores como Redshift, Octane e V-Ray GPU são concebidos para explorar a arquitetura massivamente paralela das GPUs modernas. A renderização GPU é significativamente mais rápida por dólar investido em cenas que cabem na memória GPU (VRAM). A restrição é a VRAM: se a cena exceder a VRAM disponível, a renderização GPU recorre a renderização out-of-core mais lenta ou falha completamente. É por isso que as farms GPU investem em placas com elevada VRAM -- na nossa farm, utilizamos placas NVIDIA RTX 5090 com 32 GB VRAM cada, o que lida com a maioria das cenas de produção confortavelmente.

Fator	Renderização CPU	Renderização GPU
Velocidade por dólar	Moderada	Superior (quando a cena cabe na VRAM)
Limite de complexidade de cena	Muito elevado (limitado pela RAM, tipicamente 96-256 GB)	Limitado pela VRAM (16-32 GB típico)
Exemplos de motores	V-Ray, Corona, Arnold	Redshift, Octane, V-Ray GPU
Ideal para	Archviz, VFX, cenas complexas	Motion design, lookdev, fluxos de trabalho otimizados para GPU
Escalabilidade na farm	Linear com o número de núcleos	Linear com o número de GPUs

A escolha entre renderização CPU e GPU numa farm resume-se frequentemente à complexidade da cena e ao motor de renderização. Se a cena cabe confortavelmente na VRAM da GPU e se está a utilizar um motor nativo GPU, a renderização GPU será tipicamente mais rápida e mais rentável. Se a cena tem geometria pesada, volumétricos complexos ou requer mais RAM do que uma GPU proporciona, a renderização CPU é a escolha fiável.

Quanto custa uma render farm?

Os custos de uma render farm variam amplamente dependendo do tipo de farm e da forma como é utilizada.

Custos de uma farm auto-construída. Construir uma farm própria requer um investimento inicial significativo. Uma farm CPU básica de 10 nós pode custar $30.000-$50.000 só em hardware (servidores, rede, armazenamento), mais custos contínuos com eletricidade (uma farm de 10 nós pode consumir 3-5 kW continuamente), refrigeração, manutenção, licenças de software e mão-de-obra de TI. Para uma descrição detalhada dos custos, consulte a nossa análise de custo total: construir vs. nuvem.

Custos de render farms na nuvem. As farms na nuvem cobram tipicamente por GHz-hora (CPU) ou por OctaneBench-hora (GPU), com tarifas que variam conforme o fornecedor e o plano. Intervalos aproximados da indústria no início de 2026:

• Renderização CPU: $0,015-$0,05 por GHz-hora, o que significa que um único frame que demora 1 hora num nó de 44 núcleos / 3,6 GHz pode custar aproximadamente $1,50-$5,00 numa farm na nuvem
• Renderização GPU: $1,50-$5,00 por hora de GPU para placas de gama alta (classe RTX 4090/5090), embora os modelos de preços variem bastante
• Planos mensais e descontos por volume podem reduzir as tarifas efetivas em 20-40 % para utilizadores regulares. É possível explorar os escalões de preços atuais na nossa página de preços

Para descrições detalhadas de preços por motor e tipo de projeto, consulte o nosso guia de preços de render farms e a descrição de custo por frame.

A questão financeira fundamental não é «qual é mais barato» mas sim «que modelo se adequa ao padrão de renderização». Estúdios com cargas de renderização consistentes e diárias podem justificar uma farm local. Estúdios com picos esporádicos e orientados por prazos frequentemente consideram as farms na nuvem mais económicas porque não pagam nada durante períodos inativos.

Que software e motores de renderização funcionam com render farms?

A maioria do software 3D profissional e motores de renderização são concebidos com a renderização distribuída em mente. Eis uma visão geral prática de compatibilidade:

Aplicações 3D:

• Autodesk 3ds Max -- a aplicação DCC mais comum em render farms para archviz
• Autodesk Maya -- padrão para pipelines de VFX e animação
• Maxon Cinema 4D -- amplamente utilizado em motion design
• Blender -- open-source, a crescer rapidamente em render farms. Consulte o nosso guia de render farm para Blender para detalhes de compatibilidade
• SideFX Houdini -- fluxos de trabalho de VFX e simulação

Motores de renderização:

• V-Ray (CPU e GPU) -- o motor de renderização comercial mais utilizado na nossa farm
• Corona -- apenas CPU, popular para archviz
• Arnold (CPU e GPU) -- padrão da indústria para VFX
• Redshift -- apenas GPU, popular para Cinema 4D e motion design
• Octane -- apenas GPU, conhecido pela velocidade
• Cycles -- motor integrado do Blender (CPU e GPU)

Compatibilidade de plugins é onde as coisas se tornam mais complexas numa render farm. Plugins de dispersão (Forest Pack, RailClone), ferramentas de displacement (MultiScatter, GrowFX) e bibliotecas de recursos precisam de estar instalados e licenciados em cada render node. Numa farm gerida, o fornecedor trata disso. Numa farm IaaS ou auto-construída, a gestão da instalação de plugins é da responsabilidade do utilizador. Erros de renderização relacionados com plugins são um dos problemas mais comuns que resolvemos -- plugins em falta causam objetos em branco, dispersão incorreta ou falhas totais de renderização.

Como escolher a render farm certa

Se já se decidiu que uma render farm faz sentido para o fluxo de trabalho pretendido, eis um enquadramento para avaliar as opções:

1. Identificar o padrão de renderização. Com que frequência se renderiza? É trabalho de produção diário ou picos orientados por prazos? A renderização diária favorece uma configuração local ou híbrida. A renderização esporádica favorece a nuvem.

2. Verificar o suporte de software e plugins. A farm suporta a combinação exata de DCC + motor de renderização + plugins? Este é o ponto de falha mais comum. Deve-se perguntar especificamente sobre os plugins -- não apenas sobre a aplicação principal. Uma farm que suporta «3ds Max + V-Ray» pode não ter Forest Pack ou Anima instalados.

3. Avaliar as necessidades CPU vs. GPU. Se as cenas são orientadas para GPU (Redshift, Octane), deve-se priorizar farms com GPUs de elevada VRAM. Se se utiliza principalmente V-Ray CPU ou Corona, a contagem de núcleos CPU é mais importante.

4. Considerar o modelo de gestão. Quanta configuração técnica se está disposto a fazer? As farms totalmente geridas tratam do software, licenciamento e resolução de problemas. As farms IaaS fornecem uma máquina remota e o utilizador trata do resto. A tolerância para trabalho DevOps deve orientar esta escolha.

5. Testar com um projeto real. A maioria das render farms na nuvem oferece um teste gratuito ou créditos. Devem ser utilizados -- mas com uma cena de produção real, não uma cena de demonstração. As cenas reais expõem problemas de compatibilidade de plugins, problemas de caminhos de texturas e limitações de VRAM que as cenas de demonstração não revelam.

6. Verificar as políticas de segurança de dados. Se se trabalha sob NDA (comum em cinema, publicidade e design de produto), deve-se verificar o tratamento de dados da farm: encriptação em trânsito e em repouso, políticas de retenção de dados e se oferecem acordos de NDA. A nossa política de NDA cobre isto para estúdios com requisitos rigorosos de confidencialidade.

7. Avaliar a capacidade de resposta do suporte. Os prazos de renderização são reais. Quando algo corre mal às 2 da manhã antes de uma apresentação a um cliente, com que rapidez responde a equipa de suporte da farm? Devem-se pedir detalhes de SLA ou consultar avaliações de outros utilizadores.

Lista de verificação para avaliação de render farms

Critério	Questões a colocar
Suporte de software	A farm suporta a versão exata de DCC, versão do motor de renderização e plugins?
Hardware	Que modelos de CPU e GPU estão disponíveis? Qual é a VRAM por GPU?
Modelo de preços	Por GHz-hora? Por hora de GPU? Subscrição mensal? Descontos por volume?
Segurança de dados	Encriptação? Política de retenção de dados? NDA disponível?
Suporte	24/7? Tempo médio de resposta? Chat ao vivo ou apenas por ticket?
Nível de gestão	Totalmente gerida (tratam de tudo) ou IaaS (o utilizador gere o software)?
Transferência de ficheiros	Método de upload (web, plugin, FTP)? Velocidade? Gestão de grandes projetos?
Saída	Método de entrega de frames? Sistema de notificações? Pré-visualização durante a renderização?

Conceitos errados comuns sobre render farms

«As render farms são apenas para grandes estúdios.» Isto era verdade há 15 anos. As render farms na nuvem mudaram completamente a economia -- um freelancer pode alugar 200 núcleos CPU durante algumas horas e pagar menos do que uma refeição num restaurante. A barreira já não é o custo; é saber como preparar a cena para renderização distribuída.

«Preciso de mudar o meu fluxo de trabalho para uma render farm.» Numa farm gerida bem configurada, não deveria ser necessário mudar significativamente o fluxo de trabalho. Prepara-se a cena da mesma forma que para renderização local, empacota-se, carrega-se e recebem-se os frames de volta. A principal diferença é garantir que todos os caminhos de ficheiros são relativos (não absolutos para o disco local) e que todos os recursos estão incluídos no upload.

«A renderização GPU substituiu a renderização CPU.» A renderização GPU é mais rápida em muitos cenários, mas a renderização CPU continua dominante na produção por boas razões: maior capacidade de RAM para lidar com cenas maiores, compatibilidade de software mais ampla e algoritmos de renderização mais maduros para casos de uso específicos (volumétricos, cabelo complexo, subsurface scattering). Na nossa farm, 70 % dos trabalhos ainda são executados em CPU.

«Mais nós significa sempre renderização mais rápida.» Existe um ponto de retornos decrescentes. O tempo de carregamento da cena, a sobrecarga de distribuição de tarefas e a transferência de rede adicionam latência. Uma animação de 10.000 frames beneficia enormemente de 500 nós. Uma única imagem fixa com 100 tiles de renderização não precisa de 500 nós -- 100 nós saturariam o conjunto de tarefas, e os restantes 400 ficariam inativos.

Resumo

Uma render farm -- por vezes chamada farm de renderização -- é um conjunto de computadores ligados em rede que acelera a renderização 3D ao distribuir o trabalho por muitas máquinas em paralelo. Construir uma própria, alugar a um fornecedor na nuvem ou utilizar uma abordagem híbrida depende do volume de renderização, orçamento, conhecimento técnico e requisitos do projeto.

Abordagem	Ideal para	Compromisso
Auto-construída	Produção diária, controlo total necessário	Elevado custo inicial, sobrecarga de manutenção, capacidade inativa
Nuvem (gerida)	Orientada por prazos, renderização esporádica, pequenas equipas	Custo por trabalho, tempo de upload, dependência do fornecedor
Nuvem (IaaS)	Utilizadores técnicos que necessitam de controlo sem possuir hardware	Custo por trabalho, auto-gestão necessária
Híbrida	Estúdios com carga base + necessidades de pico	Complexidade de gerir dois sistemas

O panorama das render farms continua a evoluir. A renderização GPU está a tornar as farms mais acessíveis para fluxos de trabalho de pré-visualização em tempo real. Os preços na nuvem estão a tornar-se mais competitivos. E a fronteira entre renderização local e na nuvem está a esbater-se à medida que os fluxos de trabalho híbridos amadurecem.

Para o próximo passo, explore o tipo específico que se adequa à situação pretendida: render farms na nuvem explicadas, farms geridas vs. self-service ou preços atuais na indústria. Para avaliar especificamente o custo, a nossa comparação de custos: construir vs. nuvem detalha os números.

FAQ

Quanto custa uma render farm?

Os custos dependem do tipo. Farms auto-construídas requerem $30.000-$50.000 ou mais em hardware para uma configuração básica de 10 nós, mais eletricidade e manutenção contínuos. As render farms na nuvem cobram por utilização -- tipicamente $0,015-$0,05 por GHz-hora para CPU ou $1,50-$5,00 por hora de GPU -- com planos mensais a oferecer descontos de 20-40 %. O padrão de renderização (diário vs. esporádico) determina qual o modelo mais económico.

Preciso de uma render farm?

Se os trabalhos de renderização demoram regularmente mais do que algumas horas na estação de trabalho, ou se enfrenta prazos apertados que uma única máquina não consegue cumprir, uma render farm pode ajudar. Freelancers a trabalhar numa única imagem fixa podem não precisar de uma. Estúdios a produzir animações, walkthroughs arquitectónicos ou sequências de VFX quase sempre beneficiam do acesso a uma farm.

Que software funciona com render farms?

A maioria das aplicações 3D profissionais suporta fluxos de trabalho de render farm, incluindo 3ds Max, Maya, Cinema 4D, Blender e Houdini. Os motores de renderização suportados incluem V-Ray, Corona, Arnold, Redshift, Octane e Cycles. O fator crítico é a compatibilidade de plugins -- deve-se verificar que os plugins específicos (ferramentas de dispersão, gestores de recursos, plugins de displacement) são suportados pela farm escolhida.

Posso construir a minha própria render farm?

Sim. Construir uma render farm requer a aquisição de hardware de servidor, a configuração de rede e armazenamento partilhado, a instalação de um gestor de renderização (como Deadline ou Royal Render) e a configuração de licenças de software em cada nó. É um empreendimento significativo em termos de custo, conhecimento técnico e manutenção contínua, mas proporciona controlo total sobre hardware e dados.

Qual é a diferença entre uma render farm e cloud rendering?

Uma render farm é qualquer conjunto de máquinas ligadas em rede utilizado para renderização distribuída -- pode ser local ou na nuvem. Cloud rendering refere-se especificamente à utilização de recursos de computação remotos, acessíveis pela internet, para renderização. Todas as render farms na nuvem são render farms, mas nem todas as render farms são baseadas na nuvem. O termo «render farm» é mais abrangente e inclui instalações locais auto-construídas.

Quanto tempo demora uma render farm a renderizar?

O tempo de renderização depende da complexidade da cena, resolução, definições do motor de renderização e quantos nós estão atribuídos ao trabalho. Um trabalho que demora 24 horas numa única estação de trabalho pode ficar concluído em 15-30 minutos numa farm com 100 nós. No entanto, existe sobrecarga para upload da cena, distribuição de tarefas e recolha de frames, pelo que tempos de renderização por frame extremamente curtos (menos de alguns segundos) não beneficiam tanto da escalabilidade da farm.

Os dados estão seguros numa render farm?

As render farms na nuvem de boa reputação utilizam encriptação para dados em trânsito e em repouso, implementam controlos de acesso rigorosos e oferecem acordos de NDA para projetos sensíveis. Numa farm auto-construída, a segurança dos dados é inteiramente da responsabilidade do utilizador. Ao avaliar farms na nuvem, deve-se perguntar sobre a política de retenção de dados (durante quanto tempo os ficheiros são armazenados após a renderização), padrões de encriptação e se assinam NDAs específicos de projeto.

Que motores de renderização funcionam numa render farm?

Motores baseados em CPU como V-Ray, Corona e Arnold funcionam em praticamente qualquer render farm com hardware e licenças compatíveis. Motores baseados em GPU como Redshift, Octane e V-Ray GPU requerem farms com GPUs NVIDIA suportadas e VRAM suficiente. O motor Cycles do Blender (modos CPU e GPU) é amplamente suportado devido ao seu licenciamento open-source. Deve-se verificar sempre a versão específica do motor suportada -- os motores de renderização atualizam-se frequentemente, e a compatibilidade da farm com a versão mais recente pode ter atraso.