vLLM

Kurzfazit

vLLM ist die Inferenz-Engine, an der heute keine ernsthafte LLM-Eigenbetrieb-Strategie vorbeikommt. Was 2023 als Forschungsprojekt am Sky Computing Lab der UC Berkeley begann, ist binnen zweier Jahre zum Industriestandard für hochperformante Open-Source-LLM-Auslieferung gereift. Die zentrale Innovation, PagedAttention, nutzt GPU-Speicher so effizient, dass auf derselben Hardware mehrfach mehr parallele Anfragen bedient werden können als mit naiven Implementierungen. Der Preis: vLLM ist Backend-Infrastruktur für Entwickler, kein Endprodukt. Wer ein Team mit GPU-Erfahrung hat und LLMs DSGVO-konform selbst betreiben will, bekommt mit vLLM die produktionsreife Grundlage. Wer einfach einen Chat will, ist hier falsch.

Für wen ist vLLM?

ML-Plattform-Teams in Konzernen und KMU: vLLM ist die Standardwahl, sobald LLMs nicht mehr nur experimentell, sondern als Produktivdienst betrieben werden müssen. Hohe Last, mehrere Modelle parallel, vorhersehbare Latenzen, vLLM löst genau diese Probleme.

Unternehmen mit harten DSGVO-Anforderungen: Banken, Versicherungen, Kanzleien, Krankenhäuser, Behörden, überall dort, wo OpenAI- oder Anthropic-APIs aus Compliance-Gründen ausscheiden, ist vLLM der Schlüssel zu einer sauberen Eigenbetriebs-Strategie. Anfragen verlassen das eigene Rechenzentrum (oder die EU-Cloud-Region) niemals.

Tech-Unternehmen mit hohem Anfrage-Volumen: Wer pro Monat Millionen Tokens verarbeitet, zahlt bei kommerziellen API-Anbietern schnell fünfstellige Beträge. Auf eigener GPU-Hardware (oder gemieteten Cloud-GPUs) sind die Stückkosten mit vLLM oft eine Größenordnung niedriger.

Forschungsinstitute und Universitäten: Lehrstühle, die mit Sprachmodellen arbeiten, nutzen vLLM, weil sich Modelle, Quantisierungen und Inferenz-Parameter feingranular steuern lassen. Reproduzierbare Benchmarks, kontrollierte Experimente, eigene Modell-Varianten, alles möglich.

ML-Engineering-Teams in Startups: Wer eine KI-SaaS auf Open-Source-Modellen baut, wählt vLLM als Inferenz-Schicht, weil es skaliert und nichts kostet außer Hardware. Auf Plattformen wie Modal, RunPod oder Together AI läuft vLLM unter der Haube.

Weniger geeignet für: Einzelpersonen, die einen lokalen Chat suchen (Ollama oder LM Studio sind passender). Teams ohne GPU-Erfahrung. Anwendungsfälle, in denen die Modellqualität von GPT-4o oder Claude Opus zwingend erforderlich ist, Open-Source-Modelle haben hier weiterhin eine Lücke.

Preise im Detail

Komponente	Kosten	Was du bekommst
vLLM Software	Kostenlos (Apache 2.0)	Vollständige Inferenz-Engine, alle Features, kommerzielle Nutzung erlaubt
Modelle	Kostenlos (je nach Modell-Lizenz)	Llama, Mistral, Qwen, Gemma, DeepSeek u.a., je nach Lizenz mit Nutzungsbedingungen
GPU-Hardware (eigen)	5.000–100.000 € einmalig	NVIDIA A100/H100/L40S, AMD MI300, abhängig von Modellgröße und Last
GPU-Cloud (EU)	ca. 1–10 €/Stunde pro GPU	OVHcloud, Hetzner, Scaleway, IONOS, DSGVO-konform in EU-Rechenzentren
GPU-Cloud (US-Anbieter)	ca. 0,50–8 USD/Stunde pro GPU	AWS, GCP, Azure, günstig, aber DSGVO erfordert AVV und EU-Region
Kommerzielle Distributionen	Auf Anfrage	Red Hat AI Inference Server (basiert auf vLLM), Anyscale Endpoints, Together AI

Einordnung: Die Software selbst ist und bleibt kostenlos, das ist der entscheidende Unterschied zu kommerziellen Inferenz-Plattformen. Die echten Kosten entstehen bei der Hardware. Eine produktionsreife Single-Node-Installation mit einer Llama-3-8B-Auslieferung lässt sich schon mit einer NVIDIA L40S (ca. 8.000 €) oder einer gemieteten Cloud-GPU für rund 1 €/Stunde realisieren. Für 70B-Modelle braucht es entweder mehrere GPUs (Tensor Parallelism) oder eine H100 mit 80 GB VRAM. Die Faustregel: Ab etwa 1.000 USD/Monat OpenAI-API-Verbrauch wird vLLM auf eigener Hardware wirtschaftlich, vorausgesetzt, das Team-Know-how ist da.

Stärken im Detail

PagedAttention ist der eigentliche Durchbruch. Klassische LLM-Inferenz reserviert für jede Anfrage einen großen, durchgehenden Speicherblock für den Key-Value-Cache, meist viel zu groß, weil die finale Länge nicht bekannt ist. PagedAttention überträgt das Konzept des virtuellen Speichers aus Betriebssystemen auf den GPU-Cache: Der Speicher wird in kleine Blöcke (Pages) aufgeteilt und nur bei Bedarf belegt. Das Ergebnis: 2- bis 4-fach höhere Auslastung der GPU, dramatisch höherer Durchsatz pro Sekunde, und die Möglichkeit, mehr Anfragen parallel zu bedienen. Diese Idee wurde später von Wettbewerbern wie TensorRT-LLM und SGLang übernommen, vLLM hat den Standard gesetzt.

Continuous Batching statt Static Batching. Klassisch werden Anfragen in festen Gruppen verarbeitet, alle warten, bis die längste fertig ist. vLLM nutzt iteratives Batching: Sobald eine Anfrage fertig ist, rückt eine neue nach. Das hält die GPU permanent ausgelastet und verkürzt die wahrgenommene Latenz für Endnutzer drastisch.

OpenAI-API-Kompatibilität ist die strategische Brücke. vLLM exponiert eine REST-API, die mit den OpenAI-SDKs (Python, JavaScript, Go) kompatibel ist. Bestehender Code, der openai.ChatCompletion.create() aufruft, funktioniert nach Austausch der base_url ohne weitere Änderungen mit vLLM. Das senkt die Migrationshürde von OpenAI auf eigene Infrastruktur fundamental, und ist einer der Hauptgründe für die schnelle Verbreitung.

Hardware-Vielfalt jenseits NVIDIA. Während viele Inferenz-Engines NVIDIA-only sind, unterstützt vLLM auch AMD ROCm (MI250, MI300), Intel Gaudi und XPU, Google Cloud TPUs, AWS Neuron-Chips (Inferentia/Trainium) und Huawei Ascend NPUs. Für Unternehmen, die nicht NVIDIA-abhängig sein wollen oder günstigere Alternativen suchen, ist das ein echter Hebel.

Aktives Ökosystem mit ernsthafter Förderung. Sponsoren sind unter anderem a16z, AWS, Google Cloud, NVIDIA, und seit 2025 ist vLLM offiziell Teil der PyTorch Foundation. Das ist nicht nur Symbolik, es bedeutet professionelle Governance, langfristige Sicherheit und Schutz vor dem klassischen “Lieblings-Maintainer-verschwindet”-Risiko vieler Open-Source-Projekte.

Über 78.000 GitHub-Sterne und wöchentliche Releases. Die Entwicklungsgeschwindigkeit ist hoch: neue Modell-Architekturen (Llama 4, DeepSeek-V3, Qwen3) werden meist innerhalb weniger Tage nach Veröffentlichung unterstützt. Das ist für eine Self-Hosting-Strategie entscheidend, weil Modelle sonst veraltet sind, bevor sie produktiv laufen.

Schwächen ehrlich betrachtet

Setup ist real komplex, und das wird oft unterschätzt. Wer vLLM ernsthaft produktiv betreibt, muss sich mit CUDA-Versionen, Tensor Parallelism über mehrere GPUs, Quantisierungs-Formaten (AWQ, GPTQ, FP8), Speicher-Management, Modell-Loading-Strategien und Auto-Scaling befassen. Ein erstes “Hello World” ist in 30 Minuten erledigt; eine produktionsreife Installation braucht Wochen.

Kein offizieller kommerzieller Support. vLLM ist Open Source ohne kommerzielle Entität dahinter, die SLAs verkauft. Bei kritischen Bugs oder Performance-Problemen bleibt nur GitHub Issues, Slack-Community oder die Beauftragung externer Berater. Für unternehmenskritische Workloads ist das ein Risiko, ein Grund, warum viele Unternehmen kommerzielle Distributionen wie Red Hat AI Inference Server (basiert auf vLLM) wählen, die zumindest den Support beilegen.

GPU-Pflicht und VRAM-Hunger. Der CPU-Mode existiert, ist aber für Produktion untauglich. Selbst kleinere Modelle (7B-Parameter) brauchen mindestens 16 GB VRAM für brauchbaren Durchsatz. Für 70B-Modelle ohne starke Quantisierung sind 80 GB VRAM (NVIDIA H100) oder Multi-GPU-Konfigurationen nötig. Das schließt günstige Hardware-Strategien aus.

Kein Frontend, nicht einmal ein minimales Admin-UI. vLLM ist reine Backend-Infrastruktur. Wer ein Chat-Interface braucht, muss separat z.B. Open WebUI oder LibreChat aufsetzen. Wer Monitoring und Metriken will, kombiniert mit Prometheus und Grafana. Wer Model-Switching im laufenden Betrieb will, baut das selbst. Das ist konsequente Unix-Philosophie, aber kein All-in-One-Produkt.

Komplexität bei Quantisierung und Modell-Auswahl. Welches Quantisierungs-Format passt zu welcher Hardware? AWQ läuft schneller als GPTQ, FP8 braucht H100, INT4 verliert Qualität, diese Entscheidungen müssen Teams selbst treffen, basierend auf eigenen Benchmarks. Es gibt keine “klick-und-fertig”-Empfehlung.

Modellqualität bleibt eine Open-Source-Frage. vLLM macht die Inferenz schnell und billig, aber die Qualität kommt vom Modell. Llama 3.1 70B oder DeepSeek-V3 sind beeindruckend, GPT-4o oder Claude Opus aber für viele Aufgaben weiterhin überlegen. Wer maximale Modellqualität braucht, kommt an proprietären APIs nicht vorbei.

Alternativen im Vergleich

Wenn du…	…nimm stattdessen
Lokale LLMs auf einem Laptop oder Desktop ausprobieren willst	Ollama
Modelle und Datasets entdecken, fine-tunen oder hosten willst	Hugging Face
Eine fertige DSGVO-konforme LLM-Plattform mit UI brauchst	Langdock
GPT-4-Klasse-Modelle in Azure (mit AVV in EU) brauchst	Azure OpenAI Service
Ein deutsches Foundation-Modell mit Enterprise-Support willst	Aleph Alpha

Erwähnenswert ohne eigene Tool-Seite: TensorRT-LLM (NVIDIA-only, höchste Performance auf NVIDIA-Hardware, aber proprietär), SGLang (jüngere vLLM-Alternative mit Fokus auf strukturierte Generierung), Text Generation Inference / TGI (Hugging Faces eigene Inferenz-Engine, ehemals Apache 2.0, inzwischen unter restriktiverer Lizenz), Together AI und Anyscale Endpoints (Hosted-vLLM-Services für Teams ohne eigene GPU-Infrastruktur). vLLM bleibt aber die universellste, am weitesten verbreitete Wahl, sobald Hardware-Vielfalt oder vollständige Selbstkontrolle wichtig sind.

So steigst du ein

Schritt 1: Auf einer Cloud-GPU spielerisch starten. Bevor du eigene Hardware kaufst, miete eine GPU bei Hetzner (DSGVO-freundlich, EU) oder RunPod (günstig, weltweit) für 1–2 Stunden. Installation: pip install vllm, dann ein erstes Modell starten mit vllm serve meta-llama/Llama-3.1-8B-Instruct. Eine OpenAI-kompatible API läuft danach auf Port 8000. Test mit dem OpenAI-Python-Client (openai.OpenAI(base_url="http://localhost:8000/v1")), die ersten Anfragen funktionieren in unter 30 Minuten. Wichtig: Nutze ein Modell, das mit Hugging-Face-Token zugänglich ist und in den verfügbaren VRAM passt.

Schritt 2: Realistisches Benchmark mit deinem Workload. Bevor du Produktiv-Hardware planst, miss mit deinen echten Anfragen: Wie lang sind Eingaben und Ausgaben? Wie viele parallele Nutzer? Welche Latenz wird akzeptiert? Tools wie vllm bench oder genai-perf helfen, Durchsatz (Tokens/Sekunde) und Latenz (Time-to-First-Token, Inter-Token-Latency) zu messen. Daraus ergibt sich, welche GPU und welches Quantisierungs-Format passt, das spart später erhebliche Hardware-Kosten.

Schritt 3: Produktiv mit Container-Orchestrierung. Im echten Betrieb läuft vLLM in Containern (offizielles Image: vllm/vllm-openai:latest) auf Kubernetes oder Docker Swarm, hinter einem Reverse-Proxy mit TLS und Authentifizierung. Monitoring über Prometheus-Endpoints, Logs nach Loki oder ELK. Pro-Tipp: Setze von Anfang an auf horizontale Skalierung (mehrere Replicas) statt vertikaler, bei Modell-Updates oder Hardware-Ausfällen ist das Gold wert. Für DSGVO-Setups: Cluster ausschließlich in EU-Region, Datenschutz-Folgenabschätzung vor Go-Live, Audit-Logs für jede Anfrage.

Ein konkretes Beispiel

Eine mittelständische Versicherung in Köln (1.200 Mitarbeitende) hat ihre internen KI-Werkzeuge bislang über Azure OpenAI Service betrieben. Mit dem starken Anstieg an Anfragen, Schadensgutachten-Klassifikation, Vertrags-Zusammenfassungen, interner Knowledge-Bot, wurden die Monatsrechnungen vierstellig. Ein dreiköpfiges ML-Engineering-Team setzte über zwei Quartale vLLM auf eigener Infrastruktur auf: zwei NVIDIA H100 in einem deutschen Rechenzentrum (gemietet bei Hetzner), Llama 3.1 70B mit AWQ-Quantisierung, Open WebUI als Chat-Frontend für die Mitarbeitenden, OpenAI-kompatible API für die bestehenden internen Anwendungen. Migration der bestehenden Integrationen: meist eine Zeile Code (Base-URL ändern). Ergebnis nach sechs Monaten: 70 % der Anfragen laufen jetzt über vLLM, monatliche Inferenz-Kosten von rund 8.000 EUR auf 2.300 EUR gesunken (inkl. Hardware-Miete). Komplexere Anfragen (juristische Detail-Analysen) bleiben bei Azure OpenAI, weil GPT-4-Klasse-Qualität dort noch überlegen ist. Die DSGVO-Folgenabschätzung wurde von der Compliance-Abteilung positiv bewertet, kein Datenabfluss aus dem deutschen Rechenzentrum.

DSGVO & Datenschutz

• Datenhosting: Vollständig unter eigener Kontrolle. vLLM läuft dort, wo du es betreibst, eigenes Rechenzentrum, gemietete Bare-Metal-Server, EU-Cloud-Region. Standardmäßig keine Telemetrie, keine externen Verbindungen.
• Datennutzung für Training: Nicht anwendbar, vLLM ist Inferenz-Software, kein Trainings-Service. Anfragen werden verarbeitet und das Ergebnis zurückgegeben, nichts wird gespeichert oder weitergegeben.
• Auftragsverarbeitung (AVV): Nicht erforderlich für vLLM selbst (es gibt keinen Anbieter, der Daten verarbeitet). Bei gemieteten GPU-Cloud-Anbietern (Hetzner, OVHcloud, AWS, GCP, Azure) gilt der jeweilige Cloud-Anbieter-AVV.
• Modell-Lizenzen prüfen: Llama-Modelle stehen unter der Llama Community License (kommerzielle Nutzung mit Einschränkungen ab 700 Mio. monatlichen Nutzern), Mistral und DeepSeek meist unter Apache 2.0, Gemma unter Google-spezifischer Lizenz. Vor produktivem Einsatz: jeweilige Modell-Lizenz lesen.
• Empfehlung für Unternehmen: vLLM ist die richtige Wahl, wenn DSGVO-Compliance und Datenhoheit nicht verhandelbar sind, Anwaltskanzleien, Versicherungen, Krankenhäuser, Behörden, Banken. Voraussetzung: ML-Engineering- oder DevOps-Team mit GPU-Erfahrung. Für Hosting in deutschen Rechenzentren bieten sich Hetzner (Falkenstein, Nürnberg) und OVHcloud (Limburg) an.
• Logging-Disziplin: Standardmäßig loggt vLLM keine Anfrage-Inhalte. Wer Audit-Trails aktiviert, sollte vorher klären, wo Logs gespeichert werden und wie lange, sensible Eingaben sollten nicht im Klartext in Log-Systemen landen.

Gut kombiniert mit

• Ollama, Ollama für lokale Entwickler-Sandboxes auf Laptops, vLLM für die produktive Server-Auslieferung. Beide sprechen OpenAI-kompatible APIs, sodass derselbe Anwendungs-Code gegen beide Backends läuft.
• Hugging Face, Hugging Face Hub ist die zentrale Quelle für Modell-Gewichte und Datasets. vLLM lädt Modelle direkt aus dem Hub via Modell-ID. Wer eigene Fine-Tunes baut, lädt sie auf Hugging Face hoch und betreibt sie über vLLM.
• Langdock, Langdock kann eigene OpenAI-kompatible Endpoints anbinden. So lässt sich eine vLLM-Instanz als Backend nutzen, während Langdock die UI, das Rechtemanagement und die Integration in den Unternehmensalltag liefert.

Unser Testurteil

vLLM verdient 4 von 5 Sternen. Den vierten Stern gewinnt es klar: technologische Führung in der Inferenz-Optimierung, OpenAI-API-Kompatibilität als strategischer Hebel, Hardware-Vielfalt, ernsthafte institutionelle Förderung über die PyTorch Foundation, und ein Ökosystem, das wöchentlich wächst. Den fünften Stern vergibt es nicht, weil die Einstiegshürde für Teams ohne ML-Ops-Erfahrung sehr real ist und weil das Fehlen kommerziellen Supports für unternehmenskritische Workloads eine Lücke bleibt. Wer ein eingespieltes Engineering-Team hat und LLMs ernsthaft selbst betreiben will, findet aktuell nichts Besseres als vLLM. Wer einen einfachen lokalen Chat will, ist mit Ollama besser bedient, und das ist keine Schwäche von vLLM, sondern eine Frage des passenden Werkzeugs für die jeweilige Aufgabe.

Was wir bemerkt haben

• 2023, vLLM wurde am Sky Computing Lab der UC Berkeley veröffentlicht. Das ursprüngliche Paper “Efficient Memory Management for Large Language Model Serving with PagedAttention” hat die gesamte Branche beeinflusst, TensorRT-LLM und SGLang haben das Konzept später übernommen.
• 2024, vLLM wurde offizielles Hosted-Projekt der PyTorch Foundation. Das schützt vor dem klassischen “Maintainer-Burnout”-Problem vieler Open-Source-Projekte und gibt Unternehmen, die produktiv setzen, mehr Planungssicherheit.
• 2025, Red Hat hat den “Red Hat AI Inference Server” auf Basis von vLLM veröffentlicht. Das ist ein deutliches Signal: vLLM ist im Enterprise-Umfeld angekommen und es gibt jetzt kommerzielle Distributionen mit Support, ein wichtiges Zeichen für Unternehmen, die SLA-Anforderungen haben.
• 2025, vLLM hat über 78.000 GitHub-Sterne überschritten und etabliert sich neben TensorRT-LLM und SGLang als eine der drei führenden LLM-Inferenz-Engines. Anders als TensorRT-LLM ist es Hardware-unabhängig.
• Mai 2026, Die Unterstützung für neue Modelle erfolgt typischerweise innerhalb von Tagen nach Veröffentlichung. Llama 4, DeepSeek-V3 und Qwen3 waren jeweils binnen einer Woche produktiv lauffähig, ein wichtiger Qualitätsmesser für Selbst-Hosting-Strategien.