vLLM auf Kubernetes deployen: KServe & Multi-GPU 2026

Pexon Consulting | 11 Min. Lesezeit | 14.07.2026

TL;DR

vLLM auf Kubernetes heißt: die Inference-Engine als skalierbaren Dienst betreiben, statt als Einzelprozess auf einer GPU. Der 2026er-Stack dafür ist KServe für Autoscaling und Canary, LeaderWorkerSet für Multi-Node-Modelle und Tensor-Parallelismus über mehrere GPUs. Pexon Consulting baut diese Serving-Schicht produktiv, mit Modell-Caching, GPU-Scheduling und OpenAI-kompatibler API.

Warum Einzel-GPU-Betrieb im Produktivbetrieb nicht reicht

Die kurze Antwort: Ein vllm serve auf einer GPU ist ein Prototyp, kein Dienst. Es skaliert nicht, es überlebt keinen Knotenausfall, und ein Modell, das nicht auf eine einzelne GPU passt, läuft gar nicht erst. Sobald mehrere Teams dieselbe Inferenz nutzen oder ein 70B-Modell im Spiel ist, brauchen Sie Orchestrierung.

Genau das liefert Kubernetes: Autoscaling nach Last, automatisches Neu-Scheduling bei Ausfall, und über LeaderWorkerSet die Verteilung eines Modells über mehrere GPU-Knoten. Wie der reine vllm serve-Prozess mit den richtigen Produktions-Flags aussieht, haben wir im Beitrag zu vLLM produktiv deployen beschrieben. Dieser Artikel setzt eine Ebene höher an: die Serving-Schicht auf Kubernetes.

Unsere klare Position: Fangen Sie nicht mit einem selbstgebauten Deployment-Manifest an. KServe nimmt Ihnen Autoscaling, Traffic-Splitting und die OpenAI-kompatible Route ab, die Sie sonst mühsam selbst bauen. Das Rad ist erfunden.

Der 2026er-Stack: KServe, LeaderWorkerSet, llm-d

vLLM ist 2026 die Standard-Inference-Engine, aber die Orchestrierung entscheidet über den Produktivbetrieb. Drei Bausteine sollten Sie kennen:

1. KServe (seit 2025 CNCF-graduated) umhüllt die Engine mit Kubernetes-nativen Funktionen: Autoscaling inklusive Scale-to-Zero, Canary-Deployments, Traffic-Splitting und Multi-Model-Endpoints. Für die meisten Fälle der richtige Einstieg.
2. LeaderWorkerSet (LWS) ist die Kubernetes-API für verteilte Inferenz über mehrere Knoten. Nötig, sobald ein Modell nicht auf die GPUs eines einzelnen Knotens passt. Typisch sind mindestens zwei Knoten mit je 8 GPUs.
3. llm-d ist die verteilte Serving-Schicht darunter, die KServe über eine LLMInferenceService anbinden kann, wenn Sie Prefill und Decode trennen wollen.

Für ein einzelnes, gut passendes Modell reicht KServe mit der vLLM-Runtime. Multi-Node über LWS lohnt erst, wenn die Modellgröße es erzwingt. Wir raten davon ab, gleich mit Multi-Node zu starten, wenn ein Knoten mit vier GPUs das Modell trägt. Verteilte Inferenz kostet Komplexität und NCCL-Debugging, das Sie nur zahlen sollten, wenn Sie es brauchen.

# vLLM als KServe InferenceService, 4 GPUs mit Tensor-Parallelismus
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: llama-70b
spec:
  predictor:
    model:
      modelFormat: { name: vLLM }
      args:
        - --tensor-parallel-size=4        # muss der GPU-Zahl pro Pod entsprechen
        - --gpu-memory-utilization=0.90   # KV-Cache maximal ausnutzen
      resources:
        limits:
          nvidia.com/gpu: "4"
    minReplicas: 0     # Scale-to-Zero, wenn keine Anfragen kommen
    maxReplicas: 4

Die Stolperfallen, die jeden ersten Rollout treffen

Nicht das YAML ist das Problem, sondern vier Details, die jeden ersten Produktiv-Rollout kosten. Der Reihe nach:

Der geteilte Speicher (shm) muss groß genug für die NCCL-Kommunikation zwischen den GPUs sein, mindestens 32 GB, sonst bricht Multi-GPU-Inferenz mit kryptischen Fehlern ab. Die Modellgewichte gehören auf ein persistentes Volume, sonst lädt jeder Pod-Neustart 5 bis 10 Minuten lang das Modell neu herunter. Die Startup-Probe muss dem Modell 2 bis 10 Minuten Ladezeit zugestehen, je nach Größe, sonst killt Kubernetes den Pod, bevor er bereit ist. Und tensor-parallel-size muss exakt der GPU-Zahl pro Pod entsprechen, sonst startet vLLM nicht.

# Die drei Fixes, die jeder produktive vLLM-Pod braucht
spec:
  volumes:
    - name: dshm
      emptyDir: { medium: Memory, sizeLimit: 32Gi }   # NCCL braucht großen /dev/shm
    - name: model-cache
      persistentVolumeClaim: { claimName: vllm-models }  # Gewichte einmal cachen
  containers:
    - name: kserve-container
      startupProbe:
        httpGet: { path: /health, port: 8000 }
        failureThreshold: 60           # bis zu 10 Min Ladezeit erlauben
        periodSeconds: 10

Mit Prefix-Cache-aware Routing lässt sich die Ausgabe-Rate deutlich steigern: Auf vier GPUs mit einem 70B-Modell sind rund 3-fache Tokens pro Sekunde und die halbe Zeit bis zum ersten Token drin. Das ist kein exotisches Tuning, sondern ein Flag, das Sie einschalten sollten.

Was das an GPUs und Kosten braucht

Ehrlich: Die GPUs sind der Kostentreiber, nicht Kubernetes. Ein 70B-Modell in guter Latenz braucht vier moderne GPUs, ein kleineres 8B-Modell läuft auf einer. Der Cluster-Unterbau ist im Vergleich günstig. Wichtiger als die reine Rechnung ist die Auslastung: Mit Scale-to-Zero zahlen Sie keine GPU-Stunden, wenn nachts keine Anfragen kommen.

Welche Engine überhaupt die günstigste pro Token ist, hängt vom Workload ab. Den Vergleich haben wir im Beitrag SGLang vs vLLM durchgerechnet. Für die Kubernetes-Ebene gilt: Erst die Engine und Modellgröße festlegen, dann die GPU-Zahl pro Pod, dann das Autoscaling. In dieser Reihenfolge, nicht umgekehrt. Wir setzen die komplette Serving-Schicht als 6-Wochen-Pilot auf, damit Sie an einer echten Last sehen, was die Plattform trägt. Was dazu an Hardware und Betrieb gehört, bündeln wir unter KI-Infrastruktur.

Häufig gestellte Fragen

Was kostet vLLM auf Kubernetes?

Der Kostentreiber sind die GPUs, nicht der Cluster. Ein 70B-Modell braucht rund vier moderne GPUs, ein 8B-Modell eine. Mit Scale-to-Zero über KServe zahlen Sie keine GPU-Stunden bei fehlender Last. Der Kubernetes-Unterbau selbst ist im Vergleich ein kleiner Posten.

Brauche ich KServe oder reicht ein normales Deployment?

Ein normales Deployment geht, aber Sie bauen Autoscaling, OpenAI-Route und Canary dann selbst. KServe liefert das fertig und ist seit 2025 CNCF-graduated. Für die meisten Fälle ist KServe der schnellere Weg, ein eigenes Manifest lohnt nur bei sehr speziellen Anforderungen.

Wann brauche ich LeaderWorkerSet statt eines einzelnen Pods?

Sobald ein Modell nicht auf die GPUs eines einzelnen Knotens passt. LeaderWorkerSet verteilt die Inferenz über mehrere Knoten, typisch zwei Knoten mit je acht GPUs. Passt das Modell auf einen Knoten mit vier GPUs, bleiben Sie bei einem Pod mit Tensor-Parallelismus.

vLLM auf Kubernetes oder gemanagt über einen Anbieter?

Kommt auf die Datenlage an. Wer Datensouveränität braucht oder hohe, konstante Last hat, fährt mit eigenem vLLM auf Kubernetes günstiger und kontrollierter. Für sporadische Last ohne Compliance-Druck kann ein gemanagter Endpunkt einfacher sein.

Wie vermeide ich lange Ladezeiten bei Pod-Neustarts?

Cachen Sie die Modellgewichte auf einem persistenten Volume, statt sie bei jedem Start neu herunterzuladen. Das spart 5 bis 10 Minuten pro Neustart. Zusätzlich muss die Startup-Probe genug Zeit fürs Modellladen zulassen, sonst killt Kubernetes den Pod zu früh.

Nächster Schritt

Wenn Sie vLLM produktiv auf Kubernetes bringen wollen, schauen wir uns Ihre Modelle, GPU-Ausstattung und Lastprofile an und setzen die Serving-Schicht an einer echten Anwendung auf.

Verwandte Themen