12 de noviembre de 2026 · Equipo de VRAMfarm

Blender en una GPU alquilada: Cycles sin interfaz, varias máquinas, Octane y Redshift

El cliente quiere 240 fotogramas de un recorrido por un interior para mañana por la mañana. Cada fotograma tarda 4 minutos en la RTX 3070 que tienes en casa, así que el trabajo necesita 16 horas y tú tienes 10. En tarjetas alquiladas, esos mismos fotogramas tardan unos 1,5 minutos cada uno en una RTX 4090, y repartidos entre cuatro servidores la secuencia completa está lista en menos de dos horas, por más o menos el mismo dinero que renderizarla en una sola tarjeta. Cycles, el motor de Blender, encaja bien aquí: funciona desde la línea de comandos, no necesita licencia y usa el trazado de rayos OptiX de NVIDIA en cualquier tarjeta RTX.

Qué tarjeta: los núcleos RT importan más que la etiqueta de centro de datos

Cycles con OptiX usa los núcleos RT de las tarjetas RTX para trazar rayos. Las grandes GPU de centro de datos (A100, H100, H200, B200) no tienen ningún núcleo RT. Cycles funciona igualmente en ellas, pero una RTX 4090 renderiza el mismo fotograma más rápido por una fracción del precio por hora. Para renderizar, fíjate en las tarjetas RTX y en las de la serie L.

Las proporciones son aproximadas. El benchmark Blender Open Data recoge puntuaciones medidas de casi todas estas tarjetas en cada versión de Blender, y es la mejor forma de compararlas. Después compara la puntuación con el precio por hora de nuestra página de precios: para trabajos largos durante la noche, la 3090 suele ganar por fotograma; cuando la entrega aprieta, ganan la 4090 y la 5090.

Cuánta VRAM necesita una escena

Cycles en la GPU necesita toda la escena en la memoria de vídeo: la geometría, la estructura de aceleración (BVH), las texturas y los búferes del fotograma. Si no cabe, Cycles puede pasar parte de los datos a la RAM del sistema, pero el render se ralentiza muchísimo, y las escenas muy grandes directamente fallan.

Algunas referencias:

• Fotos de producto, motion graphics, interiores sencillos: 2–8 GB. Cualquier tarjeta del catálogo.
• Arquitectura detallada con texturas 4K: 8–20 GB. Tarjetas de 24 GB.
• Vegetación dispersa, exteriores grandes, muchas texturas 8K: 20–45 GB. Una textura 8K sin comprimir con canal alfa ocupa unos 256 MB en 8 bits y cuatro veces más en coma flotante, así que cincuenta de ellas suman rápido. Tarjetas de 48 GB.
• Escenas a escala de cine, multitudes o bosques enormes con instancias: 48–96 GB. RTX PRO 6000.

Para saber tu cifra, renderiza un fotograma en tu ordenador y mira el pico de memoria en la barra de estado, o renderiza un fotograma de prueba en el servidor mientras vigilas nvidia-smi. Simplifica donde sale barato: las texturas de objetos lejanos rara vez necesitan 8K, y el límite de tamaño de texturas de Cycles (Render Properties → Simplify) es una forma rápida de comprobar cuánto ahorras. La guía de VRAM aplica la misma lógica a los modelos de IA.

Cómo llevar la escena al servidor

Un .blend que se renderiza perfectamente en casa a menudo falla en un servidor porque apunta a texturas en C:\Users\.... Antes de subirlo:

1. File → External Data → Make Paths Relative, y después Pack Resources para meter las texturas dentro del .blend. O déjalas en carpetas junto al archivo, con rutas relativas, y comprime en zip toda la carpeta del proyecto.
2. Hornea las simulaciones (fluidos, tela, partículas, cachés de geometry nodes) en casa e incluye las carpetas de caché. Un servidor no va a volver a simular lo que no encuentra.
3. Revisa los add-ons. Los add-ons que intervienen en el render también tienen que estar instalados en el Blender del servidor. La mayoría de las escenas no necesitan ninguno.
4. Configura la salida en el archivo: formato (PNG, u OpenEXR si vas a componer después), resolución, muestras y rango de fotogramas. En animaciones, activa Persistent Data (Render Properties → Performance): así Cycles mantiene la escena cargada entre fotogramas.

Sube el zip con el botón de subida de Jupyter, con scp/rsync por SSH (guía de claves SSH), o déjalo en tu propio almacenamiento en la nube y descárgalo en el servidor con wget o rclone. Con varias máquinas, la última opción es la más cómoda: cada servidor descarga el mismo enlace. Las descargas cuentan como tráfico con la tarifa de la máquina, que ves antes de lanzar.

Instalar Blender y renderizar desde la línea de comandos

Lanza un servidor vacío de PyTorch + Jupyter; da igual que venga con PyTorch. Abre un terminal en Jupyter o por SSH. Instala las pocas librerías del sistema que Blender espera y descarga la misma versión de Blender que usas en casa (copia el enlace de Linux desde blender.org):

apt-get update && apt-get install -y xz-utils libxrender1 libxi6 libxkbcommon0 \
  libxxf86vm1 libxfixes3 libsm6 libgl1 libegl1
cd /workspace
wget <Linux link for your Blender version from blender.org/download>
tar -xf blender-*-linux-x64.tar.xz && mv blender-*-linux-x64 blender

Si al arrancar Blender se queja de que falta un archivo .so, instala el paquete que indica y vuelve a intentarlo. Después guarda esto como /workspace/gpu.py. Pone Cycles en OptiX en todas las GPU de la máquina, diga lo que diga el archivo .blend:

import bpy
prefs = bpy.context.preferences.addons["cycles"].preferences
prefs.compute_device_type = "OPTIX"
prefs.get_devices()
for d in prefs.devices:
    d.use = d.type == "OPTIX"
    print("device:", d.name, d.type, d.use)
bpy.context.scene.cycles.device = "GPU"

Renderiza la animación:

cd /workspace/project
nohup /workspace/blender/blender -b scene.blend --python /workspace/gpu.py \
  -o /workspace/render/frame_#### -s 1 -e 240 -a > /workspace/render.log 2>&1 &
tail -f /workspace/render.log

El orden importa: el script de Python y las opciones de salida, inicio y fin tienen que ir antes de -a. Lo primero que muestra el log son los dispositivos. Si no aparece ningún dispositivo OptiX, el contenedor no ve la librería de OptiX; cambia "OPTIX" por "CUDA" en los dos sitios. CUDA es más lento que OptiX en las tarjetas RTX, pero funciona en todas. Renderizar un solo fotograma con -f 1 en lugar de -a es una buena prueba antes de la tirada completa.

nohup mantiene el render en marcha aunque cierres el navegador o pierdas la conexión. Un render activo mantiene ocupada la GPU, así que la protección por inactividad no lo detiene. Cuando se escribe el último fotograma, la GPU se queda quieta: si no hay nada conectado, recibes un aviso de inactividad al cabo de unas dos horas, y una hora después el servidor guarda /workspace (fotogramas incluidos) y se detiene. Sale más barato detenerlo tú en cuanto hayas descargado los fotogramas.

Varias máquinas para una misma entrega

Cycles renderiza cada fotograma por separado, así que la granja más sencilla es repartir el rango de fotogramas:

Cuatro es también el máximo de servidores que una cuenta puede tener en marcha a la vez. Lánzalos con el mismo modelo de tarjeta para que terminen a la vez, haz la misma preparación en todos (un pequeño script de shell que pegas en cada terminal evita errores) y arranca cada uno con su rango. Cuando terminen, comprime /workspace/render en cada uno, descárgalo y junta los fotogramas en una carpeta. Tu editor o el secuenciador de vídeo de Blender se encarga de montarlos.

Cuatro servidores cuestan más o menos lo mismo en tiempo de GPU que uno solo haciendo todos los fotogramas, más los minutos de preparación de cada uno (descarga de Blender y subida de la escena, unos 10 minutos) y el mínimo de 15 minutos por lanzamiento. Pagas un poco más por terminar cuatro veces antes. Para trabajos más grandes o habituales, la API de VRAMfarm lanza, lista y detiene servidores desde un script, así que un script de render puede detener su propio servidor en cuanto escribe el último fotograma.

Octane y Redshift: con tu propia licencia

Los dos funcionan en tarjetas NVIDIA alquiladas, pero a diferencia de Blender son motores comerciales, y la licencia corre de tu cuenta. No ofrecemos licencias de ninguno de los dos.

OctaneRender (OTOY) solo funciona en GPU y corre en Linux. Inicias sesión con tu cuenta de OTOY en cada servidor, y tu nivel de suscripción decide cuántas GPU pueden renderizar a la vez; compruébalo antes de lanzar cuatro máquinas. Las condiciones de OTOY deciden si una licencia se puede usar en hardware alquilado, así que léelas para tu plan. La edición de Octane para Blender es una compilación aparte de Blender con su propia instalación; sigue la documentación de OTOY para renderizarla desde la línea de comandos.

Redshift (Maxon) se licencia a través de tu cuenta de Maxon, con un puesto por cada máquina que renderiza a la vez. En un servidor Linux sin interfaz inicias sesión con la herramienta de licencias de línea de comandos de Maxon. El render en sí va por redshiftCmdLine con archivos de escena .rs exportados, o por el renderizador por lotes de la aplicación anfitriona (Houdini, Maya o el renderizador de línea de comandos de Cinema 4D). Revisa las condiciones actuales de Maxon para nodos de render antes de planificar un trabajo con varias máquinas.

Hay dos detalles prácticos que valen para los dos. Instala la misma versión que tienes en local, para que la escena se renderice igual. Y comprueba la versión del driver de la máquina antes de lanzar, porque los motores de render por GPU exigen un driver mínimo; la guía de CUDA y drivers explica qué mirar. Las herramientas que necesitan escritorio, como el Unreal Editor o la interfaz de DaVinci Resolve, encajan mal en servidores sin interfaz y no las tratamos aquí.

Coste por fotograma: calcúlalo antes de alquilar

La fórmula es sencilla: precio por hora × minutos por fotograma ÷ 60. Lo difícil son los minutos por fotograma, así que mídelos: renderiza el fotograma 1 en el servidor que has alquilado y multiplica. Un lanzamiento de prueba cuesta como mínimo los 15 minutos del mínimo, algo más con la preparación.

Nuestro ejemplo de 240 fotogramas, a 1,5 minutos por fotograma en una RTX 4090:

• Un servidor: 240 × 1,5 = 360 minutos, más 10 minutos de preparación: unas 6 h 10 min, 3,64 €, terminado en unas seis horas.
• Cuatro servidores: 60 × 1,5 = 90 minutos cada uno, más 10 minutos de preparación: 100 minutos cada uno, 6 h 40 min en total, 3,94 €, terminado en menos de dos horas.
• En una RTX 3090, a unos 3 minutos por fotograma y con un solo servidor: unas 12 h 10 min, 3,65 €, si la entrega lo permite.

Suma el tráfico de la escena y de los fotogramas con la tarifa de la máquina. Los fotogramas suelen ser la parte más grande: 240 fotogramas en OpenEXR a 1080p pueden ocupar varios gigas.

Para bajar los minutos por fotograma, las palancas habituales de Cycles son menos muestras con denoising (OptiX u OpenImageDenoise), el muestreo adaptativo, Persistent Data en animaciones y menos rebotes de luz donde la escena no los necesita. Pruébalas en el fotograma 1 antes de lanzar la granja, porque cada segundo que ahorras se multiplica por 240.