vLLM-Selfhosting on-prem: was wirklich funktioniert

TL;DR

• Throughput-Boost: vLLM liefert mit PagedAttention 2–5× höheren Throughput als naive HuggingFace-Transformers — der Grund für die de-facto-Standard-Position beim on-prem LLM-Serving.
• Setup-Aufwand: 4–8 Wochen Senior-DevOps für ein produktives Cluster, plus 8–12 Wochen Hardware-Lead-Time vor dem ersten Pod-Start.
• Hardware-Bottleneck: GPU-Beschaffung ist die kritische Engpassgröße — H100/H200-Quotas limitiert, Eigen-Hardware erfordert 5–8 kW Strom + Kühlung pro Server.

Was vLLM 2026 leistet

vLLM ist ein open-source LLM-Inference-Server, an der UC Berkeley entwickelt und seit 2024 von einer breiten Industrie-Coalition getragen. Production-ready für Llama 3/4, Mistral, Mixtral, Qwen 2.5/3, Gemma 2/3 und DeepSeek-V3.

Die zentrale Innovation ist PagedAttention — eine Speicher-Verwaltung für KV-Caches analog zu virtuellem Speicher in Betriebssystemen. Effekt: 2–5× höherer Throughput und 2–4× bessere GPU-Auslastung gegenüber naiven Frameworks. Continuous Batching, Tensor Parallelism, Speculative Decoding und Prefix Caching sind production-stable; Multi-LoRA-Serving und Quantisierung (AWQ, GPTQ, FP8) sind verfügbar, mit gelegentlichen Edge-Cases.

llama.cpp und naive Transformers liegen mit ~120 bzw. ~480 tok/s und ohne Multi-Tenant-Support weit darunter. vLLM erreicht ~80 % der TensorRT-LLM-Leistung ohne Vendor-Lock-in und mit besserer Multi-Tenant-Unterstützung — der Hauptgrund für die Standard-Position.

Setup-Workflow im Mittelstand

Der realistische Setup-Pfad teilt sich in vier sequenzielle Phasen. Senior-DevOps mit Kubernetes- und GPU-Erfahrung ist nicht verhandelbar.

• Hardware-Bestellung (Wochen 1–12): zuerst bestellen, die Lead-Time ist der Bottleneck. Typischer Einstieg für 5–10 Workloads: 2× H100 80GB SXM oder 4× L40S.
• Software-Stack (Wochen 1–4): Ubuntu 22.04 LTS, CUDA 12.4+, vLLM-Container in Kubernetes, NVIDIA-GPU-Operator, Ray, Prometheus + Grafana. Reverse-Proxy mit Auth (Kong/Envoy) ist Pflicht — vLLM hat keine Built-in-Authentication. Wer das vergisst, hat einen offenen LLM-Endpoint im Firmennetz.
• Production-Hardening (Wochen 4–6): Health-Checks, Request-Timeouts, Rate-Limits und Token-Budget-Tracking pro Tenant. vLLM crasht bei Memory-Pressure ohne sauberen Recovery — daher Pod-Auto-Restart und Sidecar-Watchdogs.
• Monitoring (Wochen 5–8): drei kritische Metriken — GPU-Memory-Utilization (Ziel 80–90 %), TTFT-P95 (Ziel <500 ms), Tokens-per-Second pro GPU. Alle mit Alerting.

Hardware-Bottleneck: GPU-Beschaffung

Die GPU-Verfügbarkeit ist 2026 das limitierende Element für jeden on-prem LLM-Build — bei Hyperscalern wie bei Direkt-Kauf.

Die nächste NVIDIA-Generation (B200) startet mit 16–24 Wochen Lead-Time. Wer im Mai 2026 H200 bestellt, hat den ersten Pod frühestens September im Rack — vier Monate sind die Norm. Als Bridge eignen sich Lambda Labs, CoreWeave oder RunPod, bis die eigene Hardware steht.

Operational Pain Points

Drei wiederkehrende Schmerzpunkte tauchen in jedem on-prem Mandat auf — keine vLLM-Probleme, sondern Konsequenzen physikalischer und organisatorischer Realität, in der Anbieter-Kommunikation systematisch unterschätzt.

• Strom und Kühlung: Ein H100-Server zieht 5–8 kW, drei Server 15–24 kW im Rack. Standard-Office-Rechenzentren sind auf 3–5 kW pro Rack ausgelegt — also neues Stromnetz, USV und Kühlung. Ein Hersteller in Süddeutschland verlor 10 Wochen allein für 32A-CEE-Verkabelung und Klimatisierung.
• Update-Cadence: vLLM veröffentlicht alle 4–6 Wochen ein Minor-Release mit häufigen Breaking Changes. Production-Cluster sollten eine Minor-Version hinter Head laufen und Releases im Staging validieren — sonst gibt es alle 4–6 Wochen einen Wochenend-Incident statt eines geplanten Quartals-Sprints.
• Multi-Tenant-Isolation: Die Memory-Isolation zwischen Tenants ist schwach — ein 32k-Context-Request kann den KV-Cache eines anderen verdrängen. Lösung: separate Engines pro Tenant-Klasse plus harte Resource-Quotas pro Pod.

Wann Cloud-GPU sinnvoller ist

On-prem vLLM ist nicht für jeden die richtige Antwort. Drei Konstellationen sprechen klar für Managed-Cloud-Inference (AWS Bedrock, Azure AI Foundry, Lambda Labs, Together.ai):

• Spikes statt Baseline: Wer 80 % der Zeit niedrige Last und nur in Spitzen hohe fährt, zahlt für Eigen-GPUs Leerlauf. Token-Pricing ist bei moderaten Volumina (<2 Mio. Tokens/Tag) deutlich günstiger.
• Modell-Vielfalt: Wer sechs Modelle parallel braucht (70B + Frontier + Mistral + Embeddings + Whisper), bräuchte lokal 4–6 GPU-Server. Managed Cloud löst das mit einer API-Zeile.
• Compliance-Frame: Wo keine strikte Datenresidenz im eigenen RZ gefordert ist (DSGVO mit EU-Region erfüllt es bei Frankfurt-Hosting), spart Cloud Monate Setup und vermeidet hohe CapEx.

On-prem-Logik greift bei konstant hoher Auslastung (>10 Mio. Tokens/Tag), strikter Datenresidenz (KRITIS, BaFin, MedTech), proprietären Fine-Tunes und TCO-Logik über 3+ Jahre.

In DACH-Mandaten zeigt sich: on-prem vLLM ist eine Architektur-Entscheidung, keine Inference-Optimierung. Aus den falschen Gründen getroffen, baut man eine Maschine, die in der Cloud einen Bruchteil gekostet hätte.

Praxis-Schritt: Ein 30-Min-Eignungsgespräch klärt, ob Volumen, Compliance-Frame und DevOps-Kapazität die on-prem-Logik tragen. Erstgespräch anfragen → /anfrage

Stand Mai 2026. vLLM-Versionen, GPU-Lead-Times und Cloud-Preise ändern sich quartalsweise — diese Übersicht wird entsprechend aktualisiert.