vLLM: Was ist das, für wen ist es gedacht und wann sollte man es verwenden ?

#vLLM in drei Sätzen

vLLM ist eine Python-Bibliothek und ein Inferenzserver, die 2023 am Sky Computing Lab der Universität Berkeley entstanden und unter Apache 2.0 veröffentlicht wurden, einer permissiven Lizenz, die eine kommerzielle Wiederverwendung ohne Einschränkungen erlaubt. vLLM lädt ein Modell im Hugging-Face-Format, meist in safetensors, auf eine oder mehrere GPUs und stellt es über eine OpenAI-kompatible HTTP-API bereit. Dadurch lässt sich jeder bereits für die OpenAI-API geschriebene Client anbinden, ohne eine Zeile Anwendungscode zu ändern – nur die Basis-URL muss angepasst werden. Seine Daseinsberechtigung lässt sich in einem Wort zusammenfassen: Durchsatz, also die Gesamtzahl der Tokens, die die GPU pro Sekunde erzeugt, wenn zehn, fünfzig oder zweihundert unterschiedliche Anfragen gleichzeitig eingehen und alle eine schnelle Antwort erhalten müssen.

#Das Problem, das vLLM löst

Wenn ein LLM Text generiert, hält es im Speicher fest, was es bereits gelesen und geschrieben hat: im KV-Cache. Dieser Cache wächst mit jedem Token, und seine endgültige Größe ist unvorhersehbar, weil man nicht im Voraus weiß, ob die Antwort zwanzig oder zweitausend Wörter umfassen wird. Inferenzserver der ersten Generation reservierten daher für jede Anfrage einen zusammenhängenden Speicherblock, der für den ungünstigsten Fall dimensioniert war.

Das bezifferte Ergebnis steht ausdrücklich im grundlegenden vLLM-Paper (Kwon et al., SOSP 2023) und wird auch vom Projektteam selbst aufgegriffen: In bestehenden Systemen wurden 60 bis 80 % des für den KV-Cache reservierten Speichers schlicht verschwendet – durch vorsorglich überhöhte Speicherreservierungen und durch Fragmentierung, die unbrauchbare Lücken zwischen den zugewiesenen Blöcken hinterlässt. Weniger tatsächlich nutzbarer Speicher bedeutet zwangsläufig, dass auf derselben Karte weniger Anfragen parallel bedient werden können. Eine mehrere Tausend Euro teure GPU arbeitet damit letztlich nur mit einem verschwindend kleinen Bruchteil ihrer theoretischen Kapazität, obwohl die Stromrechnung und die Abschreibung der Hardware unverändert bleiben.

#PagedAttention und kontinuierliches Batching

vLLM beruht auf zwei Ideen. Die erste, PagedAttention, ist Betriebssystemen entlehnt: Statt eines großen zusammenhängenden Blocks pro Anfrage wird der KV-Cache in kleine Seiten fester Größe aufgeteilt, die bei Bedarf zugewiesen und an beliebigen Stellen im Speicher abgelegt werden. Eine Tabelle verknüpft die logische Reihenfolge der Tokens mit den physischen Speicherorten der Seiten, genau wie beim virtuellen Speicher eines Computers. Laut den Autoren sinkt die Speicherverschwendung auf unter 4 %.

Die zweite Idee ist kontinuierliches Batching, das die erste ergänzt. Ein klassischer Server fasst Anfragen zu Batches zusammen und wartet, bis alle Anfragen eines Batches abgeschlossen sind, bevor er den nächsten startet: Die kurze Anfrage, die sofort hätte zurückgegeben werden können, wartet unnötig auf die lange, die noch die GPU für sich beansprucht. vLLM hingegen stellt den Batch bei jedem erzeugten Token, also bei jedem Decodierungsschritt, vollständig neu zusammen. Sobald eine Antwort abgeschlossen ist, wird ihr Platz im Batch sofort einer Anfrage aus der Warteschlange zugewiesen, und die GPU läuft niemals durch unnötige Auffülloperationen ins Leere. Die Kombination aus dieser ständigen Wiederverwendung der Plätze und der seitenbasierten Speicherverwaltung liefert den Großteil des beobachteten Durchsatzgewinns gegenüber Inferenz-Engines, die jeweils nur für einen einzelnen Benutzer ausgelegt sind.

Gemeinsame Präfixe

Wenn mehrere Anfragen mit genau demselben Text beginnen (einem Systemprompt, einem gemeinsamen Dokument), werden die entsprechenden Seiten nur einmal berechnet und von diesen Anfragen gemeinsam genutzt. Das ist Prefix-Caching.

Tensorparallele Verarbeitung

Ein Modell, das zu groß ist, um auf eine einzelne Karte zu passen, wird mit einer einzigen Startoption, --tensor-parallel-size, automatisch auf mehrere GPUs desselben Rechners verteilt.

Serverseitige Quantisierung

vLLM liest die Formate AWQ, GPTQ und FP8, die für GPU-Berechnungen in Batches entwickelt wurden. GGUF wird nur experimentell unterstützt.

OpenAI-kompatible API

Die Routen /v1/chat/completions und /v1/completions antworten genau wie die von OpenAI: Bei einer bestehenden Anwendung wird lediglich die Basis-URL geändert, ohne eine einzige Zeile der Geschäftslogik neu schreiben zu müssen.

#Was vLLM in den Speicher lädt

Das ist die häufigste Überraschung für alle, die von Ollama kommen und erwarten, ihre gewohnte Arbeitsweise direkt übernehmen zu können. Ollama lädt standardmäßig eine auf 4 Bit quantisierte GGUF-Datei herunter, die auf eine handelsübliche Grafikkarte passen soll. vLLM hingegen lädt standardmäßig die Gewichte so, wie sie auf Hugging Face veröffentlicht wurden, meist in BF16 (16-Bit-Präzision), also etwa 2 GB pro Milliarde Modellparameter. Dasselbe Modell benötigt unter vLLM daher grob dreimal so viel Arbeitsspeicher wie unter Ollama. Dabei ist der KV-Cache noch nicht einmal eingerechnet, der mit jeder laufenden Unterhaltung wächst. Das erklärt, warum eine für Ollama ausreichende Grafikkarte für vLLM viel zu klein sein kann, wenn das Format der Gewichte nicht geändert wird.

Die gängigste Lösung besteht darin, eine bereits für GPUs quantisierte Version bereitzustellen statt der vollständigen Originalgewichte: Ein AWQ- oder GPTQ-Modell mit 4 Bit belegt ungefähr genauso viel Speicher wie ein entsprechendes GGUF-Q4-Modell, und das FP8-Format halbiert gegenüber BF16 ungefähr die Größe auf neueren Grafikkarten, die es nativ unterstützen. Die große Mehrheit der wirklich populären Modelle ist bereits in einem dieser Formate auf Hugging Face veröffentlicht, oft schon am Tag ihrer offiziellen Veröffentlichung.

#Unterstützte Hardware und Systeme

#Start in fünf Minuten

Auf einem Linux-Rechner mit einer NVIDIA-GPU und aktuellen Treibern lässt sich die vollständige Installation mit wenigen Zeilen in einer sauberen Python-Umgebung durchführen, ohne vorher eine komplexe Konfiguration schreiben zu müssen. Der Befehl vllm serve lädt beim allerersten Start das angegebene Modell von Hugging Face herunter, lädt es in den Speicher und stellt anschließend sofort die API auf dem Standardport 8000 bereit, sodass sie Anfragen im standardmäßigen OpenAI-Format empfangen kann.

python -m venv vllm-env && source vllm-env/bin/activate
pip install vllm

vllm serve Qwen/Qwen3-8B --max-model-len 8192

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "Qwen/Qwen3-8B", "messages": [{"role": "user", "content": "Bonjour"}]}'

Die Option --max-model-len sollte bereits beim allerersten Start ausdrücklich festgelegt werden: Ohne sie dimensioniert vLLM den KV-Cache für das vom Modell angegebene maximale Kontextfenster, bei neueren Modellen manchmal 128.000 Tokens oder mehr, und verweigert den Start vollständig, wenn der verfügbare Speicher auf der Grafikkarte für diese Standarddimensionierung nicht ausreicht – ein häufiger Fehler beim allerersten Versuch. Der eigentliche Produktionsbetrieb mit Docker-Container, Authentifizierung der Aufrufe, kontinuierlicher Überwachung und schrittweiser Skalierung wird in einem separaten, ausführlicheren Leitfaden behandelt.

• vLLM in der Produktion bereitstellen: Docker, Sicherheit, Überwachung
• Offizielle Dokumentation von vLLM
• Der Artikel PagedAttention (Kwon et al., 2023)
• Quelle: die offizielle Ankündigung von vllm-metal (22.09.2026)
• Quelle: offizielles GitHub-Repository des vLLM-Projekts

#Für wen und für wen nicht

• llama.cpp vs vLLM vs ExLlama: drei Inferenz-Engines, drei Anwendungsfälle
• llama.cpp: Was ist das, und sollten Sie von Ollama wechseln?
• Berechnen Sie die notwendige VRAM für Ihr Modell

#FAQ