Zum Hauptinhalt springen

Eigene KI-Bildgenerierung im Homelab: Was die Cloud dir nicht beibringt

·6 min
Autor
Detlev Lengsfeld
Seit Jahrzehnten im Unix-Subsystem zu Hause. Entwickler, Systemadministrator und Liebhaber puristischer Terminal-Workflows.

KI-Bildgenerierung passiert für die meisten Menschen in einem Browser-Tab. Midjourney, DALL-E, der Discord-Bot, Stable Diffusion über irgendeinen Cloud-Anbieter. Bequem, oberflächlich kostengünstig, und vollständig undurchsichtig. Ich wollte wissen, was unter der Haube passiert — und vor allem: wie es ist, das alles auf eigener Hardware zu betreiben, ohne dass jeder Prompt einen externen Server passiert.

Was folgt, ist keine Schritt-für-Schritt-Anleitung. Das wäre langweilig und nach drei Monaten veraltet. Was folgt, sind die Lessons aus den ersten Tagen mit einem lokalen FLUX.2-Setup auf AMD-Consumer-Hardware — die Sachen, die kein Walkthrough erwähnt, weil sie erst auftauchen, wenn man tatsächlich tippt.

Drei Stationen meiner Computing-Geschichte
1985
Commodore 64
1990
Macintosh
2024
Apple Silicon

Warum lokal überhaupt
#

Cloud-AI ist günstig pro Bild, bis du es ernst meinst. Wer mehr als ein paar Spielereien generiert, sieht die Kosten schnell linear mit der Nutzung wachsen. Aber Geld ist nicht das eigentliche Argument. Das eigentliche Argument heißt: Kontrolle.

In der Cloud bekommst du die Modelle, die der Anbieter für richtig hält, mit den Filtern, die er für angemessen hält, in der Geschwindigkeit, die er gerade bereitstellt. Du siehst nicht, was im Hintergrund passiert. Du kannst Workflows nicht versioniert speichern, du kannst Modelle nicht austauschen, du kannst kein Batch-Processing über deine eigene Pipeline laufen lassen. Und alles, was du eingibst — Bilder, Prompts, Ideen — verlässt deinen Rechner.

Bei sensiblen Bildern (Personen, Privates, geschäftlich Vertrauliches) ist das ein Showstopper. Bei harmlosen Spielereien ist es immer noch ein Argument für Souveränität: was ich erzeuge, gehört mir, und niemand sonst sieht es, wenn ich das nicht will.

Der Stack
#

Mein Setup lebt auf einer ASRock-Workstation mit AMD Ryzen 9 7900, 32 GB DDR5 und einer AMD Radeon RX 7900 XTX mit 24 GB VRAM. Das System läuft Proxmox VE 9 als Hypervisor, darauf eine Debian-13-VM mit GPU-Passthrough für die GPU-intensive Arbeit. Auf der VM:

  • ROCm 7.2 als AMD-GPU-Compute-Stack
  • PyTorch 2.11.0+rocm7.2 als ML-Framework
  • ComfyUI als Workflow-Engine
  • FLUX.2 dev (GGUF Q4-Quantisierung) als Generierungsmodell
  • Mistral 3 Small als Text-Encoder

Der Mac M1 dient ausschließlich als Thin Client. Ich tippe vom Mac aus, ein Bash-Wrapper schickt den Prompt per SSH an die Linux-VM, dort rechnet die 7900 XTX, das fertige Bild kommt per scp zurück. Apple Silicon ist ein hervorragender Editor- und Browser-Computer, aber AI-Inference gehört auf eine ordentliche GPU.

flux "anthracite carport with sandstone pavers" --input carport.jpg --denoise 0.6

Das ist auf dem Mac. Im Hintergrund: SSH-Trigger, GPU-Render, scp-Download, automatisches Öffnen im Preview. Drei Sekunden Wartezeit, dann ist das Bild da — beziehungsweise, präziser: drei Sekunden plus die tatsächliche Render-Zeit von 30 bis 90 Sekunden.

Was die Tutorials nicht erwähnen
#

Hier wird’s interessant. Jedes YouTube-Tutorial zeigt dir den glücklichen Pfad: clone das Repo, pip install, fertig. Was niemand erwähnt:

Die VRAM-Falle ist eigentlich eine RAM-Falle. Eine 24-GB-Karte klingt nach Luxus für FLUX.2, das knapp unter dieser Grenze bleibt. Was niemand sagt: PyTorch reserviert beim Start standardmäßig 21 GB System-RAM als “pinned memory” für effiziente GPU-Transfers. Bei einer VM mit 24 GB RAM kollidiert das mit allem anderen, das gleichzeitig läuft (Docker-Stack, andere Services, das System selbst). Resultat: Out-of-Memory-Kills genau in dem Moment, in dem dein Render gestartet wird. Lösung: ComfyUI mit --lowvram starten — paradoxerweise nicht, weil VRAM knapp ist, sondern weil RAM knapp ist.

ROCm ist nicht CUDA. Klingt offensichtlich, ist es nicht. Viele Tools setzen stillschweigend CUDA voraus, und ihre Default-Installationsanweisungen ziehen automatisch CUDA-PyTorch-Wheels von PyPI, die auf AMD-Hardware kommentarlos auf CPU zurückfallen. Du musst pip explizit auf den ROCm-Wheel-Index zwingen — und selbst dann ignoriert uv (das modernere Pip) manchmal den Pin und fällt wieder auf PyPI zurück. Workaround: pip install --force-reinstall --no-cache --index-url https://download.pytorch.org/whl/rocm7.2 torch==X.Y.Z+rocm7.2.

Cold-Start versus Hot-Start. Der erste Render nach einem Service-Neustart dauert vier Minuten — nicht weil die GPU langsam ist, sondern weil ComfyUI das Modell aus Disk-Cache in den VRAM streamt. Alle weiteren Renders sind dann 20–30 Sekunden schnell. Das ist normal, aber bei Polling-Wrappern mit fünf-Minuten-Timeout muss man das wissen, sonst wirkt es kaputt.

Python-Environments brauchen Aufmerksamkeit. Wer das venv versehentlich als Root anlegt, kriegt später Berechtigungsschmerzen — uv legt sein managed Python im Home-Verzeichnis des ausführenden Users ab, und root-owned Symlinks sind nicht reparierbar, nur ersetzbar. Sauberer Bootstrap als der nicht-privilegierte User. Klingt selbstverständlich, hat mich trotzdem eine Stunde gekostet.

Das eigentliche Können ist Prompt-Engineering
#

Sobald der Stack steht, beginnt das echte Lernen. Und das hat wenig mit ComfyUI zu tun und alles mit präziser Sprache.

Naive Prompts liefern naive Ergebnisse. “Pflaster” rendert FLUX als generisches Beton-Grau. “Warm sandstone interlocking pavers in mixed natural shades of beige, sand-yellow, and reddish-brown, arranged in a random-bond pattern” liefert genau das, was du im Kopf hattest. Der Unterschied zwischen einem brauchbaren und einem unbrauchbaren Render ist meist nicht das Modell, sondern die Spezifität der Beschreibung.

Vier Patterns, die für 80 % der Fälle reichen:

  1. Material explizit — Farben, Texturen, Oberflächen. Nicht “Holz”, sondern “weathered oak with visible grain and natural matte finish”.
  2. Preserve-Klauseln bei img2img — was bleiben soll, wörtlich nennen. “Preserve face, expression, clothing, and background exactly as in the source image.”
  3. Negativ-Klauseln für die typischen Halluzinationen. FLUX neigt zu zufälligem Text auf Wänden, ungebetenen Menschen, “Stock-Photo”-Beleuchtung. Alles, was du nicht willst, explizit ausschließen.
  4. Denoise als Hebel verstehen — bei img2img ist 0.3 subtil, 0.6 der Sweet Spot für Material-Wechsel, 0.85 fast freie Neuinterpretation. Drei Runs mit gleichem Seed bei unterschiedlichen Denoises sagen mehr als Theorie.

Das sind keine Geheimnisse. Aber sie sind verstreut über tausend Reddit-Threads und hundert YouTube-Videos, die alle voneinander abschreiben. Wer sich seine eigene Pattern-Bibliothek aufbaut — bei mir in Obsidian — wird in wenigen Wochen besser als die meisten Cloud-Nutzer, weil er versteht, was er tut, statt zu klicken bis es passt.

Was Cloud-Tools strukturell nicht können
#

Drei Sachen, die man nicht in einer Cloud-UI haben kann:

Workflow-Persistenz auf Werkzeug-Ebene. Mein gen.py-Skript ist 80 Zeilen Python. Es nimmt einen Prompt, optional ein Quellbild, optional einen Seed, und schickt das an die ComfyUI-API. Das Resultat: ein konsistenter CLI-Trigger, der sich in jedes Tooling einbinden lässt — Shell-Aliase, Make-Targets, Hooks im Editor. Bei Midjourney sitzt du im Discord-Bot.

Prompt-Versionierung. ComfyUI bettet beim Speichern den kompletten Workflow als PNG-Metadata in jeden Output ein. Ein kleines Python-Skript extrahiert daraus die History aller jemals generierten Bilder. Ich kann jedes Bild reproduzieren, Variationen davon ableiten, Prompts revidieren. In der Cloud ist alles, was du hast, der Chat-Verlauf.

Vollständige Kontrolle über sensible Bilder. Personenbearbeitung, geschäftliche Visualisierungen, vertrauliche Konzepte — das alles geht in der Cloud entweder gar nicht (Filter) oder unter potentieller Beobachtung. Lokal liegt es auf deiner SSD und nirgendwo sonst.

Was als nächstes kommt
#

Klassisches img2img, wie ich es im Moment nutze, ist nicht das Ende. FLUX.2 hat einen dedizierten Edit-Modus, der Quellbilder über Cross-Attention als echtes Referenz-Conditioning einspeist — präziser für strukturerhaltende Bearbeitung. ControlNet erlaubt Steuerung über Tiefenkarten oder Kanten-Detection. Eigene LoRAs trainieren wäre der nächste Schritt — ein Modell darauf justieren, deinen eigenen visuellen Stil zu lernen.

Aber das ist Material für weitere Artikel. Für jetzt ist das Setup stabil, der Workflow funktioniert, und ich generiere Bilder, die ich vor zwei Wochen noch in der Cloud erzeugt hätte — schneller, billiger, kontrollierter, und ohne dass ein Anbieter zwischen mir und dem Resultat steht.

Wenn dich das Thema interessiert
#

Ich biete KI-Schulungen und Beratung zu lokal-first AI-Setups an — speziell für Leute, die nicht zwanzig Stunden Trial-and-Error investieren wollen, um an dem Punkt anzukommen, an dem ich jetzt bin. Wer das selbst durchziehen will, findet auf ComfyUI auf GitHub und in der PyTorch-ROCm-Dokumentation den Startpunkt. Black Forest Labs stellt die FLUX-Modelle auf Hugging Face bereit.

Lokale KI ist anstrengender als Cloud-KI. Sie ist auch ehrlicher: du siehst, was du dir aufgebaut hast.