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

Introducción

Una GPU render farm es un conjunto de computadoras construidas en torno a tarjetas gráficas de nivel de renderizado, conectadas mediante un programador de trabajos y almacenamiento compartido para que muchos fotogramas se rendericen en paralelo. En Super Renders Farm operamos una junto a una flota de CPU mucho más grande, y las preguntas que nos hacen los artistas son consistentes: ¿en qué se diferencia de la render farm de CPU?, ¿en qué se diferencia de las dos tarjetas adicionales en la estación de trabajo?, ¿y qué cuesta realmente una tarjeta-hora?

Esta guía responde esas preguntas desde el lado del operador. Cubre qué es una GPU render farm, cómo encajan las piezas —nodos, programador, sincronización de recursos, entrega de resultados—, dónde una render farm GPU supera genuinamente a una render farm de CPU o a un equipo local con múltiples GPU y dónde no lo hace, qué motores de renderizado corresponden a una, y cómo funciona la aritmética de facturación antes de comprometer una fecha límite. Está escrita para artistas y estudios que desean entender la maquinaria antes de evaluar cualquier servicio en particular, incluido el nuestro.

Qué es realmente una GPU render farm

Elimine el lenguaje de marketing y una GPU render farm son tres sistemas trabajando en conjunto:

• Nodos de render. Máquinas cuya potencia de renderizado proviene de una o más GPU de nivel renderizado en lugar de núcleos de CPU. La capacidad de cómputo de la tarjeta y su capacidad de VRAM definen lo que cada nodo puede asumir.
• Un programador de trabajos. Software que acepta trabajos enviados, los divide en tareas por fotograma, asigna tareas a los nodos que están libres y son adecuados, reintenta los fallos y reporta el progreso. Toda render farm tiene uno; generalmente se nota solo cuando funciona mal.
• Almacenamiento compartido y sincronización de recursos. Una capa de archivos común que contiene la escena, cada textura y caché que referencia, y los resultados renderizados, de modo que cualquier nodo pueda tomar cualquier fotograma sin que la estación de trabajo del artista esté involucrada.

Lo que hace que la render farm sea una render farm GPU no es una preferencia de hardware. Son los motores de renderizado que sirve: Redshift, Octane, V-Ray GPU y Cycles de Blender en GPU todos ejecutan su trazado de rayos en la tarjeta gráfica, por lo que la render farm que los sirve debe estar construida en torno a tarjetas en lugar de núcleos.

El mismo hardware llega al usuario bajo dos modelos de servicio muy diferentes. Una GPU render farm gestionada ejecuta un flujo de trabajo de carga-renderizado-descarga: empaqueta una escena, el pipeline de la render farm la sincroniza, la renderiza con licencias de motor agrupadas y devuelve los fotogramas —sin sesión de escritorio remoto, sin instalación de software de su parte—. La IaaS de GPU, por el contrario, le alquila máquinas virtuales de GPU sin procesar: se conecta de forma remota, instala su DCC y motor, lleva las licencias y opera las máquinas usted mismo. Ambas son GPU render farms en el sentido del hardware; operativamente son productos diferentes con modos de fallo distintos.

Este artículo se centra en los conceptos. Si está en medio de una evaluación y desea especificaciones de servicio —especificaciones de nodos, cobertura de motores, tarifas actuales—, la página de GPU cloud render farm contiene esa información.

Cómo funciona una GPU render farm: nodos, programador y sincronización

Arquitectura de una GPU render farm — una estación de trabajo de artista cargando una escena empaquetada a través de sincronización de recursos hacia almacenamiento compartido, un programador de trabajos dividiendo fotogramas entre una flota de nodos de render GPU, y fotogramas terminados fluyendo de vuelta al almacenamiento de salida para su descarga.

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

Empaquetado y carga. El archivo de escena es la parte pequeña. Una escena de producción referencia texturas, cachés de simulación, proxies y datos de plugins dispersos entre las unidades del proyecto, y cada una de esas dependencias debe trasladarse con ella. El fallo más común en el primer trabajo que vemos es un recurso referenciado desde una ruta local que existe en la máquina del artista y en ningún otro lugar —el fotograma se renderiza, pero una textura no resuelve nada—. Un buen conjunto de herramientas de la render farm recopila dependencias en el envío y valida las rutas antes de que cualquier nodo dedique tiempo al trabajo. En Super Renders Farm, la sincronización de recursos también es incremental: en su segundo envío solo viajan los archivos modificados, lo que representa la diferencia entre una nueva carga de 40 minutos y una de 40 segundos cuando itera bajo un plazo.

Cola y despacho. El programador divide una animación en tareas por fotograma (o por bloque de fotogramas) y las asigna según la disponibilidad del nodo, el ajuste de VRAM y la coincidencia de versión del motor. Vuelve a encolar fotogramas de un nodo que falla, aísla un nodo que falla repetidamente y mantiene ocupado el resto de la flota. Esta es la parte de la render farm que usted alquila pero nunca ve, y es la principal razón por la que una render farm se comporta de manera diferente a un conjunto de máquinas virtuales alquiladas.

Ejecución en el nodo. Cada nodo carga las versiones exactas del motor y los plugins a los que el trabajo fue anclado, verifica una licencia de renderizado del inventario agrupado de la render farm, carga los datos de la escena en la memoria de la GPU, renderiza los fotogramas asignados y escribe los resultados más los registros de vuelta al almacenamiento compartido. Los sistemas de vigilancia detectan fotogramas que se bloquean en lugar de fallar, lo que importa en los motores de GPU donde un desbordamiento de memoria puede detener un proceso en lugar de terminarlo.

Salida y entrega. Los fotogramas 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 viven allí indefinidamente —en nuestra render farm la ventana de retención es de 45 días desde la finalización del trabajo—, por lo que la entrega es parte del pipeline, no una consideración posterior.

GPU render farm vs render farm de CPU

Los dos tipos de render farm están separados por compatibilidad de motor primero y por hardware en segundo lugar.

El motor decide, no la render farm. Si su proyecto se renderiza en Redshift o Octane, es un trabajo de GPU; si se renderiza en Corona o en el modo CPU de V-Ray, es un trabajo de CPU. Usted elige el motor por razones creativas y de pipeline, y el motor elige el tipo de render farm por usted. Para un tratamiento más profundo a nivel de motor de esa elección, mantenemos una guía separada sobre renderizado GPU vs renderizado CPU —este artículo trata sobre cómo se ve la render farm alrededor del motor—.

Los modelos de memoria difieren en su naturaleza. Un nodo 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 96–256 GB de ella. Las funciones fuera del núcleo en los motores de GPU modernos pueden transferir algunos datos de textura y geometría a la memoria del sistema con un costo de rendimiento, pero la VRAM sigue siendo el límite práctico en la complejidad de la escena para el trabajo de GPU. Las escenas de archviz muy pesadas con dispersión masiva de vegetación, o las escenas VFX con volumétricas profundas, a menudo permanecen en render farms de CPU exactamente por esta razón.

Las afirmaciones de velocidad necesitan contexto. En escenas que encajan cómodamente en la VRAM, un motor de GPU generalmente entrega un fotograma en menos tiempo de reloj de pared por nodo que un motor de CPU renderizando un fotograma comparable. Esa es una afirmación por nodo, no un veredicto sobre render farms: una flota de CPU con más de 20.000 núcleos entrega rendimiento por puro ancho paralelo, y la economía por fotograma 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 trabajos es más de CPU de lo que sugiere el clima de marketing. Aproximadamente el 70 por ciento de los trabajos en nuestra render farm todavía se renderizan en motores de CPU —V-Ray CPU, Corona, Arnold—, con trabajo de GPU en Redshift, Octane y V-Ray GPU conformando el resto en crecimiento. Una GPU render farm no es la sucesora de una render farm de CPU; es la hermana que sirve a una familia diferente de motores.

GPU render farm vs una estación de trabajo local con múltiples GPU

La comparación más interesante para muchos artistas no es con las render farms de CPU sino con el equipo debajo del escritorio. La versión honesta tiene ventajas en ambos lados.

Donde 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 rendimiento, y una tarjeta en su propia máquina le da retroalimentación en segundos. Ninguna render farm cambia eso, y un operador de render farm que afirme lo contrario está vendiendo algo. La opción local también gana cuando la utilización es genuinamente constante —el hardware que renderiza fotogramas de producción la mayor parte de las horas de la mayoría de las semanas recupera su costo de capital de una manera que el hardware de uso ocasional nunca logra.

Donde gana la render farm. Amplitud bajo demanda. Una estación de trabajo tiene dos, quizás cuatro tarjetas; una render farm le alquila el equivalente de una docena de tarjetas de ancho paralelo para un solo fin de semana sin que las posea durante los tres años intermedios. El renderizado de animación en fotograma final es trivialmente paralelizable —300 fotogramas distribuidos entre muchas tarjetas sin estado compartido—, que es precisamente la forma para la que está construida una render farm. También existe la contención: los fotogramas que se renderizan en su estación de trabajo bloquean las mismas tarjetas que necesita para el lookdev del siguiente plano, por lo que las semanas de plazo se convierten en renderizado nocturno y trabajo en los intervalos. Y está la física poco glamorosa de la energía, el calor y el ruido que imponen los equipos con múltiples GPU en una sala de estudio pequeña.

El patrón que vemos operativamente. Los estudios tienden a llegar a un modelo híbrido: tarjetas locales para iteración, render farm para fotogramas finales y para las dos semanas al año en que todo vence a la vez. Un pequeño equipo de diseño de movimiento se unió después de una semana de entrega en la que dos tarjetas locales funcionaron sin parar y la animación igualmente perdió su fecha; el mismo trabajo distribuido entre nodos de la render farm terminó durante la noche. La lección no es que su hardware fuera inadecuado —es que la capacidad de ráfaga es una mercancía diferente a la capacidad propia. Publicamos un análisis de costos para un artista independiente de una estación de trabajo RTX 5090 vs renderizado en la nube que recorre la aritmética del lado de la propiedad.

GPU farm, render farm de CPU, IaaS de GPU o equipo local: comparación

Las cuatro opciones responden a problemas diferentes. La tabla a continuación es la comparación que hacemos con los nuevos clientes, con las ventajas y desventajas intactas —incluyendo las filas donde una render farm gestionada no es la respuesta correcta—. Para conocer cómo la categoría de cloud render farm encaja en el panorama del renderizado, vea qué es una cloud render farm.

Qué motores de renderizado encajan en una GPU render farm

Una render farm GPU toma su nombre de los motores que ejecuta, por lo que la identidad del motor es el criterio correcto para toda la categoría.

Tres notas operativas se adjuntan a esa tabla. Primero, la coincidencia de versión no es negociable: un nodo de la render farm debe ejecutar las versiones exactas del motor y los plugins contra las que se creó su escena, razón por la cual las herramientas de envío de la render farm anclan versiones por trabajo en lugar de confiar en la suerte. Segundo, las licencias son parte de la pregunta del motor —en una render farm gestionada las licencias de renderizado para Redshift, Octane, V-Ray, Corona y Arnold están agrupadas e incluidas en la tarifa, y alianzas oficiales con Maxon y Chaos respaldan esa licencia de nuestra parte—. Cycles no tiene costo de licencia alguno, siendo código abierto bajo el paraguas de Blender. En IaaS de GPU, cada una de esas licencias es su problema para aprovisionar por máquina.

Tercero, la VRAM es la especificación que debe verificar antes de cualquier cifra de velocidad. Una tarjeta que renderiza rápido pero no puede contener su escena no renderiza nada. Publicamos datos de rendimiento de renderizado en la nube con RTX 5090 medidos a través de V-Ray GPU, Redshift y Octane precisamente porque el comportamiento por motor a tamaños de escena reales le dice más que los números de rendimiento máximo sintético.

Cuánto cuesta el renderizado GPU en una render farm

La facturación en render farms de GPU tiene un problema de normalización que resolver: una tarjeta-hora no significa nada entre generaciones de hardware mixto a menos que esté anclada a un rendimiento medido. El ancla común es OctaneBench, el benchmark público de renderizado GPU de OTOY —la puntuación de un nodo expresa cuánto trabajo de renderizado entrega realmente por hora, y la facturación mide eso—.

En nuestra render farm la tarifa de GPU es de $0,003 por OctaneBench-hora, lo que equivale a aproximadamente $5,20 por tarjeta-hora en un nodo RTX 5090. Por contraste, el renderizado de CPU mide a $0,004 por GHz-hora en el nivel de prioridad base (los niveles de prioridad van de $0,004 a $0,016), con un servidor con doble Xeon ubicándose en alrededor de $2 por hora de servidor. Unidades diferentes, mismo principio: usted paga por el trabajo entregado, no por el tiempo que una máquina simplemente existe.

Este es el método de estimación que recomendamos, aplicado a un escenario concreto: una animación Redshift de 300 fotogramas que se renderiza de prueba en aproximadamente 4 minutos por fotograma en una sola tarjeta de clase RTX 5090. El cómputo total es 300 × 4 = 1.200 minutos de tarjeta, o 20 tarjetas-hora, independientemente de cuántas tarjetas compartan el trabajo:

Esa tabla es lo más útil que se puede entender sobre la economía de la render farm: a un nivel de tarifa dado, el ancho paralelo le compra tiempo de entrega, no una factura más grande. El trabajo cuesta lo que cuesta; las tarjetas solo deciden si lo obtiene esta noche o el jueves.

Trate las cifras como método, no como cotización. Los tiempos por fotograma varían a lo largo de una secuencia, la estimación asume paralelismo por fotograma (una animación, no un único fotograma enorme), y el tiempo real de fotograma de prueba de su escena es la entrada que importa. Renderice dos o tres fotogramas representativos primero y luego multiplique —ese hábito detecta tanto sorpresas presupuestarias como sorpresas de recursos rotos antes de que cuesten algo—.

Cómo evaluar una GPU render farm

Los criterios a continuación son los que separan las render farms en la práctica —son las preguntas que haríamos a cualquier proveedor, incluido el nuestro—:

• 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 genérica de velocidad—.
• Cobertura exacta de versiones del motor y plugins. Sus versiones, ancladas por trabajo, no "versiones actuales soportadas".
• Manejo de licencias. ¿Incluidas en la tarifa, o usted las aprovisiona? La respuesta reformula el costo real por hora.
• Forma del flujo de trabajo. ¿Carga-renderizado-descarga gestionado, o máquinas virtuales de escritorio remoto? Elija el que su equipo pueda operar realmente a las 11 p. m. la noche del plazo.
• Comportamiento de sincronización de recursos en el segundo envío. ¿Sincronización solo de archivos modificados, o una nueva carga completa por iteración? Esto decide cómo se siente realmente la iteración.
• Previsibilidad del costo. Tarifas publicadas en una unidad declarada, y una forma de estimar a partir de fotogramas de prueba antes de comprometer la secuencia.
• Retención de resultados y manejo de datos. Conozca la ventana (la nuestra es 45 días) y planifique la entrega dentro del cronograma.
• Soporte durante las ventanas de renderizado. Los renders fallan a las 3 a. m.; el soporte por chat en vivo las 24 horas es más valioso que una cola de tickets respondida en horario de oficina.

Llevamos ejecutando infraestructura de renderizado 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 render farms que sirven bien a los artistas son las que publican su mecánica —tarifas, motores, VRAM, comportamiento de sincronización— y le dejan verificar la aritmética usted mismo. Una GPU render farm no es magia. Es un programador, un conjunto de tarjetas muy capaces y una capa de sincronización, operados cuidadosamente para que su plazo no dependa de las dos tarjetas debajo de su escritorio.

FAQ

Q: ¿Qué es una GPU render farm? A: Una GPU render farm es un conjunto de nodos de render construidos en torno a tarjetas gráficas de nivel renderizado, coordinados por un programador de trabajos y almacenamiento compartido para que muchos fotogramas se rendericen en paralelo para motores nativos de GPU como Redshift, Octane, V-Ray GPU y Cycles. Super Renders Farm, por ejemplo, combina una flota de GPU RTX 5090 con un flujo de trabajo gestionado de carga-renderizado-descarga, de modo que los trabajos se ejecutan sin sesiones de escritorio remoto ni configuración manual de licencias.

Q: ¿Cuál es la diferencia entre una GPU render farm y una render farm de CPU? A: El motor en el que se renderiza su proyecto decide qué tipo de render farm necesita: Redshift, Octane, V-Ray GPU y Cycles en GPU se ejecutan en render farms de GPU, mientras que Corona, Arnold y V-Ray CPU se ejecutan en render farms de CPU. 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 RAM del sistema mucho mayor, razón por la que las escenas con mucha memoria a menudo permanecen en render farms de CPU—.

Q: ¿Es una GPU render farm más rápida que una estación de trabajo local con múltiples GPU? A: Por tarjeta, no —un nodo de render farm con la misma tarjeta renderiza un fotograma en aproximadamente el mismo tiempo que su estación de trabajo—. La diferencia está en el ancho paralelo y la contención: una render farm puede poner diez o más tarjetas en una animación a la vez mientras sus tarjetas locales permanecen libres para el lookdev, por lo que la secuencia termina durante la noche en lugar de consumir su estación de trabajo durante días.

Q: ¿Puedo renderizar Blender EEVEE en una GPU render farm? A: Generalmente no —EEVEE es el motor de rasterización en tiempo real de Blender y se comporta de manera diferente a los trazadores de rayos fuera de línea en los nodos de render farm sin cabecera, por lo que el soporte de la render farm varía y a menudo está ausente—. En nuestra render farm, el renderizado de Blender se ejecuta únicamente en Cycles; no ejecutamos EEVEE, y recomendamos confirmar el soporte del motor con cualquier proveedor antes de planificar un proyecto en torno a él.

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

Q: ¿Necesito mis propias licencias de motor de renderizado para usar una GPU render farm? A: En una GPU render farm gestionada, no —las licencias de renderizado para motores como Redshift, Octane y V-Ray están agrupadas en la render farm e incluidas en la tarifa, y Cycles es de código abierto sin licencia alguna—. En los alquileres de IaaS de GPU, usted aporta y gestiona sus propias licencias por máquina, lo que representa una diferencia real en costo y administración que vale la pena calcular.

Q: ¿Cuánta VRAM tienen los nodos de una GPU render farm? A: Varía según la render farm y la generación de tarjeta, así que verifique el modelo de tarjeta específico en lugar de aceptar una afirmación genérica; nuestros nodos de GPU ejecutan tarjetas RTX 5090 con 32 GB de VRAM cada una. La VRAM es el límite práctico en la complejidad de la escena para el renderizado de GPU —las funciones fuera del núcleo pueden transferir algunos datos a la memoria del sistema con un costo de rendimiento, pero una escena que genuinamente supera la VRAM pertenece a una render farm de CPU—.

Q: ¿Necesito acceso a escritorio remoto para usar una GPU render farm? A: No en una render farm gestionada —el flujo de trabajo es cargar, renderizar, descargar: empaqueta una escena, la render farm la sincroniza y renderiza, y usted descarga los fotogramas terminados—. Las sesiones de escritorio remoto son el modelo operativo de los alquileres de IaaS de GPU, 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.