En este artículo
La novedad de FLUX.3 no es que genere imágenes bonitas. Es que permite decirle dónde va cada cosa. Layout control por bounding boxes suena a detalle técnico, pero cambia el flujo editorial: en vez de reescribir el prompt hasta que la composición salga, se dibujan regiones. El problema es que esa capacidad tiene un precio en memoria que una GPU de 16 GB no puede ignorar.
Qué es FLUX.3
FLUX.3 Image Klein es un modelo de Black Forest Labs que hace texto-a-imagen, imagen-a-imagen con múltiples referencias y control de layout. La tercera capacidad es la que marca la diferencia: el modelo acepta cajas que delimitan regiones y respeta su posición con más precisión que un prompt puramente textual.
El soporte llegó a Diffusers desde el primer día, lo que reduce la fricción para quien ya tiene un pipeline en Python. No es un modelo que solo exista en una demo cerrada: se puede cargar, cuantizar y ejecutar con las herramientas habituales.
“One model does text-to-image and multi-reference image-to-image, and it adds something new, the layout control.” — Blog de FLUX.3, 15-oct-2026.
Layout control en la práctica
La forma más simple de entenderlo es imaginar una página de revista. Defines una caja para el sujeto, otra para el producto y otra para el fondo. El modelo recibe esas coordenadas y genera una imagen que respeta la composición. No es un editor gráfico: sigue siendo generación, con la cuota de imprevisibilidad que eso implica.
Para un flujo editorial, la ganancia está en la consistencia. Si necesitas una serie de imágenes con el mismo encuadre —una portada, una figura in-post y una variante para redes—, las cajas te dan una plantilla. Cambias el contenido, no la geometría. Eso ahorra iteraciones y hace que el resultado se parezca a lo que pediste.
El límite es el de siempre: una caja no garantiza que el texto dentro de ella sea legible ni que el modelo entienda el objeto. Layout control ordena el espacio; no resuelve la semántica.
La memoria real
Los números del blog son concretos. En nvfp4, FLUX.3 carga con 13,4 GiB y llega a 15,3 GiB durante la inferencia. En fp8r, sube a 14,35 GiB de carga y 16,27 GiB de pico. En bf16, 18,8 GiB de carga y 20,72 GiB de pico. La diferencia entre “cabe” y “cabe con margen” está en esos picos.
Una GPU de 16 GB puede cargar la variante nvfp4 y quedarse con poco más de 700 MiB libres en el peor momento. Eso no deja espacio para el sistema operativo, el navegador, el text encoder o una segunda tarea. La variante fp8r roza el límite y la bf16 queda directamente fuera.
Cómo cabe en 16 GB
La ruta que documenta el blog tiene tres piezas. Primero, cargar un transformer cuantizado. Segundo, ejecutar el text encoder por separado, en CPU si hace falta. Tercero, activar offloading automático para mover capas entre GPU y CPU según la memoria disponible. Cada una reduce el pico; todas juntas hacen que el modelo quepa, pero ninguna es gratis.
El costo se paga en latencia y en complejidad. Mover pesos entre dispositivos introduce esperas; ejecutar el text encoder en CPU cambia el perfil de tiempo. Para una imagen suelta, puede ser aceptable. Para un lote de veinte, la diferencia se acumula y conviene medir antes de prometer velocidad.
La otra decisión es el contexto. El blog reporta 3,87 segundos por imagen de 1024×1024 en una H100, y 4,10 segundos con una referencia de imagen. Esos números son de datacenter, no de una RTX de consumo. No se pueden presentar como locales sin medirlos.
El pico tampoco se mide con una sola imagen. Hay que generar un lote, dejar el modelo cargado y observar la memoria con el sistema operativo y el navegador abiertos. Muchas configuraciones que “caben” en una prueba aislada fallan cuando el escritorio compite por VRAM. La medición útil es la del flujo real, no la del benchmark limpio.
Calidad vs costo
La pregunta editorial no es “¿FLUX.3 es mejor?”. Es “¿qué configuración me da una imagen usable con el presupuesto que tengo?”. En 16 GB, la respuesta probable es nvfp4 con offload selectivo. En 24 GB, fp8r o bf16 con más margen. En 8 GB, el modelo no entra sin una estrategia de offload agresiva que puede volver el flujo impráctico. La diferencia es de márgenes, no de capacidad.
También hay un costo de calidad. La cuantización agresiva puede afectar detalles finos, texto pequeño y coherencia de materiales. No es un interruptor binario: depende del estilo, de la resolución y de la semilla. La única forma de saberlo es generar el mismo prompt en dos configuraciones y comparar a tamaño real, no en una miniatura.
Qué falta probar en local
Al cierre de esta nota no hay una medición pública en una RTX 5060 Ti de 16 GB. Lo que existe es el reporte del vendor y una ruta de despliegue documentada. Eso basta para decidir si vale la pena probar, no para afirmar cuánto tarda en tu máquina.
La prueba útil sería esta: misma semilla, misma resolución, tres configuraciones (nvfp4, fp8r, bf16), medir pico de VRAM, tiempo por imagen y calidad percibida. Si la diferencia de calidad entre nvfp4 y bf16 es invisible en tu caso de uso, el ahorro de memoria es real. Si no, el presupuesto manda.
Para seguir leyendo
El blog de FLUX.3 tiene las tablas de memoria y la sección de offloading completas; el repositorio de Diffusers documenta la carga y el offload en código. Si te interesa el presupuesto de memoria de un modelo de lenguaje, nuestra guía de Mellum 2.1 en 12 GB usa el mismo marco. Para el mapa general del 2-bit, revisa el análisis de octubre de 2026. Y para entender por qué el contexto y el KV cambian la cuenta, la guía de contexto y checkpoints.
Preguntas frecuentes
¿FLUX.3 corre en 8 GB?
No sin offloading agresivo y una configuración muy recortada. El blog reporta 13,4 GiB de carga en nvfp4, por encima de 8 GB.
¿Layout control garantiza texto legible?
No. Ordena la posición de los elementos; la legibilidad del texto sigue dependiendo del modelo, la resolución y el prompt.
¿Los tiempos de H100 sirven para una GPU de consumo?
No. Son datos de datacenter. Para una RTX 5060 Ti hay que medir localmente, con la configuración y el contexto reales.
El conocimiento verdadero trasciende a lo público 🌀
Continúa explorando Inteligencia Artificial con piezas relacionadas y evidencia adicional.
Ver relacionados
