
Redshift Render Farm: guía 2026 de renderizado en la nube con GPU
Resumen
Redshift es un motor de renderizado sesgado y acelerado por GPU — en nuestra render farm, y en cualquier render farm que conozcamos, funciona exclusivamente con hardware GPU, sin ninguna ruta de renderizado por CPU. Los artistas recurren a él en Cinema 4D, Maya, 3ds Max y Houdini por las mismas tres razones: está construido en torno a la tarjeta gráfica, se mantiene predecible bajo presión de entrega, y viene integrado en las aplicaciones que ya usa la mayoría de los pipelines de producción. Redshift también es un motor habitual para tomas de vehículos y producto; nuestra guía de render farm para renderizado automotriz cubre esa carga de trabajo en una render farm con GPU.
Esta guía es una referencia única para ejecutar Redshift en una render farm en la nube, sin importar en cuál de esas cuatro aplicaciones construya sus escenas. Una render farm no cambia cómo ilumina o texturiza un fotograma; cambia lo que sucede cuando pulsa render. En lugar de una sola estación de trabajo procesando una secuencia durante toda la noche, muchas máquinas GPU toman los fotogramas en paralelo y los devuelven en una fracción del tiempo real. Los factores que importan — VRAM, licencias, transferencia de archivos y costo — son los mismos tanto si su escena de Redshift empezó en Cinema 4D como en Houdini, y por eso conviene tratar "Redshift en una render farm" como un solo tema en lugar de cuatro por separado.

Flujo de renderizado en la nube con Redshift — Cinema 4D, Maya, 3ds Max y Houdini alimentan un mismo motor Redshift, y las escenas se suben a una flota de GPU que renderiza fotogramas en paralelo para su descarga
Por qué Redshift renderiza en la GPU — y qué significa eso en una render farm
Redshift es, ante todo, un renderizador GPU. Utiliza las rutas CUDA y OptiX de la tarjeta gráfica para trazar rayos, lo que le da 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 — esa es la ruta para la que está aprovisionado nuestro hardware, y conviene ser precisos al respecto, porque Redshift como producto también incorporó un modo de renderizado por CPU en la versión 3.5. En nuestra render farm, Redshift es solo GPU; aquí no existe ninguna ruta de renderizado por CPU para él. Si ha ajustado una escena para el backend de CPU, planifique validarla contra la salida de GPU antes de comprometer una secuencia larga.
Ese diseño centrado en la GPU es lo que hace de Redshift una opción natural para el renderizado distribuido. Los fotogramas son unidades de trabajo independientes, por lo que una secuencia que a una sola tarjeta le toma ocho horas puede repartirse entre muchas tarjetas y devolverse mucho antes. El trabajo de una render farm es mantener esas tarjetas alimentadas, resolver las licencias y entregarle los fotogramas — nada de lo cual debería requerir que usted piense en las máquinas subyacentes.
Una render farm también elimina el cuello de botella de GPU más común para los artistas independientes: la cantidad de tarjetas. En local, usted renderiza con las una o dos GPU de su torre. En una render farm, la limitación pasa de "cuántas tarjetas tengo" a "cómo empaqueto la escena para que las tarjetas puedan leerla" — un problema mucho más fácil de resolver, y que tratamos en la sección de flujo de trabajo más abajo. Si tiene curiosidad por saber cuánto rinde realmente una segunda (o vigésima) tarjeta en la práctica, nuestro benchmark de escalado multi-GPU mide los tiempos de renderizado con 1 GPU frente a 2 GPU directamente, en lugar de asumir un escalado lineal.
Redshift en cuatro aplicaciones: Cinema 4D, Maya, 3ds Max y Houdini
Redshift se comporta de forma consistente entre aplicaciones anfitrionas porque el motor es el mismo; lo que cambia es el plugin puente y cómo cada aplicación exporta los datos de la escena. Ofrecemos soporte para Redshift en las cuatro DCC donde más lo usan nuestros clientes:
- Cinema 4D. Aquí Redshift está estrechamente integrado — es un producto de Maxon, y Cinema 4D es una aplicación de Maxon, por lo que el sistema de materiales, la vista de render y el sistema de tomas se sienten nativos. Es el emparejamiento con Redshift más maduro que vemos, y el que tiene el historial más largo de escenas listas para render farm. Para un análisis específico de Cinema 4D — incluyendo detalles de flujo de trabajo de motion design que van más allá de lo que cubre esta guía multi-DCC — consulte nuestra guía de render farm de Redshift para Cinema 4D.
- Maya. Redshift para Maya es una integración consolidada y probada en producción, con soporte completo para las capas de renderizado de Maya, los AOV y el flujo de trabajo habitual de materiales basado en nodos. Las escenas referencian texturas y cachés a través de la estructura de proyecto de Maya, por lo que la principal consideración en la render farm es asegurarse de que esas rutas se resuelvan una vez que los archivos salen de su máquina.
- 3ds Max. La integración con 3ds Max cubre la configuración del renderizador, el editor de materiales y los render elements que cabría esperar. Aquí Redshift se usa con frecuencia junto a plugins de dispersión ("scatter") y proxy, así que los proxies y las referencias externas son lo que hay que empaquetar con cuidado.
- Houdini. Redshift en Houdini es la opción GPU que muchos artistas combinan con simulación pesada y trabajo de instancing intensivo, junto a Karma y Mantra. Si su pipeline es primero Houdini, nuestra página de render farm en la nube para Houdini cubre el panorama más amplio del motor para esa aplicación.
En las cuatro, la licencia del motor de renderizado está incluida en lo que paga por renderizar — no se le pide que aporte su propio asiento de licencia de Redshift. Como partner 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 cada aplicación compatible sin ninguna configuración de su parte. Puede verificar ese estado de partner directamente en el directorio de partners de Maxon.

Cinema 4D, Maya, 3ds Max y Houdini alimentando un mismo motor Redshift en una render farm GPU, con la licencia de Redshift incluida en la tarifa de renderizado
VRAM, out-of-core y escenas grandes
Para el renderizado GPU, la VRAM es el número que decide si una escena renderiza sin problemas o se atasca. Redshift carga geometría, texturas y otros datos de la escena en la memoria de la tarjeta; cuando una escena cabe, la tarjeta rinde a plena capacidad. Nuestra flota de GPU da a cada trabajo de Redshift 32 GB de VRAM con los que trabajar en una NVIDIA RTX 5090, lo que cubre un amplio rango de escenas de producción sin necesidad de manejo especial.
Cuando los datos de una escena superan la VRAM disponible, Redshift no falla simplemente — recurre a su tecnología out-of-core, paginando texturas y geometría desde la memoria del sistema a medida que la tarjeta las necesita. Esta es la respuesta honesta a "¿qué pasa con mi escena pesada?": Redshift puede renderizar escenas más grandes que la VRAM disponible mediante out-of-core, con cierto costo de rendimiento, porque la tarjeta debe acceder a una memoria más lenta. Es una técnica de GPU, no una cesión a un renderizador de CPU — el fotograma se sigue calculando en la RTX 5090, solo que con acceso a memoria más lento para la porción que no cabe en los 32 GB de la tarjeta. En la práctica, la forma de mantener rápida una escena de Redshift pesada es reducir primero la presión innecesaria sobre la VRAM — tamaños de textura razonables, proxies para geometría repetida y recortar lo que realmente aparece en cuadro — y dejar que el out-of-core absorba el resto.
Si está evaluando si los 32 GB de la RTX 5090 son margen suficiente para su trabajo en particular, nuestro análisis sobre el rendimiento de renderizado en la nube con GPU de la RTX 5090 repasa cómo se comporta la tarjeta en escenas reales, y nuestro benchmark de escalado multi-GPU muestra qué hace realmente añadir una segunda tarjeta al tiempo real en una escena comparable.

Gráfico del uso de VRAM aumentando con la complejidad de la escena, cruzando la línea de 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
Servicio totalmente gestionado frente a alquilar usted mismo una máquina GPU
Hay dos formas generales de renderizar Redshift en la nube, y la diferencia importa más que la especificación del hardware.
La primera es el alquiler de infraestructura, donde usted alquila una máquina GPU remota, se conecta mediante escritorio remoto, instala Redshift y su aplicación anfitriona usted mismo, resuelve la licencia, copia sus archivos y gestiona el render. Obtiene una máquina desnuda y control total, junto con toda la configuración y el mantenimiento que eso implica.
La segunda es una render farm totalmente gestionada, que es como operamos nosotros. Usted sube su escena, el motor y las licencias ya están dispuestos, los fotogramas se distribuyen por la flota de GPU — tarjetas RTX 5090, 32 GB de VRAM cada una — por usted, y usted recoge el resultado. No hay ningún 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 hacer imágenes — y es lo principal que separa una render farm gestionada de los alquileres de GPU como infraestructura como servicio que quizás haya usado. Nuestra página de render farm en la nube para Redshift es el lugar al que dirigir a un compañero de equipo que quiera la versión breve.
Qué modelo le conviene depende de cuánto control necesite sobre el entorno. Si tiene una cadena de plugins inusual o una configuración a medida, una máquina en bruto 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 mucho menos esfuerzo.
Qué cuesta renderizar con Redshift en una render farm
El renderizado GPU en nuestra render farm se factura por uso en lugar de por un plan mensual. La unidad es la hora-OctaneBench (OBh) — una medida del trabajo de GPU realizado — cobrada a una tarifa base de 0,003 $ por OBh. En términos prácticos, una tarjeta RTX 5090 equivale a aproximadamente 5,20 $ por hora-tarjeta de renderizado. Usted paga por el tiempo de GPU que realmente consumen sus fotogramas, no por un asiento o un nivel de suscripción.
La misma facturación por hora-GPU se aplica a los trabajos de Octane; nuestra guía de render farm en la nube para Octane explica cómo se ejecutan las escenas de Octane en la flota.
Algunos detalles específicos que suelen surgir:
- La licencia está incluida. La licencia de Redshift forma parte de la tarifa de renderizado. Lo mismo ocurre con los demás 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 lo gasta en trabajos; los créditos de pago siguen siendo válidos para cuando los necesite. Las cuentas nuevas también empiezan con 25 $ de crédito de prueba para dimensionar un trabajo real antes de comprometerse con una secuencia.
- Sin niveles. Cada cuenta renderiza a la misma tarifa basada en uso. No hay ningún plan que elegir ni ninguna función bloqueada detrás de un nivel superior.
Para estimar un trabajo, tome el tiempo que necesita un fotograma en una tarjeta comparable, multiplíquelo por su número de fotogramas y aplique la cifra de hora-tarjeta — al distribuirse por la flota, el tiempo real se reduce, pero las horas-GPU facturadas se mantienen aproximadamente iguales al trabajo total realizado. Renderizar una toma de 10 segundos a 24 fps son 240 fotogramas; si cada fotograma le toma cuatro minutos a una tarjeta, son unas 16 horas-tarjeta de trabajo, o en torno a 83 $ a la tarifa práctica — devueltos en una fracción muy pequeña de ese tiempo real porque los fotogramas se ejecutan en paralelo en varias tarjetas RTX 5090 en lugar de encolarse en una sola.

Ejemplo de costo calculado para una toma de 240 fotogramas: las horas-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 gran opción cuando quiere velocidad de GPU con la controlabilidad de un renderizador sesgado, y cuando su aplicación anfitriona es una de las cuatro anteriores. No es la única opción, y parte de elegir bien es saber dónde se sitúa respecto a las alternativas.
- Frente a Arnold, la disyuntiva es la velocidad e interactividad de Redshift con GPU sesgada frente a la reputación de Arnold por una salida no sesgada y físicamente fundamentada en CPU y GPU. Comparamos ambos para el trabajo en render farm en Arnold frente a Redshift en una render farm.
- Frente a Octane, ambos son renderizadores GPU con distintas filosofías de shading y soporte de aplicaciones anfitrionas. Nuestra comparativa de Octane frente a Redshift desglosa cómo difieren en la práctica.
- Frente a Cycles, el motor integrado de Blender, la comparación tiene menos que ver con GPU-solo frente a CPU-solo y más con el ecosistema — Cycles se ejecuta tanto en CPU como en GPU según las necesidades de la escena, mientras que Redshift en nuestra render farm es solo GPU en las cuatro DCC compatibles.
Una render farm no le ata a un solo motor — el mismo modelo de subir y renderizar 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, y no una de hosting.
El flujo de trabajo de subida, renderizado y descarga
Llevar una escena de Redshift a la render farm sigue los mismos tres pasos sin importar la aplicación anfitriona.
Subida. Empaquete su escena con sus activos — texturas, proxies, cachés y referencias. La subida web no tiene un límite de tamaño estricto, aunque sugerimos mantener las subidas individuales por debajo de unos 300 GB; para algo más grande, SFTP o nuestra aplicación de escritorio le dan una transferencia reanudable y paralela. Los formatos de archivo comprimido admitidos son tar, tar.gz y 7z; .zip no es compatible, así que reempaquete o transfiera los archivos sin comprimir si esa es su única opción. La causa más común de un trabajo de GPU atascado con diferencia es una ruta de activo 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 subir.
Renderizado. Envíe el trabajo y los fotogramas se distribuyen por la flota de GPU. Como aquí los trabajos de Redshift son solo GPU, cada fotograma llega a una RTX 5090 con sus 32 GB de VRAM, y el out-of-core cubre las escenas que necesitan más.
Descarga. Los fotogramas terminados están disponibles para recuperarlos por la web, por SFTP o automáticamente mediante la aplicación de escritorio. El resultado se conserva durante 45 días después de que un trabajo se completa, tras lo cual se elimina — así que descargue con prontitud o deje que la aplicación de escritorio lo descargue automáticamente a su almacenamiento local.
Una breve lista de comprobación antes de enviar un trabajo de Redshift
| Comprobación | Por qué importa |
|---|---|
| Activos externos recopilados o reenlazados | Las rutas no resueltas son la principal causa de trabajos de GPU atascados |
| Tamaños de textura y proxies razonables | Mantiene la escena dentro de la VRAM y fuera del out-of-core cuando sea posible |
| Ruta de salida y AOV configurados | Evita tener que volver a renderizar por una pasada faltante |
| El archivo comprimido es tar, tar.gz o 7z | .zip no es compatible en la subida |
| Rango y paso de fotogramas correctos | Pague por los fotogramas que necesita, no por otros extra |
| Un fotograma de prueba renderizado primero | Los 25 $ de crédito de prueba bastan para confirmar los ajustes antes de la secuencia completa |
Repasar esta lista lleva unos minutos y elimina casi todos los motivos evitables por los que un trabajo vuelve mal.
FAQ
Q: ¿Redshift es solo GPU en una render farm? A: En nuestra render farm, sí — cada trabajo de Redshift se ejecuta en GPU, en concreto en tarjetas NVIDIA RTX 5090 con 32 GB de VRAM cada una, sin ninguna ruta de renderizado por CPU. Redshift como producto añadió un modo de CPU a partir de la versión 3.5, pero ese modo no es el que se ejecuta aquí; nuestro hardware y nuestro pipeline están aprovisionados para el renderizado de Redshift solo con GPU. Si ha ajustado una escena contra el backend de CPU en otro lugar, valídela contra la salida de GPU antes de comprometer una secuencia completa.
Q: ¿Cuánto cuesta una render farm de Redshift? A: En nuestra render farm, el renderizado GPU se factura por uso a 0,003 $ por hora-OctaneBench, lo que equivale a aproximadamente 5,20 $ por hora-tarjeta de RTX 5090. La licencia de Redshift está incluida en esa tarifa — no hay una tarifa de licencia separada — y los créditos nunca caducan. Las cuentas nuevas empiezan con 25 $ de crédito de prueba, suficiente para dimensionar un trabajo real antes de comprometerse con un render completo.
Q: ¿La render farm renderiza Redshift en la GPU o en la CPU? A: Solo GPU. Nuestros trabajos de Redshift se ejecutan en una flota dedicada de NVIDIA RTX 5090 con 32 GB de VRAM por tarjeta. Redshift como producto añadió un modo de CPU en la versión 3.5, pero en nuestra render farm no existe ninguna ruta de renderizado por CPU para Redshift — si ha ajustado una escena para el backend de CPU, valídela primero contra la salida de GPU.
Q: ¿Desde qué aplicaciones puedo renderizar Redshift? A: Cinema 4D, Maya, 3ds Max y Houdini. El motor es el mismo en las cuatro; solo difieren el plugin puente y la exportación de la escena de la aplicación anfitriona. 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 usa 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 se sigue renderizando en la GPU, con cierto costo de rendimiento. Reducir los tamaños de textura y usar proxies mantiene más de la escena residente en la VRAM y rápida.
Q: ¿Necesito mi propia licencia de Redshift? A: No. La licencia de Redshift está incluida en lo que paga por renderizar. Como partner oficial de Maxon, licenciamos Redshift para uso de renderizado en la render farm, así que está disponible en cada aplicación compatible sin nada que activar de su parte.
Q: ¿Cómo se tarifica el renderizado de Redshift en el día a día, y hay niveles? A: No hay niveles de plan — cada cuenta renderiza a la misma tarifa basada en uso descrita arriba. La licencia está incluida en esa tarifa para cada motor que ejecutamos, no solo Redshift, así que no hay ninguna línea aparte que presupuestar sin importar desde cuál de las cuatro aplicaciones compatibles renderice.
Q: ¿Cómo subo mi escena a la render farm, y cuánto tiempo se conservan mis fotogramas después?
A: Suba la escena empaquetada por la web (sin límite de tamaño estricto; sugerimos menos de unos 300 GB por subida), o use SFTP o la aplicación de escritorio para transferencias más grandes o reanudables. Use archivos comprimidos tar, tar.gz o 7z — .zip no es compatible — y recopile o reenlace los activos externos antes de subir para que las rutas se resuelvan en la render farm. Una vez renderizados los fotogramas, el resultado se conserva 45 días tras completarse el trabajo, y después se elimina automáticamente — descargue por la web, por SFTP o con la descarga automática de la aplicación de escritorio antes de ese plazo, o configure la descarga automática para conservar una copia local.
About Thierry Marc
3D Rendering Expert with over 10 years of experience in the industry. Specialized in Maya, Arnold, and high-end technical workflows for film and advertising.



