Diese Seite bietet einen Überblick über das LoRA-Finetuning mit dem Ostris AI Toolkit. Für eine modell­spezifische Anleitung springen Sie zu einem dieser Guides:

• FLUX.2 Dev LoRA-Training mit AI Toolkit
• LTX-2 LoRA-Training mit AI Toolkit
• Z‑Image Turbo LoRA-Training mit AI Toolkit
• Qwen Image 2512 LoRA-Training mit AI Toolkit
• Qwen‑Image‑Edit‑2511 LoRA-Training mit AI Toolkit
• Qwen‑Image‑Edit‑2509 LoRA-Training mit AI Toolkit
• Wan 2.2 I2V 14B LoRA-Training mit AI Toolkit
• Wan 2.2 T2V 14B LoRA-Training mit AI Toolkit

Am Ende dieses Guides sollten Sie:

• die Kernideen hinter LoRA-Training verstehen (was beim Fine‑Tuning wirklich passiert),
• wissen, wie das AI Toolkit aufgebaut ist und wofür jedes Panel steht,
• verstehen, was zentrale Parameter (Learning Rate, Rank, Steps, Noise Schedule, DOP usw.) bewirken, damit Sie gezielt tunen können,
• LoRAs lokal oder mit dem RunComfy Cloud AI Toolkit trainieren und anschließend in Ihren normalen Generations-Workflows wiederverwenden können.

---

Inhaltsverzeichnis

• 1. Was ist das Ostris AI Toolkit? (LoRA-Trainer für Diffusionsmodelle)
• 2. Unterstützte Modelle im Ostris AI Toolkit (Flux, Wan, Z‑Image, Qwen‑Image, SDXL)
• 3. Ostris AI Toolkit lokal installieren und in RunComfy Cloud AI Toolkit nutzen
• 4. Überblick: Ostris AI Toolkit Web UI (Dashboard, Datasets, New LoRA Job)
• 5. LoRA-Training-Grundlagen und Kern-Hyperparameter für AI Toolkit
• 6. LoRA-Konzepte auf AI Toolkit-Parameter abbilden
• 7. Quick-Start: eine brauchbare LoRA in Ostris AI Toolkit trainieren
• 8. Troubleshooting AI Toolkit LoRA-Training: häufige Fehler und Fixes

1. Was ist das Ostris AI Toolkit? (LoRA-Trainer für Diffusionsmodelle)

Ostris AI Toolkit ist eine Trainings-Suite mit Fokus auf Diffusionsmodelle für Bilder und Video. Sprach- oder Audio-LLMs werden nicht unterstützt; alles, was das Toolkit trainiert, ist entweder ein klassisches DDPM‑artiges Diffusionsmodell (z. B. SD 1.5 oder SDXL) oder ein moderner Diffusion Transformer wie Flux, Wan, Qwen‑Image, Z‑Image oder OmniGen2. Das Toolkit ist um LoRA‑artige Adapter herum gebaut: In der Praxis trainieren Sie beim Fine‑Tuning nicht das komplette Netzwerk neu, sondern kleine LoRA‑ (oder ähnliche „lightweight“) Adapter auf einem eingefrorenen Basismodell.

Zentrale Features des Ostris AI Toolkit für LoRA-Training

AI Toolkit stellt eine gemeinsame Trainings-Engine und ein einheitliches Config-System für alle unterstützten Modellfamilien bereit. Jede Familie (Flux, Z‑Image Turbo, Wan 2.2, Qwen‑Image, SDXL usw.) hat eigene Presets, aber sie hängen alle an derselben Struktur: Modell-Loading, Quantisierung, LoRA/LoKr-Adapterdefinition, Trainings-Hyperparameter, Dataset-Handling und Sampling-Regeln. Deshalb wirkt die Web UI vertraut, egal ob Sie eine Flux‑LoRA, eine Z‑Image Turbo‑LoRA oder eine Wan‑Video‑LoRA trainieren.

Zusätzlich zur Engine bringt AI Toolkit sowohl eine CLI als auch eine vollständige Web UI mit. Die CLI startet Jobs direkt aus YAML‑Configs; die Web UI ist eine grafische Schicht über denselben Configs. In der UI meint „AI Toolkit“ meist den New Job‑Screen: Dort wählen Sie Modellfamilie, Adaptertyp und Rank, setzen Learning Rate und Steps, hängen ein oder mehrere Datasets an und definieren, wie oft Sample‑Bilder oder ‑Videos erzeugt werden. Es gibt dedizierte Panels für Job, Model, Quantization, Target, Training, Regularization, Datasets und Sample – in den meisten Fällen müssen Sie rohes YAML gar nicht anfassen. Egal ob lokal oder über eine Cloud‑Umgebung wie das RunComfy Cloud AI Toolkit: Der Workflow ist derselbe.

---

Integrierte LoRA-Trainingstools im Ostris AI Toolkit

AI Toolkit bringt eine Reihe „batteries‑included“ Features mit, die Sie sonst selbst skripten oder zusammenkleben müssten:

• Quantisierung und Low‑VRAM‑Modi – konfigurierbare 8‑/6‑/4‑Bit‑Quantisierung (und 3‑Bit mit Recovery Adapters) für Transformer plus Layer‑Offloading, damit große Modelle wie Flux oder Wan auf 24–48 GB GPUs trainierbar werden – mit kontrollierbaren Trade‑offs bei Qualität/Tempo.
• LoRA / LoKr‑Adapter – Unterstützung für Standard‑LoRA sowie LoKr (eine kompaktere, aber nicht überall unterstützte Variante), wählbar über Target Type, damit Sie zwischen maximaler Kompatibilität und kleineren, kapazitätsstarken Adaptern entscheiden können.
• Differential Output Preservation (DOP) – ein Regularisierungs-Loss, der Base‑Model vs. LoRA‑Output auf Regularization‑Bildern vergleicht und unerwünschte Änderungen bestraft. Das reduziert „LoRA‑Bleeding“ (wenn alles nach dem Trainingssubjekt aussieht).
• Differential Guidance für Turbo‑Modelle – ein optionaler Trainings‑Guidance‑Term (stark genutzt bei Z‑Image Turbo), der Updates auf „was sich ändern soll“ gegenüber dem Basismodell fokussiert. Das verbessert Anpassung bei Few‑Step/Turbo‑Modellen, ohne deren Speed‑Vorteile zu zerstören.
• Multi‑Stage Noise Training – getrennte High‑Noise- und Low‑Noise‑Phasen, um grobe Struktur (Komposition, Pose) und feine Details (Texturen, Kanten) auszubalancieren.
• Latent‑ und Text‑Embedding‑Caching – Cache Latents und Cache Text Embeddings tauschen Speicherplatz auf Disk gegen Speed und weniger VRAM. Das hilft besonders auf kleineren GPUs oder in Cloud‑Sessions, wenn Sie schnell iterieren wollen.
• EMA (Exponential Moving Average) – eine optionale geglättete Kopie der LoRA‑Weights, die Konvergenz stabilisieren kann, gerade bei kleinen Datasets.

Die Web UI macht diese Features über klare Controls zugänglich. Und weil das Layout modellübergreifend konsistent ist, können Sie das Verständnis von einer Modellfamilie (z. B. Flux) leicht auf Z‑Image Turbo, Wan, Qwen‑Image und andere Diffusionsmodelle übertragen.

---

2. Unterstützte Modelle im Ostris AI Toolkit (Flux, Wan, Z‑Image, Qwen‑Image, SDXL)

AI Toolkit unterstützt aktuell folgende Modellfamilien:

• IMAGE‑Modelle – Einzelbilder (Flux, Z‑Image Turbo, Qwen‑Image, SD usw.).
• INSTRUCTION / EDIT‑Modelle – Bildbearbeitung / Instruction‑Following (Qwen‑Image‑Edit, Flux Kontext, HiDream E1).
• VIDEO‑Modelle – Text‑to‑Video und Image‑to‑Video (Wan 2.x Serie).

---

2. Unterstützte Modelle im Ostris AI Toolkit (Flux, Wan, Z‑Image, Qwen‑Image, SDXL)

AI Toolkit unterstützt aktuell folgende Modellfamilien:

• IMAGE‑Modelle – Einzelbilder (Flux, Z‑Image Turbo, Qwen‑Image, SD usw.).
• INSTRUCTION / EDIT‑Modelle – Bildbearbeitung / Instruction‑Following (Qwen‑Image‑Edit, Flux Kontext, HiDream E1).
• VIDEO‑Modelle – Text‑to‑Video und Image‑to‑Video (Wan 2.x Serie).

---

3. Ostris AI Toolkit lokal installieren und in RunComfy Cloud AI Toolkit nutzen

3.1 Ostris AI Toolkit lokal unter Linux und Windows installieren

Die offizielle README auf GitHub enthält klare Installationsanweisungen für Linux und Windows.

Unter Linux:

git clone https://github.com/ostris/ai-toolkit.git
cd ai-toolkit

python3 -m venv venv
source venv/bin/activate

# PyTorch mit CUDA installieren (Version bei Bedarf anpassen)
pip3 install --no-cache-dir torch==2.7.0 torchvision==0.22.0 torchaudio==2.7.0 \
  --index-url https://download.pytorch.org/whl/cu126

pip3 install -r requirements.txt

Unter Windows können Sie entweder das gleiche Muster mit python -m venv venv und .\venv\Scripts\activate verwenden oder das Community‑Batch‑Script AI‑Toolkit Easy Install nutzen, das den gesamten Prozess in „einem Klick“ kapselt und die UI direkt im Browser öffnet (für die jeweils aktuelle Version).

So starten Sie die Web UI nach der Installation der Dependencies:

cd ui
npm run build_and_start

Die Oberfläche ist unter http://localhost:8675 erreichbar. Wenn Sie sie auf einer Remote‑Maschine betreiben, setzen Sie vorher AI_TOOLKIT_AUTH auf ein Passwort, damit nur Sie Zugriff haben (Security‑Hinweise stehen im AI Toolkit GitHub Repository).

---

3.2 RunComfy Cloud AI Toolkit für LoRA-Training nutzen (ohne lokale Installation)

Wenn Sie sich gar nicht mit GPU‑Treibern, CUDA oder lokalen Installationen beschäftigen möchten, können Sie das RunComfy Cloud AI Toolkit nutzen. In diesem Modus:

• AI Toolkit läuft vollständig in der Cloud – Sie öffnen einfach den Browser und sind in der UI.
• Sie erhalten Zugriff auf leistungsstarke GPUs (80 GB und 141 GB VRAM), ideal für schwere FLUX‑, Qwen‑Image‑, Z‑Image Turbo‑ oder Wan‑LoRA‑Trainings.
• Ihre Datasets, Configs, Checkpoints und bisherigen Jobs liegen in einem persistenten Workspace, der an Ihr RunComfy‑Konto gebunden ist.
• Training, Playground zum Modelltesten und ComfyUI‑Workflows sind an einem Ort vereint.

Direkt öffnen: Cloud AI Toolkit auf RunComfy

---

4. Überblick: Ostris AI Toolkit Web UI (Dashboard, Datasets, New LoRA Job)

Wenn Sie die Web UI öffnen (lokal oder auf RunComfy), sehen Sie links eine Sidebar mit wenigen, aber wichtigen Seiten:

4.1 Dashboard und Training Queue

Das Dashboard zeigt aktive und letzte Jobs auf einen Blick. Es ist vor allem eine schnelle Status‑Übersicht.

Die Seite Training Queue ist der Ort, an dem Sie:

• den Status jedes Jobs sehen (queued, running, finished, failed),
• Logs öffnen, um Probleme zu debuggen,
• Jobs stoppen oder löschen,
• Output‑Checkpoints und Sample‑Bilder herunterladen.

Denken Sie daran wie an das „Job‑Control‑Center“. Jede LoRA, die Sie trainieren, taucht hier auf.

---

4.2 Dataset-Manager

Auf der Seite Datasets definieren Sie benannte Datasets, die Sie später Jobs zuweisen:

• Sie wählen oder laden Bildordner bzw. Videoclips hoch.
• Die UI scannt sie und zeigt Auflösungen, Anzahl sowie wie viele Captions / Metadata‑Einträge existieren.
• Jedes Dataset bekommt einen internen Namen, der später im Dropdown Target Dataset des Jobs auftaucht.

Hier erstellen Sie:

• Haupt‑Trainingsdatasets (Charakter, Stil, Produktfotos),
• optional Regularization‑Datasets (andere Personen, andere Trucks, generische Hintergründe usw.) für DOP oder klassische Regularisierung.

---

4.3 New Job: der zentrale LoRA-Konfigurationsscreen

Die Seite New Job ist das Herz von AI Toolkit. Ein Job bedeutet im Kern:

Trainiere eine LoRA vom Typ X auf Modell Y, mit Dataset Z, mit diesen Hyperparametern.

Der Screen ist in Panels gegliedert:

• JOB – Naming und GPU‑Auswahl.
• MODEL – welches Basismodell fine‑getuned wird.
• QUANTIZATION – wie stark das Basismodell komprimiert wird.
• TARGET – LoRA vs. LoKr und Rank.
• SAVE – Checkpoint‑Präzision und Speicherfrequenz.
• TRAINING – Learning Rate, Steps, Optimizer, Timestep‑Schedule.
• ADVANCED / Regularization – EMA, Differential Guidance, DOP.
• DATASETS – welche Datasets trainiert werden (und wie).
• SAMPLE – wie oft während des Trainings Sample‑Bilder oder ‑Videos erzeugt werden.

Der Rest dieses Guides hilft vor allem dabei, diese Panels wieder auf die Kern‑LoRA‑Konzepte zurückzuführen.

---

5. LoRA-Training-Grundlagen und Kern-Hyperparameter für AI Toolkit

Bevor Sie irgendwelche Controls im AI Toolkit anfassen, hilft ein klares mentales Modell davon, was LoRA‑Training „unter der Haube“ macht.

5.1 Wie LoRA in Diffusionsmodellen funktioniert

Ein modernes Diffusionsmodell ist im Wesentlichen ein Stack aus Transformer‑Blöcken mit großen Weight‑Matrizen. Beim klassischen Fine‑Tuning würden Sie all diese Weights direkt updaten – teuer und leicht zu overfitten.

In allen unterstützten Modellen (z. B. Flux, Z‑Image Turbo, Wan, Qwen‑Image) ist das Backbone ein großer Diffusion Transformer. LoRA ersetzt die ursprüngliche Weight‑Matrix W nicht, sondern addiert ein kleines Low‑Rank‑Update aus zwei gelernten Matrizen A und B. Vereinfacht: W_new = W + alpha A B, wobei W eingefroren ist, A und B trainierbar sind, und alpha die Stärke des Updates zur Inference steuert.

Der rank bestimmt die Breite der Matrizen A und B und damit, wie komplex das LoRA‑Update sein kann. Höherer Rank macht die LoRA expressiver, aber auch schwerer (mehr Parameter/Compute). Niedriger Rank ergibt einen kleineren, fokussierteren Adapter, der leichter ist und meist schwerer overfittet.

---

5.2 Zentrale LoRA-Hyperparameter erklärt

Diese Begriffe tauchen in jedem Trainer auf; AI Toolkit macht sie nur übersichtlich bedienbar.

Learning Rate (Learning Rate)

• Steuert, wie groß ein Schritt im Parameterraum bei jedem Optimizer‑Update ist.
• Zu niedrig: Training ist langsam und passt Ihr Dataset ggf. nicht gut an.
• Zu hoch: Loss oszilliert oder explodiert; die LoRA wird noisy/instabil oder overfittet stark.

Für Diffusions‑LoRAs ist 0.0001 ein sehr solider Default. Viele veröffentlichte Wan‑ und Flux‑Configs liegen bei 0.0001 – 0.0002.

---

Batch Size und Gradient Accumulation

• Batch Size ist wie viele Bilder/Clips parallel für eine Gradientenberechnung verarbeitet werden.
• Gradient Accumulation bedeutet: „akkumuliere Gradienten für N Batches, bevor ein Update angewendet wird“ – das simuliert größere Batches ohne zusätzlichen VRAM.

Effektive Batchgröße: Batch Size × Gradient Accumulation

Eine höhere effektive Batchgröße ergibt glattere Gradienten und oft bessere Generalisierung, kostet aber Compute. Viele laufen auf 24 GB GPUs mit Batch Size = 1 und Gradient Accumulation = 2–4.

---

Steps (Steps)

Das ist die Anzahl der Optimizer‑Updates. Es ist der wichtigste Knopf für „wie lange trainieren wir“.

• Zu wenige Steps → Underfitting: die LoRA verändert das Basismodell kaum.
• Zu viele Steps → Overfitting: die LoRA memorisiert Trainingsbilder und „bleedet“ in alles hinein.

Die richtige Zahl hängt ab von: Dataset‑Größe, Varianz, Rank, Learning Rate.

Für typische 20–50‑Bild Charakter‑LoRAs auf modernen Modellen sind 2 000–3 000 Steps ein guter Startbereich.

---

Rank (Linear Rank)

• Rank bestimmt wie viele Freiheitsgrade Ihre LoRA hat.
• Eine Verdopplung des Ranks verdoppelt grob Kapazität und Parameterzahl.

Praktische Intuition:

• Rank 16–32 reicht für die meisten Charaktere/Stile auf großen Modellen wie Flux oder Wan.
• Höhere Ranks overfitten kleine Datasets schneller; niedrigere Ranks zwingen die LoRA zu mehr Generalisierung.

---

Weight Decay (Weight Decay)

Weight Decay ist ein klassischer Regularisierungstrick: Er zieht Weights bei jedem Step leicht Richtung Null.

• Er reduziert die Chance, dass die LoRA auf extreme Werte „einrastet“, die Trainingsbilder perfekt nachbauen, aber schlecht generalisieren.
• Werte wie 0.0001 sind gängig und meist sicher. Oft lohnt es sich erst zu ändern, wenn Sie klares Overfitting sehen.

---

Timestep‑Schedule

Diffusionsmodelle lernen Denoising über eine Bandbreite an Noise‑Levels. Sie wählen, welche Timesteps häufiger gesampelt werden:

• High Noise: Modell lernt grobe Struktur, Komposition, große Formen.
• Low Noise: Modell lernt feine Texturen und Details.
• Mid Noise: dort treffen Struktur und Details zusammen; gut für Gesichter/Charaktere.

Die Parameter Timestep Type und Timestep Bias im AI Toolkit sind UI‑Regler für diese Verteilung – das packen wir im Parameter‑Kapitel aus.

---

Dataset‑Komposition und Captions

Auch mit perfekten Hyperparametern liefert schlechte Datenbasis eine schlechte LoRA:

• Nutzen Sie saubere, vielfältige Bilder, die alle zum Konzept passen (gleiche Person, gleiche Marke, gleicher Stil), aber mit unterschiedlichen Posen, Licht und Hintergründen.
• Captions sollten ein eindeutiges Trigger‑Wort klar ans Konzept binden, damit Sie die LoRA später aktivieren können, ohne das Vokabular des Basismodells zu „verwirren“.

Bei Video‑LoRAs (Wan, HiDream E1) gilt die gleiche Logik, nur mit kurzen Clips statt Einzelbildern; Frame‑Sampling wird Teil des Dataset‑Designs.

---

6. LoRA-Konzepte auf AI Toolkit-Parameter abbilden

Jetzt gehen wir Panel für Panel durch den New Job‑Screen und verknüpfen jeden Parameter mit den Konzepten von oben.

6.1 JOB‑Panel: Projekt, GPU und Trigger‑Word

Das JOB‑Panel ist simpel, aber wichtig:

Training Name – der Job‑Name; er landet in Output‑Ordner‑ und Dateinamen. Viele nutzen Modell + Trigger, z. B. flux_dev_skschar_v1.

GPU ID – bei lokaler Installation wählen Sie damit Ihre physische GPU. Im Cloud AI Toolkit auf RunComfy lassen Sie das auf Default; der echte GPU‑Typ (H100/H200 usw.) wird später beim Starten aus der Training Queue gewählt.

Trigger Word – wenn Sie hier ein Wort setzen, wird es im AI Toolkit zur Trainingszeit allen Captions vorangestellt (ohne Ihre Dateien dauerhaft zu verändern). Praktisch, wenn Captions keinen konsistenten Trigger enthalten. Nutzen Sie ein Nonsense‑Token, das das Basismodell nicht schon kennt (z. B. sks_char_neo), damit die LoRA nicht mit bestehenden Bedeutungen konkurriert.

---

6.2 MODEL‑Panel: Basismodell auswählen und laden

Model Architecture – hier wählen Sie aus der Modellliste (Flux, Z‑Image Turbo, Wan 2.2, Qwen‑Image usw.). Wenn Sie eines wählen:

• lädt AI Toolkit ein Preset, das auf dieses Modell zugeschnitten ist (Sampler‑Typ, Noise‑Schedule‑Defaults, teils Adapter‑Paths).

Name or Path – die Hugging Face Model‑ID (Repo‑ID) des Base‑Checkpoints.

• In den meisten Builds füllt die Wahl der Model Architecture die empfohlene HF‑ID automatisch aus – lassen Sie sie so, außer Sie haben einen Grund.
• Wenn Sie sie überschreiben, nutzen Sie das Format org-oder-user/model-name (optional org-oder-user/model-name@revision).

Wenn das Modell „gated“ ist (Flux.1‑dev, Flux.2‑dev, manche Wan‑Varianten usw.), müssen Sie die Lizenz akzeptieren und HF_TOKEN in einer .env setzen, damit AI Toolkit es herunterladen kann.

Je nach Modell sehen Sie zusätzliche Flags wie Low VRAM oder Layer Offloading hier oder in angrenzenden Panels:

• Low VRAM komprimiert/offloadet Teile des Modells, damit es auf kleinere GPUs passt – auf Kosten von Speed.
• Layer Offloading schiebt Teile aggressiver zwischen CPU und GPU hin und her; nur nutzen, wenn Low VRAM nicht reicht, da es langsamer und gelegentlich weniger stabil sein kann.

Diese Switches ändern nicht, was die LoRA lernt – nur wie AI Toolkit das Basismodell im Speicher unterbringt, also den Trade‑off zwischen Speed/Stabilität und „passt auf die GPU“.

---

6.3 QUANTIZATION‑Panel: Präzision vs. VRAM

Im QUANTIZATION‑Panel sehen Sie meist:

• Transformer (z. B. float8, 6-bit, 4-bit, 3-bit ARA),
• Text Encoder (typisch float8 (default)).

Bedeutung:

• Der Transformer ist der große, schwere Teil, der Image‑Latents verarbeitet und Cross‑Attention mit Text macht.
• Der Text Encoder wandelt Prompts in Token‑Embeddings um.

Transformer‑Quantisierung:

• float8 ist am sichersten und am präzisesten; mehr VRAM, kaum Qualitätsverlust.
• 6-bit ist ein starker Kompromiss für 24 GB GPUs; kleiner Quality‑Hit, ordentliche Einsparung.
• 4-bit und 3-bit ARA sind aggressiver; 3-bit ARA kombiniert 3‑Bit‑Weights mit einem Accuracy Recovery Adapter, der einen Teil der Präzision zurückholt.

Text‑Encoder‑Quantisierung:

• Text Encoder sind deutlich kleiner und bleiben daher meist float8.
• Manche Setups freezen/unloaden den Text Encoder (siehe Unload TE und Cache Text Embeddings später); dann ist seine Quantisierung weniger relevant.

Praktisch:

• Auf einer 24 GB GPU für Flux/Wan ist Transformer = 6-bit, Text Encoder = float8 ein sehr guter Startpunkt.
• Mit 48 GB+ können Sie oft überall float8 lassen, außer Sie brauchen Speicher für sehr hohe Auflösungen oder viele Frames.

---

6.4 TARGET‑Panel: LoRA‑Typ und Rank

Das TARGET‑Panel beschreibt den Adapter, den Sie trainieren:

• Target Type – meist LoRA. Einige Builds zeigen auch LoKr (Low‑Rank Kronecker), eine etwas andere, parameter‑effiziente Variante, die aber nicht überall unterstützt wird. Für maximale Kompatibilität (z. B. in vielen ComfyUI/A1111‑Setups) ist LoRA der sichere Default.
• Linear Rank – der LoRA‑Rank wie oben: höherer Rank = mehr Kapazität, größere Datei, mehr VRAM, höheres Overfitting‑Risiko bei kleinen Datasets. Intuition für moderne Diffusion Transformer (Flux, Z‑Image Turbo, Wan 2.x, Qwen‑Image, OmniGen2, Chroma, Lumina2 usw.):
• 8–16: kompakt und generalisiert gut. Ein guter Startbereich für starke Bases wie Z‑Image Turbo sowie viele SDXL/SD 1.5‑Setups, besonders bei kleinen Datasets (5–40 Bilder oder wenige kurze Clips).
• 16–32: typischer Bereich für Style/Character‑LoRAs auf großen Backbones wie Flux, Wan 2.x, Qwen. In der Praxis startet man meist bei 16 und geht nur auf 32, wenn man genug Daten hat und die LoRA noch zu schwach ist.
• 64+: selten nötig. Nur erwägen, wenn Sie ein großes, diverses Dataset haben, bewusst einen starken Domain‑Shift wollen und genug VRAM vorhanden ist.

Bei SD 1.5 / SDXL sehen Sie ggf. auch Conv Rank (Convolution Rank), der mehr Textur/Stil‑Layer adressiert. Höherer Conv Rank betont eher wie gerendert wird (Pinselstriche, Noise‑Pattern), Linear Rank eher was im Bild ist.

---

6.5 SAVE‑Panel: Checkpoint‑Präzision und Speicherfrequenz

SAVE steuert, wie Ihre LoRA‑Checkpoints geschrieben werden:

• Data Type
• BF16 (bfloat16) ist ein sehr guter Default: stabil und effizient.
• FP16 ist minimal präziser, in der Praxis meist ohne sichtbaren Unterschied.
• FP32 ist sehr präzise, aber sehr schwer; nur nutzen, wenn Sie es wirklich brauchen.
• Save Every

  Steps zwischen Checkpoints. Wenn Save Every = 250 und Steps = 3000, erhalten Sie potenziell 12 Checkpoints (siehe nächstes Feld). Meist sollte Save Every zu Sample Every im SAMPLE‑Panel passen, damit jeder Checkpoint passende Previews hat.

• Max Step Saves to Keep

  Wie viele Checkpoints auf Disk behalten werden. Bei 4 bleiben nur die 4 neuesten; ältere werden gelöscht, um Speicher zu sparen.

---

6.6 TRAINING‑Panel: Optimizer, Steps und Noise‑Schedule

Batch Size und Gradient Accumulation

Wie oben:

• Batch Size = Bilder/Clips pro Forward Pass.
• Gradient Accumulation = wie viele solcher Passes bis zu einem Optimizer‑Update.

Wenn VRAM knapp ist:

• Batch Size = 1, Gradient Accumulation = 4 → verhält sich wie Batch 4, braucht aber viermal so viele Passes.

Stellen Sie sicher, dass die effektive Batchgröße nicht größer als Ihr Dataset ist; Sie wollen keine 16 Bilder pro Step simulieren, wenn Sie nur 10 Gesamtbilder haben.

---

Steps

Das sind Optimizer‑Steps, nicht „Epochs“.

• 2000–3000 Steps sind für viele Flux/Qwen/Z‑Image Turbo/OmniGen2/Chroma‑LoRAs (und viele Wan 2.x‑LoRAs) ein üblicher Baseline‑Bereich bei 20–50 Bildern oder kleinen Clips.

Oft ist es besser, etwas kürzer zu trainieren und einen guten Mid‑Run‑Checkpoint zu behalten, als absurd hohe Stepzahlen zu fahren und zu hoffen, dass der letzte der beste ist.

---

Optimizer (Optimizer)

Typisch:

• AdamW8Bit – AdamW mit 8‑Bit Optimizer‑States. Spart Speicher und funktioniert sehr gut auf kleinen bis mittleren Datasets.
• Adafactor – noch speichereffizienter, skaliert auf sehr große Datasets, kann aber schwerer zu tunen sein.

Für die meisten LoRAs im AI Toolkit ist AdamW8Bit die richtige Wahl, außer Sie laufen in Optimizer‑State‑OOMs.

---

Learning Rate

Ein guter Default ist 0.0001. Wenn:

• die LoRA kaum lernt, probieren Sie 0.00015–0.0002,
• Sie schnelles Overfitting oder noisy Samples sehen, probieren Sie 0.00005–0.00008.

Vermeiden Sie große Sprünge auf Raten wie 0.0005, außer ein modell­spezifischer Guide empfiehlt es (z. B. experimentelle Turbo‑Configs).

---

Weight Decay

Wie oben: 0.0001 ist eine gute „sanfte Regularisierung“. Wenn Ihre LoRA selbst bei moderaten Steps klar Trainingsbilder memorisiert, ist leicht höherer Weight Decay ein Werkzeug.

---

Timestep Type und Timestep Bias

Diese beiden Parameter formen, welche Diffusion‑Timesteps Ihre Batches bevorzugen.

• Timestep Type kann sein:
• Linear – Timesteps gleichmäßig über die ganze Noise‑Range.
• Sigmoid – konzentriert Mid‑Range‑Timesteps (gut für Gesichter/Charaktere).
• Weighted oder andere Presets – modell­spezifische Schedules.
• Timestep Bias kann sein:
• Balanced – keine Zusatz‑Bias; folgt der Verteilung aus Timestep Type.
• High Noise – Bias Richtung frühe Timesteps (sehr noisy Latents); betont globale Struktur/Komposition.
• Low Noise – Bias Richtung späte Timesteps (fast clean); betont feine Texturen.

Für Character‑LoRAs auf FlowMatch‑Modellen ist Weighted + Balanced ein sehr solider Startpunkt: Die LoRA lernt das Konzept dort, wo das Modell „halb“ denoised, was oft gut zur Inference‑Wahrnehmung passt.

---

Sampler / Noise Type im Training

Bei älteren SD‑Modellen nutzt AI Toolkit DDPM‑Sampler; bei FlowMatch‑Modellen wie Flux, Z‑Image Turbo, Wan 2.x standardmäßig FlowMatch. Normalerweise müssen Sie das nicht ändern – das Preset setzt Timestep Type und Sampler intern passend.

---

EMA (Exponential Moving Average)

• Use EMA schaltet ein, ob AI Toolkit eine geglättete Kopie der LoRA‑Weights führt.
• Wenn aktiv, steuert EMA Decay (z. B. 0.99), wie schnell die EMA alte Updates „vergisst“:
• 0.9 = reagiert schnell, weniger smooth.
• 0.99 = smoother.
• 0.999+ = sehr smooth, aber passt sich langsam an.

EMA kann Stabilität auf kleinen Datasets erhöhen, kostet aber zusätzlichen Speicher. Bei knapper VRAM‑Lage ist es ok, Use EMA auszulassen, außer ein spezieller Guide empfiehlt es.

---

Text‑Encoder‑Optimierungen

• Unload TE – entlädt den Text Encoder zwischen Steps aus dem VRAM. Spart Speicher, kann aber durch häufiges Reloading langsam sein (besonders auf HDDs).
• Cache Text Embeddings – lässt den Text Encoder einmal pro Caption laufen und speichert die Embeddings; spätere Steps reuse‑en sie. Tauscht Disk‑Platz gegen Speed/VRAM.

Für die meisten Workflows:

• Wenn VRAM reicht: beide auslassen.
• Wenn VRAM knapp ist, Sie aber eine schnelle SSD haben und Ihre Captions effektiv statisch sind (kein DOP, kein on‑the‑fly Trigger‑Rewriting, keine starke Caption‑Dropout‑Logik, die von per‑Step‑Textänderungen abhängt): Cache Text Embeddings einschalten, damit AI Toolkit jede Caption einmal encodiert und den Text Encoder entlastet.
• Wenn Sie Features nutzen, die Prompts pro Step verändern – z. B. Differential Output Preservation (DOP), dynamische Trigger‑Substitution in Captions oder Setups, die auf per‑Step Caption‑Dropout‑Verhalten setzen – lassen Sie Cache Text Embeddings aus, damit der Text Encoder den echten Prompt pro Batch neu encodieren kann.
• Unload TE nur nutzen, wenn es absolut nötig ist (z. B. sehr enge Trigger‑only LoRAs, bei denen Captions ignoriert werden), da es caption‑basiertes Training praktisch deaktiviert.

---

6.7 ADVANCED / Regularization‑Panel: DOP und Differential Guidance

Differential Output Preservation (Differential Output Preservation)

Wenn Sie das aktivieren, bittet AI Toolkit im Kern um Folgendes:

1. Das Basismodell und das LoRA‑augmentierte Modell auf einem Set an „Regularization“‑Bildern laufen lassen.
2. Einen Loss‑Term hinzufügen, der die LoRA dafür bestraft, Outputs zu verändern, die unverändert bleiben sollten.

Controls:

• DOP Loss Multiplier – Stärke des Preservation‑Loss; 0.1–1.0 ist typisch. 1.0 bedeutet „nimm Preservation sehr ernst“.
• DOP Preservation Class – Textlabel für das, was geschützt werden soll, z. B. "person" oder "truck". Das hilft dem Text Encoder beim Verständnis der Regularization‑Captions.

Für effektives DOP brauchen Sie:

• mindestens ein Dataset mit Is Regularization im DATASETS‑Panel,
• Captions für diese Bilder ohne Ihr LoRA‑Trigger‑Word (generische Beispiele).

Gute Szenarien für DOP:

• Ihre Character‑LoRA macht jede Person zu Ihrem Subjekt.
• Ihre Product‑LoRA verwandelt alle Logos in Ihre Marke, selbst ohne Trigger‑Word.

Blank Prompt Preservation ist eine Variante, bei der Regularization mit leeren Prompts läuft, um die LoRA zu ermutigen, grundlegendes „unprompted“ Verhalten nicht zu stören.

---

Do Differential Guidance (Do Differential Guidance)

Primär für Z‑Image Turbo‑LoRAs:

• AI Toolkit vergleicht Base‑ und adaptierte Outputs und nutzt ein Differenz‑Signal, um zu schärfen, was die LoRA ändern soll.
• Differential Guidance Scale steuert, wie stark diese Differenz die Trainings‑Updates beeinflusst; der Hugging Face Z‑Image Turbo LoRA Guide zeigt Beispielwerte, die in der Praxis gut funktionieren.

Differential Guidance zu aktivieren:

• hilft Z‑Image Turbo‑LoRAs, trotz Few‑Step Distillation tief zu adaptieren,
• funktioniert am besten zusammen mit cached text embeddings und sorgfältig getunten Learning Rates und Steps.

Für Nicht‑Turbo‑Modelle (Flux, Qwen, SDXL) lassen Sie Do Differential Guidance normalerweise aus, außer ein modell­spezifischer Tutorial empfiehlt es explizit.

---

6.8 DATASETS‑Panel: worauf Sie wirklich trainieren

Jeder Dataset‑Block im DATASETS‑Panel referenziert ein Dataset aus der Datasets‑Seite.

Wichtige Felder:

• Target Dataset – welches Dataset dieser Block meint.
• LoRA Weight – relative Wichtigkeit dieses Datasets gegenüber anderen im selben Job.
• Default Caption – Fallback‑Caption, wenn ein Bild keine Caption‑Datei hat.
• Caption Dropout Rate
• Num Frames (für Video‑Modelle)
• Cache Latents
• Is Regularization
• Flip X, Flip Y
• Resolutions (256–1536 Buckets)

Was das in der Praxis bedeutet:

• Kombinieren von Datasets mit LoRA Weight

  Wenn Sie mehrere Datasets haben (z. B. „Close‑ups“ und „Full‑body“), können Sie sie über LoRA Weight balancieren. Gewicht 2 wird ungefähr doppelt so oft gesampelt wie Gewicht 1.

• Default Caption und Caption Dropout Rate
• Default Caption ist praktisch, wenn Sie einige Bilder nicht captioned haben und trotzdem eine minimale Beschreibung (inkl. Trigger) wollen.
• Caption Dropout Rate entfernt/blankt Captions zufällig bei einem Teil der Beispiele:
• nahe 0 → LoRA lernt eine starke Abhängigkeit von der Caption.
• nahe 1 → LoRA verhält sich eher wie ein „Style always on“‑Modifier.
• Is Regularization

  Aktivieren, wenn das Dataset für DOP/Regularization gedacht ist, nicht als Haupttraining. Diese Bilder sollten nicht Ihren Trigger enthalten und typischerweise generische Beispiele abdecken (andere Personen/Trucks usw.).

• Cache Latents

  Wenn aktiv, berechnet AI Toolkit Latent‑Encodings vor und speichert sie. Spätere Steps müssen nicht jedes Bild neu encoden: Training wird schneller, aber Disk‑Usage steigt stark. Latents müssen Sie ggf. manuell aufräumen, wenn sie nicht dauerhaft bleiben sollen.

• Num Frames (nur Video)

  Für Wan/HiDream‑LoRAs: wie viele Frames aus jedem Clip pro Trainingssample gezogen werden. Mehr Frames → besseres Motion‑Learning, aber mehr VRAM; Presets wählen meist sinnvolle Defaults.

• Flip X und Flip Y

  Data‑Augmentation:

• Flip X (horizontal) verdoppelt effektiv das Dataset, spiegelt aber alles – inkl. asymmetrischer Features und Text.
• Flip Y (vertikal) ergibt selten Sinn für realistische Bilder.
• Resolutions

  Diese Buckets definieren, in welche Bildgrößen AI Toolkit Ihre Daten „bucketed“. Es shrinked nur auf den nächstpassenden Bucket, es upscalet nie. Wenn Sie z. B. 768 und 1024 aktivieren:

• 900×900 → wird auf 768×768 verkleinert.
• 1200×1200 → wird auf 1024×1024 verkleinert.

---

6.9 SAMPLE‑Panel: in Echtzeit sehen, wie die LoRA lernt

Das SAMPLE‑Panel definiert, wie AI Toolkit während des Trainings Preview‑Bilder oder ‑Videos erzeugt.

Top‑Level‑Felder:

• Sample Every – Steps zwischen Previews.
• Sampler – FlowMatch oder DDPM, je nach Modell.
• Width / Height – Preview‑Auflösung.
• Seed und Walk Seed.
• Guidance Scale.
• Num Frames und FPS (für Video‑Previews).
• Sample Steps.
• Advanced Toggles: Skip First Sample, Force First Sample, Disable Sampling.

Darunter können Sie mehrere Sample Prompts hinzufügen, jeweils mit Prompt‑Text, optional pro Prompt eigener Auflösung/Seed, LoRA Scale und optional einem Control‑Image.

Wie das ins Training zurückspielt:

• Sample Every vs Save Every: Idealerweise matchen beide, damit jeder gespeicherte Checkpoint passende Previews hat. Wenn Sie eins ändern, ändern Sie das andere mit.
• Sampler: Beim empfohlenen Sampler bleiben:
• FlowMatch für Flux, Z‑Image Turbo, Wan, OmniGen2 usw.
• DDPM für SD 1.5 / SDXL.
• Preview‑Auflösung und Steps
• 1024×1024 mit Sample Steps = 20–25 liefert klare Previews, ohne für die meisten Image‑Modelle zu langsam zu sein.
• Für Video sind höhere Num Frames/FPS realistischere Previews, aber schwer; Presets sind meist pro Modell getunt.
• Seeds und Walk Seed
• Fixer Seed mit Walk Seed aus bedeutet: jede Probe nutzt exakt dasselbe Rauschen, sodass Sie Checkpoints direkt vergleichen können.
• Walk Seed inkrementiert Seeds pro Prompt und gibt mehr Varianz. Schön zum Browsen, aber weniger „apples‑to‑apples“.

In der Praxis:

• Sample Every = Save Every = 250,
• 3–6 Sample‑Prompts für typische Use‑Cases,
• mindestens ein Prompt mit fixem Seed, um Konvergenz visuell über Steps zu tracken.

---

7. Quick-Start: eine brauchbare LoRA in Ostris AI Toolkit trainieren

Dieser Abschnitt ist absichtlich kompakt. Sie kennen die Bedeutung der Settings aus Abschnitt 5–6 – hier ist der kürzeste Workflow, der zuverlässig eine gute LoRA in Ostris AI Toolkit liefert, ohne jedes Panel neu zu erfinden.

7.1 Daten vorbereiten (den Teil kann man nicht „mit Settings reparieren“)

• Starten Sie mit einem kleinen, sauberen Dataset (Image‑LoRAs: ~20–50 starke Bilder; Video‑LoRAs: ein paar kurze, hochwertige Clips).
• Wählen Sie ein eindeutiges Trigger‑Token (Nonsense‑Wort) und halten Sie es konsistent in Captions – oder nutzen Sie die Job‑Trigger‑Injection.
• Ziel ist Varianz, nicht Masse: verschiedene Winkel, Licht, Hintergründe und Kompositionen, während das Kernkonzept gleich bleibt.

Optional (nur wenn Sie „Bleeding“ erwarten):

• Bereiten Sie ein Regularization‑Dataset vor (gleiche Klasse, andere Identitäten/Objekte) ohne Trigger‑Token – Sie nutzen es nur, wenn Sie später DOP aktivieren.

---

7.2 Dataset in Ostris AI Toolkit anlegen

In der Ostris AI Toolkit UI:

1. Gehen Sie zu Datasets → New Dataset.
2. Laden Sie Ihre Bilder/Clips + Captions (oder Metadata) hoch.
3. Schneller Sanity‑Check vor dem Training:
• die Anzahl stimmt,
• Captions werden erkannt (oder Sie nutzen bewusst Default Caption / Trigger‑Injection),
• Auflösungen wirken plausibel für Ihre Buckets.

---

7.3 Neuen Job erstellen: mit Presets starten, dann nur 5 Dinge ändern

Öffnen Sie New Job und wählen Sie die passende Modellfamilie (oder folgen Sie dem modell­spezifischen Rezept, wenn Sie FLUX.2, Z‑Image Turbo, Qwen‑Image‑Edit oder Wan‑Video trainieren).

Fokussieren Sie sich jetzt auf nur diese „high impact“ Controls:

1) Trigger‑Verhalten

• Wenn Ihre Captions den Trigger schon enthalten: Job‑Trigger leer lassen.
• Wenn nicht: Trigger Word setzen, damit er automatisch vorangestellt wird.

2) LoRA‑Kapazität

• Starten Sie mit Rank 16 für die meisten Charakter/Stil‑Konzepte.
• Gehen Sie auf Rank 32 nur, wenn die LoRA nach einem vernünftigen Run noch zu schwach ist (oder Sie ein größeres/diverseres Dataset haben).

3) Trainingsdauer

• Starten Sie mit 2 000–3 000 Steps für eine typische 20–50‑Bild‑LoRA.

  (Sie wollen den besten Checkpoint finden, nicht „max Steps fertig machen“.)

4) Learning Rate

• Nutzen Sie einen konservativen Default wie 0.0001, außer ein Modell‑Guide sagt etwas anderes.

5) Resolution‑Buckets (und VRAM‑Realität)

• Wählen Sie einen „comfort“ Bucket, den Ihre GPU zuverlässig schafft (typisch: 768 oder 1024 für moderne Image‑Modelle).
• Höhere Buckets erst hinzufügen, wenn Sie VRAM‑Headroom haben und sicher sind, dass Sie sie brauchen.

Zwei kleine Setup‑Gewohnheiten, die Stunden sparen:

• Save Every = Sample Every (z. B. alle 250 Steps), damit jeder Checkpoint passende Previews hat.
• Mindestens ein Fixed‑Seed Sample‑Prompt, um Checkpoints sauber zu vergleichen.

---

7.4 Sampling, das wirklich hilft, den richtigen Checkpoint zu wählen

Statt vieler Prompts reichen drei – sie diagnostizieren 90 % der Probleme:

• Activation‑Prompt (mit Trigger): beweist, dass die LoRA „anspringt“.
• Generalization‑Prompt (mit Trigger, andere Attribute): prüft Flexibilität jenseits der Trainingscaptions.
• Leak‑Test (ohne Trigger): prüft, ob die LoRA das Basismodell kapert.

Wenn der Leak‑Test Richtung Ihres Konzepts driftet, sind Sie über den Sweet Spot hinaus – wählen Sie einen früheren Checkpoint.

---

7.5 Schnelle Diagnose: einen Knopf ändern, nicht zehn

Wenn Ergebnisse nicht passen, ändern Sie immer nur eines davon:

• Zu schwach / aktiviert kaum → erst Steps erhöhen, dann ggf. Rank.
• Zu stark / overfittet / leakt ohne Trigger → zuerst einen früheren Checkpoint wählen, dann Steps (oder Rank) reduzieren.

  Wenn es weiter „bleedet“: DOP aktivieren – aber nur mit einem sauberen Regularization‑Dataset.

• OOM / instabiler VRAM → zuerst Bucket/Auflösung runter, dann Rank reduzieren; erst danach stärkere Memory‑Spar‑Optionen nutzen.

---

7.6 LoRA exportieren und nutzen

Aus der Training Queue oder aus Ihrem AI‑Toolkit‑Output‑Ordner:

• Laden Sie den besten Checkpoint herunter (eine .safetensors LoRA‑Datei).
• Wenn Sie das RunComfy Cloud AI Toolkit nutzen, werden die LoRA‑Dateien auch auf Ihrer Custom Models Seite gespeichert. Dort können Sie den Model‑Link kopieren, Dateien herunterladen und sie im Playground oder in ComfyUI testen.

---

8. Troubleshooting AI Toolkit LoRA-Training: häufige Fehler und Fixes

Dataset nicht gefunden oder leer

Symptome:

• Job beendet sofort.
• Logs erwähnen „no images found“ oder ähnlich.

Checks:

• In Datasets prüfen, ob die erwartete Bildanzahl angezeigt wird.
• Sicherstellen, dass Target Dataset im Job das richtige Dataset referenziert.
• Wenn JSONL‑Metadata verwendet wird: prüfen, ob die Datei vorhanden und korrekt formatiert ist.

---

Basismodell‑Download / Hugging‑Face‑Fehler

Symptome:

• 403/404 beim Model‑Download.
• Logs melden fehlenden Zugriff.

Fixes:

• Lizenz auf Hugging Face akzeptieren, wenn das Modell gated ist (Flux dev, manche Wan‑Varianten).
• HF_TOKEN=your_read_token in einer .env im AI Toolkit Root setzen.

---

CUDA Out‑of‑Memory beim Training oder Sampling

Symptome:

• „CUDA out of memory“ beim Job‑Start oder beim Generieren von Samples.

Optionen:

• In DATASETS:
• Hohe Auflösungen (1280, 1536) deaktivieren und bei 768/1024 bleiben.
• In TARGET:
• Linear Rank reduzieren (32 → 16).
• In QUANTIZATION / MODEL:
• Low VRAM aktivieren.
• aggressiver quantisieren (float8 → 6‑bit).
• In TRAINING:
• Batch Size oder Gradient Accumulation reduzieren.
• In SAMPLE:
• Preview‑Auflösung und Sample Steps reduzieren,
• Num Frames für Video‑Previews reduzieren.

Wenn Sie im RunComfy Cloud AI Toolkit trainieren, ist der einfachste Ausweg oft: Job auf eine GPU‑Stufe mit mehr VRAM hochsetzen und neu starten – dabei häufig aggressive Quantisierung / Low‑VRAM‑Hacks zurückdrehen und eine simplere, schnellere Config nutzen. Mit mehr VRAM und weniger Tricks läuft jeder Step schneller, und Sie iterieren durch mehr Checkpoints, statt Zeit mit VRAM‑Mikromanagement zu verlieren.

---

LoRA overfittet und „kapert“ das Basismodell

Symptome:

• Jede Person sieht wie Ihr Subjekt aus.
• Alle Trucks sehen wie Ihr spezifisches Produkt aus, selbst ohne Trigger‑Word.

Mitigations:

• Linear Rank senken.
• Einen früheren Checkpoint nutzen (z. B. 2000 statt 3000 Steps).
• Weight Decay leicht erhöhen.
• Regularization‑Dataset hinzufügen (Is Regularization = on).
• Differential Output Preservation aktivieren mit einem sinnvollen DOP Loss Multiplier (z. B. 0.2–0.5) und passender DOP Preservation Class ("person", "truck" usw.).