Llama 4 vLLM Setup: 11 Schritte, 90 Min [2026]

Meta hat mit Llama 4 im April 2025 den bislang letzten offenen Modell-Zweig seiner KI-Reihe veröffentlicht, und daran hat sich bis August 2026 nichts geändert. Der Konzern setzt seine neueste Forschung inzwischen unter dem Namen Muse Spark um, allerdings mit geschlossenen Gewichten und kostenpflichtigem API-Zugang. Llama 4 Scout und Llama 4 Maverick bleiben damit die aktuellsten Modelle, die sich legal herunterladen, anpassen und auf eigener Hardware betreiben lassen, und genau das macht sie für Unternehmen in Deutschland interessant, die Daten nicht an eine fremde API schicken wollen oder dürfen.

Dieses Tutorial zeigt, wie du Llama 4 Scout mit vLLM selbst hostest, dem Serving-Framework, das Meta selbst in seiner offiziellen Dokumentation als unterstützten Inferenz-Server nennt. Anders als Ollama, das auf schnelle Einzelnutzer-Setups zielt, ist vLLM für Durchsatz gebaut: parallele Anfragen, kontinuierliches Batching und eine OpenAI-kompatible API, die sich direkt in bestehende Anwendungen einklinkt. Am Ende hast du einen laufenden Container, eine getestete API und ein kleines Beispielprojekt, das die Grundlage für einen internen Chatbot bildet.

Zwölf Schritte, ein paar Stunden Zeit und eine GPU mit ausreichend Speicher reichen aus. Wir gehen jeden Befehl einzeln durch, zeigen echte Fehlermeldungen und erklären, warum sie auftreten, statt sie nur aufzulisten. Unterwegs bauen wir außerdem eine minimale, aber lauffähige Chat-API, damit du am Ende nicht nur einen Container hast, der irgendwo läuft, sondern eine Grundlage, die sich in ein reales Projekt einbauen lässt.

Was ist Llama 4 Scout und warum lohnt sich Self-Hosting?

Llama 4 erschien als Familie aus zwei offenen Modellen. Scout hat 109 Milliarden Parameter insgesamt, aktiviert davon aber pro Token nur 17 Milliarden, weil es als Mixture-of-Experts mit 16 Experten aufgebaut ist. Maverick geht mit 400 Milliarden Gesamtparametern und 128 Experten deutlich größer, aktiviert aber ebenfalls nur 17 Milliarden Parameter pro Anfrage. Dieses Prinzip spart Rechenleistung, ohne die Qualität der größeren Modellklasse aufzugeben.

Für dieses Tutorial nutzen wir Scout, weil Meta es laut eigener Ankündigung so ausgelegt hat, dass es quantisiert auf einer einzelnen NVIDIA-H100-GPU läuft. Maverick braucht dagegen typischerweise einen ganzen H100-DGX-Host mit acht GPUs, was für die meisten Teams jenseits des Budgets liegt. Scout bietet zudem ein Kontextfenster von bis zu 10 Millionen Tokens, Maverick kommt auf 1 Million. Beide stehen unter der Llama 4 Community License, einer offenen, aber nicht OSI-zertifizierten Lizenz mit einer Zusatzklausel: Wer mehr als 700 Millionen monatlich aktive Nutzer hat, braucht eine gesonderte Vereinbarung mit Meta. Für den Großteil der DACH-Unternehmen spielt das keine Rolle.

Self-Hosting lohnt sich aus drei Gründen: Daten verlassen nie deine Infrastruktur, was bei Kundendaten oder internen Dokumenten oft eine DSGVO-Voraussetzung ist. Die Kosten pro Anfrage sinken bei hoher Auslastung gegenüber API-Gebühren spürbar. Und du bist nicht von Rate-Limits oder Preisänderungen eines Anbieters abhängig.

Wichtig ist die Erwartungshaltung: Scout und Maverick treten qualitativ nicht gegen die neuesten geschlossenen Flaggschiffmodelle an, sie sind offene Gewichte, die Meta bereits vor über einem Jahr veröffentlicht hat. Für Aufgaben wie internen Support, Dokumentenzusammenfassung, Code-Hilfe oder ein firmeneigenes Wissenssystem reicht die Qualität in der Praxis oft trotzdem locker aus, gerade wenn Antwortzeit, Datenschutz und Kostenkontrolle wichtiger sind als der letzte Prozentpunkt Benchmark-Score. Wer die absolute Modellspitze braucht, sollte ergänzend eine API wie Gemini oder Claude einbinden und Llama 4 gezielt für die Fälle nutzen, in denen Selbstkontrolle über die Daten Vorrang hat.

Ein Blick auf die Architektur erklärt, warum Meta zwei statt einem Modell veröffentlicht hat. Scout richtet sich an Teams, die ein starkes Allround-Modell auf begrenzter Hardware betreiben wollen, etwa für Chat, Zusammenfassung oder einfache Agentenketten. Maverick zielt auf Anwendungsfälle, bei denen die zusätzliche Kapazität der 128 Experten spürbar mehr Qualität bringt, etwa komplexe mehrstufige Aufgaben oder sehr lange Dokumente, wo die Investition in einen Multi-GPU-Host sich lohnt. Für ein erstes Self-Hosting-Projekt in einem deutschen Unternehmen ist Scout fast immer der richtige Startpunkt, weil sich Erfahrungen mit Betrieb, Monitoring und Kosten dort deutlich schneller sammeln lassen als auf einem Acht-GPU-Cluster.

vLLM vs. Ollama vs. llama.cpp: die richtige Engine wählen

Bevor wir loslegen, lohnt sich die Einordnung. Ollama ist die einfachste Wahl für einen einzelnen Nutzer, der ein Modell schnell lokal testen will, und eignet sich hervorragend für DeepSeek-V4-Flash-Setups, wie wir in einem früheren Tutorial gezeigt haben. Llama.cpp ist die genügsamste Variante, läuft auch ohne GPU auf reiner CPU-Leistung und produziert die GGUF-Dateien, die viele Desktop-Tools nutzen. Für Scout gibt es GGUF-Quantisierungen von Community-Projekten wie Unsloth, die je nach Kompressionsstufe zwischen 40 und 90 GB groß sind.

Der Unterschied zeigt sich am deutlichsten bei gleichzeitigen Anfragen. Schickst du llama.cpp oder Ollama zehn Chat-Anfragen auf einmal, arbeitet die Engine sie im Wesentlichen nacheinander ab, jede wartet auf die vorherige. vLLM dagegen bündelt alle zehn in einem gemeinsamen Batch und verarbeitet sie parallel auf derselben GPU, solange der Speicher reicht. Für einen einzelnen Entwickler am Laptop ist dieser Unterschied unsichtbar. Für ein Team-Tool mit fünf gleichzeitigen Chat-Fenstern entscheidet er darüber, ob Nutzer zwei Sekunden oder zwanzig Sekunden auf eine Antwort warten.

vLLM verfolgt ein anderes Ziel: maximaler Durchsatz bei vielen gleichzeitigen Anfragen. Die Engine nutzt PagedAttention, um den Arbeitsspeicher für den Attention-Cache effizient zu verwalten, und kontinuierliches Batching, damit neue Anfragen nicht auf den Abschluss älterer warten müssen. Für einen internen Chatbot mit zehn oder hundert gleichzeitigen Nutzern ist das der entscheidende Unterschied zu Ollama, das für Einzelanfragen optimiert ist. vLLM unterstützte Llama 4 laut eigener Dokumentation bereits am Tag der Veröffentlichung, was zeigt, wie eng beide Projekte zusammenarbeiten.

Die Faustregel für die Wahl: Testest du nur, ob Llama 4 für deinen Anwendungsfall überhaupt taugt, spar dir den Docker-Aufwand und starte mit Ollama, wie im DeepSeek-Tutorial beschrieben. Baust du dagegen einen Dienst, den mehrere Kolleginnen oder Kunden gleichzeitig nutzen, oder brauchst du planbare Latenz unter Last, führt an vLLM kaum ein Weg vorbei. Der Mehraufwand bei der Einrichtung zahlt sich hier durch Durchsatz aus, nicht durch Komfort.

Wie PagedAttention und Mixture-of-Experts zusammenspielen

Zwei technische Ideen machen den Betrieb von Llama 4 Scout auf einer einzelnen GPU überhaupt praktikabel. Die erste ist die Mixture-of-Experts-Architektur des Modells selbst: Statt bei jeder Anfrage alle 109 Milliarden Parameter zu aktivieren, wählt ein Router pro Token nur wenige der 16 Experten aus und aktiviert damit effektiv nur 17 Milliarden Parameter. Das senkt den Rechenaufwand pro Token erheblich, ändert aber nichts daran, dass alle Experten trotzdem im Speicher liegen müssen, weil sich die Auswahl von Token zu Token unterscheidet.

Die zweite Idee kommt von vLLM selbst: PagedAttention verwaltet den Key-Value-Cache, also den Speicher, in dem sich das Modell an den bisherigen Gesprächsverlauf erinnert, nicht als einen zusammenhängenden Block, sondern in kleinen, flexibel zuweisbaren Seiten, ähnlich wie virtueller Speicher in einem Betriebssystem. Ohne diesen Trick müsste vLLM für jede Anfrage von vornherein den maximal möglichen Speicherblock reservieren, selbst wenn die tatsächliche Konversation viel kürzer ausfällt. Mit PagedAttention lassen sich Speicherfragmente wiederverwenden, sobald eine Anfrage abgeschlossen ist, wodurch deutlich mehr parallele Nutzer auf derselben GPU Platz finden. In Kombination mit kontinuierlichem Batching, bei dem neue Anfragen direkt in laufende Batches einsortiert werden, statt auf den nächsten freien Slot zu warten, ergibt sich der Durchsatzvorteil, der vLLM von einfacheren Serving-Lösungen unterscheidet.

Voraussetzungen: Hardware, Software und Versionen

Die native BF16-Gewichte von Scout brauchen mit 109 Milliarden Parametern etwa 218 GB Speicher, mehr als eine einzelne Consumer- oder selbst Prosumer-GPU bietet. Mit INT4- oder FP8-Quantisierung schrumpft das auf einen Bereich, der auf eine einzelne H100 mit 80 GB passt. Wer keine H100 besitzt, greift auf gemietete Cloud-GPUs zurück, etwa bei RunPod, Lambda oder AWS. Die folgende Tabelle zeigt, was du für dieses Tutorial brauchst.

Komponente	Minimum	Empfohlen
GPU	1x NVIDIA A100 80GB	1x NVIDIA H100 80GB
VRAM	80 GB (mit FP8-Quantisierung)	80–160 GB für mehr Kontext
Docker Engine	Version 24.0 oder neuer	Aktuelle Stable-Version
NVIDIA Container Toolkit	Version 1.15 oder neuer	Aktuelle Stable-Version
NVIDIA-Treiber	Ab Version 550	Aktueller Treiber für CUDA 12.4+
vLLM-Docker-Image	vllm/vllm-openai:latest	Auf feste Version pinnen (z. B. :v0.8.x)
Arbeitsspeicher (Host)	32 GB RAM	64 GB RAM
Freier Festplattenspeicher	250 GB	500 GB (für mehrere Modellversionen)

Du brauchst außerdem einen Hugging-Face-Account mit akzeptierter Llama-4-Lizenz und ein Terminal mit sudo-Rechten auf dem Host. Alle Befehle unten sind für Ubuntu 24.04 geschrieben, funktionieren mit kleinen Anpassungen aber auf jeder Linux-Distribution mit systemd.

Schritt 1: GPU-Infrastruktur wählen

Wenn dein Unternehmen bereits über eine H100 oder A100 im eigenen Rechenzentrum verfügt, kannst du direkt zu Schritt 2 springen. Andernfalls ist eine gemietete Cloud-GPU der pragmatischere Einstieg, um erst zu testen, bevor du in eigene Hardware investierst. RunPod, Lambda Labs und Vast.ai bieten stundenweise Abrechnung für H100-Instanzen an, was sich für einen ersten Testlauf über wenige Stunden eher lohnt als ein Kauf im fünfstelligen Bereich.

Achte beim Anbieter auf drei Punkte: Der Server muss NVIDIA-Treiber und Docker bereits vorinstalliert haben oder dir Root-Zugriff geben, um sie selbst zu installieren. Die Region sollte in der EU liegen, wenn du mit personenbezogenen Daten arbeitest. Und die Preisliste sollte den Stundenpreis inklusive Netzwerk-Traffic ausweisen, denn viele Anbieter berechnen Datenübertragung separat.

Ein oft übersehener vierter Punkt ist die Kündigungs- und Snapshot-Funktion des Anbieters. Wenn du eine Instanz stundenweise mietest, testest und danach wieder abschaltest, verlierst du ohne Snapshot jedes Mal den heruntergeladenen Modell-Cache und musst beim nächsten Test erneut die volle Downloadzeit einplanen. Viele Anbieter erlauben, ein Volume getrennt von der Recheninstanz zu mieten und bei Bedarf neu anzuhängen. Das kostet zwar über die Zeit gerechnet etwas mehr als eine reine Rechenstunde, spart aber bei wiederholten Tests erheblich Zeit und Nerven.

Schritt 2: Docker Engine und NVIDIA Container Toolkit installieren

Docker allein reicht nicht, damit ein Container auf die GPU zugreifen kann. Das NVIDIA Container Toolkit übernimmt diese Brücke zwischen Host-Treiber und Container-Runtime.

# Docker Engine installieren
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER

# NVIDIA Container Toolkit Repository hinzufügen
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

Melde dich nach dem ersten Befehl einmal ab und wieder an, damit die neue Docker-Gruppenmitgliedschaft greift. Ohne diesen Schritt musst du jeden folgenden Docker-Befehl mit sudo ausführen, was bei den Volume-Mounts später zu Berechtigungsproblemen führen kann.

Schritt 3: GPU-Zugriff im Container prüfen

Bevor du das große vLLM-Image lädst, das mehrere Gigabyte umfasst, solltest du sicherstellen, dass Docker die GPU überhaupt sieht. Dieser Test dauert wenige Sekunden und erspart dir später stundenlange Fehlersuche.

docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

Die Ausgabe sollte eine Tabelle mit deiner GPU, dem Treiber und der CUDA-Version zeigen, etwa so:

+-----------------------------------------------------------------------------------+
| NVIDIA-SMI 550.90.07    Driver Version: 550.90.07    CUDA Version: 12.4          |
|-------------------------------+----------------------+----------------------+
| GPU  Name                     | Bus-Id        Disp.A | Volatile Uncorr. ECC |
|   0  NVIDIA H100 80GB HBM3    | 00000000:01:00.0 Off |                    0 |
+-----------------------------------------------------------------------------------+

Erscheint stattdessen ein Fehler wie “could not select device driver”, fehlt entweder das Container Toolkit oder der Docker-Daemon wurde nach der Konfiguration nicht neu gestartet. Ein erneutes sudo systemctl restart docker löst das Problem in den meisten Fällen.

Schritt 4: Hugging-Face-Token erstellen und Lizenz akzeptieren

Die Gewichte von Llama 4 Scout liegen unter meta-llama/Llama-4-Scout-17B-16E-Instruct auf Hugging Face, sind aber gated: Du musst die Llama 4 Community License auf der Modellseite akzeptieren, bevor dein Account Zugriff bekommt. Erstelle danach unter den Account-Einstellungen einen Access Token mit Leserechten.

export HF_TOKEN="hf_dein_token_hier"
mkdir -p ~/.cache/huggingface
echo "export HF_TOKEN=$HF_TOKEN" >> ~/.bashrc

Speichere den Token niemals direkt im docker-compose.yml oder in einem Git-Repository. Nutze stattdessen eine .env-Datei, die du in .gitignore einträgst, oder ein Secret-Management-Tool, wenn du in Kubernetes deployst.

Schritt 5: Das offizielle vLLM-Image laden

vLLM stellt für NVIDIA-GPUs, AMD-ROCm und Intel-XPU jeweils eigene Images auf Docker Hub bereit. Für dieses Tutorial nutzen wir das NVIDIA-Image.

docker pull vllm/vllm-openai:latest

# Alternative für AMD-GPUs
# docker pull vllm/vllm-openai-rocm:latest

Der Download dauert je nach Verbindung fünf bis fünfzehn Minuten, da das Image CUDA-Bibliotheken, PyTorch und die vLLM-Runtime selbst enthält. Prüfe danach mit docker images, ob das Image lokal vorhanden ist, bevor du fortfährst.

Schritt 6: Llama 4 Scout mit vLLM starten

Jetzt kommt der zentrale Befehl des gesamten Tutorials. Er lädt die Modellgewichte von Hugging Face herunter, quantisiert sie nach FP8 und startet den OpenAI-kompatiblen API-Server auf Port 8000.

docker run --gpus all --rm \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HF_TOKEN=$HF_TOKEN \
  --shm-size=16g \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-4-Scout-17B-16E-Instruct \
  --port 8000 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.9 \
  --quantization fp8

Der erste Start dauert zehn bis dreißig Minuten, weil rund 60 bis 90 GB an Gewichten heruntergeladen und in den GPU-Speicher geladen werden müssen. Bei jedem weiteren Start greift vLLM auf den gemounteten Cache zurück und ist in ein bis zwei Minuten einsatzbereit. Beachte --shm-size=16g: Ohne ausreichend Shared Memory bricht der Ladevorgang bei großen Modellen mit einem Bus-Error ab.

Wir setzen --max-model-len hier bewusst auf 131.072 Tokens statt der vollen 10 Millionen, die Scout theoretisch unterstützt. Das volle Kontextfenster würde den Key-Value-Cache sprengen und ist für die meisten Chatbot-Anwendungen ohnehin nicht nötig. Ein erfolgreicher Start endet mit einer Zeile wie dieser:

INFO:     Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)
INFO 08-20 14:32:07 api_server.py:456] Application startup complete.

Schritt 7: Die OpenAI-kompatible API testen

Sobald der Server läuft, verhält sich die API wie die von OpenAI, nur mit deiner eigenen URL. Ein einfacher curl-Aufruf bestätigt, dass alles funktioniert.

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-4-Scout-17B-16E-Instruct",
    "messages": [{"role": "user", "content": "Erkläre PagedAttention in zwei Sätzen."}]
  }'

Für die Integration in eine Anwendung reicht dasselbe OpenAI-Python-Paket, das du für GPT-Modelle nutzen würdest, nur mit angepasster base_url:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="leer")

antwort = client.chat.completions.create(
    model="meta-llama/Llama-4-Scout-17B-16E-Instruct",
    messages=[{"role": "user", "content": "Fasse den letzten Absatz in einem Satz zusammen."}],
)
print(antwort.choices[0].message.content)

Die Antwort kommt als JSON mit den üblichen Feldern choices, usage und finish_reason zurück, exakt im gleichen Format, das du von der OpenAI-API kennst. Das macht den Wechsel zwischen gehosteten und selbst betriebenen Modellen zu einer einzeiligen Konfigurationsänderung.

Schritt 8: docker-compose.yml für den Dauerbetrieb

Ein einzelner docker run-Befehl ist gut zum Testen, aber ungeeignet für den Produktivbetrieb, weil er bei einem Server-Neustart nicht automatisch wieder anläuft. Eine docker-compose.yml behebt das.

services:
  vllm-llama4:
    image: vllm/vllm-openai:latest
    restart: unless-stopped
    ports:
      - "8000:8000"
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
    environment:
      - HF_TOKEN=${HF_TOKEN}
    shm_size: "16gb"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    command:
      - --model=meta-llama/Llama-4-Scout-17B-16E-Instruct
      - --max-model-len=131072
      - --gpu-memory-utilization=0.9
      - --quantization=fp8

Starte den Stack mit docker compose up -d und prüfe die Logs mit docker compose logs -f vllm-llama4. Die Datei .env im selben Verzeichnis sollte deinen HF_TOKEN enthalten, damit die Variable beim Start eingelesen wird.

Schritt 9: Performance-Parameter feinjustieren

Die Standardwerte funktionieren, sind aber selten optimal für deinen konkreten Anwendungsfall. Diese Flags solltest du kennen.

Flag	Wirkung	Empfehlung
–gpu-memory-utilization	Anteil des VRAM, den vLLM reservieren darf	0.85–0.95, niedriger bei geteilter GPU
–max-model-len	Maximale Kontextlänge in Tokens	32.768–131.072 für Chat-Anwendungen
–tensor-parallel-size	Anzahl GPUs, über die das Modell verteilt wird	1 für Scout auf einer H100, sonst Anzahl GPUs
–quantization	Kompressionsformat der Gewichte	fp8 als guter Kompromiss aus Speicher und Qualität
–max-num-seqs	Maximale Anzahl paralleler Anfragen im Batch	16–64, abhängig von VRAM-Reserve
–api-key	Aktiviert Bearer-Token-Authentifizierung	Immer setzen, sobald der Port öffentlich erreichbar ist

Erhöhst du --max-num-seqs zu aggressiv, ohne genug VRAM-Puffer zu lassen, quittiert vLLM das mit einem Out-of-Memory-Fehler beim ersten gleichzeitigen Lastspitzentest, nicht schon beim Start. Teste Lastspitzen deshalb immer mit realistischer paralleler Anfragezahl, bevor du in Produktion gehst.

Schritt 10: Reverse Proxy und API-Key-Absicherung einrichten

Port 8000 direkt ins Internet zu hängen, ist keine gute Idee. Ein Reverse Proxy mit TLS und die eingebaute API-Key-Prüfung von vLLM schließen die offensichtlichsten Lücken.

# vLLM mit aktivem API-Key starten
docker run --gpus all --rm -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HF_TOKEN=$HF_TOKEN \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-4-Scout-17B-16E-Instruct \
  --api-key "$(openssl rand -hex 24)"

Für den öffentlichen Zugriff reicht ein schlanker Caddy- oder Nginx-Proxy, der automatisch ein Let’s-Encrypt-Zertifikat zieht und Anfragen an 127.0.0.1:8000 weiterreicht. So bleibt der vLLM-Port selbst nur intern erreichbar, während Kunden oder Kollegen über HTTPS auf die verschlüsselte Domain zugreifen.

Sicherheit beim Self-Hosting: Netzwerk und Zugriffskontrolle

Ein selbst gehostetes Modell verschiebt die Verantwortung für Sicherheit komplett zu dir. Bei einer API übernimmt der Anbieter DDoS-Schutz, Zugriffskontrolle und Patch-Management. Bei vLLM auf eigener Hardware musst du diese Schichten selbst denken. Neben API-Key und Reverse Proxy gehören dazu mindestens vier weitere Maßnahmen.

Erstens: Firewall-Regeln, die Port 8000 nur für den Reverse-Proxy-Host freigeben, nicht für das gesamte Netzwerk. Ein einfaches ufw allow from 127.0.0.1 to any port 8000 reicht auf einem Single-Host-Setup meist aus. Zweitens: Rate-Limiting auf Ebene des Proxys, damit ein einzelner Client nicht die gesamte GPU-Kapazität für sich beansprucht und andere Nutzer aussperrt, ein Angriffsmuster, das bei rechenintensiven LLM-Endpunkten deutlich wirksamer ist als bei klassischen Web-APIs. Drittens: Logging aller Anfragen mit Zeitstempel, IP und angefragtem Modell, damit du im Ernstfall nachvollziehen kannst, wer wann wie viel Rechenzeit verbraucht hat. Viertens: Wenn du RAG-Inhalte oder Dokumente aus unsicheren Quellen an das Modell übergibst, solltest du diese Eingaben wie in unserem Tutorial zum Schutz vor Prompt Injection beschrieben separat behandeln, denn ein selbst gehostetes Modell ist gegen manipulierte Eingaben nicht automatisch immuner als eine API.

Ein Punkt wird beim Self-Hosting oft unterschätzt: Weil du selbst für Patches verantwortlich bist, solltest du das vLLM-Image nicht auf unbestimmte Zeit auf :latest stehen lassen, ohne die Release-Notes zu verfolgen. Ein neues Image kann Sicherheitskorrekturen, aber auch geänderte Standardwerte für Flags mitbringen. Pinne die Version explizit in deiner docker-compose.yml und teste ein Update erst in einer Staging-Umgebung, bevor es die produktive Instanz erreicht, genau wie du es bei jeder anderen Server-Software auch machen würdest.

Schritt 11: Monitoring, Updates und sauberes Herunterfahren

vLLM stellt unter /metrics einen Prometheus-kompatiblen Endpoint bereit, der Kennzahlen wie GPU-Cache-Auslastung, Anfragen pro Sekunde und durchschnittliche Latenz liefert.

curl http://localhost:8000/metrics | grep vllm:num_requests_running

Trage diesen Endpoint in deine bestehende Prometheus-Konfiguration ein, um Dashboards in Grafana zu bauen. Für Updates ziehst du eine neue Image-Version, stoppst den laufenden Container sauber und startest neu, statt den Prozess hart zu killen:

docker compose pull
docker compose down
docker compose up -d

Ein hartes docker kill kann laufende Generierungen abbrechen und im schlechtesten Fall den Hugging-Face-Cache in einem inkonsistenten Zustand hinterlassen. docker compose down gibt vLLM Zeit, aktive Anfragen abzuschließen, bevor der Container stoppt.

Das komplette Projekt: interner Support-Chatbot mit Llama 4 Scout

Mit einer laufenden vLLM-Instanz brauchst du für einen einfachen internen Chatbot nur noch eine schlanke FastAPI-Schicht, die Anfragen entgegennimmt, an vLLM weiterreicht und die Antwort zurückgibt. So sieht ein minimales, aber funktionsfähiges Beispiel aus:

from fastapi import FastAPI
from pydantic import BaseModel
from openai import OpenAI

app = FastAPI()
client = OpenAI(base_url="http://localhost:8000/v1", api_key="leer")

class Frage(BaseModel):
    text: str

@app.post("/chat")
def chat(frage: Frage):
    antwort = client.chat.completions.create(
        model="meta-llama/Llama-4-Scout-17B-16E-Instruct",
        messages=[
            {"role": "system", "content": "Du bist der interne Support-Assistent."},
            {"role": "user", "content": frage.text},
        ],
    )
    return {"antwort": antwort.choices[0].message.content}

Starte diese Datei mit uvicorn main:app --port 8080, und dein Team kann über POST /chat mit dem selbst gehosteten Modell sprechen, ohne dass eine einzige Anfrage das eigene Netzwerk verlässt. Erweitere das Grundgerüst nach Bedarf um Authentifizierung, Rate-Limiting und ein Frontend, etwa mit Open WebUI, das sich ebenfalls gegen die vLLM-API konfigurieren lässt.

Für ein produktivtaugliches Projekt fehlen an diesem Grundgerüst noch drei Dinge. Erstens ein Gesprächsverlauf: Aktuell verarbeitet die Route jede Anfrage isoliert, ein echter Chatbot muss die letzten Nachrichten mitschicken, damit das Modell den Kontext behält. Zweitens Streaming: Die OpenAI-Bibliothek unterstützt stream=True, wodurch die Antwort Token für Token beim Nutzer ankommt, statt erst nach vollständiger Generierung, was die gefühlte Wartezeit bei langen Antworten deutlich senkt. Drittens strukturiertes Logging jeder Anfrage und Antwort, idealerweise in dieselbe Beobachtungsinfrastruktur, die du auch für die Prometheus-Metriken aus Schritt 11 nutzt. Mit diesen drei Ergänzungen wird aus dem Minimalbeispiel eine Grundlage, die sich tatsächlich an ein Team ausrollen lässt.

Hardware und Kosten: was Self-Hosting wirklich kostet

Die Rechnung lohnt sich vor allem bei konstanter Auslastung. Bei sporadischer Nutzung bleibt eine API oft günstiger, weil du für ungenutzte GPU-Zeit trotzdem zahlst.

Setup	Typische Kosten	Am besten geeignet für
Gemietete H100 (Cloud, stundenweise)	Mehrere US-Dollar pro Stunde, anbieterabhängig	Tests, Proof of Concept, Lastspitzen
Eigene H100 (gekauft)	Hoher fünfstelliger Betrag pro Karte	Dauerbetrieb mit hoher, planbarer Auslastung
Gehostete Llama-4-API eines Drittanbieters	Abrechnung pro Million Tokens	Geringe bis mittlere, unregelmäßige Last
Eigene A100 80GB (gebraucht/Cloud)	Günstiger als H100, geringerer Durchsatz	Kleinere Teams mit Kostenfokus

Wer unsicher ist, sollte mit einer gemieteten Instanz starten, echte Nutzungsdaten sammeln und erst danach über einen Kauf eigener Hardware entscheiden. Ein Monat gemieteter GPU-Zeit kostet fast immer weniger als eine Fehlinvestition in überdimensionierte Hardware.

Neben der reinen GPU-Miete oder dem Kaufpreis solltest du drei versteckte Kostenpunkte einplanen. Netzwerk-Traffic wird bei manchen Cloud-Anbietern separat abgerechnet und kann bei häufigem Modell-Download über mehrere zehn Gigabyte pro Neustart spürbar ins Gewicht fallen, wenn der Cache nicht persistent gemountet ist. Speicherplatz für mehrere Modellversionen summiert sich schnell, da du beim Testen eines Updates oft die alte und neue Version parallel vorhalten willst. Und der Betriebsaufwand für Monitoring, Updates und Incident-Response ist Personalzeit, die bei einer reinen API komplett entfällt. Rechne diese drei Punkte in deinen Vergleich mit ein, bevor du eine Kostenentscheidung triffst, die nur den GPU-Stundenpreis berücksichtigt.

Llama 4 mit vLLM vs. Ollama vs. LM Studio: welches Setup passt zu dir

Die drei Wege führen zu unterschiedlichen Ergebnissen, je nachdem, was du vorhast. Unser Tutorial zu DeepSeek V4 Flash mit Ollama und unser Guide zu LM Studio mit Kimi K3 zeigen die beiden Alternativen im Detail.

Kriterium	vLLM	Ollama	LM Studio
Zielgruppe	Produktion, viele parallele Nutzer	Einzelnutzer, schneller Test	Einzelnutzer mit grafischer Oberfläche
API-Format	OpenAI-kompatibel	Eigenes REST-Format plus OpenAI-Modus	OpenAI-kompatibel
Paralleler Durchsatz	Hoch (kontinuierliches Batching)	Niedrig	Niedrig
Einrichtungsaufwand	Mittel bis hoch (Docker, GPU-Treiber)	Sehr gering	Sehr gering
Läuft ohne dedizierte GPU	Nein	Ja (langsamer)	Ja (langsamer)

Für einen ersten Test auf dem eigenen Laptop bleibt Ollama unschlagbar einfach. Sobald mehrere Nutzer gleichzeitig anfragen oder du eine Produktionslast bedienst, holt vLLM den Vorsprung durch Durchsatz wieder rein.

Ein typischer Weg vieler Teams: Zuerst Ollama auf dem eigenen Rechner nutzen, um zu prüfen, ob Llama 4 Scout die inhaltlichen Anforderungen überhaupt erfüllt, ohne Cloud-Kosten oder Docker-Aufwand. Erst wenn diese erste Prüfung positiv ausfällt und klar wird, dass mehrere Personen gleichzeitig zugreifen sollen, folgt der Umzug auf vLLM mit dedizierter GPU. Dieser zweistufige Ansatz spart Geld in der Experimentierphase und stellt sicher, dass du die aufwendigere vLLM-Infrastruktur nur für Projekte aufsetzt, die den Betrieb auch tatsächlich rechtfertigen. Da beide Engines dieselbe Hugging-Face-Modell-ID und ein OpenAI-kompatibles API-Format nutzen, bleibt der Anwendungscode beim Wechsel weitgehend unverändert.

Häufige Fehler beim Self-Hosting von Llama 4

Diese sechs Fehler tauchen in den meisten Setups früher oder später auf. Kennst du sie vorher, sparst du dir die Fehlersuche.

• Volles Kontextfenster ohne genug VRAM anfordern. Wer --max-model-len nahe am theoretischen Maximum von 10 Millionen Tokens setzt, sprengt den Key-Value-Cache selbst auf einer H100. Starte klein und erhöhe schrittweise.
• Falsche Anzahl GPUs für –tensor-parallel-size. Steht der Wert auf 2, aber nur eine GPU ist sichtbar, bricht vLLM beim Start mit einem Rank-Fehler ab, statt automatisch auf eine GPU zu reduzieren.
• Hugging-Face-Lizenz nicht akzeptiert. Der Download bricht mit einem 403-Fehler ab, wenn du die Llama 4 Community License auf der Modellseite übersprungen hast, selbst mit gültigem Token.
• Shared Memory zu knapp bemessen. Ohne --shm-size nutzt Docker einen Standardwert von 64 MB, der beim Laden großer MoE-Modelle sofort überläuft.
• Kein API-Key bei öffentlich erreichbarem Port. Ein offener Port 8000 ohne --api-key erlaubt jedem im Netzwerk kostenlose Inferenz auf deine Rechnung.
• Veraltete NVIDIA-Treiber. vLLMs Docker-Image basiert auf aktuellem CUDA. Ein zu alter Host-Treiber führt zu kryptischen Kernel-Fehlern statt einer klaren Versionsmeldung.
• Cache-Verzeichnis nicht persistent gemountet. Fehlt der Volume-Mount auf ~/.cache/huggingface, lädt vLLM bei jedem Neustart die kompletten Modellgewichte erneut herunter, was zehn bis dreißig Minuten zusätzliche Wartezeit pro Neustart bedeutet.
• Ein Modell für alle Aufgaben nutzen wollen. Scout ist ein Allrounder, aber für hochspezialisierte Aufgaben wie Klassifikation oder Embedding-Suche lohnt sich oft ein kleineres, dediziertes Modell neben Llama 4, statt alles über einen einzigen 17-Milliarden-Parameter-Pfad zu jagen.

Fehlerbehebung: die häufigsten Probleme

Diese acht Situationen begegnen dir mit hoher Wahrscheinlichkeit während oder nach der Einrichtung.

• “CUDA out of memory” beim Start. Reduziere --gpu-memory-utilization auf 0.8 oder senke --max-model-len, bis der Ladevorgang durchläuft.
• “could not select device driver” beim docker run. Das NVIDIA Container Toolkit fehlt oder Docker wurde nach der Konfiguration nicht neu gestartet.
• Download bricht mit 403 Forbidden ab. Prüfe auf der Hugging-Face-Modellseite, ob dein Account die Lizenz akzeptiert hat und der Token Leserechte besitzt.
• Container startet, API antwortet aber nicht. Warte auf die Log-Zeile “Application startup complete”, das Modell lädt beim ersten Start oft noch mehrere Minuten im Hintergrund.
• “Bus error” während des Ladevorgangs. Erhöhe --shm-size im docker run-Befehl oder im Compose-File auf mindestens 16 GB.
• Sehr langsame Antwortzeiten trotz H100. Prüfe mit nvidia-smi, ob eine andere Anwendung bereits VRAM belegt, oder ob --quantization versehentlich fehlt.
• “Address already in use” auf Port 8000. Ein alter, nicht sauber gestoppter Container blockiert den Port noch. Prüfe mit docker ps und stoppe ihn mit docker stop.
• Antworten brechen mitten im Satz ab. Der Client-seitige max_tokens-Wert in der Chat-Anfrage ist zu niedrig gesetzt, nicht das Server-Limit.
• Modell lädt, aber Antworten wirken inkohärent. Prüfe, ob versehentlich das Base-Modell statt der Instruct-Variante geladen wurde. meta-llama/Llama-4-Scout-17B-16E-Instruct ist für Chat trainiert, die Basisversion ohne Instruct-Suffix nicht.
• Docker-Compose-Start schlägt mit Capabilities-Fehler fehl. Ältere Docker-Compose-Versionen unterstützen den deploy.resources-Block für GPUs nicht vollständig. Aktualisiere Docker Compose auf die aktuelle Version oder nutze ersatzweise das --gpus all-Flag über docker run.

Erweiterte Tipps für den Produktivbetrieb

Sobald der Grundbetrieb steht, lohnen sich ein paar Optimierungen, die viele Teams erst nach den ersten Produktionsproblemen entdecken. Aktiviere Prefix-Caching, wenn viele Anfragen denselben System-Prompt teilen, etwa bei einem Support-Chatbot mit fester Rollenbeschreibung. vLLM cached dann den gemeinsamen Anfangsteil und muss ihn nicht bei jeder Anfrage neu verarbeiten, was spürbar Latenz spart. Gerade bei einem Chatbot mit einem längeren, sorgfältig formulierten System-Prompt, der Ton, Zuständigkeiten und Grenzen des Assistenten festlegt, macht dieser Cache oft den Unterschied zwischen einer Antwortzeit von wenigen hundert Millisekunden und mehreren Sekunden Verzögerung bei jeder einzelnen Nachricht.

Für mehrere Modelle auf einer Maschine, etwa Scout für Chat und ein kleineres Modell für Klassifikation, lohnt sich ein separater vLLM-Container pro Modell mit eigenem Port, statt beide in einem Prozess zu mischen. Das hält Speicherverwaltung und Fehlerisolation sauber. Wer mehr als eine GPU besitzt, sollte --tensor-parallel-size testen. Bei Scout verteilt sich das Modell dann über beide Karten, und der maximale Kontext sowie die Batch-Größe steigen deutlich. Setze außerdem regelmäßige Backups des Hugging-Face-Caches auf, damit ein Server-Ausfall nicht erneut einen 90-Minuten-Download erzwingt.

Skalierung auf mehrere GPUs und mehrere Nutzer

Ein einzelner vLLM-Container auf einer GPU trägt einen Team-Chatbot mit ein paar Dutzend Nutzern meist problemlos. Wächst die Last darüber hinaus, gibt es zwei Stellschrauben, bevor du in zusätzliche Hardware investierst. Die erste ist --max-num-seqs gemeinsam mit --gpu-memory-utilization: Beide zusammen bestimmen, wie viele parallele Konversationen die GPU gleichzeitig im Speicher halten kann, bevor neue Anfragen in die Warteschlange müssen. Miss die tatsächliche durchschnittliche Antwortlänge deiner Nutzer und rechne von dort rückwärts, statt die Werte zu raten.

Reicht eine GPU nicht mehr aus, verteilt --tensor-parallel-size das Modell über mehrere Karten im selben Host. Für noch größere Lasten unterstützt vLLM zusätzlich Pipeline-Parallelismus über mehrere Server hinweg, was allerdings eine schnelle Netzwerkverbindung zwischen den Maschinen voraussetzt, meist NVLink oder InfiniBand, da sonst die Kommunikation zwischen den GPUs zum Flaschenhals wird. Für die meisten DACH-Unternehmen mit einem internen Chatbot oder einer Support-Anwendung reicht die Kombination aus einer oder zwei H100-Karten und sauber konfiguriertem Batching aus, bevor eine mehrstufige Cluster-Architektur überhaupt nötig wird. Miss zuerst, skaliere danach.

Ein einfacher Indikator dafür, wann eine zweite GPU fällig ist: Steigt die durchschnittliche Wartezeit in der vLLM-Warteschlange, sichtbar über die Prometheus-Metrik vllm:num_requests_waiting, über mehrere Tage hinweg konstant an, statt nur bei kurzen Lastspitzen, ist das ein klareres Signal als eine reine CPU- oder GPU-Auslastungsanzeige. Kurzfristige Spitzen fängt ein gut konfigurierter Batch problemlos ab, ein dauerhafter Rückstau dagegen bedeutet, dass die aktuelle Hardware die Grundlast nicht mehr trägt.

Häufig gestellte Fragen

Ist Llama 4 kostenlos nutzbar?
Ja, unter der Llama 4 Community License, solange dein Unternehmen unter 700 Millionen monatlich aktiven Nutzern liegt. Details stehen in der offiziellen Lizenz von Meta.

Läuft Llama 4 Scout auf einer Consumer-GPU wie einer RTX 4090?
Nur mit starker Quantisierung und deutlich reduziertem Kontextfenster. Für ernsthaften Betrieb empfiehlt sich mindestens eine A100 oder H100 mit 80 GB VRAM.

Ist vLLM schneller als Ollama?
Bei einer einzelnen Anfrage kaum spürbar. Bei vielen parallelen Anfragen zieht vLLM durch kontinuierliches Batching klar davon, weil Ollama Anfragen eher sequenziell abarbeitet.

Brauche ich zwingend eine NVIDIA-GPU?
Für dieses Tutorial ja. vLLM unterstützt zusätzlich AMD-ROCm- und Intel-XPU-Images, die Einrichtung unterscheidet sich dann aber in Details.

Ist der Betrieb von Llama 4 in Deutschland DSGVO-konform möglich?
Self-Hosting auf eigener oder EU-gehosteter Infrastruktur gibt dir volle Kontrolle über den Verarbeitungsort, was die DSGVO-Compliance im Vergleich zu US-APIs deutlich vereinfacht. Die konkrete Bewertung hängt von deinem Anwendungsfall und den verarbeiteten Daten ab.

Was kostet der Wechsel von Scout auf Maverick später?
Technisch nur eine Änderung des --model-Parameters, praktisch aber deutlich mehr Hardware: Maverick braucht wegen der 400 Milliarden Gesamtparameter typischerweise einen kompletten Multi-GPU-Host statt einer einzelnen Karte.

Kann ich Llama 4 Scout mit eigenen Daten feintunen?
Ja. Unser Tutorial zu LLM-Fine-Tuning mit LoRA nutzt Llama-4-Modelle direkt als Beispiel und zeigt den Ablauf Schritt für Schritt.

Warum entscheidet sich Meta gegen ein offenes Nachfolgemodell?
Berichten zufolge hat Meta mit Muse Spark im April 2026 auf ein geschlossenes, kostenpflichtiges Modell umgeschwenkt und dabei erklärt, dass es keine offene Llama-5-Generation geben wird. Für bestehende Llama-4-Nutzer ändert sich dadurch an der Lizenz und Verfügbarkeit von Scout und Maverick zunächst nichts.

Lohnt sich vLLM auch für ein kleines Team mit wenigen Anfragen pro Tag?
Eher nicht. Der Einrichtungsaufwand mit Docker, GPU-Treibern und Tuning lohnt sich erst ab einer gewissen, kontinuierlichen Last. Bei sporadischer Nutzung ist Ollama oder eine gehostete API meist die günstigere und schneller eingerichtete Lösung.

Related Coverage

• DeepSeek V4 Flash mit Ollama: 12 Schritte, 45 Min [2026]
• LLM Fine-Tuning mit LoRA: 12 Schritte, 60 Min [2026]
• LM Studio + Kimi K3: Hybrid-KI in 12 Schritten [2026]
• Prompt Injection Schutz: 12 Schritte, 90 Min [2026]
• Gemini 3.7 Flash API: 12 Schritte, 45 Min [2026]
• Claude Opus 5 top KI-Rangliste: 1846 Elo vor GPT-5.6 [2026]

Weitere Tutorials und Einordnungen rund um KI-Modelle findest du in unserer Rubrik KI & Machine Learning.

Quellen und weiterführende Dokumentation: vLLM-Dokumentation, Metas offizielle Llama-4-Ankündigung, Llama-4-Scout auf Hugging Face, vLLM auf GitHub und die Llama 4 Community License.