AI Toolkit LoRA: preview/samples ottimi, ma inferenza ComfyUI/Diffusers diversa?

Se hai addestrato una LoRA con Ostris AI Toolkit, hai visto ottimi risultati nei Training Samples, e poi in ComfyUI o Diffusers in inferenza ottieni output molto diversi, è normale rimanere confusi. Forse hai cercato cose tipo:

“I samples di AI Toolkit sono belli ma ComfyUI fa schifo”
“La LoRA di AI Toolkit non funziona in ComfyUI”
“Stesso prompt/seed, ma Diffusers non coincide con l’anteprima di AI Toolkit”
“Perché la mia LoRA sembra diversa dopo il training?”

Ecco la risposta schietta (e di solito rassicurante):

Nel ~99% dei casi la tua LoRA è OK. È la tua configurazione di inferenza che non è la stessa della preview di training.

I Samples di AI Toolkit non sono “run Diffusers casuali”. Sono prodotti da una combinazione specifica di:

la variante esatta del modello base
come viene applicata la LoRA (adapter vs merged/fused)
semantica di steps/scheduler/guidance
gestione della risoluzione (snapping/cropping)
comportamento di seed/RNG
(a volte) input di conditioning extra (edit/control/I2V wiring)

Se anche solo uno di questi elementi cambia, i risultati “driftano”.

Ecco un esempio rapido affiancato di ciò che stai vedendo: AI Toolkit Training Sample vs la tua toolchain di inferenza (ComfyUI/Diffusers/etc.).

AI Toolkit training sample	Your inference toolchain

Cosa otterrai da questa guida

Sanity check in 60 secondi: blocca questi 6 campi (non toccare ancora il training)
Checklist di parità in 10 minuti: 7 cause comuni di “preview ≠ inference” (in ordine di priorità)
Non vuoi fare debugging? Ottieni la parità di inferenza su RunComfy

Se vuoi solo che l’inferenza corrisponda ai training samples di AI Toolkit (inizia qui)

Consigliato (workflow di parità): AI Toolkit LoRA Training‑Inference Parity
Per audit/self‑host (riferimento Diffusers): Open-source AI Toolkit inference code

Sanity check in 60 secondi: blocca questi 6 campi (non toccare ancora il training)

Scegli un AI Toolkit Training Sample che vuoi riprodurre (Sample #1 è ideale). Copia o esporta questi valori esattamente:

1) Base model (variante/revisione esatta — non solo “FLUX”)

2) Prompt (inclusa la trigger word, nella stessa posizione)

3) Negative prompt (se il training non ne usava, lascialo vuoto)

4) Width/height

5) Seed

6) Steps + guidance (e tutto ciò che riguarda sampler/scheduler)

Se questi 6 campi coincidono e i risultati divergono ancora molto, stai guardando uno dei problemi di parità qui sotto.

Checklist di parità in 10 minuti: 7 cause comuni di “preview ≠ inference” (in ordine di priorità)

Regola pratica: cambia una variabile alla volta. Se cambi cinque cose insieme, non saprai mai cosa l’ha risolto.

1) Base model mismatch (più comune, più distruttivo)

2) Mismatch nella gestione della risoluzione (snapping / resize nascosto)

3) Differenze nella semantica di steps/scheduler/guidance (i modelli few‑step sono ultra sensibili)

4) Differenze nella semantica di seed/RNG (CPU vs GPU generator, seed globale)

5) Differenze nell’applicazione della LoRA (adapter vs fuse/merge; loader sbagliato)

6) Prompt/negative/trigger non identici (un token può rompere la parità)

7) Famiglia pipeline sbagliata / input di conditioning mancanti (edit/control/I2V)

Ora, come diagnosticarle velocemente.

1) Base model mismatch: “sembra abbastanza simile” non è abbastanza simile

Sintomi

Deriva l’aspetto complessivo: volti, texture, stile, qualità dei dettagli.
Può sembrare che la LoRA “non si applichi” affatto.

Perché succede

Le LoRA sono molto specifiche del modello base. Addestrare su una variante esatta e fare inferenza su un’altra (anche “stessa famiglia”) spesso causa deriva significativa.

Test rapido

Apri la tua config/YAML di training di AI Toolkit.
Trova l’identificatore/percorso esatto del modello base.
Verifica che ComfyUI/Diffusers stia caricando lo stesso base model (non uno con nome simile).

Trappole comuni

Mescolare varianti FLUX (es. dev vs schnell, 1 vs 2)
Mescolare Qwen Image generation vs Qwen Image Edit
Mescolare Z‑Image Turbo vs DeTurbo
Usare la famiglia task sbagliata per WAN 2.2 (T2V vs I2V)

Fix

Tratta la config di training come source of truth: scegli il base model dal YAML, non a memoria.

2) Mismatch nella gestione della risoluzione: pensi sia 1024, ma non lo è

Sintomi

Cambia la composizione, cambia la nitidezza, i dettagli si “sporcano”.
La deriva è molto peggiore sui modelli few‑step/turbo.

Perché succede

Molte implementazioni aggiustano width/height a un divisore (spesso 32). Se la preview di AI Toolkit “snappa” ma il tuo stack no (o viceversa), non stai usando la stessa dimensione di input.

Esempio:

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

Test rapido

Forza una risoluzione multipla di 32 (es. 1024×1024, 1216×832).
In ComfyUI, controlla nodi nascosti di resize/crop/latent scaling.

Fix

Per parità, blocca width/height a ciò che la preview ha effettivamente usato (incluse le regole di snapping).

3) Differenze di semantica steps/scheduler/guidance: i modelli few‑step puniscono le “abitudini SDXL”

Sintomi

Risultato più blurry/sporco, perde la “crispness” della preview.
Oppure si “cuoce” troppo e compaiono artefatti.

Perché succede

I modelli distillati/turbo/few‑step spesso richiedono pochi steps e guidance basso (a volte guidance ≈ 1.0). Se applichi i default SD/SDXL (steps 20–30, CFG 5–8), esci dal regime previsto.

Test rapido

Imposta steps e guidance esattamente come nel Training Sample.
Non cambiare scheduler mentre fai troubleshooting di parità.

Fix

Parti dalle impostazioni del Training Sample come ground truth. Quando riesci a riprodurre, poi ottimizza.

4) Differenze di semantica seed/RNG: stesso seed ≠ stessa sequenza di rumore tra stack

Sintomi

Stesso prompt + stesso seed, ma risultati molto diversi.

Perché succede

Gli stack possono implementare il seeding in modo diverso:

seeding globale vs per‑node
generator CPU vs GPU
consumo RNG extra (random crop, jitter, ecc.)

Test rapido

Prima verifica la riproducibilità nello stesso stack (3 run uguali).
Poi confronta tra stack.

Fix

Allinea la gestione del seed il più possibile (seed globale + semantica esplicita del generator).

5) Applicazione LoRA diversa: adapter vs fuse/merge (e “loader sbagliato”)

Sintomi

Effetto LoRA più debole/più forte rispetto alla preview.
Oppure sembra che la LoRA non venga applicata.

Perché succede

Due differenze comuni:

Adapter: applica la LoRA dinamicamente durante l’inferenza con uno scale.
Fuse/Merge: fonde i pesi LoRA nel modello e scarica gli adapter.

Possono comportarsi in modo diverso. Inoltre, usare un loader/pipeline non adatto alla famiglia del modello può “non applicare nulla” silenziosamente.

Test rapido

Allinea lo scale LoRA al Training Sample.
Conferma che il loader/pipeline sia corretto per la famiglia del modello (non mescolare famiglie).

Fix

Usa una reference implementation nota per supportare le LoRA AI Toolkit per quella famiglia, riproduci il sample, poi porta lo stesso metodo nel tuo stack.

6) Prompt / negative / trigger mismatch: un token può rompere la parità

Sintomi

Lo stile è vicino, ma mancano i “dettagli firma”.
Oppure si comporta come un base model generico.

Errori frequenti

Il training usa negative vuoto, ma la UI di inferenza inietta un negative di default.
Trigger word mancante, sbagliata o spostata.
Parsing/weight syntax diversa tra tool.

Test rapido

Imposta il negative prompt vuoto (come nel training).
Copia/incolla il prompt esatto dal Training Sample.

Fix

Per test di parità, elimina i default nascosti. Esegui prima una run “pulita”.

7) Famiglia pipeline sbagliata / input di conditioning mancanti (edit/control/I2V)

Sintomi

Logica di output completamente sbagliata.
Oppure l’inferenza va in errore.

Perché succede

Alcune famiglie richiedono input extra (control image, edit input, I2V conditioning). La preview potrebbe usare quel wiring, ma la tua inferenza potrebbe essere solo prompt.

Test rapido

Il modello richiede una control image o un edit input?
Stai usando la famiglia pipeline corretta per il task?

Fix

Passa alla pipeline corretta e fornisci gli input richiesti.

Non vuoi fare debugging? Ottieni la parità di inferenza su RunComfy

Non vuoi inseguire la deriva ComfyUI/Diffusers da solo? RunComfy offre già pipeline di parità training & inference per le famiglie di modelli AI Toolkit, così non devi ricostruire a mano la pipeline della preview.

Ti servono solo la tua LoRA e il Training config (YAML) del run AI Toolkit. Importali in Trainer → LoRA Assets, poi clicca Run (Run LoRA) per iniziare subito l’inferenza. RunComfy esegue la pipeline corretta del base model con il comportamento critico di parità, così i risultati corrispondono ai training samples.

Workflow: AI Toolkit LoRA Training‑Inference Parity.

Ecco com’è in pratica (AI Toolkit Training Sample vs inferenza RunComfy con la config applicata):

AI Toolkit training sample	RunComfy inference (Playground/API)

Vuoi approfondire?

Open-source AI Toolkit inference code (pipeline Diffusers auditabili, adapter, scheduler)

FAQ

“La mia LoRA AI Toolkit funziona nei Training Samples, ma in ComfyUI non fa nulla.”

Inizia da base model mismatch e loader mismatch. La maggior parte dei casi “non fa nulla” è:

variante base model sbagliata
metodo/loader LoRA sbagliato
negative prompt/defaults nascosti

“Perché i Samples di AI Toolkit sono più nitidi del mio output Diffusers?”

Di solito è uno di questi:

mismatch regime steps/guidance (soprattutto few‑step)
differenze di snapping risoluzione
differenze di scheduler/timestep

“Come faccio a far coincidere l’inferenza con la preview di training in modo affidabile?”

Tratta il training config come ground truth e blocca:

base model
width/height (incluse regole di snapping)
famiglia steps/guidance/scheduler
metodo e scale di applicazione LoRA
semantica seed

Se vuoi renderlo un workflow Run LoRA ripetibile (Playground/API), costruisci l’inferenza attorno a quella stessa config.