Du gibst einen Prompt ein.
Einige Sekunden später erscheint ein Bild.
Bei einem Cloud-Dienst sieht der technische Weg vereinfacht so aus:
Prompt
↓
Internet
↓
Server des Anbieters
↓
Bildmodell
↓
Bild
↓
Internet
↓
dein Rechner
Bei lokaler Bild-KI verändert sich dieser Weg.
Prompt
↓
eigener Rechner oder Server
↓
lokales Bildmodell
↓
Bild
Die eigentliche Bildgenerierung findet damit auf Hardware statt, die du selbst betreibst oder kontrollierst.
Das kann ein normaler Desktop-PC sein.
Eine Workstation.
Ein Rechner im Heimnetz.
Oder ein eigener GPU-Server.
Genau wie bei lokaler KI ist „lokal“ also in erster Linie eine Aussage darüber, wo die Inferenz stattfindet.
Lokal bedeutet nicht zwangsläufig auf demselben Computer
Du könntest auf deinem Notebook arbeiten.
Die GPU befindet sich aber in einem Rechner im Keller.
Notebook
↓
Heimnetz
↓
KI-Server mit GPU
↓
Bildmodell
Für den Nutzer fühlt sich das nahezu wie eine Cloud an.
Der entscheidende Unterschied:
Die Infrastruktur gehört zu deinem eigenen System.
Ein lokales Bildmodell muss nicht auf einem Desktop laufen
Ein professionellerer Aufbau könnte beispielsweise so aussehen:
WordPress ───────┐
│
n8n ─────────────┼→ lokaler Bildserver
│
Weboberfläche ───┤
│
interne App ─────┘
Damit wird die GPU nicht nur von einer einzelnen Oberfläche verwendet.
Sie stellt eine gemeinsame Bildfunktion für mehrere Anwendungen bereit.
Lokale Bild-KI ist kein eigener Modelltyp
Das ist wichtig.
Ein Bildmodell ist nicht automatisch:
lokal
oder:
Cloud.
Dasselbe oder ein technisch vergleichbares Modellprinzip kann beispielsweise als:
lokaler Dienst
oder:
gehosteter Dienst
betrieben werden.
„Lokal“ beschreibt die Infrastruktur.
Nicht die kreative Fähigkeit des Modells.
Was läuft bei Bild-KI eigentlich auf der eigenen Hardware?
Ein lokaler Bildgenerator besteht nicht nur aus einer einzigen Datei.
Vereinfacht können mehrere Komponenten beteiligt sein.
Prompt
↓
Textverarbeitung
↓
Bildgenerationsmodell
↓
Zwischenrepräsentation
↓
Decoder
↓
fertiges Bild
Je nach Modellarchitektur ist der technische Aufbau unterschiedlich.
Für das praktische Verständnis reicht zunächst:
Mehrere Modellbestandteile arbeiten zusammen, um aus Text beziehungsweise weiteren Eingaben ein Bild zu erzeugen.
Das Basismodell ist nur ein Teil des Systems
Zusätzlich können verwendet werden:
LoRA
Referenzsteuerung
Pose-Kontrolle
Depth-Kontrolle
Inpainting
Upscaling
Damit wächst aus einem einfachen Bildgenerator ein kompletter Bildworkflow.
Ein einfacher lokaler Workflow
Die kleinste Variante lautet:
Prompt
↓
Basismodell
↓
GPU
↓
Bild
Das reicht bereits für Text-to-Image.
Ein etwas komplexerer Workflow
Prompt
+
Style-LoRA
↓
Bildmodell
↓
GPU
↓
Bild
Nun kommt der unter LoRA für Bild-KI beschriebene Adapter hinzu.
Noch komplexer
Prompt
+
Style-LoRA
+
Personenreferenz
+
Pose
↓
Bildmodell
↓
GPU
↓
Bild
Jetzt müssen mehrere Bedingungen gleichzeitig verarbeitet werden.
Die Hardwareanforderungen können entsprechend steigen.
Warum ist die GPU bei lokaler Bild-KI so wichtig?
Bildgenerierung besteht aus sehr vielen Matrixoperationen.
GPUs sind hervorragend für stark parallele Berechnungen geeignet.
Deshalb können sie Bildmodelle wesentlich schneller verarbeiten als eine gewöhnliche CPU.
Das bedeutet nicht:
Bild-KI
=
unbedingt diskrete GPU erforderlich
Aber für größere moderne Bildmodelle und komfortable Generierungszeiten ist eine geeignete GPU in der Praxis häufig der entscheidende Bestandteil.
CPU-Generierung ist grundsätzlich möglich
Je nach Modell und Software können Bildmodelle auch ganz oder teilweise über:
CPU
+
RAM
betrieben werden.
Das kann interessant sein für:
Experimente,
kleinere Modelle,
seltene Generierungen.
Die Geschwindigkeit liegt jedoch häufig deutlich unter einer passenden GPU-Lösung.
Die GPU bestimmt nicht allein die Qualität
Eine sehr schnelle Grafikkarte macht ein mittelmäßiges Modell nicht intelligenter.
Die GPU beeinflusst vor allem:
Geschwindigkeit
mögliche Modellgröße
mögliche Auflösung
Parallelität
Die Qualität hängt stärker ab von:
Modell,
Prompt,
Referenzen,
LoRA,
Workflow.
VRAM ist für lokale Bild-KI besonders wichtig
Wie im Artikel über VRAM beschrieben, besitzt eine diskrete GPU ihren eigenen schnellen Speicher.
Dort müssen während der Verarbeitung unter anderem Teile der verwendeten Modelle und temporäre Rechendaten Platz finden.
Vereinfacht:
VRAM
├── Basismodell
├── Textkomponenten
├── Bilddecoder
├── LoRA
├── Control-Komponenten
└── temporäre Tensoren
Nicht jeder Bestandteil muss zwangsläufig dauerhaft gleichzeitig vollständig im VRAM liegen.
Aber sie konkurrieren um dieselbe Ressource.
Ein Modell kann auf SSD passen und trotzdem nicht in den VRAM
Das ist derselbe wichtige Unterschied wie bei lokalen Sprachmodellen.
Modell liegt auf SSD
≠
Modell läuft vollständig im VRAM
Eine Modelldatei mit beispielsweise vielen Gigabyte kann problemlos auf der Festplatte liegen.
Zum Generieren benötigt die Software jedoch ausreichend:
VRAM
oder:
eine Strategie zum Auslagern von Teilen in den normalen RAM.
Offloading kann Speicherprobleme entschärfen
Wenn nicht alles gleichzeitig auf die GPU passt, können bestimmte Bestandteile zwischen:
VRAM
↔
RAM
verschoben werden.
Das ermöglicht Generierung auf kleinerer Hardware.
Der Nachteil:
Datentransfers kosten Zeit.
Eine Konfiguration, bei der alles Wichtige vollständig in den schnellen GPU-Speicher passt, kann deshalb deutlich schneller sein.
Bildauflösung beeinflusst den Speicherbedarf
Ein Bild mit:
512 × 512
besitzt wesentlich weniger Bildinformation als:
2048 × 2048
Bei der Generierung entstehen intern Zwischenrepräsentationen, deren Größe von der Auflösung abhängen kann.
Deshalb gilt grundsätzlich:
höhere Auflösung
→ mehr Rechenaufwand
→ häufig mehr VRAM
Die genaue Skalierung hängt vom Modell und Workflow ab.
Viermal so viele Pixel sind schnell erreicht
Vergleichen wir:
1024 × 1024
=
1.048.576 Pixel
mit:
2048 × 2048
=
4.194.304 Pixel
Doppelte Breite und doppelte Höhe bedeuten:
ungefähr viermal so viele Pixel.
Das erklärt, warum hohe Auflösungen schnell teuer werden können.
Deshalb muss nicht jedes Bild direkt riesig erzeugt werden
Ein sinnvoller Workflow kann lauten:
4 Kandidaten
↓
moderate Auflösung
↓
bestes Bild auswählen
↓
Upscaling beziehungsweise finale Verarbeitung
Damit wird GPU-Zeit nicht für drei Bilder verschwendet, die später sowieso verworfen werden.
Batchgröße ist ein weiterer Faktor
Ein Bild:
Batch = 1
Mehrere Bilder gleichzeitig:
Batch > 1
Eine größere Batchgröße kann auf leistungsfähiger Hardware den Durchsatz verbessern.
Sie benötigt aber auch mehr Speicher.
Vier Bilder gleichzeitig sind nicht dasselbe wie vier Bilder nacheinander
Nacheinander:
Bild 1
↓
Bild 2
↓
Bild 3
↓
Bild 4
braucht eventuell weniger maximalen VRAM.
Gleichzeitig:
├── Bild 1
├── Bild 2
├── Bild 3
└── Bild 4
kann mehr Speicher verlangen.
Für einen kleinen lokalen Server ist nacheinander deshalb oft einfacher.
Durchsatz und Latenz sind zwei unterschiedliche Ziele
Ein einzelner Nutzer möchte:
möglichst schnell mein Bild
Das ist Latenz.
Eine Contentfabrik möchte:
möglichst viele Bilder pro Stunde
Das ist Durchsatz.
Die optimale Konfiguration kann für beide Ziele unterschiedlich sein.
Ein interaktiver Bildarbeitsplatz
Du arbeitest selbst an einem Bild.
Dann ist wichtig:
Prompt
↓
möglichst schnell Vorschau
Du möchtest Varianten ausprobieren und nicht minutenlang auf jeden kleinen Test warten.
Ein Batchserver
Hundert Artikel brauchen nachts Titelbilder.
Nun ist wichtiger:
100 Jobs
↓
möglichst effizient abarbeiten
Ein einzelner Job darf etwas länger dauern, solange der Gesamtdurchsatz stimmt.
Diese Unterscheidung beeinflusst die Infrastruktur
Interaktiv:
hohe Priorität
↓
GPU sofort
Batch:
Queue
↓
freie Kapazität
Genau dafür eignen sich die Konzepte aus unseren Artikeln über Workflows und den lokalen KI-Server.
Das Basismodell kann dauerhaft geladen bleiben
Wenn fast jeder Bildjob dasselbe Grundmodell verwendet:
Basismodell
↓
VRAM
↓
bleibt geladen
Dann muss es nicht für jeden Auftrag erneut von SSD geladen werden.
Das reduziert Ladezeiten.
LoRAs können kleiner und flexibler sein
Ein Grundmodell könnte beispielsweise für mehrere Websites genutzt werden.
Basismodell
├── Style-LoRA A
├── Style-LoRA B
├── Style-LoRA C
└── Character-LoRA D
Dadurch wird dieselbe große Modellbasis mehrfach verwendet.
Das ist ein großer Vorteil von LoRA
Ohne Adapter könnte man versucht sein:
vollständiges Modell A
vollständiges Modell B
vollständiges Modell C
zu speichern und zu laden.
Mit LoRA:
ein Basismodell
+
mehrere kleine Anpassungen
Das kann sowohl Speicherplatz als auch Verwaltungsaufwand reduzieren.
LoRA benötigt trotzdem Verwaltung
Ein Bildserver muss wissen:
Welche LoRA gehört zu welchem Basismodell?
Welche Version ist produktiv?
Welche darf mit welcher Style-Konfiguration kombiniert werden?
Zum Beispiel:
style_id
↓
Basismodell
↓
LoRA
↓
Parameter
Das sollte nicht jedem einzelnen Workflow überlassen werden.
Eine Style Registry ist deshalb sinnvoll
Konzeptionell:
casiopeya-editorial
↓
base_model_x
↓
style_lora_v3
↓
reference_set_v2
↓
default_parameters
Eine andere Website:
family-handdrawn
↓
base_model_x
↓
style_lora_v5
↓
reference_set_v1
Beide nutzen dieselbe Serverplattform.
Der Bildauftrag bleibt fachlich einfach
Zum Beispiel:
{
"style": "casiopeya-editorial",
"concept": "Ein lokaler KI-Server verarbeitet mehrere Bildanfragen.",
"format": "hero"
}
Der Bildserver kümmert sich um:
Modell,
LoRA,
Referenzen,
technische Parameter.
Das trennt Redaktion von Technik
Redaktion beziehungsweise n8n sagt:
Was brauchen wir?
Der Bildserver entscheidet:
Wie erzeugen wir es technisch?
Das ist dieselbe gute Abstraktion, die wir bereits bei Sprachmodellen verwendet haben.
Ein lokaler Bildserver sollte eine API besitzen
Dann können verschiedene Anwendungen ihn nutzen.
n8n
↓
HTTP API
↓
Image Service
↓
GPU
Oder:
WordPress Backend
↓
API
↓
Image Service
Oder:
interne Weboberfläche
↓
API
↓
Image Service
Ein einfacher Auftrag
Konzeptionell:
{
"operation": "text_to_image",
"prompt": "Eine ruhige redaktionelle Illustration eines Webservers.",
"style": "editorial",
"width": 1280,
"height": 720
}
Die API antwortet nicht zwangsläufig sofort mit dem Bild.
Bildjobs eignen sich gut für asynchrone Verarbeitung
Statt:
Request
↓
30 Sekunden warten
↓
Bild
kann die API sagen:
{
"job_id": "img_4711",
"status": "queued"
}
Der Job läuft anschließend im Hintergrund des Bildservers.
Nach Abschluss
Bildworker
↓
Datei speichern
↓
Jobstatus aktualisieren
Dann kann n8n:
Status abrufen
oder:
über einen Webhook benachrichtigt werden.
Ein vollständiger Ablauf
n8n
↓
Bildjob anlegen
↓
job_id
↓
Queue
↓
GPU Worker
↓
Bild erzeugen
↓
Asset speichern
↓
Webhook
↓
n8n
Das ist wesentlich robuster als eine sehr lange offene HTTP-Anfrage.
Warum eine Queue?
Eine GPU besitzt begrenzte Kapazität.
Angenommen:
50 Artikel werden gleichzeitig fertig.
Ohne Queue:
50 Workflows
↓
50 Bildanfragen gleichzeitig
↓
GPU
Das kann zu:
Speicherproblemen,
Überlastung,
Timeouts
führen.
Mit Queue:
50 Jobs
↓
Warteschlange
↓
kontrollierte Zahl gleichzeitig
↓
GPU
Das System bleibt stabil.
Eine Queue ermöglicht Prioritäten
Zum Beispiel:
HIGH
→ Mensch wartet auf Vorschau
NORMAL
→ heute zu veröffentlichender Artikel
LOW
→ Archivartikel nachbebildern
Damit kann dieselbe GPU sowohl interaktiv als auch automatisch genutzt werden.
Bildjobs brauchen Abbruchgrenzen
Ein Auftrag sollte nicht unendlich oft neu generieren dürfen.
Zum Beispiel:
max_candidates = 4
max_retries = 2
Danach:
manual_review
Generative Systeme brauchen klare Endbedingungen.
Ein Bildservice kann verschiedene Operationen anbieten
Zum Beispiel:
text_to_image
image_to_image
inpainting
outpainting
upscale
Der Auftrag definiert den gewünschten Vorgang.
Text-to-Image-Auftrag
Prompt
↓
neues Bild
Image-to-Image-Auftrag
source_asset
+
Prompt
↓
neue Variante
Inpainting-Auftrag
source_asset
+
mask_asset
+
Prompt
↓
lokale Änderung
Outpainting-Auftrag
source_asset
+
neues Format
+
Prompt
↓
erweiterte Bildfläche
So kann eine einzige Plattform mehrere Bild-KI-Funktionen bereitstellen.
Assets sollten per ID verwaltet werden
Nicht jeder Workflow sollte große Binärdateien ständig hin und her kopieren.
Besser:
asset_id = 8172
Der Bildserver weiß:
Wo liegt die Datei?
Ein gemeinsamer Asset-Speicher
n8n
↓
asset_id
↓
Bildservice
↓
Asset Storage
Das erleichtert:
Versionierung,
Backups,
Zugriffsrechte.
Ein Bild kann mehrere Versionen besitzen
asset_4711
├── original
├── generated_v1
├── generated_v2
├── approved_master
└── web_version
Das ist wesentlich sauberer als:
final.jpg
final-neu.jpg
final-neu2.jpg
final-wirklich.jpg
Originale sollten erhalten bleiben
Insbesondere bei Image-to-Image oder Inpainting.
Original
→ unverändert archivieren
Generative Bearbeitungen:
→ neue Assets
So bleibt jederzeit nachvollziehbar, woher ein Bild stammt.
Der Asset-Datensatz kann die Generierung dokumentieren
Zum Beispiel:
{
"asset_id": "8172",
"parent_asset_id": "4711",
"operation": "image_to_image",
"style": "editorial-v3",
"status": "approved"
}
Zusätzlich können intern gespeichert werden:
Modellversion,
LoRA-Version,
Seed,
Prompt,
Format.
Nicht jeder Zwischenkandidat muss dauerhaft bleiben
Wenn für einen Artikel:
4 Kandidaten
erzeugt werden und:
1
veröffentlicht wird, können die anderen nach einer definierten Frist gelöscht werden.
Das spart erheblich Speicherplatz.
Bilddateien summieren sich schnell
Angenommen:
5 MB pro Rohbild
und:
4 Kandidaten pro Artikel
bei:
10.000 Artikeln
ergibt bereits theoretisch:
200.000 MB
≈
200 GB
nur für die vier Rohkandidaten.
Dazu kommen:
Master,
Webversion,
Thumbnails.
Asset-Lifecycle ist deshalb kein Nebenthema.
Modellfiles benötigen ebenfalls viel SSD-Speicher
Ein Bildserver kann besitzen:
mehrere Basismodelle,
mehrere Varianten,
LoRAs,
Upscaler,
Control-Modelle.
Die einzelnen Komponenten können viele Gigabyte belegen.
SSD ist für Modellladezeiten wichtig
Ein Modell wird zunächst von Massenspeicher gelesen.
SSD
↓
RAM
↓
VRAM
Eine schnelle SSD kann das Laden beschleunigen.
Während der eigentlichen Generierung ist anschließend vor allem:
RAM,
VRAM,
GPU
entscheidend.
Festplattengeschwindigkeit ersetzt keine schnelle GPU
Sie hilft hauptsächlich bei:
Start,
Modellwechsel,
Asset-Verarbeitung.
Die eigentliche Bildberechnung findet nicht einfach auf der SSD statt.
Viele Modelle gleichzeitig installiert heißt nicht viele Modelle gleichzeitig geladen
Auf der SSD können beispielsweise liegen:
Modell A
Modell B
Modell C
Im VRAM ist vielleicht nur:
Modell A
aktiv.
Beim Wechsel:
A entladen
↓
B laden
Das braucht Zeit.
Häufige Modellwechsel können den Durchsatz reduzieren
Wenn Auftrag 1 Modell A braucht.
Auftrag 2 Modell B.
Auftrag 3 wieder A.
Auftrag 4 wieder B.
Dann entsteht:
laden
entladen
laden
entladen
Das ist ineffizient.
Jobs können nach Modell gruppiert werden
Zum Beispiel:
Queue
↓
alle Jobs für Modell A
↓
Batch
danach:
Modell B
↓
dessen Jobs
Das kann bei größeren Batchsystemen sinnvoll sein.
Interaktive Jobs dürfen dabei nicht verhungern
Wenn ein Mensch wartet, sollte er nicht erst hinter:
500 Archivbildern
stehen.
Deshalb helfen erneut:
Prioritätsqueues.
Zwei GPUs können lokale Bild-KI erheblich vereinfachen
Ein Beispiel:
GPU 1
→ Sprachmodell
GPU 2
→ Bildmodell
Nun blockiert eine lange Bildgenerierung das LLM nicht.
Oder beide GPUs arbeiten an Bildjobs
Bildqueue
↓
Scheduler
├── GPU 1
└── GPU 2
Jeder Worker verarbeitet einen anderen Job.
Das kann den Durchsatz nahezu erhöhen, ohne ein einzelnes Modell über beide Karten verteilen zu müssen.
Zwei unabhängige Worker sind oft einfacher als ein verteiltes Modell
GPU 1
→ Bild A
GPU 2
→ Bild B
ist architektonisch einfacher als:
GPU 1 + GPU 2
→ gemeinsam Bild A
Solange das Modell vollständig auf eine einzelne GPU passt.
Eine große GPU kann trotzdem attraktiver sein
Wenn ein komplexer Workflow mehr VRAM benötigt als eine einzelne kleinere Karte besitzt:
Basismodell
+
LoRA
+
Control
+
hohe Auflösung
kann eine GPU mit mehr VRAM komfortabler sein.
Die Entscheidung hängt vom tatsächlichen Workflow ab.
Hardware sollte deshalb nicht nur anhand eines nackten Basismodells gekauft werden
Ein häufiger Fehler:
Modell X braucht ungefähr Y GB VRAM.
Produktionsworkflow enthält aber zusätzlich:
Referenzsteuerung,
LoRA,
Upscaling,
höhere Auflösung.
Dann ist der reale Speicherbedarf höher.
Der richtige Benchmark ist der echte Produktionsworkflow
Style-Preset
+
realistische Auflösung
+
reale Zusatzmodelle
+
typische Batchgröße
↓
VRAM messen
Das ist wesentlich aussagekräftiger als irgendein Einzelbenchmark.
Spitzenverbrauch ist besonders wichtig
Durchschnitt:
10 GB
Peak:
15,8 GB
auf einer:
16-GB-GPU
Dann ist kaum Reserve vorhanden.
Ein kleiner Parameterwechsel kann bereits einen Speicherfehler auslösen.
Reserve ist wertvoll
Ein produktives System sollte nicht dauerhaft so geplant sein:
VRAM 100 %
Eine gewisse Reserve erleichtert:
größere Prompts,
zusätzliche Komponenten,
Softwareänderungen.
Quantisierung kann auch bei Bild-KI relevant sein
Wie unter Quantisierung erklärt, können Modellgewichte teilweise mit geringerer Präzision gespeichert beziehungsweise verarbeitet werden.
Das kann:
VRAM sparen
und möglicherweise:
bestimmte Workflows auf kleinerer Hardware ermöglichen.
Quantisierung ist trotzdem nicht kostenlos
Mögliche Auswirkungen:
Qualität
Geschwindigkeit
Kompatibilität
müssen getestet werden.
Nicht jede Bildpipeline profitiert gleich stark.
Training benötigt andere Ressourcen als Inferenz
Ein LoRA zu trainieren ist eine andere Aufgabe als:
Bilder erzeugen.
Während des Trainings müssen zusätzliche Informationen gespeichert werden.
Dadurch kann der VRAM-Bedarf deutlich höher ausfallen.
Ein Bildserver muss deshalb nicht gleichzeitig Trainingsserver sein
Eine saubere Trennung kann lauten:
Produktionsserver
→ Bilder generieren
Trainingsumgebung
→ LoRAs entwickeln
Das kann sogar auf derselben Hardware zu unterschiedlichen Zeiten geschehen.
Nachts trainieren, tagsüber generieren
Zum Beispiel:
Tagsüber
→ Produktionsjobs
Nacht
→ LoRA-Training
Das kann für kleine Installationen vollkommen ausreichend sein.
Trainingsjobs sollten Produktionsjobs nicht unkontrolliert blockieren
Ein Training kann die GPU stundenlang auslasten.
Wenn gleichzeitig eine Website auf den Bildserver angewiesen ist, entstehen Probleme.
Deshalb:
Training
→ eigene Queue / Zeitfenster
Ein separater Trainingsworker ist bei größerem Bedarf komfortabler
GPU 1
→ Produktion
GPU 2
→ Training / Experimente
Dann können neue Style-LoRAs entwickelt werden, ohne laufende Generierung zu unterbrechen.
Lokale Bild-KI lässt sich hervorragend mit n8n verbinden
Ein Artikel wird fertiggestellt.
WordPress
↓
Webhook
↓
n8n
↓
Artikel analysieren
↓
Bildbriefing
↓
lokaler Bildserver
Dann:
Bildkandidaten
↓
Prüfung
↓
Freigabe
↓
WordPress-Mediathek
Das verbindet nahezu alle bisherigen KI-Themen.
Das Sprachmodell kann das Bildbriefing erstellen
Zum Beispiel:
{
"concept": "Ein KI-Modell wird auf einem eigenen Server betrieben.",
"visual_type": "technical_concept",
"composition": "Server rechts, freie Fläche links",
"format": "hero"
}
Das Style-System ergänzt die Markenregeln
visual_type
↓
Style Registry
↓
Preset
Daraus entsteht:
Bildbriefing
+
Style-Preset
↓
Bildauftrag
Der Bildserver erzeugt Kandidaten
Zum Beispiel:
Seed A
Seed B
Seed C
Seed D
Technische Prüfung
Normale Software prüft:
Datei vorhanden?
Format korrekt?
Auflösung korrekt?
Datei lesbar?
Semantische Prüfung
Ein Vision-Modell kann prüfen:
Passt das Bild zum Briefing?
Enthält es unerwünschten Text?
Ist das Hauptmotiv sichtbar?
Styleprüfung
Passt es zur Referenzgalerie?
Menschliche Endauswahl
Für wichtige Headerbilder kann anschließend einfach:
eine kleine Galerie
angezeigt werden.
Ein Klick entscheidet.
Automatisierung bedeutet nicht zwingend Vollautomatisierung
Das ist besonders bei Bild-KI wichtig.
Ein guter Workflow kann:
95 Prozent der Arbeit automatisch erledigen
und:
den letzten visuellen Entscheid beim Menschen lassen.
Das kann bereits enorm viel Zeit sparen.
Bilder können trotzdem vollständig automatisch veröffentlicht werden
Bei weniger kritischen Anwendungsfällen vielleicht:
interne Illustrationen,
große Archivmengen,
automatisch erzeugte Thumbnails.
Dann sollten allerdings strengere automatische Qualitätsregeln existieren.
Ein Confidence-Wert allein genügt nicht
Ein Vision-Modell sagt:
98 % passend
Das ist keine Garantie.
Automatische Veröffentlichung sollte sich daher möglichst auf:
klar definierte risikoarme Bildtypen
beschränken.
Bild-KI benötigt andere Qualitätsprüfungen als Text-KI
Bei Text prüfen wir beispielsweise:
Fakten,
Schema,
Quellen.
Bei Bildern eher:
Motivtreue
Anatomie
Geometrie
Stilkonsistenz
unerwünschte Schrift
Markenfehler
Jede Bildklasse braucht eigene Kriterien.
Ein technisches Erklärbild hat andere Anforderungen als ein Stimmungsbild
Technisches Erklärbild:
Beziehungen müssen verständlich sein
Stimmungsbild:
Atmosphäre darf wichtiger sein
Produktfotografie:
Produkt muss exakt sein
Menschenbild:
Anatomie und Identität können kritisch sein
Deshalb sollte das System den Bildtyp kennen.
visual_type kann genau das ausdrücken
Zum Beispiel:
technical_concept
editorial_people
product_background
abstract
Jeder Typ erhält:
Preset,
Reviewregeln,
Referenzen.
Eine lokale Plattform kann damit sehr viele unterschiedliche Aufgaben abdecken
Image Service
│
├── Text-to-Image
├── Image-to-Image
├── Inpainting
├── Outpainting
├── Upscaling
├── Style-LoRA
└── Character-LoRA
Die Anwendungen sehen nur eine gemeinsame API.
Sicherheit bleibt notwendig
Ein lokaler Bildserver nimmt möglicherweise:
Prompts,
Uploads,
Masken,
Referenzbilder
entgegen.
Das sind Eingaben.
Eine öffentliche Schnittstelle darf deshalb nicht ungeschützt erreichbar sein.
Offener Bildserver kann missbraucht werden
Ein Angreifer könnte:
tausende Bildjobs erzeugen,
GPU vollständig auslasten,
SSD mit Bildern füllen,
riesige Uploads senden.
Deshalb braucht die API:
Authentifizierung
Rate Limits
Uploadlimits
Joblimits
Interner Betrieb ist einfacher
n8n
↓
internes Netzwerk
↓
Bildserver
Dann muss der Bilddienst gar nicht öffentlich erreichbar sein.
Wie im Artikel über den lokalen KI-Server beschrieben, kann ein Reverse Proxy beziehungsweise VPN die Zugriffsschicht absichern.
Uploads sollten als untrusted data behandelt werden
Ein Bildserver sollte beispielsweise prüfen:
Dateityp,
Dateigröße,
Dimensionen.
Nicht einfach:
jeden beliebigen Upload
blind verarbeiten.
EXIF und andere Metadaten können sensible Informationen enthalten
Ein Foto kann möglicherweise enthalten:
Aufnahmedatum,
Kameradaten,
Standortinformationen.
Wenn solche Metadaten nicht benötigt werden, sollte der Workflow bewusst entscheiden, ob sie erhalten bleiben.
Referenzbilder können besonders sensibel sein
Zum Beispiel:
Fotos realer Personen,
private Wohnräume,
unveröffentlichte Produkte.
Lokale Bild-KI kann verhindern, dass diese Bilder für die eigentliche Generierung an einen externen Anbieter geschickt werden.
Aber nur, wenn tatsächlich die gesamte Pipeline lokal bleibt.
Lokal ist nicht automatisch vollständig lokal
Beispiel:
lokales Bildmodell
↓
Cloud-Vision-Prüfung
Dann verlässt das Bild trotzdem die eigene Infrastruktur.
Oder:
lokaler Bildserver
↓
Cloud-Speicher
Auch das ist ein externer Datenfluss.
Die gesamte Pipeline muss betrachtet werden
Upload
↓
Speicher
↓
Bildmodell
↓
Vision Review
↓
Backup
↓
Veröffentlichung
Erst dann kann beurteilt werden, wo Daten tatsächlich verarbeitet werden.
Logs können ebenfalls Bildinformationen verraten
Vielleicht wird nicht das Bild selbst geloggt.
Aber:
prompt = "Foto von Kunde X im Wohnzimmer..."
kann bereits sensibel sein.
Protokollierung sollte deshalb bewusst gestaltet werden.
Ein Bildserver braucht Monitoring
Mindestens interessant:
GPU-Auslastung
VRAM
Temperatur
RAM
CPU
SSD
Zusätzlich:
Queue-Länge
Generierungsdauer
Fehlerrate
Bilder pro Stunde
Das zeigt, wo der Engpass liegt.
Ein GPU-Upgrade ist nicht immer die Lösung
Queue langsam.
Vielleicht liegt es an:
häufigen Modellwechseln.
Oder:
sehr hoher Auflösung.
Oder:
langsamer Nachbearbeitung.
Oder:
zu vielen Kandidaten.
Monitoring verhindert, dass Hardware auf Verdacht gekauft wird.
Ein typischer Performance-Datensatz pro Job
model
style
width
height
duration
peak_vram
status
Damit können Presets verglichen werden.
Bilder pro Stunde können wirtschaftlich interessant sein
Angenommen:
Preset A:
60 Bilder/Stunde
Preset B:
25 Bilder/Stunde
B liefert allerdings deutlich höhere Freigabequote.
Dann muss nicht automatisch A besser sein.
Entscheidend ist die Zahl brauchbarer Bilder
Beispiel:
A:
60 generiert
20 freigegeben
B:
25 generiert
22 freigegeben
Dann ist B trotz niedrigerer Rohgeschwindigkeit möglicherweise produktiver.
Eine gute Kennzahl
freigegebene Bilder
pro GPU-Stunde
Das verbindet:
Qualität
und:
Performance.
Kosten lokaler Bild-KI bestehen weiterhin
Keine Rechnung pro Bild bedeutet nicht:
kostenlos.
Es entstehen:
Hardware
Strom
SSD
Wartung
Arbeitszeit
Der Vorteil ist:
Die Grenzkosten zusätzlicher Generierungen können bei vorhandener Hardware sehr niedrig werden.
Cloud ist bei geringer Nutzung oft einfacher
Du erzeugst:
zehn Bilder im Monat.
Dann kann ein eigener GPU-Server wirtschaftlich unnötig sein.
Lokal wird bei wiederkehrender Nutzung interessanter
Zum Beispiel:
täglich hunderte Bilder
oder:
sensible Bilder
oder:
eigene LoRA-Infrastruktur
oder:
enge n8n-Integration
Dann entstehen neben reinen Kosten auch operative Vorteile.
Hybrid kann die beste Lösung sein
Zum Beispiel:
Standardillustrationen
→ lokal
außergewöhnlich anspruchsvolle Einzelbilder
→ externer Dienst
Oder:
sensible Referenzbilder
→ nur lokal
generische Bildideen
→ flexible Auswahl
Die Architektur muss nicht dogmatisch sein.
Ein Model Router kann auch Bildmodelle routen
Bildauftrag
↓
visual_type
↓
Router
├── lokales Modell A
├── lokales Modell B
└── erlaubter externer Dienst
Die Entscheidung kann deterministisch erfolgen.
Sensible Daten sollten nicht vom Modell selbst geroutet werden
Nicht:
KI entscheidet,
ob Bild vertraulich ist
wenn eine harte Geschäftsregel möglich ist.
Besser:
asset_classification
↓
confidential?
├── ja → local_only
└── nein → policy routing
Lokale Bild-KI kann offline betrieben werden
Wenn:
Modell,
Runtime,
Referenzen,
LoRAs,
gesamte Verarbeitung
bereits lokal vorhanden sind, kann die eigentliche Generierung ohne Internetverbindung stattfinden.
Das ist für bestimmte Umgebungen attraktiv.
Offline bedeutet trotzdem Wartungsaufwand
Modelle aktualisieren.
Software aktualisieren.
Neue LoRAs einspielen.
Backups erstellen.
Ein vollständig isoliertes System braucht dafür eigene Prozesse.
Modelle kennen keine aktuellen visuellen Fakten automatisch
Ein lokales Bildmodell wird nicht dadurch aktuell, dass es lokal läuft.
Wenn ein aktuelles reales Produkt exakt dargestellt werden soll, braucht es:
Referenzbilder
oder:
echte Produktassets.
Ein Modellupdate ist etwas anderes als ein Wissensupdate über einen konkreten Gegenstand.
Generative Bildmodelle sind keine Produktdatenbank
Auch lokal gilt:
Prompt:
"Produkt X"
garantiert nicht:
exakte reale Darstellung
Für konkrete Marken- und Produktkommunikation bleibt die Verwendung echter Assets häufig sicherer.
Ein lokaler Bildserver kann ein sehr gutes Kreativwerkzeug sein
Die vielleicht wichtigste Stärke liegt nicht darin, jedes finale Bild völlig autonom zu erstellen.
Sondern:
sehr schnell Varianten zu erzeugen.
Idee
↓
4 Varianten
↓
Auswahl
↓
Weiterbearbeitung
Damit wird visuelle Exploration enorm beschleunigt.
Besonders Referenzbilder profitieren von lokaler Iteration
Du kannst:
Referenzstärke verändern,
Seed ändern,
LoRA wechseln,
Prompt anpassen
und immer wieder neu testen, ohne für jeden Versuch einen separaten externen API-Aufruf planen zu müssen.
Dasselbe gilt für LoRA-Entwicklung
LoRA v1
↓
Testbilder
↓
Training verbessern
↓
LoRA v2
↓
Testbilder
Ein lokaler Server kann diese Iterationsschleife stark vereinfachen.
Ein sinnvoller Einstieg muss trotzdem klein bleiben
Nicht sofort:
5 Basismodelle
+
30 LoRAs
+
4 GPUs
+
3 Queues
+
automatische Style Evals
Ein guter Start:
1 Basismodell
↓
1 Style-Preset
↓
1 GPU
↓
1 API
Das reicht, um eine robuste Basis zu bauen.
Danach eine LoRA
Basismodell
+
Style-LoRA
testen.
Danach Automation
n8n
↓
Bildserver
Danach Assetverwaltung
Asset-ID
↓
Versionen
Danach automatisches Review
Bild
↓
Vision-Prüfung
Danach mehrere Modelle oder GPUs
Nur wenn echte Last entsteht.
So wächst das System aus realen Anforderungen.
Eine einfache lokale Architektur
┌───────────────┐
│ n8n │
└───────┬───────┘
↓
┌───────────────┐
│ Image API │
└───────┬───────┘
↓
┌───────────────┐
│ Job Queue │
└───────┬───────┘
↓
┌───────────────┐
│ Image Worker │
└───────┬───────┘
↓
GPU
Dazu:
Asset Storage
und:
Style Registry
Mehr braucht ein kleines produktives System zunächst nicht.
Eine etwas größere Architektur
Clients
↓
Image API
↓
┌───────┴───────┐
↓ ↓
Interactive Batch Queue
Queue
↓ ↓
┌─────┴────────────────┐
↓ ↓
GPU 1 GPU 2
↓ ↓
Interactive Worker Batch Worker
Dazu:
Style Registry
Asset Storage
Monitoring
Jetzt kann dasselbe System interaktiv und automatisiert arbeiten.
Eine Multi-Brand-Architektur
Website A ─┐
Website B ─┼→ n8n
Website C ─┘
↓
Image Service
↓
Style Registry
├── Style A
├── Style B
└── Style C
↓
GPU
Das ist besonders interessant, wenn viele Websites dieselbe technische Infrastruktur nutzen, aber visuell eigenständig bleiben sollen.
Die Style Registry kann LoRAs verwalten
Style A
→ LoRA A
Style B
→ LoRA B
Style C
→ LoRA C
Dabei muss nicht jedes Bildmodell dauerhaft gleichzeitig geladen sein.
Eine Character Registry kann daneben existieren
character_id
↓
Referenzset
↓
Character-LoRA
Dann können Style und Figur unabhängig kombiniert werden.
character = anna
style = family-editorial
Der Bildserver baut daraus die technische Konfiguration.
Das ergibt eine modulare Bildplattform
Prompt
→ Was passiert?
Style
→ Wie sieht es aus?
Character
→ Wer ist zu sehen?
Reference
→ Welche aktuelle visuelle Vorlage?
Mask
→ Wo darf verändert werden?
Diese Trennung ist der Schlüssel zu komplexen, aber verständlichen Bildworkflows.
Was du dir über lokale Bild-KI merken solltest
Lokale Bild-KI bedeutet, dass die eigentliche Bildgenerierung auf eigener beziehungsweise selbst kontrollierter Hardware ausgeführt wird.
Das einfachste System lautet:
Prompt
↓
lokales Bildmodell
↓
GPU
↓
Bild
Ein produktiver Bilddienst erweitert dies um eine API.
n8n / Anwendung
↓
Image API
↓
Bildmodell
↓
GPU
Damit kann dieselbe GPU von mehreren Anwendungen genutzt werden.
Ein Bildworkflow besteht dabei häufig aus mehr als nur einem Basismodell.
Zusätzlich können verwendet werden:
LoRA
Referenzbilder
Control-Komponenten
Inpainting
Upscaling
Diese Komponenten beeinflussen den realen Ressourcenbedarf.
Deshalb sollte Hardware nicht nur anhand der Größe eines nackten Basismodells geplant werden.
Der tatsächliche Test lautet:
Produktionspreset
+
realistische Auflösung
+
LoRA
+
Referenzsteuerung
+
typische Batchgröße
↓
VRAM und Geschwindigkeit messen
VRAM ist dabei besonders wichtig.
Mehr Auflösung und mehr gleichzeitig verarbeitete Bilder können den Speicherbedarf deutlich erhöhen.
höhere Auflösung
→ mehr Rechenaufwand
größere Batchgröße
→ mehr Parallelität
→ mehr Speicher
Bei begrenztem VRAM können Modelle oder Komponenten teilweise in normalen RAM ausgelagert werden.
Das kann Generierung ermöglichen, aber Geschwindigkeit kosten.
Für automatisierte Bildproduktion ist eine Queue ausgesprochen sinnvoll.
Bildjobs
↓
Queue
↓
GPU Worker
Damit überlasten nicht 50 gleichzeitig fertige n8n-Workflows eine einzelne GPU.
Jobs können außerdem priorisiert werden.
interaktiv
→ hohe Priorität
aktueller Content
→ normal
Archiv
→ niedrig
Das macht eine gemeinsame GPU wesentlich besser nutzbar.
Der Bildserver sollte außerdem nicht nur Dateien erzeugen.
Er sollte Assets verwalten.
Original
↓
Varianten
↓
freigegebenes Master
↓
Webversion
Jede Datei erhält idealerweise eine eindeutige Asset-ID.
Damit lassen sich:
Versionen,
Prompts,
Seeds,
Style-Versionen,
LoRAs
nachvollziehen.
Für konsistente Bildserien kann eine zentrale Style Registry verwendet werden.
style_id
↓
Basismodell
↓
Style-LoRA
↓
Referenzset
↓
Parameter
Der Contentworkflow muss diese technischen Details nicht kennen.
Er sendet beispielsweise nur:
{
"style": "editorial",
"concept": "Ein KI-Server verarbeitet Bildanfragen."
}
Der Bildservice übernimmt die technische Übersetzung.
Das ist besonders attraktiv, wenn mehrere Marken oder Websites dieselbe Infrastruktur verwenden.
Website A
→ Style A
Website B
→ Style B
Website C
→ Style C
Alle nutzen:
denselben Bildserver
aber nicht zwangsläufig:
dieselbe Bildsprache
Genau darin liegt ein großer Vorteil eigener Infrastruktur.
Ein zweiter wichtiger Vorteil ist die Datenkontrolle.
Private:
Fotos,
Referenzbilder,
unveröffentlichte Produkte
müssen für die eigentliche Generierung nicht zwingend an einen externen Modellanbieter gesendet werden.
Aber nur, wenn die gesamte Pipeline lokal bleibt.
lokales Modell
+
Cloud Review
=
nicht vollständig lokal
Darum müssen auch:
Speicherung,
Vision-Prüfung,
Backups,
Logs
betrachtet werden.
Lokale Bild-KI bedeutet außerdem mehr Verantwortung.
Ein Bildserver braucht wie jeder andere Dienst:
Authentifizierung
Rate Limits
Uploadlimits
Monitoring
Backups
Updates
Er sollte nicht ungeschützt öffentlich im Internet erreichbar sein.
Für einen kleinen Einstieg genügt dennoch eine ausgesprochen überschaubare Architektur:
1 GPU
↓
1 Basismodell
↓
1 Style-Preset
↓
1 Image API
↓
n8n
Erst danach sollten bei Bedarf hinzukommen:
LoRAs
↓
Referenzsets
↓
Asset Registry
↓
Queues
↓
automatische Bildprüfung
↓
weitere GPUs
Damit entsteht keine unnötig komplizierte KI-Infrastruktur.
Sondern ein Bildsystem, das mit seinem tatsächlichen Nutzen wächst.
Und genau hier schließt sich unser Bild-KI-Cluster:
Bild-KI
↓
Text-to-Image
↓
Image-to-Image
↓
Inpainting
↓
Referenzbilder
↓
konsistente Bildstile
↓
LoRA
↓
lokale Bild-KI
Wir haben damit nicht nur erklärt, wie ein einzelnes Bild erzeugt wird.
Sondern den kompletten Weg bis zu einem automatisierbaren eigenen Bildproduktionssystem aufgebaut.