O Que É uma GPU Render Farm? Como Funciona e Quando Usar

Introdução

Uma GPU render farm é um conjunto de computadores construídos em torno de placas gráficas de nível profissional, ligadas entre si por um agendador de tarefas e armazenamento partilhado, de modo a que muitos frames sejam renderizados em paralelo. Na Super Renders Farm, operamos uma ao lado de uma frota CPU muito maior, e as questões que os artistas nos colocam são consistentes: como é que isto difere da render farm CPU, como difere de ter duas placas extra na estação de trabalho, e quanto custa realmente uma hora de placa?

Este guia responde a essas questões do lado do operador. Aborda o que é realmente uma GPU render farm, como as peças se articulam — nós, agendador, sincronização de recursos, entrega de output — onde uma render farm GPU se justifica verdadeiramente face a uma render farm CPU ou a uma estação de trabalho multi-GPU local e onde não se justifica, quais os motores de renderização adequados a uma render farm GPU, e como funciona a matemática da faturação antes de comprometer um prazo. Foi escrito para artistas e estúdios que pretendem compreender o mecanismo antes de avaliar qualquer serviço específico, incluindo o nosso.

O Que É Realmente uma GPU Render Farm

Retirando a linguagem de produto, uma GPU render farm são três sistemas a trabalhar em conjunto:

• Nós de renderização. Máquinas cuja capacidade de renderização provém de uma ou mais GPUs de nível profissional em vez de núcleos de CPU. A capacidade de processamento da placa e a sua capacidade de VRAM definem o que cada nó consegue executar.
• Um agendador de tarefas. Software que aceita tarefas submetidas, divide-as em tarefas por frame, atribui tarefas aos nós disponíveis e adequados, repete falhas e reporta o progresso. Todas as render farms têm um; na maior parte das vezes só se nota quando é mau.
• Armazenamento partilhado e sincronização de recursos. Uma camada de ficheiros comum que contém a cena, todas as texturas e caches referenciadas, e o output renderizado — para que qualquer nó possa processar qualquer frame sem envolver a estação de trabalho do utilizador.

O que torna a render farm uma render farm GPU não é uma preferência de hardware. São os motores de renderização que serve: Redshift, Octane, V-Ray GPU e Cycles em GPU no Blender, todos executam o seu path tracing na placa gráfica, pelo que a render farm que os serve tem de ser construída em torno de placas em vez de núcleos.

O mesmo hardware chega ao utilizador embrulhado em dois modelos de serviço muito diferentes. Uma GPU render farm gerida executa um fluxo de trabalho de carregamento-renderização-transferência: empacota-se uma cena, o pipeline da render farm sincroniza-a, renderiza-a com licenças de motor agrupadas, e devolve os frames — sem sessão de ambiente de trabalho remoto, sem instalação de software do lado do utilizador. O IaaS de GPU, pelo contrário, aluga máquinas virtuais GPU brutas: acede-se remotamente, instala-se o DCC e o motor, fornece-se as licenças e opera-se as máquinas por conta própria. Ambas são GPU render farms no sentido de hardware; operacionalmente são produtos diferentes com modos de falha diferentes.

Este artigo mantém-se nos conceitos. Para quem esteja a meio de uma avaliação e pretenda especificações de serviço — especificações dos nós, cobertura de motores, tarifas atuais — a página GPU cloud render farm apresenta esses detalhes.

Como Funciona uma GPU Render Farm: Nós, Agendador e Sincronização de Recursos

Arquitetura de uma GPU render farm — uma estação de trabalho de artista a carregar uma cena empacotada através da sincronização de recursos para armazenamento partilhado, um agendador de tarefas a distribuir frames por uma frota de nós de renderização GPU, e frames acabados a fluir de volta para armazenamento de output para transferência.

Uma tarefa de renderização passa por quatro fases, e a maior parte do que pode correr mal ocorre nas transições entre elas.

Empacotamento e carregamento. O ficheiro de cena é a parte pequena. Uma cena de produção referencia texturas, caches de simulação, proxies e dados de plugins dispersos pelas drives do projeto, e cada uma dessas dependências tem de viajar com ela. A falha mais comum na primeira tarefa que vemos é um recurso referenciado a partir de um caminho local que existe na máquina do artista e em mais nenhum lado — o frame renderiza, mas uma textura não resolve para nada. Uma boa ferramenta de render farm recolhe dependências aquando da submissão e valida os caminhos antes de qualquer nó gastar tempo na tarefa. Na Super Renders Farm, a sincronização de recursos é também incremental: na segunda submissão, apenas os ficheiros alterados são transferidos, o que representa a diferença entre um novo carregamento de 40 minutos e um de 40 segundos quando se itera com um prazo a aproximar-se.

Fila e despacho. O agendador divide uma animação em tarefas por frame (ou por conjunto de frames) e atribui-as por disponibilidade de nó, adequação de VRAM e correspondência da versão do motor. Volta a colocar em fila os frames de um nó que falhou, isola um nó que continua a falhar, e mantém o resto da frota ocupada. Esta é a parte da render farm que se aluga mas nunca se vê — e é a maior razão pela qual uma render farm se comporta de forma diferente de um conjunto de VMs alugadas.

Execução no nó. Cada nó carrega as versões exatas do motor e dos plugins às quais a tarefa foi associada, obtém uma licença de renderização do inventário agrupado da render farm, carrega os dados da cena para a memória GPU, renderiza os frames atribuídos e escreve os outputs mais os registos de volta para o armazenamento partilhado. Os watchdogs detetam frames que ficam bloqueados em vez de falharem, o que é relevante nos motores GPU onde um overflow de memória pode bloquear um processo em vez de o terminar.

Output e entrega. Os frames acabados ficam no armazenamento de output e chegam ao utilizador através da interface web, SFTP ou de um cliente desktop. Os outputs não ficam lá para sempre — na nossa render farm o período de retenção é de 45 dias a contar da conclusão da tarefa — pelo que a entrega faz parte do pipeline, não é uma reflexão tardia.

GPU Render Farm vs CPU Render Farm

Os dois tipos de render farm distinguem-se primeiro pela compatibilidade com os motores e depois pelo hardware.

O motor decide, não a render farm. Se o projeto renderiza em Redshift ou Octane, é uma tarefa GPU; se renderiza em Corona ou no modo CPU do V-Ray, é uma tarefa CPU. Escolhe-se o motor por razões criativas e de pipeline, e o motor escolhe o tipo de render farm. Para um tratamento mais aprofundado ao nível do motor dessa escolha, existe um guia comparativo de renderização GPU vs CPU separado — este artigo trata do aspeto que tem a render farm em torno do motor.

Os modelos de memória diferem em tipo. Um nó GPU vive dentro da VRAM da sua placa — 32 GB nas placas RTX 5090 da nossa frota GPU. Um nó CPU vive dentro da RAM do sistema, e os nossos nós CPU de duplo Xeon têm entre 96 e 256 GB. As funcionalidades out-of-core nos motores GPU modernos podem descarregar alguns dados de textura e geometria para a memória do sistema com um custo de desempenho, mas a VRAM continua a ser o teto prático de complexidade de cena para trabalho GPU. Cenas de archviz muito pesadas com dispersão massiva de vegetação, ou cenas VFX com volumetria densa, ficam frequentemente nas render farms CPU precisamente por esta razão.

As afirmações de velocidade precisam de contexto. Em cenas que cabem confortavelmente na VRAM, um motor GPU entrega normalmente um frame em menos tempo de relógio por nó do que um motor CPU renderiza um frame comparável. Trata-se de uma afirmação por nó, não de um veredicto sobre render farms: uma frota CPU com mais de 20.000 núcleos entrega rendimento pela largura paralela pura, e a economia por frame depende da taxa por unidade de trabalho, não de qual o silício em voga. Ambos os modelos têm preços ajustados ao trabalho que realizam.

A mistura de tarefas é mais CPU do que o clima de marketing sugere. Cerca de 70 por cento das tarefas na nossa render farm ainda renderizam em motores CPU — V-Ray CPU, Corona, Arnold — com trabalho GPU em Redshift, Octane e V-Ray GPU a constituir o restante em crescimento. Uma GPU render farm não é a sucessora de uma render farm CPU; é a irmã que serve uma família diferente de motores.

GPU Render Farm vs uma Estação de Trabalho Multi-GPU Local

A comparação mais interessante para muitos artistas não é contra as render farms CPU, mas contra a máquina que têm sob a secretária. A versão honesta tem vantagens de ambos os lados.

Onde as placas locais ganham. Lookdev interativo. Quando se está a ajustar materiais e iluminação, a latência de ida e volta importa mais do que o rendimento, e uma placa na própria máquina dá feedback em segundos. Nenhuma render farm muda isso, e um operador de render farm que afirme o contrário está a vender algo. O uso local também ganha quando a utilização é genuinamente constante — hardware que renderiza frames de produção a maior parte das horas da maior parte das semanas amortiza o seu custo de capital de uma forma que hardware de uso ocasional nunca consegue.

Onde a render farm ganha. Largura a pedido. Uma estação de trabalho tem duas, talvez quatro placas; uma render farm aluga a largura paralela de uma dúzia de placas para um único fim de semana sem as ter durante os três anos entre utilizações. A renderização de animação de frames finais é paralelizável de forma óbvia — 300 frames distribuídos por muitas placas sem estado partilhado — o que é precisamente a forma para a qual uma render farm foi construída. Existe também a contenção: frames a renderizar na estação de trabalho bloqueiam as mesmas placas necessárias para o lookdev da próxima cena, pelo que as semanas de prazo se transformam em renderizar de noite e trabalhar nos intervalos. E existe a física pouco glamorosa de energia, calor e ruído que caixas multi-GPU impõem a uma pequena sala de estúdio.

O padrão que observamos operacionalmente. Os estúdios tendem a chegar a um modelo híbrido: placas locais para iteração, render farm para frames finais e para as duas semanas por ano em que tudo tem prazo simultâneo. Tivemos uma pequena equipa de motion design a juntar-se após uma semana de entrega em que duas placas locais funcionaram continuamente e a animação ainda não cumpriu o prazo; a mesma tarefa distribuída pelos nós da render farm terminou durante a noite. A lição não é que o hardware era inadequado — é que a capacidade de pico é uma mercadoria diferente da capacidade própria. Publicámos uma análise de custos de um artista solo com uma estação de trabalho RTX 5090 vs renderização na nuvem que percorre a matemática do lado da propriedade.

Render Farm GPU, CPU, IaaS GPU ou Estação de Trabalho Local: Comparação

As quatro opções respondem a problemas diferentes. A tabela abaixo é a comparação que fazemos com novos clientes, com os compromissos intactos — incluindo as linhas onde uma render farm gerida não é a resposta certa. Para saber como a categoria de render farm na nuvem se enquadra no panorama da renderização, consulte o que é uma cloud render farm.

Quais os Motores de Renderização Adequados a uma GPU Render Farm

Uma render farm GPU ganha o nome pelos motores que executa, pelo que a identidade do motor é o filtro correto para toda a categoria.

Três notas operacionais acompanham essa tabela. Primeiro, a correspondência de versões não é negociável: um nó de render farm tem de executar as versões exatas do motor e dos plugins com as quais a cena foi criada, razão pela qual as ferramentas de submissão da render farm fixam versões por tarefa em vez de confiar na sorte. Segundo, o licenciamento faz parte da questão do motor — numa render farm gerida, as licenças de renderização para Redshift, Octane, V-Ray, Corona e Arnold estão agrupadas e incluídas na tarifa, com parcerias oficiais com a Maxon e a Chaos a suportar esse licenciamento do nosso lado. O Cycles não tem qualquer custo de licença, sendo código aberto sob a alçada do Blender. No IaaS de GPU, cada uma dessas licenças é da responsabilidade do utilizador aprovisionar por máquina.

Terceiro, a VRAM é a especificação a verificar antes de qualquer número de velocidade. Uma placa que renderiza rapidamente mas não consegue conter a cena não renderiza nada. Publicamos dados de desempenho medidos de renderização na nuvem com RTX 5090 em V-Ray GPU, Redshift e Octane precisamente porque o comportamento por motor em tamanhos reais de cena diz mais do que números de pico sintéticos.

Quanto Custa a Renderização GPU numa Render Farm

A faturação de render farms GPU tem um problema de normalização a resolver: uma GPU-hora não significa nada entre gerações de hardware mistas, a não ser que esteja ancorada a desempenho medido. A âncora comum é o OctaneBench, o benchmark público de renderização GPU da OTOY — a pontuação de um nó expressa quanto trabalho de renderização entrega realmente por hora, e a faturação mede nesse valor.

Na nossa render farm, a tarifa GPU é de $0,003 por OctaneBench-hora, o que equivale a cerca de $5,20 por GPU-hora num nó RTX 5090. Para comparação, a renderização CPU é medida a $0,004 por GHz-hora no nível de prioridade base (os níveis de prioridade vão de $0,004 a $0,016), com um servidor duplo Xeon a ficar em torno de $2 por hora de servidor. Unidades diferentes, mesmo princípio: paga-se pelo trabalho entregue, não pelo tempo em que uma máquina meramente existe.

Eis o método de estimativa que recomendamos, aplicado a um cenário concreto: uma animação Redshift de 300 frames que renderiza em teste a aproximadamente 4 minutos por frame numa única placa de classe RTX 5090. O total de cálculo é 300 × 4 = 1.200 minutos de placa, ou 20 GPU-horas, independentemente de quantas placas partilham o trabalho:

Essa tabela é a coisa mais útil a compreender sobre a economia de render farms: a uma dada tarifa, a largura paralela compra tempo de entrega, não uma fatura maior. A tarefa custa o que o trabalho custa; as placas apenas decidem se o resultado chega esta noite ou quinta-feira.

Trate os números como método, não como orçamento. Os tempos por frame variam ao longo de uma sequência, a estimativa pressupõe paralelismo por frame (uma animação, não um único still enorme), e o tempo real de frame de teste da cena é o input que importa. Renderize dois ou três frames representativos primeiro, depois multiplique — esse hábito apanha tanto surpresas de orçamento como surpresas de recursos corrompidos antes de custarem seja o que for.

Como Avaliar uma GPU Render Farm

Os critérios abaixo são os que separam as render farms na prática — são as questões que qualquer prestador deveria responder, incluindo nós:

• VRAM por placa, por escrito. O modelo da placa e a sua memória, mais dados de desempenho publicados para o motor específico do utilizador — não uma afirmação de velocidade genérica.
• Cobertura exata de versões de motor e plugin. As versões do utilizador, fixadas por tarefa, não "versões atuais suportadas".
• Gestão de licenças. Incluídas na tarifa ou por conta própria? A resposta reformula o custo horário real.
• Forma do fluxo de trabalho. Carregamento-renderização-transferência gerido, ou VMs de ambiente de trabalho remoto? Escolher o que a equipa consegue realmente operar às 23h de uma noite de prazo.
• Comportamento da sincronização de recursos na segunda submissão. Sincronização apenas dos ficheiros alterados, ou novo carregamento completo por iteração? Isso decide como a iteração se sente na prática.
• Previsibilidade de custos. Tarifas publicadas numa unidade declarada, e uma forma de estimar a partir de frames de teste antes de comprometer a sequência.
• Retenção de output e tratamento de dados. Conhecer o período (o nosso é de 45 dias) e planear a entrega no calendário.
• Suporte durante as janelas de renderização. As renderizações falham às 3h da manhã; suporte por chat ao vivo 24/7 vale mais do que uma fila de pedidos respondida em horário de escritório.

Na Super Renders Farm, operamos infraestrutura de renderização desde 2010, tanto na frota CPU como na frota GPU de RTX 5090, e o padrão que se mantém é este: as render farms que servem bem os artistas são as que publicam os seus mecanismos — tarifas, motores, VRAM, comportamento de sincronização — e permitem verificar a matemática por conta própria. Uma GPU render farm não é magia. É um agendador, um conjunto de placas muito capazes, e uma camada de sincronização, operados com cuidado para que o prazo não dependa das duas placas debaixo da secretária.

FAQ

Q: O que é uma GPU render farm? A: Uma GPU render farm é um conjunto de nós de renderização construídos em torno de placas gráficas de nível profissional, coordenados por um agendador de tarefas e armazenamento partilhado, de modo a que muitos frames sejam renderizados em paralelo para motores nativos de GPU como Redshift, Octane, V-Ray GPU e Cycles. A Super Renders Farm, por exemplo, combina uma frota GPU de RTX 5090 com um fluxo de trabalho gerido de carregamento-renderização-transferência, para que as tarefas corram sem sessões de ambiente de trabalho remoto ou configuração manual de licenças.

Q: Qual é a diferença entre uma GPU render farm e uma CPU render farm? A: O motor em que o projeto renderiza decide qual o tipo de render farm necessário: Redshift, Octane, V-Ray GPU e Cycles em GPU correm em render farms GPU, enquanto Corona, Arnold e V-Ray CPU correm em render farms CPU. A diferença de hardware decorre daí — os nós GPU são limitados pela VRAM (32 GB por placa na nossa frota) enquanto os nós CPU têm RAM de sistema muito maior, razão pela qual as cenas com muita memória ficam frequentemente nas render farms CPU.

Q: Uma GPU render farm é mais rápida do que uma estação de trabalho multi-GPU local? A: Por placa, não — um nó de render farm com a mesma placa renderiza um frame em aproximadamente o mesmo tempo que a estação de trabalho. A diferença está na largura paralela e na contenção: uma render farm pode colocar dez ou mais placas a trabalhar numa animação em simultâneo enquanto as placas locais ficam livres para lookdev, pelo que a sequência termina durante a noite em vez de consumir a estação de trabalho durante dias.

Q: É possível renderizar Blender EEVEE numa GPU render farm? A: Normalmente não — o EEVEE é o motor de rasterização em tempo real do Blender e comporta-se de forma diferente dos path tracers offline em nós de render farm sem ecrã, pelo que o suporte é variável e muitas vezes inexistente. Na nossa render farm, a renderização Blender corre apenas em Cycles; não executamos EEVEE, e recomendamos confirmar o suporte do motor com qualquer prestador antes de planear um projeto em torno disso.

Q: Como é faturada a utilização de uma GPU render farm? A: A maior parte das render farms GPU mede GPU-horas normalizadas por benchmark para que uma unidade de faturação corresponda a uma unidade de trabalho de renderização medido; o OctaneBench é a âncora pública comum. Na nossa render farm, a tarifa é de $0,003 por OctaneBench-hora — cerca de $5,20 por GPU-hora num nó RTX 5090 — e o total de uma tarefa depende das GPU-horas de trabalho, não de quantas placas a partilham.

Q: É necessário ter licenças próprias de motor de renderização para usar uma GPU render farm? A: Numa GPU render farm gerida, não — as licenças de renderização para motores como Redshift, Octane e V-Ray estão agrupadas na render farm e incluídas na tarifa, e o Cycles é código aberto sem qualquer licença. Em alugueres de IaaS de GPU, as licenças têm de ser fornecidas e geridas por máquina, o que representa uma diferença real de custo e administração que vale a pena quantificar.

Q: Quanta VRAM têm os nós de uma GPU render farm? A: Varia consoante a render farm e a geração de placas, pelo que convém verificar o modelo específico da placa em vez de aceitar uma afirmação genérica; os nossos nós GPU correm placas RTX 5090 com 32 GB de VRAM cada. A VRAM é o teto prático de complexidade de cena para renderização GPU — as funcionalidades out-of-core podem descarregar alguns dados para a memória do sistema com um custo de desempenho, mas uma cena que genuinamente excede a VRAM pertence a uma render farm CPU.

Q: É necessário acesso a ambiente de trabalho remoto para usar uma GPU render farm? A: Não numa render farm gerida — o fluxo de trabalho é carregar, renderizar, transferir: empacota-se uma cena, a render farm sincroniza e renderiza, e os frames acabados são descarregados. As sessões de ambiente de trabalho remoto são o modelo operacional dos alugueres de IaaS de GPU, onde as máquinas são administradas por conta própria, e essa distinção é a linha prática mais clara entre os dois tipos de serviço.