Wichtigste Erkenntnisse
- Kostenlos und Apache-2.0-lizenziert quelloffen, entstanden im Sky Computing Lab der UC Berkeley
- PagedAttention verwaltet den KV-Cache in seitengroßen, nicht zusammenhängenden Blöcken, um verschwendeten GPU-Speicher zu reduzieren
- Continuous Batching verarbeitet viele gleichzeitige Anfragen statt eines festen Batches nach dem anderen
- Bringt einen eingebauten OpenAI-kompatiblen API-Server mit, gestartet mit dem Befehl
vllm serve - Unterstützt Quantisierungsformate wie AWQ, GPTQ und FP8
- Unterstützt Tensor-Parallel- und Pipeline-Parallel-Serving über mehrere GPUs
- Primäre, am besten unterstützte Hardware sind NVIDIA-GPUs; AMD-, Intel- und weitere Backends existieren, aber mit schmalerer Abdeckung
- Keine Einzelnutzer-Desktop-App — kein grafischer Installer, und nicht auf CPU-only oder Apple Silicon ausgelegt wie llama.cpp und Ollama
📍 In einem Satz
vLLM ist eine kostenlose, Apache-2.0-lizenzierte Inferenz- und Serving-Bibliothek aus dem Sky Computing Lab der UC Berkeley, die mit PagedAttention und Continuous Batching viele gleichzeitige LLM-Anfragen effizient von einer GPU bedient und einen eingebauten OpenAI-kompatiblen API-Server mitbringt.
💬 In einfachen Worten
Statt einer Desktop-Chat-App ist vLLM Server-Software: Man richtet sie auf ein Modell aus, und sie stellt eine API bereit, die viele Personen oder Anwendungen gleichzeitig aufrufen können — mit effizienterer GPU-Speichernutzung als bei einem einfachen Ein-Anfrage-nach-der-anderen-Aufbau.
📌Hinweis: Dieser Artikel basiert auf vLLMs offiziellem GitHub-Repository und öffentlicher Dokumentation, nicht auf eigenen Benchmarks. Konkrete Durchsatz- oder Latenzzahlen fehlen bewusst, da sie für diesen Artikel nicht unabhängig gemessen wurden und stark von GPU, Modell, Batch-Größe und vLLM-Version abhängen.
Was ist vLLM?
vLLM ist eine kostenlose, Apache-2.0-lizenzierte Bibliothek und ein Server für LLM-Inferenz im großen Maßstab. Es entstand als Forschungsprojekt im Sky Computing Lab der UC Berkeley und hat sich seitdem zu einer der meistgenutzten Open-Source-LLM-Serving-Engines entwickelt, mit Beiträgen von Tausenden Entwicklern aus Wissenschaft und Industrie. Anders als Tools, die vor allem für einen einzelnen Nutzer gebaut sind, der auf seiner eigenen Maschine mit einem Modell chattet, ist vLLM darauf ausgelegt, viele gleichzeitige Anfragen — von mehreren Nutzern oder Anwendungen — möglichst effizient aus gemeinsamer GPU-Kapazität zu bedienen.
- Entstanden im Sky Computing Lab der UC Berkeley, heute ein community-geführtes Open-Source-Projekt
- Apache-2.0-lizenziert: der Quellcode ist öffentlich verfügbar zur Nutzung, Änderung und Weitergabe gemäß den Lizenzbedingungen
- Lädt Modelle im Hugging-Transformers-kompatiblen Format, was breite Architekturabdeckung ermöglicht — Llama, Mistral, Qwen, DeepSeek und viele weitere Modellfamilien — meist ohne separaten Konvertierungsschritt
- Ausgelegt auf effizientes Bedienen vieler gleichzeitiger Anfragen, nicht nur auf ein schnelles Einzelgespräch
- Eines der meistreferenzierten Open-Source-LLM-Serving-Projekte auf GitHub
Was ist PagedAttention, und warum ist es wichtig?
PagedAttention ist die Speicherverwaltungstechnik, für die vLLM am bekanntesten ist. Während der Generierung speichert ein Transformer-Modell für jedes Token jeder aktiven Anfrage einen Attention-Key-Value-Cache (KV-Cache) — normalerweise wird dieser Cache als ein großer zusammenhängender Block pro Anfrage reserviert, dimensioniert für die maximal mögliche Länge der Anfrage, was GPU-Speicher verschwendet, sobald eine Anfrage früher endet oder kürzer ist als das reservierte Maximum. PagedAttention teilt den KV-Cache stattdessen in kleine, feste Blöcke (Pages) auf, die nicht zusammenhängend zugewiesen und zwischen Anfragen geteilt werden können — eine Idee, die von der Verwaltung virtuellen Speichers in Betriebssystemen entlehnt ist.
- Reduziert Speicherverschwendung durch übermäßig reservierten KV-Cache-Platz für Anfragen, die sich als kürzer als ihr Maximum herausstellen
- Erlaubt das Teilen von Speicherblöcken zwischen Anfragen mit gemeinsamem Präfix, etwa demselben System-Prompt
- Ermöglicht es der GPU, mehr gleichzeitige Anfragen im gleichen Speicher zu halten als bei einer naiven zusammenhängenden Zuweisung
- Wirkt zusammen mit Continuous Batching, das es vLLM erlaubt, Anfragen laufend in einen aktiven Batch aufzunehmen und daraus zu entfernen, statt auf das vollständige Ende eines festen Batches zu warten, bevor der nächste beginnt
Welche Hardware braucht vLLM?
vLLMs primäres und am besten unterstütztes Ziel sind NVIDIA-GPUs mit CUDA, und die meisten Produktions-Deployments laufen auf NVIDIA-Hardware. Das Projekt dokumentiert zusätzliche Backends, aber Abdeckung und Performance sind dort nicht gleichwertig.
NVIDIA-GPUs (CUDA)
- Details:
- Das primäre, ausgereifteste Ziel. Tensor-Parallel- und Pipeline-Parallel-Serving über mehrere NVIDIA-GPUs ist gut dokumentiert und in der Produktion weit verbreitet.
AMD-GPUs (ROCm)
- Details:
- Als unterstütztes Backend für AMD-Hardware über ROCm dokumentiert, mit schmalerer realer Verbreitung und Community-Abdeckung als der CUDA-Pfad.
Intel-GPUs und Gaudi-Beschleuniger
- Details:
- Zusätzliche vom Projekt dokumentierte Backends für Intel-Hardware; als kleinerer, weniger erprobter Deployment-Pfad als NVIDIA-GPUs zu betrachten.
Google TPUs
- Details:
- Ein dokumentiertes Backend für Google-Cloud-TPU-Hardware, für Teams, die bereits auf dieser Infrastruktur laufen.
CPU (x86 / ARM / PowerPC)
- Details:
- Ein CPU-only-Backend existiert, ist aber nicht der Anwendungsfall von vLLM — das Projekt ist auf GPU-Serving ausgelegt, und CPU-Ausführung wird als deutlich langsamer dokumentiert als GPU-Backends.
Apple Silicon (Mac)
- Details:
- Kein offiziell gepflegter Pfad erster Klasse. Community-gepflegte Projekte (etwa ein Metal-Backend-Plugin) fügen teilweise Apple-Silicon-Unterstützung hinzu, aber Abdeckung und Reife liegen weit hinter vLLMs NVIDIA-GPU-Unterstützung zurück.
Wer ein Modell auf einem einzelnen Mac oder einer reinen CPU-Maschine ausführen möchte, ist mit vLLM nicht am richtigen Werkzeug — llama.cpp und darauf aufbauende Tools wie Ollama und LM Studio zielen direkt auf CPU- und Apple-Silicon-Hardware und passen dafür besser.
Welche Quantisierungsformate unterstützt vLLM?
vLLM unterstützt das Serving von Modellen mit reduzierter numerischer Präzision, um Speicherverbrauch zu senken und in vielen Fällen den Durchsatz zu erhöhen — über mehrere etablierte Quantisierungsformate statt eines einzigen proprietären Formats.
AWQ
- Details:
- Activation-aware Weight Quantization, eine weit verbreitete 4-Bit-Gewichtsquantisierungsmethode mit vorquantisierten Modellen, die die Community auf Hugging Face veröffentlicht.
GPTQ
- Details:
- Eine Post-Training-Quantisierungsmethode, üblicherweise als vorquantisierte Modell-Checkpoints verteilt, ebenfalls typischerweise mit 4-Bit-Präzision.
FP8
- Details:
- 8-Bit-Gleitkomma-Präzision, unterstützt auf neueren NVIDIA-GPU-Generationen mit Hardware-FP8-Unterstützung — weniger Präzision gegen geringeren Speicherverbrauch und schnellere Ausführung als FP16/BF16.
INT8 / INT4
- Details:
- Vom Projekt neben AWQ und GPTQ dokumentierte Ganzzahl-Quantisierungspfade mit niedrigerer Präzision für weitere Speicherreduktion.
Dieser Artikel enthält keine unabhängig gemessenen Qualitätsverlust-Werte je Format — diese variieren je nach Modellarchitektur und Aufgabe. Ausgaben mehrerer Formate an eigenen Prompts zu vergleichen ist der zuverlässigste Weg, den Trade-off für die eigene Anwendung zu beurteilen.
Was bietet der OpenAI-kompatible vLLM-Server?
Der Befehl vllm serve startet einen HTTP-Server, der das OpenAI-API-Protokoll implementiert, sodass Anwendungen und SDKs, die bereits gegen die OpenAI-API gebaut sind, oft nur mit geänderter Basis-URL und Modellname auf eine selbst gehostete vLLM-Instanz zeigen können.
- OpenAI-kompatible Chat-Completions- und Completions-Endpunkte, nutzbar als direkter Ersatz für OpenAI-API-basierten Client-Code
- Konfigurierbarer Host und Port (der Server lauscht standardmäßig auf
http://localhost:8000) - Engine-Flags für Tensor-Parallel-Größe, GPU-Speicherauslastungsziel und Quantisierungsformat, gesetzt beim Serverstart
- Unterstützung für das Serving mehrerer LoRA-Adapter gegen ein einzelnes geladenes Basismodell
- Unterstützung für strukturierte Ausgaben und Function-/Tool-Calling bei kompatiblen Anfrageformaten
Wie installiert und betreibt man vLLM?
vLLM wird als Python-Paket verteilt und typischerweise mit pip in eine Python-Umgebung mit verfügbarer NVIDIA-GPU und kompatiblen CUDA-Treibern installiert.
- 1Prüfen, ob eine unterstützte NVIDIA-GPU mit aktuellen CUDA-Treibern vorhanden ist (oder die Projektdokumentation für AMD/Intel/TPU-spezifische Installationsanleitungen konsultieren, falls eines dieser Backends genutzt werden soll).
- 2Eine Python-Virtual-Environment anlegen und vLLM installieren:
pip install vllm. - 3Den OpenAI-kompatiblen Server mit einem Modell von Hugging Face starten, z. B.:
vllm serve meta-llama/Llama-3.1-8B-Instruct. - 4Für ein vorquantisiertes Modell das passende Flag übergeben, z. B.:
vllm serve TheBloke/Llama-2-13B-AWQ --quantization awq. - 5Für Multi-GPU-Serving ein Tensor-Parallel-Flag hinzufügen, z. B.:
vllm serve <model> --tensor-parallel-size 2, um das Modell auf zwei GPUs zu verteilen. - 6Standardmäßig lauscht der Server auf
http://localhost:8000; eine Anfrage an den/v1/chat/completions-Endpunkt mit einer beliebigen OpenAI-API-kompatiblen Client-Bibliothek odercurlsenden. - 7Bestehenden OpenAI-API-Client-Code nur durch Ändern von Basis-URL und Modellname auf den selbst gehosteten Server richten.
Brauche ich eine GPU, um vLLM auszuführen?
Für alles über einen Test hinaus: ja — vLLMs primäres und am besten unterstütztes Ziel sind NVIDIA-GPUs. Ein CPU-only-Backend existiert, wird aber als deutlich langsamer dokumentiert und ist nicht der Fokus des Projekts.
Kann ich vLLM mit einem quantisierten Modell betreiben?
Ja — vLLM unterstützt Formate wie AWQ, GPTQ und FP8, und viele vorquantisierte Modelle in diesen Formaten sind auf Hugging Face veröffentlicht und lassen sich mit dem passenden --quantization-Flag betreiben.
Wie schneidet vLLM im Vergleich zu Ollama und LM Studio ab?
Ollama und LM Studio zielen auf ein anderes Problem als vLLM: einer einzelnen Person schnell und einfach ein Modell zum Chatten auf der eigenen Maschine zu geben. vLLM zielt darauf ab, viele gleichzeitige Nutzer oder Anwendungen möglichst effizient aus gemeinsamer GPU-Kapazität zu bedienen. Die beiden Werkzeugkategorien sind für die meisten Anwendungsfälle keine nahen Alternativen zueinander.
- Ollama und LM Studio bauen üblicherweise auf llama.cpp oder ähnlichen Engines und dem GGUF-Modellformat auf, optimiert für Einzelnutzer auf Consumer-Hardware inklusive CPU-only-Maschinen und Apple Silicon
- vLLM baut auf PagedAttention und Continuous Batching auf, optimiert für hochparallele GPU-Serving statt für Einzelnutzer-Reaktionsfreudigkeit auf bescheidener Hardware
- Ollama installiert sich mit einem Befehl ohne GPU-Bedarf; vLLM erwartet eine Python-Umgebung, in den meisten Deployments eine NVIDIA-GPU, und Konfiguration über die Kommandozeile
- LM Studio bringt eine grafische Desktop-Chat-Oberfläche mit; vLLM hat keine grafische Oberfläche — Zugriff erfolgt über die OpenAI-kompatible API oder Kommandozeilen-Flags
- Sowohl vLLM als auch auf llama.cpp basierende Tools können eine OpenAI-kompatible API bereitstellen, sodass Frontend-Tools für diese API oft mit beiden funktionieren
Wie schneidet vLLM im Vergleich zu TGI und TensorRT-LLM ab?
vLLM, Hugging Faces Text Generation Inference (TGI) und NVIDIAs TensorRT-LLM zielen alle auf dieselbe breite Aufgabe — Produktions-LLM-Serving im großen Maßstab —, aber mit unterschiedlichen Designs und Trade-offs.
vLLM
- Details:
- Apache-2.0-lizenziert, Python-basiert, aufgebaut auf PagedAttention und Continuous Batching. Lädt Hugging-Transformers-kompatible Modelle direkt, mit breiter Architekturabdeckung und Multi-Vendor-GPU-Backend-Unterstützung (NVIDIA primär; AMD, Intel, TPU dokumentiert).
TGI
- Details:
- Hugging Faces eigene Serving-Engine, Apache-2.0-lizenziert, unterstützt ebenfalls Continuous Batching und mehrere Quantisierungsformate. Eng in den Hugging Face Hub und das Ökosystem integriert.
TensorRT-LLM
- Details:
- NVIDIAs Engine, speziell für NVIDIA-GPUs gebaut. Modelle werden vorab in eine für die Ziel-GPU optimierte TensorRT-Engine kompiliert, was auf dieser konkreten Hardware starke Performance bringen kann — auf Kosten eines Kompilierungsschritts und geringerer plattformübergreifender Flexibilität als bei vLLM oder TGI.
Dieser Artikel hat diese drei Engines nicht selbst gegeneinander benchmarkt und behauptet nicht, dass eine universell schneller ist — der Durchsatz hängt stark von Modell, Hardware, Batch-Charakteristik und der jeweiligen Engine-Version ab. Siehe den Leitfaden zu Enterprise-Inferenz-Servern für einen detaillierteren Vergleich zu Deployment und Lizenzierung aller drei.
Für wen ist vLLM geeignet?
vLLM passt zu Teams, die ein Modell vielen gleichzeitigen Nutzern oder Anwendungen auf GPU-Infrastruktur bereitstellen — nicht zu Personen, die den schnellsten Weg suchen, auf dem eigenen Rechner mit einem Modell zu chatten.
vLLM im Vergleich zu Alternativen
Diese Tools liegen an unterschiedlichen Punkten zwischen Einzelnutzer- und Produktions-Serving-Anwendungsfall.
vLLM
- Oberfläche & Setup:
- Python-Paket über pip installiert; OpenAI-kompatibler API-Server, gestartet mit
vllm serve. Erwartet in den meisten Deployments eine NVIDIA-GPU und CUDA. - Am besten für:
- Hochdurchsatz-GPU-Serving für viele Nutzer in Produktion.
Ollama
- Oberfläche & Setup:
- CLI und REST-API, laut übereinstimmenden Berichten auf den meisten Plattformen mit llama.cpp als Backend. Ein Befehl installiert es; ein Befehl lädt und startet ein Modell.
- Am besten für:
- Der schnellste Weg zu einem laufenden lokalen Modell für einen einzelnen Nutzer, ohne Build-Schritt oder GPU.
LM Studio
- Oberfläche & Setup:
- Grafische Desktop-App für Mac, Windows und Linux. Herunterladen, installieren, dann ein Modell in der App durchsuchen und herunterladen.
- Am besten für:
- Nicht-technische Nutzer, die eine Klick-Chat-App wollen.
llama.cpp
- Oberfläche & Setup:
- CLI, eingebaute Web-UI und OpenAI-kompatible API über llama-server. Aus dem Quellcode bauen oder eine vorgebaute Binary nutzen; läuft auf CPU oder GPU.
- Am besten für:
- Direkte Kontrolle auf Engine-Ebene, Embedded-/Edge-Deployment und CPU- oder Apple-Silicon-Hardware.
Dieser Artikel hat Geschwindigkeit oder Ausgabequalität dieser Tools nicht selbst benchmarkt und behauptet nicht, dass eines technisch überlegen ist — der Vergleich oben deckt nur dokumentierte Architektur-, Setup- und Zugriffsmodell-Fakten ab. Für Durchsatzzahlen je Hardware siehe den Vergleich llama.cpp vs. Ollama vs. vLLM und den Leitfaden zu Enterprise-Inferenz-Servern.
Was deckt dieser Artikel nicht ab?
Dies ist ein Erklärartikel auf Basis von vLLMs öffentlicher Dokumentation und Repository, kein praktischer Benchmark-Bericht.
- Keine unabhängig gemessenen Durchsatz-, Latenz- oder Requests-pro-Sekunde-Zahlen — diese hängen stark von GPU, Modell, Batch-Zusammensetzung und vLLM-Version ab
- Keine unabhängig verifizierten Qualitätsverlust-Prozentwerte für bestimmte Quantisierungsformate — diese variieren je nach Modellarchitektur und Aufgabe
- Kein zeilenweises Sicherheitsaudit des vLLM-Codebase — er ist quelloffen und Apache-2.0-lizenziert, der Code selbst ist zur Überprüfung verfügbar
- Keine vollständige Abdeckung jedes unterstützten Hardware-Backends, Engine-Flags oder jeder Deployment-Orchestrierungsoption (Kubernetes, cloud-spezifische Setups) — dieser Artikel konzentriert sich auf die Konzepte und Flags, die die meisten Teams zuerst prüfen
- Keine Abdeckung kommerzieller Support-Vereinbarungen oder gemanagter vLLM-Hosting-Angebote, da vLLM selbst ein Community-Open-Source-Projekt ist und kein Anbieterprodukt mit Support-Vertrag
Häufige Fehler beim Ausprobieren von vLLM
Die meisten Reibungspunkte mit vLLM entstehen dadurch, es wie ein Einzelnutzer-Desktop-Tool statt wie Produktions-Server-Software zu behandeln.
Häufig gestellte Fragen
Was ist vLLM?
vLLM ist eine kostenlose, Apache-2.0-lizenzierte Bibliothek und ein Server für hochperformante LLM-Inferenz, entstanden im Sky Computing Lab der UC Berkeley. Es nutzt PagedAttention und Continuous Batching, um viele gleichzeitige Anfragen effizient von einer GPU zu bedienen.
Ist vLLM kostenlos?
Ja. vLLM ist kostenlose, quelloffene Software unter der Apache-2.0-Lizenz, ohne Abo oder Kontopflicht für den eigenen Betrieb.
Was ist PagedAttention?
PagedAttention ist vLLMs Technik zur Verwaltung des Attention-KV-Cache in kleinen, seitengroßen, nicht zusammenhängenden Blöcken statt einer großen zusammenhängenden Zuweisung pro Anfrage — das reduziert verschwendeten GPU-Speicher und erlaubt das Teilen von Speicher zwischen Anfragen mit gemeinsamem Präfix.
Braucht vLLM eine GPU?
Für jeden echten Workload: ja — vLLMs primäres und am besten unterstütztes Ziel sind NVIDIA-GPUs. Ein CPU-only-Backend existiert, wird aber als deutlich langsamer dokumentiert und ist nicht der Fokus des Projekts; Apple-Silicon-Unterstützung beschränkt sich auf community-gepflegte Zusätze statt einen erstklassigen Pfad.
Welche Quantisierungsformate unterstützt vLLM?
vLLM unterstützt mehrere Formate, darunter AWQ, GPTQ, FP8 und INT8/INT4, mit vielen vorquantisierten Modellen in diesen Formaten auf Hugging Face.
Ist vLLM besser als Ollama?
„Besser" hängt von der Aufgabe ab: vLLM ist für hochparalleles Produktions-GPU-Serving gebaut, Ollama für den schnellsten Weg zu einem lokalen Einzelnutzer-Modell ohne GPU. Für die meisten Anwendungsfälle sind sie keine nahen Alternativen — siehe die Vergleichstabelle oben.
Kann vLLM Modelle über mehrere GPUs hinweg bedienen?
Ja. vLLM unterstützt Tensor-Parallel- und Pipeline-Parallel-Serving über mehrere GPUs, konfigurierbar mit Flags wie --tensor-parallel-size beim Serverstart.
Hat vLLM eine OpenAI-kompatible API?
Ja. Der Befehl vllm serve startet einen Server, der das OpenAI-API-Protokoll implementiert, sodass viele für die OpenAI-API gebaute Anwendungen nur mit geänderter Basis-URL und Modellname auf eine selbst gehostete vLLM-Instanz zeigen können.
Wie unterscheidet sich vLLM von TensorRT-LLM?
TensorRT-LLM ist NVIDIAs Engine, die Modelle vorab in eine für eine bestimmte NVIDIA-GPU optimierte Engine kompiliert. vLLM lädt Hugging-Transformers-kompatible Modelle direkt, ohne Vorab-Kompilierungsschritt, und dokumentiert Backend-Unterstützung über NVIDIA-GPUs hinaus — auf Kosten hardwarespezifischer Optimierung, aber mit größerer Flexibilität und schnellerer Iteration.