Stable Diffusion auf Kubernetes: Self-Hosting fuer KI-Bildgenerierung

TL;DR

• Self-Hosting von Stable Diffusion auf Kubernetes gibt volle Kontrolle ueber Daten, Modelle und Kosten -- keine Abhaengigkeit von externen APIs
• Mindestanforderung: NVIDIA GPU mit 12 GB VRAM (fuer SDXL empfohlen: 24 GB), NVIDIA Device Plugin im Cluster
• AUTOMATIC1111 ist ideal fuer den Einstieg, ComfyUI fuer komplexe Workflows und API-Integration
• Mit Horizontal Pod Autoscaler und GPU-Metriken skaliert die Loesung automatisch bei steigendem Bedarf
• Persistent Volumes fuer Modelle und Outputs sind Pflicht -- Basismodelle allein benoetigen 5-10 GB

Warum Stable Diffusion selbst hosten?

Externe Dienste wie Midjourney oder DALL-E sind bequem, aber sie haben drei Nachteile: Jeder Prompt und jedes generierte Bild verlassen das Unternehmen. Die Kosten skalieren linear mit dem Volumen. Und Fine-Tuning auf eigene Markenassets ist nicht moeglich.

Self-Hosting auf Kubernetes loest alle drei Probleme. Prompts und Outputs bleiben im eigenen Cluster. Bei hohem Volumen sinken die Kosten pro Bild auf einen Bruchteil der API-Preise. Und mit LoRA oder DreamBooth lassen sich Modelle auf eigene Produkte, Stile oder Markenidentitaeten trainieren.

Wann lohnt sich Self-Hosting?

Ab einem Volumen von ca. 500 Bildern pro Monat wird Self-Hosting in der Regel guenstiger als API-basierte Dienste. Bei Unternehmen mit strengen Datenschutzanforderungen kann es unabhaengig vom Volumen die einzig sinnvolle Option sein.

Architektur im Ueberblick

Die Kernkomponenten einer Self-Hosted Stable Diffusion Installation auf Kubernetes:

1. GPU-Worker-Nodes mit NVIDIA-GPUs und installiertem NVIDIA Device Plugin
2. Stable Diffusion Pod mit Web-UI (AUTOMATIC1111 oder ComfyUI)
3. Persistent Volume Claims fuer Modelle (ReadWriteMany) und Outputs
4. Ingress Controller fuer den Zugriff auf das Web-UI mit TLS
5. Monitoring via Prometheus + DCGM Exporter fuer GPU-Metriken

Das NVIDIA Device Plugin registriert GPUs als schedulable Resource (nvidia.com/gpu) im Cluster. Der Kubernetes Scheduler weist Pods mit GPU-Requests automatisch den passenden Nodes zu.

GPU-Anforderungen und Hardware-Vergleich

Fuer den Einstieg reicht eine RTX 4090 mit 24 GB VRAM. Fuer Produktivbetrieb mit mehreren parallelen Nutzern oder Batch-Generierung empfehlen sich A100 oder L40S. Details zur GPU-Auswahl finden sich im Artikel GPU und CUDA Cores im Vergleich.

Deployment: Schritt fuer Schritt

1. NVIDIA Device Plugin installieren

Das Device Plugin ist Voraussetzung dafuer, dass Kubernetes GPUs erkennt und zuweisen kann.

# NVIDIA GPU Operator installieren (empfohlen -- kuemmert sich um Treiber + Plugin)
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

helm install gpu-operator nvidia/gpu-operator \
  --namespace gpu-operator \
  --create-namespace \
  --set driver.enabled=true \
  --set toolkit.enabled=true \
  --set devicePlugin.enabled=true

# Verifizieren, dass GPUs erkannt werden
kubectl get nodes -o json | jq '.items[].status.allocatable["nvidia.com/gpu"]'

2. Persistent Volumes fuer Modelle und Outputs

Modelle sind gross (SDXL Base: ~6.5 GB, Refiner: ~6 GB, LoRAs: 50-200 MB). Ein performanter Storage-Backend ist wichtig fuer schnelle Ladezeiten.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sd-models
  namespace: ai-workloads
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd    # NVMe-basiert empfohlen
  resources:
    requests:
      storage: 100Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sd-outputs
  namespace: ai-workloads
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 50Gi

Hinweise zu performantem und DSGVO-konformem Storage finden sich unter Kubernetes Storage Loesungen.

3. Stable Diffusion Deployment

Das folgende Deployment nutzt AUTOMATIC1111 als Web-UI. Fuer ComfyUI aendern sich im Wesentlichen das Image und die Startargumente.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: stable-diffusion
  namespace: ai-workloads
  labels:
    app: stable-diffusion
spec:
  replicas: 1
  selector:
    matchLabels:
      app: stable-diffusion
  template:
    metadata:
      labels:
        app: stable-diffusion
    spec:
      containers:
        - name: webui
          image: ghcr.io/your-org/sd-webui:latest
          ports:
            - containerPort: 7860
              name: http
          env:
            - name: CLI_ARGS
              value: "--listen --port 7860 --xformers --api"
          resources:
            requests:
              cpu: "2"
              memory: "8Gi"
              nvidia.com/gpu: 1
            limits:
              cpu: "4"
              memory: "16Gi"
              nvidia.com/gpu: 1
          volumeMounts:
            - name: models
              mountPath: /app/models
            - name: outputs
              mountPath: /app/outputs
          readinessProbe:
            httpGet:
              path: /sdapi/v1/options
              port: 7860
            initialDelaySeconds: 60
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /sdapi/v1/options
              port: 7860
            initialDelaySeconds: 120
            periodSeconds: 30
      nodeSelector:
        nvidia.com/gpu.present: "true"
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      volumes:
        - name: models
          persistentVolumeClaim:
            claimName: sd-models
        - name: outputs
          persistentVolumeClaim:
            claimName: sd-outputs
---
apiVersion: v1
kind: Service
metadata:
  name: stable-diffusion
  namespace: ai-workloads
spec:
  selector:
    app: stable-diffusion
  ports:
    - port: 80
      targetPort: 7860
      protocol: TCP

Wichtige Details:

• --xformers aktiviert Memory-Optimierungen und reduziert den VRAM-Verbrauch um ca. 30%
• --api stellt die REST-API bereit, ueber die andere Systeme Bilder generieren koennen
• Die readinessProbe verhindert, dass Traffic an den Pod gesendet wird, bevor das Modell geladen ist (dauert 30-90 Sekunden)
• nodeSelector stellt sicher, dass der Pod nur auf GPU-Nodes geplant wird

AUTOMATIC1111 vs. ComfyUI: Welches UI fuer welchen Zweck?

Fuer Teams, die Bilder hauptsaechlich manuell erstellen (Marketing, Design), ist AUTOMATIC1111 der bessere Einstieg. Wenn die Bildgenerierung in bestehende Systeme integriert oder automatisiert werden soll, bietet ComfyUI mit seinem Workflow-System mehr Flexibilitaet.

Skalierung und Ressourcenmanagement

Horizontale Skalierung

Bei steigendem Bedarf koennen mehrere Stable Diffusion Pods parallel laufen. Der Horizontal Pod Autoscaler kann auf GPU-Metriken (via DCGM Exporter und Prometheus Adapter) oder auf Custom Metrics wie die Laenge einer Request-Queue reagieren.

Voraussetzung: Genug GPU-Nodes im Cluster. Fuer dynamische Skalierung auf Cloud-Infrastruktur empfiehlt sich der Cluster Autoscaler, der neue GPU-Nodes automatisch provisioniert. Mehr dazu unter HPA und automatische Skalierung.

Modell-Management

Modelle sollten nicht im Container-Image eingebettet sein. Stattdessen werden sie ueber Persistent Volumes bereitgestellt. Das hat zwei Vorteile: Container-Images bleiben klein (< 5 GB statt 15+ GB), und Modelle koennen aktualisiert werden, ohne das Image neu zu bauen.

Ein initContainer kann beim Pod-Start pruefen, ob die benoetigten Modelle vorhanden sind, und fehlende Modelle von einem internen Modelserver oder S3-kompatiblen Storage herunterladen.

Monitoring

Fuer Stable Diffusion auf Kubernetes sind folgende Metriken relevant:

• GPU Utilization (%): Zeigt, wie ausgelastet die GPU ist. Unter 50% deutet auf Ueberdimensionierung hin.
• GPU Memory Used (MB): VRAM-Verbrauch. Nahe am Limit fuehrt zu Out-of-Memory-Fehlern.
• Generation Latency (ms): Zeit pro generiertem Bild. Abhaengig von Modell, Aufloesung und Step Count.
• Queue Length: Wartende Requests. Steigt dauerhaft, sind mehr Replicas noetig.
• Pod Restarts: Haeufige Restarts deuten auf OOM-Kills oder fehlerhafte Health Checks.

Prometheus mit dem NVIDIA DCGM Exporter liefert die GPU-Metriken. Ein Grafana-Dashboard macht sie sichtbar. Details zum Monitoring-Setup finden sich unter GPU Monitoring in Kubernetes.

Sicherheit

Da Stable Diffusion Web-UIs standardmaessig keine Authentifizierung mitbringen, muessen zusaetzliche Massnahmen getroffen werden:

• Ingress mit Authentifizierung: Nutzen Sie OAuth2 Proxy oder Basic Auth am Ingress Controller
• NetworkPolicies: Beschraenken Sie den Zugriff auf den Stable Diffusion Service auf autorisierte Namespaces
• RBAC: ServiceAccounts fuer Stable Diffusion Pods sollten minimale Rechte haben
• Image Scanning: Container-Images regelmaessig auf Vulnerabilities pruefen (Trivy, Grype)

Weitere Sicherheitsmassnahmen beschreibt der Artikel zu Kubernetes Security Hardening.

Haeufige Probleme und Loesungen

Pod startet, aber GPU wird nicht erkannt. Pruefen Sie, ob der NVIDIA Device Plugin DaemonSet auf dem Node laeuft (kubectl get pods -n gpu-operator). Haeufige Ursache: Inkompatible Treiberversionen.

Out of Memory beim Laden grosser Modelle. SDXL benoetigt ca. 6.5 GB VRAM. Mit --xformers oder --medvram laesst sich der Verbrauch reduzieren. Alternativ: GPU mit mehr VRAM einsetzen.

Langsame Ladezeiten beim Pod-Start. Modelle von NFS oder langsamen Volumes zu laden dauert Minuten. Nutzen Sie lokale NVMe-SSDs oder bereiten Sie Modelle in einem Init-Container vor.

Web-UI reagiert nicht mehr nach laengerer Nutzung. Memory Leaks in einigen Extensions. Setzen Sie eine livenessProbe, die den Pod bei Nichterreichbarkeit automatisch neu startet.

Kosten: Self-Hosting vs. API-Dienste

Eine grobe Rechnung fuer ein Team, das ca. 2.000 Bilder pro Monat generiert:

Bei hoeherem Volumen (10.000+ Bilder/Monat) verschiebt sich der Break-Even auf wenige Monate. Zusaetzlich: Die Moeglichkeit zum Fine-Tuning und die volle Datenkontrolle lassen sich nicht in Euro beziffern, sind aber fuer viele Unternehmen der eigentliche Treiber.

Fazit

Stable Diffusion auf Kubernetes zu betreiben ist kein Hexenwerk, erfordert aber solide Grundlagen: funktionierende GPU-Integration, durchdachtes Storage-Konzept und sinnvolles Monitoring. Der Aufwand lohnt sich, wenn Datenkontrolle, Fine-Tuning-Moeglichkeiten oder hohes Generierungsvolumen eine Rolle spielen.

Der empfohlene Einstieg: Ein einzelner GPU-Node, AUTOMATIC1111 als Pod, und ein Persistent Volume fuer Modelle. Wenn das laeuft und der Bedarf steigt, kommen Skalierung und Automatisierung dazu.

Wenn Sie Unterstuetzung beim Setup oder bei der Integration in bestehende Workflows benoetigen, melden Sie sich gerne unter /kontakt.