vLLM auf Kubernetes produktiv: Checkliste production-stack 2026

Pexon Consulting | 10 Min. Lesezeit | 30.08.2026

TL;DR

vLLM ist 2026 der De-facto-Standard für Self-Hosted-Inferenz. Auf Kubernetes gehört der production-stack dazu – sonst bleibt es ein Single Point of Failure. Diese Checkliste zeigt Minimal-Setup vs. Helm-Referenz, Tensor Parallel, Prefix-Cache und wann KServe oder llm-d nötig sind. Der Sprung vom einzelnen Endpoint zum vLLM-Betrieb auf Kubernetes ist die Betriebsfrage, nicht die Engine-Wahl. Stand: vLLM v0.28.0.

Warum vLLM 2026 der Prod-Default ist

Wer Self-Hosted-LLMs auf GPUs betreibt, landet fast immer bei derselben Engine. vLLM (Version v0.28.0, Release 26.08.2026, 90.468 GitHub-Stars, Stand 30.08.2026, Quelle: vllm-project/vllm) liefert Continuous Batching, PagedAttention und eine OpenAI-kompatible API. Hugging Face TGI liegt seit Ende 2025 im Maintenance-Modus: Bugfixes ja, Features nein. Inference Endpoints von Hugging Face laufen inzwischen standardmäßig auf vLLM. Die Marktrichtung ist damit klar.

Der Sprung vom POC zum Betrieb ist trotzdem die eigentliche Lücke. Ein vllm serve auf einer GPU beweist, dass das Modell antwortet. Es beweist nicht, dass der Dienst einen Knotenausfall überlebt, mehrere Teams bedient oder prüfbar dokumentiert ist. Genau dort scheitern viele interne Assistenten: PoC ok, Prod-Last, Multi-User, Ausfallrisiko.

Unsere Position: vLLM wählen ist die einfache Entscheidung. Den Day-2-Betrieb auf Kubernetes so aufzusetzen, dass er Audits und Last aushält, ist die schwere. Wer den Engine-Vergleich noch offen hat, findet den Abgleich mit SGLang in SGLang vs. vLLM. Die reine Serve-Config mit Produktions-Flags steht in der Anleitung zum produktiven vLLM-Deploy. Dieser Text setzt eine Ebene höher an: Cluster, production-stack und Checkliste.

Minimal vs. production-stack

Zwei Setups dominieren 2026. Beide nutzen vLLM. Nur eines ist als Produktivdienst gedacht.

Minimal ist ein Deployment (oder StatefulSet) mit einem Container vllm/vllm-openai:v0.28.0, GPU-Request, Shared Memory und einer Service-Route. Das reicht für einen PoC, ein internes Team und niedrige Gleichzeitigkeit. Es bleibt ein Single Point of Failure: ein Pod, ein Node, oft ein Modell-Cache ohne klare Wiederanlauf-Strategie.

production-stack ist die Helm-Referenz der Maintainer (vllm-project/production-stack, ca. 2.500 Stars, Stand 30.08.2026). Ziel: clusterweite Bereitstellung, Routing, Caching und Betriebsartefakte, die über „ein Manifest und Hoffnung“ hinausgehen. Prefix-Cache-aware Routing, mehrere Replicas und saubere Trennung von Modellgewichten gehören dazu. Wer von Ollama kommt und jetzt echte Serving-Last hat, landet hier – nicht bei einem zweiten Einzelprozess.

# Orientierungsbeispiel: production-stack per Helm (Repo der Maintainer)
helm repo add vllm https://vllm-project.github.io/production-stack
helm repo update
helm install vllm-stack vllm/vllm-stack 
  --namespace vllm --create-namespace 
  -f values-prod.yaml

values-prod.yaml ist der eigentliche Vertrag: Modell, tensor-parallel-size, GPU-Limits, Replica-Zahl, Shared Memory, Startup-Probes und Auth. Ohne diese Werte bleibt Helm nur ein anderes YAML.

Tensor Parallel praktisch: Das Modell wird über N GPUs eines Pods geteilt. --tensor-parallel-size muss exakt der GPU-Zahl pro Replica entsprechen und die Attention-Heads teilen. Typisch: 2 oder 4 GPUs für 70B-Klasse. 3 GPUs sind oft tot. NCCL braucht ausreichend /dev/shm (oft ≥32Gi), sonst stirbt Multi-GPU mit kryptischen Fehlern.

Wann reicht Minimal, wann Stack? Minimal reicht, wenn ein Team, ein Modell und keine SLA-Anforderung. production-stack (oder KServe darüber) braucht ihr, sobald mehrere Nutzer parallel kommen, Ausfall toleriert werden muss oder ihr Prefix-Cache und Routing wollt. llm-d und Prefill/Decode-Trennung kommen erst, wenn Durchsatz und Modellgröße das erzwingen – nicht am Tag 1.

Checkliste: vLLM produktiv auf Kubernetes

Abhaken, bevor ihr „Prod“ sagt. Stand geprüft: 30.08.2026, Engine v0.28.0.

1. Image pinnen: vllm/vllm-openai:v0.28.0 (oder -cu129), kein floating latest.
2. Auth: API-Key oder Gateway davor; nie offenen Port ohne Bearer.
3. GPU + shm: nvidia.com/gpu gesetzt; /dev/shm groß genug für TP/NCCL.
4. Tensor Parallel: tensor-parallel-size = GPU-Zahl pro Pod; Heads teilbar.
5. Speicher-Tuning: --gpu-memory-utilization um 0,90 starten; nach Lasttest anpassen.
6. Kontext kappen: --max-model-len bewusst setzen, sonst OOM im KV-Cache.
7. Modell-Cache: PVC oder Image-Cache; kein 10-Minuten-Download bei jedem Restart.
8. Probes: Startup-Probe mit Minuten-Budget; Readiness erst nach /health ok.
9. Replicas / HA: mindestens 2 Replicas oder klar dokumentierter SPOF-Akzeptanz.
10. Observability: Token/s, TTFT, KV-Cache-Hit, GPU-Util, Queue-Tiefe.
11. Gateway: Rate-Limit, Routing, Team-Keys (z. B. LiteLLM) vor dem Engine-Port.
12. Nachweis: Versionspin, Change-Log, Runbook Restart/Failover – auditfähig.

Wer Punkte 1-8 hat, betreibt Inferenz. Wer 9-12 fehlt, hat noch einen POC im Cluster-Kostüm.

Vergleichstabelle: Stufe, Setup, Wann genug, Wann Pexon-Betrieb

Prüfung der Artefakte und Versionsstände: 30.08.2026.

Die Tabelle ist Absicht: Zahlen und Grenzen mit Datum. Durchsatz-Faktoren „2-24× vs. TGI“ nur zitieren, wenn ihr die jeweilige Benchmark-Quelle mit Modell und Batch mitführt – sonst bleibt es Marketing.

Nach der Einordnung: Wenn Stufe 2 oder 3 euer Ziel ist und ihr den Betrieb nicht intern stemmt, ist der AI-Readiness-Scan-Pfad über den Hub KI-Plattform-Betrieb (990 EUR) der kurze Einstieg – Cluster, GPU und Inferenz-Pfad prüfen, ohne gleich einen Retainer zu kaufen.

Was Pexon konkret macht

Wir verkaufen keinen vagen KI-Workshop. Unter dem Claim Betrieb in Bankqualität. KI auf Kubernetes. Offene Standards. machen wir auf eurem Cluster messbare Dinge:

1. Ist-Aufnahme: GPU-Nodes, Treiber, Device Plugin, vorhandene vLLM-/Ollama-POCs.
2. Zielbild: Minimal, production-stack oder KServe – eine Stufe, kein Overengineering.
3. Manifeste/Helm-Values: Image-Pin, TP, shm, Probes, PVC, Secrets.
4. Gateway-Schicht: Team-Keys, Rate-Limits, Logging (LiteLLM o. ä.), ohne Vendor-Lock auf die Engine.
5. Observability: die Metriken aus der Checkliste, Alarmierung auf TTFT und Fehlerquote.
6. Nachweis-Paket: Versionen, Runbooks, Change-Pfad – tauglich für Kundenfragebögen (DORA/NIS2-nah), ohne „wir sind eine Bank“ zu behaupten.
7. Übergabe oder Managed Day-2: Festpreis-Korridor für Betrieb, nicht 24/7-Fantasie.

Kauf-Claim bleibt Bankqualität und Managed. Dieses Stück liefert Technik-Autorität und den Pfad zur KI-Plattform auf dem Cluster. Gebaut und betrieben. Gehört euch.

Was das nicht ist

Das ist keine Fine-Tuning-Anleitung und kein Modell-Zoo. Wir erklären nicht, wie ihr LoRA trainiert oder welches 70B-Modell „das Beste“ ist. Es ist auch kein Versprechen eines 24/7-NOC und kein Ersatz für euren Platform-Owner. vLLM auf Kubernetes produktiv zu betreiben heißt: Serving, HA, GPU-Betrieb und Nachweis. Wer „KI-Beratung“ sucht, ohne Cluster und Day-2 zu wollen, ist hier falsch. Wer den PoC schon hat und den SPOF loswerden will, ist richtig.

FAQ

vLLM oder Ollama für Produktion?

Ollama ist stark für lokalen Dev und Einzelanfragen. Unter paralleler Last gewinnt vLLM durch Continuous Batching und PagedAttention. Produktion mit mehreren Nutzern und SLA: vLLM (oder vergleichbare Serving-Engines). Ollama behalten für Laptops und schnelle Demos.

Wann reicht ein Deployment, wann KServe?

Ein Deployment reicht für Stufe 1 (ein Team, stabile Last, akzeptierter SPOF). KServe lohnt, wenn ihr Autoscaling, Canary und Scale-to-Zero wollt. production-stack der Maintainer ist die Brücke dazwischen: mehr Betrieb als ein nacktes Deployment, oft ohne sofort volle KServe-Komplexität.

Was bedeutet Tensor Parallel praktisch?

Ein großes Modell wird über mehrere GPUs im selben Pod zerlegt. Mehr GPUs = mehr VRAM und oft mehr Durchsatz, aber NCCL-Kommunikation und strikte Größenwahl. Multi-Node (LeaderWorkerSet) ist die nächste Stufe und teurer in der Fehlersuche.

Was kostet GPU-Inferenz grob pro Monat?

Dominanz hat die GPU-Miete bzw. Abschreibung, nicht die Engine-Lizenz (vLLM ist Apache 2.0). Richtwert: eine H100-Klasse in der Cloud oft vierstellig EUR pro Monat; On-Prem CapEx plus Strom und Betrieb. Ohne Auslastung und Token-Profil ist jede Zahl Marketing. Deshalb zuerst Last und Modellgröße klären, dann Hardware.

Brauche ich llm-d?

Nur wenn Prefill/Decode-Trennung und sehr hohe Last euch zwingen. Für die meisten Mittelstands- und SaaS-Setups reichen vLLM + production-stack oder KServe. llm-d ist kein Default-Tag-1.

Wie frisch ist dieser Stand?

Engine: vLLM v0.28.0 (26.08.2026). Stars: 90.468 am 30.08.2026 via GitHub API. production-stack: ca. 2.500 Stars. Image-Tags und Helm-Charts vor jedem Rollout gegen die Upstream-Releases prüfen.

Wohin mit dem Gateway und dem Nachweis?

Inferenz ohne Gateway und ohne Betriebsnachweis bleibt ein Experiment. Der Hub dafür ist KI-Plattform-Betrieb – offene Schicht auf eurem Cluster, gekoppelt an Cluster-Betrieb in Bankqualität.

Nächster Schritt

PoC läuft, Prod-Last droht: Checkliste oben gegen euren Cluster legen. Lücken bei HA, Probes, Cache oder Nachweis? Dann den KI-Plattform-Betrieb Hub (AI-Readiness-Scan-Pfad, 990 EUR). Technik klären, Betrieb und Nachweis mitdenken – nicht erst nach dem ersten Ausfall.