FLUX.3 Image Klein en Diffusers: guía completa y práctica

Didom » Tutoriales » FLUX.3 Image Klein en Diffusers: guía completa y práctica

FLUX.3 Image Klein ha aterrizado como un modelo abierto de generación de imagen que no se conforma con hacer text-to-image: también edita con varias referencias y obedece a un diseño por cajas. La misma instantánea de pesos sirve para tres tareas que antes obligaban a encadenar herramientas distintas, y eso cambia bastante el panorama para quien monta productos con IA. Black Forest Labs lo presentó el 15 de octubre de 2026 y Diffusers lo incorporó desde el primer día, así que no hay que esperar a integraciones de terceros para probarlo. La noticia se fechó el 17 de octubre de 2026 en algunos resúmenes, dos días después del lanzamiento.

La gracia no está solo en la calidad, sino en el control. Puedes indicar dónde va cada elemento con coordenadas normalizadas, algo que hasta ahora se resolvía con máscaras pintadas a mano o con inpainting menos predecible. Además, la familia FLUX.3 separa dos versiones abiertas: una destilada para volar en inferencia y una base pensada para afinar. En las próximas líneas desmenuzamos todo lo que trae, desde el flujo con Diffusers hasta los detalles de memoria, latencia, LoRA y el ecosistema de ComfyUI.

Un lanzamiento que cambia las reglas del juego

FLUX.3 Image Klein es un modelo de imagen de pesos abiertos con 5,6B de parámetros. Reúne generación desde texto, edición con hasta diez imágenes de referencia y control de composición mediante cuadros delimitadores en un único checkpoint. No es un generador más: la misma arquitectura entiende que una referencia puede ser contexto, no solo una imagen que copiar. Esa mezcla es la que permite mover un objeto de una foto a otra escena o mantener la identidad de una persona mientras cambias la ropa. En las evaluaciones internas se presenta como una frontera de Pareto entre Elo y latencia para texto a imagen y edición, con Elo interno y latencia mediana de API para 1 MP.

El modelo viene con un upsampler de prompts que, ojo, no es un adorno opcional: está pensado para usarse siempre. Se trata de un modelo visión-lenguaje de 9B, afinado a partir de Qwen3.5-9B, que convierte una petición corta en una descripción larga y detallada antes de que llegue al codificador de texto. En la CLI, la demo y la función generate viene activado por defecto. Si lo desactivas con –no-pup, la imagen resultante se resiente bastante, tanto en text-to-image como en edición y diseño por cajas. Un ejemplo de doble exposición pasa de una petición breve a un texto de 214 palabras, que es justo el tipo de detalle que el modelo agradece.

Dos sabores: destilado y base

La colección de Hugging Face separa dos pesos que conviene no confundir. Por un lado está black-forest-labs/flux-3-image-klein, destilado por timestep, con 16 pasos y sin classifier-free guidance, ideal para inferencia rápida. Por otro, black-forest-labs/flux-3-image-klein-base, el modelo base con 50 pasos y CFG, que es el punto de partida recomendado para fine-tuning. La versión destilada corre aproximadamente seis veces más rápido que la base en una misma tarea, así que para producción suele ser la primera opción. Con el mismo prompt y la misma semilla, la destilada va por la izquierda y la base por la derecha en la comparativa.

No hace falta instalarse nada para echar un vistazo: hay una space de Black Forest Labs en Hugging Face para probarlo desde el navegador. Ahora bien, si vas a integrarlo en serio, la versión destilada y la base tienen papeles distintos. La destilada brilla en generación y edición autoalojada; la base tiene sentido cuando quieres entrenar LoRA, investigar o adaptar el modelo a un estilo propio. En una H200 a 1 MP, la destilada ronda los 3 segundos por imagen frente a los 12 segundos de la base con los mismos pasos de referencia.

Diffusers y el flujo modular

La integración en Diffusers llegó con ModularPipeline, la arquitectura modular que el equipo ha ido consolidando. Para instalarlo necesitas la versión más reciente del paquete, porque FLUX.3 utiliza Qwen3-VL como codificador de texto. Cargar el checkpoint destilado y generar una imagen son unas pocas líneas, pero no te saltes la actualización: con una versión antigua te encontrarás con incompatibilidades que no siempre son evidentes.

El pipeline acepta height, width y num_inference_steps directamente en la llamada. Los prompts funcionan mejor si describes sujeto, entorno, luz, composición y estilo en lugar de soltar cuatro palabras sueltas. Esa recomendación vale para text-to-image, pero también para edición: cuanto más claro seas sobre lo que debe cambiar y lo que debe quedarse igual, más fiel será el resultado. La API cambia poco respecto a FLUX.1 y FLUX.2, así que quien ya viene de esas versiones no tiene que reaprenderlo todo. Además, ModularPipeline permite intercambiar bloques concretos sin rehacer el flujo entero.

Edición con varias referencias: el truco de los tokens

En una edición sencilla pasas una imagen con image= y el prompt actúa como pie de foto del resultado deseado. Cuando usas más de una referencia, cada imagen se cita en el texto como <ref_image_0>, <ref_image_1> y así sucesivamente, en el mismo orden en que aparecen en la lista. Eso permite combinar elementos de fotos distintas en una sola escena sin perder de vista de dónde sale cada cosa. La primera referencia, además, marca el tamaño de salida.

El modelo admite hasta diez referencias, aunque cada una suma. Una referencia de 1024×1024 añade 4.096 tokens a cada llamada del transformer, así que el tiempo no se queda fijo: crece con cada imagen extra. Ese detalle es clave para presupuestar latencia antes de lanzar una función de edición multiphotografía. No es lo mismo una edición con una referencia que una composición con cuatro o cinco; el coste se acumula y conviene medirlo con datos reales.

Control de composición con coordenadas

La novedad más diferencial es el control de diseño mediante un bloque JSON que se añade al prompt. Cada región lleva un id, una descripción y un bbox con coordenadas [y_min, x_min, y_max, x_max] en una escala de 0 a 1000, independiente del tamaño real de la imagen. Eso significa que puedes versionar una composición como si fuera código: el JSON se guarda, se revisa y se repite, en lugar de repintar una máscara en cada intento. En la CLI también existe boxes.json, con cajas en 0 a 1 y origen arriba a la izquierda, para quien prefiera ese formato.

En edición, cada región no usa un único bbox, sino un src_bbox y un tgt_bbox. El primero indica de dónde sale el elemento en la referencia y el segundo dónde debe quedar en la salida; si ambos coinciden, el elemento se queda quieto. El ejemplo clásico del caballero amigurumi mueve solo la figura y mantiene intactos el fondo, el acantilado, la aguja y el dragón, bloqueando cada parte con src_bbox igual a tgt_bbox. Es una forma de edición guiada por coordenadas que reduce la incertidumbre típica del inpainting con máscaras. Para editar, la caja puede incluir id, descripción, from con ref_image_0 o target, y las dos coordenadas src_bbox y tgt_bbox.

Cuantización y memoria: cómo elegir

Black Forest Labs publica el transformer como archivo único en bf16 y en dos formatos cuantizados: fp8r, con FP8 por fila, y nvfp4. Se pueden cargar con from_single_file sin bajarse el peso bf16 completo, algo que agradece cualquier equipo con poca VRAM. Ahora bien, no todos rinden igual. fp8r tiene kernels rápidos en GPUs con capacidad de cómputo 8.9 o superior, es decir, Ada, Hopper y Blackwell; en tarjetas más antiguas el peso se descomprime en cada paso, lo que ahorra memoria pero no acelera nada.

nvfp4 sigue una lógica parecida, pero exige Blackwell y tener flashinfer-python y flashinfer-cubin en la misma versión para notar la mejora de velocidad. Si las librerías no están alineadas, el beneficio se esfuma. Las cifras de memoria que se han publicado sirven como vara de medir: en una B200 a 1024×1024, con text-to-image y una edición con una referencia, el modelo destilado con –no-pup consume alrededor de 31 GB en bf16, 26 GB en fp8 y 25 GB en nvfp4; la base se mueve entre 31, 29 y 26 GB respectivamente. La instalación se probó en B200 y, para otras GPUs, toca revisar la tabla de memoria con calma.

Para GPUs más modestas hay trucos que cunden. Puedes liberar el codificador de texto después de usarlo, porque solo interviene una vez por imagen antes del denoising. También puedes activar la descarga automática a CPU con ComponentsManager.enable_auto_cpu_offload, que mueve cada componente a la GPU solo mientras se usa. No hay cifras oficiales de esta ruta, así que toca medir en tu hardware. El upsampler, por cierto, reserva –pup-memory del 0,35 por defecto; si no cabe junto al modelo, puedes ejecutarlo por separado y pasar el caption con –no-pup. Una RTX 3070 de 8 GB puede tirar de los archivos int8 en ComfyUI, y en las tablas de segundos por imagen la compilación más rápida es NVFP4 en Blackwell de centro de datos y DGX, e INT8 en las RTX mediante ComfyUI.

Cuánto tarda de verdad

Las pruebas de velocidad publicadas se hicieron en una sola H100 de 80 GB, sin offload, con el backend de atención por defecto y la media de tres ejecuciones tras el calentamiento. Con el checkpoint destilado de 16 pasos, una imagen de 1024×1024 tarda 1,93 segundos y alcanza un pico de 23,8 GiB. Una edición image-to-image con una referencia de 1024×1024 se va a 3,87 segundos, y el ejemplo de edición de diseño con una referencia de 1360×768 llega a 4,10 segundos.

¿Por qué una sola referencia casi duplica el tiempo? Sus tokens entran en la misma secuencia que el texto y la imagen que se está generando. Una referencia de 1024×1024 aporta 4.096 tokens a cada llamada del transformer, y eso se nota. En una función con varias referencias por petición, el coste no es fijo: suma con cada imagen. Antes de llevar una feature de edición multiphotografía a producción, conviene meter ese crecimiento en el presupuesto de latencia y no llevarse sorpresas en el pico de tráfico.

LoRA y ajuste fino: la base manda

Diffusers ya incluye scripts DreamBooth LoRA para las dos tareas, text-to-image y edición de imagen. El ejemplo oficial entrena un estilo tarot con el dataset multimodalart/1920-raider-waite-tarot-public-domain y la palabra clave trtcrd. Eso sí, para afinar hay que usar el checkpoint base con 50 pasos y CFG, no el destilado. La documentación es explícita en ese punto: el destilado está pensado para inferencia, no para entrenar.

Si vas justo de VRAM, hay tres flags que cambian el coste directamente. –gradient_checkpointing recalcula activaciones en la pasada hacia atrás, lo que baja memoria a cambio de velocidad; –cache_latents precalcula las imágenes y libera el VAE; y –use_8bit_adam mantiene el estado del optimizador en 8 bits. Para edición basada en instrucciones, el script train_dreambooth_lora_flux3_klein_img2img.py entrena con tripletas de imagen de referencia, imagen objetivo e instrucción. Es una forma bastante directa de adaptar el modelo a un flujo concreto sin reentrenar todo.

Cómo funciona por dentro: dos etapas de atención

La arquitectura explica por qué el control por cajas funciona tan bien. FLUX.3 es un modelo de flow matching en espacio latente. El VAE, el mismo de FLUX.2, comprime la imagen ocho veces en cada dirección y produce 32 canales; después empaqueta cada bloque 2×2 de ese latente en un token de 128 canales. El resultado es un token por cada parche de 16×16 píxeles: una imagen de 1024×1024 se convierte en una rejilla de 4.096 tokens, y cada referencia pasa por el mismo camino conservando su tamaño.

El texto va por Qwen3-VL, pero no se usa solo la última capa. FLUX.3 lee los estados ocultos de 8 de las 36 capas, concretamente las capas 4, 8 y así hasta la 32, los apila en un vector de 20.480 dimensiones y lo proyecta a las 3.072 dimensiones del transformer. Así incorpora información de varias profundidades del modelo de lenguaje, no solo del final. Es una decisión que ayuda a que el prompt no se quede en una representación plana.

El transformer procesa todo en dos fases. En la primera, cada modalidad —texto, imagen ruidosa y referencias— pasa por 5 bloques con pesos propios y sin hablar con las demás. En la segunda, las tres secuencias se concatenan en [texto | imagen | referencia] y atraviesan 28 bloques con pesos compartidos, donde todo atiende a todo. Es justo lo contrario de FLUX.2, cuyos bloques double-stream ya mezclaban texto e imagen desde el principio; FLUX.3 separa primero y fusiona después.

Hay otro detalle que sostiene la edición por coordenadas: cada token recibe su propia modulación de timestep. Los tokens de imagen ruidosa se modulan con el timestep actual; el texto y las referencias se modulan siempre con timestep 0, es decir, como si ya estuvieran limpios y no necesitaran denoising. Eso marca explícitamente una referencia como contexto dado, no como algo que generar. La posición usa RoPE en cuatro ejes (t, h, w, l), y como la referencia comparte las coordenadas (h, w) con la salida, el modelo entiende con precisión qué significa el mismo punto en la referencia. Ahí es donde src_bbox y tgt_bbox sacan partido.

Lo que cambia para producto

Para quien ya integra generación de imagen en un producto, hay dos puntos que pesan más que el resto. El control por coordenadas normalizadas elimina una capa de incertidumbre que el inpainting con máscaras siempre arrastraba: puedes versionar un prompt con su JSON de cajas y esperar una reproducibilidad razonable, en vez de redibujar la máscara en cada intento. Eso simplifica la revisión, el control de calidad y la automatización de composiciones.

El segundo punto es el coste. Una referencia adicional puede duplicar el tiempo de inferencia, y con varias imágenes el crecimiento es acumulativo. Antes de poner una función de edición con varias fotos en producción, hay que decidir si merece la pena para el caso de uso y cómo se va a limitar el número de referencias por petición. También conviene elegir bien la variante: nvfp4 solo compensa en Blackwell con las librerías correctas; fp8r ya gana velocidad en cualquier Ada, Hopper o Blackwell; y bf16 sigue siendo la ruta más predecible si tienes GPU de sobra y quieres evitar complicaciones. Aun así, manos, detalles pequeños y fidelidad a referencias siguen necesitando revisión humana.

ComfyUI: edición rápida con INT8

El ecosistema de ComfyUI tiene su propio flujo para FLUX 3 Klein Distilled Image Editing, pensado para editar una foto con instrucciones naturales y conservar identidad, composición e iluminación. Usa los pesos destilados INT8 y un muestreo de 16 pasos, así que va bien para iteraciones rápidas. Sirve para cambiar ropa y materiales, sustituir texto de etiquetas, mover la iluminación, añadir detalles ilustrados o reestilizar una fotografía. Al final guarda el resultado y muestra una comparación lado a lado con el original.

El grafo carga tres piezas clave: UNETLoader trae los pesos INT8 destilados, CLIPLoader carga Qwen3-VL 4B INT8 con convrot y VAELoader selecciona el VAE de FLUX.2. Quedan conectados una vez, así que no hay que configurar nada más salvo que cambies de activos. La referencia se elige con LoadImage, se codifica con el VAE y se pasa al nodo de referencia para que el sampler se ancle a identidad, pose e iluminación. Conviene partir de una foto limpia, bien iluminada y recortada al sujeto que quieres preservar; si haces varias ediciones del mismo sujeto, mantener la misma referencia estabiliza los resultados.

El prompt positivo debe ser una frase descriptiva que funcione como pie de foto final, con el cambio incluido en contexto. Merece la pena decir qué se cambia y qué se conserva, por ejemplo sustituir un pendiente por una pieza de bronce calada y mantener luz y tono de piel. Para atar referencias concretas se usan tokens como <ref_image_0>. El grafo genera un negativo incondicional con ConditioningZeroOut, así que normalmente solo hay que cuidar el texto positivo, que entra por Positive Prompt #4.

Si necesitas más imágenes, ReferenceMultiLatent permite añadir fuentes extra y referirlas como <ref_image_1>, <ref_image_2> y sucesivos. También crea un lienzo latente que coincide con la referencia para que la composición no se desmadre. Subir el objetivo interno de megapíxeles aumenta el detalle fino a cambio de tiempo y memoria. KSampler controla pasos, sampler, scheduler, cfg y denoise con un scheduler Euler eficiente: menos pasos para borradores, más pasos para texturas o tipografías delicadas; si la edición se aleja demasiado de la identidad, baja cfg o denoise, y si se queda corta, súbelos un poco. VAEDecode reconstruye, SaveImage escribe en disco e ImageCompare muestra original y editado para revisar el resultado de un vistazo.

EmptyFlux2LatentImage sirve para fijar un tamaño de salida propio en lugar de heredarlo de la referencia. Conectarlo al sampler te permite crear un lienzo en blanco con las dimensiones que quieras, aunque cuanto más grandes, más memoria y tiempo. En prompts conviene ser conciso y específico: sustituir una etiqueta por KLEIN manteniendo peso de fuente y perspectiva, conservar la textura de la chaqueta y la luz. Para borradores se pueden bajar pasos; para finales, volver a los 16 del flujo. Si el color o la iluminación se van, menciónalos de forma explícita en el caption para que el modelo se ciña más.

Ecosistema, licencias y formación

El código del repositorio de referencia se publica bajo Apache 2.0, mientras que los pesos de FLUX 3 Image Klein quedan bajo la FLUX Kommunity License y el upsampler de prompts vuelve a ser Apache 2.0. Los archivos de ComfyUI y los flujos derivados están sujetos a las licencias de sus respectivos autores. Además, el modelo incluye comprobaciones de seguridad opcionales: si activas –safety en la CLI o las opciones avanzadas en la demo, se revisan prompts, referencias y salidas en busca de personajes con copyright, marcas, figuras públicas y contenido NSFW; lo que se marca, se rechaza. Las imágenes guardadas llevan etiquetas EXIF con Software: AI generated y Make: Black Forest Labs.

El repo de referencia también trae una CLI y una demo con tres pestañas: Layout para dibujar cajas y escribir qué va en cada una, Text to image y Edit. La CLI permite pasar boxes, width, height, steps, guidance, pup y safety, además de –offload, –fp8, –nvfp4 y –no-pup. Cada imagen generada deja un .json con prompt, tamaño, pasos, guidance y semilla. Para cargar variantes cuantizadas, –fp8 funciona en Ada, Hopper y Blackwell, mientras que –nvfp4 exige Blackwell y la instalación [nvfp4], y no se lleva bien con –offload. No hay ruta INT8 en este código: en GPUs sin FP8, como las RTX 30 y anteriores, hay que tirar de los archivos INT8 de black-forest-labs/flux-3-image-klein-comfy en ComfyUI. Los modelos se cargan una vez y luego se pueden lanzar varias generaciones.

El paquete rápido con upsampler ocupa 52 GB; todo el conjunto, 107 GB. WEIGHTS_DIR apunta por defecto a ./weights, y los DiT cuantizados viven en variants/fp8r y variants/nvfp4 de cada repositorio; el codificador de texto y el autoencoder se distribuyen en ambos. weights/pup es el upsampler, que el modelo necesita. Para generar sin upsampler se puede usar un modelo visión-lenguaje externo con los system prompts y pasar su respuesta con –no-pup. Si el upsampler y el modelo no caben juntos en la GPU, se ejecuta el upsampler aparte y se pasa el caption con –no-pup.

En el terreno del ajuste fino con NeMo AutoModel, la integración cubre el Flux3Transformer2DModel solo para imagen, con generación text-to-image y edición por instrucciones, usando flow matching y condicionamiento de texto Qwen3-VL. La validación de 100 pasos cubre el entrenamiento LoRA, pero las plantillas de fine-tuning completo no han pasado por la misma validación de extremo a extremo. Para entrenar se descarga el repositorio base, que incluye pesos Diffusers y modular_model_index.json junto al paquete original de BFL; el destilado separado es para inferencia. AutoModel carga los componentes modulares directamente y no hace falta convertir los archivos originales. Las carpetas variants/fp8r y variants/nvfp4 son paquetes de inferencia cuantizada y quedan fuera de la validación de entrenamiento en BF16. Los comandos se ejecutan desde la raíz del repositorio de AutoModel en la rama main, con una cuenta autorizada de Hugging Face y las dependencias de difusión instaladas.

Los ejemplos usan uv run –no-sync para conservar la revisión instalada de Diffusers. El VAE de imagen va en FP32 y el transformer validado con LoRA usa BF16. El condicionamiento de texto emplea las capas de Qwen3-VL seleccionadas por el checkpoint, rellena los prompts a múltiplos de 80 tokens con un máximo de 8192 y conserva los position IDs de padding del entrenamiento. El preprocesamiento cachea latentes del VAE y embeddings de texto fuera de línea. En text-to-image LoRA se cachean 32 pares imagen-caption de Tuxemon a 512p, se entrenan 100 pasos con dos GPUs, atención nativa, checkpointing de activaciones, batch global 2 y warmup de 10 pasos; la configuración se validó en dos H100 de 80 GB. La lista de objetivos LoRA excluye el stream de referencia inactivo y usa adaptadores BF16 de rango 4.

Para generar con LoRA se apunta model.lora_weights al directorio model/ del checkpoint guardado. La configuración de generación usa prompt, semilla 42, 50 pasos, escala de guidance 3,5 y salida de 1024×1024; si se omite el override de LoRA, genera con el checkpoint base. En edición de imagen, el entrenamiento usa una imagen objetivo, una imagen fuente limpia y una instrucción; la fuente condiciona el stream de generación y no es un segundo objetivo. Se copia flux3_i2i_flow.yaml, se añade un bloque peft para entrenar también el stream de referencia activo y se lanza el mismo punto de entrada nativo. Para generar, se usa el checkpoint LoRA de edición, se ponen las instrucciones en inference.prompts y las rutas fuente en inference.input_images, una por prompt, con dimensiones que respeten la relación de aspecto y sean divisibles por 16. El flujo probado usa una referencia por prompt.

La validación de estas recetas es limitada: verifican el flujo de entrenamiento y generación en un dataset pequeño, no demuestran una mejora de calidad ni un benchmark de rendimiento. Quedan sin validar el fine-tuning completo, la ejecución multinodo, la paralelización de tensor o contexto mayor que uno, la reanudación de edición de imagen y el entrenamiento en FP8 o NVFP4. La integración cubre generación y edición de imagen, sin flujo de vídeo ni audio. Por otro lado, si te mueves en el mundo cloud, hay una certificación de AI CloudOps Engineer con examen online, insignia Credly, certificado oficial y créditos gratuitos por 1 dólar en lugar de 100 en una oferta limitada, aunque eso ya es otro jardín.

Lo que deja este lanzamiento es una herramienta bastante completa para quien necesita generar y editar con control fino: un mismo modelo abierto cubre texto, referencias múltiples y composición por cajas, con versiones para inferencia rápida y para entrenar, variantes cuantizadas para distintas GPUs y un ecosistema que ya incluye Diffusers, ComfyUI y recetas LoRA. La letra pequeña está en la latencia de las referencias, en la necesidad del upsampler y en las limitaciones de validación del fine-tuning. Si eliges bien la variante y mides el coste antes de desplegar, FLUX.3 Image Klein se vuelve una pieza muy seria para productos de imagen con IA.