AI Toolkit LoRA: preview/samples ótimos, mas a inferência no ComfyUI/Diffusers é diferente?

Se você treinou uma LoRA com o Ostris AI Toolkit, viu ótimos resultados nos Training Samples, mas depois obteve saídas bem diferentes na inferência em ComfyUI ou Diffusers, é normal ficar confuso. Talvez você tenha pesquisado coisas como:

“Os samples do AI Toolkit ficam bons mas o ComfyUI fica ruim”
“A LoRA do AI Toolkit não funciona no ComfyUI”
“Mesmo prompt/seed, mas o Diffusers não bate com o preview do AI Toolkit”
“Por que minha LoRA fica diferente depois do treinamento?”

Aqui vai a resposta direta (e geralmente tranquilizadora):

Em ~99% dos casos, sua LoRA está ok. O seu setup de inferência não é o mesmo da preview de treinamento.

Os Samples do AI Toolkit não são “execuções aleatórias do Diffusers”. Eles são produzidos por uma combinação específica de:

a variante exata do modelo base
como a LoRA é aplicada (adapter vs merged/fused)
semântica de steps/scheduler/guidance
tratamento de resolução (snapping/cropping)
comportamento de seed/RNG
(às vezes) inputs de condicionamento extras (edit/control/I2V wiring)

Se qualquer um desses pontos divergir, o resultado deriva.

Aqui vai um exemplo lado a lado do que você está vendo: AI Toolkit Training Sample vs seu toolchain atual de inferência (ComfyUI/Diffusers/etc.).

AI Toolkit training sample	Your inference toolchain

O que você vai ganhar com este guia

Sanity check de 60 segundos: trave estes 6 campos (não mexa no treino ainda)
Checklist de paridade de 10 minutos: 7 causas comuns de “preview ≠ inference” (por prioridade)
Não quer debugar? Obtenha paridade de inferência no RunComfy

Se você só quer que a inferência bata com os training samples do AI Toolkit (comece aqui)

Recomendado (workflow de paridade): AI Toolkit LoRA Training‑Inference Parity
Para auditar/self‑host (referência Diffusers): Open-source AI Toolkit inference code

Sanity check de 60 segundos: trave estes 6 campos (não mexa no treino ainda)

Escolha um AI Toolkit Training Sample que você quer reproduzir (o Sample #1 é ideal). Copie ou exporte estes campos exatamente:

1) Base model (variante/revisão exata — não apenas “FLUX”)

2) Prompt (incluindo a trigger word, na mesma posição)

3) Negative prompt (se o treino não usou, deixe vazio)

4) Width/height

5) Seed

6) Steps + guidance (e tudo relacionado a sampler/scheduler)

Se você igualar esses 6 campos e ainda assim houver muita divergência, você está vendo um dos problemas de paridade abaixo.

Checklist de paridade de 10 minutos: 7 causas comuns de “preview ≠ inference” (por prioridade)

Regra de ouro: mude uma variável por vez. Se você mudar cinco coisas, nunca vai saber o que resolveu.

1) Base model mismatch (mais comum e mais destrutivo)

2) Mismatch de tratamento de resolução (snapping / resize oculto)

3) Diferenças de semântica de steps/scheduler/guidance (modelos few‑step são ultra sensíveis)

4) Diferenças de semântica de seed/RNG (CPU vs GPU generator, seeding global)

5) Diferenças na aplicação da LoRA (adapter vs fuse/merge; loader errado)

6) Prompt/negative/trigger não idênticos (um token pode quebrar a paridade)

7) Família de pipeline errada / inputs de condicionamento faltando (edit/control/I2V)

Agora, como diagnosticar cada uma rapidamente.

1) Base model mismatch: “parece perto o suficiente” não é perto o suficiente

Sintomas

O visual todo deriva: rostos, textura, estilo, qualidade de detalhes.
Pode parecer que a LoRA “não aplica” de jeito nenhum.

Por que acontece

LoRAs são muito específicas do modelo base. Treinar em uma variante exata e inferir em outra (mesmo “mesma família”) frequentemente causa deriva grande.

Teste rápido

Abra o seu config/YAML de treino do AI Toolkit.
Encontre o identificador/caminho exato do modelo base.
Verifique se o ComfyUI/Diffusers está carregando o mesmo base model (não um “parecido”).

Armadilhas comuns

Misturar variantes do FLUX (dev vs schnell, 1 vs 2)
Misturar Qwen Image generation vs Qwen Image Edit
Misturar Z‑Image Turbo vs DeTurbo
Usar a família de tarefa errada do WAN 2.2 (T2V vs I2V)

Correção

Trate o training config como fonte de verdade: selecione o base model a partir do YAML, não de memória.

2) Mismatch de tratamento de resolução: você acha que é 1024, mas não é

Sintomas

A composição muda, a nitidez muda, detalhes borram.
A deriva é muito pior em modelos few‑step/turbo.

Por que acontece

Muitos stacks ajustam width/height para um divisor (geralmente 32). Se a preview do AI Toolkit “snappa” e seu stack não (ou vice‑versa), você não está rodando o mesmo tamanho de entrada.

Exemplo:

width  = (width  // divisor) * divisor
height = (height // divisor) * divisor

Teste rápido

Force uma resolução múltipla de 32 (ex.: 1024×1024, 1216×832).
No ComfyUI, procure por nodes ocultos de resize/crop/latent scaling.

Correção

Para paridade, trave width/height no que a preview realmente usou (incluindo regras de snapping).

3) Diferenças de steps/scheduler/guidance: modelos few‑step punem “hábitos SDXL”

Sintomas

O resultado fica borrado/sujo e perde a “crispness” da preview.
Ou “explode” em artefatos overcooked.

Por que acontece

Modelos destilados/turbo/few‑step normalmente esperam poucos steps e guidance baixo (às vezes guidance ≈ 1.0). Se você aplicar defaults SD/SDXL (steps 20–30, CFG 5–8), você sai do regime esperado.

Teste rápido

Force steps e guidance para bater exatamente com o Training Sample.
Não mude schedulers enquanto estiver depurando paridade.

Correção

Comece com os settings do Training Sample como ground truth. Depois que reproduzir, aí sim ajuste para o seu look.

4) Diferenças de seed/RNG: mesmo seed ≠ mesma sequência de ruído entre stacks

Sintomas

Mesmo prompt + mesmo seed, mas resultados muito diferentes.

Por que acontece

Stacks podem implementar seeding de formas diferentes:

seeding global vs por node
generator CPU vs GPU
consumo extra de RNG (random crops, jitter, etc.)

Teste rápido

Primeiro confirme reprodutibilidade dentro do mesmo stack (3 vezes igual).
Depois compare entre stacks.

Correção

Alinhe o handling de seed o máximo possível (seed global + semântica explícita do generator).

5) Aplicação da LoRA diferente: adapter vs fuse/merge (e “loader errado”)

Sintomas

Efeito da LoRA mais fraco/mais forte do que na preview.
Ou parece que a LoRA não foi aplicada.

Por que acontece

Duas diferenças comuns:

Adapter: aplica dinamicamente durante a inferência com scale.
Fuse/Merge: funde pesos no modelo e descarrega adapters.

Isso pode se comportar diferente. Além disso, usar um loader/pipeline que não corresponde à família do modelo pode “aplicar nada” silenciosamente.

Teste rápido

Igualar o scale da LoRA ao Training Sample.
Confirmar que o loader é o correto para a família do modelo (não misture pipelines entre famílias).

Correção

Use uma implementação de referência conhecida para essa família, reproduza o sample e depois porte o método para o seu stack.

6) Prompt / negative / trigger mismatch: um token pode quebrar a paridade

Sintomas

O estilo parece próximo, mas os “detalhes assinatura” somem.
Ou se comporta como um base model genérico.

Erros frequentes

Training negative vazio, mas sua UI injeta um negative padrão.
Trigger word faltando, errada ou movida.
Parsing/sintaxe de weights diferente entre ferramentas.

Teste rápido

Deixe o negative prompt vazio (como no training).
Copie/cole o prompt exato do Training Sample.

Correção

Para testar paridade, elimine defaults ocultos. Rode “limpo” primeiro.

7) Família de pipeline errada / inputs de condicionamento faltando (edit/control/I2V)

Sintomas

A lógica do output fica completamente errada.
Ou a inferência dá erro.

Por que acontece

Algumas famílias exigem inputs extras (control image, edit input, I2V). A preview pode estar usando esse wiring, mas sua inferência pode ser só prompt.

Teste rápido

O modelo exige control image ou edit input?
Você está usando a família de pipeline correta para a tarefa?

Correção

Troque para o pipeline correto e forneça os inputs necessários.

Não quer debugar? Obtenha paridade de inferência no RunComfy

Não quer perseguir o drift do ComfyUI/Diffusers por conta própria? O RunComfy já fornece pipelines de paridade de training & inference para as famílias do AI Toolkit, então você não precisa reconstruir a pipeline exata da preview na mão.

Tudo que você precisa é sua LoRA e o Training config (YAML) do seu run no AI Toolkit. Importe em Trainer → LoRA Assets e clique Run (Run LoRA). O RunComfy executa a pipeline correta do base model com o comportamento crítico de paridade para que os resultados batam com os training samples.

Workflow: AI Toolkit LoRA Training‑Inference Parity.

Exemplo na prática (AI Toolkit Training Sample vs inferência RunComfy com config aplicado):

AI Toolkit training sample	RunComfy inference (Playground/API)

Quer ir mais fundo?

Open-source AI Toolkit inference code (pipelines Diffusers auditáveis, adapters, schedulers)

FAQ

“Minha LoRA do AI Toolkit funciona nos Training Samples, mas não faz nada no ComfyUI.”

Comece por base model mismatch e loader mismatch. A maioria dos casos de “não faz nada” é:

variante errada do base model
método/loader errado de aplicação de LoRA
negative prompt/defaults ocultos

“Por que os Samples do AI Toolkit são mais nítidos que meu output do Diffusers?”

Geralmente um destes:

mismatch de regime de steps/guidance (especialmente few‑step)
diferenças de snapping de resolução
diferenças de scheduler/timestep

“Como faço para a inferência coincidir com a preview de training de forma confiável?”

Trate o training config como ground truth e trave:

base model
width/height (incluindo regras de snapping)
família de steps/guidance/scheduler
método e scale de aplicação da LoRA
semântica de seed

Se você quer isso como um workflow repetível de Run LoRA (Playground/API), construa a inferência em torno desse mesmo config.