KI · Setup & Infrastruktur

Stability Matrix

Was ein Launcher ist, warum du einen brauchst — und warum lokale Generierung der richtige Weg ist.

Wer bisher mit KI-Bildgenerierung gearbeitet hat, kennt wahrscheinlich ein Interface dieser Art: ein Textfeld für den Prompt, vielleicht ein Referenzbild hochladen, auf "Generieren" klicken, Ergebnis ansehen. Adobe Firefly, Midjourney, der KI-Generator in Canva — sie alle funktionieren nach diesem Prinzip. Die Komplexität dahinter ist vollständig verborgen. Das Modell läuft auf fremden Servern, die Infrastruktur ist unsichtbar, und das ist bewusst so.

Lokale Bildgenerierung sieht beim ersten Kontakt anders aus. Bevor das erste Bild entsteht, müssen mehrere Gigabyte Modelldateien heruntergeladen werden, Komponenten müssen konfiguriert und verbunden werden, und die Oberfläche von ComfyUI besteht nicht aus einem Textfeld, sondern aus einem Netzwerk von Nodes. Das ist keine schlechte Nutzererfahrung — es ist eine andere, die eine andere Absicht widerspiegelt.

Die Frage ist: Lohnt sich die Zeit, die dieser Einstieg kostet?

Für jemanden, der gelegentlich ein Bild für eine Präsentation generieren will, wahrscheinlich nicht. Für jemanden, der professionell mit Bildgenerierung arbeitet — oder vorhat, es zu tun — ist die Antwort eindeutig ja. Und der Grund hat wenig mit Qualität zu tun und viel mit Zeit.

Wer einen Cloud-Workflow aufgebaut hat, hat in mehrere proprietäre Systeme investiert. Jedes davon entwickelt sich in seinem eigenen Tempo: Preismodelle ändern sich, Features verschwinden, Modelle werden ersetzt. Ein Profi, der heute mit Midjourney v6 arbeitet, wird in einem Jahr seinen Workflow neu kalibrieren — nicht weil er es will, sondern weil das System sich verändert hat. Ohne Hebel, den er bedienen kann.

ComfyUI ist der Gegenentwurf. Nicht ein Modell, sondern eine Infrastruktur für alle Modelle. Wenn Flux.1 von Flux.2 abgelöst wird, tauscht man einen Node aus. Wenn ein neues ControlNet erscheint, lädt man eine Datei herunter. Der Workflow bleibt, die Logik bleibt — was sich ändert ist die eine Komponente, die sich geändert hat.

Wer ComfyUI einmal verstanden hat, muss kein neues System mehr lernen. Er muss nur ein neues Modell einbinden. Das ist der Unterschied zwischen einer einmaligen Zeitinvestition und einem Dauerlauf auf dem Laufband — bei dem man nie wirklich vorankommt, weil der Boden sich mitbewegt.

Dazu kommt etwas, das Cloud-Generatoren grundsätzlich nicht bieten können: die Möglichkeit, das System zu erweitern. Eigene LoRAs trainieren, ControlNet-Workflows aufbauen, Bildstile für eine ganze Produktionsstrecke konsistent halten — das setzt voraus, dass man Zugang zur Infrastruktur hat, nicht nur zum Interface.

Warum ein Launcher

Bevor du ComfyUI das erste Mal startest, steht eine praktische Frage: Wie kommen die Modelle auf deinen Rechner, und wo landen sie?

KI-Bildgenerierung besteht nicht aus einem einzelnen Programm. Es ist ein Zusammenspiel aus mehreren Komponenten: dem Inferenz-Frontend (ComfyUI), dem eigentlichen Diffusionsmodell (dem Checkpoint), dem VAE, den Encodern, ControlNet-Modellen, LoRAs. Jede dieser Komponenten ist eine eigene Datei, oft mehrere Gigabyte groß, oft auf verschiedenen Plattformen verteilt — Hugging Face, Civitai, GitHub. Ohne ein Verwaltungswerkzeug endet das schnell in einem Ordner voller unbeschrifteter safetensors-Dateien, bei dem man nach drei Wochen nicht mehr weiß, welche Version wozu gehört.

Stability Matrix ist dieses Verwaltungswerkzeug. Ein Launcher und Paketmanager für lokale KI-Bildgenerierung — kein Modell selbst, kein Interface, sondern die Ebene darunter: Installation, Verwaltung, Updates, Isolation.

Was Stability Matrix macht — und was nicht

Stability Matrix installiert und verwaltet Inferenz-Frontends wie ComfyUI, Automatic1111 oder InvokeAI als isolierte Instanzen. Jede Instanz hat ihre eigene Python-Umgebung, ihre eigenen Pakete, ihre eigene Konfiguration. Ein Update von ComfyUI bricht nicht die danebenstehende Automatic1111-Installation.

Es verwaltet Modelle: Checkpoints, VAEs, LoRAs, ControlNet-Modelle, Embeddings, Upscaler — alles in einem zentralen Verzeichnis, das alle installierten Frontends teilen können. Ein Modell herunterladen, in allen Frontends verfügbar.

Es lädt direkt von Hugging Face und Civitai, mit Versionskontrolle. Du siehst welche Version du hast, ob es eine neuere gibt, und kannst gezielt eine bestimmte Version festhalten — was wichtiger ist als es klingt, denn neue Modellversionen sind nicht immer besser für den eigenen Anwendungsfall.

Was Stability Matrix nicht macht: Bilder generieren, Workflows ausführen, Prompts verarbeiten. Das ist ComfyUI — das nächste Kapitel.

Installation

Stability Matrix läuft auf Windows, macOS und Linux.

Windows: Die aktuelle Version als .exe-Installer von der offiziellen GitHub-Seite herunterladen: github.com/LykosAI/StabilityMatrix/releases

Den Installer ausführen. Stability Matrix fragt beim ersten Start nach einem Datenverzeichnis — dem Ort, wo alle Modelle, Frontends und Konfigurationen gespeichert werden. Dieser Ordner sollte auf einem Laufwerk mit ausreichend Platz liegen. Ein einzelner Flux.1-dev-Checkpoint ist 23 GB, SDXL-Checkpoints liegen zwischen 6 und 7 GB. Ein realistisches Setup mit zwei bis drei Modellen, ein paar LoRAs und ControlNet-Modellen belegt schnell 60–80 GB.

macOS (Apple Silicon): Das .dmg-Paket von derselben GitHub-Seite herunterladen. Nach dem Öffnen die App in den Programme-Ordner ziehen. Beim ersten Start meldet macOS möglicherweise, dass die App von einem nicht verifizierten Entwickler stammt — unter Systemeinstellungen → Datenschutz & Sicherheit lässt sie sich trotzdem öffnen. Das Datenverzeichnis funktioniert identisch wie unter Windows. Ein externer SSD ist auf macOS empfehlenswert, da der interne Speicher auf Apple Silicon oft begrenzt ist.

ComfyUI installieren

Nach dem ersten Start zeigt Stability Matrix den Packages-Bereich. Hier werden Frontends installiert.

"Add Package" → "ComfyUI" auswählen → installieren. Stability Matrix lädt ComfyUI herunter, richtet eine isolierte Python-Umgebung ein und konfiguriert die Verzeichnisstruktur automatisch. Keine manuelle Python-Installation, keine Pfadkonfiguration.

Nach der Installation erscheint ComfyUI in der Package-Liste. Über "Launch" startet es — Stability Matrix öffnet dann automatisch den Browser mit der ComfyUI-Oberfläche unter http://127.0.0.1:8188. Dazu gleich mehr.

Modelle verstehen — bevor du etwas herunterlädst

Hier lohnt es sich kurz innezuhalten.

Ein KI-Bildmodell ist kein einzelnes Ding. Es ist ein Zusammenspiel aus Komponenten, die unterschiedliche Aufgaben übernehmen. Welche Komponenten das sind — und ob sie im Checkpoint eingebettet oder separat geladen werden — hängt vom Modell ab. Für SDXL und Flux.1 dev sieht das unterschiedlich aus, und diesen Unterschied sollte man verstehen, bevor man anfängt Dateien herunterzuladen.

Ein SDXL-Setup besteht aus:

  • Checkpoint — das eigentliche Diffusionsmodell, trainiert auf Millionen von Bild-Text-Paaren. Der Checkpoint enthält die Gewichte des U-Net, aber nicht zwingend einen eigenen VAE oder CLIP-Encoder — das hängt vom jeweiligen Checkpoint ab.
  • VAE (Variational Autoencoder) — übersetzt zwischen dem latenten Raum des Modells (wo die Diffusion stattfindet) und dem sichtbaren Pixel-Bild. Juggernaut XL empfiehlt einen externen VAE, weil der eingebettete für fotorealistische Aufnahmen suboptimal ist. Der SDXL-VAE von Stability AI (sdxl_vae.safetensors) ist der Standardfall.
  • CLIP-Encoder — verarbeitet den Text-Prompt. SDXL nutzt zwei CLIP-Encoder gleichzeitig (CLIP-G und CLIP-L), die in den meisten Checkpoints bereits eingebettet sind.
  • ControlNet-Modell — optional, aber für RAY-L zwingend. Ein separates Modell, das die Bildgenerierung an eine Eingabe-Struktur bindet — im RAY-L-Workflow: die Kantendaten aus Blender. ControlNet-Modelle sind checkpoint-spezifisch: ein für SDXL trainiertes ControlNet funktioniert nicht mit Flux.

Ein Flux.1 dev-Setup besteht aus:

  • Checkpoint — das Diffusionsmodell, hier als Transformer-Architektur (DiT) statt U-Net. Flux.1 dev ist mit ~23 GB deutlich größer als SDXL.
  • VAE — Flux bringt einen eigenen VAE mit, der in der Regel im Checkpoint enthalten ist, aber auch separat vorliegen kann.
  • Zwei Encoder — und hier liegt ein wesentlicher Unterschied zu SDXL: Flux nutzt CLIP-L und T5XXL gleichzeitig. T5XXL ist ein Sprach-Encoder, der echte Satzstruktur versteht — deutlich größer als CLIP (die T5XXL-fp16-Variante ist allein ~10 GB). Warum das für Prompts eine Rolle spielt, kommt in 2.4.3 — Prompts für Flux.
  • ControlNet-Modell — für RAY-L: ein für Flux trainiertes ControlNet Canny. Das ist ein anderes Modell als das SDXL-ControlNet — sie sind nicht austauschbar.

Diese Architekturunterschiede erklären, warum Stability Matrix zwischen Checkpoint, VAE, CLIP, T5 und ControlNet als getrennten Kategorien unterscheidet. Universelle Modell-Dateien, die für alles funktionieren, gibt es nicht.

Modelle herunterladen

Im Model Browser von Stability Matrix lassen sich Modelle direkt von Hugging Face und Civitai suchen und herunterladen — mit automatischer Einordnung in die richtige Verzeichnisstruktur.

Für ein SDXL-Setup (Juggernaut XL):

  1. Checkpoint: "Juggernaut XL" auf Civitai suchen, aktuelle Version wählen. Die .safetensors-Datei landet automatisch im Checkpoints-Verzeichnis.
  2. VAE: "sdxl-vae-fp16-fix" auf Hugging Face — dieser VAE behebt einen bekannten Farbstich des originalen SDXL-VAE bei fp16-Inferenz.
  3. ControlNet Canny für SDXL: "controlnet-canny-sdxl-1.0" von Hugging Face (diffusers-Format) oder die entsprechende .safetensors-Variante.

Für ein Flux.1 dev-Setup:

  1. Checkpoint: Flux.1 dev von Hugging Face (black-forest-labs/FLUX.1-dev) — erfordert eine kostenlose Registrierung auf huggingface.co und die Akzeptanz der Lizenzbedingungen von Black Forest Labs auf der Modell-Seite. Erst nach dieser Freischaltung ist der Download zugänglich. Die flux1-dev.safetensors (~23 GB) landet im Checkpoints-Verzeichnis.
  2. T5XXL-Encoder: t5xxl_fp16.safetensors oder t5xxl_fp8_e4m3fn.safetensors (kleiner, geringfügig weniger präzise) — von Hugging Face, in das Text Encoders-Verzeichnis.
  3. CLIP-L-Encoder: clip_l.safetensors — ebenfalls von Hugging Face, in dasselbe Verzeichnis.
  4. VAE: ae.safetensors (der Flux-eigene VAE) — oft im selben Repository wie der Checkpoint.
  5. ControlNet Canny für Flux: flux-controlnet-canny-v3.safetensors von InstantX auf Hugging Face — in das ControlNet-Verzeichnis.

Warum T5XXL separat? Bei manchen Flux-Checkpoints sind die Encoder eingebettet, bei anderen nicht. Der praktische Vorteil der separaten Variante: T5XXL lässt sich zwischen verschiedenen Modellen teilen — wer später Flux.2 oder andere T5-basierte Modelle nutzt, verwendet denselben Encoder-File.

Verzeichnisstruktur

Stability Matrix legt alle Inhalte eines installierten Frontends in einem Packages/-Verzeichnis ab. Für ComfyUI entsteht dabei folgende Struktur:

[SM-Ordner]/
└── Packages/
    └── ComfyUI/
        └── models/
            ├── checkpoints/     ← SDXL- und Flux-Checkpoints
            ├── vae/             ← VAE-Dateien
            ├── controlnet/      ← ControlNet-Modelle
            ├── loras/           ← LoRA-Dateien
            ├── clip/            ← CLIP-Encoder
            └── text_encoders/   ← T5XXL und andere Encoder

Wo [SM-Ordner] liegt, unterscheidet sich je nach Betriebssystem und Installationswahl — die Struktur darunter ist auf allen Plattformen identisch. ComfyUI liest diese Verzeichnisse direkt — keine manuellen Pfade, solange Stability Matrix als Launcher verwendet wird.

Updates — wann ja, wann nein

KI-Modelle und Frontends entwickeln sich schnell, und Stability Matrix zeigt verfügbare Updates zuverlässig an. Das bedeutet nicht, dass man sie einspielen sollte.

ComfyUI-Updates können bestehende Workflows brechen, wenn sich Node-APIs ändern. Die Faustregel: Update wenn du weißt was die neue Version bringt — oder wenn ein konkretes Problem behoben werden soll. Nicht davor.

Für Modelle gilt ähnliches: Neue Checkpoint-Versionen sind nicht automatisch besser für den eigenen Anwendungsfall. Stability Matrix lässt mehrere Versionen parallel installiert — ein Vergleich lohnt sich, bevor die alte Version gelöscht wird.

fp16, fp8, GGUF — Gewichtsformate

Modell-Dateien erscheinen oft in mehreren Varianten: fp16, fp8_e4m3fn, GGUF Q4_K_M. Das sind unterschiedliche Präzisionsformate mit direktem Einfluss auf Dateigröße, VRAM-Bedarf und Ausgabequalität.

fp16 (16-bit floating point) ist der Standard. Maximale Qualität, maximaler VRAM-Bedarf. T5XXL in fp16 ist ~10 GB.

fp8 (8-bit floating point) halbiert grob die Dateigröße bei geringfügigem Qualitätsverlust — für die meisten Anwendungsfälle kaum wahrnehmbar. Flux.1 dev in fp8 ist ~12 GB statt ~23 GB. Auf Apple Silicon MPS erfordert fp8-Inferenz einen eigens entwickelten Patch (patch_mps_fp8_SM.py).

GGUF ist ein Format aus dem LLM-Bereich, das quantisierte Modelle unterschiedlicher Präzision (Q4, Q5, Q8…) in einer Datei bündelt. Für Flux gibt es GGUF-Varianten, die auf CPU+RAM statt GPU laufen — nützlich bei begrenztem VRAM, aber deutlich langsamer.

Für den Einstieg mit Nvidia-GPU: Checkpoints in fp16 (wenn VRAM reicht), T5XXL in fp8 (guter Kompromiss), ControlNet-Modelle in fp16.