vLLM Quickstart: Hochleistungsfähige LLM-Verarbeitung – 2026

vLLM ist ein leistungsstarkes, speicher-effizientes Inferenz- und Servicemodul für Large Language Models (LLMs), das vom Sky Computing Lab der UC Berkeley entwickelt wurde.

Mit seinem revolutionären PagedAttention-Algorithmus erreicht vLLM eine Durchsatzleistung, die 14-24-mal höher ist als bei traditionellen Servicemethoden, wodurch es zur ersten Wahl für Produktions-LLM-Bereitstellungen wird. Um zu sehen, wie vLLM im Vergleich zu Ollama, Docker Model Runner, LocalAI und Cloud-Anbietern passt – einschließlich Kosten- und Infrastrukturkompromisse – siehe LLM-Hosting: Lokal, Selbstgehostet & Cloud-Infrastruktur im Vergleich.

Was ist vLLM?

vLLM (virtuelles LLM) ist eine Open-Source-Bibliothek für schnelle LLM-Inferenz und -Bereitstellung, die rasch zur Industriestandard für Produktionsbereitstellungen geworden ist. Veröffentlicht im Jahr 2023, führte es PagedAttention ein, eine bahnbrechende Speicherverwaltungstechnik, die die Effizienz der Bereitstellung erheblich verbessert.

Schlüsselmerkmale

Hohe Durchsatzleistung: vLLM liefert eine Durchsatzleistung, die 14-24-mal höher ist als bei HuggingFace Transformers mit der gleichen Hardware. Dieser massive Leistungsverlust kommt durch kontinuierliche Batching, optimierte CUDA-Kerne und den PagedAttention-Algorithmus zustande, 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 Änderung des Anwendungscode. Einfach Ihren API-Client auf den Endpunkt von vLLM richten und es funktioniert transparent.

PagedAttention-Algorithmus: Der Kern der Leistung von vLLM ist PagedAttention, der das Konzept virtueller Speicherseiten auf Aufmerksamkeitsmechanismen anwendet. Anstatt kontinuierliche Speicherblöcke für KV-Caches (was zu Fragmentierung führt) zu allozieren, teilt PagedAttention den Speicher in festgelegte Blöcke, die auf Anfrage alloziert werden können. Dies reduziert den Speicherverbrauch um bis zu 4-fach und ermöglicht viel größere Batchgrößen.

Kontinuierliches Batching: Im Gegensatz zum statischen Batching, bei dem Sie auf das Abschließen aller Sequenzen warten, verwendet vLLM kontinuierliches (rollendes) Batching. Sobald eine Sequenz abgeschlossen ist, kann eine neue hinzugefügt werden. Dies maximiert die GPU-Nutzung und minimiert die Latenz bei eingehenden Anfragen.

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

Weite Modellunterstützung: Kompatibel mit beliebten Modellarchitekturen wie LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma und vielen anderen. Unterstützt sowohl instruction-tuned als auch Basismodelle von HuggingFace Hub.

Wann vLLM verwenden

vLLM excels in bestimmten Szenarien, in denen seine Stärken glänzen:

Produktions-API-Dienste: Wenn Sie ein LLM über API vielen gleichzeitigen Nutzern bereitstellen müssen, ist vLLMs hohe Durchsatzleistung und effizientes Batching die beste Wahl. Unternehmen, die Chatbots, Code-Assistenten oder Content-Generationsdienste betreiben, profitieren von seiner Fähigkeit, Hunderte von Anfragen pro Sekunde zu verarbeiten.

Hochkonkurrenz-Arbeitslasten: Wenn Ihre Anwendung viele gleichzeitige Nutzer mit Anfragen hat, ermöglichen vLLMs kontinuierliches Batching und PagedAttention, mit der gleichen Hardware mehr Nutzer zu bedienen als bei Alternativen.

Kostenoptimierung: Wenn GPU-Kosten ein Problem sind, bedeutet vLLMs überlegene Durchsatzleistung, dass Sie den gleichen Datenverkehr mit weniger GPUs bedienen können, was die Infrastrukturkosten direkt reduziert. Die 4-fache Speichereffizienz von PagedAttention ermöglicht auch die Verwendung kleinerer, billigerer GPU-Instanzen.

Kubernetes-Bereitstellungen: vLLMs stateless Design und containerfreundliche Architektur machen es ideal für Kubernetes-Cluster. Seine konsistente Leistung unter Last und einfache Ressourcenverwaltung integrieren sich gut mit cloudbasierten Infrastrukturen.

Wann vLLM nicht verwenden: Für lokale Entwicklung, Experimente oder Einzelbenutzerszenarien bieten Tools wie Ollama eine bessere Benutzererfahrung mit einfacherer Einrichtung. Die Komplexität von vLLM ist gerechtfertigt, wenn Sie seine Leistungsadvantagen für Produktionsarbeitslasten benötigen.

Wie man vLLM installiert

Voraussetzungen

Bevor Sie vLLM installieren, stellen Sie 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 Series)
• 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 ü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 Bereitstellungsmethode, insbesondere für Produktionsumgebungen:

# Ziehen Sie das offizielle vLLM-Image
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

Der --ipc=host-Flag ist für Multi-GPU-Setup wichtig, da es die ordnungsgemäße Interprozesskommunikation ermöglicht.

Aus der Quelle bauen

Für die neuesten Funktionen oder benutzerdefinierte Änderungen bauen Sie aus der Quelle:

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

Schnellstartleitfaden für vLLM

Ihr erstes Modell starten

Starten Sie vLLM mit einem Modell über die Befehlszeilenschnittstelle:

# Laden Sie Mistral-7B herunter und stellen Sie es mit einer OpenAI-kompatiblen API bereit
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 (wenn es nicht im Cache ist) und startet den Server. Sie werden eine Ausgabe sehen, die anzeigt, dass der Server bereit ist:

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

API-Anfragen stellen

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

Mit curl:

curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "mistralai/Mistral-7B-Instruct-v0.2",
        "prompt": "Erklären Sie, was vLLM ist, in einem Satz:",
        "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 benötigt standardmäßig keine Authentifizierung
)

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

print(response.choices[0].text)

Chat Completion API:

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

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

Erweiterte Konfiguration

vLLM bietet zahlreiche Parameter, um die Leistung zu optimieren:

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

Erklärung der Schlüsselparameter:

• --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 Reduzierung spart Speicher für größere Batches.
• --tensor-parallel-size: Anzahl der GPUs, über die das Modell verteilt wird.
• --dtype: Datentyp für Gewichte (float16, bfloat16 oder float32). FP16 ist normalerweise optimal.
• --max-num-seqs: Maximale Anzahl der Sequenzen, die in einem Batch verarbeitet werden sollen.

Vergleich zwischen vLLM und Ollama

Sowohl vLLM als auch Ollama sind beliebte Optionen für lokales LLM-Hosting, zielen aber auf unterschiedliche Anwendungsfälle ab. Das Verständnis, wann jedes Tool verwendet werden sollte, kann den Erfolg Ihres Projekts erheblich beeinflussen.

Leistung und Durchsatz

vLLM ist für maximale Durchsatzleistung in mehreren Nutzerszenarien konzipiert. Sein PagedAttention und kontinuierliches Batching ermöglichen die effiziente Bereitstellung von hunderten gleichzeitigen Anfragen. Benchmarks zeigen, dass vLLM eine Durchsatzleistung von 14-24-mal höher erzielt als Standardimplementierungen und 2-4-mal höher als Ollama unter hoher Konkurrenz.

Ollama optimiert für Einzelnutzer-interaktive Nutzung mit Fokus auf niedrige Latenz für individuelle Anfragen. Obwohl es die Multi-Nutzer-Durchsatzleistung von vLLM nicht erreicht, bietet es hervorragende Leistung für Entwicklung und persönliche Nutzung mit schnelleren Kaltstartzeiten und niedrigerer Ressourennutzung in der Leerlaufzeit.

Einfachheit der Verwendung

Ollama gewinnt klar bei 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 gleicht Docker – ziehen Sie, führen Sie aus und fahren Sie fort.

vLLM erfordert mehr Einrichtung: Umgebung für Python-Management, CUDA-Installation, Verständnis von Serviceparametern und manuelle Modellspezifikation. Die Lernkurve ist steiler, aber Sie gewinnen eine feine Kontrolle über Leistungsoptimierungen. Diese Komplexität ist gerechtfertigt, wenn Sie maximale Leistung aus der Hardware bei Produktionsbereitstellungen benötigen.

API und Integration

vLLM bietet REST-APIs, die mit OpenAI kompatibel sind, standardmäßig an. Dies macht es zu einem Drop-in-Ersatz für OpenAI-API in bestehenden Anwendungen. Dies ist entscheidend, um Produktionsdienste von Cloud-Anbietern in selbstgehostete Infrastrukturen zu migrieren, ohne Codeänderungen vorzunehmen.

Ollama bietet eine einfachere REST-API und eine dedizierte Python/JavaScript-Bibliothek. Obwohl funktional, ist sie nicht mit OpenAI kompatibel, was Codeänderungen erfordert, wenn sie mit Anwendungen integriert werden, die das OpenAI-Format erwarten. Allerdings schließen Communityprojekte wie Ollama-OpenAI-Adapter diese Lücke.

Speicherverwaltung

vLLMs PagedAttention-Algorithmus bietet eine überlegene Speichereffizienz für gleichzeitige Anfragen. Es kann 2-4-mal mehr gleichzeitige Nutzer mit dem gleichen VRAM im Vergleich zu naiven Implementierungen bedienen. Dies übersetzt sich direkt in Kostenersparnisse bei Produktionsbereitstellungen.

Ollama verwendet eine einfachere Speicherverwaltung, die für Einzelnutzerszenarien geeignet ist. Es verwaltet automatisch das Laden/Entladen von Modellen basierend auf Aktivität, was für Entwicklung bequem ist, aber nicht optimal für hochkonkurrenz Produktionsverwendung ist.

Multi-GPU-Unterstützung

vLLM excels mit nativem Tensor-Parallelismus und Pipeline-Parallelismus, die Modelle effizient über 2-8+ GPUs verteilen. Dies ist entscheidend für die Bereitstellung großer Modelle wie 70B-Parameter-LLMs, die nicht in eine einzelne GPU passen.

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

Empfehlungen für Anwendungsfälle

Wählen Sie vLLM, wenn:

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

Wählen Sie Ollama, wenn:

• Sie lokale Entwicklung und Experimente durchführen
• Sie Einzelnutzer-interaktive Nutzung (persönliche Assistenten, Chatbots) haben
• Sie schnelle Prototypen und Modellbewertung durchführen
• Sie LLMs ohne Infrastrukturkomplexität lernen
• Sie auf persönlichen Workstations oder Laptops laufen
• Einfachheit und Benutzerfreundlichkeit Prioritäten sind

Viele Teams verwenden beide: Ollama für Entwicklung und Experimente, dann vLLM für Produktionsbereitstellung. Dieses Kombination bietet Entwicklerproduktivität, während Produktionsleistung erhalten bleibt.

Vergleich zwischen vLLM und Docker Model Runner

Docker hat kürzlich Model Runner (früher GenAI Stack) als offizielle Lösung für lokale AI-Modellbereitstellung eingeführt. Wie sieht der Vergleich mit vLLM aus?

Architekturphilosophie

Docker Model Runner strebt danach, das “Docker für AI” zu werden – eine einfache, standardisierte Methode, um AI-Modelle lokal mit der gleichen Einfachheit zu laufen wie Container. Es abstrahiert Komplexität und bietet eine konsistente Schnittstelle über verschiedene Modelle und Frameworks hinweg.

vLLM ist ein spezialisierter Inferenzmotor, der sich ausschließlich auf LLM-Bereitstellung mit maximaler Leistung konzentriert. Es ist ein niedrigeres Niveau-Tool, das Sie mit Docker containerisieren, anstatt eine vollständige Plattform zu sein.

Einrichtung und Start

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

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

Diese Ähnlichkeit mit der Docker-Image-Workflow-Methode macht es für Entwickler, die bereits Container verwenden, sofort vertraut.

vLLM erfordert mehr Anfangssetup (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 eine überlegene Durchsatzleistung für mehrere Nutzerszenarien aufgrund von PagedAttention und kontinuierlichem Batching. Für Produktions-API-Dienste, die hunderte von Anfragen pro Sekunde verarbeiten, liefern vLLMs Optimierungen eine 2-5-mal bessere Durchsatzleistung als generische Servicemethoden.

Docker Model Runner konzentriert sich auf Einfachheit anstelle von maximaler Leistung. Es ist für lokale Entwicklung, Testen und moderate Workloads geeignet, aber implementiert keine fortgeschrittenen Optimierungen, die vLLM bei Skalierung hervorragend macht.

Modellunterstützung

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

vLLM spezialisiert sich auf LLM-Inferenz mit tiefer Unterstützung für transformer-basierte Sprachmodelle. Es unterstützt jedes HuggingFace-kompatible LLM, aber nicht auf andere AI-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 Token bereitstellen. Seine Leistungsmerkmale und Stabilität unter hoher Last machen es zum Standard für Produktions-LLM-Bereitstellung.

Docker Model Runner ist neuer und positioniert sich mehr für Entwicklung und lokale Testumgebungen. Obwohl es Produktionsverkehr bedienen könnte, fehlt ihm die bewährte Erfahrung und Leistungsoptimierungen, die Produktionsbereitstellungen erfordern.

Integrationsekosystem

vLLM integriert sich mit Produktionsinfrastrukturtools: Kubernetes-Operatoren, Prometheus-Metriken, Ray für verteilte Servicemethoden und umfangreiche OpenAI-API-Kompatibilität für vorhandene Anwendungen.

Docker Model Runner integriert sich natürlich mit Docks Ecosystem und Docker Desktop. Für Teams, die bereits auf Docker standardisiert sind, bietet dies eine kohärente Erfahrung, aber weniger spezialisierte LLM-Bereitstellungsfunktionen.

Wann jedes verwenden

Verwenden Sie vLLM, wenn:

• Sie Produktions-LLM-API-Dienste bereitstellen
• Sie hohe Durchsatzleistung, mehrere Nutzerbereitstellungen benötigen
• Sie kostensensitive Cloud-Bereitstellungen benötigen, die maximale Effizienz erfordern
• Sie in Kubernetes und cloudbasierte Umgebungen laufen
• Sie bewährte Skalierbarkeit und Leistung benötigen

Verwenden Sie Docker Model Runner, wenn:

• Sie lokale Entwicklung und Testen durchführen
• Sie verschiedene AI-Modelle (nicht nur LLMs) ausführen
• Sie Teams sind, die stark auf Docker-Ökosystem investiert sind
• Sie schnelle Experimente ohne Infrastruktursetup durchführen
• Sie Lern- und Bildungszwecke haben

Hybride Methode: Viele Teams entwickeln mit Docker Model Runner lokal für Bequemlichkeit, dann deployen mit vLLM in Produktion für Leistung. Die Docker Model Runner-Images können auch verwendet werden, um vLLM-Container zu laufen, was beide Ansätze kombiniert.

Best Practices für Produktionsbereitstellung

Docker-Bereitstellung

Erstellen Sie eine produktionstaugliche 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 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 Beobachtbarkeit

vLLM bietet Prometheus-Metriken für Überwachung:

import requests

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

Wichtige Metriken, die Sie überwachen sollten:

• 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 - Generierungsgeschwindigkeit

Leistungsfeinabstimmung

Optimieren Sie die GPU-Speichernutzung: Starten Sie mit --gpu-memory-utilization 0.90 und passen Sie basierend auf beobachtetem Verhalten an. Höhere Werte erlauben größere Batches, aber riskieren OOM-Fehler während Spitzenlasten.

Anpassen 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. Wenn Sie beispielsweise nur 4K Kontext benötigen, setzen Sie --max-model-len 4096 anstelle der Modellmaximalen (oft 8K-32K).

Wählen Sie geeignete Quantisierung: Für Modelle, die dies unterstützen, verwenden Sie quantisierte Versionen (8-bit, 4-bit), um Speicher zu sparen und Durchsatz zu erhöhen:

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

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

--enable-prefix-caching

Dies speichert die KV-Werte für gängige Präfixe, was die Berechnung für Anfragen mit demselben Prompt-Präfix reduziert.

Problembehandlung bei häufigen Problemen

Speicherfehler

Symptome: Der 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
• Verringern Sie --max-num-seqs, um die Batchgröße zu reduzieren
• Verwenden Sie eine quantisierte Modellversion
• Aktivieren Sie Tensor-Parallelismus, um über mehr GPUs zu verteilen

Niedriger Durchsatz

Symptome: Der Server verarbeitet weniger Anfragen als erwartet.

Lösungen:

• Erhöhen Sie --max-num-seqs, um größere Batches zuzulassen
• Erhöhen Sie --gpu-memory-utilization, wenn Sie Spielraum haben
• Prüfen Sie, ob der CPU-Bottleneck mit htop – betrachten Sie schnellere CPUs
• Prüfen Sie die GPU-Nutzung mit nvidia-smi – sollte 95%+ betragen
• Aktivieren Sie FP16, wenn Sie FP32 verwenden: --dtype float16

Langsame Zeit bis zum ersten Token

Symptome: Hohe Latenz vor dem Start 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
• Betrachten Sie spekulative Decodierung für unterstützte Modelle
• Optimieren Sie die Tensor-Parallelismus-Konfiguration

Modell-Ladefehler

Symptome: Der Server kann nicht gestartet werden, das Modell kann nicht geladen werden.

Lösungen:

• Prüfen Sie, ob der Modellname exakt dem HuggingFace-Format entspricht
• Prüfen Sie die Netzwerkverbindung zu HuggingFace Hub
• Stellen Sie sicher, dass genügend Festplattenspeicher in ~/.cache/huggingface vorhanden ist
• Für eingeschränkte Modelle, setzen Sie die Umgebungsvariable HF_TOKEN
• Versuchen Sie manuell mit huggingface-cli download <model> herunterzuladen

Erweiterte Funktionen

Spekulative Decodierung

vLLM unterstützt spekulative Decodierung, bei der ein kleinerer Entwurfmodell Tokens vorschlägt, die ein größeres Zielmodell überprüft. Dies kann die Generierung um 1,5-2-mal beschleunigen:

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

LoRA-Adapter

Mehrere LoRA-Adapter können über ein Basismodell ohne das Laden mehrerer vollständiger Modelle bereitgestellt werden:

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 geben Sie an, welchen Adapter Sie pro Anfrage verwenden:

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

Multi-LoRA-Bereitstellung

vLLMs Multi-LoRA-Bereitstellung ermöglicht das Hosting von Dutzenden feingestimmten Adaptern mit minimalem Speicheroverhead. Dies ist ideal für das Hosting von kundenspezifischen oder aufgabenbezogenen 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 automatisches Präfix-Caching, um die Neuberechnung von KV-Cache 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 mehrere Anfragen wiederholt werden

Präfix-Caching kann die Zeit bis zum ersten Token um 50-80 % reduzieren für Anfragen mit gemeinsamen Prompt-Präfixen.

Integrationbeispiele

LangChain-Integration

from langchain.llms import VLLMOpenAI

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

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

LlamaIndex-Integration

from llama_index.llms import VLLMServer

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

response = llm.complete("Was ist vLLM?")
print(response)

FastAPI-Anwendung

from fastapi import FastAPI
from openai import AsyncOpenAI

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

@app.post("/generate")
async def generate(prompt: str):
    response = await client.completions.create(
        model="mistralai/Mistral-7B-Instruct-v0.2",
        prompt=prompt,
        max_tokens=200
    )
    return {"result": response.choices[0].text}

Leistungsbenchmarks

Reale Weltleistungsdaten helfen, die Vorteile von vLLM zu veranschaulichen:

Durchsatzvergleich (Mistral-7B auf A100 GPU):

• vLLM: ~3.500 Token/sekunde mit 64 gleichzeitigen Nutzern
• HuggingFace Transformers: ~250 Token/sekunde mit gleicher Konkurrenz
• Ollama: ~1.200 Token/sekunde mit gleicher Konkurrenz
• Ergebnis: vLLM bietet 14-fache Verbesserung gegenüber grundlegenden Implementierungen

Speichereffizienz (LLaMA-2-13B):

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

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

• vLLM: P50-Latenz 180 ms, P99-Latenz 420 ms bei 100 Anfragen/sekunde
• Standardbereitstellung: P50-Latenz 650 ms, P99-Latenz 3.200 ms bei 100 Anfragen/sekunde
• Ergebnis: vLLM hält eine konsistente Latenz unter hohem Last

Diese Benchmarks zeigen, warum vLLM zur Standardlösung für Produktions-LLM-Bereitstellung geworden ist, wo Leistung zählt.

Kostenanalyse

Verständnis der Kostenimplikationen von vLLM:

Szenario: 1M Anfragen/Tag bedienen

Mit Standardbereitstellung:

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

Mit vLLM:

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

Dieser Kostenvorteil wächst mit der Skalierung. Organisationen, die Milliarden von Token pro Monat bedienen, sparen hunderttausende von Dollar, indem sie vLLMs optimierte Bereitstellung anstelle von naiven Implementierungen verwenden.

Sicherheitsaspekte

Authentifizierung

vLLM enthält standardmäßig keine Authentifizierung. Für Produktionsumgebungen implementieren Sie die Authentifizierung auf Ebene des Umkehrproxys:

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

Netzwerkisolierung

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

# Kubernetes-Netzwerkrichtlinienbeispiel
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 Sekundenfenster
    
    if requests > 60:  # 60 Anfragen pro Minute
        raise HTTPException(status_code=429, detail="Rate limit exceeded")
    
    return await call_next(request)

Modellzugriffssteuerung

Für Multi-Tenant-Bereitstellungen, steuern Sie, welche Nutzer 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 selbstgehostetem vLLM ist dank der 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: base_url und model-Name aktualisieren. Der restliche Code bleibt identisch.

Von Ollama zu vLLM

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

Ollama API:

import requests

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

vLLM-Äquivalent:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
response = client.completions.create(
    model="meta-llama/Llama-2-7b-chat-hf",
    prompt="Warum ist der Himmel blau?"
)

Sie müssen die API-Aufrufe in Ihrem Codebase aktualisieren, aber die OpenAI-Clientbibliotheken 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

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

Zukunft von vLLM

vLLM weiterentwickelt sich mit spannenden Features auf dem Roadmap:

Zerlegte Bereitstellung: Trennen Sie Prefill (Promptverarbeitung) und Decode (Tokengenerierung) auf verschiedene GPUs, um die Ressourennutzung zu optimieren. Prefill ist rechenintensiv, während Decode speicherintensiv ist, daher verbessert das Laufen auf spezialisierten Hardware die Effizienz.

Multi-Node-Inferenz: Sehr große Modelle (100B+ Parameter) über mehrere Maschinen verteilen, um Modelle zu bedienen, die zu groß für Einzelmaschinen-Setup 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.

Verbesserte Spekulative Decodierung: Effizientere Entwurfmodelle und adaptive Spekulationsstrategien, um höhere Geschwindigkeitsverbesserungen ohne Genauigkeitsverlust zu erzielen.

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

Bessere Modellabdeckung: Erweiterung der Unterstützung auf Multimodellmodelle (Bild-Text-Modelle), Audiomodelle und spezialisierte Architekturen, sobald sie erscheinen.

Das vLLM-Projekt unterhält aktive Entwicklung mit Beiträgen von UC Berkeley, Anyscale und der breiten Open-Source-Community. Da die Bereitstellung von LLMs für Produktionsysteme immer kritischer wird, wächst die Rolle von vLLM als Leistungsstandard weiter. Für einen umfassenderen Vergleich von vLLM mit anderen lokalen und Cloud-LLM-Infrastrukturen, prüfen Sie unseren LLM-Hosting: Lokal, Selbstgehostet & Cloud-Infrastruktur im Vergleich.

Nützliche Links

Verwandte Artikel auf dieser Website

• Lokale LLM-Hosting: Vollständiger 2026-Leitfaden – Ollama, vLLM, LocalAI, Jan, LM Studio & mehr – Umfassender Vergleich von 12+ lokalen LLM-Hosting-Tools, einschließlich detaillierter Analyse von vLLM neben Ollama, LocalAI, Jan, LM Studio und anderen. Behandelt die Reife der API, Unterstützung für Tool-Calling, GGUF-Verträglichkeit und Leistungsbenchmarks, um die richtige Lösung zu wählen.

• Ollama Cheat Sheet – Vollständiger Ollama-Befehlsverweis und Cheat Sheet, das Installation, Modellverwaltung, API-Nutzung und Best Practices für die lokale LLM-Deployment abdeckt. Unverzichtbar für Entwickler, die Ollama neben oder anstelle von vLLM verwenden.

• Docker Model Runner vs. Ollama: Welches zu wählen? – Ausführlicher Vergleich zwischen Docks Model Runner und Ollama für lokale LLM-Deployment, die Leistung, GPU-Unterstützung, API-Verträglichkeit und Anwendungsfälle analysiert. Hilft, das Wettbewerbsumfeld zu verstehen, in dem vLLM operiert.

• Docker Model Runner Cheat Sheet: Befehle & Beispiele – Praktisches Docker Model Runner Cheat Sheet mit Befehlen und Beispielen für die AI-Modell-Deployment. Nützlich für Teams, die Docks Ansatz mit den spezialisierten LLM-Serverkapazitäten 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 aktuell mit den neuesten Funktionen und bei der Fehlerbehebung zu bleiben.

• vLLM Dokumentation – Offizielle Dokumentation, die alle Aspekte von vLLM von der grundlegenden Einrichtung bis zu fortgeschrittenen Konfigurationen abdeckt. Enthält API-Referenzen, Leitfäden zur Leistungsabstimmung und Best Practices zur Deployment.

• PagedAttention Paper – Wissenschaftlicher Artikel, der den PagedAttention-Algorithmus einführt, der die Effizienz von vLLM antreibt. Wichtige Lektüre, um die technischen Innovationen hinter den Leistungsadvantagen von vLLM zu verstehen.

• vLLM Blog – Offizieller vLLM Blog, der Release-Announcements, Leistungsbenchmarks, technische Tiefeinblicke und Community-Fallstudien aus Produktionsdeploymenten enthält.

• HuggingFace Model Hub – Umfassende Sammlung offener LLMs, die mit vLLM zusammenarbeiten. Suchen Sie nach Modellen nach Größe, Aufgabe, Lizenz und Leistungsmerkmalen, um das richtige Modell für Ihre Anwendung zu finden.

• Ray Serve Dokumentation – Ray Serve Framework-Dokumentation zum Aufbau skalierbarer, verteilter vLLM-Deployment. Ray bietet erweiterte Funktionen wie Automatisches Skalieren, Multi-Modell-Server und Ressourcenverwaltung für Produktionsumgebungen.

• NVIDIA TensorRT-LLM – NVIDIA TensorRT-LLM für hochoptimierte Inferenz auf NVIDIA-GPUs. Alternative zu vLLM mit unterschiedlichen Optimierungsstrategien, nützlich für Vergleiche und zum Verständnis des Inferenz-Optimierungs-Landschafts.

• OpenAI API Referenz – Offizielle OpenAI API-Dokumentation, mit der die API von vLLM kompatibel ist. Verweisen Sie darauf, wenn Sie Anwendungen erstellen, die mit beiden OpenAI und selbstgehosteten vLLM-Endpunkten interwechselnd arbeiten müssen.