Was ist ein Modell

Im Kern steht das neuronale Netz aus dem letzten Artikel: mit allen Gewichten, die während des Trainings aus Milliarden Bild-Text-Paaren entstanden sind. Es übernimmt die eigentliche Arbeit — das schrittweise Entrauschen. Wenn jemand von "SDXL", "Flux.1 dev" oder "Flux.1 Krea dev" spricht, meint er meistens dieses Netz.

Allein erzeugt es aber noch kein Bild. Es braucht zwei Helfer: einen Text-Encoder, der den Prompt in Vektoren übersetzt, und einen VAE, der das Ergebnis aus dem Latent Space in Pixel zurückrechnet. Wie diese drei Teile auf deine Festplatte kommen, hängt von der Modellfamilie ab.

Bei SDXL ist alles in einer Datei gebündelt: Diffusionsmodell, Text-Encoder und VAE stecken zusammen in einem Checkpoint von rund 6–7 GB. Du lädst eine Datei, und das Modell ist arbeitsfähig. In ComfyUI liegt sie im Ordner models/checkpoints/ und wird über den Node "Load Checkpoint" geladen. Das gilt für die ganze ältere Stable-Diffusion-Linie — SD 1.5 und SDXL samt aller darauf aufbauenden Modelle. Neuere Modellfamilien wie Flux oder Qwen-Image werden dagegen meist in Einzeldateien geliefert.

Der Name stammt aus dem Trainingsprozess selbst: Während ein Modell trainiert wird, speichert man regelmäßig Zwischenstände — Checkpoints —, um den Fortschritt zu sichern oder verschiedene Trainingsstadien später vergleichen zu können. Einer dieser Zwischenstände wird am Ende als das fertige, veröffentlichte Modell herausgegeben. Der Begriff hat sich als gängige Bezeichnung für "die Modelldatei" gehalten — genau genommen aber nur dort, wo alles in einer Datei steckt.

Bei Flux.1 werden die Teile einzeln geliefert: das Diffusionsmodell (rund 24 GB in voller Präzision), zwei Text-Encoder und der VAE. Das Diffusionsmodell ist deshalb kein Checkpoint. Es liegt in models/unet/ und wird über "Load Diffusion Model" geladen — nicht über "Load Checkpoint". Eine Flux-Datei im Checkpoint-Ordner findet der richtige Loader nicht.

Es gibt zwar auch Flux-Komplettpakete im Checkpoint-Format, sie sind aber die Ausnahme. RAY-L arbeitet mit den Einzeldateien — im Panel heißt das Feld deshalb "Diffusion (UNet)" und nicht "Checkpoint".

Flux.1 Krea dev ist das Geschwister von Flux.1 dev: Beide stammen aus derselben Rohbasis und unterscheiden sich nur im Post-Training — Krea wurde auf eine natürlichere, fotografischere Bildsprache trainiert. Krea ersetzt nur das Diffusionsmodell — Text-Encoder, VAE und ControlNet bleiben dieselben wie bei dev. Für RAY-L ist Krea das empfohlene Modell; wie sich die beiden unterscheiden, steht im nächsten Artikel und ausführlich in 2.3.3 — Flux.1 Krea dev.

Der Text-Encoder übersetzt den Prompt in die Vektoren, mit denen das Diffusionsmodell arbeitet. Bei SDXL steckt er im Checkpoint — du siehst ihn nie als eigene Datei.

Bei Flux.1 sind es zwei: CLIP-L (rund 250 MB), der vor allem kurze Stichworte erfasst, und T5XXL, der ganze Sätze versteht. Beide liegen in models/clip/ (in neueren ComfyUI-Versionen auch text_encoders/). T5XXL ist für sich schon ein großes Netz: rund 10 GB in fp16, gut 5 GB als fp8_scaled, als GGUF noch kleiner.

Text-Encoder gehören zur Architektur. Flux.1 dev und Krea teilen sich dieselben; die SDXL-Encoder passen nicht zu Flux und umgekehrt.

Dasselbe Diffusionsmodell gibt es oft in mehreren Fassungen, die sich nur darin unterscheiden, wie genau die Gewichte gespeichert sind. fp16 ist die volle Fassung, fp8 halbiert die Größe. Noch kleiner werden GGUF-Dateien: Quantisierungen in Stufen wie Q8, Q6, Q4 oder Q3. Je kleiner die Zahl, desto kleiner die Datei — und desto stärker weicht das Ergebnis vom Original ab.

Für Apple Silicon wichtig: fp8 läuft dort nicht. Auf dem Mac heißt die Wahl deshalb fp16 oder GGUF. GGUF-Dateien liegen ebenfalls in models/unet/, brauchen in ComfyUI aber einen eigenen Loader aus dem Custom Node ComfyUI-GGUF. RAY-L steuert sie ab v0.9.1 an. Formate und Loader im Detail stehen in 2.3.2 — Flux.1 dev; welche Stufe auf welcher Maschine wie schnell läuft, zeigt die Zeitmatrix in 2.3.3 — Flux.1 Krea dev.

Ein fertiges Diffusionsmodell kann sehr viel — aber nicht alles gleich gut. Wenn du einen bestimmten Bildstil, ein wiederkehrendes Gesicht oder ein bestimmtes Produktdesign verlässlich erzeugen willst, müsste man dem Modell diese spezielle Disziplin eigentlich beibringen. Das komplette Modell dafür neu zu trainieren wäre unverhältnismäßig — es würde enorme Rechenleistung und riesige Datenmengen brauchen, nur um eine einzelne, enge Fähigkeit zu schärfen.

Genau dieses Problem löst ein LoRA (Low-Rank Adaptation). Ein LoRA ist kein eigenständiges Modell, sondern ein kleines, nachtrainiertes Zusatzpaket, das auf ein bestehendes Diffusionsmodell aufgesetzt wird. Statt alle Milliarden Gewichte neu zu lernen, werden beim LoRA-Training nur sehr viel kleinere Zusatzgewichte berechnet, die das vorhandene Wissen gezielt in eine bestimmte Richtung verschieben. Technisch bedeutet das: Anstatt eine riesige Gewichtsmatrix komplett zu verändern, werden zwei sehr viel kleinere Matrizen gelernt, deren Zusammenspiel eine niedrigrangige Annäherung an die gewünschte Veränderung ergibt — daher "low-rank". Das Ergebnis ist eine Datei von wenigen Megabyte bis niedrigen hundert Megabyte, statt mehrerer Gigabyte. In ComfyUI liegt sie in models/loras/.

Was ein LoRA nicht kann: Er erschafft kein neues Grundwissen. Ein LoRA für einen bestimmten Architekturstil funktioniert, weil das Modell bereits weiß, was Fassaden, Materialien und Proportionen grundsätzlich sind — der LoRA verschiebt dieses vorhandene Wissen in eine bestimmte ästhetische Richtung. Je nach Trainingsziel wirkt das eher präzisierend (aus "ein Gesicht" wird verlässlich "dieses eine Gesicht") oder eher stilistisch verfärbend (aus "ein Bild" wird "ein Bild in dieser bestimmten Bildsprache"). Beides ist dieselbe Mechanik — eine gezielte Gewichtsverschiebung — nur mit unterschiedlicher Wirkung je nach Trainingsdaten.

Diese Eigenschaft erklärt auch, warum LoRA-Training mit überraschend wenigen Bildern funktioniert — oft genügen 30 bis 50 stilistisch konsistente Aufnahmen, statt der Millionen, die für ein vollständiges Modelltraining nötig wären. Es muss kein neues Verständnis aufgebaut werden, nur eine bestehende Tendenz im Modell gezielt verstärkt werden.

Ein Diffusionsmodell kann mit verschiedenen LoRAs kombiniert werden — je nach Aufgabe ein anderer Aufsatz, oder auch mehrere gleichzeitig mit unterschiedlicher Gewichtung. Das Grundmodell bleibt dabei immer dasselbe; nur die Spezialisierung wechselt.

Weil ein LoRA bestimmte Gewichte verschiebt, ist er an die Architektur gebunden, für die er trainiert wurde: Ein SDXL-LoRA wirkt nicht auf Flux. LoRAs für Flux.1 dev laden und wirken dagegen auch auf Krea und umgekehrt, weil beide dieselbe Architektur haben. Wie gut sich ein Stil-LoRA mit Kreas eigener Ästhetik verträgt, ist eine andere Frage.

Eigene LoRAs lassen sich auch mit kleinen, selbst zusammengestellten Bildersets trainieren — relevant etwa für einen bestimmten Bildstil oder die durchgehende Konsistenz einer Bildserie. Dieses Thema verdient ein eigenes Tutorial und wird an anderer Stelle vertieft.

Der VAE (Variational Autoencoder) wurde im letzten Artikel bereits kurz erwähnt: Das Ergebnis des Diffusionsprozesses liegt zunächst im Latent Space vor — einer komprimierten, mathematischen Repräsentation, mit der das neuronale Netz arbeitet. Diese Repräsentation ist kein Bild im üblichen Sinn; sie muss erst übersetzt werden.

Diese Übersetzung übernimmt der VAE: ein eigenes, kleineres Netz, das die komprimierte Latent-Space-Repräsentation in tatsächliche Pixelwerte umrechnet. Ohne diesen letzten Schritt gäbe es kein sichtbares Bild — nur die mathematische Repräsentation davon.

Bei SDXL ist der VAE im Checkpoint enthalten und wird automatisch mitgeladen; bei Bedarf lässt er sich durch einen separat geladenen VAE ersetzen. Bei Flux.1 ist er immer eine eigene Datei: ae.safetensors, rund 335 MB, in models/vae/. Auch der VAE gehört zur Architektur — jede Modellfamilie baut ihren Latent Space anders auf, deshalb passt der Flux-VAE nicht zu SDXL und umgekehrt.

Zu all dem kommt eine weitere Kategorie ladbarer Modelldateien: ControlNet-Modelle. Anders als ein LoRA verändern sie nicht, was generiert wird, sondern geben eine zusätzliche, strukturelle Steuerung vor — zum Beispiel anhand von Kantenverläufen, Tiefeninformation oder Posen, die aus einem Referenzbild oder einer 3D-Szene stammen.

Für RAY-L ist genau diese Kategorie zentral: ControlNet Canny ist die Brücke, über die Blender-Geometrie Einfluss auf das generierte Bild nimmt. Wie das im Detail funktioniert — und warum gerade Canny und nicht eine andere ControlNet-Variante — folgt in einem eigenen Artikel.

Auch ControlNet-Modelle sind an die Architektur gebunden: SDXL braucht ein SDXL-Canny, Flux.1 ein Flux-Canny, beide in models/controlnet/. Genau daran hängt, welche Modelle RAY-L unterstützen kann — für Flux.2 Klein gibt es bisher kein ComfyUI-taugliches ControlNet Canny, und Flux.2 dev hat zwar eines, scheidet aber über die Renderzeit aus.