vLLM Quickstart: Hochleistungs-LLM-Hosting – 2026

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

Mit seinem revolutionären PagedAttention-Algorithmus erreicht vLLM eine 14- bis 24-mal höhere Durchsatzrate als herkömmliche Serving-Methoden und ist damit die erste Wahl für die Produktion von LLM-Implementierungen. Um zu sehen, wie sich vLLM im Vergleich zu Ollama, Docker Model Runner, LocalAI und Cloud-Anbietern positioniert – einschließlich Kosten- und Infrastrukturabwägungen – lesen Sie LLM Hosting: Lokal, Selbstgehostet & Cloud-Infrastruktur im Vergleich.

Was ist vLLM?

vLLM (virtual LLM) ist eine Open-Source-Bibliothek für schnelle LLM-Inferenz und Serving, die sich rasch zum Industriestandard für Produktionsimplementierungen entwickelt hat. Bei der Veröffentlichung im Jahr 2023 führte es PagedAttention ein, eine bahnbrechende Speicherverwaltungstechnik, die die Serving-Effizienz drastisch verbessert.

Hauptfunktionen

Hohe Durchsatzleistung: vLLM liefert im Vergleich zu HuggingFace Transformers mit derselben Hardware eine 14- bis 24-mal höhere Durchsatzrate. Dieser massive Leistungsgewinn resultiert aus Continuous Batching, optimierten CUDA-Kernen und dem PagedAttention-Algorithmus, der Speicherfragmentierung eliminiert.

OpenAI-API-Kompatibilität: vLLM enthält einen integrierten API-Server, der vollständig mit dem OpenAI-Format kompatibel ist. Dies ermöglicht einen nahtlosen Wechsel von OpenAI zu selbstgehosteter Infrastruktur, ohne den Anwendungscode ändern zu müssen. Verweisen Sie einfach Ihren API-Client auf den vLLM-Endpunkt, und er funktioniert transparent.

PagedAttention-Algorithmus: Die Kerninnovation hinter der Leistung von vLLM ist PagedAttention, das das Konzept des virtuellen Speicherpaging auf Aufmerksamkeitsmechanismen (Attention Mechanisms) anwendet. Anstatt zusammenhängende Speicherblöcke für KV-Caches zuzuweisen (was zu Fragmentierung führt), unterteilt PagedAttention den Speicher in festgelegte Blöcke fester Größe, die bei Bedarf dynamisch zugewiesen werden können. Dies reduziert den Speicherabfall um bis zu 4-fach und ermöglicht deutlich größere Batch-Größen.

Continuous Batching: Im Gegensatz zum statischen Batching, bei dem Sie darauf warten müssen, dass alle Sequenzen abgeschlossen sind, verwendet vLLM ein kontinuierliches (laufendes) Batching. Sobald eine Sequenz abgeschlossen ist, kann eine neue zur 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-Parallelismus und Pipeline-Parallelismus zur Verteilung großer Modelle über 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 weiteren. Unterstützt sowohl instruktionsgetunte als auch Basismodelle vom HuggingFace Hub.

Wann sollten Sie vLLM verwenden?

vLLM glänzt in bestimmten Szenarien, in denen seine Stärken zur Geltung kommen:

Produktions-API-Dienste: Wenn Sie ein LLM über eine API für viele gleichzeitige Benutzer bereitstellen müssen, ist vLLM aufgrund seiner hohen Durchsatzrate und des effizienten Batching die beste Wahl. Unternehmen, die Chatbots, Code-Assistenten oder Dienste zur Inhaltserstellung betreiben, profitieren von der Fähigkeit, Hunderte von Anfragen pro Sekunde zu verarbeiten.

Hochfrequenz-Workloads: Wenn Ihre Anwendung viele gleichzeitige Benutzer hat, die Anfragen stellen, ermöglichen das Continuous Batching und PagedAttention von vLLM die Bereitstellung für mehr Benutzer mit derselben Hardware im Vergleich zu Alternativen.

Kostenoptimierung: Wenn GPU-Kosten ein Problem darstellen, bedeutet die überlegene Durchsatzrate von vLLM, dass Sie denselben Datenverkehr mit weniger GPUs bereitstellen können, was die Infrastrukturkosten direkt senkt. Die 4-fache Speichereffizienz durch PagedAttention ermöglicht zudem die Verwendung kleinerer, günstigerer GPU-Instanzen.

Kubernetes-Bereitstellungen: Das zustandslose Design und die containerfreundliche Architektur von vLLM machen es ideal für Kubernetes-Cluster. Seine konsistente Leistung unter Last und das einfache Ressourcenmanagement integrieren sich gut in cloud-native Infrastrukturen.

Wann Sie vLLm NICHT verwenden sollten: Für die lokale Entwicklung, Experimente oder Szenarien mit einem einzelnen Benutzer bieten Tools wie Ollama oder llama.cpp eine bessere Benutzererfahrung mit einfacherer Einrichtung. Die Komplexität von vLLM ist gerechtfertigt, wenn Sie seine Leistungsvorteile für Produktions-Workloads benötigen.

Installation von vLLM

Voraussetzungen

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

• GPU: NVIDIA-GPU mit Compute Capability 7.0+ (V100, T4, A10, A100, H100, RTX 20/30/40 Reihe)
• CUDA: Version 11.8 oder höher
• Python: 3.8 bis 3.11
• VRAM: Mindestens 16GB für 7B-Modelle, 24GB+ für 13B, 40GB+ für größere Modelle
• Treiber: NVIDIA-Treiber 450.80.02 oder neuer

Installation über pip

Die einfachste Installationsmethode ist die Verwendung von pip. Dies funktioniert auf Systemen mit CUDA 11.8 oder neuer:

# Virtuelle Umgebung erstellen (empfohlen)
python3 -m venv vllm-env
source vllm-env/bin/activate

# vLLM installieren
pip install vllm

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

Für Systeme mit anderen CUDA-Versionen installieren Sie das entsprechende Wheel:

# Für CUDA 12.1
pip install vllm==0.4.2+cu121 -f https://github.com/vllm-project/vllm/releases

# Für CUDA 11.8
pip install vllm==0.4.2+cu118 -f https://github.com/vllm-project/vllm/releases

Installation mit Docker

Docker bietet die zuverlässigste Bereitstellungsmethode, insbesondere für die Produktion:

# Offizielles vLLM-Image abrufen
docker pull vllm/vllm-openai:latest

# vLLM mit GPU-Unterstützung ausführen
docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model mistralai/Mistral-7B-Instruct-v0.2

Das Flag --ipc=host ist für Multi-GPU-Setups wichtig, da es die ordnungsgemäße Prozess-zu-Prozess-Kommunikation ermöglicht.

Build aus dem Quellcode

Für die neuesten Funktionen oder benutzerdefinierte Modifikationen können Sie aus dem Quellcode bauen:

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

vLLM Schnellstartanleitung

Ihr erstes Modell ausführen

Starten Sie vLLM mit einem Modell über die Befehlszeilenschnittstelle:

# Mistral-7B mit OpenAI-kompatibler API herunterladen und bereitstellen
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000

vLLL wird das Modell automatisch vom HuggingFace Hub herunterladen (falls nicht zwischengespeichert) und den Server starten. Sie sehen eine Ausgabe, 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": "mistralai/Mistral-7B-Instruct-v0.2",
        "prompt": "Erklären Sie in einem Satz, was vLLM ist:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

Mit dem 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 erfordert standardmäßig keine Authentifizierung
)

response = client.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    prompt="Erklären Sie in einem Satz, was vLLM ist:",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

Chat Completions API:

response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[
        {"role": "system", "content": "Sie sind ein hilfreicher Assistent."},
        {"role": "user", "content": "Was ist PagedAttention?"}
    ],
    max_tokens=200
)

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

Erweiterte Konfiguration

vLLB bietet zahlreiche Parameter zur Optimierung der Leistung:

python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000 \
    --gpu-memory-utilization 0.95 \  # 95% des GPU-Speichers verwenden
    --max-model-len 8192 \            # Maximale Sequenzlänge
    --tensor-parallel-size 2 \        # 2 GPUs mit Tensor-Parallelismus verwenden
    --dtype float16 \                 # FP16-Präzision verwenden
    --max-num-seqs 256                # Maximale Batch-Größe

Erklärung der wichtigsten Parameter:

• --gpu-memory-utilization: Wie viel GPU-Speicher verwendet werden soll (0.90 = 90%). Höhere Werte ermöglichen größere Batches, lassen aber weniger Spielraum für Speicherspitzen.
• --max-model-len: Maximale Kontextlänge. Durch Reduzierung dieses Parameters wird Speicher für größere Batches freigehalten.
• --tensor-parallel-size: Anzahl der GPUs, über die das Modell aufgeteilt wird.
• --dtype: Datentyp für Gewichte (float16, bfloat16 oder float32). FP16 ist normalerweise optimal.
• --max-num-seqs: Maximale Anzahl von Sequenzen, die in einem Batch verarbeitet werden sollen.

Vergleich vLLM vs. Ollama

Sowohl vLLM als auch Ollama sind beliebte Optionen für das lokale LLM-Hosting, zielen jedoch auf unterschiedliche Anwendungsfälle ab. Zu verstehen, wann welches Tool verwendet werden sollte, kann den Erfolg Ihres Projekts erheblich beeinflussen.

Leistung und Durchsatz

vLLM wurde für maximalen Durchsatz in Szenarien mit mehreren Benutzern entwickelt. Sein PagedAttention und Continuous Batching ermöglichen die effiziente Bereitstellung von Hunderten gleichzeitiger Anfragen. Benchmarks zeigen, dass vLLM unter hoher Gleichzeitigkeit eine 14- bis 24-mal höhere Durchsatzrate als Standardimplementierungen und eine 2- bis 4-mal höhere Durchsatzrate als Ollama erreicht.

Ollama optimiert für die interaktive Einzelbenutzernutzung mit Fokus auf niedrige Latenz für einzelne Anfragen. Obwohl es den Mehrbenutzer-Durchsatz von vLLM nicht erreicht, bietet es hervorragende Leistung für Entwicklung und persönliche Nutzung mit schnelleren Kaltstartzeiten und geringerem Ressourcenverbrauch im Leerlauf.

Benutzerfreundlichkeit

Ollama gewinnt eindeutig in Bezug auf Einfachheit. Die Installation erfolgt mit einem einzigen Befehl (curl | sh), und das Ausführen von Modellen ist so einfach wie ollama run llama2. Es verfügt über eine Modellbibliothek mit quantisierten Versionen, die für verschiedene Hardwareprofile optimiert sind. Die Benutzererfahrung ähnelt Docker – Pull, Run und los geht’s.

vLLM erfordert mehr Einrichtung: Python-Umgebungsmanagement, CUDA-Installation, Verständnis von Serving-Parametern und manuelle Modellspezifikation. Die Lernkurve ist steiler, aber Sie gewinnen eine feingranulare Kontrolle über die Leistungsoptimierung. Diese Komplexität ist gerechtfertigt für Produktionsbereitstellungen, bei denen Sie maximale Leistung aus Ihrer Hardware herausholen müssen.

API und Integration

vLLM bietet standardmäßig OpenAI-kompatible REST-APIs und ist somit ein Plug-and-Play-Ersatz für die OpenAI-API in bestehenden Anwendungen. Dies ist entscheidend für die Migration von Produktionsdiensten von Cloud-Anbietern zu selbstgehosteter Infrastruktur ohne Codeänderungen.

Ollama bietet eine einfachere REST-API und eine dedizierte Python/JavaScript-Bibliothek. Obwohl sie funktional ist, ist sie nicht OpenAI-kompatibel, was Codeänderungen bei der Integration mit Anwendungen erfordert, die das OpenAI-Format erwarten. Community-Projekte wie Ollama-OpenAI-Adapter schließen jedoch diese Lücke.

Speicherverwaltung

vLLMs PagedAttention-Algorithmus bietet eine überlegene Speichereffizienz für gleichzeitige Anfragen. Es kann mit demselben VRAM 2- bis 4-mal mehr gleichzeitige Benutzer bereitstellen als naive Implementierungen. Dies führt direkt zu Kosteneinsparungen bei Produktionsbereitstellungen.

Ollama verwendet ein einfacheres Speichermanagement, das für Einzelbenutzerszenarien geeignet ist. Es verwaltet das Laden und Entladen von Modellen automatisch basierend auf der Aktivität, was für die Entwicklung bequem ist, aber nicht für Hochfrequenz-Produktionsbetrieb optimal ist.

Multi-GPU-Unterstützung

vLLM glänzt mit nativem Tensor-Parallelismus und Pipeline-Parallelismus und verteilt Modelle effizient über 2 bis 8+ GPUs. Dies ist unerlässlich für die Bereitstellung großer Modelle wie 70B-Parameter-LLMs, die nicht in eine einzelne GPU passen.

Ollama hat derzeit eine begrenzte Multi-GPU-Unterstützung und funktioniert am besten mit einer einzelnen GPU. Dies macht es weniger geeignet für sehr große Modelle, die verteilte Inferenz erfordern.

Empfehlungen für Anwendungsfälle

Wählen Sie vLLM, wenn:

• Produktions-APIs mit vielen gleichzeitigen Benutzern bereitgestellt werden
• Die Kosten pro Anfrage in Cloud-Bereitstellungen optimiert werden sollen
• In Kubernetes oder Container-Orchestrierungsplattformen gearbeitet wird
• OpenAI-API-Kompatibilität für bestehende Anwendungen benötigt wird
• Große Modelle bereitgestellt werden, die Multi-GPU-Unterstützung erfordern
• Leistung und Durchsatz kritische Anforderungen sind

Wählen Sie Ollama, wenn:

• Lokale Entwicklung und Experimente stattfinden
• Interaktive Einzelbenutzernutzung (persönliche Assistenten, Chatbots) erfolgt
• Schnelles Prototyping und Modellbewertung stattfinden
• Über LLMs gelernt wird, ohne Infrastrukturkomplexität
• Auf persönlichen Arbeitsstationen oder Laptops gearbeitet wird
• Einfachheit und Benutzerfreundlichkeit Priorität haben

Viele Teams verwenden beide: Ollama für Entwicklung und Experimente, dann vLLM für die Produktionsbereitstellung. Diese Kombination bietet Entwicklerproduktivität bei gleichzeitiger Aufrechterhaltung der Produktionsleistung.

Vergleich vLLM vs. Docker Model Runner

Docker hat kürzlich Model Runner (früher GenAI Stack) als seine offizielle Lösung für die lokale KI-Modellbereitstellung eingeführt. Wie vergleicht er sich mit vLLM?

Architekturphilosophie

Docker Model Runner zielt darauf ab, das “Docker für KI” zu sein – eine einfache, standardisierte Möglichkeit, KI-Modelle lokal mit der gleichen Leichtigkeit auszuführen wie Container. Es abstrahiert Komplexität und bietet eine konsistente Schnittstelle über verschiedene Modelle und Frameworks hinweg.

vLLM ist eine spezialisierte Inferenz-Engine, die sich ausschließlich auf LLM-Serving mit maximaler Leistung konzentriert. Es ist ein Tool auf niedrigerer Ebene, das Sie mit Docker containerisieren, und keine komplette Plattform.

Einrichtung und erster Start

Die Installation von Docker Model Runner ist für Docker-Benutzer unkompliziert:

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

Diese Ähnlichkeit mit dem Docker-Image-Workflow macht es Entwicklern, die bereits Container verwenden, sofort vertraut.

vLLM erfordert mehr initiale Einrichtung (Python, CUDA, Abhängigkeiten) oder die Verwendung vorgefertigter Docker-Images:

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

Leistungseigenschaften

vLLM liefert aufgrund von PagedAttention und Continuous Batching einen überlegenen Durchsatz für Szenarien mit mehreren Benutzern. Für Produktions-API-Dienste, die Hunderte von Anfragen pro Sekunde verarbeiten, bieten die Optimierungen von vLLM eine 2- bis 5-mal bessere Durchsatzrate als generische Serving-Ansätze.

Docker Model Runner konzentriert sich auf Benutzerfreundlichkeit statt maximaler Leistung. Es eignet sich für die lokale Entwicklung, Tests und moderate Workloads, implementiert jedoch nicht die fortschrittlichen Optimierungen, die vLLM im großen Maßstab auszeichnen.

Modellunterstützung

Docker Model Runner bietet eine kuratierte Modellbibliothek mit Zugriff auf beliebte Modelle in einem Befehl. 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 ist spezialisiert auf LLM-Inferenz mit tiefer Unterstützung für auf Transformern basierende Sprachmodelle. Es unterstützt jedes HuggingFace-kompatible LLM, erstreckt sich jedoch nicht auf andere KI-Modelltypen wie Bildgenerierung oder Spracherkennung.

Produktionsbereitstellung

vLLM ist bei Unternehmen wie Anthropic, Replicate und vielen anderen, die täglich Milliarden von Tokens bereitstellen, erprobt. Seine Leistungseigenschaften und Stabilität unter hoher Last machen es zum De-facto-Standard für das Produktions-LLM-Serving.

Docker Model Runner ist neuer und positioniert sich eher für Entwicklungs- und lokale Test-Szenarien. Obwohl es Produktionsverkehr bedienen könnte, fehlt ihm die nachgewiesene Erfolgsbilanz und die Leistungsoptimierungen, die Produktionsbereitstellungen benötigen.

Integrationsökosystem

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

Docker Model Runner integriert sich natürlich in das Docker-Ökosystem und Docker Desktop. Für Teams, die bereits auf Docker standardisiert sind, bietet diese Integration ein kohärentes Erlebnis, jedoch weniger spezialisierte LLM-Serving-Funktionen.

Wann Sie welches Tool verwenden sollten

Verwenden Sie vLLM für:

• Produktions-LLM-API-Dienste
• Hochdurchsatz, Mehrbenutzer-Bereitstellungen
• Kostensensitive Cloud-Bereitstellungen, die maximale Effizienz benötigen
• Kubernetes- und Cloud-native Umgebungen
• Wenn Sie nachgewiesbare Skalierbarkeit und Leistung benötigen

Verwenden Sie Docker Model Runner für:

• Lokale Entwicklung und Tests
• Verschiedene KI-Modelltypen (nicht nur LLMs) ausführen
• Teams, die stark in das Docker-Ökosystem investiert sind
• Schnelle Experimente ohne Infrastruktureinrichtung
• Lern- und Bildungszwecke

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

Best Practices für Produktionsbereitstellungen

Docker-Bereitstellung

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 mistralai/Mistral-7B-Instruct-v0.2
      --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-Bereitstellung

Bereitstellen Sie vLLM auf Kubernetes für Produktionsmaßstäbe:

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
          - mistralai/Mistral-7B-Instruct-v0.2
          - --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

Überwachung und Beobachtbarkeit

vLLM stellt Prometheus-Metriken für die Überwachung bereit:

import requests

# Metriken abrufen
metrics = requests.get("http://localhost:8000/metrics").text
print(metrics)

Wichtige zu überwachende Metriken:

• vllm:num_requests_running - Aktive Anfragen
• vllm:gpu_cache_usage_perc - KV-Cache-Auslastung
• vllm:time_to_first_token - Latenzmetrik
• vllm:time_per_output_token - Generierungsgeschwindigkeit

Leistungsoptimierung

GPU-Speicherauslastung optimieren: Beginnen Sie mit --gpu-memory-utilization 0.90 und passen Sie basierend auf dem beobachteten Verhalten an. Höhere Werte ermöglichen größere Batches, bergen jedoch das Risiko von OOM-Fehlern (Out of Memory) bei Verkehrsspitzen.

Maximale Sequenzlänge anpassen: Wenn Ihr Anwendungsfall nicht die volle Kontextlänge benötigt, reduzieren Sie --max-model-len. Dies speichert Speicher für größere Batches frei. Wenn Sie beispielsweise nur 4K-Kontext benötigen, setzen Sie --max-model-len 4096 statt das Maximum des Modells zu verwenden (oft 8K-32K).

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

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

Prefix-Caching aktivieren: Für Anwendungen mit wiederholten Prompts (wie Chatbots mit Systemnachrichten) aktivieren Sie Prefix-Caching:

--enable-prefix-caching

Dies zwischenspeichert die KV-Werte für gemeinsame Präfixe und reduziert die Berechnung für Anfragen, die denselben Prompt-Präfix teilen.

Fehlerbehebung bei häufigen Problemen

Speicherüberlauf-Fehler (Out of Memory)

Symptome: Server stürzt mit CUDA-Speicherüberlauf-Fehlern ab.

Lösungen:

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

Niedriger Durchsatz

Symptome: Server verarbeitet weniger Anfragen als erwartet.

Lösungen:

• Erhöhen Sie --max-num-seqs, um größere Batches zu ermöglichen
• Erhöhen Sie --gpu-memory-utilization, wenn Spielraum vorhanden ist
• Überprüfen Sie, ob die CPU ein Engpass ist, mit htop – denken Sie an schnellere CPUs
• Überprüfen Sie die GPU-Auslastung mit nvidia-smi – sollte 95%+ betragen
• Aktivieren Sie FP16, wenn Sie FP32 verwenden: --dtype float16

Lange Zeit bis zum ersten Token

Symptome: Hohe Latenz vor Beginn der Generierung.

Lösungen:

• Verwenden Sie kleinere Modelle für latenzkritische Anwendungen
• Aktivieren Sie Prefix-Caching für wiederholte Prompts
• Reduzieren Sie --max-num-seqs, um Latenz vor Durchsatz zu priorisieren
• Betrachten Sie speculative decoding für unterstützte Modelle
• Optimieren Sie die Tensor-Parallelismus-Konfiguration

Modell-Ladefehler

Symptome: Server startet nicht, kann Modell nicht laden.

Lösungen:

• Stellen Sie sicher, dass der Modellname exakt dem HuggingFace-Format entspricht
• Überprüfen Sie die Netzwerkverbindung zum HuggingFace Hub
• Stellen Sie ausreichend Festplattenspeicher in ~/.cache/huggingface sicher
• Für geschützte Modelle setzen Sie das HF_TOKEN-Umgebungsvariable
• Versuchen Sie den manuellen Download mit huggingface-cli download <model>

Erweiterte Funktionen

Speculative Decoding

vLLM unterstützt speculative decoding, bei dem ein kleineres Entwurfsmodell Tokens vorschlägt, die ein größeres Zielmodell verifiziert. Dies kann die Generierung um 1,5- bis 2-mal beschleunigen:

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-70b-chat-hf \
    --speculative-model meta-llama/Llama-2-7b-chat-hf \
    --num-speculative-tokens 5

LoRA-Adapter

Stellen Sie mehrere LoRA-Adapter auf Basis eines Basismodells bereit, ohne mehrere vollständige Modelle laden zu müssen:

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-7b-hf \
    --enable-lora \
    --lora-modules sql-lora=./path/to/sql-adapter \
                   code-lora=./path/to/code-adapter

Geben Sie dann an, welcher Adapter pro Anfrage verwendet werden soll:

response = client.completions.create(
    model="sql-lora",  # Den SQL-Adapter verwenden
    prompt="Konvertieren Sie dies in SQL: Zeigen Sie mir alle Benutzer, die diesen Monat erstellt wurden"
)

Multi-LoRA-Bereitstellung

vLLMs Multi-LoRA-Bereitstellung ermöglicht das Hosting Dutzender feinabgestimmter Adapter mit minimalem Speicher-Overhead. Dies ist ideal für die Bereitstellung kundenspezifischer oder aufgabenbezogener Modellvarianten:

# Anfrage mit spezifischem LoRA-Adapter
response = client.chat.completions.create(
    model="meta-llama/Llama-2-7b-hf",
    messages=[{"role": "user", "content": "Schreiben Sie eine SQL-Abfrage"}],
    extra_body={"lora_name": "sql-lora"}
)

Prefix-Caching

Aktivieren Sie das automatische Prefix-Caching, um die Neuberechnung des KV-Cache für wiederholte Prompt-Präfixe zu vermeiden:

--enable-prefix-caching

Dies ist besonders effektiv für:

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

Prefix-Caching kann die Zeit bis zum ersten Token für Anfragen, die Prompt-Präfixe teilen, um 50-80% reduzieren.

Integrationsbeispiele

LangChain-Integration

from langchain.llms import VLLMOpenAI

llm = VLLMOpenAI(
    openai_api_key="EMPTY",
    openai_api_base="http://localhost:8000/v1",
    model_name="mistralai/Mistral-7B-Instruct-v0.2",
    max_tokens=512,
    temperature=0.7,
)

response = llm("Erklären Sie PagedAttention in einfachen Worten")
print(response)

LlamaIndex-Integration

from llama_index.llms import VLLMServer

llm = VLLMServer(
    api_url="http://localhost:8000/v1",
    model="mistralai/Mistral-7B-Instruct-v0.2",
    temperature=0.7,
    max_tokens=512
)

response = llm.complete("Was ist vLLM?")
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="mistralai/Mistral-7B-Instruct-v0.2",
        prompt=prompt,
        max_tokens=200
    )
    return {"result": response.choices[0].text}

Leistungsbenchmarks

Leistungsdaten aus der Praxis verdeutlichen die Vorteile von vLLM:

Vergleich des Durchsatzes (Mistral-7B auf A100-GPU):

• vLLM: ~3.500 Tokens/Sekunde bei 64 gleichzeitigen Benutzern
• HuggingFace Transformers: ~250 Tokens/Sekunde bei gleicher Gleichzeitigkeit
• Ollama: ~1.200 Tokens/Sekunde bei gleicher Gleichzeitigkeit
• Ergebnis: vLLM bietet 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 demselben 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 bei hoher Last eine konsistente Latenz aufrecht

Diese Benchmarks zeigen, warum vLLM zum De-facto-Standard für das Produktions-LLM-Serving geworden ist, bei dem Leistung entscheidend ist.

Kostenanalyse

Verständnis der Kostenauswirkungen bei der Wahl von vLLM:

Szenario: Bereitstellung von 1 Million Anfragen/Tag

Mit Standard-Serving:

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

Mit vLLM:

• Erforderlich: 2x A100-GPUs (80GB)
• AWS-Kosten: ~8 $/Stunde × 24 × 30 = 5.760 $/Monat
• Kosten pro 1 Million Tokens: ~0,19 $
• Einsparungen: 17.280 $/Monat (75% Reduktion)

Dieser Kostenvorteil wächst mit dem Maßstab. Organisationen, die monatlich Milliarden von Tokens bereitstellen, sparen Hunderttausende von Dollar, indem sie die optimierte Bereitstellung von vLLM statt naiver Implementierungen verwenden.

Sicherheitsaspekte

Authentifizierung

vLLB enthält standardmäßig keine Authentifizierung. Für die Produktion implementieren Sie Authentifizierung auf der Ebene des Reverse-Proxys:

# 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 Authentifizierung und Rate Limiting auf Unternehmensebene.

Netzwerkisolierung

Führen Sie vLLM in privaten Netzwerken aus, nicht direkt im Internet exponiert:

# 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 mit 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 überschritten")
    
    return await call_next(request)

Modellzugriffskontrolle

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

ALLOWED_MODELS = {
    "user_tier_1": ["mistralai/Mistral-7B-Instruct-v0.2"],
    "user_tier_2": ["mistralai/Mistral-7B-Instruct-v0.2", "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

Migrationsanleitung

Von OpenAI zu vLLM

Die Migration von OpenAI zu selbstgehostetem vLLM ist dank API-Kompatibilität unkompliziert:

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": "Hallo"}]
)

Nachher (vLLM):

from openai import OpenAI

client = OpenAI(
    base_url="https://your-vllm-server.com/v1",
    api_key="your-internal-key"  # Falls Sie Authentifizierung hinzugefügt haben
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "Hallo"}]
)

Es sind nur zwei Änderungen erforderlich: base_url und model-Name aktualisieren. Der gesamte übrige Code bleibt identisch.

Von Ollama zu vLLM

Ollama verwendet ein anderes API-Format. Hier ist die Umwandlung:

Ollama API:

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={
        'model': 'llama2',
        'prompt': 'Warum ist der Himmel blau?'
    })

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="Warum ist der Himmel blau?"
)

Sie müssen API-Aufrufe in Ihrer gesamten Codebasis aktualisieren, aber die OpenAI-Client-Bibliotheken bieten bessere Fehlerbehandlung und Funktionen.

Von HuggingFace Transformers zu vLLM

Migration der direkten Python-Nutzung:

HuggingFace:

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")
tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")

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="mistralai/Mistral-7B-Instruct-v0.2")
sampling_params = SamplingParams(max_tokens=100)

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

vLLMs Python-API ist einfacher und viel schneller für Batch-Inferenz.

Die Zukunft von vLLM

vLLM entwickelt sich weiterhin rasch mit aufregenden Funktionen auf der Roadmap:

Disaggregiertes Serving: Trennung von Prefill (Prompt-Verarbeitung) und Decode (Token-Generierung) auf verschiedene GPUs zur Optimierung der Ressourcennutzung. Prefill ist rechenintensiv, während Decode speicherintensiv ist, sodass die Ausführung auf spezialisierter Hardware die Effizienz verbessert.

Multi-Node-Inferenz: Verteilung sehr großer Modelle (100B+ Parameter) über mehrere Maschinen, um die Bereitstellung von Modellen zu ermöglichen, die für Einzelknoten-Setups zu groß sind.

Verbesserte Quantisierung: Unterstützung neuer Quantisierungsformate wie GGUF (verwendet von llama.cpp) und verbesserte AWQ/GPTQ-Integration für bessere Leistung mit quantisierten Modellen.

Verbesserungen beim speculative decoding: Effizientere Entwurfsmodelle und adaptive Spekulationsstrategien, um höhere Beschleunigungen ohne Genauigkeitsverlust zu erzielen.

Aufmerksamkeitsoptimierungen: FlashAttention 3, Ring-Attention für extrem lange Kontexte (100K+ Tokens) und andere hochmoderne Aufmerksamkeitsmechanismen.

Bessere Modellabdeckung: Erweiterung der Unterstützung auf Multimodellmodelle (Vision-Language-Modelle), Audimodelle und spezialisierte Architekturen, wie sie entstehen.

Das vLLM-Projekt pflegt aktive Entwicklung mit Beiträgen von UC Berkeley, Anyscale und der breiteren Open-Source-Community. Während die LLM-Bereitstellung für Produktionssysteme immer kritischer wird, wächst die Rolle von vLLM als Leistungsstandard weiter.

Für einen breiteren Vergleich von vLLM mit anderer lokaler und Cloud-LLM-Infrastruktur überprüfen Sie unsere LLM Hosting: Lokal, Selbstgehostet & Cloud-Infrastruktur im Vergleich.

Nützliche Links

Verwandte Artikel auf dieser Website

• Lokales LLM-Hosting: Vollständige 2026-Anleitung - Ollama, vLLM, LocalAI, Jan, LM Studio & Mehr - Umfassender Vergleich von 12+ lokalen LLM-Hosting-Tools einschließlich detaillierter vLLM-Analyse alongside Ollama, LocalAI, Jan, LM Studio und anderen. Deckt API-Reife, Tool-Aufruf-Unterstützung, GGUF-Kompatibilität und Leistungsbenchmarks ab, um die richtige Lösung zu wählen.

• Ollama Cheatsheet - Vollständige Ollama-Befehlsreferenz und Cheatsheet, das Installation, Modellverwaltung, API-Nutzung und Best Practices für lokales LLM-Deployment abdeckt. Wesentlich für Entwickler, die Ollama neben oder statt vLLM verwenden.

• llama.cpp Schnellstart mit CLI und Server - Leichtgewichtiges C/C++-Inferenz für GGUF-Modelle mit llama-cli und OpenAI-kompatiblem llama-server. Ideal, wenn Sie feingranulare Kontrolle, Offline-Bereitstellung oder einen minimalen Stack ohne Python benötigen.

• Docker Model Runner vs. Ollama: Was sollten Sie wählen? - Tiefgehender Vergleich von Docks Model Runner und Ollama für lokales 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.

• Docker Model Runner Cheatsheet: Befehle & Beispiele - Praktisches Docker Model Runner Cheatsheet mit Befehlen und Beispielen für KI-Modellbereitstellung. Nützlich für Teams, die Docks Ansatz mit vLLMs spezialisierten LLM-Serving-Fähigkeiten vergleichen.

Externe Ressourcen und Dokumentation

• vLLM GitHub Repository - Offizielles vLLM-Repository mit Quellcode, umfassender Dokumentation, Installationsanleitungen und aktiven Community-Diskussionen. Wesentliche Ressource, um über die neuesten Funktionen und Fehlerbehebungen auf dem Laufenden zu bleiben.

• vLLM Dokumentation - Offizielle Dokumentation, die alle Aspekte von vLLM von der Basis-Einrichtung bis zur erweiterten Konfiguration abdeckt. Enthält API-Referenzen, Leistungsoptimierungsleitfäden und Bereitstellungs-Best Practices.

• PagedAttention Paper - Wissenschaftliches Papier, das den PagedAttention-Algorithmus einführt, der vLLMs Effizienz antreibt. Wesentliches Lesen, um die technischen Innovationen hinter vLLMs Leistungsvorteilen zu verstehen.

• vLLM Blog - Offizieller vLLM-Blog mit Veröffentlichungsankündigungen, Leistungsbenchmarks, technischen Tiefenanalysen und Community-Fallstudien aus Produktionsbereitstellungen.

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

• Ray Serve Dokumentation - Ray Serve-Framework-Dokumentation für den Aufbau skalierbarer, verteilter vLLM-Bereitstellungen. Ray bietet erweiterte Funktionen wie Autoscaling, Multi-Modell-Serving und Ressourcenmanagement 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 Vergleich und Verständnis der Inferenz-Optimierungslandschaft.

• OpenAI API Referenz - Offizielle OpenAI-API-Dokumentation, mit der vLLMs API kompatibel ist. Referenzieren Sie dies beim Aufbau von Anwendungen, die sowohl mit OpenAI als auch selbstgehosteten vLLM-Endpunkten wechselnd arbeiten müssen.