vLLM Quickstart: Hochleistungsfähiges LLM-Serving – im Jahr 2026

vLLM ist eine hochleistungsfähige, speichereffiziente Engine für die Inferenz und Bereitstellung von großen Sprachmodellen (LLMs), entwickelt vom Sky Computing Lab der UC Berkeley.

Mit ihrem revolutionären PagedAttention-Algorithmus erreicht vLLM eine 14- bis 24-fach höhere Durchsatzrate als herkömmliche Bereitstellungsmethoden, was es zur bevorzugten Wahl für produktive LLM-Deploymentes macht. Um zu sehen, wie vLLM sich im Vergleich zu Ollama, Docker Model Runner, LocalAI und Cloud-Anbietern positioniert – einschließlich der Abwägungen zwischen Kosten und Infrastruktur –, siehe LLM-Hosting: Lokale, selbst gehostete und Cloud-Infrastrukturen im Vergleich.

Was ist vLLM?

vLLM (virtual LLM) ist eine Open-Source-Bibliothek für schnelle LLM-Inferenz und -Bereitstellung, die schnell zum Industriestandard für produktive Deployments geworden ist. Veröffentlicht im Jahr 2023, führte sie PagedAttention ein, eine wegweisende Speicherverwaltungstechnik, die die Effizienz der Bereitstellung drastisch verbessert.

Kernfunktionen

Hoher Durchsatz: vLLM liefert eine 14- bis 24-fach höhere Durchsatzrate im Vergleich zu HuggingFace Transformers bei gleicher Hardware. Dieser massive Leistungsgewinn stammt aus kontinuierlichem Batching, optimierten CUDA-Kernels und dem PagedAttention-Algorithmus, der Speicherfragmentierung eliminiert.

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

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

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

Multi-GPU-Support: vLLM unterstützt Tensor Parallelism und Pipeline Parallelism 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.

Umfassende Modellunterstützung: Kompatibel mit beliebten Modellarchitekturen einschließlich LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma und vielen anderen. Unterstützt sowohl instruktionsjustierte als auch Basis-Modelle vom HuggingFace Hub.

Wann vLLM verwenden

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

Produktive API-Dienste: Wenn Sie ein LLM über eine API für viele gleichzeitige Benutzer bereitstellen müssen, machen die hohe Durchsatzrate und die effiziente Batching-Fähigkeit von vLLM es zur besten Wahl. Unternehmen, die Chatbots, Code-Assistenten oder Content-Generierungs-Dienste betreiben, profitieren von seiner Fähigkeit, Hunderte von Anfragen pro Sekunde zu bearbeiten.

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

Kostenoptimierung: Wenn GPU-Kosten ein Anliegen sind, bedeutet die überlegene Durchsatzrate von vLLM, dass Sie denselben Verkehr mit weniger GPUs bedienen können, was die Infrastrukturkosten direkt senkt. Die 4-fache Speichereffizienz durch PagedAttention erlaubt es auch, kleinere, günstigere GPU-Instanzen zu nutzen.

Kubernetes-Deployments: 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 vLLM NICHT verwenden: Für lokale Entwicklung, Experimente oder Ein-Benutzer-Szenarien bieten Werkzeuge wie Ollama oder llama.cpp eine bessere Benutzererfahrung mit einfacherer Einrichtung. Die Komplexität von vLLM ist gerechtfertigt, wenn Sie für produktive Workloads seine Leistungsvorteile benötigen.

So installieren Sie 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 Serie)
• 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 via pip

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

# Create a virtual environment (recommended)
python3 -m venv vllm-env
source vllm-env/bin/activate

# Install vLLM
pip install vllm

# Verify installation
python -c "import vllm; print(vllm.__version__)"

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

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

# For 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 Bereitstellungs-Methode, insbesondere für Produktion:

# Pull the official vLLM image
docker pull vllm/vllm-openai:latest

# Run vLLM with GPU support
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

Der --ipc=host-Flag ist für Multi-GPU-Setups wichtig, da er die korrekte Interprozesskommunikation ermöglicht.

Kompilierung aus dem Quellcode

Für die neuesten Funktionen oder eigene Modifikationen aus dem Quellcode bauen:

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

vLLM Schnellstart-Anleitung

Ihr erstes Modell ausführen

Starten Sie vLLM mit einem Modell über die Kommandozeile:

# Download and serve Mistral-7B with OpenAI-compatible API
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000

vLLM lädt das Modell automatisch vom HuggingFace Hub herunter (wenn es nicht im Cache ist) und startet den Server. 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 senden

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

Mit curl:

curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "mistralai/Mistral-7B-Instruct-v0.2",
        "prompt": "Explain what vLLM is in one sentence:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

Mit OpenAI-Python-Client:

from openai import OpenAI

# Point to your vLLM server
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # vLLM doesn't require authentication by default
)

response = client.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    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="mistralai/Mistral-7B-Instruct-v0.2",
    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 Optimierung der Leistung:

python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000 \
    --gpu-memory-utilization 0.95 \  # Use 95% of GPU memory
    --max-model-len 8192 \            # Maximum sequence length
    --tensor-parallel-size 2 \        # Use 2 GPUs with tensor parallelism
    --dtype float16 \                 # Use FP16 precision
    --max-num-seqs 256                # Maximum batch size

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 Puffer für Speicher-Spitzen.
• --max-model-len: Maximale Kontextlänge. Das Reduzieren dieser spart Speicher für größere Batches.
• --tensor-parallel-size: Anzahl der GPUs, über die das Modell verteilt wird.
• --dtype: Datentyp für die Gewichte (float16, bfloat16 oder float32). FP16 ist in der Regel optimal.
• --max-num-seqs: Maximale Anzahl von Sequenzen, die in einem Batch verarbeitet werden.

vLLM vs. Ollama

vLLM ist für hochvolumige, Multi-User-Produktionsbereitstellung mit kontinuierlichem Batching, PagedAttention und Multi-GPU-Support konzipiert. Ollama optimiert für schnelle lokale Einrichtung, Ein-Benutzer-Bequemlichkeit und einfaches Modellmanagement.

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 hat kürzlich Model Runner (ehemals GenAI Stack) als offizielle Lösung für den lokalen AI-Model Deployment eingeführt. Wie verhält es sich im Vergleich zu vLLM?

Architekturphilosophie

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

vLLM ist eine spezialisierte Inferenz-Engine, die sich ausschließlich auf die Bereitstellung von LLMs mit maximaler Leistung konzentriert. Es ist ein Werkzeug niedrigerer Ebene, das Sie mit Docker containerisieren, anstatt eine komplette Plattform.

Einrichtung und Einstieg

Die Installation von Docker Model Runner ist für Docker-Nutzer 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 anfängliche Einrichtung (Python, CUDA, Abhängigkeiten) oder die Verwendung vorbaueter Docker-Images:

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

Leistungscharakteristik

vLLM liefert eine überlegene Durchsatzrate für Multi-User-Szenarien dank PagedAttention und kontinuierlichem Batching. Für produktive API-Dienste, die Hunderte von Anfragen pro Sekunde verarbeiten, bieten die Optimierungen von vLLM eine 2- bis 5-fach bessere Durchsatzrate als allgemeine Bereitstellungsmethoden.

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

Modellunterstützung

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

vLLM spezialisiert sich auf die LLM-Inferenz mit tiefgreifender Unterstützung für Transformer-basierte Sprachmodelle. Es unterstützt jede HuggingFace-kompatible LLM, erstreckt sich aber nicht auf andere AI-Modelltypen wie Bildgenerierung oder Spracherkennung.

Produktive Bereitstellung

vLLM ist in Produktion bei Unternehmen wie Anthropic, Replicate und vielen anderen erprobt, die täglich Milliarden von Tokens bereitstellen. Seine Leistungsmerkmale und Stabilität unter hoher Last machen es zum De-facto-Standard für die produktive Bereitstellung von LLMs.

Docker Model Runner ist neuer und positioniert sich eher für Entwicklungs- und lokale Testszenarien. Obwohl es produktiven Verkehr bedienen könnte, fehlt es der bewährten Leistungshistorie und den Leistungs­optimierungen, die produktive Deployments erfordern.

Integrations-Ökosystem

vLLM integriert sich mit produktiven Infrastrukturenwzeugen: Kubernetes-Operatoren, Prometheus-Metriken, Ray für verteilte Bereitstellung und umfassende OpenAI-API-Kompatibilität für vorhandene Anwendungen.

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

Wann welches verwenden

Verwenden Sie vLLM für:

• Produktive LLM-API-Dienste
• Hochvolumige, Multi-User-Deployments
• Kostenbewusste Cloud-Deployments, die maximale Effizienz benötigen
• Kubernetes- und Cloud-native-Umgebungen
• Wenn Sie bewiesene Skalierbarkeit und Leistung benötigen

Verwenden Sie Docker Model Runner für:

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

Hybrider Ansatz: Viele Teams entwickeln lokal mit Docker Model Runner für Bequemlichkeit und deployen dann in der Produktion mit vLLM 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 produktive 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 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-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
          - 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

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

Wichtige Metriken zur Überwachung:

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

Leistungs-Tuning

GPU-Speichernutzung optimieren: Beginnen Sie mit --gpu-memory-utilization 0.90 und passen Sie dies basierend auf beobachtetem Verhalten an. Höhere Werte ermöglichen größere Batches, bergen aber das Risiko von OOM-Fehlern während Verkehrsspitzen.

Maximale Sequenzlänge anpassen: Wenn Ihr Anwendungsfall keine volle Kontextlänge benötigt, reduzieren Sie --max-model-len. Dies befreit Speicher für größere Batches. Wenn Sie beispielsweise nur 4K Kontext benötigen, setzen Sie --max-model-len 4096 anstelle der Modell-Maximalwert (oft 8K-32K) zu verwenden.

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

--quantization awq  # For AWQ quantized models
--quantization gptq # For GPTQ quantized models

Präfix-Caching aktivieren: Für Anwendungen mit wiederholten Prompts (wie Chatbots mit System-Nachrichten), aktivieren Sie Präfix-Caching:

--enable-prefix-caching

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

Fehlersuche bei häufigen Problemen

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 dies 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

Auf einer einzelnen 16-GB-Karte gehen die meisten dieser OOM-Fehler auf das KV-Cache-Budget zurück, nicht nur auf die Gewichte – KV-Cache auf 16-GB-GPUs deckt die exakte Formel, FP8-KV-Cache-Datatype und Präfix-Caching-Trade-offs hinter --max-model-len und --max-num-seqs ab, bevor Sie zu einem kleineren Modell greifen.

Geringe Durchsatzrate

Symptome: Server bearbeitet weniger Anfragen als erwartet.

Lösungen:

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

Lange Zeit bis zum ersten Token

Symptome: Hohe Latenz, bevor die Generierung startet.

Lösungen:

• Verwenden Sie kleinere Modelle für latenzkritische Anwendungen
• Aktivieren Sie Präfix-Caching für wiederholte Prompts
• Reduzieren Sie --max-num-seqs, um Latenz gegenüber Durchsatz zu priorisieren
• Erwägen Sie spekulatives Dekodieren für unterstützte Modelle
• Optimieren Sie die Tensor-Parallelism-Konfiguration

Modelllade-Fehler

Symptome: Server kann nicht starten, kann Modell nicht laden.

Lösungen:

• Stellen Sie sicher, dass der Modellname exakt dem HuggingFace-Format entspricht
• Prüfen Sie die Netzwerkverbindung zum HuggingFace Hub
• Stellen Sie ausreichenden Speicherplatz in ~/.cache/huggingface sicher
• Setzen Sie für gate-Modelle die HF_TOKEN-Umgebungsvariable
• Versuchen Sie, manuell herunterzuladen mit huggingface-cli download <model>

Fortgeschrittene Funktionen

Spekulatives Dekodieren

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

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

Bereitstellen mehrerer LoRA-Adapter über einem Basis-Modell, ohne mehrere volle Modelle zu laden:

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 pro Anfrage an, welcher Adapter verwendet werden soll:

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

Multi-LoRA-Bereitstellung

Die Multi-LoRA-Bereitstellung von vLLM ermöglicht das Hosting Dutzender fein justierter Adapter mit minimalem Speicherüberhang. Dies ist ideal für die Bereitstellung kundenspezifischer oder aufgabenspezifischer Modellvarianten:

# Request with specific LoRA adapter
response = client.chat.completions.create(
    model="meta-llama/Llama-2-7b-hf",
    messages=[{"role": "user", "content": "Write SQL query"}],
    extra_body={"lora_name": "sql-lora"}
)

Präfix-Caching

Aktivieren Sie automatisches Präfix-Caching, um das erneute Berechnen 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 Kontext-Vorlagen
• Few-Shot-Learning-Prompts, die über Anfragen hinweg wiederholt werden

Präfix-Caching kann die Zeit bis zum ersten Token für Anfragen mit geteilten Prompt-Präfixen 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("Explain PagedAttention in simple terms")
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("What is 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}

Leistungsbewertungen

Praktische Leistungsdaten helfen, die Vorteile von vLLM zu veranschaulichen:

Durchsatz-Vergleich (Mistral-7B auf A100 GPU):

• vLLM: ~3.500 Tokens/Sekunde mit 64 gleichzeitigen Benutzern
• HuggingFace Transformers: ~250 Tokens/Sekunde mit gleicher Parallelität
• Ollama: ~1.200 Tokens/Sekunde mit gleicher Parallelität
• Ergebnis: vLLM bietet 14-fach Verbesserung gegenüber Basis-Implementierungen

Speichereffizienz (LLaMA-2-13B):

• Standard-Implementierung: 24GB VRAM, 32 gleichzeitige Sequenzen
• vLLM mit PagedAttention: 24GB VRAM, 128 gleichzeitige Sequenzen
• Ergebnis: 4-fach 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-Bereitstellung: P50 Latenz 650ms, P99 Latenz 3.200ms bei 100 req/s
• Ergebnis: vLLM hält konsistente Latenz unter hoher Last

Diese Benchmarks belegen, warum vLLM zum De-facto-Standard für die produktive LLM-Bereitstellung geworden ist, wo Leistung entscheidend ist.

Kostenanalyse

Die Kosteneinflüsse der Wahl von vLLM zu verstehen:

Szenario: 1 Mio. Anfragen/Tag bereitstellen

Mit Standard-Bereitstellung:

• 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 $
• Einsparungen: 17.280 $/Monat (75 % Reduktion)

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

Sicherheitsüberlegungen

Authentifizierung

vLLM enthält standardmäßig keine Authentifizierung. Für Produktion implementieren Sie die Authentifizierung auf Reverse-Proxy-Ebene:

# Nginx configuration
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 unternehmensfähige Authentifizierung und Rate-Limiting.

Netzwerktrennung

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

# Kubernetes NetworkPolicy example
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:

# Example using Redis for 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 second window
    
    if requests > 60:  # 60 requests per 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": ["mistralai/Mistral-7B-Instruct-v0.2"],
    "user_tier_2": ["mistralai/Mistral-7B-Instruct-v0.2", "meta-llama/Llama-2-13b-chat-hf"],
    "admin": ["*"]  # All models
}

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 auf selbst gehostetes vLLM ist dank der 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": "Hello"}]
)

Nachher (vLLM):

from openai import OpenAI

client = OpenAI(
    base_url="https://your-vllm-server.com/v1",
    api_key="your-internal-key"  # If you added authentication
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "Hello"}]
)

Nur zwei Änderungen erforderlich: base_url und den Modellnamen aktualisieren. Der restliche Code bleibt identisch.

Von Ollama zu vLLM

Ollama verwendet ein anderes API-Format. Die grundlegende clientseitige Änderung besteht darin, von Ollamas REST-Endpoint auf vLLMs OpenAI-kompatible API zu wechseln:

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?"
)

Für einen gründlichen Migrationsleitfaden, der Modellwahl, Chat-Vorlagen, gestaffelte Migration und eine praktische Checkliste abdeckt, siehe Ollama to vLLM: Wann Sie Ihren lokalen LLM-Server migrieren sollten.

Von HuggingFace Transformers zu vLLM

Direkte Python-Verwendungs-Migration:

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 für Batch-Inferenz viel schneller.

Zukunft von vLLM

vLLM entwickelt sich schnell weiter, mit aufregenden Funktionen auf der Roadmap:

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

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

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

Verbesserungen des spekulativen Dekodierens: Effizientere Entwurfsmodelle und adaptive Spekulationsstrategien, um höhere Geschwindigkeitszuwächse ohne Genauigkeitsverlust zu erzielen.

Attention-Optimierungen: FlashAttention 3, Ring Attention für extrem lange Kontexte (100K+ Tokens) und andere Cutting-edge-Attention-Mechanismen.

Bessere Modellabdeckung: Erweiterung der Unterstützung auf multimodale Modelle (Vision-Language-Modelle), Audiomodelle und spezialisierte Architekturen, wie sie aufkommen.

Das vLLM-Projekt pflegt eine aktive Entwicklung mit Beiträgen von UC Berkeley, Anyscale und der breiteren Open-Source-Community. Da LLM-Deployment für Produktionssysteme immer wichtiger wird, wächst die Rolle von vLLM als Leistungsstandard weiter. Für einen breiteren Vergleich von vLLM mit anderen lokalen und Cloud-LLM-Infrastrukturen, schauen Sie sich unseren LLM-Hosting: Lokale, selbst gehostete und Cloud-Infrastrukturen im Vergleich.

Nützliche Links

Verwandte Artikel auf dieser Seite

• Lokales LLM-Hosting: Umfassender 2026-Guide - Ollama, vLLM, LocalAI, Jan, LM Studio & mehr - Umfassender Vergleich von 12+ lokalen LLM-Hosting-Werkzeugen, einschließlich detaillierter vLLM-Analyse neben Ollama, LocalAI, Jan, LM Studio und anderen. Deckt API-Reife, Tool-Calling-Unterstützung, GGUF-Kompatibilität und Leistungs-Benchmarks ab, um die richtige Lösung auszuwählen.

• Ollama-Spickzettel - Vollständiger Ollama-Befehlssatz und Spickzettel, der Installation, Modellmanagement, API-Nutzung und Best Practices für das lokale LLM-Hosting abdeckt. Unverzichtbar für Entwickler, die Ollama neben oder anstelle von vLLM verwenden.

• llama.cpp Schnellstart mit CLI und Server - Leichte 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: Welches wählen? - Tiefgehender Vergleich von Docr Model Runner und Ollama für die lokale LLM-Bereitstellung, Analyse von Leistung, GPU-Unterstützung, API-Kompatibilität und Anwendungsfällen. Hilft, das Wettbewerbsumfeld zu verstehen, in dem vLLM operiert.

• Docker Model Runner Spickzettel: Befehle & Beispiele - Praktischer Docker Model Runner Spickzettel mit Befehlen und Beispielen für die AI-Modell-Bereitstellung. Nützlich für Teams, die Docrs Ansatz mit den spezialisierten LLM-Bereitstellungsfähigkeiten von vLLM vergleichen.

Externe Ressourcen und Dokumentation

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

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

• PagedAttention-Paper - Wissenschaftliches Paper, das den PagedAttention-Algorithmus einführt, der die Effizienz von vLLM antreibt. Pflichtlektüre zum Verständnis der technischen Innovationen hinter vLLMs Leistungsvorteilen.

• vLLM Blog - Offizieller vLLM-Blog mit Release-Ankündigungen, Leistungs-Benchmarks, technischen Deep Dives und Community-Case Studies aus produktiven Deployments.

• HuggingFace Modell-Hub - Umfassender 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 - Ray Serve Framework Dokumentation zum Aufbau skalierbarer, verteilter vLLM-Deployments. Ray bietet erweiterte Funktionen wie Autoscaling, Multi-Modell-Bereitstellung und Ressourcenmanagement für Produktionssysteme.

• NVIDIA TensorRT-LLM - NVIDIA 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 des Inferenz-Optimierungs-Landschafts.

• OpenAI API Referenz - Offizielle OpenAI-API-Dokumentation, mit der vLLMs API kompatibel ist. Referenzieren Sie dies bei der Entwicklung von Anwendungen, die mit sowohl OpenAI als auch selbst gehosteten vLLM-Endpoints vertauschbar arbeiten müssen.