Guía gratuita · 3D y render

PC para Blender: cuánta VRAM necesitás
y qué GPU rinde de verdad.

El hardware para 3D se compra distinto: acá no mandan los FPS sino la VRAM, el viewport no quiere lo mismo que el render, y un benchmark de gaming no te dice nada. Esta guía explica dónde está cada cuello de botella para que inviertas donde tu trabajo lo siente.

La herramienta de esta guía: el Blender Open Data Benchmark — gratuito y oficial — tiene los puntajes de render de prácticamente todas las GPUs y CPUs del mercado, medidos en Blender real. Antes de comprar cualquier componente para 3D, buscalo ahí. Es la diferencia entre elegir con datos y elegir con marketing.
01

Los dos Blenders: el viewport y el render no quieren lo mismo

Trabajar en Blender son dos cargas distintas: el viewport (modelar, esculpir, animar en tiempo real) depende sobre todo de la velocidad single-core del CPU y del rasterizado de la GPU; el render en Cycles es cómputo puro de GPU con la escena entera viviendo en VRAM. Una máquina puede volar en uno y arrastrarse en el otro — por eso comprar "la GPU más grande" sin mirar el resto es un error caro.

La regla: identificá dónde perdés tiempo VOS — ¿el viewport se traba al modelar o esperás renders? La respuesta define dónde va tu plata.

02

VRAM: el límite duro que no se negocia

Para renderizar en GPU, tu escena — geometría, texturas, volumetrías, pelo — tiene que entrar en la VRAM. Si no entra, Cycles puede derramar a la RAM del sistema con penalidad de velocidad, o directamente fallar. Y lo que come VRAM crece rápido: texturas 4K/8K, subdivisiones, simulaciones. Orientación honesta: 8 GB es entrada (escenas simples), 12–16 GB es trabajo serio, 24 GB o más es producción con escenas pesadas.

Medilo: abrí TU escena más pesada y mirá el consumo de VRAM en el render (Blender lo muestra). Compra futura = ese número × margen para crecer.

03

OptiX vs. HIP: la verdad incómoda del ecosistema

Cycles corre en NVIDIA (CUDA/OptiX) y en AMD (HIP). La verdad honesta de hoy: OptiX acelera el ray tracing por hardware y suele rendir muy por encima en Cycles, y el ecosistema (denoising OptiX, addons, soporte) está más maduro del lado verde. AMD mejora cada versión y rinde bien por precio en gaming — pero para una máquina cuyo trabajo es renderizar en Cycles, NVIDIA sigue siendo el camino con menos fricción.

Verificalo vos: compará los modelos que tengas en mente en el Open Data Benchmark — los números de Blender real valen más que cualquier opinión, incluida la nuestra.

04

El CPU importa (pero no como creés)

"Es para 3D, compro 64 núcleos" — no tan rápido. El viewport, los modificadores y la preparación de escena dependen fuerte del rendimiento single-core; los núcleos en cantidad brillan en simulaciones (fluidos, telas, humo), en el bake de físicas y como respaldo de render por CPU. Un CPU moderno de 8–16 núcleos con buen single-core es el punto dulce para la mayoría; los core-count extremos son para quien simula pesado todos los días.

La regla: single-core rápido para la experiencia de trabajar; muchos núcleos solo si tus simulaciones lo piden. En 3D, el CPU acompaña — la GPU protagoniza.

05

RAM: la regla del 2–4× la VRAM

La escena vive en RAM antes y después de vivir en VRAM — más los assets, el undo, las simulaciones y el navegador con 30 referencias abiertas. Regla práctica: RAM = 2 a 4 veces tu VRAM, con 32 GB como piso serio y 64 GB para simulaciones y escenas de producción. Quedarse corto de RAM es la muerte por swap: todo funciona, pero todo tarda.

Y en dos sticks (dual channel), como ya explicamos en el checklist post-compra — en cargas de 3D la diferencia se siente.

06

Drivers Studio: los renders largos quieren aburrimiento

NVIDIA publica dos ramas de drivers: Game Ready (novedades rápidas para juegos nuevos) y Studio (validados para aplicaciones creativas, con meses de testeo extra). Para una máquina de render, la elección es obvia: Studio. Un driver de juegos recién salido con un bug de cómputo te puede tirar un render en la hora siete de nueve.

Hacé: instalá la rama Studio y actualizá con calma — nunca la noche antes de una entrega (la regla del rig congelado de los VJs aplica igual acá).

07

Render de horas = carga sostenida: térmica y energía

Un render largo es la GPU al 100% durante horas — la prueba de fuego que el gaming intermitente nunca exige. Acá se caen las térmicas justas: throttling que alarga el render, o crashes en la madrugada. Refrigeración dimensionada para carga sostenida, suspensión de Windows desactivada durante renders, y plan de energía de alto rendimiento (nuestro performance-profile lo activa con vuelta atrás).

Probalo: un render de una hora monitoreando temps y clocks. Si los clocks caen con los minutos, tu térmica está limitando tu trabajo — y eso en una máquina de render es plata.

08

Almacenamiento: texturas, cachés y la nube traicionera

Los proyectos de 3D pesan en serio: bibliotecas de texturas 4K, cachés de simulación (Alembic, VDB) que se van a decenas de gigas, versiones de escena. NVMe para proyectos y cachés activos, y el clásico silencioso: la nube sincronizando tu carpeta de proyecto mientras Blender escribe el caché — corrupción y tirones garantizados. Carpeta de trabajo fuera de la sincronización en tiempo real; el backup se hace después, no durante.

Estructurá: proyectos activos en NVMe excluido de la nube; biblioteca de assets donde quieras; backup programado fuera del horario de trabajo.

09

¿Tu máquina o una granja? El cálculo honesto

Para stills y proyectos personales, tu GPU alcanza y sobra. Pero cuando aparece una animación — cientos o miles de frames — hacé la cuenta: minutos por frame × frames = horas de máquina ocupada. A veces conviene renderizar las pruebas en local y mandar el final a una granja de render, que cobra por uso y devuelve en horas lo que tu máquina haría en días. No es rendirse: es usar la herramienta correcta para cada escala.

La cuenta: si un render final te bloquea la máquina más de un día de trabajo, cotizá la granja. Tu tiempo de trabajo vale más que el orgullo de renderizar en casa.

10

Benchmarkeá tu realidad, no la del reviewer

El Open Data Benchmark compara hardware con escenas estándar — perfecto para elegir componentes. Pero tu métrica real es TU trabajo: guardate una escena tuya representativa como benchmark personal y medila en cada cambio (driver nuevo, Blender nuevo, ajuste térmico). Es la única forma de saber si un cambio te mejoró o te arruinó el flujo — con tus números, no los de un youtuber.

Hacé: elegí una escena tuya, anotá su tiempo de render de referencia, y repetí la medición después de cada cambio importante del sistema.

El checklist del hardware para 3D

Para decidir la compra y dejar la máquina lista para renderizar en serio.

  1. Identificado TU cuello de botella real: ¿viewport o tiempos de render?
  2. VRAM medida con tu escena más pesada + margen de crecimiento.
  3. GPU elegida con el Open Data Benchmark, no con benchmarks de gaming.
  4. CPU con buen single-core; núcleos extra solo si simulás pesado.
  5. RAM = 2–4× la VRAM, mínimo 32 GB, en dual channel.
  6. Drivers Studio instalados; nada se actualiza antes de una entrega.
  7. Térmica probada con una hora de render monitoreando clocks.
  8. Suspensión desactivada y plan de alto rendimiento para renders largos.
  9. Proyectos y cachés en NVMe, fuera de la sincronización de nube.
  10. Escena propia de benchmark con tiempo de referencia anotado.

Esta guía la escribimos desde BARAM, un taller boutique de computadoras a medida de Buenos Aires. Nuestra Serie Pulqui lleva el nombre del primer avión a reacción de Latinoamérica — "flecha" en mapudungun — porque para eso existe: renders que no te hacen esperar. Sale del taller con la VRAM dimensionada para TU escena, térmica probada en carga sostenida y drivers Studio configurados, todo documentado en su ficha. Pero los principios son los mismos en cualquier máquina: aplicalos y que renderizar deje de ser esperar.

Más regalos: los scripts de la casa y todas las guías gratuitas.