Pexon Consulting | 11 Min. Lesezeit | 01.07.2026
TL;DR
vLLM Deployment heißt: ein LLM mit vllm serve als OpenAI-kompatiblen Endpoint auf eigener GPU-Hardware betreiben. Pexon Consulting (80 MA, Deutschland, Azure/AWS/GCP) baut das produktiv – inklusive Tensor-Parallelismus, GPU-Scheduling und DSGVO-Betrieb. In der Praxis: 2-24x höherer Durchsatz als HuggingFace TGI, rund 0,022 EUR pro Inferenz-Request.
Was vLLM Deployment produktiv bedeutet
vLLM Deployment ist das Ausrollen der Inferenz-Engine vLLM als dauerhaft laufenden HTTP-Dienst, der Prompts entgegennimmt und Tokens zurückgibt – kompatibel zur OpenAI-API, sodass bestehender Code ohne Umbau weiterläuft. vLLM ist 2026 der De-facto-Standard für Self-Hosted-LLM-Betrieb: 85.000 GitHub-Stars (Stand: 30.06.2026, vllm-project/vllm), aktuelle Version v0.24.0 vom 29.06.2026.
Der Kern ist PagedAttention: der Speicher für Attention-Keys und -Values wird in feste Blöcke aufgeteilt und on-demand belegt – wie virtuelles Memory-Paging. Dazu Continuous Batching, das neue Anfragen sofort in den laufenden Batch schiebt, statt auf einen vollen Batch zu warten. Ergebnis: 85-92% GPU-Auslastung statt 68-74% bei TGI.
Ein wichtiger Kontext-Wechsel Ende 2025: HuggingFace hat TGI in den Maintenance-Modus gesetzt – seit Dezember 2025 nur noch Bugfixes, keine neuen Features. HuggingFace Inference Endpoints laufen jetzt standardmäßig auf vLLM. Wenn Sie gerade zwischen Engines evaluieren, ist die Marktrichtung damit ziemlich eindeutig – den direkten Engine-Vergleich schlüsseln wir weiter unten in den verwandten Themen auf.
Der erste Schritt: vLLM serve mit Produktions-Flags
Für einen belastbaren Betrieb reicht vllm serve modellname nicht – die Defaults sind für lokale Experimente gedacht, nicht für einen Multi-User-Endpoint. Vier Flags entscheiden über Stabilität: --tensor-parallel-size, --gpu-memory-utilization, --max-model-len und --api-key. Ohne die letzten beiden holen Sie sich OOM-Abstürze und einen offenen, ungeschützten Endpoint.
# vLLM produktiv starten: OpenAI-kompatibler Server mit Auth
# Modell: Qwen3-32B, verteilt über 2 GPUs (tensor-parallel)
vllm serve Qwen/Qwen3-32B-Instruct
--tensor-parallel-size 2 # Modell auf 2 GPUs aufteilen (muss GPU-Anzahl treffen)
--gpu-memory-utilization 0.90 # 90% VRAM für vLLM, Rest für CUDA-Kontext + Fragmentierung
--max-model-len 16384 # Kontextfenster kappen -> begrenzt KV-Cache, verhindert OOM
--max-num-seqs 128 # max. gleichzeitige Sequenzen im Batch
--dtype auto # FP8/BF16 automatisch je nach Hardware
--api-key "$VLLM_API_KEY" # Bearer-Token-Auth (NIE ohne in Produktion)
--host 0.0.0.0 --port 8000Zwei Fallstricke, die wir bei fast jedem Kunden sehen: --tensor-parallel-size muss eine Zweierpotenz sein, die die Attention-Head-Anzahl des Modells sauber teilt – 3 GPUs für ein Standardmodell funktionieren nicht. Und --gpu-memory-utilization über 0,92 zu drehen, um noch ein bisschen mehr KV-Cache herauszuquetschen, rächt sich unter Last mit Fragmentierungs-OOMs. Unsere Empfehlung: 0,90 als Startwert, erst nach Lasttest nach oben schrauben.
Sobald der Server läuft, testen Sie ihn wie jede andere OpenAI-kompatible API – kein SDK-Umbau nötig:
# Endpoint gegen die OpenAI-kompatible Chat-Completions-Route testen
curl http://localhost:8000/v1/chat/completions
-H "Content-Type: application/json"
-H "Authorization: Bearer $VLLM_API_KEY"
-d '{
"model": "Qwen/Qwen3-32B-Instruct",
"messages": [
{"role": "system", "content": "Du bist ein genauer Assistent."},
{"role": "user", "content": "Fasse vLLM in einem Satz zusammen."}
],
"max_tokens": 128,
"temperature": 0.2
}'Läuft dieser Call sauber durch, haben Sie einen funktionierenden Inferenz-Endpoint. Das ist der Moment, in dem die meisten POCs stehenbleiben – und genau da fängt die eigentliche Arbeit erst an. Diese Arbeit ist der Sprung vom einzelnen Endpoint zum KI-Plattform-Betrieb auf Kubernetes, nicht zum Chatbot-Use-Case.
Deployment im Cluster: Kubernetes statt Einzel-GPU
Sobald mehr als ein Team den Endpoint nutzt, brauchen Sie Kubernetes – ein einzelner vllm serve-Prozess auf einer GPU ist kein Produktivbetrieb, sondern ein Single Point of Failure. Für den Einstieg reicht ein schlankes Deployment-Manifest, das die GPU als Ressource anfordert und den Server als Pod betreibt.
# vllm-deployment.yaml - vLLM als Kubernetes-Deployment mit GPU-Request
apiVersion: apps/v1
kind: Deployment
metadata:
name: vllm-qwen3
labels:
app: vllm-qwen3
spec:
replicas: 1
selector:
matchLabels:
app: vllm-qwen3
template:
metadata:
labels:
app: vllm-qwen3
spec:
containers:
- name: vllm
image: vllm/vllm-openai:v0.24.0 # gepinnte Version, kein :latest in Prod
args:
- "--model=Qwen/Qwen3-32B-Instruct"
- "--tensor-parallel-size=2"
- "--gpu-memory-utilization=0.90"
- "--max-model-len=16384"
env:
- name: VLLM_API_KEY
valueFrom:
secretKeyRef: # API-Key aus K8s-Secret, nie im Manifest
name: vllm-secrets
key: api-key
ports:
- containerPort: 8000
resources:
limits:
nvidia.com/gpu: 2 # 2 GPUs anfordern (passend zu tensor-parallel-size)
readinessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 120 # Modell-Load dauert -> großzügig setzenFür echten Cluster-Betrieb greifen wir nicht zu selbstgebauten Manifesten, sondern zum offiziellen vLLM production-stack – dem einzigen von den vLLM-Maintainern gepflegten K8s-Referenz-Setup. Es liefert per Helm-Chart Pods, Services, Autoscaler und Dashboards in einem Rutsch. Der entscheidende Unterschied zu KServe oder vanilla-vLLM: prefix-aware Routing schickt Anfragen an die Instanz, die den passenden KV-Cache schon hält, und LMCache teilt den Cache über Instanzen hinweg. Die Maintainer nennen 3-10x niedrigere Latenz und 2-5x höheren Durchsatz gegenüber Einzel-Instanzen.
Autoscaling läuft über KEDA (ab production-stack v0.1.11), direkt im Helm-Chart konfigurierbar. Wer schon eine Internal Developer Platform betreibt, hängt vLLM als weiteren Golden Path ein – die Muster dafür haben wir im Aufbau eines internen KI-Plattform-Stacks beschrieben.
Kosten: Was Self-Hosted vLLM wirklich kostet
Die ehrliche Antwort zuerst: Self-Hosting lohnt sich erst ab konstant hoher Auslastung, sonst ist die API günstiger. Eine H100 kostet bei spezialisierten Anbietern 1,49-1,99 USD pro GPU-Stunde, bei europäischen Clouds wie OVH, Scaleway oder Hetzner 3,20-4,60 EUR, bei AWS rund 11 EUR pro H100-Stunde. Der Kauf-Break-Even eines eigenen H100-Servers liegt inklusive Infrastruktur bei 18+ Monaten Dauerbetrieb nahe 100% Auslastung.
Aussagekräftiger als GPU-Stunden ist die Kosten-pro-Request-Rechnung. Bei einem unserer Kunden – eine RAG-Anwendung mit rund 80.000 Requests pro Tag – lagen die Kosten bei etwa 0,034 EUR pro Request: 0,022 EUR Inferenz, 0,008 EUR Vektor-Retrieval, 0,004 EUR Logging und Observability. Rechnen Sie in diesen drei Größen – Kosten pro 1.000 Output-Tokens, pro abgeschlossener Anfrage, pro aktivem Nutzer und Monat – dann wird die Make-or-Buy-Entscheidung sauber statt bauchgesteuert.
Unsere klare Empfehlung: Starten Sie gemietet. Kaufen Sie erst, wenn die Auslastung über Monate stabil über 60% liegt und Datensouveränität ein hartes Kriterium ist. Wer vorher 120k EUR Capex bindet, zahlt für Leerlauf. Zu Hardware-Sizing und Betrieb haben wir die Grundlagen der KI-Infrastruktur zusammengestellt.
Worauf Sie beim produktiven Betrieb achten sollten
Ein vLLM-Endpoint, der im Demo läuft, ist noch kein produktiver Dienst. Fünf Punkte trennen POC von Betrieb – und genau die werden im Tutorial-Enthusiasmus gern übersprungen:
- Version pinnen. Kein
:latestim Container. vLLM released fast wöchentlich (v0.24.0 am 29.06.2026) – ein ungepinntes Image bricht Ihnen irgendwann still die Konfiguration. - Auth über den API-Key hinaus.
--api-keyist ein Bearer-Token, kein Berechtigungskonzept. Für Multi-Team-Betrieb kommt ein Gateway davor, das pro Team routet, Rate-Limits setzt und Kosten zuordnet. Das Muster dafür steht in unserer Anleitung zum Multi-Modell-Routing mit LiteLLM. - KV-Cache und
max-model-lenaufeinander abstimmen. Ein zu großzügiges Kontextfenster frisst KV-Cache-Speicher und drückt den Durchsatz. Messen, nicht raten. - Observability von Tag eins. Ohne Metriken zu Latenz, Token-Durchsatz und KV-Cache-Hit-Rate fliegen Sie blind. vLLM exportiert Prometheus-Metriken – nutzen Sie sie.
- Engine bewusst wählen. Für reine Kostenoptimierung auf H100 kann SGLang enger sein (~16.200 vs. ~12.500 Tokens/Sekunde bei Llama 3.1 8B). Den GPU-Kosten-Vergleich haben wir separat durchgerechnet (siehe verwandte Themen) – für die meisten Enterprise-Setups gewinnt vLLM trotzdem über Ökosystem und Modell-Abdeckung.
Häufig gestellte Fragen
Was kostet ein produktives vLLM Deployment?
Kommt auf die Auslastung an. Die GPU-Miete startet bei 1,49-1,99 USD pro H100-Stunde bei spezialisierten Anbietern, europäische Clouds liegen bei 3,20-4,60 EUR. Pro Request landen Sie in einer RAG-Anwendung bei rund 0,022 EUR reiner Inferenz. Ein eigener H100-Server (~120k EUR Capex) rechnet sich erst nach 15-18 Monaten Dauerbetrieb.
vLLM oder OpenAI-API – was ist günstiger?
Bei niedriger oder schwankender Last ist die OpenAI-API günstiger, weil Sie keine GPU-Grundlast bezahlen. Self-Hosted vLLM lohnt sich ab konstant hoher Auslastung (grob über 60% über Monate) oder wenn Datensouveränität und DSGVO ein hartes Kriterium sind – dann verlassen keine Daten Ihre Infrastruktur.
Ist vLLM OpenAI-kompatibel?
Ja. vLLM stellt einen OpenAI-kompatiblen Server bereit (/v1/chat/completions, /v1/completions, /v1/embeddings). Bestehender Code, der gegen die OpenAI-API geschrieben ist, läuft nach Umstellung der Base-URL und des API-Keys ohne weiteren Umbau.
Wie viele GPUs braucht mein Modell?
Faustregel für 2026: Ein 70B-Modell in FP8 passt auf eine einzelne H100 80GB, in FP16 brauchen Sie zwei H100 mit --tensor-parallel-size 2. Der Wert muss eine Zweierpotenz sein und die Attention-Head-Anzahl des Modells sauber teilen. Kleinere Modelle (7-14B) laufen auf einer GPU.
Warum nicht bei HuggingFace TGI bleiben?
HuggingFace hat TGI Ende 2025 in den Maintenance-Modus gesetzt – seit Dezember 2025 nur noch Bugfixes, keine neuen Features. vLLM liefert 2-24x höheren Durchsatz je nach Last und nutzt durch PagedAttention 19-27% weniger GPU-Speicher. HuggingFace Inference Endpoints laufen selbst inzwischen standardmäßig auf vLLM.
Nächster Schritt
Ein POC auf einer GPU ist in einem Tag gebaut. Der belastbare Produktivbetrieb – HA, Autoscaling, GPU-Scheduling, Observability, DSGVO – ist die Arbeit dahinter. Genau die machen wir planbar in sechs Wochen. Wie dieser Betrieb konkret aussieht, von Autoscaling über GPU-Scheduling bis Observability, zeigt unsere Seite zu vLLM im Managed Betrieb.
Verwandte Themen
