KI · Grundlagen
Modelltypen im Überblick
SDXL, Flux.1 dev, Flux.2 dev, Ideogram 4 — welches Modell wann.
Der letzte Artikel hat geklärt, was ein Checkpoint überhaupt ist: das vollständige, trainierte Modell, auf das LoRA, VAE und ControlNet als Ergänzungen aufsetzen. Dieser Artikel widmet sich der Frage, die in der Praxis zuerst kommt: welchen Checkpoint lädst du überhaupt?
Es gibt nicht "das eine" Bildgenerierungsmodell, sondern mehrere grundverschiedene Architekturen, die sich in Größe, Geschwindigkeit, Qualität, Lizenz und Hardware-Anforderungen erheblich unterscheiden. Die Wahl ist keine reine Geschmacksfrage — sie hängt davon ab, was du zur Verfügung hast und was du erreichen willst.
Dieser Überblick ist bewusst breit gespannt: von Modellen, die auf einem MacBook Air laufen, bis zu Modellen, die selbst potente Hardware an ihre Grenzen bringen. Das spiegelt die Zielgruppe dieser Seite — vom Azubi mit begrenztem Budget bis zur Profi-Produktion mit entsprechender Ausstattung.
Die Modelle im Vergleich
SDXL
Der etablierteste und zugänglichste Einstieg. SDXL läuft stabil mit vergleichsweise wenig Speicherbedarf — auch ein MacBook Air mit 16 GB RAM kommt damit zurecht. Die Bildqualität ist solide, das ControlNet-Ökosystem rund um SDXL ist ausgereift und gut dokumentiert, weil das Modell schon länger im breiten Einsatz ist.
Der Kompromiss: SDXL erreicht nicht das fotorealistische Niveau oder die Prompt-Treue neuerer Architekturen. Für schnelle Iteration, zum Lernen der Grundlagen und für Workflows mit begrenzter Hardware ist es trotzdem die solideste Wahl.
Flux.1 dev
Der nächste Schritt in Qualität und Prompt-Verständnis, bei weiterhin vertretbarem Hardware-Bedarf. Flux.1 dev ist guidance-distilliert — eine Trainingstechnik, die das Modell effizienter macht und die Art verändert, wie es gesteuert wird (mehr dazu im Setup-Artikel zu Flux.1 dev). Für die Praxis heißt das: spürbar bessere Ergebnisse als SDXL, ohne dass die Generierungszeit explodiert.
ControlNet Canny ist für Flux.1 dev bereits verfügbar und funktioniert zuverlässig — das macht es aktuell zum tragfähigsten Modell für den RAY-L-Workflow.
Flux.2 dev
Ein erheblich größeres und leistungsfähigeres Modell als Flux.1 dev — die Größenordnung der Parameter liegt deutlich höher, das Modell kombiniert die Bildsynthese mit einem eigenen Sprachverständnis-System für deutlich genauere Prompt-Umsetzung, bessere Konsistenz über mehrere Referenzbilder hinweg und höhere Auflösung.
Der Preis dafür ist Rechenzeit: Auf einem Mac Studio mit angepasstem Setup läuft Flux.2 dev zwar stabil, aber mit deutlich längerer Generierungszeit als Flux.1 dev — Größenordnung 40 Minuten pro Bild, statt Sekunden bis wenige Minuten. Für schnelle Iteration ist das ungeeignet, für gezielte, finale Ergebnisse durchaus machbar.
Für RAY-L aktuell wichtig: Eine ControlNet-Canny-Implementierung für Flux.2 dev existiert noch nicht. Da das bestehende ControlNet-Ökosystem rund um die Flux-Modellfamilie aber bereits ausgereift ist, ist eine Erweiterung auf Flux.2 dev ein naheliegender, wahrscheinlicher nächster Schritt — eine Frage der Zeit, nicht der grundsätzlichen Machbarkeit.
Ideogram 4
Ein neueres, von Grund auf neu trainiertes Modell mit einem anderen Schwerpunkt: herausragende Textwiedergabe in Bildern, präzise Steuerung über Bounding-Boxes (rechteckige Bereiche, die festlegen, wo welches Element im Bild sitzen soll) und eine strukturierte Prompt-Eingabe statt reinem Fließtext.
Für RAY-L wichtig, und hier ehrlich offen formuliert: Ideogram 4 steuert Komposition nativ über dieses Bounding-Box-System, nicht primär über klassisches ControlNet. Ob und wie sich Blender-Geometrie über Kantenbilder (Canny) an dieses Modell anbinden lässt, ist aktuell ungeklärt — das könnte sich als reine Zeitfrage herausstellen, oder einen grundsätzlich anderen Übersetzungsweg erfordern. Dazu mehr, sobald die RAY-L-Integration für dieses Modell konkret geprüft wird.
Entscheidungsfragen, nicht nur Eckdaten
Statt einer reinen Spec-Tabelle helfen bei der Modellwahl eher diese Fragen:
Was gibt deine Hardware her? SDXL läuft auf bescheidener Ausstattung, Flux.1 dev braucht etwas mehr, Flux.2 dev fordert auch potente Hardware und Geduld.
Brauchst du schnelle Iteration oder ein einzelnes, hochwertiges Ergebnis? Für viele Testläufe in kurzer Zeit eignen sich kleinere, schnellere Modelle. Für ein finales, einzelnes Bild lohnt sich auch ein langsameres, leistungsfähigeres Modell.
Ist ControlNet Canny für deinen Workflow notwendig? Wenn Blender-Geometrie die Bildkomposition steuern soll — wie im RAY-L-Workflow — ist die Verfügbarkeit von ControlNet Canny für das jeweilige Modell aktuell das entscheidende Auswahlkriterium. Stand heute ist das bei SDXL und Flux.1 dev gegeben, bei Flux.2 dev und Ideogram 4 noch nicht.
Welche Lizenz passt zu deinem Vorhaben? Dazu mehr im nächsten Artikel — Lizenzmodelle unterscheiden sich zwischen den Modellen erheblich, und "offene Gewichte" bedeutet nicht automatisch uneingeschränkte kommerzielle Nutzung.
Zusammenfassung
Es gibt keine einzelne richtige Antwort auf "welches Modell soll ich nehmen" — nur die richtige Antwort für deine Hardware, dein Zeitbudget und deinen Workflow. SDXL als zugänglicher, schneller Einstieg mit ausgereiftem ControlNet-Ökosystem. Flux.1 dev als aktuell stärkste Kombination aus Qualität und RAY-L-Tauglichkeit. Flux.2 dev als Ausblick auf deutlich höhere Qualität, mit Geduld und (noch) ohne ControlNet. Ideogram 4 als eigenständiger Weg mit anderer Steuerungsphilosophie, dessen RAY-L-Tauglichkeit noch offen ist.
Für die lokale Verwendung mit ComfyUI sind alle vier Modelle bereits vorhanden. Auf Windows mit Nvidia-Hardware — der für diese Workflows typischen Plattform — laufen SDXL, Flux.1 dev, Flux.2 dev und Ideogram 4 ohne besondere Einschränkungen. Eine Ausnahme bildet Apple Silicon (Mac): Hier ist fp8, das Format in dem Ideogram 4 vorliegt, nicht nativ unterstützt, ein vergleichbarer Anpassungsweg fehlt bislang noch.
Der nächste Artikel klärt, was "offene Gewichte" lizenzrechtlich tatsächlich bedeutet — ein Punkt, der bei der Modellwahl oft unterschätzt wird.