Llama 3.3 70B auf vLLM: Setup in 40 Minuten

vLLM ist 2026 der De-facto-Standard für produktive LLM-Inferenz auf NVIDIA-Hardware. Das Projekt aus Berkeley liefert PagedAttention, Continuous Batching und einen OpenAI-kompatiblen Server in einem Python-Paket. Wer Llama 3.3 70B oder vergleichbare Modelle im eigenen Rechenzentrum betreiben will, kommt an vLLM derzeit kaum vorbei — die Alternativen TensorRT-LLM (komplexer) und Text Generation Inference (geringere Performance) verlieren in Mittelstands-Setups regelmäßig den Vergleich. Diese Anleitung bringt einen frischen Server in unter 40 Minuten auf produktives Niveau.

/01Voraussetzungen prüfen

Bevor Sie Container starten, sollten Treiber und Hardware passen. Wir setzen Ubuntu 22.04 LTS oder 24.04 LTS voraus, NVIDIA-Treiber Version 550 oder höher, CUDA 12.4+ im Container, Docker 24+ mit dem NVIDIA Container Toolkit. Hardware: zwei NVIDIA L40S (48 GB), alternativ eine H100 80GB, H200 141GB oder zwei A100 80GB. Mindestens 64 GB RAM, 500 GB freier NVMe-Storage für Modelle.

Prüfen Sie zuerst, ob die GPU vom Host gesehen wird und der Treiber passt:

nvidia-smi
# Treiber-Version muss >= 550 sein
# CUDA-Version 12.4+ wird in der oberen rechten Ecke angezeigt

docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi
# Muss dieselben GPUs zeigen wie der Host

Wenn die zweite Zeile fehlschlägt, fehlt das NVIDIA Container Toolkit. Installation:

distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

/02Hugging-Face-Token und Modell-Zugriff

Llama 3.3 70B ist gated. Sie brauchen einen Hugging-Face-Account und müssen die Meta Llama Community License akzeptieren. Auf der Modell-Seite meta-llama/Llama-3.3-70B-Instruct klicken Sie auf "Access" und füllen das Formular aus. Die Freischaltung erfolgt in der Regel innerhalb von 1–24 Stunden.

Anschließend erstellen Sie unter Settings → Access Tokens einen Read-Token. Diesen exportieren Sie in eine .env-Datei neben dem Docker-Compose:

# /opt/vllm/.env
HF_TOKEN=hf_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Für die produktive AWQ-Quantisierung empfehlen wir das Community-Repository casperhansen/llama-3.3-70b-instruct-awq oder das offizielle Meta-Modell mit --quantization awq_marlin. Letzteres lädt das FP16-Original (~140 GB Download) und quantisiert beim Start — einmalig 20 Minuten Wartezeit, danach im Cache.

/03Docker-Compose: Der saubere Weg

vLLM können Sie mit pip install vllm direkt installieren, in der Praxis empfehlen wir aber den offiziellen Container — er bringt CUDA, cuDNN, FlashAttention und alle Abhängigkeiten in geprüften Versionen mit. Legen Sie folgende docker-compose.yml an:

# /opt/vllm/docker-compose.yml
services:
  vllm:
    image: vllm/vllm-openai:v0.9.1
    container_name: vllm-llama33
    restart: unless-stopped
    runtime: nvidia
    environment:
      - HF_TOKEN=${HF_TOKEN}
      - HF_HOME=/root/.cache/huggingface
      - VLLM_WORKER_MULTIPROC_METHOD=spawn
    volumes:
      - ./hf-cache:/root/.cache/huggingface
    ports:
      - "8000:8000"
    ipc: host
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    command: >
      --model meta-llama/Llama-3.3-70B-Instruct
      --quantization awq_marlin
      --tensor-parallel-size 2
      --max-model-len 16384
      --gpu-memory-utilization 0.92
      --served-model-name llama-3.3-70b
      --api-key sk-local-changeme
      --enable-prefix-caching

Starten Sie den Stack mit docker compose up -d und beobachten Sie die Logs: docker compose logs -f vllm. Beim ersten Start lädt vLLM das Modell, alloziert KV-Cache und initialisiert CUDA-Graphs — das dauert je nach Setup 5–12 Minuten. Wenn die Zeile "Application startup complete" erscheint, ist der Server bereit.

/04OpenAI-API testen

Die API ist OpenAI-kompatibel. Ein einfacher Curl-Test bestätigt, dass alles läuft:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-local-changeme" \
  -d '{
    "model": "llama-3.3-70b",
    "messages": [
      {"role": "system", "content": "Du bist ein knapper, präziser Assistent."},
      {"role": "user", "content": "Erkläre Tensor-Parallelismus in zwei Sätzen."}
    ],
    "max_tokens": 200,
    "temperature": 0.3
  }'

Antwortzeit auf 2× L40S liegt bei kalter Anfrage um 1,5 Sekunden, bei warmem Cache um 0,4 Sekunden. Die Antwort kommt als JSON mit dem üblichen choices[0].message.content-Feld. Jeder OpenAI-kompatible Client funktioniert sofort: setzen Sie OPENAI_BASE_URL=http://ihr-server:8000/v1 und OPENAI_API_KEY=sk-local-changeme.

Wenn der Curl-Aufruf einen 401-Fehler zurückgibt, fehlt der Authorization-Header oder der Key stimmt nicht überein. Bei einem 422 ist meist der Modellname falsch — Sie müssen exakt den Wert verwenden, den Sie in --served-model-name definiert haben, nicht den Hugging-Face-Pfad. Bei einem 503 läuft vLLM zwar, ist aber noch im Warmup. Die Logs zeigen den Fortschritt zuverlässig: erst wenn "Application startup complete" steht, beantwortet vLLM Anfragen.

Ein guter Smoke-Test für den ersten produktiven Tag ist die Endpoint-Liste: curl http://localhost:8000/v1/models liefert die geladenen Modelle samt Metadaten. Das ist eine harmlose Anfrage ohne GPU-Last und damit ideal für Healthchecks im Reverse-Proxy oder in Monitoring-Tools wie Uptime Kuma.

/05Benchmark mit vllm bench

Ohne Messung wissen Sie nicht, was Ihr Server wirklich kann. vLLM liefert seit Version 0.7 ein eingebautes Benchmark-Tool. Das wichtigste Szenario: Throughput bei realistischer Concurrency.

# Im laufenden Container ausführen
docker exec -it vllm-llama33 \
  vllm bench serve \
  --backend vllm \
  --model llama-3.3-70b \
  --base-url http://localhost:8000 \
  --api-key sk-local-changeme \
  --dataset-name sharegpt \
  --num-prompts 200 \
  --max-concurrency 16 \
  --request-rate 4

Typische Ergebnisse auf 2× L40S mit Llama 3.3 70B in AWQ: 850–1100 Output-Tokens pro Sekunde aggregiert über 16 parallele Sessions, P50-Latenz pro Token bei 35–45 Millisekunden, P99 unter 80 Millisekunden. Auf einer H100 80GB sind es 1400–1800 Tokens/s. Diese Werte sind die Grundlage Ihrer Kapazitätsplanung — multipliziert mit aktiven Nutzern und durchschnittlicher Anfragefrequenz ergibt sich, ob Ihre Hardware das Pilotvolumen trägt.

Sind Sie wirklich bereit für ein 70B-Modell? vLLM aufzusetzen ist die einfache Hälfte. Datenaufbereitung, RBAC, Logging und Change-Management sind die andere. Der Reifegrad-Selbsttest sortiert die Themen für Sie — in 7 Minuten und mit konkreten Empfehlungen. Selbsttest starten →

/06Wichtige Parameter im Detail

Die Kommandozeilenflags in der Compose-Datei sind nicht beliebig gewählt. Eine kurze Erklärung der entscheidenden Schalter:

--enable-prefix-caching ist der unterschätzte Performance-Hebel. In RAG-Anwendungen, in denen ein 2.000-Token-System-Prompt mit Tool-Definitionen vor jeder Anfrage steht, spart Prefix-Caching bei der zweiten Anfrage diesen kompletten Prefill — die Time-to-First-Token sinkt von 800 auf 80 Millisekunden.

Eine zweite Stellschraube, die häufig übersehen wird, ist die Wahl zwischen Streaming und Non-Streaming-Antworten. vLLM streamt Token-für-Token sobald sie generiert sind. Für Chat-Frontends macht das einen riesigen subjektiven Unterschied: Nutzer warten gefühlt nicht mehr auf eine 30-sekündige Generierung, sondern lesen mit. Im Curl-Test übergeben Sie dazu "stream": true im Request-Body und parsen die Server-Sent-Events. Nahezu alle OpenAI-kompatiblen Clients beherrschen das von Haus aus.

Schließlich lohnt ein Blick auf --swap-space. Standardmäßig hält vLLM den KV-Cache vollständig im VRAM. Bei sehr hoher Concurrency lassen sich nicht aktive Sequenzen vorübergehend in CPU-RAM auslagern (Standardwert 4 GB), das verschiebt den Engpass von VRAM zu RAM und steigert die nutzbare Sessionzahl spürbar. Der Preis ist Latenz beim Wiedereintritt einer Session — in Chat-Workloads kaum spürbar, weil Nutzer ohnehin Sekunden zwischen Eingaben pausieren.

/07Troubleshooting: OOM, Timeouts, langsame Antworten

Die häufigsten Fehlerbilder und ihre Lösungen aus der Praxis:

• CUDA OutOfMemory beim Start: Reihenfolge der Hebel — --gpu-memory-utilization 0.85 setzen, dann --max-model-len 8192 reduzieren, dann --enforce-eager aktivieren (deaktiviert CUDA-Graphs, spart 2–3 GB), zuletzt --max-num-seqs 32.
• "Failed to download model" trotz Token: HF_TOKEN-Variable wird im Container nicht durchgereicht. Prüfen mit docker compose exec vllm env | grep HF. Lizenz auf huggingface.co/meta-llama/... wirklich akzeptiert?
• Sehr langsamer Throughput trotz freier GPU: Vermutlich ist --enable-prefix-caching aus oder --enforce-eager versehentlich aktiv. Außerdem prüfen, ob NVIDIA-Persistence-Mode aktiv ist: nvidia-smi -pm 1.
• Tensor-Parallelismus startet nicht (NCCL-Fehler): Im Container VLLM_WORKER_MULTIPROC_METHOD=spawn setzen und ipc: host in Compose. Bei zwei separaten Karten ohne NVLink ist das Standard.
• Antworten brechen mitten im Satz ab: max_tokens im Request zu niedrig oder Modell trifft EOS. Im Request-Body explizit auf 2048 oder höher setzen.

Dieser Beitrag ist Teil des Leitfadens On-Premise-KI für den Mittelstand — dort steht der Gesamtzusammenhang.