Custo de renderização na nuvem por frame em 2026: Guia de preços

Custo de renderização na nuvem por frame em 2026: O que um frame realmente custa

"Quanto custa a renderização na nuvem por frame?" é uma das perguntas que ouvimos com mais frequência de artistas e estúdios que transferem o primeiro projeto para fora da estação de trabalho. Parece simples, mas a resposta honesta é um intervalo — e o intervalo é amplo porque um frame não é uma unidade de trabalho, é uma unidade de resultado. Dois frames com a mesma resolução podem demorar 30 segundos ou 30 minutos, dependendo do motor, das amostras, da geometria e da iluminação.

Este guia analisa como o custo por frame se apresenta na nuvem em 2026, por que varia tanto e como os modelos de preços subjacentes funcionam na prática. A Super Renders Farm opera desde 2017, e os números abaixo provêm da combinação de projetos que vemos diariamente em archviz, motion design, VFX e animação.

Para uma análise matemática detalhada de como os render farms calculam especificamente os encargos por frame, consulte o nosso guia de custo por frame de render farm. Para uma comparação lado a lado de cinco render farms específicos, consulte a análise de custo por frame para 2026. Este artigo é o ponto de entrada conceptual que está acima de ambos — cobrindo a renderização na nuvem como categoria completa, incluindo alternativas IaaS como AWS Batch e Azure Batch.

TL;DR — Custo de renderização na nuvem por frame em 2026

O custo por frame na nuvem em 2026 situa-se tipicamente nestes intervalos:

• Still de archviz (1080p, V-Ray ou Corona): $0.03 – $0.25 por frame
• Animação de archviz (1080p, 24–30 fps): $0.08 – $0.65 por frame
• Visualização de produto (4K, GPU ou CPU): $0.15 – $1.20 por frame
• Shot de VFX / motion design: $0.50 – $3.00 por frame
• Shot de animação de longa-metragem / CG pesado: $1.00 – $5.00 por frame

Estes números cobrem apenas o custo de computação de renderização — não incluem licenciamento, preparação de assets ou edição. O custo por frame varia conforme a complexidade da cena, o motor de renderização, a resolução de saída, as definições de amostras/qualidade e o modelo de preços do fornecedor. Detalhamos cada um desses fatores abaixo e depois comparamos os render farms com plataformas de computação na nuvem de uso geral (AWS Batch, Azure Batch) para a mesma carga de trabalho.

Quanto custa a renderização na nuvem por frame?

A resposta curta é "entre três cêntimos e cinco dólares por frame, dependendo do tipo de frame que se está a renderizar". Não é uma esquiva — o intervalo reflete a diferença entre um still de archviz 1080p e um shot de animação 4K com volumétricos e motion blur.

Para tornar os intervalos concretos, aqui está a tabela de referência por frame que usamos internamente ao dimensionar novos projetos. As colunas CPU pressupõem V-Ray, Corona ou Arnold em nós dual Xeon. As colunas GPU pressupõem Redshift, Octane ou V-Ray GPU em hardware da classe RTX 5090 (32 GB VRAM).

Tipo de projeto	Resolução	CPU $/frame	GPU $/frame	Notas
Still de archviz — interior	1920×1080	$0.05 – $0.25	$0.04 – $0.18	Corona / V-Ray; 1–8 min por frame
Still de archviz — exterior com vegetação	3840×2160	$0.20 – $0.80	$0.15 – $0.55	Forest Pack, displacement
Walkthrough de animação de archviz	1920×1080	$0.08 – $0.40	$0.06 – $0.28	720–4500 frames típico
Visualização de produto	3840×2160	$0.25 – $1.20	$0.15 – $0.90	Iluminação de estúdio, pouca geometria
Motion design / mograph	1920×1080	$0.30 – $1.50	$0.20 – $1.10	Redshift / Octane dominantes
Shot de VFX (complexidade média)	1920×1080–2K	$0.60 – $2.50	$0.45 – $1.80	Simulações, displacement, AOVs
Shot de animação de longa-metragem	2K – 4K	$1.20 – $5.00	$0.90 – $3.80	GI pesado, cabelo, volumétricos

Duas conclusões práticas desta tabela. Primeiro, o custo por frame em GPU é geralmente 20–35 % inferior ao CPU na mesma cena se a cena for compatível com GPU — o que significa que as texturas e a geometria cabem em 32 GB de VRAM e o motor é Redshift, Octane ou V-Ray GPU. Segundo, o intervalo por frame dentro de um único tipo de projeto é frequentemente 4–5x mais amplo. Não é variação de fornecedor; é variação de cena. Um interior Corona limpo com alguns pontos de luz renderiza de forma muito diferente do que a mesma sala com vegetação Forest Pack fora das janelas.

O que significa "preço por frame" num render farm?

"Preço por frame" é uma abreviatura para dois conceitos relacionados mas distintos, e confundi-los provoca muita confusão.

Conceito 1 — Um modelo de preços. Um pequeno número de fornecedores (principalmente serviços drag-and-drop destinados a amadores) cobram literalmente um preço fixo por frame independentemente do tempo que o frame demora. Vê-se isso em renderizadores cloud simples para Blender Eevee ou cenas básicas de V-Ray. A tarifa cobre o tempo de computação médio esperado para esse motor e resolução.

Conceito 2 — Uma unidade de relatório. A maioria dos render farms de grau de produção (incluindo a Super Renders Farm) cobra por segundo de tempo de computação, normalizado para uma unidade de hardware — tipicamente GHz-hours para CPU ou OctaneBench-hours para GPU. O "custo por frame" que aparece na fatura é calculado depois de o render terminar, dividindo o custo total pelo número de frames. É descritivo, não prescritivo.

Ambos os conceitos produzem um número que se parece com "$0.42 por frame" numa cotação ou fatura. A diferença é que o Conceito 1 está bloqueado antes de submeter; o Conceito 2 reflete o que a cena realmente consumiu. Para cargas de trabalho previsíveis (imagens estáticas, shots repetitivos), a diferença raramente importa. Para cenas experimentais — primeiros motores, novas configurações de iluminação, simulações não testadas — o Conceito 2 protege de pagar tarifa fixa num frame que acabou por ser barato, mas expõe em frames que acabam por ser pesados.

Quando se vê "preço por frame" anunciado, deve perguntar-se qual o modelo que o fornecedor usa. A resposta afeta a forma como se orçamenta o projeto.

Por que o preço por frame varia tanto

Há quatro fatores de custo que fazem oscilar os números por frame em ordem de grandeza. Compreendê-los é a diferença entre uma cotação que se mantém e uma que duplica a meio do projeto.

1. Complexidade da cena. Contagem de polígonos, contagem de instâncias, subdivisões de displacement, sistemas de cabelo e dados volumétricos multiplicam o tempo de renderização por pixel. Um interior arquitectónico limpo a 1080p pode renderizar em 3 minutos por frame; o mesmo shot com uma dispersão de vegetação Forest Pack no exterior, vedações RailClone e um raio de luz volumétrico pode aumentar para 25 minutos por frame no mesmo hardware. É uma oscilação de custo 8x apenas do conteúdo da cena.

2. Motor de renderização e definições do renderizador. V-Ray, Corona, Arnold, Redshift, Octane e Cycles têm cada um as suas próprias curvas de eficiência. O Corona é geralmente mais rápido para interiores com difusão intensa; o V-Ray tem um teto de funcionalidades mais amplo para exteriores de archviz. No lado GPU, o Redshift biased rendering é mais rápido do que o path tracing bruto do Octane para a mesma qualidade alvo. A contagem de amostras é a variável mais sobrevalorizada — muitas cenas de archviz podem baixar de 200 para 50 amostras com denoising e parecer idênticas, reduzindo o custo em aproximadamente 4x.

3. Resolução de saída. O custo escala quase linearmente com a contagem de pixels, não com o número de resolução. Passar de 1080p (2,07 megapixéis) para 4K (8,29 megapixéis) é um aumento 4x de pixels e aproximadamente 3,5–4x de custo. Vemos clientes a subestimar isto constantemente quando um diretor pede "podemos simplesmente entregar em 4K?"

4. Modelo de preços e nível de hardware. Um serviço fixo por frame pode ser mais barato do que um render farm por segundo para uma cena Eevee simples e 5x mais caro para uma cena V-Ray pesada. A renderização GPU em hardware dedicado de 32 GB VRAM (classe RTX 5090) custa mais por hora de nó do que CPU, mas por frame é frequentemente mais barato porque o frame termina mais depressa.

Um modelo mental útil: o custo por frame é aproximadamente (complexidade da cena × resolução × amostras) ÷ throughput de hardware × taxa horária. Alterar qualquer fator por 2x e o custo do frame move-se com ele.

Modelos de preços por frame: como os render farms cobram

Há quatro modelos de preços de uso comum nos serviços de renderização na nuvem em 2026. Cada um otimiza para um padrão de carga de trabalho diferente, e escolher o errado pode duplicar a fatura.

Modelo	Como funciona	Adequado para	Cuidados
Por frame fixo	Tarifa fixa por frame independentemente do tempo de computação	Amadores, motores previsíveis (Eevee, Cycles simples)	Frames pesados custam ao fornecedor, que incorpora margem na média — paga-se a mais nos frames simples
Por tempo de computação (GHz-hour ou OctaneBench-hour)	Paga-se pelos segundos que o frame usa numa unidade de hardware normalizada	Trabalho de produção onde a complexidade da cena varia	Absorve-se a variância — uma cena com bugs e geometria oculta pode disparar
Subscrição / pacote mensal	Taxa mensal fixa desbloqueia N horas de nó ou uso justo ilimitado	Estúdios com throughput mensal elevado e estável	Gasto desperdiçado em meses lentos; limitação no pico
Crédito pré-pago híbrido	Saldo pré-pago, cobrado por segundo a uma taxa descontada	Estúdios baseados em projetos — a maioria dos freelancers de archviz	Validade de crédito; descontos de nível que prendem ao fornecedor

Para a maioria do trabalho de produção, o tempo de computação com créditos pré-pagos é a escolha previsível. Recompensa cenas eficientes (paga-se menos quando se otimiza) e nunca cobra horas não usadas. O preço fixo por frame é genuinamente mais barato para casos de uso muito restritos — um amador de Blender a renderizar turntables Eevee — mas perde dinheiro rapidamente em qualquer coisa com variância de amostras.

Para uma análise mais detalhada de cada modelo de preços com exemplos concretos, consulte o nosso guia de comparação de modelos de preços de render farm.

Comparação de custos de renderização na nuvem: render farms vs plataformas de computação na nuvem

"Renderização na nuvem" é a categoria mais ampla. Os render farms são uma opção dentro dela. A outra opção principal é executar trabalhos de renderização diretamente em computação na nuvem de uso geral — AWS Batch, Azure Batch, Google Cloud Batch — que fornecem tempo de VM bruto e deixam a orquestração ao utilizador.

Ambas as abordagens entregam o mesmo produto final (frames renderizados), mas a economia por frame e a sobrecarga operacional diferem significativamente. Aqui está como as duas rotas se comparam para uma carga de trabalho de produção representativa.

Fator	Render farm (gerido)	Computação na nuvem (AWS / Azure Batch)
Custo por frame (still de archviz 1080p)	$0.05 – $0.25	$0.18 – $0.55 incluindo licenciamento e sobrecarga de orquestração
Gestão de licenças	Incluída (V-Ray, Corona, Arnold, Redshift, Octane, Cycles incluídos)	Traz-se a própria licença — licenças flutuantes, dongles ou acordos BYOL
Tempo de configuração por projeto	Minutos — upload, configurar, submeter	Dias a semanas para o primeiro projeto; imagens AMI/container, servidores de licenças, configuração de fila
Gestor de render	Gerido pelo fornecedor	Configura-se (Deadline, Tractor, OpenCue ou fila personalizada)
Custo de armazenamento	Geralmente incluído na taxa por frame	Fatura separada de S3 / Blob (especialmente egress acumula)
Flexibilidade de nível de hardware	Frota do fornecedor — escolha limitada	Catálogo completo de tipos de instância (pode-se escolher qualquer SKU GPU que a AWS ofereça)
Gestão de frames falhados	Re-colocação automática na fila sem custo extra na maioria dos render farms	Paga-se pela computação falhada; implementa-se lógica de retry
Adequação típica	Archviz, motion design, estúdios de VFX até ~50 artistas	Estúdios de hiperescala com equipa DevOps completa e pipelines complexos

O resumo honesto: se for um estúdio de archviz, um motion designer ou uma pequena equipa de VFX, um render farm gerido será quase sempre mais barato por frame finalizado do que gerir o próprio pipeline AWS Batch — mesmo que os preços de instância bruta da AWS pareçam mais baixos no papel. Os custos ocultos são o licenciamento (as licenças flutuantes de V-Ray e Redshift não são baratas), o tempo de engenharia DevOps para construir e manter o pipeline e o egress de armazenamento. Já integrámos clientes que fizeram os cálculos da AWS e descobriram que o custo por frame era 2–3x o que um render farm cobraria quando tudo era contabilizado.

Se for um estúdio de hiperescala com uma equipa dedicada de pipeline de renderização — pense numa produtora de animação de longa-metragem com 200+ artistas — executar diretamente em computação na nuvem faz sentido porque os custos fixos de engenharia são amortizados numa grande contagem de frames. Para todos os outros, a rota de render farm gerido ganha no custo por frame.

Para a diferença conceptual entre estas duas abordagens com mais profundidade, consulte a nossa visão geral de o que é um render farm na nuvem e o guia explicativo de renderização na nuvem.

Referências de preços externos para contexto entre nuvens: preços do AWS Batch e preços do Azure Batch — note que estes listam apenas computação bruta, sem licenciamento de DCC ou motor de renderização incluído.

Referências de preço por frame em 2026 por tipo de projeto

A tabela de referência anterior neste artigo apresenta os intervalos por frame. Esta secção adiciona contexto de nível de projeto — como esses números por frame se traduzem em custo total de projeto no trabalho que vemos com mais frequência.

Pacote de stills de archviz (8 stills principais, 4K, exterior V-Ray com vegetação). O preço por frame situa-se tipicamente em $0.40 – $0.80 em CPU. Custo total do projeto: $3.20 – $6.40. Tempo de renderização num render farm gerido: 30 minutos a 2 horas de tempo real dependendo da paralelização. O mesmo trabalho numa única estação de trabalho prenderia a máquina durante a noite.

Animação de archviz (walkthrough de 60 segundos a 30 fps = 1800 frames, 1080p, interior Corona). Por frame: $0.10 – $0.30. Total: $180 – $540. Tempo real num render farm gerido: 4–10 horas. A economia aqui é generosa — mesmo no extremo superior, o custo por entregável é inferior ao consumo de eletricidade de uma única estação de trabalho durante a mesma duração de renderização.

Visualização de produto (200 frames, turntable 4K, Redshift em GPU). Por frame: $0.20 – $0.70. Total: $40 – $140. Tempo real: 30 minutos a 2 horas. A renderização GPU realmente compensa aqui porque as cenas de visualização de produto são geralmente limpas — geometria pequena, iluminação controlada, cabe confortavelmente em 32 GB de VRAM.

Sequência de motion design (450 frames a 30 fps, mograph com Redshift, AOVs). Por frame: $0.40 – $1.10. Total: $180 – $495. Tempo real: 1–3 horas. A variância de custo provém da contagem de AOVs e das definições de amostras de motion blur.

Shot de VFX (240 frames, 2K, Arnold com displacement e volumétricos). Por frame: $1.20 – $2.80. Total: $290 – $670. Tempo real: 4–12 horas. É aqui que o custo por frame começa a ser significativo, e onde a otimização de custos de renderização (redução de amostras, denoising, light linking) apresenta as maiores poupanças.

Pickup de animação de longa-metragem (50 frames, 4K, GI completo + cabelo + volumétricos). Por frame: $2.50 – $5.00. Total: $125 – $250. Tempo real: 3–8 horas. Nesta complexidade, a disciplina por frame de um pipeline de longa-metragem (orçamentos de assets, checkpoints de renderização) realmente vale o esforço.

Estes intervalos são para computação de renderização apenas. Não incluem o custo do tempo de artista, preparação de assets, dailies ou armazenamento de ficheiros de origem. Para a maioria dos estúdios, a computação de renderização é 5–15 % do orçamento total do projeto — significativo o suficiente para gerir com cuidado, mas raramente o fator decisivo para que um projeto seja entregue.

Quando o preço por frame supera o preço horário ou mensal?

Escolher o modelo de preços certo depende de três características do projeto: previsibilidade, volume e cadência.

Previsibilidade — se souber com ±20 % quanto tempo cada frame demorará, o preço fixo por frame pode funcionar. Se não souber (a maioria do trabalho de produção), o tempo de computação com créditos pré-pagos é a escolha mais segura.

Volume — se renderizar menos de ~500 frames por mês, a faturação por segundo sem compromisso supera a subscrição. Acima de ~5.000 frames por mês com cadência estável, um pacote de subscrição começa a fazer sentido.

Cadência — cargas de trabalho por picos (um grande projeto por trimestre, depois nada) favorecem créditos pré-pagos sem validade. Throughput semanal estável favorece subscrição.

Uma regra de decisão simples que partilhamos com os clientes:

• Amador ou freelancer com menos de 500 frames/mês, motores mistos: crédito pré-pago, faturação por segundo
• Pequeno estúdio de archviz, 500–5.000 frames/mês, combinação previsível: crédito pré-pago com desconto de nível superior
• Estúdio de média dimensão, 5.000–20.000 frames/mês, cadência estável: pacote de subscrição se disponível, pré-pago caso contrário
• Hiperescala (mais de 20.000 frames/mês): negociar contrato de volume diretamente

A armadilha a evitar: bloquear numa subscrição "por precaução". Já vimos estúdios a pagar por capacidade não usada durante seis meses porque a burocracia da subscrição era mais difícil de desfazer do que manter.

Como estimar o custo por frame antes de submeter

Uma estimativa aproximada por frame antes da submissão protege de surpresas no projeto. O método abaixo demora cerca de 10 minutos e é preciso com ±30 % para a maioria das cenas de produção.

Passo 1 — Renderizar um frame de teste na estação de trabalho local. Anotar o tempo real. Este é o ponto de referência.

Passo 2 — Medir o throughput do hardware local. Para CPU, é aproximadamente (núcleos × clock GHz). Um Ryzen 9 moderno a 4,5 GHz com 16 núcleos tem 72 GHz de computação. Para GPU, executar um benchmark como OctaneBench ou uma cena de benchmark Redshift para obter uma pontuação relativa.

Passo 3 — Calcular o throughput do nó na nuvem. Um nó de render farm típico na nossa frota tem aproximadamente 70–90 GHz de computação CPU (classe dual Xeon E5-2699 V4) ou uma RTX 5090 (32 GB VRAM) para trabalho GPU. Comparar com o local — a maioria das estações de trabalho tem 30–60 % do throughput de um único nó de render farm.

Passo 4 — Multiplicar o tempo local pela razão de throughput. Se o frame de teste demorou 12 minutos numa estação de trabalho que tem 50 % da velocidade de um nó de render farm, o render farm renderizará em aproximadamente 6 minutos.

Passo 5 — Multiplicar o tempo do render farm pela taxa por segundo. A maioria dos render farms de produção publica uma taxa por GHz-hour ou por OctaneBench-hour. Um frame que demora 6 minutos num nó CPU de 90 GHz consome 9 GHz-hours. Na nossa render farm ($0.004 por GHz-hour para CPU), isso representa aproximadamente $0.04 para esse frame. As taxas variam significativamente entre fornecedores — usar qualquer render farm que esteja a avaliar, multiplicado pelo throughput do próprio nó do render farm.

Passo 6 — Multiplicar o custo por frame pela contagem de frames e adicionar 15 % de buffer. O buffer cobre frames de retry, variância de AOV e o shot excecionalmente pesado ocasional.

Para uma verificação de sanidade face a esta estimativa, a nossa página de preços mostra as taxas de GHz-hour e OctaneBench-hour com exemplos concretos, e o guia de custo por frame de render farm tem um walkthrough mais longo com cálculos.

Táticas práticas de redução de custos

Algumas vitórias rápidas que vemos repetidamente cortar o custo por frame em 30–60 % sem diferença visível de qualidade:

• Usar denoising em vez de forçar amostras. Os denoisers modernos (Intel Open Image Denoise, NVIDIA OptiX) permitem que a maioria das cenas de archviz desça de 200 para 50 amostras com perda de qualidade imperceptível.
• Usar light linking de forma agressiva. Excluir luzes de objetos que não iluminam significativamente reduz os testes de ray de forma significativa.
• Renderizar na resolução que se vai entregar, não "por precaução". Um render 4K custa aproximadamente 4x mais do que um render 1080p da mesma cena. Apenas renderizar 4K se o entregável for 4K.
• Pré-calcular o que for possível. Lightmaps para elementos estáticos, caches de fotões para interiores, mapas de irradiância reutilizados ao longo de uma animação — todos reduzem o custo por frame sem alterar o aspeto.
• Adequar o motor à cena. Os motores GPU (Redshift, Octane) são geralmente mais baratos por frame se a cena couber em VRAM. Os motores CPU (V-Ray, Corona) lidam com orçamentos de geometria maiores a menor custo por frame para exteriores de archviz com vegetação pesada.

Para uma perspetiva da indústria sobre benchmarks de eficiência de renderização, a base de dados de benchmarks do Chaos é uma referência útil para tempos de cena V-Ray em diferentes níveis de hardware.

FAQ

Q: Quanto custa a renderização na nuvem por frame? A: Em 2026, o custo por frame na nuvem situa-se tipicamente entre $0.03 para um still de archviz 1080p simples e $5.00 para um shot de animação 4K pesado. O intervalo amplo reflete a complexidade da cena, o motor de renderização, a resolução de saída e o modelo de preços do fornecedor. A animação de archviz de gama média situa-se em $0.08–$0.65 por frame; shots de VFX e motion design são geralmente $0.50–$3.00 por frame.

Q: O que é o preço por frame num render farm? A: O preço por frame é uma abreviatura para duas coisas distintas. Alguns fornecedores cobram literalmente uma tarifa fixa por frame independentemente do tempo de computação — comum para trabalho simples de Blender ou Eevee. A maioria dos render farms de produção cobra por segundo de tempo de computação e apresenta o custo por frame na fatura como uma unidade de relatório, calculada dividindo o custo total pelo número de frames. Ambos produzem um número que parece "$0.42 por frame", mas o primeiro está bloqueado antes da submissão e o segundo reflete o que a cena realmente consumiu.

Q: A renderização GPU é mais barata por frame do que CPU? A: Para cenas compatíveis com GPU — Redshift, Octane, V-Ray GPU, onde texturas e geometria cabem em 32 GB de VRAM — a renderização GPU é geralmente 20–35 % mais barata por frame do que a renderização CPU da mesma cena. Para cenas que excedem a VRAM, têm displacement pesado ou usam motores sem implementações GPU fortes (Corona, Arnold CPU clássico), o CPU é mais económico por frame.

Q: Como posso reduzir o custo de renderização na nuvem por frame? A: As cinco táticas de maior impacto são: reduzir as contagens de amostras e usar um denoiser; apenas renderizar na resolução que se vai entregar; usar light linking para excluir luzes de objetos que não iluminam; pré-calcular lightmaps estáticos e caches de fotões onde possível; e adequar o motor de renderização à cena (GPU quando couber, CPU para geometria pesada). Em conjunto, estas táticas cortam tipicamente o custo por frame em 30–60 % sem perda visível de qualidade.

Q: O que é mais barato — preço por frame ou subscrição mensal? A: Depende do volume e da previsibilidade. Abaixo de 500 frames por mês, a faturação por segundo com créditos pré-pagos é quase sempre mais barata. Entre 500 e 5.000 frames por mês com cadência estável, o crédito pré-pago com desconto de nível geralmente ganha. Acima de 5.000 frames por mês com throughput semanal previsível, um pacote de subscrição começa a fazer sentido. Cargas de trabalho trimestrais por picos devem manter-se em créditos pré-pagos independentemente do volume total.

Q: Sou cobrado por frames falhados num render farm na nuvem? A: Nos render farms geridos (incluindo a Super Renders Farm), os frames falhados são automaticamente recolocados na fila sem encargo adicional, desde que a falha seja do lado do render farm — falhas de nó, erros de disco, problemas transitórios de licença. As falhas causadas por problemas do lado da cena (assets em falta, plugins corrompidos, falhas de memória por geometria demasiado grande) são geralmente cobradas pela computação consumida até à falha. Nas plataformas de computação na nuvem de uso geral como o AWS Batch, paga-se pela computação falhada independentemente da causa, a não ser que se construa lógica de retry no pipeline.

Q: Como se compara o custo de renderização na nuvem com a gestão dos próprios nós de renderização? A: Para a maioria dos estúdios com menos de ~50 artistas, a renderização na nuvem é significativamente mais barata por frame porque apenas se paga pelo tempo de renderização ativo. Um único nó de renderização de alto desempenho parado 70 % do mês é depreciação cara. Para uma utilização de estado estável muito elevada (mais de 90 % ao longo de anos), ter o hardware pode fazer sentido — mas também se assume potência, arrefecimento, ciclos de renovação de hardware e sobrecarga de engenharia. A comparação de custos de render farm vs construção própria percorre os cálculos completos.

Q: Por que o mesmo frame tem custos diferentes em render farms diferentes? A: Três razões principais. Primeiro, o nível de hardware — um render farm com CPUs ou GPUs mais recentes cobra mais por segundo mas frequentemente termina o frame mais depressa, pelo que o custo por frame pode ser inferior. Segundo, o licenciamento incluído — render farms que incluem licenças de V-Ray, Redshift ou Octane cobram mais por segundo, mas poupa-se em taxas de licença separadas. Terceiro, o modelo de preços — os fornecedores de preço fixo por frame incorporam margem no tempo de computação médio esperado, pelo que cenas simples pagam a mais e cenas complexas conseguem um bom negócio. Comparar sempre por frame finalizado numa cena de teste representativa, não nas taxas horárias anunciadas.