đŸ› ïž Infrastructure & Deployment

Fokus: Die technische Grundlage und Hardware.

LLM Performance Hub

LLM-Performance ist ein Systemproblem, kein GPU-Einkaufsproblem. Ob man ein einzelnes Modell auf einer lokalen Workstation betreibt oder einen Multi-Modell-Kubernetes-Cluster verwaltet — Inferenzgeschwindigkeit, Latenz und Effizienz werden durch das Zusammenspiel des gesamten Stacks bestimmt:

Diese Seite ist meine persönliche Referenz dafĂŒr, wie sich LLMs unter realen Workloads verhalten und wie man sie gezielt optimiert. Der Fokus liegt auf selbst gehosteten und On-Premise-Deployments — nicht auf verwalteter Cloud-Inferenz.

Was LLM-Performance wirklich bedeutet

Performance ist keine einzelne Zahl. Zwei Systeme können identischen Durchsatz haben und trotzdem ein völlig unterschiedliches Nutzererlebnis liefern, je nachdem wie die Latenz verteilt ist.

Throughput vs. Latenz

Ein System, das rein auf Durchsatz optimiert ist, kann sich im interaktiven Betrieb trĂ€ge anfĂŒhlen. Die richtige Balance hĂ€ngt vom Anwendungsfall ab.

Wo der Flaschenhals ĂŒblicherweise sitzt

EngpĂ€sse treten in einer recht vorhersehbaren Reihenfolge auf. Den richtigen Layer zu identifizieren ist wertvoller als blind Hardware aufzurĂŒsten:

  1. VRAM-KapazitĂ€t — Passt das Modell ĂŒberhaupt? Wenn nicht, hat man schon verloren.
  2. Speicherbandbreite — Wie schnell können Gewichte pro Token in die Recheneinheiten gelesen werden?
  3. Runtime-Scheduling — Wie effizient queued und batched der Serving-Layer Requests?
  4. KV-Cache-Druck — Lange Kontexte fĂŒllen den VRAM schnell; Cache-Eviction ist teuer.
  5. CPU/Treiber-Overhead — Oft ĂŒbersehen, immer vorhanden sobald ParallelitĂ€t ins Spiel kommt.

Inference-Runtimes und lokales Tooling

Meine Setups unterscheiden sich zwischen Arbeit und Zuhause — Benchmarks und Beobachtungen sind daher immer einem konkreten Kontext zugeordnet.

Arbeit — Kubernetes-Cluster (Quadro RTX 6000 Ada, 24 GB VRAM)

Im Arbeitsumfeld laufen llama.cpp-Instanzen in Kubernetes-Pods, ein Modell pro GPU, mit LiteLLM als einheitlichem API-Proxy und Open WebUI fĂŒr den Teamzugang. Produktiv im Einsatz: Gemma 4 26B und Qwen3-Coder 30B.

Zuhause — Eigene Workstation (RTX 5070, 12 GB VRAM)

Zu Hause ist der Toolstack experimenteller: llama.cpp fĂŒr die rohe Inferenz, Jan.ai und LM Studio als lokale Frontends, OpenCode fĂŒr KI-gestĂŒtzte Entwicklungsworkflows. Die 12-GB-Grenze ist real — Quantisierungsentscheidungen wiegen hier deutlich schwerer als auf der Arbeit.

Hardware-Grenzen, die wirklich zÀhlen

Rohe GPU-Rechenleistung ist selten der limitierende Faktor. Systemarchitektur — PCIe-Bandbreite, VRAM-KapazitĂ€t, Speicherbandbreite — bestimmt, was ĂŒberhaupt möglich ist, bevor man auch nur eine Modelldatei anfasst. Die beiden Setups, mit denen ich tĂ€glich arbeite, reprĂ€sentieren zwei sehr unterschiedliche Constraint-Profile: 24 GB auf der Arbeit (Server-GPU, ECC, gute Bandbreite) und 12 GB zu Hause (Consumer-GPU, schneller pro Core, engeres VRAM-Budget).

Benchmarks & Modellvergleiche

Benchmarks sind nur dann nĂŒtzlich, wenn sie eine konkrete Frage beantworten. Leaderboard- Scores ohne Workload-Kontext sind Rauschen.

Arbeit — Quadro RTX 6000 Ada (24 GB VRAM)

Der Arbeitscluster betreibt Gemma 4 26B und Qwen3-Coder 30B produktiv. Bei 24 GB geht es nicht nur darum, ob das Modell passt — sondern wie viel Kontext-Headroom nach dem Laden der Gewichte noch ĂŒbrig bleibt und wie sich das Modell unter realer gleichzeitiger Teamnutzung schlĂ€gt.

Zuhause — RTX 5070 (12 GB VRAM)

12 GB sind eine echte EinschrĂ€nkung. Die meisten interessanten Modelle brauchen aggressive Quantisierung, und das KV-Cache-Budget schrumpft bei lĂ€ngeren Kontexten schnell. Der Vorteil: Die RTX 5070 hat fĂŒr ihre Klasse eine hervorragende Speicherbandbreite, und die interaktive Single-User-Latenz ist sehr gut.

Modellgeschwindigkeit & QualitÀt

Spezialisierte Tests

Inferenz-Optimierung

Techniken, die Latenz reduzieren oder den Durchsatz verbessern, ohne die AusgabequalitÀt zu beeintrÀchtigen.

Optimierungs-Playbook

Tuning funktioniert am besten als inkrementeller Prozess. Jeder Schritt sollte validiert werden, bevor man zum nĂ€chsten ĂŒbergeht.

Schritt 1: Modell zum Laufen bringen

Schritt 2: Latenz stabilisieren

Schritt 3: Durchsatz steigern

FĂŒr Hosting-Strategie und Infrastrukturentscheidungen: LLM Hosting in 2026: Local, Self-Hosted and Cloud Infrastructure Compared.

HĂ€ufige Fragen

Warum ist mein LLM langsam, obwohl ich eine leistungsstarke GPU habe? Meistens liegt es an der Speicherbandbreite. LLM-Dekodierung ist speicherbegrenzt — die GPU wartet öfter auf ankommende Gewichte als dass sie wirklich rechnet. Quantisierung hilft, weil sie die Datenmenge reduziert, die pro Token bewegt werden muss.

Was ist wichtiger — VRAM-GrĂ¶ĂŸe oder GPU-Modell? VRAM-KapazitĂ€t kommt zuerst. Wenn Modell oder KV-Cache nicht in den VRAM passen, bricht die Performance in dem Moment zusammen, in dem der Runtime anfĂ€ngt auf System-RAM auszulagern. Jenseits des reinen Fits ist dann die Speicherbandbreite entscheidend.

Warum verschlechtert sich die Performance, wenn mehr Nutzer gleichzeitig arbeiten? Request-Queuing, KV-Cache-Contention und Scheduler-SÀttigung verstÀrken sich gegenseitig. Jeder zusÀtzliche parallele Request verbraucht VRAM und Speicherbandbreite, auf die alle anderen Sessions ebenfalls angewiesen sind. Die Degradationskurve ist selten linear.

Fazit

LLM-Performance-Optimierung folgt vorhersehbaren Prinzipien, sobald man die Engpass-Hierarchie verstanden hat. Die Hardware spielt eine weit kleinere Rolle als das korrekte Identifizieren des tatsÀchlich limitierenden Layers.

Erst messen → Engpass identifizieren → diesen Layer beheben → wiederholen.

LLM Hosting in 2026: Local, Self-Hosted und Cloud-Infrastruktur Vergleich

LLM Hosting — Übersicht und Entscheidungshilfe

Large Language Models laufen lĂ€ngst nicht mehr nur in der Cloud. 2026 ist die Frage nicht mehr "Kann ich ein LLM selbst betreiben?" — sondern:

Welche Hosting-Strategie passt zu meinem Workload, meinem Budget und meinen Anforderungen an Kontrolle und Datenschutz?

Diese Seite ist meine persönliche Referenz. Ich dokumentiere hier, was ich tatsĂ€chlich betreibe und getestet habe — keine vollstĂ€ndige MarktĂŒbersicht, sondern ehrliche Erfahrungswerte aus zwei verschiedenen Kontexten: dem Arbeitsumfeld (Kubernetes-Cluster, Team-Betrieb) und dem Home-Lab (Workstation, Einzelnutzer).

Was LLM Hosting eigentlich bedeutet

LLM Hosting beschreibt, wie und wo Modelle fĂŒr Inferenz betrieben werden. Diese Entscheidung hat direkte Auswirkungen auf:

LLM Hosting ist keine reine Installationsaufgabe — es ist eine Infrastrukturentscheidung.

Entscheidungsmatrix

Ansatz Geeignet fĂŒr Hardware Produktionstauglich Kontrolle
llama.cpp GGUF-Modelle, CLI + Server, Offline CPU / GPU Ja (llama-server) Sehr hoch
vLLM Hochdurchsatz-Produktion Dedizierter GPU-Server Ja Hoch
Jan.ai Lokale Experimente, Einzelnutzer Consumer GPU / CPU Begrenzt Hoch
LM Studio Lokale Experimente, Parameter-Tuning Consumer GPU / CPU Begrenzt Hoch
LiteLLM Proxy-Layer, Multi-Backend, API-Unified Keiner (nur Proxy) Ja Hoch
Open WebUI Team-Frontend fĂŒr lokale Modelle Keiner (nur Frontend) Ja Hoch

Nur noch selten in Benutzung

Ansatz Geeignet fĂŒr Hardware Produktionstauglich Kontrolle
Ollama Schneller Einstieg, minimale Konfiguration Consumer GPU / CPU EingeschrÀnkt Hoch
Cloud-Anbieter Zero-Ops, Skalierung ohne Hardware Keiner (remote) Ja Gering

Lokales LLM Hosting

Lokales Hosting bringt:

Die Kehrseite: Hardware-Grenzen, Wartungsaufwand und manuelle Skalierung.

llama.cpp

llama.cpp ist mein primĂ€res Inference-Backend — sowohl auf der Arbeit als auch zu Hause. Es ist eine schlanke C/C++-Engine fĂŒr GGUF-Modelle mit sehr feingranularer Kontrolle ĂŒber Speicher, Threads, KontextgrĂ¶ĂŸe und Quantisierung.

Ich nutze llama.cpp wenn:

Arbeit: llama.cpp-Instanzen laufen als Kubernetes-Pods, je ein Modell pro Quadro-RTX-6000-Ada-GPU (24 GB VRAM), hinter LiteLLM als einheitlichem API-Proxy.

Zuhause: llama.cpp direkt auf der RTX 5070 (12 GB VRAM), meistens als Backend fĂŒr Jan.ai oder OpenCode.

LiteLLM

LiteLLM ist kein Inference-Backend — sondern der Proxy-Layer davor. Ein einheitlicher OpenAI-kompatibler Endpunkt, der Requests an verschiedene Backends weiterleitet: llama.cpp-Instanzen, vLLM, externe Cloud-APIs. LiteLLM habe ich hauptsĂ€chlich im Arbeitsumfeld im Einsatz. Private nur eine Instanz fĂŒr Tests und Updates.

Ich nutze LiteLLM wenn:

vLLM

vLLM ist auf Hochdurchsatz-Inferenz ausgelegt — PagedAttention, kontinuierliches Batching, tensor-paralleles Sharding. Ich habe vLLM installiert und getestet, betreibe es aber nicht produktiv, weil llama.cpp + LiteLLM fĂŒr mein Workload-Profil ausreichend ist.

Interessant wird vLLM wenn:

Jan.ai

Jan.ai ist mein primĂ€res lokales Frontend zu Hause — eine plattformĂŒbergreifende App mit eingebautem llama.cpp-Backend, experimenteller MLX-UnterstĂŒtung, ĂŒbersichtlicher Modellverwaltung mit Zugriff auf Huggingface und direktem Zugang zu Inference-Parametern. Gut geeignet fĂŒr Experimente, lokale Assistenten mit MCP-Server UnterstĂŒtzung, Rollenspiel-Prompts (nicht so gut wie SillyTavern) und Modellvergleiche im interaktiven Betrieb.

Ich nutze Jan.ai wenn:

LM Studio

LM Studio ist eine Alternative zu Jan.ai mit Àhnlichem Ansatz: lokale GUI, eingebettetes llama.cpp-Backend, OpenAI-kompatibler lokaler Server. Etwas stÀrker auf Entwickler-Workflows ausgerichtet, mit besserem Prompt-Template-Editor.

Ich nutze LM Studio wenn:

Open WebUI

Open WebUI ist das Team-Frontend im Arbeitsumfeld — eine ChatGPT-Ă€hnliche Web-OberflĂ€che, die hinter LiteLLM auf die llama.cpp-Instanzen zugreift. Kollegen brauchen nichts zu installieren; sie öffnen den Browser.

Ich nutze Open WebUI wenn:

OpenCode

OpenCode ist mein KI-gestĂŒtztes Coding-Werkzeug — ein CLI-Agent, der llama.cpp als Backend nutzt und direkt in den Entwicklungsworkflow integriert ist. Kein Frontend, kein Chat — sondern Codeanalyse, Refactoring und AufgabenausfĂŒhrung im Terminal.

Ollama

Ollama habe ich getestet, betreibe ich aber nicht aktiv. Es ist der einfachste Einstieg in lokale LLMs — gute CLI, automatisches Modell-Pulling, minimale Konfiguration. Die EinschrĂ€nkungen beim Scheduling und die begrenzte Kontrolle ĂŒber Inference-Parameter haben mich zu llama.cpp gefĂŒhrt.

Ollama macht Sinn wenn:

Cloud LLM Hosting

Cloud-Anbieter abstrahieren die Hardware vollstĂ€ndig. Ich nutze Cloud-APIs punktuell — vor allem fĂŒr Modelle, die lokal nicht sinnvoll betreibbar sind (frontier-Modelle wie Claude oder GPT-4-class).

Vorteile:

Nachteile:

Frontends & OberflÀchen

Das Hosting-Backend ist nur ein Teil des Systems. Welches Frontend Nutzer sehen, beeinflusst die Akzeptanz erheblich.

Frontend Kontext Typ
Open WebUI Arbeit, Team Web-App
Jan.ai Zuhause, Einzelnutzer Desktop-App
LM Studio Zuhause, Entwicklung Desktop-App
OpenCode Zuhause, Terminal CLI-Agent

Kosten und Kontrollvergleich

Faktor Lokal Cloud
Anschaffungskosten Hardware Keine
Laufende Kosten Strom Token-Abrechnung
Datenschutz VollstÀndig EingeschrÀnkt
Skalierung Manuell Automatisch
Wartung Selbst Anbieter
Modellkontrolle VollstÀndig EingeschrÀnkt

Wann welcher Ansatz?

llama.cpp wenn maximale Kontrolle und GGUF-Modelle gefragt sind — sowohl fĂŒr Einzelnutzer als auch im Kubernetes-Cluster.

LiteLLM sobald mehrere Backends oder mehrere Nutzer hinter einer einheitlichen API zusammengefasst werden sollen.

vLLM wenn llama.cpp unter Parallellast zum Engpass wird und Durchsatz PrioritÀt hat.

Jan.ai oder LM Studio fĂŒr lokale Experimente mit GUI, ohne CLI-Aufwand.

OpenCode wenn KI direkt in den Coding-Workflow integriert werden soll.

Open WebUI wenn Kollegen ohne technisches Setup Zugang zu lokalen Modellen brauchen.

Cloud wenn frontier-Modelle gefragt sind oder lokale Hardware nicht ausreicht.

HĂ€ufige Fragen

Was ist der einfachste Einstieg in lokale LLMs? Ollama — minimale Konfiguration, sofort lauffĂ€hig. Wer mehr Kontrolle braucht, wechselt zu llama.cpp.

Ist Self-Hosting gĂŒnstiger als Cloud-APIs? Bei hohem, gleichmĂ€ĂŸigem Volumen oft ja — sobald die Hardware amortisiert ist. Bei sporadischer Nutzung rechnet sich Cloud meistens besser.

Kann man LLMs ohne GPU betreiben? Ja, aber die Inferenzgeschwindigkeit ist erheblich eingeschrĂ€nkt. FĂŒr produktiven Betrieb ist eine dedizierte GPU praktisch Pflicht.

Welches Frontend empfehle ich fĂŒr ein Team? Open WebUI — es braucht keine lokale Installation auf den Client-Rechnern und lĂ€sst sich gut hinter einen Reverse-Proxy stellen.

Zur Performance und Optimierung der Inference-Backends: LLM Performance Hub

Drei Rechner, ein Modell — llama.cpp RPC Cluster im Heimnetz

Ich habe drei Rechner zu Hause, die sonst meist im Leerlauf laufen. Die Idee: alle drei per llama.cpp RPC zu einem gemeinsamen VRAM-Pool zusammenschalten und damit Modelle betreiben, die auf einer einzelnen Karte nicht mehr passen. Dieses Dokument beschreibt, wie ich das umgesetzt habe — inklusive der Stellen, an denen es hakelig wurde.

Hardware-Übersicht

Master Node — Windows 11

Worker Node 1 & 2 — Linux (Debian)

Gepoolter VRAM: 12 + 8 + 8 = 28 GB

Was 28 GB VRAM wirklich bedeuten

Bevor man anfĂ€ngt, lohnt sich ein ehrlicher Blick auf die Zahlen. Ein 70B-Modell in Q4_K_M braucht allein fĂŒr die Gewichte rund 43 GB. Das ĂŒbersteigt den Pool deutlich.

Komponente Bedarf (70B Q4_K_M) Gepoolter VRAM Differenz
Modellgewichte ~43 GB 28 GB −15 GB
KV-Cache (8K Kontext) ~5 GB 0 GB −5 GB
KV-Cache (32K Kontext) ~25 GB 0 GB −25 GB

Die fehlenden 15 GB Gewichte landen im System-RAM des Master-Nodes. Der KV-Cache ebenfalls. Das hat Konsequenzen: Die Inferenzgeschwindigkeit liegt realistisch bei 8–12 Tokens pro Sekunde — nicht mehr. Wer schnelle Antworten erwartet, wird enttĂ€uscht sein. FĂŒr experimentelle Zwecke und zum Verstehen der Architektur ist es trotzdem interessant.

Wer in diesem Setup produktiv mit großen Kontexten arbeiten will, kommt an RAG nicht vorbei — kleines Kontextfenster (z.B. 8K) halten, relevante Passagen per Retrieval einbinden, VRAM fĂŒr die Gewichte freihalten.

OS-Wahl fĂŒr die Worker Nodes

Ich habe Debian auf beiden Intel-Maschinen installiert. GrĂŒnde:

Ubuntu funktioniert genauso — der Installationsweg ist nahezu identisch.

Linux Worker Nodes einrichten

Pakete und Build-Toolchain

sudo apt install build-essential g++ cmake git curl libcurl4-openssl-dev pciutils

NVIDIA-Treiber installieren

APT-Quellen um non-free erweitern:

sudo sed -i 's/main/main non-free contrib/g' /etc/apt/sources.list
sudo apt update

Kernel-Header, DKMS und nvidia-detect installieren:

sudo apt install linux-headers-$(uname -r) build-essential dkms nvidia-detect

PrĂŒfen ob die Karte erkannt wird:

nvidia-detect

Wenn ja, Treiber installieren:

sudo apt install nvidia-driver nvidia-kernel-dkms
sudo reboot

Nach dem Neustart verifizieren:

nvidia-smi

CUDA Toolkit

sudo apt install nvidia-cuda-toolkit

Compute Capability der GPU ermitteln — das braucht man beim Build:

nvidia-smi --query-gpu=compute_cap --format=csv

llama.cpp auf den Linux Nodes bauen

Ich kompiliere llama.cpp selbst — einerseits fĂŒr maximale KompatibilitĂ€t, andererseits weil ich wissen will, was da lĂ€uft. Auf dem i5 mit acht parallelen Prozessen dauert der Build ca. 6 Minuten.

Schritt 1: Normaler CUDA-Build

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

Den -j 8-Parameter an die eigene Kernzahl anpassen.

Schritt 2: RPC-fÀhigen Build erstellen

Jetzt nochmal kompilieren, diesmal mit RPC-Support. Das ist ein separater Build-Ordner:

mkdir build-rpc-cuda
cd build-rpc-cuda
cmake .. -DGGML_CUDA=ON -DGGML_RPC=ON
cmake --build . --config Release

Das erzeugt das rpc-server-Binary, das auf den Worker Nodes laufen muss.

llama.cpp auf Windows installieren

Ich habe winget verwendet — unkompliziert und ausreichend fĂŒr den Master-Node:

winget install llama.cpp

Wichtig: Master und Worker mĂŒssen denselben llama.cpp-Stand (Git-Commit) verwenden. Das RPC-Protokoll ist noch in aktiver Entwicklung; Versionsunterschiede fĂŒhren zu AbstĂŒrzen beim Tensor-Laden. Bei winget immer prĂŒfen, welcher Stand installiert wird, und die Linux-Worker ggf. auf denselben Commit zurĂŒcksetzen.

Netzwerk

Kein WLAN. Verteilte Inferenz reagiert sehr empfindlich auf Latenz und Jitter — WLAN macht das Ergebnis unbrauchbar. Gigabit-Ethernet per Kabel ist das absolute Minimum.

Das RPC-Protokoll ĂŒbertrĂ€gt Modell-Tensoren und Hidden States unverschlĂŒsselt. Die Ports (Standard: 50052, ich nutze 21000) dĂŒrfen ausschließlich im lokalen Netz erreichbar sein. Niemals nach außen öffnen.

Firewall auf den Linux-Nodes: den gewĂ€hlten Port fĂŒr die IP des Master-Nodes freigeben, alles andere sperren.

Worker Nodes starten

Auf beiden Linux-Maschinen ins Build-Verzeichnis wechseln und den RPC-Server starten:

./rpc-server --host 0.0.0.0 --port 21000

--host 0.0.0.0 lÀsst den Server auf allen Interfaces lauschen. Das ist nur dann vertretbar, wenn die Firewall den Zugriff auf die IP des Masters beschrÀnkt.

Master Node: Inferenz starten

Der Master orchestriert das Sharding — die Remote-Worker erscheinen als zusĂ€tzliche CUDA-Devices.

Meine Worker laufen auf 192.168.0.91 und 192.168.0.92:

./llama-cli.exe -m llama-3-70b-q4_k_m.gguf \
  --rpc 192.168.0.91:21000,192.168.0.92:21000 \
  --n-gpu-layers 100 \
  --ctx-size 8192

Performance-Flags

Diese Flags bringen messbare Verbesserungen:

Fehlerbehebung

"RPC Failed to Connect" oder Worker meldet "0 MiB free"

Verbindung klappt, aber der Worker meldet keinen freien VRAM:

  1. CUDA-Backend auf dem Worker ist nicht korrekt initialisiert — nvidia-smi prĂŒfen
  2. Falsches CUDA_DOCKER_ARCH beim Build gesetzt
  3. nvidia-cuda-toolkit unvollstÀndig installiert

Absturz beim Tensor-Laden

Fast immer ein Versions-Mismatch. llama.cpp-Version auf Master und Worker angleichen — identischer Git-Commit, nicht nur dieselbe Release-Nummer.

Screenshots

Hier ein paar Aufnahmen aus dem laufenden Betrieb — NVTOP und NVITOP zeigen schön, wie die VRAM-Last auf die Worker verteilt wird.

(Screenshots aus dem Wiki-Upload — siehe Originalartikel)

Fazit

Das Setup lĂ€uft. 70B-Modelle sind auf 28 GB VRAM machbar, aber man muss die Erwartungen kalibrieren: 8–12 TPS, kein großes Kontextfenster, der Master-RAM ist der eigentliche Flaschenhals. FĂŒr das Experimentieren mit Modellen, die sonst gar nicht laufen wĂŒrden, ist es trotzdem ein sinnvolles Setup.

Wer ernsthaft mit großen Kontexten und diesem VRAM-Budget arbeiten will, sollte RAG in Betracht ziehen — kleines Fenster halten, Retrieval macht den Rest.

Lokale Installation und Betrieb von LLMs mit vLLM

vLLM ist ein hochdurchsatzorientiertes Inference-Framework fĂŒr Hugging-Face-Modelle. Im Vergleich zu llama.cpp liegt der Fokus auf kontinuierlichem Batching und PagedAttention — das macht vLLM besonders interessant wenn mehrere Requests gleichzeitig bedient werden sollen. FĂŒr Einzelnutzer im Homelab ist llama.cpp oft die einfachere Wahl; vLLM lohnt sich wenn der Throughput wichtiger ist als unkomplizierte Konfiguration.

Voraussetzungen

CUDA und Treiber prĂŒfen:

nvcc --version
nvidia-smi

System vorbereiten und uv installieren

uv ist ein moderner Python-Paketmanager von Astral — deutlich schneller als pip, zuverlĂ€ssigere Dependency-Resolution, empfehlenswert fĂŒr alle Python-basierten AI-Projekte.

Linux:

sudo apt update && sudo apt upgrade -y
sudo apt install curl
curl -LsSf https://astral.sh/uv/install.sh | sh

Shell neu laden damit uv im PATH liegt:

source ~/.bashrc
# oder
source ~/.zshrc

Windows:

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

vLLM installieren

Eine virtuelle Umgebung anlegen und vLLM darin installieren:

uv venv vllm-env --python 3.12
source vllm-env/bin/activate
uv pip install vllm

Auf Windows:

uv venv vllm-env --python 3.12
vllm-env\Scripts\activate
uv pip install vllm

Die Installation zieht PyTorch mit CUDA-Support automatisch — das sind mehrere GB, also etwas Geduld einplanen.

Installation verifizieren:

python -c "import vllm; print(vllm.__version__)"

Erstes Modell starten

vLLM lÀdt Modelle direkt von Hugging Face. Beim ersten Start wird das Modell heruntergeladen und im Cache gespeichert (~/.cache/huggingface).

Beispiel mit Qwen3 4B (passt gut auf 12 GB VRAM):

vllm serve Qwen/Qwen3-4B-Instruct \
  --host 0.0.0.0 \
  --port 8000

Beispiel mit Gemma 3 12B auf 24 GB VRAM (Arbeitsumgebung):

vllm serve google/gemma-3-12b-it \
  --host 0.0.0.0 \
  --port 8000 \
  --dtype bfloat16

Wenn der Server lĂ€uft, ist die API unter http://localhost:8000 erreichbar und OpenAI-kompatibel — LiteLLM, Open WebUI und andere Clients können direkt damit arbeiten.

API testen

VerfĂŒgbare Modelle anzeigen:

curl http://localhost:8000/v1/models

Chat-Request absetzen:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen3-4B-Instruct",
    "messages": [
      {"role": "user", "content": "Was ist der Unterschied zwischen vLLM und llama.cpp?"}
    ]
  }'

Wichtige Start-Parameter

Parameter Beschreibung Beispiel
--host Bind-Adresse 0.0.0.0 fĂŒr Netzwerkzugriff
--port Port 8000
--max-model-len Maximale KontextlÀnge 8192
--gpu-memory-utilization VRAM-Auslastung (0–1) 0.85
--dtype Datentyp bfloat16 oder float16
--quantization Quantisierungsmethode awq, gptq
--tensor-parallel-size Multi-GPU-ParallelitĂ€t 2 fĂŒr zwei GPUs

--gpu-memory-utilization ist praktisch wenn vLLM zu viel VRAM belegt und OOM wirft. Default ist 0.9 — auf 0.8 oder 0.85 reduzieren wenn andere Prozesse auch VRAM brauchen.

--max-model-len begrenzt den KV-Cache. Bei 12 GB VRAM macht es Sinn, diesen Wert explizit zu setzen:

vllm serve Qwen/Qwen3-4B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.85

Quantisierte Modelle verwenden

Wer auf VRAM-Budget achten muss, nutzt AWQ- oder GPTQ-quantisierte Varianten — die meisten großen Modellreihen haben diese direkt auf Hugging Face:

vllm serve Qwen/Qwen3-7B-Instruct-AWQ \
  --quantization awq \
  --host 0.0.0.0 \
  --port 8000

Als systemd-Service betreiben

FĂŒr dauerhaften Betrieb auf einem Linux-Server:

[Unit]
Description=vLLM Inference Server
After=network.target

[Service]
Type=simple
User=DEIN_USER
WorkingDirectory=/home/DEIN_USER
ExecStart=/home/DEIN_USER/vllm-env/bin/vllm serve Qwen/Qwen3-4B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 8192
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Speichern als /etc/systemd/system/vllm.service, dann:

sudo systemctl daemon-reload
sudo systemctl enable vllm
sudo systemctl start vllm
sudo systemctl status vllm

Fehlerbehebung

CUDA out of memory beim Start --gpu-memory-utilization reduzieren oder --max-model-len kleiner setzen. vLLM reserviert beim Start den gesamten kalkulierten KV-Cache — das ist kein Bug, sondern das Design.

Modell lĂ€dt aber Requests schlagen fehl PrĂŒfen ob der --max-model-len mit der KontextlĂ€nge des Modells kompatibel ist. Manche Modelle haben eine maximale LĂ€nge die vLLM nicht automatisch erkennt.

Langsame erste Anfrage Normal — vLLM kompiliert beim ersten Request CUDA-Kernel. Ab der zweiten Anfrage lĂ€uft es mit voller Geschwindigkeit.

vLLM vs. llama.cpp — wann was?

vLLM llama.cpp
Modellformat Safetensors (HF) GGUF
StÀrke Hoher Durchsatz, ParallelitÀt Feingranulare Kontrolle, Offline
VRAM-Overhead Höher Niedriger
Konfiguration Einfacher fĂŒr HF-Modelle Flexibler fĂŒr GGUF-Ökosystem
Produktionstauglich Ja Ja (llama-server)

FĂŒr meinen Arbeitscluster bleibt llama.cpp die erste Wahl — das GGUF-Ökosystem, die LiteLLM-Integration und der niedrigere VRAM-Overhead passen besser. vLLM kommt ins Spiel wenn ein Modell nur als Safetensors verfĂŒgbar ist oder wenn ich unter echter Parallellast testen will.

llama.cpp — Installation, Betrieb und Konfiguration

llama.cpp ist mein primĂ€res Inference-Backend — sowohl im Arbeitscluster als auch zu Hause. Es ist eine schlanke C/C++-Engine fĂŒr GGUF-Modelle mit sehr direktem Zugang zu allen relevanten Parametern: KontextgrĂ¶ĂŸe, GPU-Layer-Verteilung, Quantisierung, Threading. Kein Python-Stack, kein Framework-Overhead.

Der Einstieg ist etwas steiler als bei Ollama oder Jan.ai, aber die Kontrolle ist es wert sobald man weiß was man tut.

Wann llama.cpp, wann etwas anderes?

Situation Empfehlung
GGUF-Modell, maximale Kontrolle llama.cpp
Schneller Einstieg ohne CLI Jan.ai oder LM Studio
Hugging-Face-Modell (Safetensors) vLLM
Hoher Durchsatz, viele parallele Nutzer vLLM
Team-Frontend ohne lokale Installation Open WebUI + LiteLLM

Modelle beschaffen

llama.cpp arbeitet ausschließlich mit GGUF-Dateien. Die beste Anlaufstelle ist Hugging Face — dort gibt es fĂŒr fast jedes bekannte Modell fertige GGUF-Versionen, meistens von bartowski oder direkt vom Modellhersteller.

Quantisierungsstufen im Überblick:

Quantisierung VRAM-Bedarf (7B) QualitÀt Empfehlung
Q8_0 ~8 GB Sehr gut Wenn VRAM reicht
Q6_K ~6 GB Gut Guter Kompromiss
Q4_K_M ~4.5 GB Akzeptabel Standard fĂŒr knappes VRAM
Q4_K_S ~4 GB Etwas schlechter Nur wenn nötig
Q3_K_M ~3.5 GB SpĂŒrbare Verluste Notlösung

FĂŒr die RTX 5070 (12 GB) passen 7B-Modelle in Q8_0 bequem, 13B-Modelle in Q4_K_M noch gut. FĂŒr die Quadro RTX 6000 Ada (24 GB) sind 30B-Modelle in Q4_K_M oder kleinere Modelle in höherer Quantisierung realistisch.

Modell direkt von Hugging Face laden:

# Mit huggingface-cli (pip install huggingface_hub)
huggingface-cli download bartowski/Qwen3-8B-GGUF \
  Qwen3-8B-Q6_K.gguf \
  --local-dir ./models

Installation

Linux — aus dem Quellcode bauen

Empfohlen fĂŒr maximale KompatibilitĂ€t und aktuelle Features. Auf einem i5 mit 8 parallelen Jobs ca. 6 Minuten Buildzeit.

AbhÀngigkeiten:

sudo apt install build-essential cmake git curl libcurl4-openssl-dev

Bauen mit CUDA-Support:

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

Die fertigen Binaries liegen in build/bin/.

Windows — winget

Der einfachste Weg fĂŒr den Windows-Master-Node:

winget install llama.cpp

Wer eine spezifische Version oder CUDA-optimierte Builds braucht, findet diese als fertige Releases auf der llama.cpp GitHub-Seite.

llama-cli — Interaktiver Betrieb

llama-cli ist das Kommandozeilen-Interface fĂŒr direkte Interaktion mit einem Modell. Gut fĂŒr schnelle Tests, Prompt-Experimente und das Debuggen von Parametern.

Basis-Aufruf:

./build/bin/llama-cli \
  -m ./models/Qwen3-8B-Q6_K.gguf \
  --interactive \
  -ngl 99 \
  --ctx-size 8192

Mit System-Prompt:

./build/bin/llama-cli \
  -m ./models/Qwen3-8B-Q6_K.gguf \
  --interactive \
  -ngl 99 \
  --ctx-size 8192 \
  --system-prompt "Du bist ein hilfreicher Assistent."

Einzelne Ausgabe ohne interaktiven Modus (gut fĂŒr Scripting):

./build/bin/llama-cli \
  -m ./models/Qwen3-8B-Q6_K.gguf \
  -ngl 99 \
  --ctx-size 4096 \
  -p "ErklÀre den Unterschied zwischen TCP und UDP in drei SÀtzen."

llama-server — OpenAI-kompatibler API-Endpunkt

llama-server ist das produktive Backend — startet einen HTTP-Server mit OpenAI-kompatibler API. Damit lassen sich LiteLLM, Open WebUI, OpenCode, Jan.ai und alle anderen OpenAI-kompatiblen Clients direkt anbinden.

Starten:

./build/bin/llama-server \
  -m ./models/Qwen3-8B-Q6_K.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  -ngl 99 \
  --ctx-size 8192

API testen:

# VerfĂŒgbare Modelle
curl http://localhost:8080/v1/models

# Chat-Request
curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3-8b",
    "messages": [
      {"role": "user", "content": "Was ist llama.cpp?"}
    ]
  }'

Wichtige Parameter

GPU und Speicher

Parameter Beschreibung Empfehlung
-ngl / --n-gpu-layers Layer auf der GPU 99 — alles auf GPU
--ctx-size KontextfenstergrĂ¶ĂŸe 8192 als Ausgangswert
--flash-attn Flash Attention aktivieren Immer
--mlock Modell im RAM fixieren Empfohlen

Threading und ParallelitÀt (llama-server)

Parameter Beschreibung Empfehlung
--parallel Parallele Request-Slots 2–4 fĂŒr Einzelnutzer
--threads CPU-Threads fĂŒr Prefill Physische Kerne
--threads-batch Threads fĂŒr Batch-Verarbeitung Wie --threads

Ausgabesteuerung

Parameter Beschreibung
--temp Temperature (0 = deterministisch)
--top-p Nucleus Sampling
--repeat-penalty Wiederholungsstrafe
--seed Reproduzierbare Ausgaben

Ein typischer Produktions-Start fĂŒr den Arbeitscluster (Quadro RTX 6000 Ada, 24 GB):

./build/bin/llama-server \
  -m ./models/Qwen3-Coder-30B-Q4_K_M.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  -ngl 99 \
  --ctx-size 16384 \
  --flash-attn \
  --mlock \
  --parallel 4 \
  --threads 8

FĂŒr die RTX 5070 zu Hause (12 GB) mit einem 8B-Modell:

./build/bin/llama-server \
  -m ./models/Qwen3-8B-Q6_K.gguf \
  --host 127.0.0.1 \
  --port 8080 \
  -ngl 99 \
  --ctx-size 8192 \
  --flash-attn \
  --mlock \
  --parallel 2

Als systemd-Service betreiben

FĂŒr dauerhaften Betrieb auf einem Linux-Server:

[Unit]
Description=llama.cpp Inference Server
After=network.target

[Service]
Type=simple
User=DEIN_USER
WorkingDirectory=/home/DEIN_USER/llama.cpp
ExecStart=/home/DEIN_USER/llama.cpp/build/bin/llama-server \
  -m /home/DEIN_USER/models/Qwen3-8B-Q6_K.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  -ngl 99 \
  --ctx-size 8192 \
  --flash-attn \
  --mlock \
  --parallel 4
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable llamacpp
sudo systemctl start llamacpp
sudo systemctl status llamacpp

Integration mit LiteLLM

Im Arbeitscluster lĂ€uft llama-server hinter LiteLLM als einheitlichem API-Proxy. LiteLLM-Konfiguration fĂŒr einen llama.cpp-Endpunkt:

model_list:
  - model_name: qwen3-coder-30b
    litellm_params:
      model: openai/qwen3-coder-30b
      api_base: http://localhost:8080
      api_key: none

Damit ist das Modell fĂŒr alle LiteLLM-Clients unter qwen3-coder-30b erreichbar, ohne dass sie direkt mit llama-server kommunizieren mĂŒssen.

Fehlerbehebung

Modell startet, aber Inferenz ist sehr langsam PrĂŒfen ob -ngl 99 gesetzt ist und ob nvidia-smi wĂ€hrend der Inferenz VRAM-Auslastung zeigt. Wenn der VRAM bei 0 bleibt, wurde llama.cpp ohne CUDA gebaut.

CUDA-Build schlĂ€gt fehl nvcc --version prĂŒfen — wenn kein NVCC gefunden wird, fehlt das CUDA Toolkit:

sudo apt install nvidia-cuda-toolkit

Out of Memory beim Start Entweder --ctx-size reduzieren oder ein stÀrker quantisiertes Modell verwenden. Mit --verbose starten um die genaue VRAM-Kalkulation zu sehen.

Langsamer Prefill, schneller Decode Normales Verhalten — Prefill ist compute-bound, Decode ist memory-bound. Flash Attention (--flash-attn) verbessert den Prefill messbar.

WeiterfĂŒhrend