Octane numa Render Farm na Nuvem: Renderização GPU, Preços OctaneBench e Suporte DCC em 2026

Introdução

O OctaneRender tem uma reputação bem definida: fisicamente preciso, espectralmente correto e rápido no hardware certo. Mas tem também uma regra rígida que condiciona todas as decisões em torno do seu uso — funciona na GPU e em mais lado nenhum. Essa única restrição é o que torna o Octane ao mesmo tempo um prazer numa máquina bem equipada e um verdadeiro desafio de escalar numa render farm.

Na Super Renders Farm, executamos trabalhos Octane na nossa render farm GPU a par de motores CPU como V-Ray, Corona e Arnold. O lado GPU — Octane, Redshift, V-Ray GPU — cresceu para uma fatia significativa e em constante expansão do trabalho, e ao longo de milhares desses trabalhos aprendemos onde o motor se destaca e onde apresenta dificuldades.

Este guia aborda a realidade prática de executar o OctaneRender em grande escala na nuvem: por que a renderização exclusivamente em GPU muda o comportamento de uma render farm, como funciona a faturação por OctaneBench-hora e por que é uma unidade mais honesta do que uma taxa fixa por placa, quais as aplicações 3D que se conjugam bem com o Octane, e como pensar em VRAM antes de enviar uma cena pesada. Sem linguagem comercial — apenas como as coisas funcionam.

O que torna o OctaneRender diferente: exclusivo GPU, sem viés, espectral

O OctaneRender é o path tracer sem viés e espectralmente preciso da OTOY. "Sem viés" significa que converge para uma solução fisicamente correta simulando o transporte de luz real em vez de o aproximar; "espectral" significa que calcula a cor ao longo de todo o espectro luminoso em vez de trabalhar em RGB simples — parte do motivo pelo qual os renders Octane têm um aspeto tão limpo. Para a conversa sobre render farms, o facto determinante é o hardware que exige.

O Octane funciona exclusivamente em GPUs NVIDIA através de CUDA e da API de ray tracing NVIDIA OptiX. Não existe modo de renderização CPU — nem como alternativa, nem como opção híbrida, nem como caminho de sobrecarga. Se uma cena não conseguir correr na GPU, não corre no Octane de forma alguma. Isto é diferente do V-Ray ou do Redshift, que oferecem caminhos CPU ou híbridos. Significa também que GPUs AMD e Apple Silicon não são suportadas: o Octane precisa de CUDA, e CUDA é exclusivo da NVIDIA. A nossa frota GPU é construída com placas NVIDIA RTX 5090 com 32 GB de VRAM cada — precisamente o que o Octane e os outros motores GPU necessitam.

Nas placas da geração RTX (Ampere, Ada e agora Blackwell), o Octane usa OptiX para ray tracing acelerado por hardware — travessia BVH genuína nos núcleos RT em vez de emulação por software — e inclui um denoiser de IA espectral que corre na mesma GPU como pós-processo ao longo das amostras acumuladas. O denoiser é determinístico para uma determinada semente e número de amostras, o que importa mais do que parece: ao distribuir uma animação por vários nós, não se quer que o denoiser faça o frame 47 parecer subtilmente diferente do frame 46.

Um ponto gera mais confusão do que qualquer outro: memória out-of-core. O Octane pode paginar texturas através do bus PCIe a partir da memória do sistema quando excedem a VRAM, pelo que uma cena com um conjunto de texturas pesado ainda pode renderizar — com um custo de desempenho, uma vez que a largura de banda PCIe é uma fração da largura de banda GDDR7 integrada da placa. O que a memória out-of-core não cobre é a geometria: os dados de triângulos e a estrutura de aceleração BVH devem caber na VRAM. Uma cena cuja geometria por si só exceda a memória da placa não renderiza. Portanto, antes de assumir que "out-of-core significa tamanho de cena ilimitado" — não é assim. Significa texturas flexíveis e um limite rígido de geometria.

Memória out-of-core do Octane: a geometria deve caber nos 32 GB de VRAM da GPU, enquanto as texturas podem transbordar para a RAM do sistema

Executar o Octane numa render farm na nuvem: as partes que são realmente difíceis

Distribuir renderização CPU por uma render farm é um problema relativamente simples — dividir os frames, enviar a cena, recolher os resultados. A renderização GPU com Octane introduz restrições que uma render farm CPU nunca precisa de considerar.

Cada GPU é uma ilha independente. Ao distribuir uma animação, o modelo padrão é a distribuição por frames: cada GPU renderiza um frame diferente de forma independente. Isso escala quase linearmente — o dobro das placas, aproximadamente o dobro dos frames por hora. O Octane tem um modo de renderização em rede onde várias GPUs cooperam num único frame, mas esse é um fluxo de trabalho diferente e com mais sobrecarga; o modelo de render farm é um frame por placa. A consequência prática: cada nó deve caber com toda a cena nos seus próprios 32 GB, porque não há partilha de VRAM com a placa vizinha.

Distribuição de frames na render farm Octane: cada nó GPU RTX 5090 renderiza um frame de animação diferente de forma independente, depois os frames terminados são recolhidos para download

A correspondência de drivers e versões é pouco glamorosa e crítica. O Octane é rigoroso quanto às versões de drivers CUDA, e o plugin Octane no DCC deve corresponder à versão do núcleo Octane na render farm. Drivers desalinhados numa frota podem causar falhas ou, pior, diferenças de renderização silenciosas entre nós. Numa instância IaaS autogerida, é necessário fixar drivers e reconciliar versões de plugins manualmente; numa render farm totalmente gerida, a frota está bloqueada a versões de compilações Octane suportadas e a licença do motor (Octane incluída) está incluída na tarifa — nada a instalar ou ativar da parte do utilizador.

Os recursos têm de estar em todos os nós onde o frame pode aterrar. Cada textura, HDRI e ficheiro referenciado deve ser acessível a partir de qualquer nó que processe um frame, no exato caminho que a cena espera. Um pipeline gerido resolve e distribui esses recursos a partir do projeto enviado; uma render farm GPU autogerida deixa a configuração de armazenamento partilhado e o remapeamento de caminhos a cargo do utilizador.

Aqui está a divisão de tarefas que observamos entre uma configuração GPU autogerida e uma render farm totalmente gerida:

A última linha é importante. Como a renderização numa render farm Octane é totalmente headless, não existe etapa de desktop remoto — submete-se a partir do DCC e a render farm renderiza, eliminando toda uma categoria de fricção de configuração que os alugueres de GPU IaaS ainda impõem.

OctaneBench e o modelo de preços por OBh

Esta é a parte da economia do Octane que a maioria dos artistas nunca teve explicada claramente, pelo que vale a pena demorar um pouco.

OctaneBench é o benchmark GPU padronizado da OTOY. Renderiza uma cena de referência fixa e produz uma pontuação única sem dimensão que representa quanta carga Octane uma GPU consegue processar por segundo em relação a uma placa de referência — uma pontuação mais alta significa mais débito. Como a OTOY o publica e qualquer pessoa pode executá-lo, tornou-se uma forma credível e neutra em termos de fornecedor para comparar GPUs especificamente para Octane.

Esse benchmark é também a base de faturação do trabalho GPU nesta plataforma. Faturamos a renderização GPU a $0,003 por OctaneBench-hora (OBh). Uma OctaneBench-hora é uma hora de computação de uma GPU que entrega uma unidade de débito OctaneBench. Uma placa com uma pontuação OctaneBench elevada entrega muitas OBh por hora de relógio; uma placa mais lenta entrega menos. A faturação é feita pelas OctaneBench-horas que o trabalho realmente consome.

Por que isso importa? Considere uma taxa fixa por placa-hora. Duas render farms podem ambas anunciar "$X por GPU-hora", mas se uma aluga uma placa de geração atual e a outra uma placa de duas gerações anteriores, paga-se o mesmo preço horário por quantidades de trabalho muito diferentes — a placa mais rápida termina numa fração do tempo, a mais lenta fatura muito mais horas. A faturação por OctaneBench-hora normaliza isso: paga-se pelo débito de renderização entregue, não pelo tempo a ocupar uma máquina. Uma placa mais rápida que termina mais cedo simplesmente consome as OBh que o trabalho exigiu e para.

A faturação por OctaneBench-hora normaliza o custo de renderização pelo débito entregue: uma GPU mais rápida termina em menos horas, pelo que o mesmo trabalho custa o mesmo independentemente da geração da placa

Como referência, uma RTX 5090 entrega cerca de 1.730 OctaneBench-horas de débito por hora de relógio — um valor consistente com os benchmarks publicados para a arquitetura Blackwell, embora as pontuações exatas variem com a complexidade da cena e a configuração do sistema. O número canónico a reter é a própria tarifa: $0,003/OBh. Eis como um trabalho se decompõe:

O tempo de renderização por frame e a pontuação OctaneBench nessa tabela são ilustrativos — ambos dependem inteiramente da cena. A tarifa é a parte fixa. As novas contas começam também com $25 em créditos de renderização gratuitos, e os créditos não expiram, pelo que é possível executar uma cena de teste real e ver os seus próprios números antes de se comprometer com um trabalho completo. Apresentamos o modelo completo no guia de preços da render farm, e existe uma análise detalhada de como estimar trabalhos frame a frame no nosso guia de custo por frame.

Uma nota que vale a pena referir claramente, porque confunde as pessoas ao comparar fornecedores: OctaneBench-hora é por vezes usado como unidade de faturação mesmo por render farms que não executam o OctaneRender — pegam no benchmark como métrica de normalização para qualquer motor GPU que oferecem. Se o suporte ao Octane for especificamente importante, confirme que a render farm executa o próprio motor, não apenas o seu benchmark. E uma cotação por placa-hora tem pouco significado até saber qual a placa que está a alugar; a geração da GPU é o número que decide o custo real.

Octane no DCC: Cinema 4D, Maya, 3ds Max e Houdini

O Octane chega ao trabalho através de plugins, e a maturidade desses plugins varia consoante a aplicação. Saber onde o Octane é mais forte ajuda a decidir se é o motor certo para o pipeline.

Cinema 4D é a casa emblemática do Octane. O plugin OctaneRender para C4D é a integração mais madura e prevalente em produção que a OTOY disponibiliza, com suporte aprofundado para materiais nativos do C4D, MoGraph e effectors, o sistema Takes para saída multi-pass e motion blur nativo. Para designers de motion ou artistas de visualização de produtos que trabalham em Cinema 4D, o Octane é uma escolha natural — e é o motor que a maioria das pessoas tem em mente quando fala de "Octane em produção". É também onde a decisão entre Octane e Redshift ocorre com mais frequência; abordamos esse equilíbrio no nosso guia Redshift para Cinema 4D para quem esteja a ponderar os dois.

Maya tem um plugin OctaneRender sólido usado em pipelines VFX e de motion que pretendem path tracing GPU sem se comprometerem com Arnold ou Redshift. Redes de materiais, integração de câmara e iluminação, e caches Alembic são todos suportados. É menos dominante na comunidade do que o par com C4D, mas tem relevância comercial significativa.

3ds Max corre bem o Octane, particularmente em archviz e visualização de produtos. O mercado archviz do 3ds Max ainda recorre muito a motores CPU como V-Ray e Corona, pelo que o Octane é uma escolha deliberada nesse contexto e não a predefinição — mas o plugin é capaz e a conversão de materiais é boa.

Houdini tem um plugin OctaneRender que lida bem com geometria procedural e aparece em trabalhos VFX. No espaço GPU do Houdini, o Karma XPU da própria SideFX e o Redshift têm uma quota maior, pelo que o Octane para Houdini é uma fatia real mas menor — uma boa opção se o Octane já é o padrão do estúdio.

Uma nota para artistas Blender. O path tracer padrão de produção do Blender é Cycles, e é Cycles que executamos nos trabalhos Blender na render farm. Nos nossos nós RTX 5090, o Cycles usa ray tracing por hardware OptiX, pelo que se obtém path tracing GPU no mesmo nível de hardware que os trabalhos Octane — saída sem viés, fisicamente baseada — sem necessidade de uma subscrição Octane separada. (EEVEE, o motor em tempo real do Blender, é uma questão completamente diferente: precisa de um contexto de visualização ativo e não corre em nós de renderização headless, pelo que as cenas EEVEE devem ser convertidas para Cycles antes do envio.) Se o Octane for especificamente o motor pretendido, Cinema 4D, Maya, 3ds Max e Houdini são onde ele está mais em casa; para artistas Blender, o Cycles em GPU oferece a mesma classe de resultados.

Requisitos de GPU e quando o Octane é o motor certo

Como o Octane depende inteiramente da GPU, vale a pena ter presentes algumas realidades de hardware.

A VRAM é o número mais importante. Os 32 GB de uma RTX 5090 definem o limite de geometria para o Octane. Interiores archviz com bibliotecas completas de mobiliário e displacement, ou planos VFX com geometria de personagem densa e volumes, chegam rotineiramente além do que uma placa de 24 GB consegue conter — e uma cena que falha ao carregar numa GPU de 24 GB pode ter sucesso numa de 32 GB. Esta é uma diferença concreta e verificável, não uma afirmação de marketing. A memória out-of-core acrescenta margem para texturas, mas o planeamento da geometria deve ter em conta esse limite. Há mais informação sobre o posicionamento da RTX 5090 para renderização GPU no nosso artigo de desempenho RTX 5090.

CUDA e NVIDIA, sempre. O Octane requer uma GPU NVIDIA compatível com CUDA (capacidade de computação 5.0 ou superior, o que qualquer placa atual cumpre confortavelmente). Qualquer conselho encontrado online sobre renderização em placas AMD ou Apple Silicon simplesmente não se aplica a um fluxo de trabalho Octane — o motor não as suporta. É por isso que uma render farm construída especificamente em hardware NVIDIA é a correspondência correta para o Octane, sem ressalvas.

Quando é que o Octane é a escolha certa e quando é que há algo melhor? Uma forma equilibrada de pensar sobre isso:

Vale a pena referir claramente que a renderização GPU, incluindo o Octane, não é toda a história na nossa render farm — a maioria dos trabalhos que executamos ainda é baseada em CPU, com trabalhos archviz V-Ray e Corona a constituírem a maior parte do volume. O Octane situa-se num segmento GPU em crescimento, não no centro de tudo. Se o pipeline for CPU-first, nenhuma das restrições específicas do Octane acima se aplica, e um motor CPU é muito provavelmente a melhor escolha. O objetivo deste guia é ser claro sobre onde o Octane merece o seu lugar — e onde não o merece.

FAQ

Q: A Super Renders Farm suporta OctaneRender? A: Sim. O Octane corre nos nossos nós GPU NVIDIA RTX 5090 (32 GB de VRAM cada), e a licença OctaneRender está incluída na tarifa de renderização — não há nada a instalar ou ativar, e não é necessário desktop remoto, uma vez que a renderização é totalmente headless.

Q: O que é uma OctaneBench-hora (OBh) e como funcionam os preços? A: Uma OctaneBench-hora é uma hora de computação de uma GPU que entrega uma unidade de débito OctaneBench, onde OctaneBench é o benchmark GPU padronizado da OTOY. Faturamos a renderização GPU a $0,003 por OBh, o que significa que se paga pelo débito de renderização efetivamente entregue e não pelo tempo a ocupar uma placa — uma GPU mais rápida termina mais cedo e simplesmente consome as OBh que o trabalho exigiu.

Q: Que GPU é necessária para renderizar Octane na render farm? A: Não é necessária nenhuma GPU própria para renderizar na render farm — a renderização é feita nos nossos nós RTX 5090. O Octane requer uma GPU NVIDIA compatível com CUDA (não funciona em AMD ou Apple Silicon), que é exatamente o que a frota usa, pelo que a cena corre em hardware adequado ao motor.

Q: O Octane consegue renderizar uma cena maior do que a VRAM da GPU? A: Parcialmente. O Octane pode paginar texturas a partir da memória do sistema através de out-of-core quando excedem a VRAM, com um custo de desempenho. A geometria é diferente — os dados de triângulos e a estrutura de aceleração devem caber na VRAM, pelo que uma cena cuja geometria por si só exceda os 32 GB da placa não renderiza até ser otimizada com instâncias, proxies ou tessellação reduzida.

Q: Que aplicações 3D funcionam com o Octane na render farm? A: As casas mais prevalentes do Octane em produção são Cinema 4D (a integração emblemática), Maya, 3ds Max e Houdini. O Cinema 4D tem o plugin OctaneRender mais aprofundado e amplamente utilizado; os restantes são maduros e usados em VFX, archviz e motion.

Q: Posso renderizar cenas Blender com Octane? A: Para Blender, executamos Cycles, que é o path tracer padrão de produção do Blender. Nos nossos nós RTX 5090, o Cycles usa ray tracing por hardware OptiX, pelo que se obtém path tracing GPU no mesmo nível de hardware que os trabalhos Octane sem uma subscrição Octane separada. Se o Octane for especificamente o motor pretendido, Cinema 4D, Maya, 3ds Max e Houdini são a escolha natural; os artistas Blender obtêm resultados GPU equivalentes através de Cycles.

Q: O Octane recorre à CPU se uma cena não couber na GPU? A: Não. O OctaneRender é exclusivamente GPU — não existe modo CPU nem alternativa híbrida. Se uma cena não conseguir correr na GPU, tem de ser otimizada para caber, ou renderizada num motor que suporte renderização CPU, como V-Ray, Corona ou Arnold, que também executamos.

Q: Como envio o projeto para a render farm e quanto tempo ficam os renders guardados? A: O projeto é enviado em pacote (aceitamos arquivos tar, tar.gz e 7z; .zip não é suportado), e a render farm resolve e distribui os recursos pelos nós de renderização. Os renders terminados ficam guardados durante 45 dias e podem ser transferidos via web, SFTP ou auto-download da aplicação Client App.