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) * divisorTeste 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.
Pronto para começar o treinamento?