vLLM Quickstart: Hochperformanter LLM-Serving – im Jahr 2026

vLLM ist ein hochdurchsatzstarker, speichereffizienter Inferenz- und Serving-Engine für Large Language Models (LLMs), der vom Sky Computing Lab der UC Berkeley entwickelt wurde.

Sein PagedAttention-Algorithmus behandelt den KV-Cache wie virtuelle Speicherseiten des Betriebssystems und kombiniert ihn mit continuous batching – die Kombination, die vLLM zum Standard-Engine für produktionsreifes LLM-Serving gemacht hat. Um zu sehen, wie vLLM sich im Vergleich zu Ollama, Docker Model Runner, LocalAI und Cloud-Anbietern einordnet – einschließlich der Kompromisse zwischen Kosten und Infrastruktur – siehe LLM-Hosting: Lokale, selbst gehostete und Cloud-Infrastrukturen im Vergleich.

Dieser Leitfaden ist aktuell für vLLM v0.31.0 (Oktober 2026). Zwei Dinge haben sich in letzter Zeit geändert, falls Sie von älteren Tutorials kommen: python -m vllm.entrypoints.openai.api_server ist veraltet und gibt eine Warnung aus — vllm serve ist jetzt der Standard-CLI-Befehl — und vorgebaute Wheels zielen standardmäßig auf CUDA 12.9, nicht auf 11.8.

Was ist vLLM?

vLLM (virtual LLM) ist eine Open-Source-Bibliothek für schnelle LLM-Inferenz und -Serving, die schnell zum Industriestandard für Produktions-Deployments geworden ist. 2023 veröffentlicht, führte es PagedAttention ein, eine bahnbrechende Speicherverwaltungstechnik, die die Serving-Effizienz erheblich verbessert.

Key Features

Hoher Durchsatz: Die Benchmarks aus der Launch-Ära von vLLM berichteten von einem 14- bis 24-fach höheren Durchsatz als HuggingFace Transformers auf derselben Hardware, und der Engine hat diese Führung durch continuous batching, optimierte CUDA-Kernels und den PagedAttention-Algorithmus, der Speicherfragmentierung eliminiert, beibehalten.

OpenAI-API-Kompatibilität: vLLM enthält einen integrierten API-Server, der vollständig mit dem OpenAI-Format kompatibel ist. Dies ermöglicht eine nahtlose Migration von OpenAI zu selbst gehosteter Infrastruktur, ohne den Anwendungscode zu ändern. Zeigen Sie einfach Ihren API-Client auf den Endpoint von vLLM und es funktioniert transparent.

PagedAttention-Algorithmus: Die Kerninnovation hinter der Leistung von vLLM ist PagedAttention, das das Konzept der virtuellen Speicherverwaltung auf Mechanismen der Aufmerksamkeitsberechnung anwendet. Anstatt zusammenhängende Speicherblöcke für KV-Caches zuzuweisen (was zu Fragmentierung führt), teilt PagedAttention den Speicher in fest dimensionierte Blöcke, die bei Bedarf zugewiesen werden können. Dies reduziert die Speicherineffizienz um bis zu das 4-Fache und ermöglicht viel größere Batch-Größen.

Continuous Batching: Im Gegensatz zu statischem Batching, bei dem man auf den Abschluss aller Sequenzen wartet, verwendet vLLM continuous (rolling) Batching. Sobald eine Sequenz abgeschlossen ist, kann eine neue zum Batch hinzugefügt werden. Dies maximiert die GPU-Auslastung und minimiert die Latenz für eingehende Anfragen.

Multi-GPU-Unterstützung: vLLM unterstützt Tensor Parallelism und Pipeline Parallelism für die Verteilung großer Modelle auf mehrere GPUs. Es kann Modelle effizient bereitstellen, die nicht in den Speicher einer einzelnen GPU passen, und unterstützt Konfigurationen von 2 bis 8+ GPUs.

Breite Modellunterstützung: Kompatibel mit beliebten Modellarchitekturen einschließlich LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma und vielen anderen. Unterstützt sowohl instruction-tuned als auch Basismodelle vom HuggingFace Hub.

Wann vLLM verwendet werden sollte

vLLM excelliert in bestimmten Szenarien, in denen seine Stärken zum Tragen kommen:

Produktions-API-Dienste: Wenn Sie ein LLM vielen gleichzeitigen Benutzern über eine API bereitstellen müssen, machen der hohe Durchsatz und das effiziente Batching von vLLM es zur besten Wahl. Unternehmen, die Chatbots, Code-Assistenten oder Inhaltsgenerierungsdienste betreiben, profitieren von seiner Fähigkeit, Hunderte von Anfragen pro Sekunde zu verarbeiten.

Workloads mit hoher Konnektivität: Wenn Ihre Anwendung viele gleichzeitige Benutzer hat, die Anfragen stellen, ermöglichen das continuous Batching und PagedAttention von vLLM das Bereitstellen für mehr Benutzer mit derselben Hardware im Vergleich zu Alternativen.

Kostenoptimierung: Wenn GPU-Kosten ein Anliegen sind, bedeutet der überlegene Durchsatz von vLLM, dass Sie denselben Traffic mit weniger GPUs bedienen können, was die Infrastrukturkosten direkt senkt. Die 4-fache Speichereffizienz durch PagedAttention ermöglicht auch die Verwendung kleinerer, günstigerer GPU-Instanzen.

Kubernetes-Deployments: Das zustandslose Design und die containerfreundliche Architektur von vLLM machen es ideal für Kubernetes-Cluster. Seine konsistente Leistung unter Last und die geradlinige Ressourcengliederung integrieren sich gut mit cloud-nativer Infrastruktur.

Wann vLLM NICHT verwendet werden sollte: Für lokale Entwicklung, Experimente oder Ein-Benutzer-Szenarien bieten Tools wie Ollama oder llama.cpp ein besseres Benutzererlebnis mit einfacherer Einrichtung. Die Komplexität von vLLM ist gerechtfertigt, wenn Sie seine Leistungsvorteile für Produktions-Workloads benötigen.

Wie man vLLM installiert

Voraussetzungen

Stellen Sie vor der Installation von vLLM sicher, dass Ihr System diese Anforderungen erfüllt:

• OS: Linux mit glibc 2.35 oder neuer (Ubuntu 22.04+, Debian 12+, RHEL 9+)
• GPU: NVIDIA GPU mit Compute Capability 7.5 oder höher (T4, A10, A100, L4, H100, B200, RTX 20/30/40/50 Serien). Ältere Karten der 7.0-Generation wie die V100 stehen nicht mehr auf der unterstützten Liste. AMD-GPUs werden über separate ROCm-Wheels unterstützt — siehe ROCm vs Vulkan für AMD Local LLM Hosting für das AMD-spezifische Image, Device-Flags und Kernel-Abdeckungs-Einschränkungen.
• CUDA: Die Standard-Pip-Wheels wurden gegen CUDA 12.9 kompiliert; Varianten für 12.8 und 13.0 werden parallel veröffentlicht. Blackwell-GPUs (B200, GB200) erfordern CUDA 12.8+. Ihr NVIDIA-Treiber muss neu genug für die installierte CUDA-Version sein.
• Python: 3.10 bis 3.13 — 3.12 ist die empfohlene Version (ROCm-Wheels sind nur für 3.12 verfügbar)
• VRAM: Mindestens 16GB für 7B-Modelle, 24GB+ für 13B, 40GB+ für größere Modelle

Installation über pip

Die empfohlene Installation verwendet uv, um eine Python 3.12-Umgebung zu erstellen und den passenden PyTorch CUDA-Backend automatisch auszuwählen (--torch-backend=auto untersucht den installierten Treiber). Für einen tieferen Einblick in uv selbst, siehe uv: Der neue Python-Paket- und Projektmanager:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

# Installation überprüfen
python -c "import vllm; print(vllm.__version__)"

Einfaches pip funktioniert auch:

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

Die Standard-Wheels wurden gegen CUDA 12.9 kompiliert. Wenn Sie eine andere CUDA-Version benötigen, ziehen Sie den passenden PyTorch-Wheel-Index – zum Beispiel CUDA 12.8:

pip install vllm --extra-index-url https://download.pytorch.org/whl/cu128

Die alten, fixierten Wheels wie vllm==0.4.2+cu121 existieren in dieser Form nicht mehr. Das Mischen von vLLM in eine bestehende Umgebung mit einem anderen PyTorch-Build ist eine häufige Ursache für Installationsfehler; das Projekt empfiehlt eine neue Umgebung und einen Source-Build, wenn ein benutzerdefiniertes CUDA-Ziel erforderlich ist.

Installation mit Docker

Docker bietet die zuverlässigste Deployment-Methode, insbesondere für Produktion. Fixieren Sie das Image auf eine Release-Version statt latest, damit Upgrades absichtlich erfolgen, und beachten Sie, dass Varianten-Images für CUDA 12.9 (-cu129 Tag-Suffix), AMD ROCm (vllm-openai-rocm), CPU (vllm-openai-cpu) und Intel XPU (vllm-openai-xpu) existieren:

# Offizielles vLLM-Image holen
docker pull vllm/vllm-openai:v0.31.0

# vLLM mit GPU-Unterstützung ausführen
docker run --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:v0.31.0 \
    --model Qwen/Qwen3-8B

Das Flag --ipc=host ist wichtig für Multi-GPU-Setups, da es die korrekte Kommunikation zwischen Prozessen ermöglicht.

Build aus dem Quellcode

Für die neuesten Funktionen oder benutzerdefinierte Anpassungen, bauen Sie aus dem Quellcode:

git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -e .

vLLM Quickstart-Leitfaden

Ihr erstes Modell ausführen

Starten Sie vLLM mit einem Modell über die command-line interface:

# Modell herunterladen und mit der OpenAI-kompatiblen API bereitstellen
vllm serve Qwen/Qwen3-8B \
    --port 8000

vllm serve ist die aktuelle CLI für den OpenAI-kompatiblen Server. Die ältere Aufrufweise python -m vllm.entrypoints.openai.api_server funktioniert noch, gibt aber eine Deprecation-Warnung aus und kann in einer zukünftigen Version entfernt werden, daher sollten alle Skripte oder Kubernetes-Manifeste, die sie noch verwenden, aktualisiert werden.

vLLM lädt das Modell automatisch vom HuggingFace Hub herunter (falls nicht gecacht) und startet den Server. Sie werden eine Ausgabe sehen, die anzeigt, dass der Server bereit ist:

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

API-Anfragen stellen

Sobald der Server läuft, können Sie Anfragen mit dem OpenAI Python Client oder curl stellen:

Mit curl:

curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "Qwen/Qwen3-8B",
        "prompt": "Explain what vLLM is in one sentence:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

Mit OpenAI Python Client:

from openai import OpenAI

# Auf Ihren vLLM-Server zeigen
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # vLLM ignoriert dies, es sei denn, Sie starten den Server mit --api-key
)

response = client.completions.create(
    model="Qwen/Qwen3-8B",
    prompt="Explain what vLLM is in one sentence:",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

Chat Completions API:

response = client.chat.completions.create(
    model="Qwen/Qwen3-8B",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "What is PagedAttention?"}
    ],
    max_tokens=200
)

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

Erweiterte Konfiguration

vLLM bietet zahlreiche Parameter zur Leistungsoptimierung:

vllm serve Qwen/Qwen3-8B \
    --port 8000 \
    --gpu-memory-utilization 0.95 \  # 95% des GPU-Speichers nutzen
    --max-model-len 32k \            # Maximale Sequenzlänge (8192 und 32k funktionieren beide)
    --tensor-parallel-size 2 \       # 2 GPUs mit Tensor Parallelism nutzen
    --dtype float16 \                # FP16-Präzision nutzen
    --max-num-seqs 256               # Maximale Batch-Größe

Wichtige Parameter erklärt:

• --gpu-memory-utilization: Anteil des GPU-Speichers für den Modell-Executor (Standard 0.92). Höhere Werte erlauben größere Batches, lassen aber weniger Spielraum für Speicher-Spitzen.
• --max-model-len: Maximale Kontextlänge. Akzeptiert Token-Anzahlen oder menschenlesbare Werte wie 32k. Die Reduktion spart Speicher für größere Batches.
• --tensor-parallel-size: Anzahl der GPUs, auf die das Modell verteilt wird.
• --dtype: Datentyp für Gewichte (auto, float16, bfloat16, float32). auto folgt dem Dtype des Checkpoints, was meistens das Gewünschte ist.
• --max-num-seqs: Maximale Anzahl von Sequenzen in einem Batch.
• --max-num-active-seqs: Begrenzt die RUNNING-Zulassung unabhängig von max_num_seqs (neu in v0.31.0) — nützlich, um Latenz zu begrenzen, ohne das Batch-Fenster des Schedulers zu verkleinern.

vLLM vs Ollama

vLLM wurde für hochdurchsatzstarkes, multi-user Produktions-Serving mit continuous batching, PagedAttention und Multi-GPU-Unterstützung konzipiert. Ollama optimiert für schnelle lokale Einrichtung, Ein-Benutzer-Bequemlichkeit und einfache Modellverwaltung.

Für einen detaillierten Entscheidungsleitfaden, der Migrationssignale, Planungsschritte, Docker Compose-Setup und eine praktische Checkliste abdeckt, siehe Ollama to vLLM: Wann Sie Ihren lokalen LLM-Server migrieren sollten.

vLLM vs Docker Model Runner

Docker Model Runner ist ihre offizielle Lösung für das lokale Deployment von KI-Modellen. Wie steht es im Vergleich zu vLLM da?

Architekturphilosophie

Docker Model Runner zielt darauf ab, das „Docker für KI“ zu sein – ein einfacher, standardisierter Weg, KI-Modelle lokal auszuführen, mit derselben Leichtigkeit wie beim Ausführen von Containern. Es abstrahiert Komplexität ab und bietet eine konsistente Schnittstelle über verschiedene Modelle und Frameworks hinweg.

vLLM ist ein spezialisierter Inferenz-Engine, der sich ausschließlich auf LLM-Serving mit maximaler Leistung konzentriert. Es ist ein Low-Level-Tool, das man mit Docker containerisiert, anstatt eine vollständige Plattform zu sein.

Einrichtung und Einstieg

Die Installation von Docker Model Runner ist für Docker-Nutzer geradlinig:

docker model pull llama3:8b
docker model run llama3:8b

Diese Ähnlichkeit mit dem Image-Workflow von Docker macht es für Entwickler, die bereits Container verwenden, sofort vertraut; der vollständige Befehlssatz ist im Docker Model Runner Spickzettel.

vLLM erfordert mehr anfängliche Einrichtung (Python, CUDA, Abhängigkeiten) oder die Verwendung vorgebauter Docker-Images:

docker pull vllm/vllm-openai:latest
docker run --runtime nvidia --gpus all vllm/vllm-openai:latest --model <model-name>

Leistungsmerkmale

vLLM liefert einen überlegenen Durchsatz für Multi-User-Szenarien dank PagedAttention und continuous batching. Für Produktions-API-Dienste, die Hunderte von Anfragen pro Sekunde verarbeiten, liefern die Optimierungen von vLLM einen 2- bis 5-mal besseren Durchsatz als generische Serving-Ansätze.

Docker Model Runner konzentriert sich auf Benutzerfreundlichkeit statt auf maximale Leistung. Es ist für lokale Entwicklung, Tests und moderate Workloads geeignet, implementiert aber nicht die fortschrittlichen Optimierungen, die vLLM bei Skalierung excelieren lassen.

Modellunterstützung

Docker Model Runner bietet eine kuratierte Modellbibliothek mit Ein-Befehl-Zugriff auf beliebte Modelle. Es unterstützt mehrere Frameworks (nicht nur LLMs), einschließlich Stable Diffusion, Whisper und anderer KI-Modelle, was es vielseitiger für verschiedene KI-Workloads macht.

vLLM spezialisiert sich auf LLM-Inferenz mit tiefer Unterstützung für transformerbasierte Sprachmodelle. Es unterstützt jede HuggingFace-kompatible LLM, erstreckt sich aber nicht auf andere KI-Modelltypen wie Bildgenerierung oder Spracherkennung.

Produktions-Deployment

vLLM ist in der Produktion bei Unternehmen wie Anthropic, Replicate und vielen anderen bewährt, die täglich Milliarden von Tokens verarbeiten. Seine Leistungsmerkmale und Stabilität unter hoher Last machen es zum De-facto-Standard für produktionsreifes LLM-Serving.

Docker Model Runner ist neu und positioniert sich eher für Entwicklungs- und lokale Test-Szenarien. Während es Produktions-Traffic bedienen könnte, fehlt ihm der bewährte Leumund und die Leistungsoptimierungen, die Produktions-Deployments erfordern.

Integrations-Ökosystem

vLLM integriert sich mit Produktions-Infrastruktur-Tools: Kubernetes-Operatoren, Prometheus-Metriken, Ray für verteiltes Serving und extensive OpenAI-API-Kompatibilität für bestehende Anwendungen.

Docker Model Runner integriert sich natürlich mit dem Docker-Ökosystem und Docker Desktop. Für Teams, die bereits standardisiert auf Docker sind, bietet diese Integration ein zusammenhängendes Erlebnis, aber weniger spezialisierte LLM-Serving-Funktionen.

Wann welches verwendet werden sollte

vLLM verwenden für:

• Produktions-LLM-API-Dienste
• Hochdurchsatz-, Multi-User-Deployments
• Kosten-sensitive Cloud-Deployments, die maximale Effizienz benötigen
• Kubernetes- und cloud-native Umgebungen
• Wenn Sie bewiesene Skalierbarkeit und Leistung benötigen

Docker Model Runner verwenden für:

• Lokale Entwicklung und Tests
• Ausführen verschiedener KI-Modelltypen (nicht nur LLMs)
• Teams, die stark im Docker-Ökosystem investiert sind
• Schnelle Experimente ohne Infrastruktur-Setup
• Lern- und Bildungszwecke

Hybrider Ansatz: Viele Teams entwickeln lokal mit Docker Model Runner aus Bequemlichkeitsgründen und deployen dann mit vLLM in der Produktion für Leistung. Die Docker Model Runner-Images können auch verwendet werden, um vLLM-Container auszuführen, was beide Ansätze kombiniert.

Best Practices für Produktions-Deployments

Docker-Deployment

Erstellen Sie eine produktionsreife Docker Compose-Konfiguration:

version: '3.8'

services:
  vllm:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    environment:
      - CUDA_VISIBLE_DEVICES=0,1
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
      - ./logs:/logs
    ports:
      - "8000:8000"
    command: >
      --model Qwen/Qwen3-8B
      --tensor-parallel-size 2
      --gpu-memory-utilization 0.90
      --max-num-seqs 256
      --max-model-len 8192
    restart: unless-stopped
    shm_size: '16gb'
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]

Kubernetes-Deployment

Deployen Sie vLLM auf Kubernetes für Produktions-Skalierung:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
          - --model
          - Qwen/Qwen3-8B
          - --tensor-parallel-size
          - "2"
          - --gpu-memory-utilization
          - "0.90"
        resources:
          limits:
            nvidia.com/gpu: 2
        ports:
        - containerPort: 8000
        volumeMounts:
        - name: cache
          mountPath: /root/.cache/huggingface
      volumes:
      - name: cache
        hostPath:
          path: /mnt/huggingface-cache
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm
  ports:
  - port: 80
    targetPort: 8000
  type: LoadBalancer

Monitoring und Observability

Der OpenAI-kompatible Server zeigt Prometheus-Metriken standardmäßig unter /metrics an — keine zusätzlichen Flags erforderlich:

curl -s http://localhost:8000/metrics | grep '^vllm:'

Wichtige Metriken zum überwachen:

• vllm:num_requests_running / vllm:num_requests_waiting / vllm:num_requests_swapped — Anfragen in den Scheduling-Zuständen RUNNING, WAITING und SWAPPED
• vllm:kv_cache_usage_perc — Anteil der verwendeten KV-Cache-Blöcke (0–1)
• vllm:time_to_first_token_seconds — TTFT-Histogramm
• vllm:time_per_output_token_seconds — Generierungsgeschwindigkeit pro Token
• vllm:num_preemptions_total — Kumulierte Preemptions; ein steigender Zähler bedeutet, dass der KV-Cache überzeichnet ist und Anfragen neu berechnet werden

Für Dashboards, PromQL-Beispiele und Alarm-Schwellenwerte rund um LLM-Serving, siehe LLM-Inferenz in der Produktion überwachen (2026): Prometheus & Grafana für vLLM, TGI, llama.cpp.

Leistungstuning

GPU-Speichernutzung optimieren: Der Standardwert ist 0.92; passen Sie dies basierend auf dem beobachteten Verhalten an. Höhere Werte erlauben größere Batches, bergen aber das Risiko von OOM-Fehlern während von Traffic-Spitzen.

Maximale Sequenzlänge einstellen: Wenn Ihr Anwendungsfall keine volle Kontextlänge benötigt, reduzieren Sie --max-model-len. Dies befreit Speicher für größere Batches. Zum Beispiel, wenn Sie nur 4K Kontext benötigen, setzen Sie --max-model-len 4096 anstatt die maximale Länge des Modells zu verwenden (oft 8K-32K).

Geeignete Quantisierung wählen: Für Modelle, die es unterstützen, verwenden Sie quantisierte Versionen (8-Bit, 4-Bit), um Speicher zu reduzieren und Durchsatz zu erhöhen:

--quantization awq  # Für AWQ-quantisierte Modelle
--quantization gptq # Für GPTQ-quantisierte Modelle

Prefix Caching: Prefix Caching ist im aktuellen Engine standardmäßig aktiviert, sodass Anfragen, die einen Prompt-Präfix teilen (ein fester System-Prompt, eine RAG-Kontext-Vorlage), dessen KV-Cache ohne Flag wiederverwenden. Deaktivieren Sie es mit --no-enable-prefix-caching für Workloads mit vielen einzigartigen langen Prompts, bei denen die Cache-Buchführung nichts bringt.

Häufige Probleme und deren Lösung

Out-of-Memory-Fehler

Symptome: Server stürzt mit CUDA out-of-memory-Fehlern ab.

Lösungen:

• Reduzieren Sie --gpu-memory-utilization auf 0.85 oder 0.80
• Verringern Sie --max-model-len, wenn Ihr Anwendungsfall es zulässt
• Senken Sie --max-num-seqs, um die Batch-Größe zu reduzieren
• Verwenden Sie eine quantisierte Modellversion
• Aktivieren Sie Tensor Parallelism, um auf mehr GPUs zu verteilen

Zwei verschiedene OOM-Formen erfordern unterschiedliche Fixes. Ein Startup-OOM passiert vor jeder Anfrage: vLLM profiliert den Speicher und schlägt fehl, selbst den minimalen KV-Cache zuzuweisen, daher hilft die Reduktion von --max-num-seqs nicht — reduzieren Sie --max-model-len oder erhöhen Sie --gpu-memory-utilization, wenn Sie Spielraum haben. Ein Runtime-OOM unter Last kann vom Speicher für die CUDA-Graph-Capture stammen, der mit --max-num-seqs skaliert, aber außerhalb der KV-Cache-Abrechnung liegt; führen Sie einmal mit --enforce-eager aus, um zu prüfen, ob CUDA-Graphs der fehlende Speicher sind, und testen Sie die exakt gleiche Konfiguration erneut, bevor Sie den Cache beschuldigen. Wenn Starts auf identischer Hardware mit derselben Allokation weiterhin erfolgreich sind, übergeben Sie den --kv-cache-memory-bytes-Wert, den vLLM beim Start protokolliert, um die Profilierungsphase bei nachfolgenden Starts zu überspringen.

Auf einer einzelnen 16 GB-Karte gehen die meisten dieser OOM-Fehler auf das KV-Cache-Budget zurück und nicht nur auf die Gewichte — KV Cache auf 16 GB-GPUs deckt die exakte Formel, den FP8-KV-Cache-Dtype und die Kompromisse des Prefix-Caching hinter --max-model-len und --max-num-seqs ab, bevor Sie zu einem kleineren Modell greifen.

Langsamer Start

Symptome: Der Server benötigt Minuten vom Start bis „Application startup complete“.

Lösungen:

• Laden der Gewichte, Kompilierung und CUDA-Graph-Capture dominieren den Start — --enforce-eager überspringt beide Kompilierung und Capture und zeigt, welchen Anteil des Starts sie kosten, auf Kosten der Geschwindigkeit in der stabilen Dekodierungsphase
• Wiederverwenden Sie den protokollierten --kv-cache-memory-bytes-Wert, um die Speicherprofilierungs- und CUDA-Graph-Schätzphasen bei wiederholten Starts zu überspringen
• Ab v0.30.0 führt der vllm preload-Befehl einen persistenten Weight-Cache-Daemon aus, der post-quantisierte Gewichte im GPU-Speicher resident hält, sodass Engine-Neustarts Gewichte über CUDA IPC zuordnen statt sie von der Festplatte neu zu laden (--load-format ipc_cache)
• Für NVFP4-Checkpoints, die beim Start-Kompilieren OOM-fühlen, ist das Beschränken der Build-Threads mit MAX_JOBS=4 und NVCC_THREADS=4 ein weit verbreiteter Fix — es verlangsamt den JIT-Build, stoppt aber das OOM

Niedriger Durchsatz

Symptome: Server verarbeitet weniger Anfragen als erwartet.

Lösungen:

• Erhöhen Sie --max-num-seqs, um größere Batches zu erlauben
• Erhöhen Sie --gpu-memory-utilization, wenn Sie Spielraum haben
• Prüfen Sie, ob die CPU der Engpass ist, mit htop – erwägen Sie schnellere CPUs
• Überprüfen Sie die GPU-Auslastung mit nvidia-smi – sollte 95%+ sein
• Aktivieren Sie FP16, wenn FP32 verwendet wird: --dtype float16

Langsame First-Token-Zeit

Symptome: Hohe Latenz vor Beginn der Generierung.

Lösungen:

• Verwenden Sie kleinere Modelle für latenzkritische Anwendungen
• Prefix Caching ist standardmäßig aktiv — überprüfen Sie, ob es aktiv ist, anstatt das Flag erneut hinzuzufügen
• Reduzieren Sie --max-num-seqs, um Latenz vor Durchsatz zu priorisieren
• Erwägen Sie spekulatives Dekodieren für unterstützte Modelle
• Optimieren Sie die Tensor-Parallelism-Konfiguration

Modell-Lade-Fehler

Symptome: Server startet nicht, kann Modell nicht laden.

Lösungen:

• Stellen Sie sicher, dass der Modellname exakt dem HuggingFace-Format entspricht
• Prüfen Sie die Netzwerkanbindung an HuggingFace Hub
• Stellen Sie ausreichenden Speicherplatz in ~/.cache/huggingface sicher
• Setzen Sie für gatablellierte Modelle die Umgebungsvariable HF_TOKEN
• Versuchen Sie das manuelle Herunterladen mit hf download <model> (oder huggingface-cli download <model> bei älteren Installationen)

Erweiterte Funktionen

Spekulatives Dekodieren

vLLM unterstützt spekulatives Dekodieren, bei dem ein kleineres Draft-Modell Tokens vorschlägt, die ein größeres Target-Modell verifiziert. Dies kann die Generierung um 1,5-2x beschleunigen. Für einen umfassenden Leitfaden zu Methoden des spekulativen Dekodierens — Draft-Modelle, EAGLE-3, P-EAGLE und n-gram — siehe Speculative Decoding: Schnellere Inferenz ohne Qualitätsverlust.

vllm serve meta-llama/Llama-3.1-8B-Instruct \
    --speculative-config '{"method": "draft_model", "model": "meta-llama/Llama-3.2-1B-Instruct", "num_speculative_tokens": 4}'

Die alten Flags --speculative-model und --num-speculative-tokens sind verschwunden — die Konfiguration wurde in das einzelne --speculative-config-JSON-Argument verlagert, das auch die Methode auswählt (draft_model, ngram, EAGLE-Familie oder MTP für Modelle mit nativen Multi-Token-Prediction-Heads).

LoRA-Adapter

Bieten Sie mehrere LoRA-Adapter über einem Basismodell an, ohne mehrere vollständige Modelle zu laden:

vllm serve meta-llama/Llama-3.1-8B-Instruct \
    --enable-lora \
    --lora-modules sql-lora=/path/to/sql-adapter \
                   code-lora=/path/to/code-adapter

Geben Sie dann pro Anfrage an, welchen Adapter verwendet werden soll, indem Sie seinen Namen im model-Feld angeben — derselbe Mechanismus skaliert auf Dutzende aufgabenspezifischer Adapter (kundenspezifische oder domänenspezifische Varianten), mit nur dem Basismodell resident im Speicher:

response = client.completions.create(
    model="sql-lora",  # SQL-Adapter verwenden
    prompt="Convert this to SQL: Show me all users created this month"
)

Prefix Caching

Prefix Caching vermeidet das Neu-Berechnen des KV-Caches für geteilte Prompt-Präfixe und ist im aktuellen Engine standardmäßig aktiviert.

Es lohnt sich am meisten für:

• Chatbots mit festen System-Prompts
• RAG-Anwendungen mit konsistenten Kontext-Vorlagen
• Few-Shot-Learning-Prompts, die über Anfragen hinweg wiederholt werden

Für Anfragen, die einen Präfix teilen, sinkt die Zeit bis zum ersten Token erheblich, da das Prefilling für den geteilten Teil übersprungen wird.

Integrationsbeispiele

LangChain-Integration

from langchain_community.llms import VLLMOpenAI

llm = VLLMOpenAI(
    openai_api_key="EMPTY",
    openai_api_base="http://localhost:8000/v1",
    model_name="Qwen/Qwen3-8B",
    max_tokens=512,
    temperature=0.7,
)

response = llm("Explain PagedAttention in simple terms")
print(response)

FastAPI-Anwendung

from fastapi import FastAPI
from openai import AsyncOpenAI

app = FastAPI()
client = AsyncOpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"
)

@app.post("/generate")
async def generate(prompt: str):
    response = await client.completions.create(
        model="Qwen/Qwen3-8B",
        prompt=prompt,
        max_tokens=200
    )
    return {"result": response.choices[0].text}

Leistungsbenchmarks

Echtwelt-Leistungsdaten helfen, die Vorteile von vLLM zu veranschaulichen. Die folgenden Zahlen stammen aus der Dokumentations-Ära des Projekts und frühen Community-Messungen — betrachten Sie sie als Größenordnungs-Indikatoren für den Effekt der Architektur, nicht als aktuelle Ergebnisse für die heutige Modell-Generation:

Durchzugsvergleich (Mistral-7B auf A100 GPU):

• vLLM: ~3.500 Tokens/Sekunde mit 64 gleichzeitigen Benutzern
• HuggingFace Transformers: ~250 Tokens/Sekunde mit gleicher Konnektivität
• Ollama: ~1.200 Tokens/Sekunde mit gleicher Konnektivität
• Ergebnis: vLLM liefert eine 14-fache Verbesserung gegenüber Basisimplementierungen

Speichereffizienz (LLaMA-2-13B):

• Standardimplementierung: 24GB VRAM, 32 gleichzeitige Sequenzen
• vLLM mit PagedAttention: 24GB VRAM, 128 gleichzeitige Sequenzen
• Ergebnis: 4-mal mehr gleichzeitige Anfragen mit gleichem Speicher

Latenz unter Last (Mixtral-8x7B auf 2xA100):

• vLLM: P50 Latenz 180ms, P99 Latenz 420ms bei 100 req/s
• Standard-Serving: P50 Latenz 650ms, P99 Latenz 3.200ms bei 100 req/s
• Ergebnis: vLLM hält konsistente Latenz unter hoher Last

Kostenanalyse

Das Verständnis der Kostenimplikationen der Wahl von vLLM:

Szenario: 1 Mio. Anfragen/Tag

Mit Standard-Serving:

• Erforderlich: 8x A100 GPUs (80GB)
• AWS-Kosten: ~$32/Stunde × 24 × 30 = $23.040/Monat
• Kosten pro 1 Mio. Tokens: ~$0.75

Mit vLLM:

• Erforderlich: 2x A100 GPUs (80GB)
• AWS-Kosten: ~$8/Stunde × 24 × 30 = $5.760/Monat
• Kosten pro 1 Mio. Tokens: ~$0.19
• Ersparnis: $17.280/Monat (75% Reduktion)

Dieser Kostenvorteil wächst mit der Skalierung. Organisationen, die monatlich Milliarden von Tokens verarbeiten, sparen Hunderttausende von Dollar, indem sie das optimierte Serving von vLLM statt naive Implementierungen verwenden.

Sicherheitsaspekte

Authentifizierung

vLLM bringt ein integriertes --api-key-Flag mit, aber laut offiziellen Dokumenten authentifiziert es nur Endpunkte unter den Pfad-Präfixen /v1, /v2 und /inference — andere Endpunkte auf demselben Server bleiben unauthentifiziert. Behandeln Sie es als eine Schicht, nicht als die gesamte Antwort; für vollständige Abdeckung implementieren Sie Authentifizierung auf der Reverse-Proxy-Ebene:

# Nginx Konfiguration
location /v1/ {
    auth_request /auth;
    proxy_pass http://vllm-backend:8000;
}

location /auth {
    proxy_pass http://auth-service:8080/verify;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
}

Oder verwenden Sie API-Gateways wie Kong, Traefik oder AWS API Gateway für Enterprise-Authentifizierung und Rate-Limiting.

Netzwerkisolation

Führen Sie vLLM in privaten Netzen aus, nicht direkt dem Internet ausgesetzt:

# Kubernetes NetworkPolicy Beispiel
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: vllm-access
spec:
  podSelector:
    matchLabels:
      app: vllm
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api-gateway
    ports:
    - protocol: TCP
      port: 8000

Rate-Limiting

Implementieren Sie Rate-Limiting, um Missbrauch zu verhindern:

# Beispiel unter Verwendung von Redis für Rate-Limiting
from fastapi import FastAPI, HTTPException
from fastapi.middleware.cors import CORSMiddleware
import redis
from datetime import datetime, timedelta

app = FastAPI()
redis_client = redis.Redis(host='localhost', port=6379)

@app.middleware("http")
async def rate_limit_middleware(request, call_next):
    client_ip = request.client.host
    key = f"rate_limit:{client_ip}"
    
    requests = redis_client.incr(key)
    if requests == 1:
        redis_client.expire(key, 60)  # 60 Sekunden Fenster
    
    if requests > 60:  # 60 Anfragen pro Minute
        raise HTTPException(status_code=429, detail="Rate limit exceeded")
    
    return await call_next(request)

Modell-Zugangskontrolle

Für Multi-Tenant-Deployments kontrollieren Sie, welche Benutzer auf welche Modelle zugreifen können:

ALLOWED_MODELS = {
    "user_tier_1": ["Qwen/Qwen3-8B"],
    "user_tier_2": ["Qwen/Qwen3-8B", "meta-llama/Llama-2-13b-chat-hf"],
    "admin": ["*"]  # Alle Modelle
}

def verify_model_access(user_tier: str, model: str) -> bool:
    allowed = ALLOWED_MODELS.get(user_tier, [])
    return "*" in allowed or model in allowed

Migrationsleitfaden

Von OpenAI zu vLLM

Die Migration von OpenAI zu selbst gehostetem vLLM ist dank API-Kompatibilität geradlinig:

Vorher (OpenAI):

from openai import OpenAI

client = OpenAI(api_key="sk-...")
response = client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": "Hello"}]
)

Nachher (vLLM):

from openai import OpenAI

client = OpenAI(
    base_url="https://your-vllm-server.com/v1",
    api_key="your-internal-key"  # Wenn Sie Authentifizierung hinzugefügt haben
)
response = client.chat.completions.create(
    model="Qwen/Qwen3-8B",
    messages=[{"role": "user", "content": "Hello"}]
)

Nur zwei Änderungen erforderlich: base_url und model-Name aktualisieren. Aller andere Code bleibt identisch.

Von Ollama zu vLLM

Ollama verwendet ein anderes API-Format. Die grundlegende clientseitige Änderung ist der Wechsel vom Ollama-REST-Endpoint zur OpenAI-kompatiblen API von vLLM:

Ollama API:

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={'model': 'llama2', 'prompt': 'Why is the sky blue?'})

vLLM-Äquivalent:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
response = client.completions.create(
    model="meta-llama/Llama-2-7b-chat-hf",
    prompt="Why is the sky blue?"
)

Die Ollama-API ist ein plain REST mit ihrer eigenen Anfrageform, während vLLM das OpenAI-Protokoll spricht — dieser API-Format-Unterschied ist die Haupt-Client-Änderung, und der gestufte Ansatz (beide Server ausführen, Traffic Endpoint für Endpoint verschieben) wird im Migrationsleitfaden behandelt, der früher in diesem Artikel verlinkt ist.

Von HuggingFace Transformers zu vLLM

Direkte Python-Nutzungs-Migration:

HuggingFace:

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen3-8B")
tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen3-8B")

inputs = tokenizer("Hello", return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=100)
result = tokenizer.decode(outputs[0])

vLLM:

from vllm import LLM, SamplingParams

llm = LLM(model="Qwen/Qwen3-8B")
sampling_params = SamplingParams(max_tokens=100)

outputs = llm.generate("Hello", sampling_params)
result = outputs[0].outputs[0].text

Die Python-API von vLLM ist einfacher und viel schneller für Batch-Inferenz.

Neueste Releases: Was sich in 2026 geändert hat

Drei Releases im September–Oktober 2026 (v0.29.0, v0.30.0, v0.31.0) zeigen, wohin sich die Entwicklung bewegt:

Schnelle Neustarts: vllm preload startet einen persistenten per-GPU-Weight-Cache-Daemon, der post-quantisierte, TP-shardierte Gewichte im GPU-Speicher resident hält, sodass neu gestartete Engines sie über CUDA IPC zuordnen (--load-format ipc_cache) statt sie von der Festplatte neu zu laden. Experimentelles vllm snapshot create/restore snapshotet eine vollständig initialisierte Engine mit CRIU.

Spekulatives Dekodieren auf Model Runner V2: Draft-Modell-spekulatives Dekodieren, benutzerdefinierte Logits-Prozessoren und adaptive Verifizierung wurden auf den neuen Model Runner verlagert, mit dem LiLiCorr-Drafter hinzugefügt und asynchronem Scheduling für den DFlash-Drafter.

Großskaliges MoE-Serving: Neue balancierte expert-parallel all2all-Backends (--all2all-backend moonep), DeepEPv2 mit sequenzieller Parallelität, EPLB mit shared-expert-Overlap und Prefill-Kontext-Parallelität kombiniert mit Datenparallelität.

Scheduling-Kontrolle: --max-num-active-seqs begrenzt die RUNNING-Zulassung unabhängig von max_num_seqs, und die Warteschlange plant jetzt Anfragen, die bereits KV-Blöcke halten, zuerst.

Roadmap-Elemente aus älteren vLLM-Leitfäden wurden längst ausgeliefert — GGUF-Unterstützung, multimodales Serving, disaggregiertes Prefill/Decode und Multi-Knoten-Inferenz sind alle Teil aktueller Releases, daher sollte man jeden Tutorial, der sie als „bald verfügbar" auflistet, als veraltet betrachten. Release-Notizen für jede Version sind auf der vLLM-Releases-Seite.

Nützliche Links

Verwandte Artikel auf dieser Website

• Ollama-Spickzettel - Vollständige Ollama-Befehlreferenz und Spickzettel, der Installation, Modellverwaltung, API-Nutzung und Best Practices für lokale LLM-Deployment abdeckt. Essentiell für Entwickler, die Ollama zusammen mit oder anstelle von vLLM verwenden.

• Docker Model Runner vs Ollama: Welche soll man wählen? - Tiefgehende Vergleich von Dofficers Model Runner und Ollama für lokale LLM-Deployment, der Leistung, GPU-Unterstützung, API-Kompatibilität und Anwendungsfälle analysiert. Hilft, das wettbewerbsfähige Umfeld zu verstehen, in dem vLLM operiert.

Externe Ressourcen und Dokumentation

• vLLM-GitHub-Repository - Offizielles vLLM-Repository mit Quellcode, umfassender Dokumentation, Installationsleitfäden und aktiven Community-Diskussionen. Essentielle Ressource, um auf dem neuesten Stand der neuesten Funktionen und Problemen zu bleiben.

• vLLM-Dokumentation - Offizielle Dokumentation, die alle Aspekte von vLLM von der grundlegenden Einrichtung bis zur erweiterten Konfiguration abdeckt. Enthält API-Referenzen, Leistungstuning-Leitfäden und Deployment-Best-Practices.

• PagedAttention-Paper - Akademisches Paper, das den PagedAttention-Algorithmus einführt, der die Effizienz von vLLM antreibt. Lesenswertes für das Verständnis der technischen Innovationen hinter den Leistungsvorteilen von vLLM.

• vLLM-Blog - Offizieller vLLM-Blog, der Release-Ankündigungen, Leistungsbenchmarks, technische Deep-Dives und Community-Fallstudien aus Produktions-Deployments präsentiert.

• HuggingFace Model Hub - Umfassendes Repository von Open-Source-LLMs, die mit vLLM funktionieren. Suchen Sie nach Modellen nach Größe, Aufgabe, Lizenz und Leistungsmerkmalen, um das richtige Modell für Ihren Anwendungsfall zu finden.

• Ray Serve Dokumentation - Dokumentation des Ray Serve Frameworks für den Aufbau skalierbarer, verteilter vLLM-Deployments. Ray bietet fortschrittliche Funktionen wie Auto-Scaling, Multi-Modell-Serving und Ressourcengliederung für Produktionssysteme.

• NVIDIA TensorRT-LLM - NVIDIAs TensorRT-LLM für hochoptimierte Inferenz auf NVIDIA-GPUs. Alternative zu vLLM mit anderen Optimierungsstrategien, nützlich für den Vergleich und das Verständnis der Inferenz-Optimierungslandschaft.

• OpenAI API-Referenz - Offizielle OpenAI API-Dokumentation, mit der vLLM-API kompatibel ist. Verweisen Sie darauf, wenn Sie Anwendungen erstellen, die sowohl mit OpenAI als auch mit selbst gehosteten vLLM-Endpoints austauschbar funktionieren müssen.