FLUX.3 Image Klein estreia no Diffusers com inferência local mais barata

A Black Forest Labs lançou o FLUX.3 Image Klein em 15 de outubro de 2026 já integrado ao Diffusers, com pesos quantizados e um recurso novo de controle de layout por caixas delimitadoras.

A Black Forest Labs lançou o FLUX.3 Image Klein em 15 de outubro de 2026 já integrado ao Diffusers, com pesos quantizados e um recurso novo de controle de layout por caixas delimitadoras.

A Black Forest Labs lançou o FLUX.3 Image Klein em 15 de outubro de 2026, e ele já nasce integrado ao Diffusers da Hugging Face, biblioteca que a maioria de quem roda modelos de difusão localmente já usa no dia a dia. O ponto central para quem constrói com isso não é só "mais um modelo de imagem": é que ele vem pensado para caber em menos GPU, gerar mais rápido e ainda fazer coisa que o Flux anterior não fazia, como mover um objeto dentro de uma imagem de referência dizendo exatamente para onde ele vai.

Um modelo, três tarefas

O FLUX.3 Image Klein resolve texto para imagem, imagem para imagem com múltiplas referências e um recurso novo chamado layout control: você escreve caixas delimitadoras (bounding boxes) dentro do próprio prompt para dizer onde cada elemento da imagem deve ficar, ou qual pedaço de uma imagem de referência deve se mover e para onde. Isso é diferente de inpainting tradicional porque a posição é dada em coordenadas normalizadas de 0 a 1000, então a mesma caixa funciona em qualquer resolução de saída.

Existem dois checkpoints abertos, e a escolha entre eles é a primeira decisão de custo que você toma:

O destilado é o que você usa em produção quando quer velocidade. O base é o que você usa para fine-tuning com LoRA, rodando com 50 passos e CFG.

Rodando o modelo pela primeira vez

A instalação exige a versão mais recente de diffusers e transformers, porque o FLUX.3 usa o Qwen3-VL como codificador de texto:

pip install -U diffusers transformers

O carregamento usa o ModularPipeline, a arquitetura de pipeline modular que o time do Diffusers vem empurrando para os modelos mais recentes:

import torch
from diffusers import ModularPipeline

pipe = ModularPipeline.from_pretrained("black-forest-labs/flux-3-image-klein")
pipe.load_components(dtype=torch.bfloat16)
pipe.to("cuda")

pipe(prompt="a red fox", output="images")[0].save("fox.png")

Para imagem a partir de imagem, basta passar o argumento image com uma referência e escrever o prompt como a legenda do resultado desejado, já com a mudança embutida. Com várias referências, cada uma é citada no prompt como <ref_image_0>, <ref_image_1> e assim por diante, na ordem em que entram na lista image.

Controle de layout: a parte que não existia no Flux anterior

O layout control funciona anexando um JSON de regiões depois da legenda. Cada região tem um id, um bbox no formato [y_min, x_min, y_max, x_max] e uma desc. Num exemplo de edição, cada região também declara de onde vem (src_bbox, na referência) e para onde vai (tgt_bbox, no resultado); uma região com as duas caixas iguais simplesmente fica parada:

edit_prompt = (
 "In <ref_image_0>, move the knight upwards and to the left... "
 '[{"id": "knight_1", "from": "ref_image_0", "src_bbox": [500,150,850,350], '
 '"tgt_bbox": [194,55,544,255], "desc": "grey amigurumi knight"}]'
)
moved = pipe(prompt=edit_prompt, image=knight_image, output="images")[0]

Isso abre caminho para edição programática de composição (reposicionar um produto num banner, mover um elemento de UI mockup) sem depender de inpainting manual com máscara pintada à mão.

Quanto de GPU isso exige, de verdade

Aqui está o ponto que mais interessa para quem decide onde rodar o modelo. A Black Forest Labs distribui o transformer também como arquivo único, em bf16 e em duas versões quantizadas, fp8r (FP8 por linha) e nvfp4. O carregamento usa from_single_file, e você pode trazer só os outros componentes por nome para não baixar o transformer em bf16 à toa:

from diffusers import BFLQuantizationConfig, Flux3Transformer2DModel, ModularPipeline

model_id = "black-forest-labs/flux-3-image-klein-base"
transformer = Flux3Transformer2DModel.from_single_file(
 f"https://huggingface.co/{model_id}/blob/main/variants/fp8r/model.safetensors",
 config=model_id, subfolder="transformer",
 quantization_config=BFLQuantizationConfig(compute_dtype=torch.bfloat16),
 dtype=torch.bfloat16,
)
pipe = ModularPipeline.from_pretrained(model_id)
pipe.update_components(transformer=transformer)

O ganho prático aparece na tabela de memória de pico medida pela própria Hugging Face:

Isso significa que a versão nvfp4 roda numa RTX 6000, uma GPU bem mais barata de alugar ou comprar do que um H100, que é o hardware necessário para a versão bf16 sem aperto de memória. Vale notar o trade-off: o fp8r só ganha kernels rápidos de verdade em GPUs com compute capability 8.9 ou superior (Ada, Hopper, Blackwell); em qualquer outra, os pesos são desquantizados a cada passo, o que economiza memória mas não acelera nada.

Para quem tem ainda menos memória disponível, a Hugging Face sugere três caminhos: carregar um transformer quantizado, rodar o codificador de texto separadamente e liberar a memória dele (ele só roda uma vez por imagem, antes da remoção de ruído), ou ligar o offload automático para CPU, que move cada componente para a GPU só enquanto ele é usado:

from diffusers import ComponentsManager, ModularPipeline

manager = ComponentsManager()
manager.enable_auto_cpu_offload(device="cuda")
pipe = ModularPipeline.from_pretrained("black-forest-labs/flux-3-image-klein", components_manager=manager)

Velocidade: os números que a Hugging Face mediu

Os tempos abaixo são medidos pela própria Hugging Face, numa única H100 de 80GB, sem offload e com o backend de atenção padrão, média de três execuções após aquecimento:

O motivo de uma referência quase dobrar o tempo é direto: os tokens da referência entram na mesma sequência do texto e da imagem sendo gerada, e uma referência de 1024x1024 adiciona 4.096 tokens a cada chamada do transformer. Isso é custo real de computação por imagem, não só latência de rede, e precisa entrar na conta de quem vai colocar isso atrás de uma API própria.

Fine-tuning com LoRA, se o estilo padrão não servir

O Diffusers já publica scripts de DreamBooth LoRA para as duas tarefas, treinados a partir do checkpoint base. Um exemplo de texto para imagem, aprendendo um estilo de carta de tarot a partir do dataset multimodalart/1920-raider-waite-tarot-public-domain:

accelerate launch train_dreambooth_lora_flux3_klein.py \
 --pretrained_model_name_or_path="black-forest-labs/flux-3-image-klein-base" \
 --dataset_name="multimodalart/1920-raider-waite-tarot-public-domain" \
 --instance_prompt="trtcrd" \
 --resolution=1024 --rank=16 --lora_alpha=16 \
 --learning_rate=1e-4 --max_train_steps=1500 \
 --gradient_checkpointing --cache_latents --use_8bit_adam

As três últimas flags são as que importam para quem tem VRAM limitada: --gradient_checkpointing recalcula ativações no backward (menos memória, um pouco mais lento), --cache_latents pré-codifica as imagens e libera o VAE, e --use_8bit_adam guarda o estado do otimizador em 8 bits. Para edição por instrução, existe um script separado que treina em trios de (referência, alvo, instrução).

Por que ele responde mais rápido: a arquitetura por baixo

O FLUX.3 separa os tokens em três tipos (texto, imagem ruidosa, referências) e processa isso em dois estágios: primeiro cada tipo passa por 5 blocos próprios, sem olhar para os outros; depois os três fluxos se juntam numa sequência única que atravessa 28 blocos com pesos compartilhados, onde tudo atende a tudo. O Flux.2 deixava texto e imagem se misturarem desde o início; o Flux.3 separa primeiro, junta depois.

Outra mudança sutil mas relevante: no Flux.1 e no Flux.2, um único passo de tempo modula todos os tokens. No Flux.3, a imagem ruidosa é modulada pelo passo de tempo atual, mas texto e referências recebem sempre o passo de tempo zero, que sinaliza "isso já está limpo, não precisa remover ruído daqui".

É o esquema de posições RoPE em (h, w), compartilhado entre a referência e a saída, que dá sentido preciso a "o mesmo ponto na referência" para o modelo, e é disso que depende a edição por src_bbox/tgt_bbox. A marcação de timestep zero, por sua vez, apenas sinaliza que a referência é contexto já dado, não algo para gerar do zero.

Onde isso ainda não compensa

O ganho de velocidade e memória é real, mas vem com condição: os kernels rápidos do fp8r exigem GPU Ada, Hopper ou Blackwell, e o nvfp4 exige Blackwell com as bibliotecas flashinfer-python e flashinfer-cubin na mesma versão. Fora dessas placas, você ainda ganha memória menor, mas não ganha velocidade. E cada referência de imagem adicionada praticamente dobra o tempo de geração, então um pipeline de edição em lote com várias referências por imagem precisa dimensionar GPU pensando nisso, não só no tamanho do modelo base.

Fonte: Hugging Face Blog