¿Qué es una render farm de GPU? Cómo funciona y cuándo usarla

Introducción

Una render farm de GPU es una flota de ordenadores construida alrededor de tarjetas gráficas de nivel profesional, conectadas mediante un job scheduler y almacenamiento compartido, de modo que muchos frames de una escena nativa de GPU se renderizan en paralelo en lugar de encolarse uno a uno en una sola máquina. En Super Renders Farm operamos una de estas junto a una flota de CPU mucho más grande, y las preguntas que los artistas nos hacen sobre ella son constantes: en qué se diferencia de la CPU farm, en qué se diferencia de las dos tarjetas adicionales de mi workstation, y cuánto cuesta realmente una card-hour.

Esta guía responde a esas preguntas desde el lado del operador. Cubre qué es realmente una render farm de GPU, cómo encajan las piezas — nodos, scheduler, sincronización de assets, entrega de resultados —, las particularidades concretas del hardware que determinan si su escena realmente encaja (VRAM, comportamiento out-of-core, generación de tarjeta), qué motores de render pertenecen a este tipo de farm y cuáles no, dónde una GPU farm realmente gana frente a una CPU farm o un rig local multi-GPU y dónde no, y cómo funciona el cálculo de facturación antes de comprometer una fecha límite a ella. Está escrita para artistas y estudios que quieren entender la maquinaria antes de evaluar cualquier servicio en particular, incluido el nuestro.

Qué es realmente una render farm de GPU

Sin el lenguaje comercial, una render farm de GPU son tres sistemas trabajando juntos:

• Nodos de render. Máquinas cuya potencia de renderizado proviene de una o más GPU de nivel profesional en lugar de núcleos de CPU. El rendimiento de cómputo de la tarjeta y su capacidad de VRAM definen lo que cada nodo puede asumir.
• Un job scheduler. Software que acepta los jobs enviados, los divide en tareas por frame, asigna las tareas a los nodos que estén libres y sean adecuados, reintenta los fallos y reporta el progreso. Toda farm tiene uno; normalmente solo se nota cuando funciona mal.
• Almacenamiento compartido y sincronización de assets. Una capa de archivos común que contiene su escena, cada textura y caché a la que hace referencia, y el resultado renderizado — de modo que cualquier nodo puede tomar cualquier frame sin que su workstation intervenga.

Lo que convierte a la farm en una farm de GPU no es una preferencia de hardware. Son los motores de render a los que sirve: Redshift, Octane, V-Ray GPU, y Cycles y EEVEE de Blender en modo GPU ejecutan todos su renderizado en la tarjeta gráfica, por lo que la farm que los sirve tiene que estar construida alrededor de tarjetas y no de núcleos.

El mismo hardware llega a usted envuelto en dos modelos de servicio muy distintos. Una render farm de GPU gestionada ejecuta un flujo de subir-renderizar-descargar: usted empaqueta una escena, el pipeline de la farm la sincroniza, la renderiza con licencias de motor agrupadas y devuelve los frames — sin sesión de escritorio remoto, sin instalación de software de su lado. GPU IaaS, en cambio, le alquila máquinas virtuales de GPU en bruto: usted se conecta de forma remota, instala su DCC y su motor, aporta las licencias y opera las máquinas usted mismo. Ambas son render farms de GPU en el sentido del hardware; operativamente son productos distintos con distintos modos de fallo.

Este artículo se centra en los conceptos. Si está en proceso de evaluación y busca detalles concretos de servicio en su lugar — especificaciones de nodo, cobertura de motores, tarifas actuales —, la página de GPU cloud render farm contiene esa información.

Cómo funciona una render farm de GPU: nodos, scheduler y sincronización de assets

Un render job pasa por cuatro etapas, y la mayor parte de lo que puede salir mal ocurre en los límites entre ellas.

Empaquetado y subida. El archivo de escena es la parte pequeña. Una escena de producción hace referencia a texturas, cachés de simulación, proxies y datos de plugins repartidos por varias unidades de proyecto, y cada una de esas dependencias tiene que viajar con ella. El fallo más común en un primer job que vemos es un asset referenciado desde una ruta local que existe en la máquina del artista y en ningún otro sitio — el frame se renderiza, pero una textura no se resuelve. Un buen tooling de farm recopila las dependencias en el momento del envío y valida las rutas antes de que ningún nodo dedique tiempo al job. En Super Renders Farm, la sincronización de assets también es incremental: en su segundo envío solo viajan los archivos modificados, lo que marca la diferencia entre una resubida de 40 minutos y una de 40 segundos cuando está iterando contra una fecha límite.

Cola y despacho. El scheduler divide una animación en tareas por frame (o por bloque de frames) y las asigna según la disponibilidad de los nodos, el ajuste de VRAM y la coincidencia de versión de motor. Vuelve a encolar los frames de un nodo que falla, aísla un nodo que sigue fallando y mantiene ocupado al resto de la flota. Esta es la parte de la farm que usted alquila pero nunca ve — y es la mayor razón por la que una farm se comporta de forma distinta a un montón de VM alquiladas.

Ejecución en el nodo. Cada nodo carga las versiones exactas de motor y plugin a las que el job estaba fijado, valida una licencia de render del inventario agrupado de la farm, carga los datos de la escena en la memoria de la GPU, renderiza los frames asignados y escribe los resultados y los logs de vuelta al almacenamiento compartido. Los watchdogs detectan frames que se quedan colgados en lugar de fallar, algo relevante en motores de GPU donde un desbordamiento de memoria puede detener un proceso en lugar de terminarlo.

Entrega de resultados. Los frames terminados llegan al almacenamiento de salida y vuelven a usted a través de la interfaz web, SFTP o un cliente de escritorio. Los resultados no permanecen ahí para siempre — en nuestra farm la ventana de retención es de 45 días desde la finalización del job —, así que la entrega forma parte del pipeline, no una idea de último momento.

Particularidades del hardware de GPU: VRAM, generación de tarjeta y qué significa out-of-core para el tamaño de escena

La especificación a nivel de nodo que más importa en una GPU farm es la VRAM, no la velocidad de reloj ni el número de núcleos — y merece la pena ser concreto sobre el motivo.

Qué hay realmente en un nodo de GPU. En nuestra flota de GPU, cada nodo ejecuta una tarjeta NVIDIA RTX 5090 con 32 GB de VRAM. Ese número es toda la historia para planificar una escena: cuando la geometría, las texturas y los datos de simulación de una escena cargados en la tarjeta superan ese límite, el motor tiene que hacer algo al respecto, y ninguna de las opciones es gratuita.

Qué hace realmente el renderizado out-of-core. Los motores de GPU modernos — Redshift y Octane en particular — admiten modos out-of-core (o "GPU + memoria del sistema") que vuelcan a la RAM del sistema los datos que la tarjeta no puede alojar y los transmiten de vuelta según sea necesario. Se trata de una válvula de seguridad real, no un recurso al que apoyarse por defecto: transmitir por PCIe es dramáticamente más lento que leer directamente desde la VRAM, así que una escena que se desborda mucho puede perder gran parte de la ventaja de velocidad que hizo atractivo el renderizado por GPU en primer lugar. El out-of-core le permite terminar una escena sobredimensionada; no restaura el rendimiento nativo de la GPU una vez superado el límite de VRAM.

Qué significa esto para el tamaño de escena en la práctica. Una escena construida con geometría eficiente e instanciada y texturas de tamaño razonable — la mayoría del trabajo de motion graphics en Cinema 4D/Redshift, la mayoría de la visualización de producto — encaja cómodamente en 32 GB y renderiza a la velocidad completa de la GPU. Una escena con geometría única y densa, conjuntos de texturas de 8K o más en muchos materiales únicos, o datos volumétricos/de partículas pesados (el tipo de carga habitual en VFX y en algunas escenas de archviz con mucha vegetación) tiene más probabilidades de rozar el límite de VRAM y caer en streaming out-of-core o necesitar pasar a una CPU farm, donde la RAM del sistema (96–256 GB en nuestros nodos de CPU) da mucho más margen. Comprobar la huella de VRAM real de su escena frente a la especificación de la tarjeta — no frente a la suposición genérica de que "el renderizado por GPU es rápido" — es el paso previo más útil antes de enviar un trabajo a una GPU farm.

La generación de tarjeta también importa, pero menos que la VRAM. Las tarjetas más recientes aportan más núcleos CUDA y mayor ancho de banda de memoria, lo que aumenta el rendimiento por tarjeta — pero una tarjeta más rápida con el mismo límite de VRAM sigue chocando con el mismo muro en una escena sobredimensionada. Al evaluar una GPU farm, pregunte por el modelo de tarjeta y la cifra de VRAM juntos; una afirmación de velocidad sin una cifra de VRAM no le dice nada sobre si su escena realmente va a encajar.

Qué motores de render requieren una GPU farm y cuáles funcionan en ambas

La identidad del motor es la lente más útil para entender qué pertenece a una render farm de GPU, porque "GPU farm" se define por los motores a los que sirve, no por una preferencia de hardware.

Motor	Solo GPU, solo CPU o ambos	Qué significa esto para la elección de farm
Redshift	Solo GPU (Maxon)	No existe fallback de CPU — un job de Redshift requiere un nodo compatible con GPU. Motor central de las GPU farm; el tipo de job de GPU más común que vemos desde pipelines de Cinema 4D.
Octane	Solo GPU (OTOY)	Misma historia — Octane no tiene ruta de renderizado por CPU. Construido para tarjetas; su benchmark incluso ancla la facturación de la farm (más abajo).
V-Ray GPU	Modo GPU de un motor compatible con CPU/GPU (Chaos)	La misma licencia de V-Ray puede renderizar en CPU o GPU según el modo — muchos pipelines de V-Ray siguen renderizando en CPU, así que V-Ray por sí solo no determina el tipo de farm; lo hace el modo que elija.
Cycles	Tanto CPU como GPU, código abierto (Blender)	Funciona en cualquiera de los dos tipos de farm. En nuestra farm, el trabajo con Cycles es la ruta estándar de Blender en GPU.
EEVEE	GPU (motor de tiempo real/rasterización de Blender)	Solo GPU en la práctica — EEVEE está diseñado en torno al pipeline gráfico, no al path tracing por CPU. EEVEE es compatible en nuestra flota de GPU junto a Cycles; no es un motor de CPU farm.
Corona	Solo CPU (Chaos)	No existe modo GPU. El trabajo con Corona vive exclusivamente en CPU farms.
Arnold	CPU en la mayoría de pipelines de producción (existe un modo GPU)	Normalmente territorio de CPU farm; en nuestra farm Arnold renderiza en CPU. Autodesk sí ofrece un modo GPU, pero los pipelines de producción en su mayoría lo siguen ejecutando en CPU.

A esa tabla se le añaden tres notas operativas. Primero, la coincidencia de versión no es negociable: un nodo de farm debe ejecutar las versiones exactas de motor y plugin con las que se creó su escena, razón por la cual el tooling de envío de la farm fija las versiones por job en lugar de confiar en la suerte. Segundo, la licencia forma parte de la cuestión del motor — en una farm gestionada, las licencias de render para Redshift, Octane, V-Ray, Corona y Arnold están agrupadas e incluidas en la tarifa, y las asociaciones oficiales con Maxon y Chaos respaldan esa licencia de nuestro lado. Cycles no tiene ningún coste de licencia, al ser de código abierto dentro del paraguas de Blender, y lo mismo ocurre con EEVEE. En GPU IaaS, cada una de esas licencias es responsabilidad suya de aprovisionar por máquina.

Tercero, la VRAM es la especificación que hay que comprobar antes que cualquier cifra de velocidad, por las razones cubiertas en la sección de hardware anterior. Publicamos datos medidos de rendimiento de renderizado en la nube con RTX 5090 en V-Ray GPU, Redshift y Octane precisamente porque el comportamiento por motor en tamaños de escena reales dice más que las cifras máximas sintéticas. Para una visión de benchmark más amplia entre varias tarjetas trabajando juntas en lugar de un solo nodo, consulte nuestro benchmark de escalado multi-GPU y nuestros resultados de rendimiento del cluster RTX 5090.

Render farm de GPU frente a render farm de CPU

Los dos tipos de farm se distinguen primero por la compatibilidad de motores y en segundo lugar por el hardware — y merece la pena precisar esa distinción, porque los términos se confunden en el uso informal.

El motor decide, no la farm. Si su proyecto se renderiza en Redshift, Octane o EEVEE, es un job de GPU; si se renderiza en Corona o en el modo CPU de V-Ray, es un job de CPU. Cycles puede ir en cualquiera de las dos direcciones según el dispositivo que seleccione en la configuración de su escena.

Para un recorrido específico del motor sobre cómo ejecutar Octane en una GPU farm gestionada, consulte nuestra guía de Octane render cloud farm. Usted elige el motor por razones creativas y de pipeline, y el motor elige el tipo de farm por usted. Para un tratamiento más profundo a nivel de motor de esa elección, mantenemos una guía aparte de GPU rendering frente a CPU rendering — este artículo trata sobre cómo es la farm que rodea al motor.

Los modelos de memoria difieren en su naturaleza. Un nodo de GPU vive dentro de la VRAM de su tarjeta — 32 GB en las tarjetas RTX 5090 que ejecuta nuestra flota de GPU. Un nodo de CPU vive dentro de la RAM del sistema, y nuestros nodos de CPU con doble Xeon llevan entre 96 y 256 GB de ella. Las funciones out-of-core de los motores de GPU modernos pueden volcar parte de los datos de textura y geometría a la memoria del sistema con un coste de rendimiento (consulte la sección de hardware anterior para lo que eso realmente cuesta), pero la VRAM sigue siendo el límite práctico de la complejidad de escena para trabajo de GPU. Las escenas muy pesadas de archviz con dispersión masiva de vegetación, o las escenas de VFX con volumétricos profundos, a menudo permanecen en CPU farms precisamente por esta razón.

Las afirmaciones de velocidad necesitan contexto. En escenas que encajan cómodamente en la VRAM, un motor de GPU suele entregar un frame en menos tiempo de reloj por nodo que un motor de CPU al renderizar un frame comparable. Esa es una afirmación por nodo, no un veredicto sobre las farms: una flota de CPU con más de 20.000 núcleos entrega rendimiento por pura anchura paralela, y la economía por frame depende de la tarifa por unidad de trabajo, no de qué silicio esté de moda. Ambos modelos tienen un precio acorde al trabajo que realizan.

La mezcla de jobs es más de CPU de lo que sugiere el clima de marketing. Aproximadamente el 70 por ciento de los jobs de nuestra farm todavía se renderizan en motores de CPU — V-Ray CPU, Corona, Arnold —, mientras que el trabajo de GPU en Redshift, Octane, V-Ray GPU, Cycles y EEVEE compone el resto creciente. Una render farm de GPU no es la sucesora de una CPU farm; es la hermana que sirve a una familia distinta de motores. Para una base conceptual más completa que comparten ambos tipos de farm, nuestra guía qué es una render farm cubre las partes que aplican independientemente del hardware — scheduling, almacenamiento y criterios de evaluación.

Render farm de GPU frente a una workstation local multi-GPU

La comparación más interesante para muchos artistas no es frente a las CPU farms, sino frente al equipo que tienen bajo el escritorio. La versión honesta tiene ventajas en ambos lados.

Dónde ganan las tarjetas locales. El lookdev interactivo. Cuando está ajustando materiales e iluminación, la latencia de ida y vuelta importa más que el throughput, y una tarjeta en su propia máquina le da feedback en segundos. Ninguna farm cambia eso, y un operador de farm que afirme lo contrario está vendiendo algo. Lo local también gana cuando su utilización es genuinamente constante — el hardware que renderiza frames de producción la mayoría de las horas de la mayoría de las semanas amortiza su propio coste de capital de una forma que el hardware de uso ocasional nunca logra. Para un desglose completo de cuándo el hardware dedicado tiene más sentido que la capacidad compartida de una farm, consulte nuestra guía de servidor de render dedicado RTX 5090.

Dónde gana la farm. Anchura bajo demanda. Una workstation aloja dos, quizás cuatro tarjetas; una farm le alquila el equivalente a una docena de tarjetas de anchura paralela para un solo fin de semana sin que usted las posea durante los tres años intermedios. El renderizado de animación de frame final es paralelizable de forma trivial — 300 frames repartidos entre muchas tarjetas sin estado compartido —, que es precisamente la forma para la que está construida una farm. También existe la contención: los frames que se renderizan en su workstation bloquean las mismas tarjetas que necesita para el lookdev del siguiente plano, así que las semanas de entrega se convierten en renderizar de noche y trabajar en los huecos. Y está la física poco glamurosa de la energía, el calor y el ruido que las cajas multi-GPU imponen en la sala pequeña de un estudio.

El patrón que vemos operativamente. Los estudios tienden a llegar a un híbrido: tarjetas locales para la iteración, farm para los frames finales y para las dos semanas al año en que todo vence a la vez. Tuvimos un pequeño equipo de motion design que se incorporó tras una semana de entrega en la que dos tarjetas locales funcionaron sin parar y la animación aun así no llegó a su plazo; el mismo job repartido entre nodos de la farm terminó de la noche a la mañana. La lección no es que su hardware fuera inadecuado — es que la capacidad de pico es un producto distinto de la capacidad en propiedad. Publicamos un desglose de coste de un artista independiente entre una workstation RTX 5090 y el renderizado en la nube que recorre las cuentas del lado de la propiedad.

GPU farm, CPU farm, GPU IaaS o rig local: comparación directa

Las cuatro opciones responden a problemas distintos. La tabla siguiente es la comparación que mostramos a los nuevos clientes, con las contrapartidas intactas — incluidas las filas en las que una farm gestionada no es la respuesta correcta. Para ver cómo encaja la categoría de cloud farm en su conjunto dentro del panorama del renderizado, consulte qué es una cloud render farm.

	Render farm de GPU gestionada	Render farm de CPU gestionada	GPU IaaS (VM de GPU alquiladas)	Workstation local multi-GPU
Por qué paga	Frames renderizados, medidos por card-hour de trabajo	Frames renderizados, medidos por unidad de trabajo de CPU	Tiempo de máquina, renderizando o inactiva	Hardware por adelantado, energía al mes
Motores que encajan	Redshift, Octane, V-Ray GPU, Cycles (GPU), EEVEE	V-Ray CPU, Corona, Arnold, Cycles (CPU)	Cualquiera que instale y licencie usted mismo	Lo que admitan sus tarjetas y licencias
Carga de configuración	Empaquetar escena, subir, enviar	Empaquetar escena, subir, enviar	Aprovisionar VM, instalar DCC + motor, gestionar licencias, operar la cola	Construir, refrigerar, alimentar y mantener la caja
Licencias de render	Agrupadas e incluidas en la tarifa	Agrupadas e incluidas en la tarifa	Aportadas por usted	Aportadas por usted
Forma de escalado	Ráfagas amplias bajo demanda	Ráfagas muy amplias bajo demanda	Tantas VM como pueda configurar y costear	Fijo en 2-4 tarjetas
Límite de memoria	VRAM por tarjeta (32 GB en nuestros nodos RTX 5090)	RAM del sistema (96-256 GB en nuestros nodos)	VRAM de la clase de VM que alquile	VRAM de las tarjetas que compró
Gana cuando	Animación de frame final en GPU con plazo ajustado	Escenas pesadas en memoria, pipelines de motor CPU	Pipelines personalizados que necesitan control a nivel de SO	Lookdev interactivo, utilización constante todo el año
Se complica cuando	Necesita bucles de iteración de menos de un minuto	Lo mismo — la iteración pertenece a lo local	Quería renderizar, no administrar sistemas	El plazo necesita 10 veces su número de tarjetas esta semana

Cuánto cuesta el renderizado por GPU en una farm

La facturación de una GPU farm tiene un problema de normalización que resolver: una card-hour no significa nada entre generaciones de hardware mixtas a menos que esté anclada a un rendimiento medido. El ancla habitual es OctaneBench, el benchmark público de renderizado por GPU de OTOY — la puntuación de un nodo expresa cuánto trabajo de renderizado entrega realmente por hora, y la facturación se mide sobre esa base.

En nuestra farm, la tarifa de GPU es de 0,003 $ por OctaneBench-hour, lo que equivale a unos 5,20 $ por card-hour en un nodo RTX 5090. Como contraste, el renderizado por CPU se mide a 0,004 $ por GHz-hour en el nivel de prioridad base (los niveles de prioridad van de 0,004 $ a 0,016 $), con un servidor de doble Xeon rondando los 2 $ por server-hour. Unidades distintas, mismo principio: usted paga por el trabajo entregado, no por el tiempo en que una máquina simplemente existe.

Aquí está el método de estimación que recomendamos, trabajado sobre un escenario concreto: una animación de 300 frames en Redshift que en una prueba renderiza en aproximadamente 4 minutos por frame en una sola tarjeta de clase RTX 5090. El cómputo total es de 300 × 4 = 1.200 card-minutes, o 20 card-hours, sin importar cuántas tarjetas compartan el trabajo:

Tarjetas trabajando en paralelo	Tiempo de reloj	Card-hours facturadas	Coste estimado a ~5,20 $/card-hour
1	~20 horas	20	~104 $
5	~4 horas	20	~104 $
10	~2 horas	20	~104 $

Esa tabla es lo más útil para entender la economía de una farm: a un nivel de tarifa dado, la anchura paralela compra tiempo de entrega, no una factura más grande. El job cuesta lo que cuesta el trabajo; las tarjetas solo deciden si lo recibe esta noche o el jueves.

Trate estas cifras como método, no como presupuesto cerrado. Los tiempos por frame varían a lo largo de una secuencia, la estimación asume paralelismo por frame (una animación, no un único fotograma enorme), y el tiempo real de su frame de prueba es el dato que importa. Renderice primero dos o tres frames representativos y luego multiplique — ese hábito detecta tanto sorpresas de presupuesto como sorpresas de assets rotos antes de que cuesten nada.

Renderizado en la nube por GPU frente a render farm de GPU: ¿hay alguna diferencia?

Las dos expresiones se usan casi de forma intercambiable, y en general eso está bien — pero merece la pena ser preciso sobre la pequeña distinción. "Render farm de GPU" describe la infraestructura: la flota real de nodos de GPU, el scheduler y el almacenamiento que hacen el trabajo, ya se acceda mediante un servicio gestionado o se alquile como IaaS en bruto. "Renderizado en la nube por GPU" es la actividad más amplia de renderizar en cómputo de GPU remoto y accesible por internet en lugar de en hardware local — es lo que está haciendo, mientras que "render farm de GPU" es la cosa sobre la que lo está haciendo.

En la práctica, cuando alguien pregunta "renderizado en la nube por GPU frente a render farm de GPU", casi siempre está preguntando por la división entre gestionado e IaaS cubierta antes en esta guía, no por un genuino conflicto terminológico: el renderizado en la nube por GPU ocurre sobre una render farm de GPU en cualquier caso, y la pregunta real es si esa farm le entrega un pipeline gestionado de subir-renderizar-descargar o un conjunto de VM de escritorio remoto que usted mismo administra. Para la misma distinción aplicada a la categoría más amplia (no específica de GPU) de renderizado en la nube, consulte nuestra guía renderizado en la nube explicado.

Cómo evaluar una render farm de GPU

Los criterios siguientes son los que separan a las farms en la práctica — son las preguntas que haríamos a cualquier proveedor, incluidos nosotros:

• VRAM por tarjeta, por escrito. El modelo de tarjeta y su memoria, más datos de rendimiento publicados para su motor — no una afirmación de velocidad genérica.
• Cobertura exacta de versiones de motor y plugin. Sus versiones, fijadas por job, no "versiones actuales compatibles".
• Gestión de licencias. ¿Incluida en la tarifa, o suya para aprovisionar? La respuesta redefine el coste real por hora.
• Forma del flujo de trabajo. ¿Subir-renderizar-descargar gestionado, o VM de escritorio remoto? Elija la que su equipo pueda operar realmente a las 11 de la noche en el día del plazo.
• Comportamiento de sincronización de assets en el segundo envío. ¿Sincronización solo de archivos modificados, o una resubida completa por iteración? Esto decide cómo se siente realmente la iteración.
• Previsibilidad de coste. Tarifas publicadas en una unidad indicada, y una forma de estimar a partir de frames de prueba antes de comprometer la secuencia completa.
• Retención de resultados y gestión de datos. Conozca la ventana (la nuestra es de 45 días) y planifique la entrega dentro del calendario.
• Soporte durante las ventanas de render. Los renders fallan a las 3 de la madrugada; un soporte por chat en vivo 24/7 vale más que una cola de tickets atendida en horario de oficina.

Llevamos operando infraestructura de render en Super Renders Farm desde 2010, tanto en la flota de CPU como en la flota de GPU RTX 5090, y el patrón que se mantiene es este: las farms que sirven bien a los artistas son las que publican su mecánica — tarifas, motores, VRAM, comportamiento de sincronización — y le dejan comprobar las cuentas usted mismo. Una render farm de GPU no es magia. Es un scheduler, un conjunto de tarjetas muy capaces y una capa de sincronización, operados con cuidado para que su plazo no dependa de las dos tarjetas que tiene bajo el escritorio.

FAQ

Q: ¿Qué es una render farm de GPU? A: Una render farm de GPU es un clúster de nodos de render construido alrededor de tarjetas gráficas de nivel profesional, coordinado por un job scheduler y almacenamiento compartido de modo que muchos frames se renderizan en paralelo para motores nativos de GPU como Redshift, Octane, V-Ray GPU, Cycles y EEVEE. Super Renders Farm, por ejemplo, combina una flota de GPU RTX 5090 con un flujo de trabajo gestionado de subir-renderizar-descargar, de modo que los jobs se ejecutan sin sesiones de escritorio remoto ni configuración manual de licencias.

Q: Renderizado en la nube por GPU frente a render farm de GPU: ¿cuál es la diferencia? A: Una render farm de GPU es la infraestructura — la flota real de nodos, el scheduler y el almacenamiento —, mientras que el renderizado en la nube por GPU es la actividad más amplia de renderizar en cómputo de GPU remoto en lugar de en hardware local. En la práctica, lo que la gente suele querer decir con esa pregunta es la división entre gestionado e IaaS: si la render farm de GPU detrás del renderizado en la nube le entrega un pipeline terminado de subir-renderizar-descargar o VM de escritorio remoto en bruto que usted configura usted mismo.

Q: ¿Cuál es la diferencia entre una render farm de GPU y una render farm de CPU? A: El motor en el que se renderiza su proyecto decide qué tipo de farm necesita: Redshift, Octane, V-Ray GPU, EEVEE y Cycles en modo GPU se ejecutan en GPU farms, mientras que Corona, Arnold y V-Ray CPU se ejecutan en CPU farms. La diferencia de hardware se deriva de ahí — los nodos de GPU están limitados por la VRAM (32 GB por tarjeta en nuestra flota), mientras que los nodos de CPU llevan una RAM del sistema mucho mayor (96-256 GB en los nuestros), razón por la cual las escenas pesadas en memoria a menudo permanecen en CPU farms.

Q: ¿Qué motores de render requieren una render farm de GPU? A: Redshift y Octane son solo GPU — no tienen ninguna ruta de renderizado por CPU, así que cualquier job en cualquiera de los dos motores requiere una farm compatible con GPU. EEVEE también es en la práctica solo GPU, construido alrededor del pipeline de renderizado en tiempo real de Blender. V-Ray GPU y Cycles pueden ejecutarse en GPU pero también tienen modos de CPU, así que esos motores no imponen por sí solos el tipo de farm — lo hace el modo que elija en la configuración de su escena.

Q: ¿Es una render farm de GPU más rápida que una workstation local multi-GPU? A: Por tarjeta, no — un nodo de farm con la misma tarjeta renderiza un frame en aproximadamente el mismo tiempo que su workstation. La diferencia está en la anchura paralela y la contención: una farm puede poner diez o más tarjetas en una animación a la vez mientras sus tarjetas locales quedan libres para el lookdev, de modo que la secuencia termina de la noche a la mañana en lugar de consumir su workstation durante días.

Q: ¿Puedo renderizar Blender EEVEE o Cycles en una render farm de GPU? A: Sí — en nuestra flota de GPU, tanto EEVEE como Cycles (en modo GPU) son motores de render compatibles para escenas de Blender. El pipeline de rasterización en tiempo real de EEVEE se ejecuta en los nodos de GPU igual que Redshift u Octane; Cycles puede ejecutarse en modo CPU o GPU según la configuración de su escena.

Q: ¿Cómo se factura el uso de una render farm de GPU? A: La mayoría de las GPU farms miden card-hours normalizadas por benchmark, de modo que una unidad de facturación equivale a una unidad de trabajo de renderizado medido; OctaneBench es el ancla pública habitual. En nuestra farm la tarifa es de 0,003 $ por OctaneBench-hour — unos 5,20 $ por card-hour en un nodo RTX 5090 —, y el total de un job depende de las card-hours de trabajo, no de cuántas tarjetas lo compartan.

Q: ¿Necesito mis propias licencias de motor de render para usar una render farm de GPU? A: En una render farm de GPU gestionada, no — las licencias de render para motores como Redshift, Octane y V-Ray están agrupadas en la farm e incluidas en la tarifa, y Cycles y EEVEE son de código abierto sin ninguna licencia. En alquileres de GPU IaaS usted aporta y gestiona sus propias licencias por máquina, lo cual es una diferencia real de coste y administración que conviene tener en cuenta.

Q: ¿Cuánta VRAM tienen los nodos de una render farm de GPU, y qué pasa si mi escena es más grande? A: Varía según la farm y la generación de tarjeta, así que compruebe el modelo de tarjeta concreto en lugar de aceptar una afirmación genérica; nuestros nodos de GPU ejecutan tarjetas RTX 5090 con 32 GB de VRAM cada una. Si una escena supera ese límite, motores modernos como Redshift y Octane pueden volcar algunos datos a la memoria del sistema mediante renderizado out-of-core, pero con un coste de rendimiento real — una escena que supera la VRAM de forma genuina y considerable normalmente se sirve mejor con una CPU farm.

Q: ¿Necesito acceso por escritorio remoto para usar una render farm de GPU? A: No en una farm gestionada — el flujo de trabajo es subir, renderizar, descargar: usted empaqueta una escena, la farm la sincroniza y la renderiza, y usted recupera los frames terminados. Las sesiones de escritorio remoto son el modelo operativo de los alquileres de GPU IaaS, donde usted administra las máquinas usted mismo, y esa distinción es la línea práctica más clara entre los dos tipos de servicio.