Redshift Render Farm: Guía 2026 sobre renderizado en la nube con GPU

Redshift es uno de los motores sobre los que más preguntas recibimos en nuestra render farm. Es un motor de renderizado con aceleración GPU y sesgo hacia la producción, diseñado para la velocidad, y los artistas suelen elegirlo por tres razones: está diseñado en torno a la tarjeta gráfica, se comporta de forma predecible bajo plazos de entrega ajustados, y viene integrado en las cuatro aplicaciones con las que ya trabajan la mayoría de nuestros clientes: Cinema 4D, Maya, 3ds Max y Houdini.

Esta guía es una referencia única para ejecutar Redshift en una render farm en la nube, independientemente de la aplicación con la que construya sus escenas. Una render farm no cambia la forma en que ilumina o texturiza un fotograma; cambia lo que ocurre cuando pulsa renderizar. En lugar de que una sola estación de trabajo procese una secuencia durante toda la noche, muchas máquinas GPU recogen los fotogramas en paralelo y los devuelven en una fracción del tiempo real. Las variables que importan — VRAM, licencias, transferencia de archivos y costo — son las mismas tanto si su escena de Redshift comenzó en Cinema 4D como en Houdini, razón por la cual conviene tratar "Redshift en una render farm" como un único tema en lugar de cuatro temas separados.

Flujo de renderizado en la nube de Redshift: Cinema 4D, Maya, 3ds Max y Houdini alimentan un único motor Redshift, luego las escenas se cargan a una flota de GPU que renderiza los fotogramas en paralelo para su descarga

Por qué Redshift renderiza en GPU — y qué significa esto en una render farm

Redshift es ante todo un motor GPU. Utiliza los caminos CUDA y OptiX de la tarjeta gráfica para trazar rayos, lo que le confiere la sensación interactiva que los artistas asocian con él. En nuestra render farm, cada trabajo de Redshift se ejecuta en una flota de GPU dedicada construida sobre tarjetas NVIDIA RTX 5090 con 32 GB de VRAM cada una. Ejecutamos Redshift en modo GPU — ese es el camino para el que está aprovisionado nuestro hardware, y merece la pena ser preciso al respecto, porque el producto Redshift también incorporó un modo de renderizado CPU en la versión 3.5. En nuestra render farm, Redshift es exclusivamente GPU; no existe un camino de renderizado CPU aquí. Si ha ajustado una escena para el backend de CPU, planifique validarla frente a la salida GPU antes de comprometerse con una secuencia larga.

Ese diseño GPU-primero es lo que hace de Redshift una opción natural para el renderizado distribuido. Los fotogramas son unidades de trabajo independientes, de modo que una secuencia que a una sola tarjeta le llevaría ocho horas puede repartirse entre muchas tarjetas y devolverse en mucho menos tiempo. El trabajo de una render farm es mantener esas tarjetas ocupadas, gestionar las licencias y entregarle los fotogramas — nada de lo cual debería requerir que piense en las máquinas subyacentes.

Una render farm también elimina el cuello de botella GPU más común para los artistas independientes: el número de tarjetas. Localmente, renderiza con una o dos GPU de su equipo. En una render farm, la restricción pasa de "cuántas tarjetas poseo" a "cómo empaqueto la escena para que las tarjetas puedan leerla" — un problema mucho más fácil de resolver, y uno que cubrimos en la sección de flujo de trabajo más adelante.

Redshift en cuatro aplicaciones: Cinema 4D, Maya, 3ds Max y Houdini

Redshift se comporta de forma consistente en todas las aplicaciones anfitrionas porque el motor es el mismo; lo que difiere es el plugin puente y la forma en que cada aplicación exporta los datos de la escena. Admitimos Redshift en los cuatro DCCs donde más lo usan nuestros clientes:

• Cinema 4D. Redshift está muy integrado aquí — es un producto de Maxon, y Cinema 4D es una aplicación de Maxon, por lo que el sistema de materiales, la vista de renderizado y el sistema de tomas se sienten nativos. Esta es la combinación de Redshift más madura que vemos, y la que tiene el historial más largo de escenas listas para render farm. Para una guía específica de Cinema 4D, consulte nuestra guía de render farm Redshift para Cinema 4D.
• Maya. Redshift para Maya es una integración consolidada y de nivel productivo con soporte completo para las capas de renderizado, AOVs y el flujo de trabajo habitual de materiales basado en nodos. Las escenas referencian texturas y caches a través de la estructura de proyecto de Maya, por lo que la principal consideración para la render farm es asegurarse de que esas rutas se resuelven una vez que los archivos salen de su máquina.
• 3ds Max. La integración con 3ds Max cubre la configuración del motor de renderizado, el editor de materiales y los elementos de renderizado que cabría esperar. Redshift en este entorno se usa frecuentemente junto con plugins de dispersión y proxies, por lo que los proxies y las referencias externas son los elementos que hay que empaquetar con más cuidado.
• Houdini. Redshift en Houdini es la opción GPU que muchos artistas combinan con trabajo pesado de simulación e instanciación, junto a Karma y Mantra. Si su pipeline es Houdini-first, nuestra página de render farm en la nube para Houdini cubre el panorama completo de motores para esa aplicación.

En los cuatro casos, la licencia del motor de renderizado está incluida en lo que paga por renderizar — no se le pide que aporte su propio asiento de Redshift. Como socio oficial de Maxon, licenciamos Redshift (y el resto de la línea Maxon) para uso de renderizado en la render farm, lo que permite que el motor esté disponible en todas las aplicaciones compatibles sin ninguna configuración de su parte. Puede verificar ese estado de socio directamente en el directorio de socios de Maxon.

Cinema 4D, Maya, 3ds Max y Houdini alimentando todos un único motor Redshift en una render farm de GPU, con la licencia de Redshift incluida en la tarifa de renderizado

VRAM, out-of-core y escenas de gran tamaño

Para el renderizado GPU, la VRAM es el número que decide si una escena se renderiza limpiamente o se bloquea. Redshift carga la geometría, las texturas y otros datos de la escena en la memoria de la tarjeta; cuando una escena cabe, la tarjeta funciona a pleno rendimiento. Nuestra flota de GPU proporciona a cada trabajo de Redshift 32 GB de VRAM con los que trabajar, lo que cubre una amplia gama de escenas de producción sin necesidad de gestión especial.

Cuando los datos de una escena superan la VRAM disponible, Redshift no falla sin más — recurre a su tecnología out-of-core, paginando texturas y geometría desde la memoria del sistema según las necesita la tarjeta. Esta es la respuesta honesta a la pregunta "¿qué ocurre con mi escena pesada?": Redshift puede renderizar escenas que superan la VRAM mediante out-of-core, con algún costo en rendimiento, porque la tarjeta tiene que acceder a una memoria más lenta. Es una técnica de GPU, no una transferencia a un motor de CPU. En la práctica, la forma de mantener una escena de Redshift pesada ágil es reducir primero la presión innecesaria sobre la VRAM — tamaños de textura razonables, proxies para geometría repetida y eliminar lo que no está en plano — y dejar que out-of-core absorba el resto.

Si está sopesando si los 32 GB de la RTX 5090 son suficiente margen para su trabajo específico, nuestro artículo sobre rendimiento de renderizado en la nube con GPU RTX 5090 explica cómo se comporta la tarjeta en escenas reales.

Gráfico del uso de VRAM que aumenta con la complejidad de la escena, cruzando la línea de los 32 GB de la RTX 5090 donde se activa el out-of-core de Redshift y continúa renderizando en la GPU con cierto costo de rendimiento

Render farm completamente gestionada frente a alquilar una máquina GPU usted mismo

Hay dos formas principales de renderizar Redshift en la nube, y la diferencia importa más que las especificaciones de hardware.

La primera es el alquiler de infraestructura, en el que se alquila una máquina GPU remota, se conecta a ella mediante escritorio remoto, se instala Redshift y la aplicación anfitriona manualmente, se gestionan las licencias, se copian los archivos y se administra el renderizado. Se obtiene una máquina básica y control total, junto con toda la configuración y el mantenimiento que eso implica.

La segunda es una render farm completamente gestionada, que es como operamos nosotros. Usted carga su escena, el motor y las licencias ya están en su lugar, los fotogramas se distribuyen por la flota de GPU automáticamente y usted recoge la salida. No hay escritorio remoto al que conectarse, nada que instalar y ninguna licencia que activar. Para un artista de Redshift esto elimina las partes del renderizado en la nube que no tienen nada que ver con la creación de imágenes — y es lo que principalmente diferencia una render farm gestionada de los alquileres de GPU de infraestructura como servicio que quizás haya utilizado. Nuestra página de render farm en la nube para Redshift es el lugar adecuado al que dirigir a un compañero que quiera la versión resumida.

El modelo que le conviene depende de cuánto control necesita sobre el entorno. Si tiene una cadena de plugins inusual o una compilación personalizada, una máquina básica puede ser la herramienta adecuada. Para la mayoría del trabajo con Redshift — una aplicación anfitriona estándar, el motor y su escena — una render farm gestionada devuelve los fotogramas con mucha menos carga operativa.

Cuánto cuesta el renderizado de Redshift en una render farm

El renderizado GPU en nuestra render farm se factura por uso y no por un plan mensual. La unidad es la OctaneBench-hora (OBh) — una medida del trabajo GPU realizado — con una tarifa base de $0,003 por OctaneBench-hora. En términos prácticos, una tarjeta RTX 5090 equivale a aproximadamente $5,20 por hora de tarjeta de renderizado. Usted paga por el tiempo de GPU que consumen sus fotogramas, no por un asiento ni por un nivel de suscripción.

Algunos detalles que suelen surgir:

• Las licencias están incluidas. La licencia de Redshift forma parte de la tarifa de renderizado. Lo mismo ocurre con los otros motores que ejecutamos — no hay una línea de licencia separada que presupuestar.
• Los créditos no caducan. Usted recarga un saldo de créditos y los gasta en trabajos; los créditos pagados siguen siendo válidos para cuando los necesite. Las nuevas cuentas también comienzan con $25 en crédito de prueba para dimensionar un trabajo real antes de comprometerse con una secuencia.
• Sin niveles. Todas las cuentas renderizan a la misma tarifa basada en uso. No hay ningún plan que elegir ni ninguna función condicionada a un nivel superior.

Para estimar un trabajo, tome el tiempo que necesita un fotograma en una tarjeta comparable, multiplíquelo por el número de fotogramas y aplique la cifra de horas de tarjeta — distribuido entre la flota el tiempo real se reduce drásticamente, pero las horas de GPU facturadas se mantienen aproximadamente igual al total de trabajo realizado. Renderizar un plano de 10 segundos a 24 fps son 240 fotogramas; si cada fotograma le lleva a una tarjeta cuatro minutos, eso equivale a unas 16 horas de tarjeta de trabajo, o alrededor de $83 a la tarifa práctica — devuelto en una pequeña fracción de ese tiempo real porque los fotogramas se ejecutan en paralelo.

Ejemplo de costo resuelto para un plano de 240 fotogramas: las horas de tarjeta facturadas son las mismas en una sola tarjeta GPU y en una render farm de 24 tarjetas, pero el tiempo real de la render farm es mucho más corto

Elegir Redshift, u otro motor, para el trabajo

Redshift es una buena opción cuando se desea la velocidad de GPU con la controlabilidad de un motor con sesgo, y cuando la aplicación anfitriona es una de las cuatro mencionadas. No es la única opción, y parte de elegir bien es saber dónde se sitúa en relación con las alternativas.

• Frente a Arnold, el intercambio es la velocidad e interactividad GPU con sesgo de Redshift frente a la reputación de Arnold por su salida sin sesgo y físicamente fundamentada en CPU y GPU. Comparamos los dos para el trabajo en render farm en Arnold vs. Redshift en una render farm.
• Frente a Octane, ambos son motores GPU con diferentes filosofías de sombreado y compatibilidad con aplicaciones anfitrionas. Nuestra comparativa Octane vs. Redshift detalla cómo difieren en la práctica.

Una render farm no le ata a un único motor — el mismo modelo de carga y renderizado se aplica a los demás motores que ejecutamos — por lo que la elección del motor puede seguir siendo una decisión creativa y de pipeline en lugar de una decisión de alojamiento.

El flujo de trabajo de carga, renderizado y descarga

Llevar una escena de Redshift a la render farm sigue los mismos tres pasos independientemente de la aplicación anfitriona.

Carga. Empaquete su escena con sus recursos — texturas, proxies, caches y referencias. La carga web no tiene un límite de tamaño fijo, aunque recomendamos mantener las cargas individuales por debajo de unos 300 GB; para tamaños mayores, SFTP o nuestra aplicación cliente le ofrece una transferencia reanudable y paralela. Los formatos de archivo compatibles son tar, tar.gz y 7z; .zip no está admitido, así que reempaquete o transfiera los archivos sin comprimir si es su única opción. La causa más frecuente de un trabajo GPU bloqueado es una ruta de recurso que se resolvía en su estación de trabajo pero no una vez que los archivos se movieron, así que recopile o reenlace las referencias externas antes de cargar.

Renderizado. Envíe el trabajo y los fotogramas se distribuyen por la flota de GPU. Dado que los trabajos de Redshift son exclusivamente GPU aquí, cada fotograma se asigna a una RTX 5090 con sus 32 GB de VRAM, y out-of-core cubre las escenas que necesitan más.

Descarga. Los fotogramas terminados están disponibles para descargarse a través de la web, por SFTP o automáticamente a través de la aplicación cliente. La salida se conserva durante 45 días después de que se completa un trabajo, tras lo cual se elimina — así que descargue con prontitud o deje que la aplicación cliente descargue automáticamente en su almacenamiento local.

Una breve lista de verificación antes de enviar un trabajo de Redshift

Trabajar con esta lista lleva unos pocos minutos y elimina prácticamente todas las razones evitables por las que un trabajo puede salir mal.

FAQ

Q: ¿La render farm renderiza Redshift en GPU o en CPU? A: Solo en GPU. Nuestros trabajos de Redshift se ejecutan en una flota dedicada de NVIDIA RTX 5090 con 32 GB de VRAM por tarjeta. El producto Redshift añadió un modo CPU en la versión 3.5, pero en nuestra render farm no existe un camino de renderizado CPU para Redshift — si ha ajustado una escena para el backend de CPU, valídela frente a la salida GPU primero.

Q: ¿Desde qué aplicaciones puedo renderizar Redshift? A: Cinema 4D, Maya, 3ds Max y Houdini. El motor es el mismo en los cuatro casos; solo difieren el plugin puente de la aplicación anfitriona y la exportación de la escena. La licencia de Redshift está incluida en la tarifa de renderizado en todos los casos.

Q: ¿Qué ocurre si mi escena supera los 32 GB de VRAM? A: Redshift utiliza la tecnología out-of-core para paginar texturas y geometría desde la memoria del sistema cuando una escena supera la VRAM disponible. La escena sigue renderizándose en la GPU, con algún costo en rendimiento. Reducir los tamaños de textura y usar proxies mantiene más escena residente en la VRAM y la hace más ágil.

Q: ¿Necesito mi propia licencia de Redshift? A: No. La licencia de Redshift está incluida en lo que paga por renderizar. Como socio oficial de Maxon, licenciamos Redshift para uso de renderizado en la render farm, por lo que está disponible en todas las aplicaciones compatibles sin nada que activar de su parte.

Q: ¿Cómo se cobra el renderizado de Redshift? A: El renderizado GPU se factura por uso a una tarifa base de $0,003 por OctaneBench-hora, lo que equivale a aproximadamente $5,20 por hora de tarjeta RTX 5090. Las licencias están incluidas, los créditos no caducan y las nuevas cuentas comienzan con $25 en crédito de prueba para dimensionar un trabajo real.

Q: ¿Cómo traslado mi escena y recursos a la render farm? A: Cargue la escena empaquetada a través de la web (sin límite de tamaño fijo; recomendamos menos de unos 300 GB por carga), o use SFTP o la aplicación cliente para transferencias más grandes o reanudables. Use archivos comprimidos tar, tar.gz o 7z — .zip no está admitido — y recopile o reenlace los recursos externos antes de cargar para que las rutas se resuelvan en la render farm.

Q: ¿Cuánto tiempo se conservan mis fotogramas renderizados? A: La salida se conserva durante 45 días después de que se completa un trabajo, y luego se elimina automáticamente. Descargue sus fotogramas a través de la web, SFTP o la descarga automática de la aplicación cliente antes de ese plazo, o configure la descarga automática para mantener una copia local.