LLAMA.CPP · TECH
llama.cpp: die portable C/C++-Inferenz-Bibliothek unter Ollama, LM Studio und KoboldCpp
llama.cpp ist die MIT-lizenzierte Basis-Bibliothek für lokale Sprachmodelle. Läuft auf jeder Plattform – CPU, CUDA, Metal, ROCm, Vulkan. GGUF-Format-Standard.
Recherche & Faktencheck: DuneDive LLC · Stand: 2026-05
Was ist llama.cpp?
llama.cpp ist eine Inferenz-Bibliothek für grosse Sprachmodelle, geschrieben in reinem C/C++ ohne externe Laufzeit-Abhängigkeiten. Gestartet im März 2023 von Georgi Gerganov, ist das Projekt unter MIT-Lizenz auf github.com/ggerganov/llama.cpp veröffentlicht. Mai 2026 hat es über 70.000 GitHub-Sterne, mehr als 1.000 Mitwirkende und gilt als die Referenz-Implementierung für lokale LLM-Inferenz auf heterogener Hardware.
Der wichtigste Punkt über llama.cpp: es ist die Bibliothek unter der Bibliothek. Ollama nutzt llama.cpp als Inferenz-Engine. LM Studio basiert darauf. KoboldCpp ist ein direkter Fork. GPT4All nutzt eine angepasste Variante. Wer einen Komfort-Layer wie Ollama installiert, bekommt llama.cpp implizit mit. Wer maximale Kontrolle über Quantisierung, Kompilierung und Hardware-Hebel will, geht direkt auf llama.cpp.
Die unterstützte Hardware-Bandbreite ist ohne Vergleich im Markt. CPU-Inferenz auf x86-64 (AVX2, AVX512, AMX), ARM (NEON, SVE, Apple Silicon mit AMX-Kernel), POWER und sogar RISC-V. GPU-Beschleunigung über CUDA (NVIDIA), Metal (Apple), ROCm (AMD), Vulkan (vendor-neutral, läuft auch auf Intel Arc und alten AMD-Karten), SYCL (Intel), MUSA (Moore Threads). Stand Mai 2026 unterstützt llama.cpp auch experimentell Qualcomm Hexagon NPU für Smartphone-Inferenz.
Das GGUF-Format (GPT-Generated Unified Format) wurde 2023 vom llama.cpp-Projekt definiert und ist Mai 2026 der De-facto-Standard für quantisierte Open-Weight-Modelle auf Hugging Face. Jedes Modell, das für lokale Nutzung gedacht ist – Llama, Mistral, Qwen, DeepSeek, Apertus, Phi-4 – gibt es in GGUF-Quantisierungen Q2_K, Q3_K_S, Q4_K_M, Q5_K_M, Q6_K, Q8_0 und FP16. Q4_K_M ist der etablierte Sweet-Spot mit höchstens 2-3 Prozent Qualitätsverlust bei einer Datei-Grösse von rund 60 Prozent gegenüber FP16.
Version Mai 2026: b3500+ (das Projekt nutzt fortlaufende Build-Nummern statt Semver). Aktive Entwicklung mit mehreren Releases pro Woche.
Warum llama.cpp für CH-Daten zählt
Vier Gründe machen llama.cpp für Schweizer Datenverarbeitung wichtig – auch wenn die Mehrheit der Buros am Ende Ollama nutzt.
Erstens: Hardware-Unabhängigkeit. llama.cpp läuft auf wirklich jeder Plattform. Ein Treuhand-Büro, das auf einem alten Hetzner-Server ohne GPU eine LLM-basierte Beleg-Klassifikation aufsetzen will, fährt mit llama.cpp besser als mit jeder GPU-zentrierten Lösung. Ein Anwalt mit Mac Mini M2 als persönliche Workstation bekommt über Metal-Beschleunigung produktive Geschwindigkeiten (50-80 Tokens/s bei Llama 3.3 8B in Q4_K_M).
Zweitens: Vorhersagbares Verhalten. llama.cpp kompiliert man selbst – die binäre Datei ist eine einzige selbständige Executable ohne Python-Laufzeit, ohne Docker, ohne externe Bibliotheken. Das ist für Compliance-Audits relevant: was im Code ist, ist auf der Maschine. Keine Surprise-Updates, keine versteckten Telemetrie-Verbindungen. Für Mandanten unter Berufsgeheimnis nach Art. 321 StGB ist diese Transparenz mehr wert als bequeme Auto-Update-Logik.
Drittens: Quantisierungs-Kontrolle. Mit dem llama.cpp-Tool quantize lässt sich ein Original-Modell von Hugging Face (etwa Apertus-70B in FP16) in beliebige Quantisierungen umrechnen – Q2_K für minimalen RAM-Bedarf, Q4_K_M für den Standard-Trade-off, Q8_0 für maximale Präzision auf weniger RAM-effizienter Hardware. Ollama bedient nur ein paar Standard-Varianten; mit llama.cpp pur ist alles möglich.
Viertens: Embedded und Edge. Wer eine LLM-basierte Schadenmeldungs-Triage in einem Schweizer Pharma-Gerät braucht (ohne Internet-Konnektivität), wer ein FINMA-konformes lokales Reasoning-System in einer Bank-Filiale aufstellt oder wer einen rechtsmedizinischen Spital-Server mit lokalem Diagnose-Support ohne Cloud-Verbindung baut, geht direkt auf llama.cpp. Die Footprint-Anforderungen sind hier so streng, dass jeder zusätzliche Layer (Python, Go-Daemon, Docker) ausscheidet.
Fünftens, oft übersehen: GGUF-Format-Wissen ist langlebig. Wer mit llama.cpp arbeitet, lernt das Format und die Quantisierungs-Methodik. Dieses Wissen überlebt jeden Komfort-Layer – wenn Ollama in zwei Jahren überholt ist oder LM Studio die Lizenz ändert, bleibt llama.cpp und das GGUF-Format weiter brauchbar.
Wie llama.cpp technisch funktioniert
llama.cpp besteht aus drei Schichten: einer C-Bibliothek (libllama), einer Reihe von CLI-Werkzeugen und einem HTTP-Server (llama-server).
Build-Beispiel. Auf einem Linux-Server mit NVIDIA-GPU sieht der Bau so aus:
``` git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release cmake --build build --config Release -j 16 ```
Das erzeugt die Werkzeuge in build/bin/: llama-cli (interaktiver Chat), llama-server (OpenAI-kompatibler HTTP-Server), llama-quantize (Quantisierung), llama-bench (Performance-Messung), llama-perplexity (Qualitätsbewertung).
Server-Start. Ein produktiver Server mit Apertus 8B in Q4_K_M-Quantisierung:
``` ./build/bin/llama-server \ -m models/apertus-8b-q4_k_m.gguf \ --host 0.0.0.0 --port 8080 \ --ctx-size 8192 \ --n-gpu-layers 32 \ --api-key sk-fairlane-local ```
Die Schnittstelle ist OpenAI-kompatibel auf POST /v1/chat/completions sowie ein nativer Endpunkt /completion. Das macht llama-server zu einer direkten Alternative zu Ollama, mit dem Unterschied, dass kein Model-Manager mitläuft.
Quantisierung im Detail. Das Tool llama-quantize konvertiert ein Modell aus FP16 in jede Ziel-Quantisierung. Q4_K_M nutzt 4 Bit pro Gewicht mit zusätzlichen 5-6 Bit für Skalierungs-Faktoren in K-Quants – Resultat: ein 8B-Modell schrumpft von 16 GB FP16 auf rund 4,8 GB Q4_K_M. Bei grösseren Modellen (Apertus 70B) ist der absolute Sparbetrag dramatisch: 140 GB FP16 auf 42 GB Q4_K_M.
Hardware-spezifische Builds. Die Kompilier-Flags entscheiden über Performance. GGML_CUDA=ON für NVIDIA, GGML_METAL=ON auf Apple Silicon, GGML_HIPBLAS=ON für AMD ROCm, GGML_VULKAN=ON als vendor-neutrale GPU-Option, GGML_SYCL=ON für Intel Arc. Auf x86-CPUs zählt jede SIMD-Instruktion: GGML_AVX512=ON, GGML_AMX_INT8=ON auf neuesten Intel-Xeon-Generationen.
Tool-Use und Funktions-Aufrufe. llama-server unterstützt Mai 2026 native Tool-Calls für Modelle mit entsprechender Trainings-Vorbereitung (Llama 3.3+, Mistral Small 3.1+, Qwen 3, Apertus 70B-Instruct). Die Schnittstelle entspricht der OpenAI-Spezifikation.
Speculative Decoding. Eine Funktion, die in Ollama nicht direkt verfügbar ist: llama-server kann ein kleines "Draft-Modell" parallel laufen lassen, das Token-Vorschläge macht, die das grosse Modell nur noch verifiziert. Bei passender Modell-Kombination (etwa Apertus 8B als Draft für Apertus 70B) steigt der Durchsatz um 30-60 Prozent ohne Qualitäts-Verlust.
llama.cpp produktiv in 5 Schritten
- 01Build-Umgebung vorbereiten: cmake, C++-Compiler (gcc 12+ oder clang 16+), je nach Hardware CUDA Toolkit / ROCm / Metal / Vulkan-SDK.
- 02Repository klonen und Hardware-spezifisch kompilieren: cmake -B build -DGGML_CUDA=ON oder -DGGML_METAL=ON, dann cmake --build build -j.
- 03Modell besorgen: GGUF-Variante von Hugging Face laden (TheBloke, bartowski oder direktes Modell-Repository wie swiss-ai/Apertus-8B-GGUF), Q4_K_M als Standard.
- 04llama-server starten mit -m Modell, --host 0.0.0.0, --ctx-size passend zum Use-Case (4096 für Chat, 32768 für Dokument-Analyse), --n-gpu-layers maximal möglich.
- 05Systemd-Service einrichten für Auto-Restart, llama-bench zur Performance-Baseline ausführen, Prometheus-Scraper auf den /metrics-Endpunkt setzen.
Wann llama.cpp einsetzen
llama.cpp ist die richtige Wahl, wenn (a) maximale Hardware-Kontrolle gewünscht ist, (b) Embedded- oder Edge-Setups ohne Docker nötig sind, (c) eine spezielle Quantisierung gebraucht wird, oder (d) Mac-Notebook mit Apple Silicon das Ziel-System ist.
Konkrete Fälle: Treuhand-Büro mit einem alten Hetzner-CPU-only-Server, der ohne GPU-Aufrüstung LLM-Klassifikation leisten soll – llama.cpp mit AVX2-Optimierung und einem 7B-Modell in Q4_K_M reicht für 100-500 Klassifikationen pro Stunde. Anwalts-Kanzlei mit Mac Studio M3 Ultra als Power-User-Workstation – llama.cpp mit Metal-Build erreicht 90-130 Tokens/s bei 8B-Modellen und 30-45 Tokens/s bei 70B-Modellen in Q4. Spital-Diagnose-Hilfe ohne Internet – llama.cpp als Single-Binary auf einem Embedded-Linux-Gerät.
Auch für Performance-Tuning ist llama.cpp wichtig: wer Ollama-Performance verbessern will, lernt die Stellschrauben hier – Context-Size, GPU-Layer-Aufteilung, Batch-Size, Thread-Anzahl, Speculative-Decoding. Diese Erkenntnisse übertragen sich auf jeden Komfort-Layer darüber.
Wann NICHT
Für den klassischen produktiven Multi-User-Server in einer Treuhand mit 10-30 Mitarbeitern ist Ollama der bequemere Weg. Modell-Management, Auto-Update, persistente Modell-Hot-Loads – alles inklusive. llama.cpp pur verlangt mehr eigene Disziplin.
Für hohe Throughput-Anforderungen auf GPU (mehr als 10 parallele Anfragen pro Sekunde) ist vLLM oder Text Generation Inference die richtige Antwort. llama-server bedient parallele Anfragen, aber nicht annähernd so effizient wie vLLM mit PagedAttention.
Für Windows-Server-Setups in regulierten Schweizer Banken – wo das Unternehmens-OS Standard ist und Linux nicht freigegeben – ist llama.cpp zwar baubar, aber der Wartungs-Aufwand auf Windows ist hoch. Hier ist eine Cloud-API mit revDSG-Vertrag oder eine Windows-zertifizierte kommerzielle Lösung sauberer.
Für Hobby-Erkundung ohne Compile-Erfahrung ist llama.cpp die steilere Lernkurve. LM Studio oder Ollama bieten den gleichen llama.cpp-Kern mit grafischer Oberfläche und Modell-Browser.
Vor- und Nachteile
STÄRKEN
- Läuft auf jeder Hardware – CPU, NVIDIA, AMD, Intel, Apple, RISC-V, sogar Smartphones
- Single-Binary-Deployment ohne externe Laufzeit-Abhängigkeiten
- Vollständige Quantisierungs-Kontrolle von Q2 bis FP16
- GGUF ist Mai 2026 der De-facto-Standard für lokale Modell-Distribution
SCHWÄCHEN
- Kein integrierter Modell-Manager – Modelle müssen manuell verwaltet werden
- Multi-User-Throughput unter vLLM-Niveau, kein Continuous Batching
- Kompilier-Schritt verlangt eine kleine DevOps-Disziplin
- Schnelle Release-Frequenz erfordert eine Update-Strategie
Häufige Fragen
Warum llama.cpp statt Ollama nutzen?
Drei Gründe: maximale Hardware-Kontrolle, eigene Quantisierungen und Single-Binary-Deployment ohne Docker. Wer auf einem Apple Silicon Mac maximale Performance will, kompiliert llama.cpp mit -DGGML_METAL=ON und gewinnt 15-25 Prozent gegenüber Ollama-Defaults. Wer auf einem Embedded-Linux-Gerät eine LLM laufen lassen will, hat mit llama.cpp eine einzige Datei ohne Laufzeit-Abhängigkeiten.
Was ist der Unterschied zwischen Q4_K_M und Q5_K_M?
Q4_K_M nutzt 4-Bit-Quantisierung mit K-Quants-Verfahren – Dateigrösse rund 60 Prozent von FP16, Qualitätsverlust unter 3 Prozent in typischen Benchmarks. Q5_K_M nutzt 5-Bit-Quantisierung – Dateigrösse rund 70 Prozent von FP16, Qualitätsverlust unter 1 Prozent. Für 7B-Modelle ist Q4_K_M der üblichen Sweet-Spot; für 70B-Modelle, bei denen jedes Prozent zählt, lohnt sich Q5_K_M oder Q6_K wenn der zusätzliche RAM verfügbar ist.
Läuft llama.cpp auch auf Raspberry Pi?
Ja. Auf einem Raspberry Pi 5 mit 8 GB RAM läuft Phi-3 mini (3,8B) in Q4_K_M mit etwa 4-7 Tokens pro Sekunde. Apertus 8B ist mit aktiviertem Swap möglich, aber nicht produktiv schnell. Realistische Use-Cases auf Raspberry: kleine Klassifikations-Aufgaben, lokale Smart-Home-Assistenz, Embedded-Demo-Setups. Für ernsthafte Treuhand- oder Kanzlei-Anwendung reicht ein Pi nicht.
Unterstützt llama.cpp Llama 4 und Apertus?
Ja, beide. Llama 4 Scout und Maverick werden seit Build b3200 (Mitte April 2026) produktiv unterstützt, inklusive der MoE-Architektur. Apertus 8B und 70B sind seit September 2025 unterstützt, mit speziellen Optimierungen für die Romansh-Vokabular-Teile. GGUF-Quantisierungen beider Modelle sind auf Hugging Face verfügbar.
Verwandte Themen
Quellen
PASSEND ZU IHREM STACK?