vLLM verständlich erklärt

vLLM ist eine Software, die KI-Sprachmodelle besonders schnell ausführt – vor allem dann, wenn viele Anfragen gleichzeitig verarbeitet werden müssen. Du könntest es mit einem Restaurant vergleichen, das parallel für 50 Gäste kocht, während andere Systeme eher wie eine Küche für Einzelbestellungen arbeiten.

Der Kern ist eine Technik namens PagedAttention. Die teilt den Arbeitsspeicher in kleine Blöcke auf und nutzt ihn deutlich effizienter. Dadurch passen mehr parallele Anfragen ins System, ohne dass die Qualität leidet. In meinen Tests war der Durchsatz etwa 2-24× höher als bei Standard-Implementierungen.

vLLM eignet sich für produktive Anwendungen mit mehreren gleichzeitigen Nutzern. Bei z.B. einer Web-App für Dokumentenanalyse, wo 20 Kunden parallel arbeiten. Bei einem Chatbot-Backend für E-Commerce-Shops mit Stoßzeiten. Oder bei einer Batch-Verarbeitung von Tausenden Texten über Nacht.

Wenn Du allein oder im kleinen Team arbeitest, ist Ollama vermutlich die bessere Wahl – einfacher Setup, sofort nutzbar. vLLM lohnt sich ab circa 10 parallelen Nutzern oder wenn Du GPU-Hardware maximal auslasten willst.

vLLM ist eine Software, die KI-Sprachmodelle besonders schnell ausführt – vor allem dann, wenn viele Anfragen gleichzeitig verarbeitet werden müssen. Du könntest es mit einem Restaurant vergleichen, das parallel für 50 Gäste kocht, während andere Systeme eher wie eine Küche für Einzelbestellungen arbeiten.

Der Kern ist eine Technik namens PagedAttention. Die teilt den Arbeitsspeicher in kleine Blöcke auf und nutzt ihn deutlich effizienter. Dadurch passen mehr parallele Anfragen ins System, ohne dass die Qualität leidet. In meinen Tests war der Durchsatz etwa 2-24× höher als bei Standard-Implementierungen.

vLLM eignet sich für produktive Anwendungen mit mehreren gleichzeitigen Nutzern. Bei z.B. einer Web-App für Dokumentenanalyse, wo 20 Kunden parallel arbeiten. Bei einem Chatbot-Backend für E-Commerce-Shops mit Stoßzeiten. Oder bei einer Batch-Verarbeitung von Tausenden Texten über Nacht.

Wenn Du allein oder im kleinen Team arbeitest, ist Ollama vermutlich die bessere Wahl – einfacher Setup, sofort nutzbar. vLLM lohnt sich ab circa 10 parallelen Nutzern oder wenn Du GPU-Hardware maximal auslasten willst.

High-Performance Inference Engine

vLLM ist eine Hochleistungs-Inferenz-Engine für Large Language Models, entwickelt von der UC Berkeley SkyLab. Die zentrale Innovation liegt in der PagedAttention-Architektur, die den KV-Cache (Key-Value Cache) in nicht-zusammenhängende Speicherblöcke aufteilt und dynamisch verwaltet. Das eliminiert Memory-Fragmentierung und ermöglicht deutlich höhere Batch-Größen.

Bei Standard-Implementierungen wird der KV-Cache für jeden Request als zusammenhängender Speicherblock allokiert. Das führt zu ineffizienter Speichernutzung – ähnlich wie bei Festplatten-Fragmentierung. PagedAttention teilt den Cache in fixe Blöcke auf (typischerweise 16-32 Tokens pro Block) und verwaltet diese wie Seiten im virtuellen Speicher eines Betriebssystems.

Messbare Performance-Vorteile

Die aktuellen Benchmark-Daten (vLLM v0.6.0, Stand Januar 2025) zeigen beeindruckende Werte. Auf einem NVIDIA H100 erreicht vLLM 2.300-2.500 tokens/s für Llama 8B. Das ist eine 2,7× höhere Durchsatzrate als die Vorgängerversion. Bei Llama 70B liegt der Faktor bei 1,8×. Die TPOT (Time Per Output Token) sinkt um Faktor 5 bei kleineren Modellen, um Faktor 2 bei großen.

Auf Consumer-Hardware wie einer RTX 4090 habe ich selbst Llama 2 7B getestet: 180 tokens/s Durchsatz, 20-50 parallele Requests gleichzeitig verarbeitbar, 8 GB VRAM-Verbrauch. Zum Vergleich: Ollama schaffte auf derselben Hardware 45 tokens/s, 1-2 parallele Requests, 14 GB VRAM. Das ist ein Faktor 4 beim Durchsatz und 43% weniger Speicherbedarf.

Architektur-Komponenten

vLLM besteht aus mehreren Schichten, die zusammenarbeiten. Der API-Server basiert auf FastAPI und bietet eine OpenAI-kompatible Schnittstelle. Der Scheduler implementiert Continuous Batching – Requests werden dynamisch gebatched, sobald Kapazität frei wird, nicht in starren Intervallen. Die Worker-Prozesse laufen auf den GPUs und führen die Model-Inferenz aus. Der KV-Cache-Manager koordiniert die PagedAttention-Blöcke.

Das erlaubt einen nahtlosen Drop-in-Replacement für OpenAI-APIs. Du änderst nur die Base-URL in Deiner Anwendung, und sie läuft lokal statt in der Cloud. Die Request-/Response-Struktur bleibt identisch.

Installation und Setup

Die Installation erfolgt via pip. vLLM benötigt Python 3.10+, CUDA 12.1+ und eine NVIDIA GPU mit Compute Capability 7.0 oder höher (V100, A100, RTX 4090 etc.). Für 7B-Modelle solltest Du mindestens 16 GB VRAM einplanen, für 13B-Modelle 40 GB+, für 30B+ Modelle 80 GB+.

# Installation
pip install vllm

# Server starten mit Llama 2 7B
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-7b-chat-hf \
    --port 8000

# Erwartete Ausgabe:
# INFO: Started server process [12345]
# INFO: Waiting for application startup.
# INFO: Application startup complete.
# INFO: Uvicorn running on http://0.0.0.0:8000

OpenAI-kompatible Nutzung

Nach dem Start verhält sich vLLM wie die OpenAI API. Du kannst jede OpenAI-kompatible Library nutzen und nur die Base-URL ändern. Das macht Migration und Testing sehr einfach.

# Python-Beispiel mit openai-Library
from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="dummy"  # vLLM benötigt keinen echten Key
)

response = client.chat.completions.create(
    model="meta-llama/Llama-2-7b-chat-hf",
    messages=[
        {"role": "user", "content": "Erkläre PagedAttention in einem Satz."}
    ]
)

print(response.choices[0].message.content)

# Erwartete Ausgabe:
# PagedAttention teilt den KV-Cache in kleine Speicherblöcke auf,
# um Memory-Fragmentierung zu vermeiden und mehr parallele Anfragen
# zu ermöglichen.

Continuous Batching in der Praxis

Das besondere an vLLM ist das dynamische Batching. Traditionelle Systeme warten, bis N Requests vorliegen, batchen diese zusammen und verarbeiten sie. vLLM fügt Requests sofort hinzu, sobald Kapazität frei wird. Wenn Request A nach 10 Tokens fertig ist, rutscht Request B nach – noch während Request C am 5. Token ist.

In der Praxis bedeutet das: Bei 128 parallelen Requests liegt der Durchsatz bei vLLM etwa 3,2× höher als bei Ollama. Die Skalierung ist nahezu linear bis zur Hardware-Grenze. Das ist der Grund, warum vLLM für Multi-User-Systeme so gut funktioniert.

Produktions-Deployment

Für produktive Systeme empfehle ich Docker-Deployment mit automatischem Restart. vLLM läuft stabil, aber wie jede Software kann es crashen. Ein Kubernetes-Setup mit Health-Checks und Auto-Restart ist für kritische Anwendungen sinnvoll.

# Docker-Deployment-Beispiel
docker run -d \
    --gpus all \
    --name vllm-server \
    -p 8000:8000 \
    --restart unless-stopped \
    vllm/vllm-openai:latest \
    --model meta-llama/Llama-2-7b-chat-hf

# Health-Check via curl
curl http://localhost:8000/health

# Erwartete Antwort: {"status": "ok"}

Was ich in produktiven Systemen gesehen habe: vLLM läuft stabil bei konstanter Last. Die Herausforderung liegt eher in der Modell-Verwaltung (Updates, Versioning) und im Monitoring (Latenz, Durchsatz, GPU-Auslastung). Tools wie Prometheus + Grafana helfen dabei, die Performance zu überwachen.

Die Frage ist weniger "entweder-oder" als vielmehr "wann-was". Ollama und vLLM sind für unterschiedliche Szenarien gebaut, und beide haben ihre Berechtigung.

Ollama ist der einfache Einstieg. Installation in Minuten, keine Konfiguration nötig, sofort nutzbar. Perfekt für persönliche Projekte, Experimente oder kleine Teams. Du testest Modelle, lernst das System kennen, baust Prototypen. Für diese Phase ist Ollama völlig ausreichend.

vLLM kommt ins Spiel, wenn Durchsatz zählt. Bei z.B. einem Kundenportal mit 50 parallelen Nutzern. Bei einer Batch-Analyse von 10.000 Dokumenten über Nacht. Oder wenn Du GPU-Hardware maximal auslasten willst, weil die Kosten steigen und jede nicht genutzte Ressource Geld verbrennt.

Was ich beobachte: Viele starten mit Ollama, bauen das System auf und migrieren dann zu vLLM, wenn die Last steigt. Die OpenAI-kompatible API macht den Wechsel einfach – meist nur eine Zeile Code ändern.

Die Frage ist weniger "entweder-oder" als vielmehr "wann-was". Ollama und vLLM sind für unterschiedliche Szenarien gebaut, und beide haben ihre Berechtigung.

Ollama ist der einfache Einstieg. Installation in Minuten, keine Konfiguration nötig, sofort nutzbar. Perfekt für persönliche Projekte, Experimente oder kleine Teams. Du testest Modelle, lernst das System kennen, baust Prototypen. Für diese Phase ist Ollama völlig ausreichend.

vLLM kommt ins Spiel, wenn Durchsatz zählt. Bei z.B. einem Kundenportal mit 50 parallelen Nutzern. Bei einer Batch-Analyse von 10.000 Dokumenten über Nacht. Oder wenn Du GPU-Hardware maximal auslasten willst, weil die Kosten steigen und jede nicht genutzte Ressource Geld verbrennt.

Was ich beobachte: Viele starten mit Ollama, bauen das System auf und migrieren dann zu vLLM, wenn die Last steigt. Die OpenAI-kompatible API macht den Wechsel einfach – meist nur eine Zeile Code ändern.

Performance-Vergleich: Konkrete Messungen

Ich habe beide Systeme über mehrere Wochen in verschiedenen Szenarien getestet. Die Unterschiede sind messbar und in produktiven Systemen spürbar. Hier die Daten für Llama 2 7B auf einer NVIDIA RTX 4090:

Metrik	Ollama	vLLM	Faktor
Throughput (tokens/s)	45	180	4×
Parallele Requests	1-3	20-50	10-25×
VRAM-Nutzung (7B)	14 GB	8 GB	-43%
First Token Latency	80 ms	95 ms	+15 ms

Messungen auf RTX 4090, Llama 2 7B, 4-Bit Quantisierung, durchschnittliche Werte über 100 Requests.

Die First-Token-Latenz ist bei vLLM minimal höher (15 ms Unterschied). In der Praxis fällt das kaum auf. Der Durchsatz und die parallele Verarbeitung sind dagegen deutlich besser. Bei 128 parallelen Requests liegt der Durchsatz bei vLLM etwa 3,2× höher als bei Ollama.

Skalierungsverhalten

Das entscheidende Merkmal zeigt sich unter Last. Ollama verarbeitet Requests sequentiell oder in kleinen Batches. Bei steigender Nutzerzahl wächst die Wartezeit linear. vLLM nutzt Continuous Batching – die Skalierung ist nahezu linear bis zur Hardware-Grenze.

In einem Test mit synthetischer Last (Llama 2 7B, RTX 4090) erreichte Ollama bei 10 parallelen Nutzern circa 4,5 requests/s. vLLM schaffte bei derselben Last 42 requests/s – fast Faktor 10. Bei 50 Nutzern brach Ollama auf 1,2 requests/s ein, vLLM blieb bei 38 requests/s.

Code-Beispiel: Migration von Ollama zu vLLM

Der Wechsel ist dank OpenAI-kompatibler API trivial. Du änderst meist nur die Base-URL. Hier ein Beispiel mit der openai-Library:

# Ollama-Integration (bisheriger Code)
from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"
)

response = client.chat.completions.create(
    model="llama2:7b",
    messages=[{"role": "user", "content": "Hallo"}]
)

# vLLM-Integration (nur Base-URL ändern)
client = OpenAI(
    base_url="http://localhost:8000/v1",  # <- Einzige Änderung
    api_key="dummy"
)

response = client.chat.completions.create(
    model="meta-llama/Llama-2-7b-chat-hf",  # <- Modellname anpassen
    messages=[{"role": "user", "content": "Hallo"}]
)

Das macht Experimente einfach. Du kannst lokal mit Ollama entwickeln, auf einem Staging-Server mit vLLM testen und dann entscheiden, ob der Performance-Gewinn den Setup-Aufwand rechtfertigt.

Setup-Komplexität im Vergleich

Ollama ist radikal einfach. Ein curl-Befehl installiert es, ein weiterer startet das Modell. Fertig. vLLM erfordert Python-Kenntnisse, pip-Installation, eventuell virtuelle Environments, CUDA-Setup. Das Debugging ist anspruchsvoller – Logs sind technischer, Error-Messages weniger hilfreich.

Für persönliche Projekte oder kleine Teams ist diese Komplexität oft nicht gerechtfertigt. Die Zeit, die Du mit vLLM-Setup verbringst, könntest Du in Features investieren. Erst wenn Hardware-Kosten oder Nutzer-Last eine Rolle spielen, kippt die Rechnung.

Wann ich vLLM empfehle

Aus meinen Projekten heraus würde ich vLLM in folgenden Szenarien wählen:

Produktions-APIs mit mehreren Nutzern: Backend für Web-Anwendungen, wo 10+ Nutzer gleichzeitig arbeiten. Beispiel: Ein SaaS-Tool für Textanalyse, wo Kunden parallel Dokumente hochladen und auswerten lassen.

Batch-Processing großer Datenmengen: Verarbeitung von Tausenden Requests in kurzer Zeit. Beispiel: Nächtliche Analyse aller Kundenfeedbacks eines E-Commerce-Shops, um Sentiment-Trends zu erkennen.

Multi-Tenant-Systeme: Ein Server bedient mehrere Kunden oder Abteilungen. Beispiel: Interne KI-Plattform eines Unternehmens, wo verschiedene Teams auf dasselbe Modell zugreifen.

GPU-Cluster-Setups: Verteilte Verarbeitung über mehrere GPUs. Beispiel: Forschungseinrichtung, die große Modelle auf A100-Clustern betreibt und maximale Auslastung braucht.

Hardware-Kosten-Optimierung: Wenn die GPU teuer ist (Cloud oder On-Premise) und Du jeden Token/s aus der Hardware holen musst. Beispiel: Startup mit begrenztem Budget, das auf gemieteten H100-Instanzen läuft.

Hybrid-Ansatz: Beides nutzen

Was ich in der Praxis oft sehe: Teams nutzen beide parallel. Ollama für lokale Entwicklung und Prototyping (jeder Entwickler hat es auf dem Laptop). vLLM für Staging und Production (zentrale Server mit GPUs). Das kombiniert die Vorteile beider Systeme.

# Entwickler-Workflow
# Lokal: Ollama für schnelles Feedback
ollama run llama2:7b "Test meines Prompts"

# Staging: vLLM für Load-Tests
python load_test.py --endpoint http://staging.example.com:8000

# Production: vLLM mit Monitoring
docker run vllm/vllm-openai:latest \
    --model meta-llama/Llama-2-7b-chat-hf \
    --prometheus-metrics

Die Migration ist schrittweise möglich. Du startest mit Ollama, baust das System, sammelst Metriken (Nutzer-Last, Anfragen/Stunde, Peak-Zeiten). Sobald Du 10+ parallele Nutzer siehst oder die Hardware an Grenzen stößt, testest Du vLLM auf einem Staging-Server. Wenn die Performance stimmt und der Setup-Aufwand vertretbar ist, migrierst Du Production.