Was ist vLLM? Ein praktischer Leitfaden für die leistungsstarke LLM-Inferenz-Engine

vLLM ist eine Open-Source-Inferenz- und Bereitstellungs-Engine für große Sprachmodelle. Sie lädt ein Modell auf eine oder mehrere GPUs und stellt es über eine OpenAI-kompatible HTTP-API bereit, wobei zwei Techniken – PagedAttention und kontinuierliches Batchen – eingesetzt werden, um deutlich höhere Durchsätze als bei naiver Bereitstellung zu erreichen. Sie wurde am Sky Computing Lab der UC Berkeley entwickelt und 2023 veröffentlicht.

Was vLLM ist und für wen es gedacht ist

Stellen Sie sich vLLM als Produktionsvariante zu Desktop-Werkzeugen wie Ollama vor. Beide nehmen ein Modell entgegen und beantworten Anfragen, optimieren jedoch für gegensätzliche Anforderungen: Ollama optimiert für eine einzelne Person, die auf bescheidener Hardware eine Antwort erhält; vLLM optimiert für Durchsatz: Gesamtanzahl generierter Tokens pro Sekunde bei Dutzenden oder Hunderten gleichzeitiger Anfragen, die dieselbe GPU belasten.

Das macht vLLM zum richtigen Werkzeug, wenn Sie:

• Ein LLM hinter einer internen oder öffentlichen API bereitstellen, die von mehreren Personen oder Diensten genutzt wird
• Batch-Jobs ausführen – Klassifizierung, Extraktion, Generierung synthetischer Daten – über große Datensätze
• Eine kostenpflichtige API durch ein selbst gehostetes Open-Weight-Modell zu ersetzen, um die Kosten pro Token zu senken (der Selbsthosting- vs. API-Kostenvergleichsrechner hilft Ihnen zu prüfen, ob die GPU-Rechnung bei Ihrem Volumen tatsächlich günstiger ist als die API-Rechnung)

Und das falsche Werkzeug, wenn Sie einen Chat-Assistenten auf Ihrem eigenen Laptop, gelegentliche Einzelbenutzer-Inferenz oder etwas anderes auf einem Rechner ohne leistungsstarke GPU benötigen. vLLM setzt einen Server voraus: Linux, als Standardpfad eine NVIDIA-GPU (AMD ROCm, Intel-, TPU- und CPU-Backends existieren, sind aber weniger verbreitet) sowie eine Arbeitslast mit Konkurrenz.

Bei der Markteinführung im Jahr 2023 zeigten vLLMs Benchmarks bis zu das 24-fache Durchsatzvolumen im Vergleich zur Bereitstellung mit reinem Hugging Face Transformers sowie etwa das 2- bis 3,5-fache gegenüber den damaligen Inferenzsystemen. Die genauen Zahlen variieren je nach Modell, Hardware und Arbeitslast – doch der Grund für diese Lücke lohnt sich zu verstehen, denn er zeigt Ihnen, wann vLLM wirklich relevant wird.

PagedAttention in einfachen Worten

Wenn ein LLM Text generiert, hält es einen KV-Cache in GPU-Speicher: die Attention-Schlüssel und -Werte für jedes Token in jeder aktiven Konversation. Dieser Cache wächst mit jedem generierten Token und kann bei langen Kontexten mehr VRAM belegen als die Modellgewichte selbst.

Vor vLLM reservierten Inferenz-Engines für jede Anfrage einen zusammenhängenden Speicherblock mit Größe für die maximal mögliche Sequenzlänge, da sie im Voraus nicht wussten, wie lang die Ausgabe werden würde. Die meisten Anfragen enden deutlich vor Erreichen der maximalen Länge, sodass der größte Teil dieses reservierten Speichers ungenutzt blieb. In der vLLM-Studie wurde festgestellt, dass frühere Systeme durch diese Art der Fragmentierung 60–80 % des KV-Cache-Speichers verschwendeten.

PagedAttention übernimmt die Lösung vom Betriebssystem: virtuelles Speicherpaging. Der KV-Cache wird in kleine, feste Blöcke (standardmäßig je 16 Tokens) unterteilt, die bedarfsgerecht zugewiesen werden und nicht zusammenhängend sein müssen. Eine Blocktabelle ordnet die logischen Positionen jeder Sequenz den jeweils freien physischen Blöcken zu – genau wie ein Betriebssystem virtuelle Seiten physikalischem RAM zuordnet. Der Speicherverlust sinkt auf unter 4 %, und Blöcke können sogar zwischen Sequenzen gemeinsam genutzt werden (nützlich, wenn mehrere Ergänzungen aus einem einzigen Prompt generiert werden).

Die praktische Folge: deutlich mehr gleichzeitige Sequenzen passen in denselben VRAM. Mehr Sequenzen im Speicher bedeuten größere effektive Batches, und größere Batches halten eine GPU ausgelastet. Das ist die gesamte Durchsatzgeschichte – PagedAttention beschleunigt keine einzelne Anfrage; es ermöglicht lediglich, viele mehr gleichzeitig auszuführen.

Kontinuierliches Batchen

Die zweite Technik greift nicht den Speicher, sondern die Planung an. Bei naiver Batch-Verarbeitung werden Anfragen gruppiert, der gesamte Batch wird bis zum Abschluss ausgeführt, und erst danach beginnt der nächste Batch – so wartet eine Anfrage, die nach 20 Tokens fertig ist, auf diejenige, die 2.000 Tokens generiert, während neue Anfragen außerhalb warten. Kontinuierliches Batchen (auch Iterationsstufen-Planung genannt) bildet den Batch bei jedem Generierungsschritt neu: Abgeschlossene Sequenzen verlassen sofort, wartende Anfragen treten sofort ein.

Die GPU bleibt ausgelastet, kurze Anfragen werden nicht durch lange blockiert, und sowohl die Latenz unter Last als auch der Durchsatz verbessern sich. PagedAttention und kontinuierliches Batchen verstärken sich gegenseitig: Ersteres passt mehr Sequenzen in den Speicher, Letzteres stellt sicher, dass diese Kapazität tatsächlich genutzt wird.

Installation von vLLM: typische Hindernisse

Die Installation erfolgt mit einem einzigen Befehl, doch drei Einschränkungen verursachen die meisten fehlgeschlagenen Installationen:

1. Python-Version. Aktuelle Versionen richten sich grob an Python 3.9–3.12, wobei das unterstützte Fenster zwischen den Releases variiert. Falls pip keine passende Distribution findet, ist Ihre Python-Version der erste Verdächtige.
2. CUDA-Version. Die vorgefertigten Wheels sind gegen eine bestimmte CUDA-Hauptversion kompiliert (für aktuelle Releases CUDA 12.x). Sie benötigen einen aktuellen NVIDIA-Treiber; Wheels für andere CUDA-Versionen existieren für einige Releases über spezielle Index-URLs, die in der vLLM-Dokumentation dokumentiert sind.
3. PyTorch-Konflikte. vLLM bindet eine eigene PyTorch-Version fest. Die Installation in eine Umgebung, die bereits eine andere Torch-Version enthält, ist die klassische Ursache für kryptische Importfehler. Verwenden Sie daher stets eine frische virtuelle Umgebung.

Hardwareseitig erfordert der Mainstream-Pfad eine NVIDIA-GPU mit Compute Capability 7.0 oder höher – V100, T4, RTX-20-Serie und neuer. Wenn Sie Hardware auswählen, lesen Sie den Leitfaden zu den besten GPUs für lokales LLM-Hosting.

Linux (die unterstützte Plattform)

python3 -m venv vllm-env
source vllm-env/bin/activate
pip install vllm

Die vLLM-Dokumentation empfiehlt zudem uv (uv venv und anschließend uv pip install vllm), da uv die festgelegten Abhängigkeiten schneller auflöst. Unabhängig davon steht jedoch immer der Punkt einer sauberen Umgebung im Vordergrund.

Windows: Verwenden Sie WSL2 oder Docker

Es gibt keine native Windows-Version. Funktionierende Setups sind WSL2 mit einer Ubuntu-Distribution (NVIDIAs Windows-Treiber leitet CUDA an WSL2 weiter, sodass die oben genannten Linux-Anweisungen innerhalb von WSL2 funktionieren) oder Docker Desktop mit aktivierter GPU-Unterstützung unter Verwendung des offiziellen Images:

docker run --gpus all -p 8000:8000 vllm/vllm-openai --model Qwen/Qwen2.5-7B-Instruct

macOS: Nicht das richtige Werkzeug

vLLM bietet keinen Metal-/Apple-GPU-Backend. Ein experimenteller CPU-Build kann zwar aus dem Quellcode kompiliert werden, widerspricht aber dem Zweck einer Durchsatz-Engine. Auf einem Mac verwenden Sie stattdessen LM Studio oder Ollama – beide nutzen die GPU von Apple Silicon korrekt.

Serverbetrieb: vllm serve

Mit einem einzigen Befehl starten Sie einen Inferenzserver (das Modell wird beim ersten Start automatisch von Hugging Face heruntergeladen):

vllm serve Qwen/Qwen2.5-7B-Instruct

Dieser stellt das Modell am Port 8000 bereit. Die Flags, die Sie tatsächlich benötigen werden:

Beachten Sie, dass vLLM standardmäßig den Großteil der GPU-Speicherkapazität vorab reserviert – ein nahezu vollständig belegter VRAM-Status ist daher normal und kein Speicherleck. Bevor Sie ein Modell auswählen, prüfen Sie mit dem VRAM-Rechner, ob Gewichte plus KV-Cache auf Ihre Grafikkarte passen; als grobe Faustregel benötigen FP16-Gewichte etwa 2 GB pro Milliarde Parameter, 8-Bit-Gewichte etwa die Hälfte davon – zuzüglich Puffer für den Cache.

Die OpenAI-kompatible API

Der Server implementiert die OpenAI-API-Oberfläche: /v1/chat/completions, /v1/completions, /v1/models, und /v1/embeddings (für Embedding-Modelle). Jede Software, die auf dem OpenAI-SDK basiert, funktioniert unverändert, sobald Sie die Basis-URL anpassen:

curl http://localhost:8000/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{
    "model": "Qwen/Qwen2.5-7B-Instruct",
    "messages": [{"role": "user", "content": "Erklären Sie PagedAttention in einem Satz."}]
  }'

In Python lautet die gesamte Migration: OpenAI(base_url="http://localhost:8000/v1", api_key="none") Diese Kompatibilität ist ein wesentlicher Grund für die weite Verbreitung von vLLM: Bestehende Tools, Agenten und Frameworks funktionieren ohne Änderungen weiter.

Wann Ollama oder llama.cpp die bessere Wahl sind

Auswählen Ollama wenn nur ein Nutzer vorhanden ist und die Hardware ein Laptop oder Desktop-PC ist – die Installation erfolgt über einen einzigen Installer, und es kann problemlos quantisierte GGUF-Modelle auf CPUs und Apple Silicon ausgeführt werden (siehe Kompletter Leitfaden zu Ollama). Wählen Sie llama.cpp direkt, wenn maximale Portabilität erforderlich ist oder Sie die Inferenz in eine andere Anwendung einbetten möchten. Wählen Sie vLLM wenn Anfragen gleichzeitig eintreffen und Tokens pro Sekunde pro Dollar die entscheidende Kenngröße ist. Bei einer Einzelbenutzer-Workload bringt PagedAttention kaum Vorteile; bei einer Workload mit 50 Benutzern dagegen enorme Leistungssteigerungen.

Häufig gestellte Fragen

Ist vLLM kostenlos?

Ja. vLLM ist quelloffen unter der Apache-2.0-Lizenz, ursprünglich entwickelt an der UC Berkeley und mittlerweile als Community-Projekt unter der Trägerschaft der PyTorch Foundation weiterentwickelt. Es gibt keine kostenpflichtige Version; Ihre Kosten beschränken sich auf Hardware und Strom.

Kann vLLM GGUF-Modelle wie Ollama ausführen?

GGUF-Unterstützung existiert, ist jedoch experimentell und nicht der vorgesehene Weg. vLLM basiert primär auf Standard-Hugging-Face-Checkpoints (safetensors), wobei Quantisierung über AWQ-, GPTQ- oder FP8-Checkpoints erfolgt. Falls Ihre Modelle ausschließlich im GGUF-Format vorliegen, sind Ollama oder llama.cpp die natürlicheren Wahlmöglichkeiten.

Funktioniert vLLM auch ohne NVIDIA-GPU?

Es gibt Backends für AMD ROCm, Intel-Hardware, Google TPUs, AWS Neuron und CPUs; der NVIDIA-CUDA-Pfad ist jedoch bei weitem am weitesten fortgeschritten und am besten dokumentiert. Ein rein CPU-basierter vLLM-Betrieb eignet sich lediglich für Tests, nicht für den Durchsatz, für den die Engine eigentlich konzipiert wurde.

Wie viel VRAM benötigt vLLM?

Genug für Modellgewichte plus KV-Cache: grob gerechnet etwa 2 GB pro Milliarde Parameter bei FP16, bei 8-Bit etwa die Hälfte davon – zuzüglich Cache-Puffer, der mit Kontextlänge und Parallelität zunimmt. Ein 7B-Modell in FP16 passt problemlos auf eine 24-GB-Grafikkarte; ein 70B-Modell benötigt entweder mehrere GPUs oder eine starke Quantisierung. Die Referenz zu den VRAM-Anforderungen nach Modell enthält konkrete Zahlen pro Modell.

Wie vergleicht sich vLLM mit TensorRT-LLM, SGLang oder TGI?

Alle gehören derselben Kategorie an – Produktions-Inferenz-Engines. vLLM bietet im Allgemeinen die breiteste Modellunterstützung, die einfachste Einrichtung und die größte Community; TensorRT-LLM kann zwar mehr Spitzenleistung aus NVIDIA-Hardware herausholen, erfordert dafür aber einen aufwändigeren Build- und Tuning-Prozess; SGLang ist ein starker Konkurrent, insbesondere bei strukturierten Ausgaben. Führen Sie vor einer Entscheidung Benchmarks mit Ihrem eigenen Modell und Ihrer spezifischen Workload durch – Rangfolgen können sich zwischen Versionen ändern.

Kann ich Modelle mit vLLM feinjustieren?

Nein – vLLM ist ausschließlich für Inferenz gedacht. Es wird häufig als schneller Generierungs-Backend innerhalb von RLHF-Trainingsframeworks eingesetzt, doch das Training selbst erfolgt an anderer Stelle. Führen Sie Feinjustierungen mit Tools wie Hugging Face TRL, Axolotl oder Unsloth durch und stellen Sie das resultierende Checkpoint anschließend mit vLLM bereit.