vLLM Schnellstart: Hochperformantes LLM-Serving – in 2026

vLLM ist eine hochperformante, speichereffiziente Inferenz- und Serving-Engine für Large Language Models (LLMs), die vom Sky Computing Lab der UC Berkeley entwickelt wurde.

Mit seinem revolutionären PagedAttention-Algorithmus erreicht vLLM eine 14- bis 24-fach höhere Durchsatzrate als traditionelle Serving-Methoden, was es zur bevorzugten Wahl für Produktions-Deployments von LLMs macht. Um zu sehen, wie vLLM im Vergleich zu Ollama, Docker Model Runner, LocalAI und Cloud-Anbietern abschneidet – einschließlich Kosten- und Infrastruktur-Trade-offs – lesen Sie LLM-Hosting: Lokale, Self-Hosted- und Cloud-Infrastruktur im Vergleich.

Was ist vLLM?

vLLM (Virtual LLM) ist eine Open-Source-Bibliothek für schnelles LLM-Inferenz- und Serving, die sich schnell zum Industriestandard für Produktionsdeployments entwickelt hat. Veröffentlicht 2023, führte es PagedAttention ein, eine bahnbrechende Speicherverwaltungstechnik, die die Serving-Effizienz dramatisch verbessert.

Hauptmerkmale

Hohe Durchsatzleistung: vLLM liefert einen 14- bis 24-fach höheren Durchsatz im Vergleich zu HuggingFace Transformers auf derselben Hardware. Dieser massive Leistungsgewinn resultiert aus Continuous Batching, optimierten CUDA-Kernels und dem PagedAttention-Algorithmus, der Speicherfragmentierung eliminiert.

OpenAI-API-Kompatibilität: vLLM enthält einen integrierten API-Server, der vollständig mit dem Format von OpenAI kompatibel ist. Dies ermöglicht eine nahtlose Migration von OpenAI zu self-hosted Infrastruktur, ohne den Anwendungscode ändern zu müssen. Leiten Sie einfach Ihren API-Client auf vLLMs Endpunkt um, und es funktioniert transparent.

PagedAttention-Algorithmus: Die Kerninnovation hinter vLLMs Leistung 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 Blöcke fester Größe, die bedarfsgerecht zugewiesen werden können. Dies reduziert die Verschwendung von Speicher um bis zu 4-fach und ermöglicht deutlich größere Batch-Größen.

Continuous Batching: Im Gegensatz zum statischen Batching, bei dem man wartet, bis alle Sequenzen abgeschlossen sind, verwendet vLLM kontinuierliches (Rolling) Batching. Sobald eine Sequenz fertig 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-Parallelität und Pipeline-Parallelität, um große Modelle auf mehrere GPUs zu verteilen. Es kann effizient Modelle bedienen, 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 Basis-Modelle von HuggingFace Hub.

Wann man vLLM verwenden sollte

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 Nutzer bereitstellen müssen, machen vLLMs hoher Durchsatz und effizientes Batching es zur besten Wahl. Unternehmen, die Chatbots, Code-Assistenten oder Content-Generierungs-Dienste betreiben, profitieren von der Fähigkeit, Hunderte von Anfragen pro Sekunde zu bewältigen.

Workloads mit hoher Konkurrenz: Wenn Ihre Anwendung viele gleichzeitige Nutzer hat, die Anfragen stellen, ermöglichen vLLMs Continuous Batching und PagedAttention das Bedienen mehrerer Nutzer mit derselben Hardware im Vergleich zu Alternativen.

Kostenoptimierung: Wenn GPU-Kosten eine Rolle spielen, bedeutet vLLMs überlegener Durchsatz, dass Sie den gleichen Verkehr mit weniger GPUs bedienen können, was die Infrastrukturkosten direkt reduziert. Die 4-fache Speichereffizienz durch PagedAttention ermöglicht auch die Verwendung kleinerer, günstigerer GPU-Instanzen.

Kubernetes-Deployments: vLLMs zustandsloses Design und containerfreundliche Architektur machen es ideal für Kubernetes-Cluster. Seine konsistente Leistung unter Last und das einfache Ressourcenmanagement integrieren sich gut in cloud-native Infrastrukturen.

Wann man vLLM NICHT verwenden sollte: Für lokale Entwicklung, Experimente oder Single-User-Szenarien bieten Tools wie Ollama oder llama.cpp eine bessere Benutzererfahrung mit einfacherer Einrichtung. vLLMs Komplexität ist nur dann gerechtfertigt, wenn Sie seine Leistungsvorteile für Produktionsworkloads benötigen.

Wie man vLLM installiert

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 über pip

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

# Erstellen Sie eine virtuelle Umgebung (empfohlen)
python3 -m venv vllm-env
source vllm-env/bin/activate

# Installieren Sie vLLM
pip install vllm

# Überprüfen Sie die Installation
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 Deployment-Methode, insbesondere für die Produktion:

# Ziehen Sie das offizielle vLLM-Image
docker pull vllm/vllm-openai:latest

# Starten Sie vLLM mit GPU-Unterstützung
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 Flag --ipc=host ist wichtig für Multi-GPU-Setups, da er eine ordnungsgemäße Interprozesskommunikation ermöglicht.

Erstellen aus dem Quellcode

Für die neuesten Funktionen oder benutzerdefinierte Modifikationen erstellen Sie aus dem Quellcode:

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

vLLM Schnellstart-Leitfaden

Ausführen Ihres ersten Modells

Starten Sie vLLM mit einem Modell über die Befehlszeilenschnittstelle:

# Laden Sie Mistral-7B herunter und bedienen Sie es mit einer OpenAI-kompatiblen API
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000

vLLM lädt das Modell automatisch von HuggingFace Hub herunter (falls nicht gecacht) 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 stellen

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

Verwendung von 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
    }'

Verwendung des OpenAI Python-Clients:

from openai import OpenAI

# Zeigen Sie auf Ihren vLLM-Server
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": "Du bist ein hilfreicher Assistent."},
        {"role": "user", "content": "Was ist 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 \  # Verwenden Sie 95% des GPU-Speichers
    --max-model-len 8192 \            # Maximale Sequenzlänge
    --tensor-parallel-size 2 \        # Verwenden Sie 2 GPUs mit Tensor-Parallelität
    --dtype float16 \                 # Verwenden Sie FP16-Präzision
    --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 Puffer für Speicherspitzen.
• --max-model-len: Maximale Kontextlänge. Die Reduzierung dieser Einstellung spart Speicher für größere Batches.
• --tensor-parallel-size: Anzahl der GPUs, auf die das Modell aufgeteilt werden soll.
• --dtype: Datentyp für Gewichte (float16, bfloat16 oder float32). FP16 ist in der Regel optimal.
• --max-num-seqs: Maximale Anzahl von Sequenzen, die in einer Batch verarbeitet werden sollen.

vLLM vs. Ollama

vLLM ist für hochperformantes, multi-user Produktions-Serving mit Continuous Batching, PagedAttention und Multi-GPU-Unterstützung entwickelt. Ollama optimiert für schnelles lokales Setup, Single-User-Bequemlichkeit und einfaches Modellmanagement.

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

vLLM vs. Docker Model Runner

Docker hat kürzlich Model Runner (ehemals GenAI Stack) als ihre offizielle Lösung für die lokale Deployment von KI-Modellen eingeführt. Wie vergleicht es sich mit vLLM?

Architekturphilosophie

Docker Model Runner zielt darauf ab, das “Docker für KI” zu sein – ein einfacher, standardisierter Weg, 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, anstatt eine vollständige Plattform zu sein.

Setup und Einstieg

Docker Model Runner Installation ist für Docker-Nutzer unkompliziert:

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

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

vLLM erfordert mehr initiales Setup (Python, CUDA, Abhängigkeiten) oder die Verwendung von vorerstellten Docker-Images:

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

Leistungsmerkmale

vLLM liefert überlegenen Durchsatz für Multi-User-Szenarien aufgrund von PagedAttention und Continuous Batching. Für Produktions-API-Dienste, die Hunderte von Anfragen pro Sekunde bearbeiten, bieten vLLMs Optimierungen einen 2- bis 5-fach besseren Durchsatz als generische Serving-Ansätze.

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

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 andere KI-Modelle, was es vielseitiger für verschiedene KI-Workloads macht.

vLLM spezialisiert sich auf LLM-Inferenz mit tiefgehender Unterstützung für transformer-basierte Sprachmodelle. Es unterstützt jedes mit HuggingFace kompatible LLM, erweitert sich jedoch nicht auf andere KI-Modelltypen wie Bildgenerierung oder Spracherkennung.

Produktions-Deployment

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

Docker Model Runner ist neuer und positioniert sich eher für Entwicklungs- und lokale Testszenarien. Während es Produktionsverkehr bedienen könnte, fehlt ihm die bewährte Erfolgsbilanz und die Leistungsoptimierungen, die Produktionsdeployments erfordern.

Integration Ökosystem

vLLM integriert sich mit Produktionsinfrastruktur-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 Docker’s Ökosystem und Docker Desktop. Für Teams, die bereits auf Docker standardisiert haben, bietet diese Integration ein kohärentes Erlebnis, aber weniger spezialisierte LLM-Serving-Funktionen.

Wann man jedes verwenden sollte

Verwenden Sie vLLM für:

• Produktions-LLM-API-Dienste
• Hochleistungs-, Multi-User-Deployments
• Kostensensitive Cloud-Deployments, die maximale Effizienz benötigen
• Kubernetes- und Cloud-native-Umgebungen
• Wenn Sie bewährte Skalierbarkeit und Leistung benötigen

Verwenden Sie Docker Model Runner für:

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

Hybrider Ansatz: Viele Teams entwickeln mit Docker Model Runner lokal für Bequemlichkeit 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 produktionsbereite 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 Produktionsmaßstab:

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 Observabilität

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

import requests

# Metriken abrufen
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 - Latenzmetrik
• vllm:time_per_output_token - Generierungsgeschwindigkeit

Leistungsoptimierung

GPU-Speicherauslastung optimieren: Beginnen Sie mit --gpu-memory-utilization 0.90 und passen Sie basierend auf beobachtetem Verhalten an. Höhere Werte ermöglichen größere Batches, riskieren aber OOM-Fehler bei Verkehrsspitzen.

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

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 mit AWQ quantisierte Modelle
--quantization gptq # Für mit GPTQ quantisierte Modelle

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

--enable-prefix-caching

Dies cached 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

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 erlaubt
• Senken Sie --max-num-seqs, um die Batch-Größe zu reduzieren
• Verwenden Sie eine quantisierte Modellversion
• Aktivieren Sie Tensor-Parallelität, um auf mehr GPUs zu verteilen

Niedriger Durchsatz

Symptome: Server bearbeitet 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 Sie Spielraum haben
• Prüfen Sie mit htop, ob die CPU der Flaschenhals ist – Erwägen Sie schnellere CPUs
• Überprüfen Sie die GPU-Auslastung mit nvidia-smi – sollte bei 95%+ liegen
• Aktivieren Sie FP16, wenn Sie FP32 verwenden: --dtype float16

Lange Zeit bis zum ersten Token

Symptome: Hohe Latenz, bevor die Generierung beginnt.

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
• Erwägen Sie spekulatives Decoding für unterstützte Modelle
• Optimieren Sie die Tensor-Parallelitätskonfiguration

Modelllade-Fehler

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 zu HuggingFace Hub
• Stellen Sie ausreichenden Festplattenspeicher in ~/.cache/huggingface sicher
• Setzen Sie für gated Modelle die Umgebungsvariable HF_TOKEN
• Versuchen Sie, manuell herunterzuladen mit huggingface-cli download <model>

Erweiterte Funktionen

Spekulatives Decoding

vLLM unterstützt spekulatives Decoding, bei dem ein kleineres Entwurfsmodell Tokens vorschlägt, die ein größeres Zielmodell verifiziert. Dies kann die Generierung um das 1,5- bis 2-fache beschleunigen. Für einen umfassenden Leitfaden zu Methoden des spekulativen Decodings – Entwurfsmodelle, EAGLE-3, P-EAGLE und n-gram – lesen Sie Spekulatives Decoding: 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

Bedienen Sie mehrere LoRA-Adapter auf Basis eines Basismodells, ohne mehrere vollständige 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 an, welcher Adapter pro Anfrage verwendet werden soll:

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

Multi-LoRA-Serving

vLLMs Multi-LoRA-Serving ermöglicht das Hosting von Dutzenden feinabgestimmter Adapter mit minimalem Speicheraufwand. Dies ist ideal für das Bereitstellen 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 SQL-Abfrage"}],
    extra_body={"lora_name": "sql-lora"}
)

Prefix-Caching

Aktivieren Sie automatisches Prefix-Caching, um das erneute Berechnen des KV-Caches für wiederholte Prompt-Präfixe zu vermeiden:

--enable-prefix-caching

Dies ist besonders effektiv für:

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

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

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

Realwelt-Leistungsdaten helfen, die Vorteile von vLLM zu veranschaulichen:

Durchsatzvergleich (Mistral-7B auf A100 GPU):

• vLLM: ~3.500 Tokens/Sekunde mit 64 gleichzeitigen Nutzern
• HuggingFace Transformers: ~250 Tokens/Sekunde mit gleicher Konnektivität
• Ollama: ~1.200 Tokens/Sekunde mit gleicher Konnektivität
• Ergebnis: vLLM bietet 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-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-Serving: P50-Latenz 650ms, P99-Latenz 3.200ms bei 100 req/s
• Ergebnis: vLLM behält konsistente Latenz unter hoher Last

Diese Benchmarks demonstrieren, warum vLLM zum de-facto-Standard für Produktions-LLM-Serving geworden ist, wo Leistung zählt.

Kostenanalyse

Verstehen Sie die Kostenauswirkungen der Wahl von vLLM:

Szenario: 1M Anfragen/Tag bedienen

Mit Standard-Serving:

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

Mit vLLM:

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

Dieser Kostenvorteil wächst mit dem Maßstab. Organisationen, die monatlich Milliarden von Tokens bedienen, sparen Hunderttausende von Dollar, indem sie vLLMs optimiertes Serving anstelle von naiven Implementierungen verwenden.

Sicherheitsüberlegungen

Authentifizierung

vLLM enthält standardmäßig keine Authentifizierung. Implementieren Sie für die Produktion Authentifizierung auf 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 unternehmensgrade Authentifizierung und Rate-Limiting.

Netzwerktrennung

Führen Sie vLLM in privaten Netzen 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 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)

Modellzugriffskontrolle

Kontrollieren Sie für Multi-Tenant-Deployments, welche Nutzer 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

Migrationsleitfaden

Von OpenAI zu vLLM

Die Migration von OpenAI zu self-hosted 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"}]
)

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

Von Ollama zu vLLM

Ollama verwendet ein anderes API-Format. Die grundlegende clientseitige Änderung ist der Wechsel von Ollamas REST-Endpunkt zu vLLMs OpenAI-kompatibler API:

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

Für einen gründlichen Migrationsleitfaden, der Modellauswahl, Chat-Templates, gestaffelte Migration und eine praktische Checkliste abdeckt, lesen Sie Ollama zu vLLM: Wann Sie Ihren lokalen LLM-Server migrieren sollten.

Von HuggingFace Transformers zu vLLM

Direkte Migration der 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("Hallo", 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("Hallo", sampling_params)
result = outputs[0].outputs[0].text

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

Zukunft von vLLM

vLLM entwickelt sich schnell weiter mit spannenden Funktionen auf der Roadmap:

Disaggregated Serving: Trennung von Prefill (Prompt-Verarbeitung) und Decode (Token-Generierung) auf verschiedene GPUs, um die Ressourcennutzung zu optimieren. Prefill ist compute-bound, während Decode memory-bound ist, daher verbessert das Ausführen auf spezialisierter Hardware die Effizienz.

Multi-Node-Inferenz: Verteilung sehr großer Modelle (100B+ Parameter) auf mehrere Maschinen, was das Bedienen 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 beim spekulativen Decoding: Effizientere Entwurfsmodelle und adaptive Spekulationsstrategien, um höhere Beschleunigungen ohne Genauigkeitsverlust zu erreichen.

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

Bessere Modellabdeckung: Erweiterung der Unterstützung für multimodale Modelle (Vision-Language-Modelle), Audio-Modelle 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. Da LLM-Deployments für Produktionssysteme immer kritischer werden, wächst die Rolle von vLLM als Leistungsstandard weiter. Für einen breiteren Vergleich von vLLM mit anderen lokalen und Cloud-LLM-Infrastrukturen, überprüfen Sie unsere LLM-Hosting: Lokale, Self-Hosted- und Cloud-Infrastruktur im Vergleich.

Nützliche Links

Verwandte Artikel auf dieser Site

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

• Ollama Cheatsheet - Komplette Ollama-Befehlsreferenz und Cheatsheet, die Installation, Modellmanagement, API-Nutzung und Best Practices für lokales LLM-Deployment abdeckt. Essenziell für Entwickler, die Ollama neben oder anstelle von vLLM verwenden.

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

• Docker Model Runner vs. Ollama: Welches sollten Sie wählen? - Tiefgehender Vergleich von Docker’s Model Runner und Ollama für lokales LLM-Deployment, unter Analyse von Leistung, GPU-Unterstützung, API-Kompatibilität und Anwendungsfällen. Hilft, das wettbewerbsfähige Umfeld zu verstehen, in dem vLLM operiert.

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

Externe Ressourcen und Dokumentation

• vLLM GitHub-Repository - Offizielles vLLM-Repository mit Quellcode, umfassender Dokumentation, Installationsleitfäden und aktiven Community-Diskussionen. Essenzielle Ressource, um mit neuesten Funktionen auf dem Laufenden zu bleiben und Probleme zu beheben.

• vLLM-Dokumentation - Offizielle Dokumentation, die alle Aspekte von vLLM von der Basisinstallation 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 vLLMs Effizienz antreibt. Essenzielle Lektüre zum Verständnis der technischen Innovationen hinter vLLMs Leistungsvorteilen.

• vLLM-Blog - Offizieller vLLM-Blog mit Release-Ankündigungen, Leistungsbenchmarks, technischen Deep Dives und Community-Case Studies aus Produktionsdeployments.

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

• Ray Serve Dokumentation - Ray Serve Framework-Dokumentation für den Aufbau skalierbarer, verteilter vLLM-Deployments. Ray bietet erweiterte Funktionen wie Autoscaling, Multi-Model-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 den Vergleich und das Verständnis der Inferenzoptimierungslandschaft.

• 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 mit self-hosted vLLM-Endpunkten austauschbar arbeiten müssen.