Braucht Ihre KI-Plattform Kubernetes?

TL;DR

In den meisten mittelständischen Installationen: nein. Ein Compose-Stack auf zwei Servern mit einem Reverse-Proxy davor trägt eine Plattform für mehrere hundert Nutzer. Der Umzug lohnt sich bei vier konkreten Auslösern — Mehrknoten-GPU, mehrere Teams, echte Hochverfügbarkeit, oder ein bereits vorhandener Cluster.

Der Stack, mit dem fast alle starten

Und der überraschend weit trägt:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    depends_on: [litellm, postgres]
    restart: unless-stopped

  litellm:
    image: ghcr.io/berriai/litellm:main-stable
    volumes: ["./config.yaml:/app/config.yaml:ro"]
    restart: unless-stopped

  vllm:
    image: vllm/vllm-openai:latest
    command: >
      --model /models/qwen3-30b-a3b --served-model-name standard
      --max-model-len 32768 --gpu-memory-utilization 0.90
    volumes: ["/models:/models:ro"]
    deploy:
      resources:
        reservations:
          devices: [{driver: nvidia, count: 1, capabilities: [gpu]}]
    restart: unless-stopped

  postgres:
    image: postgres:17
    volumes: ["pgdata:/var/lib/postgresql/data"]
    restart: unless-stopped

  qdrant:
    image: qdrant/qdrant:latest
    volumes: ["qdrant:/qdrant/storage"]
    restart: unless-stopped

volumes: { pgdata: , qdrant: }

Fünf Dienste, eine Datei, ein Server mit einer GPU. Das bedient in der Praxis 100 bis 300 Nutzer mit moderater Gleichzeitigkeit — die Grenze liegt bei der GPU, nicht bei der Orchestrierung.

Wir sagen das deutlich, weil in Architekturdiskussionen regelmäßig das Gegenteil behauptet wird: Wenn dieser Stack Ihre Anforderung erfüllt, ist Kubernetes einzuführen kein Fortschritt, sondern eine zusätzliche Betriebslast ohne Gegenwert.

Die vier Auslöser für den Umzug

Erstens: Das Modell braucht mehrere Knoten. Solange alle GPUs in einem Server stecken, reicht Compose. Sobald ein Modell über Server hinweg verteilt werden muss — Pipeline-Parallelität bei sehr großen Modellen —, brauchen Sie eine Orchestrierung, die Prozesse über Knoten koordiniert. Wie das aussieht, steht im Beitrag zu GPU-Clustern unter Kubernetes.

Zweitens: Mehrere Teams brauchen getrennte Umgebungen. Wenn Entwicklung, Test und Produktion parallel laufen sollen, mit unterschiedlichen Modellen und getrennten Berechtigungen, wird Compose unübersichtlich. Namensräume und Ressourcenkontingente sind genau dafür gebaut.

Drittens: Ausfallzeit ist nicht akzeptabel. Bei Compose bedeutet ein Modellwechsel oder ein Update einen Neustart des Dienstes. Wenn die Plattform in einer Schichtfertigung rund um die Uhr verfügbar sein muss, brauchen Sie rollierende Aktualisierung mit mehreren Instanzen.

Aber prüfen Sie diese Anforderung kritisch. "Hochverfügbar" ist in Anforderungslisten billig und im Betrieb teuer. Eine interne Wissenssuche, die nachts um drei für vier Minuten nicht erreichbar ist, verursacht keinen Schaden.

Viertens: Es läuft ohnehin schon. Wenn im Haus ein Cluster steht, den ein Team betreibt, ist die Rechnung eine andere. Dann ist Kubernetes der Weg des geringeren Widerstands, weil Sicherung, Überwachung, Zertifikate und Bereitstellung bereits geregelt sind.

Was beim Umzug tatsächlich Arbeit macht

Nicht die Dienste. Die sind in beiden Welten Container mit denselben Umgebungsvariablen. Drei andere Dinge:

GPU-Zuweisung. Sie brauchen den NVIDIA Device Plugin oder den GPU Operator im Cluster, und die Knoten müssen entsprechend gekennzeichnet sein. Eine GPU wird als ganze Einheit zugewiesen — eine Aufteilung geht nur über MIG oder Time-Slicing, mit jeweils eigenen Nachteilen. Welche Karte welche Klasse abdeckt, steht im GPU-Vergleich für LLM-Inferenz.

spec:
  containers:
    - name: vllm
      image: vllm/vllm-openai:latest
      resources:
        limits:
          nvidia.com/gpu: 1
      # Modellgewichte per PVC, nicht ins Image backen —
      # sonst haben Sie ein 40-GB-Container-Image
      volumeMounts:
        - {name: models, mountPath: /models, readOnly: true}
      # vLLM braucht beim Start Minuten zum Laden der Gewichte
      startupProbe:
        httpGet: {path: /health, port: 8000}
        failureThreshold: 60
        periodSeconds: 10
  nodeSelector:
    nvidia.com/gpu.product: NVIDIA-RTX-PRO-6000-Blackwell

Die startupProbe mit hohem Schwellenwert ist der Punkt, an dem die meisten Erstumzüge scheitern. Ein Modell mit 60 GB Gewichten braucht Minuten zum Laden. Eine Bereitschaftsprüfung mit Standardwerten tötet den Pod, bevor er fertig ist — und startet ihn neu, in einer Schleife.

Zustandsbehaftete Dienste. PostgreSQL und die Vektordatenbank brauchen persistente Speicherbereiche und eine Sicherungsstrategie, die zum Cluster passt. Das ist der Teil, der bei Compose durch ein Verzeichnis auf der Platte gelöst war und in Kubernetes eine Entscheidung über Speicherklassen verlangt.

Modellgewichte. 60 GB Modelldateien gehören nicht ins Container-Image. Sie brauchen einen gemeinsamen Speicher, auf den alle GPU-Knoten zugreifen — ein PVC mit ReadOnlyMany oder ein Objektspeicher, aus dem beim Start geladen wird. Beides hat Nachteile, und beides muss vor dem Umzug entschieden werden.

Der Zwischenweg, den viele übersehen

Zwischen einer Compose-Datei und einem Kubernetes-Cluster liegt eine Option, die im Mittelstand oft die richtige ist: Compose auf zwei bis drei Servern, mit einem Reverse-Proxy davor, der auf die GPU-Server verteilt.

        [Traefik / nginx]
         /            \
   [GPU-Server 1]  [GPU-Server 2]     ← je ein vLLM
         \            /
     [Server 3: Postgres, Qdrant, Gateway, Oberfläche]

Das gibt Ihnen Lastverteilung über GPUs und überlebt den Ausfall eines GPU-Servers — die beiden Dinge, für die die meisten Häuser Kubernetes einführen wollen. Ohne Cluster, ohne Speicherklassen, ohne zusätzliches Betriebswissen.

Was es nicht gibt: automatische Wiederherstellung bei Knotenausfall, rollierende Aktualisierung ohne Unterbrechung, deklarative Zustandsverwaltung. Wenn Sie diese drei nicht brauchen, brauchen Sie kein Kubernetes.

Unsere Empfehlung für Häuser bis etwa 500 Plattform-Nutzer ohne bestehenden Cluster: diesen Zwischenweg gehen. Die eingesparte Betriebskomplexität ist mehr wert als die gewonnene Eleganz.

Häufig gestellte Fragen

Ab wann braucht eine KI-Plattform Kubernetes?

Wenn eines von vier Kriterien zutrifft: Ein Modell muss über mehrere Server verteilt werden, mehrere Teams brauchen getrennte Umgebungen, Ausfallzeiten sind fachlich nicht akzeptabel, oder es existiert bereits ein betreuter Cluster. Trifft keines zu, trägt ein Compose-Stack auf ein bis drei Servern eine Plattform für mehrere hundert Nutzer.

Kann Docker Compose GPUs nutzen?

Ja, über die Ressourcenreservierung im Dienst mit dem NVIDIA-Treiber als Backend. Die Zuweisung ist einfacher als in Kubernetes, weil keine Geräte-Plugins und Knotenkennzeichnungen nötig sind. Die Grenze liegt darin, dass Compose an einen Server gebunden ist — GPUs auf mehreren Rechnern lassen sich damit nicht als ein Pool betreiben.

Was ist beim Umzug einer LLM-Plattform auf Kubernetes am aufwendigsten?

Die Bereitstellung der Modellgewichte und die Startzeiten. Modelldateien von mehreren zehn Gigabyte gehören nicht ins Container-Image, sondern auf einen gemeinsam nutzbaren Speicher — diese Entscheidung sollte vor dem Umzug fallen. Und die Startprüfungen brauchen deutlich höhere Schwellenwerte als üblich, weil das Laden der Gewichte Minuten dauert.

Lohnt sich Kubernetes für eine Plattform mit 200 Nutzern?

In der Regel nicht, wenn kein Cluster vorhanden ist. Bei 200 Nutzern mit üblicher Gleichzeitigkeit ist die GPU der begrenzende Faktor, nicht die Orchestrierung — und die löst Kubernetes nicht. Der Betriebsaufwand für einen eigenen Cluster übersteigt den Nutzen, solange nicht mehrere Teams oder mehrere GPU-Server im Spiel sind.

Wie verteile ich Last über mehrere GPU-Server ohne Kubernetes?

Über einen Reverse-Proxy oder das LLM-Gateway selbst. Beide können mehrere Modellendpunkte als Gruppe führen und Anfragen verteilen, inklusive Ausweichen bei Ausfall eines Servers. Das deckt Lastverteilung und einfache Ausfallsicherheit ab — was fehlt, ist die automatische Wiederherstellung, die ein Cluster bietet.

Der nächste Schritt

Prüfen Sie die vier Auslöser gegen Ihre tatsächliche Lage, nicht gegen die geplante. Wenn keiner zutrifft, bleiben Sie bei Compose und investieren die freigewordene Zeit in die Datenanbindung — dort liegt der Nutzen, nicht in der Orchestrierung. Bei der Entscheidung schauen wir gern mit.