Redshift Render Farm: Guia de Renderização GPU na Nuvem para 2026

O Redshift é um dos motores sobre os quais mais perguntas chegam à nossa render farm. Trata-se de um renderer biased com aceleração GPU, concebido para velocidade em produção. Os artistas recorrem a ele pelos mesmos três motivos: é desenvolvido em torno da placa gráfica, mantém um comportamento previsível sob prazos apertados, e está disponível nas quatro aplicações em que a maioria dos nossos clientes já trabalha — Cinema 4D, Maya, 3ds Max e Houdini.

Este guia é uma referência única para utilizar o Redshift numa render farm na nuvem, independentemente da aplicação em que a cena foi criada. Uma render farm não altera a forma como se ilumina ou define materiais num frame; altera o que acontece quando se inicia a renderização. Em vez de uma única estação de trabalho a processar uma sequência durante a noite, muitas máquinas GPU recolhem os frames em paralelo e devolvem-nos numa fração do tempo real. As trocas de compromisso que importam — VRAM, licenciamento, transferência de ficheiros e custo — são as mesmas, seja qual for o ponto de partida da cena Redshift, em Cinema 4D ou em Houdini. É precisamente por isso que faz sentido tratar "Redshift numa render farm" como um único tema, em vez de quatro temas separados.

Fluxo de renderização Redshift na nuvem — Cinema 4D, Maya, 3ds Max e Houdini alimentam um único motor Redshift, e depois as cenas são carregadas para uma frota GPU que renderiza os frames em paralelo para download

Por que o Redshift renderiza em GPU — e o que isso significa numa render farm

O Redshift é, antes de mais, um renderer GPU. Utiliza os percursos CUDA e OptiX da placa gráfica para traçar raios, o que lhe confere a resposta interativa que os artistas lhe associam. Na nossa render farm, todos os jobs de Redshift são executados numa frota GPU dedicada, composta por placas NVIDIA RTX 5090 com 32 GB de VRAM cada. Utilizamos o Redshift em modo GPU — é o percurso para o qual o nosso hardware foi configurado — e vale a pena ser preciso neste ponto, porque o Redshift também ganhou um modo de renderização CPU na versão 3.5. Na nossa render farm, o Redshift funciona exclusivamente em GPU; não existe percurso de renderização CPU disponível aqui. Se uma cena tiver sido otimizada para o backend CPU, é necessário validá-la com a saída GPU antes de comprometer uma sequência longa.

Esta arquitetura GPU-first é o que torna o Redshift uma escolha natural para renderização distribuída. Os frames são unidades de trabalho independentes, pelo que uma sequência que demora oito horas numa placa pode ser distribuída por muitas placas e devolvida muito mais rapidamente. A função de uma render farm é manter essas placas a trabalhar, tratar do licenciamento e entregar os frames — sem que seja necessário pensar nas máquinas subjacentes.

Uma render farm também elimina o principal obstáculo GPU para artistas a trabalhar sozinhos: o número de placas. Localmente, renderiza-se com uma ou duas GPU. Numa render farm, a restrição passa de "quantas placas possuo" para "como estruturo a cena para que as placas a possam ler" — um problema muito mais fácil de resolver, que abordamos na secção sobre fluxo de trabalho.

Redshift em quatro aplicações: Cinema 4D, Maya, 3ds Max e Houdini

O Redshift comporta-se de forma consistente entre as aplicações host porque o motor é o mesmo; o que difere é o plugin de ligação e a forma como cada aplicação exporta os dados da cena. Suportamos o Redshift nos quatro DCCs onde os nossos clientes mais o utilizam:

• Cinema 4D. O Redshift está aqui profundamente integrado — é um produto Maxon, e o Cinema 4D é uma aplicação Maxon, pelo que o sistema de materiais, a vista de renderização e o sistema de takes se comportam de forma nativa. Esta é a combinação Redshift mais madura que encontramos, e a que tem mais historial de cenas prontas para render farm. Para uma análise aprofundada específica do Cinema 4D, consulte o nosso guia de render farm Redshift para Cinema 4D.
• Maya. O Redshift for Maya é uma integração com longa tradição em produção, com suporte completo para camadas de renderização do Maya, AOVs e o habitual fluxo de trabalho com materiais baseados em nós. As cenas referenciam texturas e caches através da estrutura de projeto do Maya, pelo que a principal consideração na render farm é garantir que esses caminhos se resolvem depois de os ficheiros saírem da estação de trabalho.
• 3ds Max. A integração com 3ds Max abrange as definições do renderer, o editor de materiais e os render elements expectáveis. O Redshift é aqui frequentemente utilizado com plugins de dispersão e proxy, pelo que proxies e referências externas são os elementos a empacotar com maior cuidado.
• Houdini. O Redshift no Houdini é a opção GPU que muitos artistas combinam com trabalho intensivo de simulação e instancing, a par de Karma e Mantra. Se o pipeline for orientado para Houdini, a nossa página sobre render farm na nuvem para Houdini abrange o panorama geral de motores nessa aplicação.

Em todas as quatro aplicações, a licença do motor de renderização está incluída no valor pago pela renderização — não é necessário trazer uma licença Redshift própria. Enquanto parceiro oficial Maxon, licenciamos o Redshift (e o restante da linha Maxon) para utilização de renderização na render farm, o que permite que o motor esteja disponível em todas as aplicações suportadas sem qualquer configuração necessária da parte do utilizador. É possível verificar esse estatuto de parceiro diretamente no diretório de parceiros Maxon.

Cinema 4D, Maya, 3ds Max e Houdini a alimentar um único motor Redshift numa render farm GPU, com a licença Redshift incluída na taxa de renderização

VRAM, out-of-core e cenas de grande dimensão

Na renderização GPU, a VRAM é o valor que determina se uma cena renderiza sem problemas ou fica bloqueada. O Redshift carrega geometria, texturas e outros dados da cena para a memória da placa; quando a cena cabe nessa memória, a placa funciona a plena capacidade. A nossa frota GPU disponibiliza 32 GB de VRAM para cada job de Redshift, o que cobre uma ampla variedade de cenas de produção sem necessidade de tratamento especial.

Quando os dados de uma cena excedem a VRAM disponível, o Redshift não falha simplesmente — recorre à sua tecnologia out-of-core, paginando texturas e geometria a partir da memória do sistema conforme a placa necessita delas. Esta é a resposta honesta à pergunta "e quanto à minha cena pesada": o Redshift consegue renderizar cenas maiores do que a VRAM através do out-of-core, com algum custo de desempenho, porque a placa tem de aceder a memória mais lenta. É uma técnica GPU, não uma transferência para um renderer CPU. Na prática, a forma de manter uma cena Redshift pesada a renderizar com rapidez é reduzir a pressão desnecessária sobre a VRAM — tamanhos de textura adequados, proxies para geometria repetida, e eliminar o que não está realmente em frame — deixando o out-of-core absorver o restante.

Se estiver a ponderar se os 32 GB do RTX 5090 são suficientes para o trabalho em causa, o nosso artigo sobre desempenho de renderização GPU na nuvem com RTX 5090 analisa o comportamento da placa em cenas reais.

Gráfico da utilização de VRAM a aumentar com a complexidade da cena, ultrapassando a linha dos 32 GB do RTX 5090 onde o out-of-core do Redshift entra em ação e continua a renderizar na GPU com algum custo de desempenho

Render farm totalmente gerida vs. aluguer de uma máquina GPU

Existem duas formas gerais de renderizar o Redshift na nuvem, e a diferença importa mais do que as especificações de hardware.

A primeira é o aluguer de infraestrutura, onde se arrenda uma máquina GPU remota, se liga a ela por desktop remoto, se instala o Redshift e a aplicação host, se resolve o licenciamento, se copiam os ficheiros e se gere a renderização. Obtém-se uma máquina vazia com controlo total, juntamente com toda a configuração e manutenção que isso implica.

A segunda é uma render farm totalmente gerida, que é a forma como operamos. Carrega-se a cena, o motor e as licenças já estão em funcionamento, os frames são distribuídos pela frota GPU automaticamente, e recolhe-se o resultado. Não há desktop remoto em que iniciar sessão, nada a instalar nem licenças a ativar. Para um artista de Redshift, isto elimina as partes da renderização na nuvem que nada têm a ver com a criação de imagens — e é a principal diferença entre uma render farm gerida e os alugueres de GPU como infraestrutura-como-serviço que possa ter utilizado. A nossa página sobre render farm Redshift na nuvem é o sítio indicado para um colega que queira a versão resumida.

Qual dos modelos é mais adequado depende do nível de controlo necessário sobre o ambiente. Se existir uma cadeia de plugins invulgar ou uma build personalizada, uma máquina vazia pode ser a ferramenta certa. Para a maioria do trabalho com Redshift — uma aplicação host padrão, o motor e a cena — uma render farm gerida devolve os frames com muito menos esforço adicional.

Quanto custa a renderização com Redshift numa render farm

A renderização GPU na nossa render farm é faturada por utilização, e não por plano mensal. A unidade é a OctaneBench-hora (OBh) — uma medida do trabalho GPU realizado — cobrada a uma taxa base de $0,003 por OBh. Em termos práticos, uma placa RTX 5090 corresponde a aproximadamente $5,20 por hora de renderização por placa. Paga-se pelo tempo de GPU que os frames efetivamente consomem, não por uma licença ou nível de subscrição.

Alguns detalhes que surgem habitualmente:

• O licenciamento está incluído. A licença do Redshift faz parte da taxa de renderização. O mesmo se aplica aos outros motores que executamos — não existe uma linha de licença separada a orçamentar.
• Os créditos não expiram. Carrega-se um saldo de créditos e utiliza-se nos jobs; os créditos pagos mantêm-se válidos para quando forem necessários. As novas contas também começam com $25 de crédito de teste para avaliar um job real antes de comprometer uma sequência.
• Sem níveis. Todas as contas renderizam à mesma taxa baseada em utilização. Não há plano a escolher nem funcionalidades limitadas a um nível superior.

Para estimar um job, tome o tempo que um frame demora numa placa comparável, multiplique pelo número de frames, e aplique o valor por hora de placa — distribuído pela frota, o tempo real colapsa, mas as horas GPU faturadas mantêm-se aproximadamente iguais ao trabalho total realizado. Renderizar um plano de 10 segundos a 24 fps corresponde a 240 frames; se cada frame demorar quatro minutos numa placa, isso representa cerca de 16 horas de placa, ou na ordem dos $83 à taxa prática — devolvidos numa fração desse tempo real porque os frames são executados em paralelo.

Exemplo de cálculo de custo para um plano de 240 frames: as horas de placa faturadas são iguais numa única placa GPU e numa render farm de 24 placas, mas o tempo real da render farm é muito mais curto

Escolher o Redshift, ou outro motor, para o trabalho

O Redshift é uma boa escolha quando se pretende velocidade GPU com a controlabilidade de um renderer biased, e quando a aplicação host é uma das quatro mencionadas. Não é a única opção, e parte de escolher bem é saber onde se posiciona relativamente às alternativas.

• Face ao Arnold, a troca é entre a velocidade e interatividade GPU biased do Redshift e a reputação do Arnold para saída unbiased e fisicamente fundamentada, em CPU e GPU. Comparamos os dois para trabalho em render farm em Arnold vs. Redshift numa render farm.
• Face ao Octane, ambos são renderers GPU com filosofias de shading diferentes e suporte a diferentes aplicações host. A nossa comparação Octane vs. Redshift detalha como diferem na prática.

Uma render farm não limita a um único motor — o mesmo modelo de upload-e-renderização aplica-se aos outros motores que executamos — pelo que a escolha do motor pode permanecer uma decisão criativa e de pipeline, e não de alojamento.

O fluxo de trabalho: upload, renderização e download

Enviar uma cena Redshift para a render farm segue os mesmos três passos, independentemente da aplicação host.

Upload. Empacote a cena com os seus recursos — texturas, proxies, caches e referências. O upload por browser não tem limite de tamanho definido, embora se sugira manter uploads individuais abaixo de cerca de 300 GB; para volumes maiores, SFTP ou a aplicação cliente oferecem uma transferência retomável e paralela. Os formatos de arquivo suportados são tar, tar.gz e 7z; .zip não é suportado, pelo que deve reempacotar ou transferir os ficheiros sem arquivo se for a única opção disponível. A causa mais comum de um job GPU bloqueado é um caminho de recurso que resolvia na estação de trabalho mas não após a transferência dos ficheiros, pelo que é importante recolher ou relincar referências externas antes do upload.

Renderização. Submeta o job e os frames são distribuídos pela frota GPU. Como os jobs de Redshift são exclusivamente GPU aqui, cada frame é processado num RTX 5090 com os seus 32 GB de VRAM, e o out-of-core cobre as cenas que necessitem de mais.

Download. Os frames concluídos ficam disponíveis para download via browser, SFTP ou automaticamente através da aplicação cliente. O resultado é mantido durante 45 dias após a conclusão de um job, após o qual é eliminado — por isso, deve fazer o download rapidamente ou configurar o download automático da aplicação cliente para o armazenamento local.

Uma lista de verificação antes de enviar um job de Redshift

Percorrer esta lista demora apenas alguns minutos e elimina quase todos os motivos evitáveis pelos quais um job pode não ser devolvido corretamente.

FAQ

Q: A render farm renderiza o Redshift em GPU ou em CPU? A: Exclusivamente em GPU. Os jobs de Redshift são executados numa frota dedicada de NVIDIA RTX 5090 com 32 GB de VRAM por placa. O Redshift adicionou um modo CPU na versão 3.5, mas na nossa render farm não existe percurso de renderização CPU para o Redshift — se uma cena tiver sido otimizada para o backend CPU, deve ser validada com saída GPU primeiro.

Q: Em que aplicações é possível renderizar com Redshift? A: Cinema 4D, Maya, 3ds Max e Houdini. O motor é o mesmo nas quatro; apenas o plugin de ligação da aplicação host e a exportação da cena diferem. A licença do Redshift está incluída na taxa de renderização em todos os casos.

Q: O que acontece se a cena for maior do que 32 GB de VRAM? A: O Redshift utiliza a tecnologia out-of-core para paginar texturas e geometria a partir da memória do sistema quando uma cena excede a VRAM disponível. A cena continua a ser renderizada em GPU, com algum custo de desempenho. Reduzir os tamanhos de textura e utilizar proxies mantém mais da cena residente em VRAM e agiliza o processo.

Q: É necessária uma licença Redshift própria? A: Não. A licença do Redshift está incluída no valor pago pela renderização. Enquanto parceiro oficial Maxon, licenciamos o Redshift para utilização de renderização na render farm, pelo que está disponível em todas as aplicações suportadas sem nada a ativar da parte do utilizador.

Q: Qual é o preço da renderização com Redshift? A: A renderização GPU é faturada por utilização a uma taxa base de $0,003 por OctaneBench-hora, o que corresponde a aproximadamente $5,20 por hora de placa RTX 5090. As licenças estão incluídas, os créditos não expiram, e as novas contas começam com $25 de crédito de teste para avaliar um job real.

Q: Como se envia a cena e os recursos para a render farm? A: Faz-se upload da cena empacotada via browser (sem limite de tamanho definido; sugerimos menos de cerca de 300 GB por upload), ou utiliza-se SFTP ou a aplicação cliente para transferências maiores ou retomáveis. Utilize arquivos tar, tar.gz ou 7z — .zip não é suportado — e recolha ou relinque os recursos externos antes do upload para que os caminhos se resolvam na render farm.

Q: Durante quanto tempo são mantidos os frames renderizados? A: O resultado é mantido durante 45 dias após a conclusão de um job, sendo depois eliminado automaticamente. Faça o download dos frames via browser, SFTP ou o download automático da aplicação cliente antes desse prazo, ou configure o download automático para manter uma cópia local.