Render Farm na Nuvem para Nuke: Renderizar Composições à Escala em 2026

Renderização de composições Nuke numa render farm na nuvem

A composição é a última etapa de um plano de efeitos visuais. Quando uma sequência chega ao Nuke, as renderizações 3D estão concluídas, as plates estão gradadas e o artista está a montar a imagem final — merges, keys, deep holdouts, trabalho de lente, granulado. O problema é que esta "imagem final" raramente é barata de gravar. Uma sequência de 200 frames em 4K com uma pilha de inputs EXR multicanal e alguns nós elegíveis para GPU pode bloquear uma estação de trabalho durante horas, e o artista não pode continuar a trabalhar enquanto renderiza. É exatamente este tipo de trabalho que uma render farm na nuvem existe para absorver.

Na Super Renders Farm, corremos NukeX em toda a nossa frota de renderização e, ao longo dos anos, observámos os mesmos poucos detalhes a decidir se uma composição Nuke renderiza corretamente numa farm ou fica bloqueada a meio de uma sequência. Quase nunca é a matemática de composição que falha. É um gizmo em falta, uma configuração OCIO que não corresponde, um caminho Windows absoluto que não significa nada num worker Linux, ou um equívoco sobre qual edição do Nuke pode sequer renderizar fora da máquina local. Este guia aborda como a renderização de composições Nuke se distribui por uma farm, o panorama de edições e licenciamento que é necessário compreender antes de submeter, onde a aceleração GPU realmente ajuda (e onde não ajuda), e como preparar uma composição para que nada falte. O mesmo raciocínio operacional aplica-se a workflows mais amplos de VFX e visualização de produtos, mas o Nuke tem os seus próprios problemas específicos, e é nesses que nos vamos focar.

Porque uma composição Nuke é paralela por frame, não por tile

Para compreender como o Nuke se distribui por uma farm, é útil compará-lo com um renderizador 3D. Um path tracer como V-Ray ou Arnold pode dividir um único frame em buckets ou tiles e atribuir cada região a uma thread diferente — ou, com renderização distribuída, a uma máquina diferente. Os pixels no canto superior esquerdo não dependem dos pixels no canto inferior direito, pelo que o frame pode ser dividido espacialmente.

Uma composição 2D funciona de forma diferente. O valor de qualquer pixel no frame N depende apenas dos inputs desse frame a correr pela árvore de nós. Cada frame é completamente autónomo, o que torna uma composição Nuke embaraçosamente paralela por frame: é possível renderizar o frame 1 numa máquina e o frame 200 noutra sem qualquer coordenação entre elas. O que o Nuke não faz é dividir um frame em tiles espaciais distribuídos por máquinas separadas — um nó Write renderiza um frame completo num único processo. Dentro de uma máquina, o Nuke paraleliza entre threads CPU e utiliza um motor de scanline/região, mas entre máquinas a unidade de distribuição é o frame.

Este facto único determina tudo sobre a renderização em farm para Nuke. O gestor de renderização não subdivide imagens; subdivide o intervalo de frames. Uma sequência de 1.000 frames torna-se um conjunto de "blocos" de intervalo de frames mais pequenos, cada bloco é atribuído a um worker, e cada worker lança a sua própria renderização Nuke headless para a sua fatia. O diagrama abaixo ilustra esta estrutura.

Como os frames são independentes, o rendimento escala próximo de linearmente com o número de workers disponíveis para o trabalho — que é precisamente a razão pela qual renderizar uma longa sequência de composição na nuvem vale a pena.

A renderização headless: como o Nuke corre num worker

Numa farm não existe interface gráfica. Cada worker corre o Nuke em modo terminal (batch), que renderiza todos os nós Write ativos para um determinado intervalo de frames e depois sai. O comando base tem este aspeto:

nuke -x -F 1-50 comp.nk

-x coloca o Nuke em modo de execução. -F define o intervalo de frames e aceita frames individuais (-F 7), intervalos inclusivos (-F 1-50) e intervalos com passo (-F 1-100x2 renderiza cada segundo frame). É possível passar vários argumentos -F num único comando para intervalos não contíguos. Algumas flags adicionais são relevantes quando se passa de uma única composição para sequências em produção:

Uma renderização iniciada desta forma solicita por defeito uma licença de renderização em vez de uma licença interativa — mais sobre isso na secção seguinte. O Nuke também devolve códigos de saída úteis que um gestor de renderização lê para marcar uma tarefa como bem-sucedida, falhada ou a necessitar de nova tentativa: 0 é sucesso, 1 é um erro de renderização e 100 assinala uma falha de licenciamento. Numa farm gerida, raramente se escrevem estes comandos manualmente; as ferramentas de submissão constroem-nos automaticamente. Mas saber o que corre por baixo explica a maioria dos comportamentos que se veem num log de renderização.

Existe mais um mecanismo de distribuição que vale a pena mencionar para não confundir com a renderização em farm: o Frame Server interno do Nuke. O Frame Server lança múltiplos processos de renderização em segundo plano para acelerar uma única renderização — útil numa estação de trabalho sobrecarregada ou num pequeno grupo de máquinas auxiliares. Trata-se de uma ferramenta diferente da distribuição de intervalos de frames à escala de farm, que é o que se pretende quando uma sequência completa precisa de estar pronta durante a noite em vez de ao longo de um fim de semana.

Edições e licenciamento do Nuke para renderização em farm

Esta é a parte que gera mais confusão, porque "Nuke" é uma família, não um produto único, e as edições não se comportam da mesma forma numa farm.

Esta tabela descreve a família Nuke em geral face aos requisitos de qualquer render farm — não especificamente da nossa frota; na nossa própria farm, a aplicação do lado da renderização é NukeX, conforme o resto deste guia descreve. Dois aspetos merecem destaque nesta tabela.

Em primeiro lugar, o Nuke Indie não pode renderizar numa farm de todo. A edição Indie da Foundry foi criada para artistas individuais abaixo de um limite de receita, e os seus termos excluem explicitamente render farms externas de terceiros, serviços de renderização na nuvem e renderização remota com Frame Server. O Indie também guarda em formatos de script encriptados que o parser comercial não consegue ler. Por isso, se utiliza Indie e tem estado a questionar-se sobre o motivo pelo qual a submissão para farm não funciona, não é um problema de configuração — é uma fronteira de licenciamento. A renderização em farm requer as edições Commercial, NukeX ou Nuke Studio.

Em segundo lugar, numa farm a renderização é feita com licenças de renderização, não com licenças interativas. Uma licença de renderização é um Nuke headless e sem interface gráfica que existe especificamente para renderizar — quando se lança uma renderização em terminal, o Nuke solicita uma por defeito. As licenças de renderização são independentes das licenças interativas usadas pelos artistas, o que permite a um estúdio colocar uma composição em cinquenta máquinas sem comprar cinquenta licenças interativas completas do Nuke. Um detalhe útil para pipelines mistos: uma licença de renderização pode renderizar quaisquer nós criados na edição NukeX ou inferior, pelo que um nó de renderização equipado com NukeX renderiza sem problemas um script construído pelo artista em Nuke base. NukeX é um superconjunto do Nuke — adiciona nós, não remove a capacidade de ler os nós padrão. A restrição inversa é a única real: o Nuke base não consegue avaliar nós exclusivos do NukeX.

Quanto ao modelo de licenciamento, a Foundry migrou a família Nuke para subscrição anual no início de 2023, com licenciamento baseado em login que pode funcionar online ou offline; também existem opções perpétuas e de aluguer. A mecânica difere de estúdio para estúdio, o que é o ponto central da secção seguinte.

Como o licenciamento funciona na nossa farm

A Super Renders Farm não é parceira da Foundry, e não afirmamos sê-lo — as nossas parcerias de fornecedores verificadas são com os fabricantes de motores de renderização, não com fornecedores de software de composição. O que a nossa farm corre é um modelo de utilização apenas de renderização, a mesma abordagem que usamos para as outras aplicações da frota que não estão ligadas a uma parceria.

Na prática, isto significa que não é necessário provisionar ou gerir uma licença de renderização por worker. A frota de workers corre NukeX, com versão fixada num build suportado, e o compositor lança headless para renderizar o script. Como a SuperRenders é uma render farm totalmente gerida, não é necessário aceder remotamente às máquinas, instalar o Nuke ou configurar manualmente servidores de licenças — o ambiente do lado da renderização já está em funcionamento quando o trabalho chega. Esta é a diferença operacional entre uma farm gerida e uma configuração IaaS de auto-configuração, onde instalar o Nuke e o seu licenciamento é da responsabilidade de quem gere cada instância.

Em termos de custo, a renderização de composições é faturada da mesma forma que o restante trabalho CPU — por GHz-hora de computação utilizada, sem mínimos de aluguer de máquina e com créditos de renderização que não expiram. As novas contas começam com um crédito de $25, que é suficiente para renderizar uma sequência de teste curta do início ao fim e confirmar que a composição se comporta da mesma forma na farm que na estação de trabalho local antes de submeter um trabalho completo. As tarifas atuais e uma calculadora de custos estão disponíveis na página de preços.

Distribuição do intervalo de frames na prática

Saber que uma farm divide o intervalo de frames é uma coisa; obter renderizações limpas e previsíveis é outra. Algumas práticas surgem repetidamente do nosso lado de suporte.

O tamanho do bloco é uma troca. Blocos pequenos (poucos frames cada) distribuem o trabalho por mais máquinas e recuperam mais rapidamente de uma tarefa falhada, mas pagam o custo de arranque do Nuke — carregamento do script, obtenção da licença, inicialização de plugins — com mais frequência. Blocos grandes amortizam o arranque, mas deixam trabalhadores lentos quando uma máquina lenta retém a cauda de uma sequência. Para a maioria das composições, um bloco moderado que mantenha cada worker ocupado durante vários minutos é um valor predefinido sensato; composições muito pesadas por frame (deep, 4K ou mais, muitos nós GPU) tendem para blocos mais pequenos.

Atenção às dependências de nós Write. Se o script tiver um Read a jusante que depende de um ficheiro produzido por um Write anterior — uma pré-composição gravada em disco, por exemplo — esses Writes devem ser executados por ordem. É para isso que serve --sro. Sem ele, um worker pode tentar o Write dependente antes de o seu input existir, resultando em erros de frames em falta que parecem aleatórios porque dependem do timing das máquinas.

Planear para o frame problemático ocasional. Um único input ilegível ou uma falha transitória de armazenamento não deve destruir um bloco inteiro. --cont permite que uma renderização continue após um frame falhado, para que seja possível recolocar apenas as lacunas na fila em vez de voltar a renderizar tudo. Combinar isso com a repetição automática de tarefas de um gestor de renderização mantém as sequências longas a avançar sem supervisão constante.

O benefício de fazer isto corretamente é simples: uma sequência que ocuparia a máquina de um artista durante um dia inteiro fica pronta no tempo que o bloco individual mais lento demora a renderizar, porque todos os outros blocos renderizam em paralelo.

GPU vs CPU para Nuke na farm

Aqui está um ponto que surpreende quem vem da renderização 3D com prioridade em GPU: o Nuke é fundamentalmente uma aplicação CPU. A vasta maioria das operações de composição — merges, correções de cor, transformações, keys, a maioria dos filtros — corre na CPU. A aceleração GPU no Nuke é opcional para um subconjunto específico de nós, exposta através de um controlo "usar GPU se disponível"; os nós sem esse controlo são exclusivos de CPU.

Árvore de nós Nuke conceptual mostrando a maioria dos nós de composição a correr na CPU com alguns nós com aceleração GPU destacados

O que isto significa para o hardware é que uma composição dominada por grades, merges e transformações beneficia pouco de uma GPU — precisa de núcleos CPU e memória. Uma composição que se apoia num Kronos retime pesado, um ZDefocus grande, Denoise ou trabalho personalizado com BlinkScript pode acelerar substancialmente com uma GPU. A maioria das composições de produção situa-se algures entre os dois extremos, razão pela qual priorizamos a capacidade CPU e tratamos a GPU como um acelerador para os nós que efetivamente a utilizam.

A nossa frota reflete isso. A maior parte do trabalho de composição corre em máquinas CPU construídas sobre processadores Intel Xeon E5-2699 V4 duplos com 96–256 GB de RAM cada — coletivamente mais de 20.000 núcleos CPU — e essa margem de memória é a parte que as pessoas subestimam. A composição deep e plates EXR multicanal de alta resolução exigem muita memória; um único frame deep em 4K pode conter muitas amostras por pixel, e ficar sem RAM a meio de um frame é uma causa muito mais comum de falhas de renderização em farm do que a velocidade CPU bruta. Para as composições que genuinamente beneficiam de nós GPU, também operamos uma render farm GPU na nuvem dedicada com placas NVIDIA RTX 5090 com 32 GB de VRAM cada. Para ver o desempenho desse nível GPU em cargas de trabalho mais pesadas, os nossos benchmarks de renderização na nuvem RTX 5090 cobrem isso em detalhe. A orientação honesta para o Nuke especificamente, porém, é dimensionar adequadamente para a composição: não pagar por tempo GPU que um script dominado por merges nunca vai utilizar.

Gestão de ficheiros e assets: a parte que realmente falha

Se uma renderização Nuke falha numa farm, a probabilidade esmagadora é que seja um problema de dependências, não um problema de composição. Um script de composição é principalmente um conjunto de referências — para footage, para gizmos, para uma configuração de cor — e cada uma dessas referências tem de ser resolvida de forma idêntica num worker que não é a máquina do artista.

Diagrama de um script de composição Nuke e as dependências que devem acompanhá-lo para uma render farm: footage, gizmos, configuração OCIO, fontes e LUTs

Alguns destes merecem uma análise mais aprofundada. Os caminhos são o clássico: um artista no Windows a referenciar Z:\project\plates\ produzirá um script que não significa nada para um worker Linux. Caminhos de projeto consistentes e acessíveis pela rede — ou um gestor de renderização que reescreve os caminhos antes de enviar para a farm — resolvem este problema. Os gizmos e OFX personalizados devem existir no nó de renderização; o hábito mais seguro antes de submeter é converter quaisquer gizmos personalizados em Groups para que sejam integrados no script sem dependência externa.

O desvio de configuração OCIO é o mais subtil e merece atenção, porque produz uma renderização que tem sucesso mas parece errada. A gestão de cor do Nuke é impulsionada por uma configuração OpenColorIO; se a farm resolver uma configuração diferente da que o artista usou — um caminho de ficheiro diferente, uma configuração personalizada que nunca foi implementada, ou uma variável de ambiente que aponta para outro sítio — as transformações de cor divergem e a renderização da farm não vai corresponder ao visualizador que o artista aprovou. A solução é disciplina: fixar o projeto a uma configuração específica e implementada e garantir que o ambiente de renderização usa exatamente essa. Uma farm gerida mantém as configurações OCIO padrão e incluídas do Nuke implementadas por defeito, mas a configuração OCIO personalizada de um estúdio ainda precisa de acompanhar o trabalho.

Do lado da saída, as composições Nuke leem e escrevem tipicamente EXR multicanal. Um único ficheiro OpenEXR pode conter muitos canais — um passe de beleza mais difuso, especular, AOVs de iluminação, um passe de profundidade Z e mattes de cryptomatte — todos lidos através de um único nó Read e separados com nós Shuffle para trabalho por passe na composição. Para composição deep, o Nuke lê e escreve deep EXR via DeepRead e DeepWrite, armazenando múltiplas amostras de profundidade por pixel para resolver problemas de holdout e bordo sem voltar a renderizar em 3D. A maioria destes dados é armazenada como half-float de 16 bits, o padrão para plates lineares HDR, com float completo de 32 bits reservado para passes de dados como posição no mundo ou vetores de movimento que necessitam de precisão total. Nada disto é exótico — mas cada um desses canais representa mais dados para mover e mais memória para manter, o que remete diretamente para a razão pela qual a RAM e o débito de armazenamento importam tanto quanto o número de núcleos para a renderização de composições.

Lista de verificação pré-submissão para composições Nuke

Antes de enviar uma composição para qualquer farm — a nossa ou a fila interna do estúdio — uma revisão rápida destes pontos previne a grande maioria das renderizações falhadas:

• Caminhos: todos os nós Read e Write usam caminhos acessíveis pela rede e independentes do sistema operativo, não letras de unidade locais.
• Gizmos: os gizmos personalizados são convertidos em Groups (integrados) ou confirmados como instalados nos nós de renderização.
• Cor: a configuração OCIO é a que a farm vai resolver; qualquer configuração personalizada acompanha o trabalho.
• Fontes e LUTs: cada fonte usada por um nó Text e cada ficheiro .cube/LUT referenciado está presente.
• Versão: o build de renderização corresponde ao build em que a composição foi criada.
• Edição: o script é do Nuke Commercial, NukeX ou Nuke Studio — não Indie, que não pode renderizar em farm.
• Ordem de renderização: se um Read a jusante depende de um Write anterior, renderizar com --sro.
• Testar em pequeno: renderizar alguns frames primeiro e comparar com a saída local do artista antes de submeter o intervalo completo.

Este último ponto é um seguro barato. Uma renderização de teste de cinco frames deteta uma incompatibilidade de caminho, cor ou versão ao custo de alguns minutos — muito melhor do que descobri-la 800 frames dentro de um trabalho noturno.

Onde a renderização Nuke se encaixa num pipeline mais amplo

A saída final em EXR é o endpoint mais comum de uma composição Nuke, mas não é o único. Se o plano segue para um motor em tempo real em vez de uma sequência renderizada plana — produção virtual ou revisão no motor — as questões de integração são diferentes, e cobrimos esse caminho separadamente no nosso guia de pipeline Nuke para Unreal Engine. A distinção é clara: este artigo é sobre renderizar frames de composição à escala numa farm, enquanto o caminho Unreal é sobre mover trabalho Nuke para um contexto em tempo real. Para quem ainda está a mapear como a renderização distribuída funciona em geral, o nosso guia sobre o que é uma render farm é um bom ponto de partida.

Para uma referência autoritativa sobre a mecânica aqui descrita, a documentação própria da Foundry sobre operações por linha de comandos e render farms e as suas FAQs de licenciamento da família Nuke são as fontes canónicas, e os sites dos projetos OpenEXR e OpenColorIO documentam os padrões de ficheiros e cor dos quais uma composição depende.

FAQ

Q: Posso renderizar Nuke numa render farm na nuvem com uma licença Nuke Indie? A: Não. A edição Nuke Indie da Foundry explicitamente não suporta render farms externas de terceiros, serviços de renderização na nuvem ou renderização remota com Frame Server, e guarda em formatos de script encriptados que o parser comercial não consegue ler. A renderização em farm requer as edições Commercial Nuke, NukeX ou Nuke Studio.

Q: Preciso de uma licença de renderização Nuke separada para usar uma render farm na nuvem? A: Numa farm, as renderizações correm headless usando licenças de renderização em vez de licenças interativas — é assim que um estúdio pode renderizar em muitas máquinas sem comprar uma licença interativa completa para cada uma. Na nossa farm, não é necessário provisionar estas licenças; a frota de workers corre NukeX num modelo de utilização apenas de renderização, pelo que o licenciamento do lado da renderização é gerido pela farm.

Q: A renderização Nuke é mais rápida em GPU ou CPU? A: Para a maioria das composições, CPU. O Nuke é fundamentalmente uma aplicação CPU; apenas um subconjunto específico de nós — Kronos, Denoise, ZDefocus, Convolve, BlinkScript e ferramentas de machine learning como CopyCat — têm aceleração GPU. Uma composição construída principalmente com merges, grades e transformações precisa de núcleos CPU e RAM, enquanto uma composição que se apoia nesses nós pesados beneficia de uma GPU.

Q: Como é que uma render farm divide uma composição Nuke pelas máquinas? A: Por intervalo de frames, não por região de imagem. Como cada frame de uma composição é independente, o gestor de renderização divide o intervalo de frames total em blocos e atribui cada bloco a um worker, que renderiza a sua fatia headless. O rendimento escala próximo de linearmente com o número de workers no trabalho.

Q: Porque é que a minha composição Nuke renderiza com cores erradas na farm? A: A causa mais comum é o desvio de configuração OCIO — a farm resolveu uma configuração OpenColorIO diferente da que o artista usou, seja através de um caminho de ficheiro diferente, de uma variável de ambiente ou de uma configuração personalizada que nunca foi implementada nos nós de renderização. Fixar o projeto a uma configuração específica e garantir que é exatamente essa que o ambiente de renderização usa resolve o problema.

Q: Que ficheiros preciso de enviar com um script Nuke para renderizar remotamente? A: O script mais tudo o que referencia: footage e sequências de imagens, quaisquer gizmos ou plugins OFX personalizados (ou integrá-los em Groups), a configuração de cor OCIO, fontes usadas por nós Text e quaisquer ficheiros LUT autónomos. O build de renderização também deve corresponder à versão em que a composição foi criada.

Q: O NukeX renderiza uma composição Nuke padrão? A: Sim. O NukeX é um superconjunto do Nuke base — adiciona nós em vez de remover a capacidade de ler os nós padrão — pelo que um nó de renderização NukeX renderiza scripts construídos em Nuke base sem problemas. Uma licença de renderização pode renderizar qualquer nó criado na edição NukeX ou inferior. A única restrição é o inverso: o Nuke base não consegue avaliar nós exclusivos do NukeX.

Q: Quanto custa renderizar composições Nuke na vossa farm? A: A renderização de composições é faturada por GHz-hora de computação CPU utilizada, sem mínimos de aluguer de máquina e com créditos de renderização que não expiram. As novas contas recebem um crédito de $25, que cobre uma sequência de teste curta do início ao fim. As tarifas atuais e uma calculadora de custos estão na nossa página de preços.