vLLM für produktive Inferenz: wenn Ollama nicht mehr reicht | ComputeBox

vLLM für produktive Inferenz: wenn Ollama nicht mehr reicht | ComputeBox

Kurzfassung NVIDIA-Treiber und Container Toolkit installieren, vLLM als Docker-Container mit einem quantisierten Modell starten, API-Key setzen, mit --max-model-len und --gpu-memory-utilization an den VRAM anpassen — und den OpenAI-kompatiblen Endpunkt über Caddy oder Tailscale bereitstellen. Ergebnis: ein Inferenz-Server, der Dutzende parallele Anfragen gleichzeitig bedient.

Wann reicht Ollama nicht mehr?#

Ollama ist perfekt für den Einstieg: ein Befehl, Modell läuft. Solange du allein oder im kleinen Team sequentiell mit dem Modell arbeitest, gibt es keinen Grund zu wechseln.

Anders sieht es aus, sobald dein Modell zum Backend wird — eine App mit vielen Nutzern, ein interner KI-Dienst für die ganze Firma, eine Pipeline, die tausende Dokumente verarbeitet. Dann treffen viele Anfragen gleichzeitig ein, und genau hier spielt vLLM seine Stärken aus:

Continuous Batching: Neue Anfragen werden laufend in den aktuellen Batch eingefädelt, statt zu warten, bis die vorherige Generierung fertig ist. Die GPU ist dadurch fast permanent ausgelastet.
PagedAttention: Der KV-Cache wird wie virtueller Speicher in Blöcken verwaltet. Das reduziert VRAM-Verschwendung drastisch und erlaubt deutlich mehr parallele Sessions.
OpenAI-kompatible API mit API-Keys: /v1/chat/completions und /v1/completions funktionieren mit jedem OpenAI-SDK — nur die base_url wird umgestellt. In der Praxis heißt das: Wo Ollama bei parallelen Anfragen Anfragen nacheinander oder in kleinen Gruppen abarbeitet, bedient vLLM auf derselben Hardware ein Vielfaches an gleichzeitigen Nutzern — bei stabiler Latenz. Der Preis dafür ist etwas mehr Einrichtungsaufwand und ein Server, der pro Instanz genau ein Modell bedient und dessen VRAM dafür fest reserviert.

Kurz: Ollama ist der Werkzeugkasten, vLLM ist die Produktionsmaschine.

CTA: Produktive Inferenz braucht dedizierten VRAM: RTX 6000 Ada mit 48 GB, ohne Sharing, aus deutschen Rechenzentren. GPU-Server ansehen →

Voraussetzungen#

Einen starken GPU-Server
Configure this GPU server
SSH-Zugang zum Server
Docker und Docker Compose
Firewall mit ufw eingerichtet — der vLLM-Port bleibt zu Wir betreiben vLLM per Docker. Das hält den Host sauber, macht Updates trivial und entspricht dem Setup, das du vielleicht schon vom Odysseus-GPU-Tutorial kennst.

Schritt 1: NVIDIA-Treiber installieren#

Falls noch nicht geschehen:

Nach dem Neustart prüfen:

Deine RTX 4000 Ada oder RTX 6000 Ada sollte mit VRAM und Treiberversion gelistet sein.

Schritt 2: NVIDIA Container Toolkit einrichten#

Damit Docker-Container auf die GPU zugreifen können:

Kurzer Funktionstest:

Zeigt der Container deine GPU an, ist alles bereit.

Schritt 3: Modell wählen#

Anders als Ollama lädt vLLM Modelle direkt von Hugging Face — und reserviert den VRAM einer Instanz fest für genau ein Modell. Für dedizierte GPUs mit 20 oder 48 GB sind quantisierte Modelle (AWQ) die richtige Wahl: fast gleiche Qualität, deutlich weniger Speicher, mehr Platz für parallele Sessions.

GPU	Empfehlung	Hugging-Face-ID
RTX 4000 Ada (20 GB)	Qwen 2.5 7B Instruct (AWQ)	`Qwen/Qwen2.5-7B-Instruct-AWQ`
RTX 4000 Ada (20 GB)	Llama 3.1 8B Instruct (AWQ)	`hugging-quants/Meta-Llama-3.1-8B-Instruct-AWQ-INT4`
RTX 6000 Ada (48 GB)	Qwen 2.5 32B Instruct (AWQ)	`Qwen/Qwen2.5-32B-Instruct-AWQ`

Hinweis: Llama-Modelle sind auf Hugging Face „gated" — du brauchst einen (kostenlosen) Hugging-Face-Account, musst die Lizenz dort einmal akzeptieren und einen Access Token erstellen. Qwen-Modelle sind ohne Token frei ladbar.

Schritt 4: vLLM per Docker Compose starten#

Lege ein Projektverzeichnis an:

Erstelle eine .env mit einem selbst gewählten API-Key (und optional deinem Hugging-Face-Token):

Einen sicheren Key erzeugst du z. B. mit openssl rand -hex 32. Dann die docker-compose.yml:

Starten und Logs verfolgen:

Der erste Start dauert ein paar Minuten: Das Modell wird heruntergeladen, in den VRAM geladen und der KV-Cache reserviert. Sobald im Log Application startup complete erscheint, läuft dein Inferenz-Server.

Wichtige Details am Rande: Der Port ist mit 127.0.0.1:8000 bewusst nur lokal gebunden, das Volume hf-cache verhindert erneute Downloads bei Neustarts, und --api-key schützt jede Anfrage.

Schritt 5: API testen#

vLLM spricht das OpenAI-Protokoll. Direkt auf dem Server:

In Anwendungen brauchst du nur zwei Anpassungen — hier am Beispiel des offiziellen OpenAI-SDK für Python:

Damit funktionieren auch Frameworks wie LangChain, LlamaIndex oder Odysseus direkt gegen deinen Server — Odysseus bekommt als OpenAI-kompatiblen Endpunkt einfach http://host.docker.internal:8000/v1 plus deinen API-Key eingetragen.

Schritt 6: Nach außen bereitstellen — sauber über Caddy#

Auch mit API-Key gehört Port 8000 nicht direkt ins Internet. Der saubere Weg ist ein Reverse Proxy mit HTTPS, wie im Tutorial Reverse Proxy mit Caddy eingerichtet. In der Caddyfile genügt:

Caddy besorgt automatisch das TLS-Zertifikat, vLLM prüft den API-Key — fertig ist dein produktiver Endpunkt unter https://ai.deine-domain.de/v1.

Soll die API nur intern erreichbar sein, ist stattdessen Tailscale die richtige Wahl: Server ins Tailnet hängen, Port-Bindung in der Compose-Datei auf die Tailscale-IP legen, kein öffentlicher Zugriff nötig.

Tuning: die drei wichtigsten Stellschrauben#

--max-model-len — die maximale Kontextlänge pro Anfrage. Kürzerer Kontext = kleinerer KV-Cache pro Session = mehr parallele Anfragen. Wer keine 128k-Kontexte braucht, gewinnt mit 16k oder 32k massiv Kapazität.

--gpu-memory-utilization — welcher Anteil des VRAM reserviert wird (Standard 0.90). Läuft auf der GPU sonst nichts, kannst du auf 0.95 gehen; teilt sie sich den Speicher mit anderen Prozessen, reduziere den Wert.

Quantisierung — AWQ-Modelle brauchen rund ein Viertel des Speichers der Vollversion. Der frei werdende VRAM fließt direkt in den KV-Cache, also in parallele Kapazität. Für produktive Inferenz auf 20-bis-48-GB-Karten fast immer die richtige Wahl.

Wie gut dein Setup ausgelastet ist, siehst du live in den Logs (Running: X reqs, GPU KV cache usage: Y%) und unter http://localhost:8000/metrics im Prometheus-Format — ideal für ein späteres Monitoring.

Fehlerbehebung#

CUDA out of memory beim Start Das Modell plus KV-Cache passt nicht in den VRAM. Reduziere --max-model-len, senke --gpu-memory-utilization leicht oder nimm ein AWQ-quantisiertes bzw. kleineres Modell.

401 Unauthorized bei Anfragen Der Authorization: Bearer …-Header fehlt oder der Key stimmt nicht mit VLLM_API_KEY in der .env überein. Nach Änderungen an der .env: docker compose up -d erneut ausführen.

403 oder gated repo beim Modell-Download Das Modell ist auf Hugging Face zugangsbeschränkt (typisch bei Llama). Lizenz auf der Modellseite akzeptieren, Access Token erstellen und als HF_TOKEN in die .env eintragen.

Container startet, aber die GPU wird nicht genutzt Container Toolkit prüfen: docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi. Schlägt das fehl, Schritt 2 wiederholen und Docker neu starten.

Sehr lange Startzeit bei jedem Neustart Fehlt das hf-cache-Volume, lädt vLLM das Modell jedes Mal neu herunter. Volume wie in der Compose-Datei oben einbinden.

Häufige Fragen#

Ollama oder vLLM — konkrete Faustregel? Ein bis wenige Nutzer, wechselnde Modelle, schnelles Ausprobieren: Ollama. Ein festes Modell als Dienst für viele parallele Anfragen: vLLM. Beides parallel auf einem Server geht wegen der festen VRAM-Reservierung von vLLM nur eingeschränkt.

Kann vLLM mehrere Modelle gleichzeitig bedienen? Eine Instanz bedient ein Modell. Mehrere Modelle heißt mehrere Instanzen — und damit realistisch mehrere GPUs oder eine sehr großzügige VRAM-Aufteilung.

Wie viele parallele Anfragen schafft mein Server? Das hängt von Modellgröße, Kontextlänge und Antwortlänge ab. Grob: Was nach dem Modell an VRAM übrig bleibt, wird zu KV-Cache — und der bestimmt die Zahl gleichzeitiger Sessions. Mit einem 7B-AWQ-Modell und 16k Kontext bedient eine RTX 4000 Ada problemlos dutzende parallele Anfragen; die 48 GB der RTX 6000 Ada schaffen entsprechend mehr Reserve oder größere Modelle.

Bleiben meine Daten auf dem Server? Ja. vLLM läuft vollständig lokal; nur der einmalige Modell-Download kontaktiert Hugging Face. Prompts und Antworten verlassen deinen ComputeBox-Server nicht — die Grundlage für datenschutzkonforme KI-Dienste aus deutschen Rechenzentren.

Wie geht es weiter?#

Ollama auf dem GPU-Server installieren — der einfache Einstieg, falls du vLLM (noch) nicht brauchst
Reverse Proxy mit Caddy — HTTPS und Domain für deinen Endpunkt
Odysseus installieren: self-hosted AI-Workspace — die Oberfläche für dein vLLM-Backend

CTA: GPU-Server für produktive Inferenz RTX 6000 Ada mit 48 GB VRAM — dediziert, ohne Token-Kosten, aus deutschen Rechenzentren. GPU-Server konfigurieren →

bash

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 update && sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

yaml

services:
  vllm:
    image: vllm/vllm-openai:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:8000"
    environment:
      - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}
    volumes:
      - hf-cache:/root/.cache/huggingface
    command: >
      --model Qwen/Qwen2.5-7B-Instruct-AWQ
      --max-model-len 16384
      --gpu-memory-utilization 0.90
      --api-key ${VLLM_API_KEY}
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
 
volumes:
  hf-cache:

bash

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $VLLM_API_KEY" \
  -d '{
    "model": "Qwen/Qwen2.5-7B-Instruct-AWQ",
    "messages": [{"role": "user", "content": "Erkläre Continuous Batching in einem Satz."}]
  }'

python

from openai import OpenAI
 
client = OpenAI(
    base_url="https://ai.deine-domain.de/v1",  # dein Endpunkt
    api_key="dein-vllm-api-key",
)
 
response = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct-AWQ",
    messages=[{"role": "user", "content": "Hallo vLLM!"}],
)
print(response.choices[0].message.content)