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.

1. Voraussetzungen 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

2. Hugging-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.

3. Docker-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.

4. OpenAI-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.

5. Benchmark 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.

6. Wichtige Parameter im Detail

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

Parameter	Wert (Beispiel)	Bedeutung
--tensor-parallel-size	2	Verteilt Modellgewichte auf 2 GPUs. Wert muss Teiler der Layer-Anzahl sein.
--quantization	awq_marlin	Aktiviert AWQ mit Marlin-Kernel. Beste Performance/Qualität-Balance auf Ada/Hopper.
--max-model-len	16384	Maximale Kontextlänge. Bestimmt KV-Cache-Größe — niedriger = mehr Concurrency.
--gpu-memory-utilization	0.92	Anteil des VRAM, den vLLM nutzen darf. 0.92 ist sicher, 0.95 maximiert Cache.
--enable-prefix-caching	(flag)	Cached gemeinsame System-Prompts über Sessions hinweg. Massiver Latenz-Gewinn bei RAG.
--max-num-seqs	256	Maximale parallele Sequenzen. Reduzieren bei OOM, default ist meist okay.
--api-key	sk-local-...	Pflicht in produktiven Setups, sonst ist der Server offen.

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

7. Troubleshooting: 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.

FAQ zum vLLM-Setup