llama.cpp und vLLM: Sprachmodelle lokal betreiben

Lokale Sprachmodelle laufen auf eigener Hardware statt über eine Schnittstelle im Internet. Zwei Werkzeugklassen dominieren: llama.cpp für den sparsamen Einzelplatzbetrieb und vLLM für den Serverbetrieb mit vielen gleichzeitigen Anfragen. Dieser Artikel erklärt, was beide tun, wann welches passt und welche Größen die Praxis bestimmen.

Das gemeinsame Problem

Ein Sprachmodell ist im Kern eine große Zahl von Rechenoperationen über viele Milliarden Zahlen (Parameter). Bei jeder Anfrage muss der gesamte Modellbestand gelesen werden. Damit wird die Speicherbandbreite zum Flaschenhals – nicht die Rechenleistung. Genau daraus folgt die zentrale Faustregel:

Geschwindigkeit (Token/s)  ~  Speicherbandbreite (GB/s) / Modellgroesse (GB)\n\n# Beispiele mit einer Bandbreite von 500 GB/s (neuere Grafikkarte)\n#   7B-Modell,  4 Bit:  ~4 GB   ->  ~120 Token/s moeglich\n#  70B-Modell,  4 Bit: ~40 GB   ->   ~12 Token/s moeglich\n#  70B-Modell, FP16:  ~140 GB   ->    ~3 Token/s (und passt meist nicht in den Speicher)

llama.cpp: der Einzelplatz

llama.cpp ist eine in C++ geschriebene Laufzeitumgebung ohne große Abhängigkeiten. Ihr Merkmal ist die breite Hardwareunterstützung: Prozessoren (auch ARM), Grafikkarten verschiedener Hersteller und die geteilte Ausführung über beide (offload in Schichten).

# Modell im GGUF-Format beschaffen, dann starten\n./llama-server -m modelle/qwen2.5-7b-instruct-q4_k_m.gguf \\\n  --host 0.0.0.0 --port 8080 \\\n  --ctx-size 8192 \\\n  --n-gpu-layers 99 \\        # alle Schichten auf die GPU\n  --threads 8 \\\n  --flash-attn\n\n# Direkte Abfrage pruefen\ncurl -s http://localhost:8080/v1/chat/completions \\\n  -H 'Content-Type: application/json' \\\n  -d '{"model":"lokal","messages":[{"role":"user","content":"Hallo"}]}' | jq -r '.choices[0].message.content'\n\n# Reine Textgenerierung ohne Server\n./llama-cli -m modell.gguf -p "Erklaere DNS in zwei Saetzen." -n 128

\n
• GGUF-Dateien enthalten Modellgewichte und Metadaten. Das Format ist die Verteilform für llama.cpp.
\n
• Quantisierung verringert die Größe. Q4_K_M ist der übliche Kompromiss aus Qualität und Speicherbedarf; Q5 und Q8 sind besser, kosten mehr Speicher.
\n
• Offload in Schichten erlaubt es, ein zu großes Modell teilweise auf der Grafikkarte zu rechnen. Es funktioniert, ist aber deutlich langsamer als vollständiger Offload.
\n

vLLM: der Server

vLLM ist auf Durchsatz ausgelegt. Der Kern ist PagedAttention: Der Zwischenspeicher für den Gesprächsverlauf wird in Seiten verwaltet – ähnlich der Speicherverwaltung eines Betriebssystems. Dadurch passt bei gleicher Hardware ein Vielfaches an gleichzeitigen Anfragen in den Speicher, weil kein Speicher durch Verschnitt verloren geht.

# Start im OpenAI-kompatiblen Modus\nvllm serve Qwen/Qwen2.5-7B-Instruct \\\n  --host 0.0.0.0 --port 8000 \\\n  --max-model-len 16384 \\\n  --gpu-memory-utilization 0.90 \\\n  --tensor-parallel-size 1\n\n# Anfragen (die API entspricht der von OpenAI)\ncurl -s http://localhost:8000/v1/chat/completions \\\n  -H 'Content-Type: application/json' \\\n  -d '{"model":"Qwen/Qwen2.5-7B-Instruct","messages":[{"role":"user","content":"Hi"}]}' | jq\n\n# Wichtige Parameter\n#   --max-model-len            max. Kontextlaenge\n#   --gpu-memory-utilization   Anteil des GPU-Speichers fuer den KV-Cache\n#   --tensor-parallel-size     Aufteilung auf mehrere GPUs\n#   --max-num-seqs             gleichzeitige Anfragen begrenzen

Continuous Batching ist der zweite Vorteil: vLLM nimmt neue Anfragen in einen laufenden Durchgang auf, statt zu warten, bis der aktuelle Stapel abgearbeitet ist. Unter Last steigt der Durchsatz dadurch um ein Vielfaches gegenüber einer einfachen Verarbeitung.

Vergleich für die Entscheidung

\n
• llama.cpp: wenig Abhängigkeiten, läuft auf Prozessor und vielen Grafikkarten, gut für einzelne Personen, Testaufbau, eingebettete Systeme. Weniger Durchsatz bei vielen gleichzeitigen Anfragen.
\n
• vLLM: hoher Durchsatz, OpenAI-kompatible Schnittstelle, für Server mit einer oder mehreren Grafikkarten. Braucht mehr Speicher und ist in der Bedienung aufwendiger.
\n
• Alternative: Ollama verpackt llama.cpp in eine bequeme Verwaltung mit Modellverzeichnis – ideal zum Ausprobieren, weniger für Produktionslast.
\n

Speicherbedarf abschätzen

# 1. Modellgewichte\n#    Anzahl Parameter * Bytes je Parameter\n#    7B in FP16  = 7e9 * 2 Byte = 14 GB\n#    7B in 4 Bit = 7e9 * 0,5    =  3,5 GB\n#    Faustregel: 4 Bit entspricht etwa 0,5-0,6 GB je Milliarde Parameter\n\n# 2. Zwischenspeicher fuer den Gespraechsverlauf (KV-Cache)\n#    Er waechst mit Kontextlaenge UND Anzahl gleichzeitiger Anfragen.\n#    7B-Modell, FP16, 8k Kontext: je Anfrage rund 1-2 GB\n#    -> 10 gleichzeitige Anfragen: 10-20 GB zusaetzlich\n\n# 3. Reserven fuer das System: 1-2 GB\n\n# Beispiel Rechnung fuer 7B in 4 Bit auf einer 24-GB-Karte:\n#    Gewichte 4 GB + KV-Cache 16 GB + Reserve 2 GB = 22 GB -> passt\n# Mit 32k Kontext passt nur noch eine kleine Zahl gleichzeitiger Anfragen.

Der KV-Cache ist der Punkt, den man unterschätzt: Er wächst linear mit der Zahl der gleichzeitigen Gespräche. Ein Kontextfenster von 128k klingt beeindruckend, belegt aber bei einem 7B-Modell je Anfrage mehrere Gigabyte – bei zehn gleichzeitigen Anfragen ist der Speicher voll.

Worauf es in der Praxis ankommt

\n
1. Speicherbandbreite vor Rechenleistung. Beim Kauf zählt, wie schnell Daten aus dem Grafikkartenspeicher gelesen werden – nicht die Zahl der Rechenkerne.
\n
2. Quantisierung ist der größte Hebel. Ein Modell in 4 Bit statt 16 Bit braucht ein Viertel des Speichers und läuft ungefähr viermal schneller. Der Qualitätsverlust ist bei modernen Verfahren gering.
\n
3. Das Modell muss in den Speicher passen. Reicht der Grafikkartenspeicher nicht, ist der Betrieb über System-RAM oder Prozessor möglich, aber um Größenordnungen langsamer.
\n
4. Mehrere kleine Anfragen sind der Normalfall. Ein Werkzeug, das viele kurze Anfragen parallel beantwortet, braucht Durchsatz – hier ist vLLM klar im Vorteil. Ein einzelner Gesprächspartner merkt kaum einen Unterschied.
\n
5. Datenschutz als Argument. Ein lokal betriebenes Modell verlässt nie das eigene Netz. Für vertrauliche Daten ist das häufig der ausschlaggebende Grund, unabhängig von der Leistung.
\n

Verwandte Grundlagen: Welche GPU für LLMs?, Quantisierung, Lokale KI vs. Cloud-KI, Inference.