FLUX.3 Image Klein publica pesos abiertos y llega a Diffusers el primer día: control por cajas de diseño y compensaciones para desarrolladores
Según un blog de Hugging Face publicado el 15 de octubre de 2026, FLUX.3 Image Klein de Black Forest Labs se publica con dos checkpoints abiertos y está disponible en Diffusers desde el primer día. El modelo admite, con los mismos pesos, generación de imagen a partir de texto, generación con múltiples imágenes de referencia y control de diseño mediante cajas delimitadoras; el checkpoint destilado genera una imagen de 1024×1024 en unos 2 segundos en una H100, y además se ofrecen pesos de archivo único NVFP4 y FP8, así como scripts de entrenamiento LoRA.
Qué ha cambiado
Según el blog oficial de Hugging Face del 15 de octubre de 2026, Black Forest Labs publicó FLUX.3 Image Klein y afirma que puede ejecutarse en Diffusers desde el primer día. El blog enumera dos checkpoints abiertos: black-forest-labs/flux-3-image-klein es la versión destilada en pasos de tiempo, con 16 pasos por defecto y sin guiado libre de clasificador; flux-3-image-klein-base es el modelo base, con 50 pasos por defecto y guiado, que según el blog es más adecuado para ajuste fino. En cuanto a funcionalidad, el mismo modelo cubre texto a imagen, imagen a imagen con una o varias imágenes de referencia, y control de diseño escribiendo una lista JSON de regiones en el prompt. Las regiones usan los campos id, bbox y desc, con coordenadas escritas como [y_min, x_min, y_max, x_max] en una escala normalizada de 0 a 1000; el blog afirma que la misma caja sirve para cualquier tamaño de imagen. En escenarios de edición, las regiones se describen con src_bbox y tgt_bbox para indicar de dónde proviene el contenido en la imagen de referencia y a dónde se mueve en la salida. El blog afirma que el checkpoint destilado genera una imagen de 1024×1024 en unos 1,93 segundos en una H100, y que una imagen de referencia de 1024×1024 duplica aproximadamente el tiempo hasta 3,87 segundos, porque cada llamada al transformer añade 4096 tokens de referencia. El blog también presenta pesos de archivo único NVFP4 y FP8 por filas, un script de entrenamiento DreamBooth LoRA y una explicación de la canalización modular de Modular Diffusers; el codificador de texto es Qwen3-VL. El rendimiento y las funciones anteriores son lo expuesto por los autores del blog; esta publicación no los ha reproducido de forma independiente.
Impacto para desarrolladores
Para los equipos que despliegan inferencia propia, lo más destacable no es que haya un modelo más, sino que el control de diseño convierte la «posición» en una entrada programable. Las coordenadas de las regiones están en escala normalizada, lo que significa que un mismo front-end de anotación puede reutilizarse directamente en distintas resoluciones de salida; para canalizaciones que necesitan composición fija, como imágenes de comercio electrónico, diseño de carteles o reedición de material, esto es un cambio estructural y no solo una técnica de prompting. En segundo lugar, la segmentación de memoria de vídeo es clara: la asignación máxima indicada en el blog muestra que bf16 ocupa unos 18,8 GiB tras la carga y unos 20,7 GiB tras la inferencia, mientras que FP8 y NVFP4 bajan a unos 14,35 y 13,4 GiB respectivamente, lo que determina el reparto entre tarjetas de consumo y tarjetas de centro de datos. En tercer lugar, el modelo de coste cambia con las imágenes de referencia: cada imagen de referencia de 1024×1024 añade 4096 tokens en cada llamada al transformer, por lo que la latencia y el uso de memoria de vídeo en edición con varias referencias crecen de forma aproximadamente lineal con el número de referencias; la planificación de capacidad no puede extrapolarse a partir de las cifras de texto a imagen. En cuarto lugar, en la interfaz de ingeniería, el modelo se publica en forma de Modular Diffusers; el blog demuestra cómo separar el codificador de texto para «codificar una vez y generar muchas veces», y cómo insertar pasos personalizados en el bucle de eliminación de ruido, lo que permite que el almacenamiento en caché, la telemetría y el control de calidad queden dentro de la canalización en lugar de ser una llamada de caja negra externa. Cabe señalar que estos beneficios presuponen el autoalojamiento de los pesos; el blog no describe disponibilidad, limitación de tasa ni facturación de ninguna API alojada, por lo que, antes de integrar el control de diseño en producción, los equipos deben asumir por su cuenta la distribución de pesos, la memoria de vídeo y la programación de concurrencia.
Integración y evaluación
Lo siguiente son juicios y recomendaciones basados en la fuente, no hechos verificados. La primera decisión se refiere a la elección de checkpoint: el blog afirma que la versión destilada usa 16 pasos por defecto y no usa CFG, mientras que la versión base usa 50 pasos por defecto con guiado y es adecuada para ajuste fino. Si la tarea es generar imágenes en lote y no exige una gran consistencia de estilo, puede empezarse por la versión destilada para reducir la latencia; si se necesita ajuste fino con LoRA o se es sensible a la intensidad del guiado, conviene partir de los pesos de la versión base. Las condiciones previas son los datos de entrenamiento y el presupuesto de memoria de vídeo: el ejemplo del blog entrena 1500 pasos a resolución 1024, batch size 1 y rank 16, y recomienda añadir checkpointing de gradientes, almacenar latentes en caché y usar Adam de 8 bits para reducir la memoria de vídeo. El criterio de evaluación medible es la diferencia de tasa de utilidad en una evaluación ciega humana entre los 16 pasos de la versión destilada y los 50 pasos de la versión base con un conjunto fijo de prompts, así como el tiempo de extremo a extremo por imagen de ambas en el mismo lote. La segunda decisión se refiere al formato de cuantización: el blog afirma que fp8r puede usar kernels rápidos en capacidad de cómputo 8.9 o superior (Ada, Hopper, Blackwell), mientras que en otras GPU los pesos se desquantizan en cada paso, con menor uso de memoria pero sin aceleración; NVFP4 requiere Blackwell y exige que las versiones de flashinfer-python y flashinfer-cubin coincidan. Por tanto, la cuantización no es una aceleración incondicional: la elección depende del modelo de tarjeta; en Ada/Hopper puede priorizarse fp8r para ganar memoria, en Blackwell puede considerarse NVFP4, y en tarjetas antiguas la cuantización compra principalmente que quepa, no que corra más rápido. El criterio de medición es la latencia por imagen con la misma resolución y el mismo prompt, y si aparece una degradación de calidad perceptible por la desquantización. La tercera decisión se refiere a si merece la pena integrar el control de diseño: el blog afirma que la imagen de referencia y la salida comparten el mismo conjunto de coordenadas (h, w), y que la misma posición tiene un significado preciso para el modelo, que es la base de que funcione la edición por cajas; pero ese mecanismo también implica que cuantas más imágenes de referencia, más tokens por llamada. Se recomienda usar primero un conjunto de evaluación fijo para medir la tasa de acierto de las instrucciones de diseño dentro de las cajas y el grado de deriva de las partes invariantes de la escena, y luego decidir si llevar la anotación de bocetos al flujo de producto. Si no cumple lo esperado, conviene volver a texto a imagen puro más composición posterior, cuya estructura de costes es más predecible.
Límites y cuestiones pendientes
Limitaciones clave: según la comprobación de catálogo de esta edición, la versión FLUX.3 Image Klein y flux-3-image-klein-base no aparece en el catálogo actual de modelos listados de KimiSeek, y esta publicación tampoco dispone de ningún plan de alojamiento de dicha plataforma; todas las descripciones de pesos, scripts y rendimiento de este artículo provienen del texto original del blog de Hugging Face, responden a la versión de la fuente y no han sido reproducidas de forma independiente por esta publicación. Las cifras de latencia y memoria de vídeo publicadas en el blog provienen del promedio de tres ejecuciones de tres flujos de trabajo en una única H100 de 80 GB, sin offloading y con el backend de atención predeterminado; no pueden aplicarse directamente al cambiar a otra GPU, otro backend de atención o al activar CPU offload, y el blog indica explícitamente que no ha comparado escenarios con offloading. El impacto del número de imágenes de referencia en la latencia solo ofrece una medición con una sola referencia; el comportamiento con múltiples referencias, resolución muy alta o lotes largos requiere pruebas de carga propias. Que los pesos estén disponibles no equivale a una licencia permisiva: el blog usa en todo momento «checkpoint abierto» y no explica en este texto los términos concretos de licencia ni las condiciones de uso comercial, por lo que los equipos deben consultar la model card y el texto original de la licencia antes de usar los pesos en productos comerciales. El ejemplo de entrenamiento LoRA es solo una demostración con un único conjunto de datos y un único estilo; no hay garantía de que los pasos de convergencia, el rank y la combinación de optimizadores sean transferibles a datos propios. Además, el blog afirma que la canalización acepta solo un prompt por llamada, y que el prompt se rellena hasta múltiplos de 80 tokens y recibe atención; la forma de escribir lotes y concatenación de prompts debe adaptarse a su convención. Los precios y la disponibilidad de alojamiento pueden cambiar; si en el futuro se sigue el precio ofrecido por su API, debe tomarse como referencia la página de precios del proveedor.
Ilustraciones de la noticia original
