Wenn du eine LoRA mit Ostris AI Toolkit trainiert hast, in den Training Samples großartige Ergebnisse siehst, aber in ComfyUI oder Diffusers bei der Inferenz plötzlich stark abweichende Outputs bekommst, wirkt das oft völlig widersprüchlich. Vielleicht hast du nach Dingen gesucht wie:
- „AI Toolkit Samples sehen gut aus, aber ComfyUI sieht schlecht aus“
- „AI Toolkit LoRA funktioniert nicht in ComfyUI“
- „Gleicher Prompt/Seed, aber Diffusers passt nicht zur AI‑Toolkit‑Preview“
- „Warum sieht meine LoRA nach dem Training anders aus?“
Hier ist die direkte (und meist beruhigende) Antwort:
In ~99% der Fälle ist deine LoRA in Ordnung. Dein Inferenz‑Setup ist nur nicht dasselbe wie die Training‑Preview.
AI‑Toolkit‑Samples sind keine „zufälligen Diffusers‑Runs“. Sie entstehen durch eine sehr spezifische Kombination aus:
- der exakten Base‑Model‑Variante
- wie die LoRA injiziert wird (Adapter vs merged/fused)
- Step/Scheduler/Guidance‑Semantik
- Auflösungs‑Handling (Snapping/Cropping‑Regeln)
- Seed/RNG‑Verhalten
- (manchmal) zusätzlichen Conditioning‑Inputs (Edit/Control/I2V‑Wiring)
Wenn irgendeiner dieser Punkte abweicht, driftet das Ergebnis.
Hier ein schneller Side‑by‑Side‑Vergleich dessen, was du siehst: AI Toolkit Training Sample vs deine aktuelle Inferenz‑Toolchain (ComfyUI/Diffusers/etc.).
| AI Toolkit training sample | Your inference toolchain |
|---|---|
 |
 |
Was du aus diesem Guide mitnimmst
- 60‑Sekunden‑Sanity‑Check: diese 6 Felder fixieren (Training noch nicht anfassen)
- 10‑Minuten‑Parity‑Checkliste: 7 häufige Ursachen „Preview ≠ Inference“ (nach Priorität)
- Keine Lust zu debuggen? Inferenz‑Parity auf RunComfy
Wenn du nur willst, dass die Inferenz zu deinen AI‑Toolkit‑Training‑Samples passt (start here)
- Empfohlen (Parity‑Workflow): AI Toolkit LoRA Training‑Inference Parity
- Zum Audit/Self‑Host (Diffusers‑Referenz): Open-source AI Toolkit inference code
60‑Sekunden‑Sanity‑Check: diese 6 Felder fixieren (Training noch nicht anfassen)
Wähle ein AI‑Toolkit‑Training‑Sample, das du reproduzieren willst (Sample #1 ist ideal). Kopiere oder exportiere diese Punkte exakt:
1) Base model (exakte Variante/Revision — nicht nur „FLUX“)
2) Prompt (inkl. Trigger‑Wort, an derselben Position)
3) Negative prompt (wenn Training keinen hatte, leer lassen)
4) Width/height
5) Seed
6) Steps + guidance (und alles Sampler/Scheduler‑Relevante)
Wenn diese 6 Felder stimmen und es trotzdem stark driftet, liegt es sehr wahrscheinlich an einem der Parity‑Themen unten.
10‑Minuten‑Parity‑Checkliste: 7 häufige Ursachen „Preview ≠ Inference“ (nach Priorität)
Faustregel: Ändere immer nur eine Variable. Wenn du fünf Dinge gleichzeitig änderst, weißt du nie, was es gefixt hat.
1) Base‑Model‑Mismatch (am häufigsten, am zerstörerischsten)
2) Auflösungs‑Handling‑Mismatch (Snapping / verstecktes Resize)
3) Steps/Scheduler/Guidance‑Semantik unterscheidet sich (Few‑Step‑Models sind ultrasensibel)
4) Seed/RNG‑Semantik unterscheidet sich (CPU vs GPU Generator, Global‑Seeding)
5) LoRA‑Anwendung unterscheidet sich (Adapter vs Fuse/Merge; falscher Loader)
6) Prompt/Negative/Trigger‑Wort nicht identisch (ein Token kann Parity brechen)
7) Falsche Pipeline‑Familie / fehlende Conditioning‑Inputs (Edit/Control/I2V)
Jetzt: wie du jede Ursache schnell diagnostizierst.
1) Base‑Model‑Mismatch: „sieht nah genug aus“ ist nicht nah genug
Symptome
- Der gesamte Look driftet: Gesichter, Textur, Stil, Detailqualität.
- Es kann so wirken, als würde die LoRA gar nicht angewendet.
Warum das passiert
LoRAs sind stark base‑model‑spezifisch. Auf einer exakten Base‑Model‑Variante trainieren und auf einer anderen (selbst „gleiche Familie“) inferieren, führt oft zu massivem Drift.
Schnelltest
- Öffne deine AI‑Toolkit‑Trainings‑Config/YAML.
- Suche die exakte Base‑Model‑ID/den Pfad.
- Prüfe, dass ComfyUI/Diffusers dieselbe Base lädt (nicht eine ähnlich benannte).
Häufige Fallen
- FLUX‑Varianten mischen (z.B. dev vs schnell, 1 vs 2)
- Qwen Image generation vs Qwen Image Edit mischen
- Z‑Image Turbo vs DeTurbo mischen
- Falsche WAN‑2.2‑Task‑Familie (T2V vs I2V)
Fix
Behandle die Trainings‑Config als Source of Truth: Base‑Model aus der YAML wählen, nicht aus dem Gedächtnis.
2) Auflösungs‑Handling‑Mismatch: du denkst es ist 1024, aber es ist es nicht
Symptome
- Komposition verschiebt sich, Schärfe ändert sich, Details verschmieren.
- Drift ist bei Few‑Step/Turbo‑Models viel stärker.
Warum das passiert
Viele Inferenz‑Implementierungen passen Width/Height an einen Divisor an (oft 32). Wenn AI‑Toolkit‑Preview snappt, dein Stack aber nicht (oder umgekehrt), laufen die Inputs nicht in derselben Größe.
Beispielmuster:
width = (width // divisor) * divisor
height = (height // divisor) * divisorSchnelltest
- Erzwinge eine saubere 32‑Multiple‑Auflösung (z.B. 1024×1024, 1216×832).
- In ComfyUI: nach versteckten Resize/Crop/Latent‑Scaling‑Nodes suchen.
Fix
Für Parity: Width/Height auf das fixieren, was die Preview effektiv genutzt hat (inkl. Snapping‑Regeln).
3) Steps/Scheduler/Guidance‑Semantik unterscheidet sich: Few‑Step‑Models bestrafen „SDXL‑Gewohnheiten“
Symptome
- Ergebnis wird blurry/dirty und verliert die „Preview‑Crispness“.
- Oder es explodiert in overcooked Artefakte.
Warum das passiert
Distilled/Turbo/Few‑Step‑Models erwarten oft wenige Steps und niedrige Guidance (manchmal Guidance ≈ 1.0). Wenn du SD/SDXL‑Defaults nutzt (20–30 Steps, CFG 5–8), verlässt du schnell den intended regime.
Schnelltest
- Steps und Guidance exakt wie im Training Sample setzen.
- Beim Parity‑Debuggen keine Scheduler‑Wechsel.
Fix
Starte mit den Training‑Sample‑Settings als Ground Truth. Erst wenn du reproduzierst, danach tunen.
4) Seed/RNG‑Semantik unterscheidet sich: gleicher Seed ≠ gleicher Noise‑Stream über Stacks
Symptome
- Gleicher Prompt + gleicher Seed, aber völlig andere Outputs.
Warum das passiert
Stapel implementieren Seeding unterschiedlich:
- Global‑Seeding vs per‑Node‑Seeding
- CPU‑Generator vs GPU‑Generator
- zusätzlicher RNG‑Verbrauch (Random Crops, Jitter, etc.)
Schnelltest
- Erst Reproduzierbarkeit innerhalb desselben Stacks prüfen (3 Läufe, gleiches Ergebnis).
- Dann Stack‑übergreifend vergleichen.
Fix
Seed‑Handling so eng wie möglich angleichen (globaler Seed + explizite Generator‑Semantik).
5) LoRA‑Anwendung unterscheidet sich: Adapter vs Fuse/Merge (und „falscher Loader“)
Symptome
- LoRA‑Effekt schwächer/stärker als in der Preview.
- Oder es wirkt, als würde die LoRA gar nicht angewendet.
Warum das passiert
Zwei häufige Unterschiede:
- Adapter‑Anwendung: LoRA wird dynamisch mit Scale während der Inferenz angewendet.
- Fuse/Merge‑Anwendung: LoRA‑Gewichte werden in das Modell gemerged, Adapter werden entladen.
Das kann sich anders verhalten. Zusätzlich: ein LoRA‑Loader/Pipeline‑Mismatch zur Modellfamilie kann stillschweigend „nichts anwenden“.
Schnelltest
- LoRA‑Scale wie im Training Sample setzen.
- Prüfen, dass der Loader zur Modellfamilie passt (keine Family‑Cross‑Pipelines).
Fix
Nutze zuerst eine Referenz‑Implementierung, die AI‑Toolkit‑LoRAs für diese Familie sicher unterstützt, reproduziere das Sample, portiere dann in deinen Stack.
6) Prompt / Negative / Trigger‑Wort‑Mismatch: ein Token kann Parity brechen
Symptome
- Stil ist nah dran, aber „Signature Details“ fehlen.
- Oder es verhält sich wie ein generisches Base‑Model.
Häufige Stolpersteine
- Training‑Negative ist leer, aber deine UI injiziert eine Default‑Negative.
- Trigger‑Wort fehlt, ist falsch geschrieben oder verschoben.
- Unterschiedliche Prompt‑Parsing/Weight‑Syntax zwischen Tools.
Schnelltest
- Negative prompt leer setzen (wie im Training).
- Prompt aus dem Training Sample exakt copy/pasten.
Fix
Für Parity‑Tests: versteckte Defaults eliminieren. Erst „clean“ laufen lassen.
7) Falsche Pipeline‑Familie / fehlende Conditioning‑Inputs (Edit/Control/I2V)
Symptome
- Output‑Logik ist komplett falsch.
- Oder Inferenz wirft Fehler.
Warum das passiert
Manche Modellfamilien brauchen zusätzliche Inputs (Control Images, Edit Inputs, I2V‑Conditioning). Die Preview kann diese Wiring nutzen, dein Run ist aber prompt‑only.
Schnelltest
- Braucht das Modell ein Control‑Image oder Edit‑Input?
- Nutzt du die richtige Pipeline‑Familie für die Task?
Fix
Auf die korrekte Pipeline wechseln und die nötigen Inputs liefern.
Keine Lust zu debuggen? Inferenz‑Parity auf RunComfy
Keine Lust, ComfyUI/Diffusers‑Drift selbst zu jagen? RunComfy stellt bereits Training‑ & Inferenz‑Parity‑Pipelines für die AI‑Toolkit‑Modellfamilien bereit, sodass du die Preview‑Sampling‑Pipeline nicht von Hand nachbauen musst.
Alles was du brauchst:
- deine LoRA
- die Training‑Config (YAML) aus deinem AI‑Toolkit‑Run
Importiere beides in Trainer → LoRA Assets, klicke Run (Run LoRA) und starte sofort die Inferenz. RunComfy nutzt die korrekte Base‑Model‑Pipeline mit parity‑kritischem Verhalten, damit die Ergebnisse zu den Training‑Previews passen.
Workflow: AI Toolkit LoRA Training‑Inference Parity.
So sieht das in der Praxis aus (AI‑Toolkit‑Sample vs RunComfy‑Inferenz mit Training‑Config):
| AI Toolkit training sample | RunComfy inference (Playground/API) |
|---|---|
 |
 |
|
 |
 |
 |
Noch tiefer gehen?
- Open-source AI Toolkit inference code (auditierbare Diffusers‑Pipelines, Adapter, Scheduler)
FAQ
„Meine AI‑Toolkit‑LoRA funktioniert in den Training Samples, aber in ComfyUI tut sie nichts.“
Starte mit Base‑Model‑Mismatch und LoRA‑Loader‑Mismatch. Die meisten „tut nichts“-Reports sind:
- falsche Base‑Model‑Variante
- falsche LoRA‑Injection/Loader
- versteckte Negative‑Prompts/Defaults
„Warum sind AI‑Toolkit‑Samples schärfer als mein Diffusers‑Output?“
Meist eines davon:
- Steps/Guidance‑Regime‑Mismatch (besonders bei Few‑Step‑Models)
- unterschiedliche Resolution‑Snapping‑Regeln
- Scheduler/Timestep‑Unterschiede
„Wie bekomme ich Inferenz zuverlässig auf Training‑Preview‑Niveau?“
Behandle die Training‑Config als Ground Truth und locke:
- base model
- width/height (inkl. Snapping‑Regeln)
- steps/guidance/scheduler family
- LoRA‑Injection‑Methode und Scale
- seed semantics
Wenn du das als reproduzierbaren Run‑LoRA‑Workflow (Playground/API) willst, baue deine Inferenz um genau diese Config herum.
Bereit zum Starten des Trainings?