Inferenz-Server einrichten: vLLM, llama.cpp, SGLang

Die Hardware ist da, der Treiber läuft, nvidia-smi zeigt jede Karte an. Jetzt stellt sich die Frage, was die Tokens tatsächlich ausliefert. Die Antwort ist einer von vier oder fünf offenen Serving-Stacks, und die falsche Wahl kostet Sie 2× Durchsatz, 3× Latenz oder drei Tage Fehlersuche. Dieser Artikel wählt ehrlich zwischen ihnen aus und führt die Einrichtung für den Stack vor, mit dem die meisten Kentino-Kunden zuerst starten sollten: vLLM in Docker, mit dem NGC-validierten Image, hinter einem OpenAI-kompatiblen Endpunkt.

Zielgruppe: Wer L02gelesen hat, docker run --gpus all nvidia-smiausführen kann und nun die nächste Ebene darüber braucht.

Die Entscheidungsmatrix

Fünf Stacks, die im Mai 2026 eine Betrachtung wert sind. Alles andere ist entweder ein Wrapper um einen davon oder ein Forschungsprojekt.

Die meinungsstarke Kurzfassung: Wenn Sie unsicher sind, betreiben Sie vLLM im NGC-Container. Ist Ihr Workload stark auf strukturierte Ausgabe oder gemeinsame System-Prompts ausgerichtet, nehmen Sie SGLang. Sitzen Sie an einem Jetson oder einem Entwicklungsrechner mit einer einzelnen 4090, nehmen Sie llama.cpp. Alles andere ist ein Sonderfall.

vLLM ist der Standard – und warum

vLLM (Stand Mai 2026: v0.20+) ist der am häufigsten eingesetzte offene Serving-Stack für Transformer-LLMs und VLMs. Drei Dinge verschaffen ihm den Vorsprung:

1. Continuous Batching – eingehende Anfragen schließen sich beim nächsten Forward-Pass einem laufenden Batch an. Die GPU-Auslastung an einem Endpunkt mit gemischtem Verkehr steigt gegenüber naiv gebatchter HuggingFace-Inferenz von 40% auf 85%+.
2. PagedAttention plus Prefix-Caching – der KV-Cache wird in Blöcken fester Größe verwaltet, wie die Seiten des virtuellen Speichers eines Betriebssystems. Zwei Anfragen mit demselben System-Prompt teilen sich die KV-Blöcke dieses Präfixes. Bei Agenten-Workflows mit 2 KB großen gemeinsamen System-Prompts liegt die Trefferquote des Präfix-Caches bei 80–95%.
3. Kernel, die zuerst für Blackwell entstehen – FlashAttention 3, FP8-Attention, MXFP4-Quantisierung nur der Gewichte und der CUTLASS-basierte Matmul-Pfad adressieren sm_120 (5090, RTX Pro 6000 Blackwell) und sm_100 (B200) nativ.

CUDA 13 ist der Standard für die PyPI-Wheels ab v0.20 und für das Image vllm/vllm-openai:latest selbst. CUDA-12.8-Wheels werden für den sm_120-Fallback weiterhin ausgeliefert.

vLLM installieren: pip oder Docker

Zwei Installationswege. Nehmen Sie Docker, sofern nichts Konkretes dagegen spricht.

Weg A – pip in einem venv (nur für die Entwicklung)

python3.12 -m venv ~/venvs/vllm && source ~/venvs/vllm/bin/activate
pip install --upgrade pip && pip install vllm   # CUDA 13.0 wheels by default

vllm serve meta-llama/Llama-3.3-70B-Instruct-FP8 --tensor-parallel-size 4 --port 8000

Pip funktioniert und ist beim Durchprobieren von Engine-Flags schneller. Es bindet aber auch Python-Interpreter, CUDA-Runtime und die Kompatibilität zwischen Treiber und Runtime an genau eine Host-Konfiguration. Nutzen Sie es für die Entwicklung, nicht für den Produktivbetrieb.

Weg B – Docker mit dem Upstream-Image (Standard für den Produktivbetrieb)

docker run --gpus all --runtime nvidia \
  --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3.3-70B-Instruct-FP8 \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.92 \
  --max-model-len 8192 \
  --enable-prefix-caching

Hinweise, die sich rächen, wenn man sie überspringt:

• --ipc=host ist für Multi-GPU zwingend. Die vLLM-Worker kommunizieren über Shared Memory; der Standard-IPC-Namespace von Docker ist 64 MB groß und fasst die NCCL-Puffer nicht.
• Binden Sie den HuggingFace-Cache ein. Sonst lädt jedes docker run erneut 75 GB an Gewichten herunter.
• Pinnen Sie für den Produktivbetrieb ein Tag: vllm/vllm-openai:v0.20.2 statt :latest.

Das NGC-Image nvcr.io/nvidia/vllm:25.09-py3 bringt CUDA 13.0, einen getesteten vLLM-Build, NCCL und NVIDIAs QA-Stempel mit. Größer (~12 GB), ein bis zwei Monate hinter Upstream. Nehmen Sie es, wenn Sie auf demselben Host auch TensorRT-LLM oder Triton betreiben und überall denselben CUDA-/NCCL-Stack wollen. Ansonsten ist das Image von Docker Hub kleiner, aktueller und gleichwertig.

Die Flags, auf die es wirklich ankommt

vLLM bietet rund zweihundert CLI-Flags. Die meisten sind situationsabhängig. Diese fassen Sie jedes Mal an:

--gpu-memory-utilization ist das am häufigsten justierte Flag. vLLM entscheidet damit, wie viel VRAM nach dem Laden der Gewichte vorab reserviert wird; der Rest wird zum KV-Cache-Pool. Zu niedrig → vorzeitige KV-Verdrängung unter Last. Zu hoch → OOM bei der ersten Anfrage mit langem Kontext. 0.92 ist ein vernünftiger Startwert für eine dedizierte Inferenzmaschine. Auf 0.85 senken, wenn Sie sich die GPU teilen.

Drei konkrete Startbefehle

Das sind die Konfigurationen, die Kentino-Kunden tatsächlich betreiben. Alle setzen CUDA 13.0, Treiber 570+, das Docker-Image und --ipc=host.

Qwen 2.5 72B Instruct INT4 (AWQ) auf 4× RTX Pro 6000 Blackwell

docker run --gpus all --runtime nvidia --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
  vllm/vllm-openai:v0.20.2 \
  --model Qwen/Qwen2.5-72B-Instruct-AWQ \
  --quantization awq \
  --tensor-parallel-size 4 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92 \
  --enable-prefix-caching \
  --max-num-seqs 64 \
  --port 8000

Rund 36 GB Gewichte bei INT4, 4× 96-GB-Karten. Bei TP=4 sieht jede Karte 1/4 des KV-Caches pro Anfrage, sodass 32 K Kontext bei 64 gleichzeitigen Nutzern deutlich im Budget bleiben. Rechnen Sie mit 40–60 tok/s pro Anfrage bei geringer Nebenläufigkeit und insgesamt ~600–900 tok/s bei 32 gleichzeitigen Anfragen.

Llama 3.3 70B Instruct FP8 auf 8× RTX 5090

docker run --gpus all --runtime nvidia --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
  vllm/vllm-openai:v0.20.2 \
  --model meta-llama/Llama-3.3-70B-Instruct-FP8 \
  --quantization fp8 \
  --tensor-parallel-size 4 \
  --pipeline-parallel-size 2 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --max-num-seqs 64 \
  --swap-space 4 \
  --port 8000

Beachten Sie TP=4 × PP=2 statt TP=8. Die 5090 haben je 32 GB; die FP8-Gewichte für 70B liegen bei ~75 GB und damit bequem unter den 128 GB von vier Karten. Die Pipeline-Aufteilung vermeidet den All-Reduce-Aufschlag, den TP=8 über PCIe kosten würde (siehe K03, N03). TP=8 über PCIe skaliert mit Continuous Batching ab einer Nebenläufigkeit von 8 schlechter als TP=4 × PP=2.

Qwen 2.5 VL 32B auf zwei 5090

docker run --gpus all --runtime nvidia --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:v0.20.2 \
  --model Qwen/Qwen2.5-VL-32B-Instruct-AWQ \
  --quantization awq \
  --tensor-parallel-size 2 \
  --max-model-len 16384 \
  --limit-mm-per-prompt '{"image": 4, "video": 0}' \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --port 8000

Zwei 5090, ~20 GB INT4-Gewichte, Platz für Vision-Encoder und KV-Cache. Die 72B-VL-Variante passt nicht auf zwei 5090, auch nicht mit INT4; nehmen Sie dafür 4× 5090 oder eine einzelne Pro 6000. --limit-mm-per-prompt begrenzt die Bilder pro Anfrage – eine einzige Anfrage mit 20 Bildern kann den Vision-Encoder auf einer 5090 ins OOM treiben. Der Endpunkt ist OpenAI-kompatibel (POST /v1/chat/completions mit Bestandteilen vom Typ image_url ).

SGLang – wenn sein Router vLLM schlägt

Das Verkaufsargument von SGLang heißt RadixAttention: Wiederverwendung des Präfix-Caches als Radix-Baum über alle Anfragen hinweg, nicht nur als Abgleich gleicher Blöcke. Bei Workloads, in denen die meisten Anfragen lange System-Prompts teilen, schlägt die Trefferquote den Präfix-Cache von vLLM. Öffentliche Benchmarks zeigen SGLang bei ~16k tok/s gegenüber vLLM mit ~12k tok/s auf H100 für Shared-Prefix-Workloads, mit deutlich größeren Abständen bei strukturierter Ausgabe.

Wo SGLang gewinnt:

• Strukturiertes JSON über xGrammar. Schneller und formattreuer als das Constrained Decoding von vLLM. Für eine API mit JSON-Ausgabe bei Millionen Anfragen zählt das.
• DeepSeek-V3 und andere große MoE-Modelle. Breite Expert-Parallelität und die Trennung von Prefill und Decode kamen früher; bei mehreren Knoten weiterhin vorn.
• Agenten-Workflows mit gemeinsamen System-Prompts. RAG-Endpunkte, Copiloten, 2–4 KB große System-Prompts, die sich die meisten Anfragen teilen.

Wo vLLM gewinnt: Stapelverarbeitung mit jeweils einzigartigen Prompts (der Vorteil von RadixAttention verschwindet), Modellbreite (mehr Architekturen ab Werk) und die Zeit bis zum ersten laufenden Endpunkt.

docker run --gpus all --runtime nvidia --ipc=host \
  -p 30000:30000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  lmsysorg/sglang:latest \
  python3 -m sglang.launch_server \
    --model-path Qwen/Qwen2.5-72B-Instruct-AWQ \
    --quantization awq \
    --tp 4 \
    --port 30000 \
    --host 0.0.0.0

SGLang stellt einen OpenAI-kompatiblen Endpunkt auf einem eigenen Port bereit (standardmäßig 30000). Direkt austauschbar für denselben Client-Code, dazu SGLang-eigene Endpunkte für strukturierte Generierung. Die ehrliche Empfehlung: Probieren Sie zuerst vLLM. Liegt Ihre Shared-Prefix-Trefferquote über ~60% und ist Ihnen die Tail-Latenz wichtig, testen Sie mit SGLang gegen und nehmen Sie den Sieger.

llama.cpp – wenn klein und einzeln gewinnt

llama.cpp ist Inferenz in C++ ohne Python-Runtime, ohne CUDA-Abhängigkeit und mit dem GGUF-Gewichtsformat, das die Quantisierungs-Metadaten in die Datei packt. Es läuft auf CPU, einer einzelnen GPU, Mac der M-Serie, Jetson oder anteilig auf mehreren davon. Tensor-Parallelität wie bei vLLM beherrscht es nicht. Ein Modell, eine Inferenzschleife, schnell.

Wann llama.cpp die richtige Antwort ist:

• Jetson Orin. vLLM ist für Jetson kaum ausgelegt, llama.cpp schon. Für ein Modell an Bord eines Unitree G1 ist das die Standardantwort.
• Entwicklungsrechner mit einer einzelnen 5090 oder 4090. Ein Entwickler beim Ausprobieren, keine Nebenläufigkeit, der schnellste Installationsweg.
• Gemischte Aufteilung auf CPU und GPU. Ein 70B passt nicht auf eine 5090 (32 GB). Mit -ngl 40landen 40 von 80 Schichten auf der GPU, der Rest läuft auf der CPU in einer für einen einzelnen Nutzer akzeptablen Geschwindigkeit.
• Eingebettete Appliance. Kein Docker, kein Ärger mit Treiberversionen, kein Python.

GGUF-Quantisierungsstufen, geordnet nach Größe und Qualität:

Q4_K_M ist der richtige Standard. Q5_K_M, wenn Sie Luft haben. Q8_0 nur, um „kein Quantisierungsverlust“ nachzuweisen. Die i-Quants (IQ4_XS und Verwandte) sind eine Weiterentwicklung von 2025/2026, die einen Versuch wert ist, wenn Sie ein 70B auf eine einzelne 32-GB-Karte quetschen.

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON && cmake --build build --config Release -j

./build/bin/llama-server \
  --model models/qwen2.5-72b-instruct-q4_k_m.gguf \
  --n-gpu-layers 99 --ctx-size 32768 \
  --host 0.0.0.0 --port 8080 --api-key sk-localdev

-ngl 99 lagert so viele Schichten aus, wie hineinpassen. Der Endpunkt ist OpenAI-kompatibel unter :8080/v1/chat/completions. Für Last mit mehreren Nutzern ist das das falsche Werkzeug – dafür nehmen Sie vLLM. Für einen Nutzer an einer 5090 oder einem Jetson ist es das richtige.

TensorRT-LLM und Triton – die schwere Variante

TensorRT-LLM ist NVIDIAs optimierender Compiler für LLM-Inferenz. Er übersetzt ein Modell vorab in eine TensorRT-Engine, verschmilzt Kernel und wählt pro GPU das beste Layout. Typischerweise 10–25% mehr Durchsatz und 15–30% weniger Latenz als vLLM auf derselben Hardware, auf H100/B200 mehr. Der Preis: ein Build-Schritt (Minuten bis Stunden pro Modell- und GPU-Konfiguration), Engines, die nicht über CUDA-, Treiber- und GPU-Generationen hinweg portabel sind, und ein Betriebsaufwand jenseits von docker run.

Triton Inference Server ist die Serving-Schicht für mehrere Modelle, die TensorRT-LLM-Engines (dazu PyTorch, ONNX, TensorFlow, Python und vLLM als Backend) in einem Server hostet. Das Model-Repository-Muster erlaubt es, LLM A, LLM B, ein Vision-Modell, ein ASR-Modell und eine Python-Pipeline hinter einer URL zu laden – mit Versionierung, A/B-Routing und Ensemble-Graphen.

Der Aufwand lohnt sich, wenn: mehrere heterogene Modelle auf einem Server laufen; der Produktivbetrieb über Monate stabil mit derselben Modellauswahl läuft; das letzte Quäntchen p99-Latenz auf Rechenzentrums-GPUs der Hopper- und Blackwell-Klasse herausgeholt werden soll.

Der Aufwand lohnt sich nicht, wenn: Sie Ihr Modell noch suchen (jeder Wechsel bedeutet einen neuen Engine-Build); Sie auf Consumer- oder Workstation-GPUs arbeiten (der Vorsprung von TRT-LLM schrumpft gegenüber H100, und vLLM unterstützt das Modell von nächster Woche sechs Wochen vor TRT-LLM); Sie ein kleines Team ohne Betriebskapazität sind.

NVIDIA NIM – der vorgefertigte Weg

NIM (NVIDIA Inference Microservices) bündelt „Triton + TensorRT-LLM + eine optimale Konfiguration für genau dieses Modell + eine Enterprise-Lizenz“ in einem Container. docker pull nvcr.io/nim/meta/llama-3.3-70b-instruct:latest, einen NGC-Schlüssel setzen, starten – und Sie haben einen getesteten OpenAI-kompatiblen Endpunkt, ohne Quantisierung zu wählen oder Flags zu justieren.

Passt, wenn: Sie NVIDIA AI Enterprise gekauft haben (oder ein Kunde es verlangt); Sie schnellstmöglich einen bewährten Endpunkt wollen (Stunden, nicht Tage); das gewünschte Modell im Katalog steht (Llama, Mistral, Mixtral, Gemma, Nemotron und ein wachsendes Partnerangebot). Seit der GTC 2026 deckt eine kostenlose Stufe bis zu 16 GPUs für Mitglieder des Developer Program ab – genug, um auf den meisten Kentino-Installationen mit einem Server zu evaluieren; prüfen Sie die aktuellen Lizenzbedingungen, bevor Sie darauf setzen.

Passt nicht, wenn: das Modell nicht im Katalog steht (offene Gewichte kommen mit Wochen Verzögerung); Sie feinjustieren wollen (NIM verbirgt die meisten Stellschrauben mit Absicht).

Reverse-Proxy, Authentifizierung, Ratenbegrenzung

Stellen Sie vLLM nicht direkt ins öffentliche Internet. Setzen Sie nginx (oder Caddy oder Traefik) davor. Eine minimale nginx-Konfiguration:

upstream vllm_backend {
    server 127.0.0.1:8000;
    keepalive 32;
}

limit_req_zone $binary_remote_addr zone=vllm:10m rate=20r/s;

server {
    listen 443 ssl http2;
    server_name infer.example.com;

    ssl_certificate     /etc/letsencrypt/live/infer.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/infer.example.com/privkey.pem;

    location /v1/ {
        if ($http_authorization != "Bearer sk-yourlongrandomtoken") {
            return 401;
        }
        limit_req zone=vllm burst=40 nodelay;

        proxy_pass http://vllm_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;             # streaming SSE
        proxy_read_timeout 600s;
        chunked_transfer_encoding on;
    }
}

Drei Punkte, die häufig falsch gemacht werden:

• proxy_buffering off ist für Streaming-Antworten zwingend. Sonst sammeln sich die Tokens im Proxy, und der Client bekommt alles auf einmal.
• proxy_read_timeout steht standardmäßig auf 60s. Lange multimodale Prefills mit 4 tok/s sprengen das. Setzen Sie es auf 5–10 Minuten.
• Der Block if prüft auf exakte Übereinstimmung. Für echte Authentifizierung nehmen Sie Lua, oauth2-proxy oder ein Gateway wie Kong.

Monitoring

Zwei Metrikquellen, zwei Scrape-Ziele.

• Der Endpunkt /metrics von vLLM. Prometheus-kompatibel, auf demselben Port wie die OpenAI-API (:8000/metrics). Veröffentlicht vllm:num_requests_running, vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_seconds, vllm:time_per_output_token_seconds. Die KV-Cache-Auslastung ist die Metrik, die Verdrängung erkennt, bevor sie die Latenz ruiniert.
• DCGM exporter (nvcr.io/nvidia/k8s/dcgm-exporter, Port 9400). Exportiert SM-Auslastung, Speicherauslastung, Leistungsaufnahme, Temperatur, PCIe-Bandbreite und ECC-Zähler der GPU.

Beide nach Prometheus, beide nach Grafana. Erstes Dashboard: laufende Anfragen, KV-Cache-Auslastung, GPU-Auslastung, GPU-Temperatur, P95 TTFT, P95 TPOT. Sättigt die KV-Cache-Auslastung, während die Zahl wartender Anfragen steigt, verdrängen Sie – senken Sie --max-num-seqs, erhöhen Sie --gpu-memory-utilizationoder ergänzen Sie eine Replik.

Die Falle beim Modell-Warmup

Die erste Anfrage an ein frisch gestartetes vLLM ist 5–30× langsamer als im eingeschwungenen Zustand. CUDA-Graphen werden für jede Batch-Form aufgezeichnet, der Präfix-Cache ist leer, der Scheduler kalibriert sich. Setzen Sie beim Start eine kleine Anfrage an /v1/chat/completions ab, bevor Sie den Load Balancer aufschalten; sonst bekommt der erste echte Nutzer nach 15 Sekunden eine Antwort bei einem Modell, das normalerweise in 1 Sekunde antwortet. Bei Blue-Green-Deployments wärmen Sie die neue Replik auf, bevor Sie die alte leeren. Ein ausgelassenes Warmup ist mit Abstand die häufigste Ursache für „das Deployment sah gut aus, aber die Nutzer haben sich zehn Minuten lang beschwert“.

Mehrere Modelle auf einem Server

vLLM ist im Kern ein Server für ein Modell. Drei Optionen, wenn Sie mehrere brauchen:

1. Ein Container pro Modell, unterschiedliche Ports. Jeder hält seinen eigenen VRAM. Ein 70B und ein 7B teilen sich eine Maschine mit 4 GPUs, aufgeteilt über CUDA_VISIBLE_DEVICES und mit passend gesetztem --gpu-memory-utilization. Das Speicherbudget zu planen, ist Ihre Aufgabe.
2. Bei Bedarf laden. Ein Frontend lädt und entlädt, wie die Anfragen eintreffen. Das Laden dauert bei einem 70B 30–120 s; die Latenz beim ersten Treffer ist für interaktive Nutzung nicht akzeptabel. Für den Stapelbetrieb in Ordnung.
3. Das Model-Repository von Triton. Triton verwaltet den Lebenszyklus von N Modellen in einem Server und routet nach Modellnamen. Dorthin wechseln Sie, wenn Option 1 nicht mehr skaliert.

Für die meisten Kentino-Installationen ist Option 1 richtig, bis Sie vier oder mehr Modelle haben – ab dann lohnt sich die Betriebssteuer von Triton.

Die ehrliche Einschätzung

Fünfundneunzig Prozent der Kentino-Kunden sollten mit vllm/vllm-openai in Docker beginnen, hinter nginx, mit einem Modell, mit Prometheus und DCGM-Exporter als Scrape-Quellen – und sich in den ersten drei Monaten nichts anderes ansehen. SGLang verdient seinen Platz bei strukturierter Ausgabe oder bei Agentenverkehr mit gemeinsamem Präfix im großen Maßstab. llama.cpp verdient seinen Platz auf einem Jetson, einem Mac oder einem Einzelplatz-Entwicklungsrechner. Triton und TensorRT-LLM verdienen ihren Platz, wenn Sie über Monate stabilen Produktivbetrieb mit mehreren Modellen haben. NIM verdient seinen Platz, wenn das Modell im Katalog steht und die Lizenz vorliegt.

Der Preis eines zu komplexen Starts ist real. Wir haben Laborinstallationen gesehen, die drei Wochen damit verbracht haben, Triton und TensorRT-LLM dazu zu bringen, ein einzelnes Llama 70B auszuliefern, das vLLM in zwanzig Minuten gehostet hätte. Nehmen Sie zuerst das Einfache. Fügen Sie Komplexität hinzu, wenn Sie belegen können, dass Sie sie brauchen.

---

Dies ist Teil des Kentino Wiki, einer Referenzreihe zu KI-Compute, Robotik und den Systemen, die beides verbinden. Kommentare und Korrekturen willkommen unter info@kentino.com.