vLLM Quickstart: Hochleistungs-LLM-Serving

vLLM ist ein hochleistungsfähiger, speichereffizienter Inference- 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-fach höhere Durchsatzrate als herkömmliche Serving-Methoden und ist damit die erste Wahl für produktive LLM-Implementierungen.

Was ist vLLM?

vLLM (virtueller LLM) ist eine Open-Source-Bibliothek für schnelle LLM-Inference und Serving, die schnell zum Branchenstandard für produktive Implementierungen geworden ist. Seit ihrer Veröffentlichung im Jahr 2023 führte sie PagedAttention ein, eine bahnbrechende Speicherverwaltungstechnik, die die Servingeffizienz deutlich verbessert.

Wichtige Funktionen

Hohe Durchsatzleistung: vLLM bietet eine 14- bis 24-fach höhere Durchsatzrate im Vergleich zu HuggingFace Transformers mit derselben Hardware. Diese massive Leistungssteigerung resultiert aus kontinuierlichem 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 Format von OpenAI kompatibel ist. Dies ermöglicht eine nahtlose Migration von OpenAI zu selbstgehosteter Infrastruktur ohne Änderungen am Anwendungscode. Richten Sie einfach Ihren API-Client auf das vLLM-Endpoint aus, und es funktioniert transparent.

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

Kontinuierliches Batching: Im Gegensatz zum statischen Batching, bei dem gewartet wird, bis alle Sequenzen abgeschlossen sind, verwendet vLLM kontinuierliches (rollendes) 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-Parallelität und Pipeline-Parallelität zur Verteilung großer Modelle über mehrere GPUs. Es kann Modelle effizient 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, darunter LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma und vielen anderen. Unterstützt sowohl instruktionstrainierte als auch Basismodelle vom HuggingFace Hub.

Wann vLLM verwenden

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

Produktive API-Dienste: Wenn Sie einen LLM über API für viele gleichzeitige Benutzer bereitstellen müssen, ist vLLM mit seiner hohen Durchsatzrate und effizienten Batching-Funktion die beste Wahl. Unternehmen, die Chatbots, Code-Assistenten oder Content-Generierungsdienste betreiben, profitieren von seiner Fähigkeit, Hunderte von Anfragen pro Sekunde zu verarbeiten.

Hochkonkurrierende Arbeitslasten: Wenn Ihre Anwendung viele gleichzeitige Benutzer hat, die Anfragen stellen, ermöglichen vLLMs kontinuierliches Batching und PagedAttention die Bedienung mehrerer Benutzer mit derselben Hardware im Vergleich zu Alternativen.

Kostenoptimierung: Wenn GPU-Kosten ein Problem darstellen, ermöglicht die überlegene Durchsatzrate von vLLM die Bedienung desselben Verkehrs mit weniger GPUs, was die Infrastrukturkosten direkt reduziert. Die 4-fache Speichereffizienz von PagedAttention ermöglicht auch die Verwendung kleinerer, günstigerer GPU-Instanzen.

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

Wann vLLM NICHT verwenden: Für lokale Entwicklung, Experimente oder Einzelnutzer-Szenarien bieten Tools wie Ollama eine bessere Benutzererfahrung mit einfacherer Einrichtung. Die Komplexität von vLLM lohnt sich erst, wenn Sie seine Leistungsvorteile für produktive Arbeitslasten benötigen.

Wie vLLM installieren

Voraussetzungen

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

• GPU: NVIDIA-GPU mit Rechenfähigkeit 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 16 GB für 7B-Modelle, 24 GB+ für 13B, 40 GB+ 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:

# 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 unterschiedlichen CUDA-Versionen installieren Sie das entsprechende Rad:

# 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 Implementierungsmethode, insbesondere für produktive Zwecke:

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

# Führen Sie vLLM mit GPU-Unterstützung aus
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

Die Flagge --ipc=host ist wichtig für Multi-GPU-Konfigurationen, da sie eine ordnungsgemäße Interprozesskommunikation ermöglicht.

Installation aus dem Quellcode

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

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

vLLM Quickstart Guide

Ausführen Ihres ersten Modells

Starten Sie vLLM mit einem Modell über die Befehlszeilenschnittstelle:

# Laden und bereitstellen von Mistral-7B mit OpenAI-kompatiblem 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 (falls nicht zwischengespeichert) 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": "Erklären Sie, was vLLM in einem Satz ist:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

Mit OpenAI Python Client:

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, was vLLM in einem Satz 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)

Erweitertes Konfigurieren

vLLM bietet zahlreiche Parameter zur Leistungsoptimierung:

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-Genauigkeit
    --max-num-seqs 256                # Maximale Batch-Größe

Wichtige Parameter erklärt:

• --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. Eine Verringerung davon spart Speicher für größere Batches.
• --tensor-parallel-size: Anzahl der GPUs, über 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 einem Batch verarbeitet werden sollen.

vLLM vs Ollama Vergleich

Sowohl vLLM als auch Ollama sind beliebte Optionen für die lokale Bereitstellung von LLMs, aber sie richten sich an unterschiedliche Anwendungsfälle. Das Verständnis, wann man welches Tool verwenden sollte, kann den Erfolg Ihres Projekts erheblich beeinflussen.

Leistung und Durchsatz

vLLM ist für maximalen Durchsatz in Szenarien mit mehreren Benutzern entwickelt. Seine PagedAttention und kontinuierliche Batching ermöglichen das effiziente Servieren von hunderten gleichzeitigen Anfragen. Benchmarks zeigen, dass vLLM einen 14-24x höheren Durchsatz als Standardimplementierungen und 2-4x höher als Ollama bei hoher Konkurrenz erreicht.

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

Einfachheit der Nutzung

Ollama gewinnt deutlich in puncto Einfachheit. Die Installation erfolgt mit einem einzigen Befehl (curl | sh), und das Ausführen von Modellen ist so einfach wie ollama run llama2. Es enthält eine Modellbibliothek mit quantisierten Versionen, die für verschiedene Hardwareprofile optimiert sind. Die Benutzererfahrung ähnelt Docker – ziehen, ausführen und loslegen.

vLLM erfordert mehr Einrichtung: Verwaltung der Python-Umgebung, CUDA-Installation, Verständnis der Serving-Parameter und manuelle Modellangabe. Die Lernkurve ist steiler, aber Sie erhalten eine fein abgestimmte Kontrolle über die Leistungsoptimierung. Diese Komplexität ist für Produktionsbereitstellungen gerechtfertigt, bei denen Sie die maximale Leistung aus Ihrer Hardware herausholen müssen.

API und Integration

vLLM bietet OpenAI-kompatible REST-APIs standardmäßig, wodurch es ein direkter Ersatz für OpenAI’s API in bestehenden Anwendungen ist. Dies ist entscheidend für die Migration von Produktionsdiensten von Cloud-Anbietern zu selbstgehosteten Infrastrukturen ohne Codeänderungen.

Ollama bietet eine einfachere REST-API und eine dedizierte Python/JavaScript-Bibliothek. Obwohl funktionsfähig, ist sie nicht OpenAI-kompatibel, was Codeänderungen erfordert, wenn sie mit Anwendungen integriert wird, die OpenAI’s Format erwarten. Allerdings überbrücken Community-Projekte wie Ollama-OpenAI-Adapter diese Lücke.

Speicherverwaltung

vLLMs PagedAttention-Algorithmus bietet überlegene Speichereffizienz für gleichzeitige Anfragen. Es kann 2-4x mehr gleichzeitige Benutzer mit demselben VRAM bedienen im Vergleich zu naiven Implementierungen. Dies übersetzt sich direkt in Kosteneinsparungen bei Produktionsbereitstellungen.

Ollama verwendet einfachere Speicherverwaltung, die für Einzelbenutzerszenarien geeignet ist. Es verwaltet automatisch das Laden/Entladen von Modellen basierend auf der Aktivität, was für die Entwicklung praktisch ist, aber nicht optimal für Produktionsbereitstellungen mit hoher Konkurrenz.

Multi-GPU-Unterstützung

vLLM glänzt mit nativer Tensor-Parallelität und Pipeline-Parallelität, die Modelle effizient über 2-8+ GPUs verteilt. Dies ist essenziell für das Servieren großer Modelle wie 70B-Parameter-LLMs, die nicht in eine einzelne GPU passen.

Ollama hat derzeit 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.

Anwendungsfall-Empfehlungen

Wählen Sie vLLM, wenn:

• Sie Produktions-APIs mit vielen gleichzeitigen Benutzern bereitstellen
• Sie die Kosten pro Anfrage in Cloud-Bereitstellungen optimieren
• Sie in Kubernetes oder Container-Orchestrierungsplattformen laufen
• Sie OpenAI-API-Kompatibilität für bestehende Anwendungen benötigen
• Sie große Modelle mit Multi-GPU-Unterstützung bereitstellen
• Leistung und Durchsatz kritische Anforderungen sind

Wählen Sie Ollama, wenn:

• Lokale Entwicklung und Experimente
• Einzelbenutzer-Interaktive Nutzung (persönliche Assistenten, Chatbots)
• Schnelle Prototypenerstellung und Modellbewertung
• Lernen über LLMs ohne Infrastrukturexplizit
• Ausführung auf persönlichen Arbeitsstationen oder Laptops
• Einfachheit und Benutzerfreundlichkeit Prioritäten sind

Viele Teams nutzen beide: Ollama für Entwicklung und Experimente, dann vLLM für Produktionsbereitstellungen. Diese Kombination bietet Entwicklerproduktivität, während die Produktionsleistung aufrechterhalten wird.

vLLM vs Docker Model Runner

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

Architekturphilosophie

Docker Model Runner strebt danach, der “Docker für KI” zu sein – eine einfache, standardisierte Möglichkeit, KI-Modelle lokal mit derselben Leichtigkeit wie das Ausführen von Containern zu betreiben. Es abstrahiert Komplexität und bietet eine konsistente Schnittstelle für verschiedene Modelle und Frameworks.

vLLM ist eine spezialisierte Inference-Engine, die sich ausschließlich auf die LLM-Bereitstellung mit maximaler Leistung konzentriert. Es ist ein Low-Level-Tool, das Sie mit Docker containerisieren, anstatt eine vollständige Plattform.

Einrichtung und Einstieg

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

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

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

vLLM erfordert mehr initiale Einrichtung (Python, CUDA, Abhängigkeiten) oder die Verwendung von vorgefertigten 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 Mehrbenutzerszenarien dank PagedAttention und kontinuierlichem Batching. Für Produktions-API-Dienste, die Hunderte von Anfragen pro Sekunde verarbeiten, bieten vLLMs Optimierungen 2-5x 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 Arbeitslasten, implementiert aber nicht die fortgeschrittenen Optimierungen, die vLLM bei Skalierung auszeichnen.

Modellunterstützung

Docker Model Runner bietet eine kuratierte Modellbibliothek mit Ein-Kommando-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-Arbeitslasten macht.

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

Produktionsbereitstellung

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

Docker Model Runner ist neuer und positioniert sich mehr für Entwicklungs- und lokale Test-Szenarien. Obwohl es Produktionsverkehr bedienen könnte, fehlen ihm die bewährte Erfolgsbilanz und Leistungsoptimierungen, die Produktionsbereitstellungen erfordern.

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, aber weniger spezialisierte LLM-Serving-Funktionen.

Wann man jedes verwenden sollte

Verwenden Sie vLLM für:

• Produktions-LLM-API-Dienste
• Hochdurchsatz-Mehrbenutzer-Bereitstellungen
• Kostenempfindliche Cloud-Bereitstellungen mit maximaler Effizienz
• 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ührung verschiedener KI-Modelltypen (nicht nur LLMs)
• Teams, die stark in das Docker-Ökosystem investiert sind
• Schnelle Experimente ohne Infrastruktureinrichtung
• Lern- und Bildungszwecke

Hybridansatz: Viele Teams entwickeln mit Docker Model Runner lokal für Bequemlichkeit und bereiten dann mit vLLM in der Produktion für Leistung auf. Die Docker Model Runner-Images können auch verwendet werden, um vLLM-Container auszuführen und beide Ansätze zu kombinieren.

Produktionsbereitstellung - Best Practices

Docker-Bereitstellung

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

Bereitstellen von vLLM auf Kubernetes für Produktionsskalierung:

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 Metriken zur Überwachung:

• vllm:num_requests_running - Aktive Anfragen
• vllm:gpu_cache_usage_perc - KV-Cache-Nutzung
• vllm:time_to_first_token - Latenzmetrik
• vllm:time_per_output_token - Generationsgeschwindigkeit

Leistungsoptimierung

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

Anpassung der maximalen Sequenzlänge: Wenn Ihr Anwendungsfall nicht die volle Kontextlänge benötigt, reduzieren Sie --max-model-len. Dies befreit Speicher für größere Batches. Beispielsweise, wenn Sie nur 4K Kontext benötigen, setzen Sie --max-model-len 4096 statt die maximale Modelllänge (oft 8K-32K) zu verwenden.

Wahl der geeigneten Quantisierung: Für Modelle, die dies unterstützen, verwenden Sie quantisierte Versionen (8-Bit, 4-Bit), um den Speicher zu reduzieren und die Durchsatzrate zu erhöhen:

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

Aktivierung des Präfix-Cachings: Für Anwendungen mit wiederholten Prompts (wie Chatbots mit Systemnachrichten) aktivieren Sie das Präfix-Caching:

--enable-prefix-caching

Dieser Cache speichert die KV-Werte für häufige Präfixe und reduziert die Berechnung für Anfragen mit demselben Prompt-Präfix.

Fehlerbehebung bei häufigen Problemen

Speicherfehler (Out of Memory)

Symptome: Server stürzt mit CUDA-Speicherfehlern 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-Parallelität, um auf mehr GPUs zu verteilen

Geringe Durchsatzrate

Symptome: Der 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 Sie Spielraum haben
• Überprüfen Sie mit htop, ob die CPU eine Flasche ist – überlegen Sie sich schnellere CPUs
• Verifizieren Sie die GPU-Auslastung mit nvidia-smi – sollte 95%+ betragen
• Aktivieren Sie FP16, wenn FP32 verwendet wird: --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 Präfix-Caching für wiederholte Prompts
• Reduzieren Sie --max-num-seqs, um Latenz gegenüber Durchsatz zu priorisieren
• Überlegen Sie sich spekulatives Decodieren für unterstützte Modelle
• Optimieren Sie die Tensor-Parallelitätskonfiguration

Modellladefehler

Symptome: Server startet nicht, kann Modell nicht laden.

Lösungen:

• Überprüfen Sie, ob der Modellname exakt dem HuggingFace-Format entspricht
• Überprüfen Sie die Netzwerkverbindung zum HuggingFace Hub
• Stellen Sie sicher, dass ausreichend Festplattenspeicher in ~/.cache/huggingface vorhanden ist
• Für gesperrte Modelle die Umgebungsvariable HF_TOKEN setzen
• Versuchen Sie, manuell mit huggingface-cli download <model> herunterzuladen

Erweiterte Funktionen

Spekulatives Decodieren

vLLM unterstützt spekulatives Decodieren, bei dem ein kleineres Entwurfsmodell Tokens vorschlägt, die ein größeres Zielmodell überprüft. Dies kann die Generierung um das 1,5- bis 2-fache 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

Bieten Sie mehrere LoRA-Adapter auf Basis eines Grundmodells an, 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

Dann legen Sie fest, 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 mir alle Benutzer, die in diesem Monat erstellt wurden"
)

Multi-LoRA-Bereitstellung

vLLMs Multi-LoRA-Bereitstellung ermöglicht das Hosting von Dutzenden feinabgestimmter Adapter mit minimalem Speicherüberhead. Dies ist ideal für das Hosting von kunden- oder aufgabenspezifischen 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"}
)

Präfix-Caching

Aktivieren Sie das automatische Präfix-Caching, um die KV-Cache-Berechnung 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-Lernprompts, die über Anfragen hinweg wiederholt werden

Präfix-Caching kann die Zeit bis zum ersten Token um 50-80% für Anfragen mit gemeinsamen Prompt-Präfixen 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 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

Echtwelt-Leistungsdaten veranschaulichen die Vorteile von vLLM:

Durchsatzvergleich (Mistral-7B auf A100-GPU):

• vLLM: ~3.500 Tokens/Sekunde mit 64 gleichzeitigen Benutzern
• HuggingFace Transformers: ~250 Tokens/Sekunde mit derselben Gleichzeitigkeit
• Ollama: ~1.200 Tokens/Sekunde mit derselben Gleichzeitigkeit
• Ergebnis: vLLM bietet eine 14-fache Verbesserung gegenüber grundlegenden Implementierungen

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 Anfragen/Sekunde
• Standard-Serving: P50-Latenz 650ms, P99-Latenz 3.200ms bei 100 Anfragen/Sekunde
• Ergebnis: vLLM hält eine konsistente Latenz unter hoher Last aufrecht

Diese Benchmarks demonstrieren, warum vLLM zum de facto-Standard für die Produktionsbereitstellung von LLMs geworden ist, wo Leistung entscheidend ist.

Kostenanalyse

Verständnis der Kostenimplikationen bei der Wahl von vLLM:

Szenario: Bereitstellung von 1M Anfragen/Tag

Mit Standard-Serving:

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

Mit vLLM:

• Benötigt: 2x A100-GPUs (80GB)
• AWS-Kosten: ~$8/Stunde × 24 × 30 = $5.760/Monat
• Kosten pro 1M 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 vLLMs optimierte Bereitstellung anstelle von naiven Implementierungen verwenden.

Sicherheitsüberlegungen

Authentifizierung

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

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

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-Deployments steuern Sie, welche Benutzer auf welche Modelle zugreifen können:

ERLAUBTE_MODELLE = {
    "benutzer_stufe_1": ["mistralai/Mistral-7B-Instruct-v0.2"],
    "benutzer_stufe_2": ["mistralai/Mistral-7B-Instruct-v0.2", "meta-llama/Llama-2-13b-chat-hf"],
    "admin": ["*"]  # Alle Modelle
}

def ueberpruefe_modellzugriff(benutzer_stufe: str, modell: str) -> bool:
    erlaubt = ERLAUBTE_MODELLE.get(benutzer_stufe, [])
    return "*" in erlaubt or modell in erlaubt

Migrationsleitfaden

Von OpenAI zu vLLM

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

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"  # Wenn 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 den model-Namen. Alle anderen Codes bleiben 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 Ihrem gesamten Code aktualisieren, aber die OpenAI-Client-Bibliotheken bieten bessere Fehlerbehandlung und Funktionen.

Von HuggingFace Transformers zu vLLM

Direkte Python-Nutzungsmigration:

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

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

Zukunft von vLLM

vLLM entwickelt sich weiterhin schnell mit spannenden Funktionen in der Roadmap:

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

Multi-Node-Inferenz: Verteilung sehr großer Modelle (100B+ Parameter) über mehrere Maschinen, Ermöglichung des Servings von Modellen, die für Single-Node-Setups zu groß sind.

Verbesserte 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 bei der spekulativen Decodierung: Effizientere Entwurfsmodelle und adaptive Spekulationsstrategien zur Erzielung höherer Geschwindigkeitssteigerungen ohne Genauigkeitsverlust.

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

Bessere Modellabdeckung: Erweiterung der Unterstützung auf multimodale Modelle (Visions-Sprachmodelle), Audiomodelle und spezialisierte Architekturen, wie sie entstehen.

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

Nützliche Links

Verwandte Artikel auf dieser Seite

• Lokale LLM-Hosting: Kompletter Leitfaden 2025 - Ollama, vLLM, LocalAI, Jan, LM Studio & mehr - Umfassender Vergleich von 12+ Tools zum lokalen LLM-Hosting, einschließlich detaillierter vLLM-Analyse neben Ollama, LocalAI, Jan, LM Studio und anderen. Abdeckung von API-Reife, Tool-Calling-Unterstützung, GGUF-Kompatibilität und Leistungsbenchmarks zur Auswahl der richtigen Lösung.

• Ollama Cheatsheet - Vollständiger Ollama-Befehlsreferenz- und Cheatsheet, der Installation, Modellverwaltung, API-Nutzung und Best Practices für die lokale LLM-Implementierung abdeckt. Wichtig für Entwickler, die Ollama neben oder anstelle von vLLM verwenden.

• Docker Model Runner vs Ollama: Welches wählen? - Tiefgehender Vergleich von Docks Model Runner und Ollama für lokale LLM-Implementierung, 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 - Praktischer Docker Model Runner Cheatsheet mit Befehlen und Beispielen für die KI-Modellbereitstellung. Nützlich für Teams, die Docks Ansatz mit den spezialisierten LLM-Serving-Fähigkeiten von vLLM vergleichen.

Externe Ressourcen und Dokumentation

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

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

• PagedAttention-Paper - Akademisches Paper, das den PagedAttention-Algorithmus einführen, der die Effizienz von vLLM antreibt. Wichtige Lektüre zum Verständnis der technischen Innovationen hinter den Leistungsvorteilen von vLLM.

• vLLM-Blog - Offizieller vLLM-Blog mit Veröffentlichungsankündigungen, Leistungsbenchmarks, technischen Deep Dives 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 zum Aufbau skalierbarer, verteilter vLLM-Bereitstellungen. Ray bietet erweiterte Funktionen wie Autoskaling, Multi-Model-Serving und Ressourcenmanagement für Produktionssysteme.

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

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