Lokale LLM: Ollama oder llama.cpp – was passt besser?

Lokale LLM: Wann lohnt sich Ollama, wann llama.cpp?

Ollama ist die passende Wahl für Entwicklerarbeitsplätze oder einen überschaubaren internen Modelldienst. Befehle zur Modellverwaltung, benannte Konfigurationen und eine API für Anwendungen verkürzen den Weg vom heruntergeladenen Modell zum nutzbaren Dienst. Speicherbedarf und Zugriffsschutz müssen weiterhin geplant werden. Dafür müssen weniger Entscheidungen zum Inferenzbetrieb in die Einrichtungsanleitung jedes einzelnen Arbeitsplatzes einfließen.

llama.cpp ist die bessere Wahl, wenn die Inferenzkonfiguration in eigener Hand liegt. Das gilt besonders, wenn ein bestimmtes GGUF-Artefakt ausgewählt, eine neue Quantisierung geprüft, die GPU-Belegung angepasst oder das Zusammenspiel von parallelen Anfragen und Kontextzuweisung abgestimmt werden soll. Das Ergebnis ist eine präzise beschreibbare Bereitstellung. Im Gegenzug muss diese Konfiguration selbst gepflegt werden.

Die vorhandene Laufzeitumgebung sollte bleiben, solange sie die Anforderungen an Antwortzeiten und Qualität erfüllt. Ein fremder Laptop-Benchmark mit besseren Geschwindigkeitswerten ist allein kein überzeugender Grund, von Ollama zu llama.cpp zu wechseln. Ein Wechsel lohnt sich, wenn eine konkret benötigte Einstellung oder ein gemessenes Problem benannt werden kann.

Abgleich mit der aktuellen Dokumentation beider Projekte am 16. Oktober 2026. Der Vergleich bewertet Installation, Kontrolle über Modellartefakte, API-Verhalten, parallele Verarbeitung und Hardwareunterstützung. Ein eigener Leistungstest liegt ihm nicht zugrunde.

Die genannten Funktionen sind im CLI-Leitfaden von Ollama, in dessen Anleitung zum GGUF-Import und in der Server-Referenz von llama.cpp dokumentiert. Beide lokalen Softwareprojekte sind kostenlos, anders als die gehosteten Angebote von Ollama. Die Lizenzen der Modelle sind gesondert zu betrachten. Ollama-Repository, llama.cpp-Repository.

Verwandte Inferenztechnik, unterschiedliche Zuständigkeiten

Ollama ergänzt die Inferenz um Modellverwaltung und eine Dienstschicht; llama.cpp macht das Inferenzwerkzeug direkt zugänglich. Inferenz bezeichnet die Berechnung, die aus Modellgewichten und einer Eingabe Ausgabetokens erzeugt. Zum Betrieb gehören außerdem das Finden von Modellen, das Benennen und Laden von Konfigurationen, die Annahme von Anfragen und das Ausmustern alter Artefakte.

Ollama nennt llama.cpp in den Danksagungen seines Repositorys. Die Bezeichnung „nur ein Wrapper“ greift dennoch zu kurz: Der aktuelle Quellcode enthält auch Arbeit an anderen Backends, darunter MLX-Komponenten. Die gemeinsame technische Herkunft bedeutet nicht, dass jedes Modell dasselbe Backend, denselben Versionsstand oder denselben Ausführungspfad nutzt. Ollama-Quellcode und Danksagungen.

Entscheidend ist, wie viele technische Details in der eigenen Bereitstellungsanleitung stehen sollen. Benötigt ein Entwickler lediglich einen dokumentierten Modellnamen und einen Endpunkt, hilft die Bündelung durch Ollama. Müssen für den Infrastrukturverantwortlichen Dateiprüfsumme, Backend-Build und Speichereinstellungen zusammen festgehalten werden, lässt sich das mit einer direkten llama.cpp-Konfiguration leichter explizit abbilden.

Installation und Modellverwaltung: Ollama erleichtert den Alltag

Ollama: Wiederkehrende Einrichtungsschritte bündeln

Ollama führt Modelle lokal aus und stellt dafür eine verwaltete Modellbibliothek sowie eine Dienst-API bereit. Downloads gibt es für macOS, Windows und Linux. Die CLI bietet die alltäglichen Verwaltungsbefehle für IT-Verantwortliche: pull, run, ls, rm, ps und stop. Ein Modelfile beschreibt eine Modellkonfiguration als Textdatei. Damit lassen sich ein Basismodell und Anweisungen unter einem Namen bündeln. Ollama-Schnellstart, CLI-Referenz.

Für ein gemeinsames Pilotprojekt zur Programmierunterstützung genügt es, das freigegebene Modell, seine Konfiguration und den Endpunkt einmal zu dokumentieren. Ein Entwickler sollte sich nicht erst mit der GPU-Zuweisung beschäftigen müssen, nur um eine Anwendung anzubinden. Darin liegt das stärkste Argument für Ollama gegenüber llama.cpp.

Die Grenze ist erreicht, sobald sich das benötigte Serververhalten mit diesem vorgegebenen Ablauf nicht mehr abbilden lässt. Es ist nicht selbstverständlich, dass sich ein Flag aus dem zugrunde liegenden llama.cpp unverändert durch Ollama weiterreichen lässt. Bevor eine Bereitstellung auf einer bestimmten Einstellung aufbaut, muss deren Verfügbarkeit in der installierten Version geprüft werden.

llama.cpp: Direkter Zugriff ohne Kompilierpflicht

llama.cpp ist ein Inferenzwerkzeug mit Kommandozeile, HTTP-Server und Weboberfläche. Die aktuelle README nennt einen Installer, vorgefertigte Releases, Docker und Builds aus dem Quellcode. Außerdem dokumentiert sie llama cli -hf und llama serve -hf, um Modelle direkt von der Modellplattform Hugging Face zu laden. Selbst zu kompilieren ist eine Option, keine Einstiegsvoraussetzung. Installation und Schnellstart von llama.cpp.

Ebenso wenig bedeutet der direkte Einsatz von llama.cpp, dauerhaft für jedes Modell einen separaten Prozess von Hand starten zu müssen. Die Server-Dokumentation beschreibt einen Router mit Modellverzeichnissen und Konfigurationsvorlagen. Der Unterschied liegt darin, wie viel von diesem Betriebskonzept selbst ausgewählt und gepflegt wird. Dokumentation zum Server-Router.

Vorteil: Ollama bei der üblichen Installation und Modellverwaltung. llama.cpp lohnt sich hier vor allem dann, wenn die explizite Konfiguration dem eigenen Arbeitsablauf einen Mehrwert bringt. Geht es eigentlich um eine Desktop-Arbeitsumgebung für Modelle, hilft eher der Vergleich Ollama vs LM Studio.

GGUF und Quantisierung: llama.cpp bietet mehr Kontrolle über die Modelldatei

Beide können GGUF-Modelle ausführen; llama.cpp bietet den direkteren Weg zur Vorbereitung und Auswahl. GGUF ist ein Dateiformat für Modellgewichte und Metadaten. Bei der Quantisierung werden Gewichte mit geringerer Präzision gespeichert, um den Speicherbedarf zu senken. Welche Qualitätseinbußen damit verbunden sind, hängt vom Modell und der Aufgabe ab.

Der Quantisierer von llama.cpp dokumentiert Formate wie Q4_K_M, Q5_K_M und Q8_0 sowie Einstellungen für Importance-Matrizen und einzelne Tensoren. Eine Importance-Matrix hilft zu bestimmen, welche Modellteile mehr Präzision benötigen. Mit Einstellungen pro Tensor lassen sich unterschiedliche Gewichtsarrays unterschiedlich behandeln. Das wird relevant, wenn ein gewöhnlicher Download die Anforderungen an Speicherbedarf oder Qualität nicht erfüllt. Quantisierungsleitfaden von llama.cpp.

Ollama kann eine vorbereitete GGUF-Datei über eine FROM-Zeile im Modelfile importieren. Die aktuelle Dokumentation stellt ausdrücklich klar: Der GGUF-Import quantisiert das Modell nicht. Dafür verweist sie auf einen vorherigen Schritt mit Werkzeugen wie llama-quantize. Daraus ergibt sich eine sinnvolle Arbeitsteilung: das Artefakt mit llama.cpp vorbereiten und anschließend eine benannte Konfiguration über Ollama verteilen. Ollama-Dokumentation zum Import.

Liegt beispielsweise ein kompatibles Textmodell als einzelne Datei unter ./team-model.gguf, erzeugen diese Befehle eine Ollama-Konfiguration mit festgelegtem Kontextumfang:

cat > Modelfile <<'MODEL'
FROM ./team-model.gguf
PARAMETER num_ctx 8192
MODEL
ollama create team-local -f Modelfile
ollama run team-local

Datei- und Modellname sind frei wählbar. Die Kontexteinstellung dient als Beispiel und ist keine pauschale Empfehlung für jede Arbeitslast. Die Syntax stammt aus der Modelfile-Referenz.

Die Dateiendung .gguf ist keine Kompatibilitätsgarantie. Unterstützt werden müssen auch die Modellarchitektur und das Chat-Template, also die Regeln, die Nachrichten in das erwartete Eingabeformat des Modells umwandeln. Multimodale Modelle benötigen unter Umständen zusätzliche Bild- oder Audiokomponenten. Der Quantisierungsleitfaden von llama.cpp erklärt die ergänzenden Projektordateien. Eine erfolgreiche Textantwort allein belegt weder funktionierende Bildeingaben noch die Nutzung von Tools.

Vorteil: llama.cpp bei individueller Quantisierung und der Auswahl exakter Modellartefakte. Ollama bleibt geeignet, wenn das vorbereitete Modell funktioniert und dessen Betriebsablauf besser passt. Die Modellgewichte sollten unabhängig von der Laufzeitumgebung ausgewählt werden; dabei hilft Die besten lokalen LLMs 2026.

Server und API-Kompatibilität: Ollama vereinfacht die Standardintegration

Für Anwendungen mit einer dokumentierten lokalen Modell-API ist Ollama der einfachere Ausgangspunkt. llama.cpp liegt vorn, wenn die Serverkonfiguration selbst abgestimmt werden muss. Ollama bietet eine native API und OpenAI-kompatible Routen. Auch llama.cpp stellt OpenAI-kompatible Chat Completions, Responses und Embeddings bereit. Kompatibilität bedeutet hier eine vertraute Schnittstelle für Anfragen, nicht identisches Verhalten bei jedem Feature. Ollama-API-Dokumentation, llama.cpp-Server-Referenz.

Eine konkrete Einschränkung kann für den Wechsel ausschlaggebend sein: Ollamas Responses API ist zustandslos. Sie unterstützt weder previous_response_id noch conversation. Verlässt sich eine Anwendung darauf, dass der Server über diese Felder einen Gesprächsverlauf vorhält, reicht es nicht, lediglich die Basis-URL zu ändern. Das dokumentierte Verhalten des Zielservers muss geprüft und der Speicherort des Gesprächsverlaufs festgelegt werden.

Eine weitere Grenze betrifft die Kontextkonfiguration. Ollamas Leitfaden zur OpenAI-Kompatibilität verweist für Änderungen an der Kontextgröße lokaler Modelle auf ein Modelfile. Diese Einstellung ist vom Limit für Ausgabetokens zu unterscheiden: Eine längere erlaubte Antwort schafft nicht automatisch Platz für eine längere Eingabe.

Bei einer direkten Bereitstellung mit llama.cpp bietet der Server Modellaliasnamen, Einstellungen für Chat-Templates, API-Schlüssel und optionale Metriken. Das ist hilfreich, wenn ein interner Assistent seinen festen Modellnamen in der API behalten soll, während das zugrunde liegende Artefakt ausgetauscht wird. Zugleich wächst damit die Konfiguration, die geprüft und über Upgrades hinweg erhalten werden muss.

Parallele Anfragen: llama.cpp macht die Steuerung explizit

Ollama kann mehrere Anfragen gleichzeitig bedienen; llama.cpp legt mehr Einstellungen für die Ablaufplanung und Speichernutzung direkt offen. Mehrere Modelle gleichzeitig zu laden und mehrere Anfragen gleichzeitig zu verarbeiten, sind unterschiedliche Aufgaben. Ein Programmiermodell neben einem Embedding-Modell zu laden, beansprucht den Speicher anders als mehrere Gespräche, die sich ein geladenes Modell teilen.

Ollama dokumentiert OLLAMA_NUM_PARALLEL, OLLAMA_MAX_LOADED_MODELS und OLLAMA_MAX_QUEUE. Standardmäßig ist pro Modell 1 parallele Anfrage vorgesehen; die parallele Verarbeitung hängt vom verfügbaren Speicher ab. Ein höheres Warteschlangenlimit lässt mehr Arbeit warten, schafft aber keine zusätzliche Inferenzkapazität. Ollama-Dokumentation zu parallelen Anfragen.

llama.cpp dokumentiert paralleles Decoding, Continuous Batching und Server-Slots. Mit Continuous Batching kann der Server neue Arbeit aufnehmen, sobald laufende Anfragen abgeschlossen sind. Ein Slot ist ein Platz für eine Anfrage, die gerade verarbeitet wird. Zu den Einstellungen gehören --parallel und --kv-unified-per-slot sowie die GPU-Zuweisung und Cache-Einstellungen. Server-Einstellungen von llama.cpp.

Erst den Kontext dimensionieren, dann die Parallelität erhöhen

Ein beispielhafter Pilotbetrieb rechnet mit 4 gleichzeitigen Anfragen × 8,192 Tokens Kontext = 32,768 Tokenpositionen. Das beschreibt die Kontextkapazität, keinen gemessenen RAM-Bedarf. Der KV-Cache, in dem das Modell seinen Attention-Zustand speichert, belegt zusätzlich zu den Gewichten und weiteren Arbeitsbereichen Speicher. Sein Bedarf in Bytes hängt von der Architektur und der Präzision des Caches ab.

Mit der kompatiblen Datei team-model.gguf aus dem vorherigen Beispiel lässt sich diese Konfiguration in einer aktuellen llama.cpp-Installation direkt ausdrücken:

llama serve -m ./team-model.gguf \
  --alias team-local \
  --host 127.0.0.1 --port 8080 \
  --parallel 4 \
  --kv-unified-per-slot 8192

Das sind gewählte Einstellungen für einen Pilotbetrieb, keine Benchmark-Ergebnisse oder Standardwerte des Projekts. Laut Server-Dokumentation wird der gemeinsame KV-Pool ohne explizite Angabe von --ctx-size aus der Anzahl der Slots multipliziert mit dem Limit pro Slot bemessen. Der Pilotbetrieb sollte auf die Loopback-Schnittstelle beschränkt bleiben, bis die Zugriffskontrollen eingerichtet sind.

Bei Ollama werden Parallelität und Kontext in der Dienstumgebung konfiguriert. Anschließend lassen sich der tatsächlich wirksame Kontextumfang und die Verteilung auf CPU und GPU mit ollama ps prüfen. Die eigene Dokumentationsseite zum Kontext beschreibt hardwareabhängige Standardwerte. Deshalb sollte die tatsächlich verwendete Zuweisung festgehalten werden. Ollama-Kontextkonfiguration.

Geschwindigkeit lässt sich nur an einer konkreten Arbeitslast bewerten

Keines der Projekte gewinnt allein aufgrund seines Namens jeden Latenz- oder Durchsatztest. Für einen Vergleich müssen Modellgewichte, Quantisierung, Template, Kontext, Backend und Hardware übereinstimmen. Danach gilt es, Wartezeit, Zeit bis zum ersten Token, Generierungsgeschwindigkeit und abgeschlossene Anfragen unter Last getrennt zu betrachten.

Bei einem internen Support-Assistenten belegt eine einzelne schnelle Antwort noch nicht, dass Beschäftigte ihn gemeinsam nutzen können. Dafür sollten repräsentative kurze Fragen und Anfragen mit langen Dokumenten erneut durchgespielt, Kaltstarts gesondert erfasst und Laufzeitversionen samt Datum dokumentiert werden. Ein berichteter Geschwindigkeitsunterschied ist erst dann aussagekräftig, wenn Tester, Datum, Hardware, Modell und Arbeitslast genannt sind.

Vorteil: llama.cpp bei der gezielten Abstimmung paralleler Anfragen. Ollama bleibt sinnvoll, wenn seine Einstellungen die Anforderungen an den Dienst erfüllen und der einfachere Betrieb mehr zählt als zusätzliche Eingriffsmöglichkeiten.

Apple Silicon und GPU-Unterstützung: Welches Backend passt zur Hardware?

Ollama erleichtert die übliche Bereitstellung auf Arbeitsplätzen; llama.cpp bietet mehr Kontrolle über spezielle Backends. Beide unterstützen die Beschleunigung über Apple-GPUs. Ollama dokumentiert Metal-Unterstützung. llama.cpp behandelt Apple Silicon als zentrale Zielplattform und nutzt Metal, Accelerate und ARM-Optimierungen. Ollama-Hardwareunterstützung, von llama.cpp unterstützte Hardware.

Auf einem Mac empfiehlt sich als Ausgangspunkt die native Anwendung oder ein natives Binärpaket. Laut Ollama-Dokumentation bietet Docker Desktop unter macOS keine GPU-Beschleunigung. Wird eine funktionierende native Installation in einen Container verlegt, kann sich damit der Ausführungspfad ändern, der eigentlich verglichen werden sollte. Ollama-Hinweis zur GPU-Nutzung in Docker.

Für andere Arbeitsplätze dokumentiert Ollama NVIDIA-Unterstützung, AMD über ROCm und Vulkan-Unterstützung bei installiertem Backend. llama.cpp bietet CUDA für NVIDIA, HIP für AMD sowie Vulkan und SYCL. Build-Anleitungen erklären die Auswahl der Backends. Entscheidend ist die konkrete Kombination aus Betriebssystem, GPU und Treiber; ein Herstellername allein garantiert keine Unterstützung. Ollama-GPU-Leitfaden, Build-Anleitung für llama.cpp.

Die erste praktische Prüfung betrifft die Platzierung: Liegen die Gewichte auf der GPU, auf der CPU oder verteilt auf beiden? Zusätzliche Einstellungen lösen nicht das Problem, dass Modell und Kontext zusammen den zugewiesenen Speicher übersteigen. Zuerst muss die Konfiguration in den verfügbaren Speicher passen. Anschließend lässt sich beurteilen, ob die Antwortqualität ausreicht.

Was ändert Muse Spark Open an der Entscheidung?

Dass Meta llama.cpp nennt, eröffnet einen dokumentierten Weg zur Erprobung dieser Inferenzengine. Ein automatischer Grund, Ollama abzulösen, ergibt sich daraus nicht. In der Ankündigung von Muse Spark Open vom 15. Oktober 2026 führt Meta llama.cpp unter den unterstützten Inferenzengines auf. Damit wird der direkte Einsatz von llama.cpp relevant, wenn das neu veröffentlichte Modell geprüft werden soll, ohne gleichwertige, bereits eingebundene Unterstützung in einer anderen Laufzeitumgebung vorauszusetzen. Metas Ankündigung.

Dabei ist der Hardwarekontext entscheidend. Meta beschreibt 816B Parameter insgesamt und 42B aktive Parameter. Das Desktop-Beispiel verwendet zwei Apple M5 Ultra Mac Studios mit MLX. Dieses Beispiel ist kein llama.cpp-Benchmark. Auch die Zahl der aktiven Parameter ersetzt keine Prüfung des Speicherbedarfs des vollständigen Modells. Metas Beschreibung von Hardware und Modell.

Für die eigene Bereitstellung müssen der genaue Build, das Modellartefakt, die Quantisierung, das Template und die benötigten Eingabetypen gemeinsam geprüft werden. Die Nennung einer Engine in einer Produktankündigung belegt weder die Unterstützung in der installierten Ollama-Version noch, dass das Modell auf einen gewöhnlichen Entwickler-Laptop passt. Für Infrastrukturverantwortliche entsteht damit eine neue Möglichkeit zur Erprobung. Die Einführung auf Arbeitsplätzen muss weiterhin gesondert validiert werden.

Von Ollama zu llama.cpp wechseln: Die Konfiguration muss mit

Bei der Migration geht es darum, das Verhalten zu erhalten, nicht bloß Gewichte zu kopieren. Gesprächsverlauf, Retrieval-Index und Anfrageverarbeitung einer Anwendung können außerhalb beider Laufzeitumgebungen liegen. Diese Zuständigkeitsgrenzen müssen beim Austausch des Modelldienstes klar bleiben.

Ein Wechsel ist nicht nötig, wenn der bestehende Dienst funktioniert und niemand die zusätzlichen Einstellungen braucht. Ebenso lässt sich eine GGUF-Datei mit llama.cpp vorbereiten und weiterhin über Ollama bereitstellen. Beide Projekte können unterschiedliche Aufgaben innerhalb desselben Arbeitsablaufs übernehmen.

Ollama vs llama.cpp vs vLLM: Wann reicht der Arbeitsplatz nicht mehr aus?

vLLM sollte geprüft werden, wenn dauerhaft gemeinsame Nutzung oder verteilte Inferenz zur zentralen Anforderung wird. Die Dokumentation dieser Inferenzengine legt den Schwerpunkt auf Continuous Batching, Cache-Verwaltung und Möglichkeiten zur verteilten Ausführung. Diese Fähigkeiten rechtfertigen eine Erprobung, wenn ein Dienst mit dediziert bereitgestellter Beschleunigerkapazität betrieben wird. vLLM-Dokumentation.

Continuous Batching allein ist kein Abgrenzungskriterium, denn llama.cpp unterstützt es ebenfalls. Ebenso wenig gibt es eine allgemeingültige Mitarbeiterzahl, ab der ein Wechsel nötig wird. Ein Dienst mit gelegentlichen kurzen Anfragen hat eine andere Arbeitslast als eine kleinere Gruppe, die fortlaufend lange Programmieraufgaben stellt.

Die Entscheidung lässt sich an Messwerten festmachen: Verfehlt die bestehende Konfiguration bei repräsentativer Spitzenlast die Zielwerte für Antwortzeiten und bietet vLLM die fehlende Einstellung oder Bereitstellungsmöglichkeit, ist ein Test sinnvoll. Erfüllt die bestehende Konfiguration die Anforderungen, kann sie bleiben. Der gesonderte Vergleich Ollama vs vLLM behandelt diese Entscheidung zum Inferenzbetrieb ausführlich.

Der nächste Schritt für Montag ist konkret: einen lokalen Arbeitsablauf auswählen, Modell und Kontext festlegen, die erwartete gleichzeitige Nutzung bestimmen und den Ablauf vor einer breiteren Freigabe durchspielen. Das Ergebnis zeigt, ob eine andere Laufzeitumgebung benötigt wird oder lediglich eine bessere Konfiguration.

Häufige Fragen

Die Checkliste zur Prüfung geschäftlicher KI-Arbeitsabläufe hilft, den ersten vertraulichen Arbeitsablauf auszuwählen, für den sich ein lokaler Dienst lohnt. Der Newsletter informiert anschließend über weitere Änderungen bei den Tools.