AI Toolkit LoRA : preview/samples super, mais ComfyUI/Diffusers diffère en inférence ?

Si vous avez entraîné une LoRA avec Ostris AI Toolkit, obtenu d’excellents résultats dans les Training Samples, puis des sorties très différentes en inférence dans ComfyUI ou Diffusers, c’est normal d’être perdu. Vous avez peut‑être cherché :

« Les samples AI Toolkit sont bons mais ComfyUI est mauvais »
« La LoRA AI Toolkit ne marche pas dans ComfyUI »
« Même prompt/seed, mais Diffusers ne correspond pas à la preview AI Toolkit »
« Pourquoi ma LoRA est différente après l’entraînement ? »

Voici la réponse directe (et souvent rassurante) :

Dans ~99% des cas, votre LoRA est OK. C’est votre configuration d’inférence qui n’est pas la même que la preview d’entraînement.

Les Samples AI Toolkit ne sont pas des « runs Diffusers au hasard ». Ils sont produits par une combinaison très précise de :

la variante exacte du modèle de base
la manière d’injecter la LoRA (adapter vs merged/fused)
la sémantique steps/scheduler/guidance
la gestion de la résolution (snapping/cropping)
le comportement seed/RNG
(parfois) des entrées de conditionnement supplémentaires (edit/control/I2V wiring)

Si un seul de ces éléments diffère, les résultats dérivent.

Voici un aperçu côte à côte de ce que vous voyez : AI Toolkit Training Sample vs votre toolchain d’inférence actuelle (ComfyUI/Diffusers/etc.).

AI Toolkit training sample	Your inference toolchain

Ce que vous allez obtenir avec ce guide

Sanity check en 60 secondes : verrouillez ces 6 champs (ne touchez pas encore au training)
Checklist de parité en 10 minutes : 7 causes fréquentes « preview ≠ inference » (par priorité)
Pas envie de debugger ? Obtenez la parité d’inférence sur RunComfy

Si vous voulez juste que l’inférence corresponde à vos training samples AI Toolkit (commencez ici)

Recommandé (workflow de parité) : AI Toolkit LoRA Training‑Inference Parity
Audit/self‑host (référence Diffusers) : Open-source AI Toolkit inference code

Sanity check en 60 secondes : verrouillez ces 6 champs (ne touchez pas encore au training)

Choisissez un AI Toolkit Training Sample que vous voulez reproduire (le Sample #1 est idéal). Copiez/exportez à l’identique :

1) Base model (variante/révision exacte — pas seulement « FLUX »)

2) Prompt (y compris le trigger word, au même endroit)

3) Negative prompt (si le training n’en utilisait pas, laissez vide)

4) Width/height

5) Seed

6) Steps + guidance (et tout ce qui touche au sampler/scheduler)

Si ces 6 champs sont identiques et que ça diverge encore fortement, vous êtes probablement face à l’un des problèmes de parité ci‑dessous.

Checklist de parité en 10 minutes : 7 causes fréquentes « preview ≠ inference » (par priorité)

Règle d’or : ne changez qu’une variable à la fois. Si vous changez cinq choses, vous ne saurez jamais ce qui a corrigé.

1) Base model mismatch (le plus courant, le plus destructeur)

2) Mismatch de gestion de résolution (snapping / resize caché)

3) Différences de sémantique steps/scheduler/guidance (les modèles few‑step sont ultra sensibles)

4) Différences de sémantique seed/RNG (CPU vs GPU generator, seeding global)

5) Différences d’application de la LoRA (adapter vs fuse/merge ; mauvais loader)

6) Prompt/negative/trigger non identiques (un token peut casser la parité)

7) Mauvaise famille de pipeline / entrées de conditionnement manquantes (edit/control/I2V)

Voyons comment diagnostiquer chaque point rapidement.

1) Base model mismatch : « assez proche » n’est pas assez proche

Symptômes

Tout le rendu dérive : visages, texture, style, qualité des détails.
On dirait parfois que la LoRA « ne s’applique pas ».

Pourquoi

Les LoRA sont très spécifiques au modèle de base. Entraîner sur une variante exacte et inférer sur une autre (même « même famille ») entraîne souvent une dérive importante.

Test rapide

Ouvrez votre config/YAML d’entraînement AI Toolkit.
Trouvez l’identifiant/le chemin exact du modèle de base.
Vérifiez que ComfyUI/Diffusers charge le même base model (pas un modèle au nom similaire).

Pièges fréquents

Mélanger des variantes FLUX (dev vs schnell, 1 vs 2)
Mélanger Qwen Image generation vs Qwen Image Edit
Mélanger Z‑Image Turbo vs DeTurbo
Utiliser la mauvaise famille de tâche WAN 2.2 (T2V vs I2V)

Fix

Considérez la config d’entraînement comme source de vérité : sélectionnez le base model depuis le YAML, pas au feeling.

2) Mismatch de gestion de résolution : vous pensez être en 1024, mais non

Symptômes

La composition bouge, la netteté change, les détails bavent.
La dérive est bien pire sur les modèles few‑step/turbo.

Pourquoi

Beaucoup d’implémentations ajustent width/height à un diviseur (souvent 32). Si la preview AI Toolkit “snap” mais votre stack ne le fait pas (ou inversement), vous n’utilisez pas la même taille d’entrée.

Exemple :

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

Test rapide

Forcez une résolution multiple de 32 (ex. 1024×1024, 1216×832).
Dans ComfyUI, cherchez des nodes cachés de resize/crop/latent scaling.

Fix

Pour la parité, verrouillez width/height à ce que la preview a réellement utilisé (snapping inclus).

3) Différences steps/scheduler/guidance : les modèles few‑step punissent les « habitudes SDXL »

Symptômes

Résultat flou/sale, perte de la netteté de la preview.
Ou artefacts “overcooked”.

Pourquoi

Les modèles distillés/turbo/few‑step attendent souvent peu de steps et une guidance faible (parfois ≈ 1.0). Si vous appliquez des defaults SD/SDXL (20–30 steps, CFG 5–8), vous sortez du régime prévu.

Test rapide

Forcez steps et guidance exactement comme le Training Sample.
Ne changez pas de scheduler tant que vous cherchez la parité.

Fix

Partez des settings du Training Sample comme ground truth. Une fois reproductible, vous pourrez ajuster.

4) Différences seed/RNG : même seed ≠ même bruit entre stacks

Symptômes

Même prompt + même seed, mais résultats très différents.

Pourquoi

Les stacks gèrent le seeding différemment :

seeding global vs par node
générateur CPU vs GPU
consommation RNG supplémentaire (random crops, jitter, etc.)

Test rapide

Vérifiez d’abord la reproductibilité au sein d’un même stack (3 runs identiques).
Puis comparez entre stacks.

Fix

Alignez autant que possible le seed handling (seed global + sémantique explicite du generator).

5) Application LoRA différente : adapter vs fuse/merge (et « mauvais loader »)

Symptômes

Effet LoRA plus faible/plus fort que la preview.
Ou impression que la LoRA ne s’applique pas.

Pourquoi

Deux différences fréquentes :

Adapter : application dynamique de la LoRA avec un scale pendant l’inférence.
Fuse/Merge : fusion des poids dans le modèle puis déchargement des adapters.

Le comportement peut diverger. Et un loader/pipeline qui ne correspond pas à la famille de modèle peut « appliquer rien » silencieusement.

Test rapide

Faites correspondre le scale LoRA au Training Sample.
Confirmez que le loader/pipeline est bien celui de la famille de modèle (évitez les mélanges).

Fix

Utilisez une implémentation de référence connue pour supporter ces LoRA, reproduisez le sample, puis portez la même méthode dans votre stack.

6) Prompt / negative / trigger mismatch : un token peut casser la parité

Symptômes

Style proche, mais les « détails signature » manquent.
Ou comportement comme un base model générique.

Pièges fréquents

Training negative vide, mais votre UI injecte un negative par défaut.
Trigger manquant, mal orthographié ou déplacé.
Parsing/weights différents entre outils.

Test rapide

Mettez le negative prompt vide (comme en training).
Copiez/collez le prompt exact du Training Sample.

Fix

Pour les tests de parité, éliminez les defaults cachés. Lancez d’abord une run “clean”.

7) Mauvaise famille de pipeline / entrées manquantes (edit/control/I2V)

Symptômes

Logique de sortie totalement incorrecte.
Ou erreurs à l’exécution.

Pourquoi

Certaines familles exigent des inputs supplémentaires (control image, edit input, I2V). La preview peut les utiliser, mais votre run peut être prompt‑only.

Test rapide

Le modèle requiert‑il une control image ou un edit input ?
Utilisez‑vous la bonne famille de pipeline ?

Fix

Passez à la bonne pipeline et fournissez les inputs requis.

Pas envie de debugger ? Obtenez la parité d’inférence sur RunComfy

Vous ne voulez pas traquer la dérive ComfyUI/Diffusers vous‑même ? RunComfy fournit déjà des pipelines de parité training & inference pour les familles AI Toolkit, vous évitant de reconstruire la pipeline exacte de preview.

Tout ce qu’il vous faut : votre LoRA et le Training config (YAML) de votre run AI Toolkit. Importez‑les dans Trainer → LoRA Assets, puis cliquez Run (Run LoRA). RunComfy exécute la bonne pipeline base model avec le comportement critique de parité, pour coller aux training samples.

Workflow : AI Toolkit LoRA Training‑Inference Parity.

Exemple (AI Toolkit Training Sample vs inférence RunComfy avec la config appliquée) :

AI Toolkit training sample	RunComfy inference (Playground/API)

Pour aller plus loin :

Open-source AI Toolkit inference code (pipelines Diffusers auditables, adapters, schedulers)

FAQ

« Ma LoRA AI Toolkit marche dans les Training Samples, mais ne fait rien dans ComfyUI. »

Commencez par base model mismatch et LoRA loader mismatch. La plupart des cas « ne fait rien » sont :

mauvaise variante de base model
mauvaise méthode/loader d’injection LoRA
negative prompt/defaults cachés

« Pourquoi les Samples AI Toolkit sont plus nets que mon output Diffusers ? »

Souvent l’un de ces points :

mismatch de régime steps/guidance (surtout sur few‑step)
différences de snapping de résolution
différences de scheduler/timestep

« Comment rendre l’inférence cohérente avec la preview d’entraînement ? »

Traitez la config d’entraînement comme ground truth et verrouillez :

base model
width/height (snapping inclus)
famille steps/guidance/scheduler
méthode et scale d’application LoRA
sémantique de seed

Si vous voulez en faire un workflow Run LoRA répétable (Playground/API), bâtissez l’inférence autour de cette même config.