Skip to main content
PromptQuorumBuilt for humans. Structured for AI.
Startseite/Lokale LLMs Pro
Overview & Reference

vLLM erklärt: Hochleistungs-LLM-Serving mit PagedAttention (2026)

·13 Min. LesezeitVon Hans Kuepper · Gründer von PromptQuorum · Entdeckungsplattform für Open-Weight- und Open-Source-KI

vLLM ist eine kostenlose, quelloffene (Apache 2.0) Bibliothek für hochperformante LLM-Inferenz und -Serving, entstanden im Sky Computing Lab der UC Berkeley und heute von einer großen Open-Source-Community gepflegt. Das technische Alleinstellungsmerkmal ist PagedAttention, das den Attention-KV-Cache in nicht zusammenhängenden, seitengroßen Blöcken verwaltet — ähnlich wie ein Betriebssystem virtuellen Speicher verwaltet —, sodass eine GPU deutlich mehr gleichzeitigen Anfrage-Zustand halten kann, ohne für jede Anfrage übermäßig Speicher zu reservieren. Zusammen mit Continuous Batching erlaubt das vLLM, viele gleichzeitige Nutzer von einer GPU (oder einem Tensor-Parallel-Multi-GPU-Setup) mit weniger verschwendetem Speicher zu bedienen als eine naive Serving-Schleife. vLLM bringt einen eingebauten OpenAI-kompatiblen API-Server (vllm serve) mit, unterstützt Quantisierungsformate wie AWQ, GPTQ und FP8 und ist für Produktions- und Multi-Tenant-Serving gebaut — nicht für den Einzelnutzer-Klick-Anwendungsfall, auf den Tools wie Ollama und LM Studio zielen.

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.

Lesen auf:
🇺🇸en🇩🇪de🇫🇷fr🇯🇵ja🇨🇳zh🇪🇸es🇧🇷pt🇸🇦ar🇰🇷ko

vLLM ist eine kostenlose, Apache-2.0-lizenzierte Bibliothek für LLM-Inferenz und -Serving, die im Sky Computing Lab der UC Berkeley entstand und heute von einer großen Open-Source-Community gepflegt wird. Der zentrale technische Beitrag ist PagedAttention, eine Speicherverwaltungstechnik für den Attention-Key-Value-Cache (KV-Cache), die es einer GPU erlaubt, aus dem gleichen Speicher deutlich mehr gleichzeitige Anfragen zu bedienen als bei naiven Attention-Implementierungen — kombiniert mit Continuous Batching, das eine GPU über viele gleichzeitige Anfragen hinweg ausgelastet hält, statt sie in festen Batches nacheinander abzuarbeiten. vLLM bringt einen eingebauten OpenAI-kompatiblen API-Server mit und zielt auf Produktions-Serving für viele Nutzer ab — ein anderes Werkzeug als Einzelnutzer-Desktop-Apps wie Ollama oder LM Studio.

vLLM erklärt: Hochleistungs-LLM-Serving mit PagedAttention (2026)

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.

  1. 1
    Prü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).
  2. 2
    Eine Python-Virtual-Environment anlegen und vLLM installieren: pip install vllm.
  3. 3
    Den OpenAI-kompatiblen Server mit einem Modell von Hugging Face starten, z. B.: vllm serve meta-llama/Llama-3.1-8B-Instruct.
  4. 4
    Für ein vorquantisiertes Modell das passende Flag übergeben, z. B.: vllm serve TheBloke/Llama-2-13B-AWQ --quantization awq.
  5. 5
    Fü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.
  6. 6
    Standardmäßig lauscht der Server auf http://localhost:8000; eine Anfrage an den /v1/chat/completions-Endpunkt mit einer beliebigen OpenAI-API-kompatiblen Client-Bibliothek oder curl senden.
  7. 7
    Bestehenden 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).
Artikel über vLLM (9)

+84 weitere nicht angezeigt

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.
Artikel über TensorRT-LLM (6)

Auch erwähnt in:

+1 weitere nicht angezeigt

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.

Nutzen Sie vLLM, wenn

  • Sie ein LLM hinter einer API bereitstellen, die viele Nutzer oder nachgelagerte Dienste gleichzeitig aufrufen
  • Sie Zugriff auf eine oder mehrere NVIDIA-GPUs (oder ein unterstütztes AMD-/Intel-/TPU-Deployment) haben und Durchsatz sowie gleichzeitige Anfragekapazität dieser Hardware maximieren wollen
  • Sie einen selbst gehosteten OpenAI-kompatiblen API-Server statt Abhängigkeit von einem Drittanbieter-API wollen
  • Sie Multi-GPU-Tensor-Parallel-Serving für ein Modell brauchen, das nicht auf eine einzelne GPU passt
  • Sie mit einer Python-Umgebung, Kommandozeilen-Konfiguration und GPU-/CUDA-Setup vertraut sind

Vermeiden Sie vLLM, wenn

  • Sie ein Modell auf dem eigenen Laptop oder Desktop für persönlichen Einzelnutzer-Chat ausführen wollen — Ollama oder LM Studio passen dafür deutlich besser
  • Sie keine unterstützte GPU haben — vLLMs CPU-Backend ist nicht der Fokus, und es gibt keine nennenswerte Apple-Silicon-Unterstützung wie bei llama.cpp oder Ollama
  • Sie eine grafische Klick-Oberfläche statt eines API-Servers und Kommandozeilen-Flags wollen
  • Sie sich nicht sicher im Umgang mit CUDA-Treibern, Python-Abhängigkeitskonflikten oder GPU-Speicherkonfiguration fühlen

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.
Artikel über vLLM (9)

+84 weitere nicht angezeigt

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.
Artikel über Ollama (10)

+310 weitere nicht angezeigt

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.
Artikel über LM Studio (10)

+146 weitere nicht angezeigt

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.
Artikel über llama.cpp (10)

+167 weitere nicht angezeigt

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.

Im Verzeichnis vergleichen

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.

Fehler 1: Der Versuch, es auf einem Laptop ohne dedizierte GPU auszuführen

vLLMs CPU-Backend existiert, ist aber nicht der Fokus, und es gibt keine nennenswerte Apple-Silicon-Unterstützung wie bei llama.cpp oder Ollama. Der Versuch, es auf einem reinen CPU-Laptop oder einem Apple-Silicon-Mac auszuführen, führt typischerweise zu schlechter Performance oder Setup-Reibung, die ein dafür gebautes lokales Tool ganz vermeiden würde.

Fehler 2: Einen grafischen Installer oder ein Chat-Fenster erwarten

vLLM hat keinen Klick-Installer und keine eingebaute Chat-UI. Es wird mit pip installiert und über seine OpenAI-kompatible API angesprochen — für ein Chat-Fenster braucht es ein separates Frontend (selbst gebaut oder eine Drittanbieter-Chat-UI, die die OpenAI-API spricht).

Fehler 3: GPU-Speicher nur für das Modell selbst dimensionieren, nicht für gleichzeitige Anfragen

Eine GPU mit gerade genug Speicher für eine Kopie eines Modells hat wenig Spielraum für den KV-Cache mehrerer gleichzeitiger Anfragen. Die Dimensionierung an der erwarteten gleichzeitigen Last — nicht nur daran, dass die Modellgewichte in den VRAM passen — vermeidet Out-of-Memory-Fehler unter echtem Traffic.

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.

Quellen

← Zurück zu Lokale LLMs Pro

MCP