llama.cpp vs. Ollama: dieselbe Engine, 4 Anfragen gleichzeitig oder 1 – und welches?

Nimm Ollama, wenn du einen Befehl pro Modell, eine Desktop-App auf Mac oder Windows und Modelle willst, die sich von selbst laden und entladen. Nimm llama.cpp, wenn du jede Einstellung selbst in der Hand haben willst, ab Werk 4 Anfragen gleichzeitig und nichts, was irgendwohin gesendet wird. Unter der Haube steckt dieselbe Engine: Ollama startet intern den Server von llama.cpp.

Genau dieser letzte Satz macht den Vergleich spannend, und wir haben ihn nicht einfach geglaubt. llama.cpp v0.7.0 ist die stabile Version vom 15. Oktober 2026; Ollama 0.40.10 erschien am 23. Oktober 2026 als stabile Version. Wir haben den Code beider Versionen überall dort gelesen, wo er über Speicher, parallele Anfragen, Netzwerk und deine Privatsphäre entscheidet. Mit der Stoppuhr haben wir sie nicht gegeneinander antreten lassen, einen Sieger beim Tempo gibt es hier also nicht: Mit derselben Modelldatei auf derselben Engine hängt das Tempo vom Build und von den Einstellungen ab, und genau bei diesen Einstellungen gehen die beiden auseinander.

llama.cppProgramm-Datenblatt→ OllamaProgramm-Datenblatt→

	llama.cpp	Ollama
Was es ist	Die Engine selbst, mit Server, Terminal-Chat und Chat-Seite	Ein Verwalter obendrauf: Modellbibliothek, Hintergrunddienst, Desktop-App
Version am 24. Oktober 2026	v0.7.0 (Build b11669), dazu rund 16 Builds pro Tag im täglichen Kanal	0.40.10, mit llama.cpp-Build b11803 an Bord
Code und Lizenz	Open Source, MIT	Open Source, MIT
Läuft auf	Windows, macOS, Linux und Android; Builds für CPU, CUDA, ROCm, Vulkan, Metal, SYCL und OpenVINO	Windows 10 22H2 oder neuer, macOS 14 oder neuer, Linux; NVIDIA, AMD, Vulkan und Apple Silicon (auch mit MLX)
Modelldateien	GGUF; safetensors erst nach dem Konvertieren	GGUF und safetensors; auf Apple Silicon standardmäßig MLX
Woher die Modelle kommen	Jede GGUF-Datei, oder Hugging Face mit -hf	Ollamas eigene Bibliothek mit ollama pull, oder deine eigene Datei per Modelfile
Anfragen gleichzeitig, ab Werk	4, die sich einen gemeinsamen Kontextspeicher teilen	1 pro Modell; der Rest wartet in einer Warteschlange mit bis zu 512 Plätzen
Kontext ab Werk	Das Maximum des Modells, gekürzt, bis es passt (nie unter 4.096 Token)	4.096 Token unter 23 GiB Grafikspeicher, 32.768 ab 23 GiB, 262.144 ab 47 GiB
Modell im Leerlauf	Bleibt geladen, bis du den Server beendest	Wird nach 5 Minuten entladen
Installation und erste Antwort	Ein Build oder brew install llama.cpp, dann llama serve -hf mit einem Modell	Installer oder Einzeiler-Skript, dann ollama run mit einem Modell
Fenster	Eine Chat-Seite im Browser, ab Werk aktiv	Desktop-App auf macOS und Windows; Terminal unter Linux
Lauscht auf	127.0.0.1:9931 (8080 bis v0.6.0)	127.0.0.1:11434
Schlüssel und CORS	Ab Werk kein Schlüssel (--api-key fügt einen hinzu); CORS offen für jede Webseite	Gar kein Schlüssel möglich; CORS nur offen für Seiten auf localhost, 127.0.0.1 und 0.0.0.0
Sendet von sich aus	Nichts	2 Arten von Aufrufen mit ollama serve, 4 mit der Desktop-App; OLLAMA_NO_CLOUD=1 kappt 2

Dieselbe Engine: was Ollama 0.40.10 intern laufen lässt

Wer Ollamas Code öffnet, findet die Beziehung schwarz auf weiß. Eine Datei im Hauptordner des Projekts, LLAMA_CPP_VERSION, legt fest, welches llama.cpp gebaut wird: b11803, ein täglicher Build vom 21. Oktober 2026. Lädst du ein GGUF-Modell, startet Ollama 0.40.10 den Server von llama.cpp, llama-server, als eigenen Prozess: auf 127.0.0.1, auf einem freien Port, den das System vergibt, mit abgeschalteter Chat-Seite und verbotenen Downloads (--offline). Ollama spricht mit ihm und reicht dir die Antworten über seine eigene API auf Port 11434 weiter. Obendrauf legt Ollama eine eigene Kompatibilitätsschicht und einen kleinen Patch für den Modell-Lader und den Bildteil von llama.cpp.

Jetzt kommt der Witz an der Sache: Am 24. Oktober 2026 ist Ollamas llama.cpp neuer als die stabile Version von llama.cpp selbst. v0.7.0 entspricht Build b11669 vom 15. Oktober; Ollama bringt b11803 mit, 134 Commits später. Die täglichen Builds von llama.cpp sind noch weiter vorn: Brauchst du ein Modell, das gestern erschienen ist, ist llama.cpp allein zuerst da.

Die zweite Engine in Ollama ist MLX, Apples Framework, das Ollama auf Apple Silicon nutzt, sobald das heruntergeladene Modell seine MLX-Version ist. Flint, ein Programmiermodell, läuft inzwischen auf beiden Engines: 0.40.8 ließ es nur auf macOS laufen, über MLX; 0.40.9 bringt es auch auf Linux und Windows, denn b11803 ist der llama.cpp-Build, der Flint hinzugefügt hat. Das Standard-Tag in Ollamas Katalog enthält jetzt zwei Versionen, MLX für Macs mit Apple Silicon und eine GGUF-Datei für llama.cpp überall sonst, und Ollama lädt die passende für deinen Rechner.

Du wählst also nicht zwischen zwei Engines. Du wählst, ob du die Engine direkt mit allen Optionen nutzt oder über einen Verwalter, der sie für dich festlegt. Um genau diese Festlegungen geht es im Rest der Seite.

4 Anfragen gleichzeitig, oder 1

Startest du llama serve, öffnet es 4 Slots: Bis zu 4 Anfragen werden gleichzeitig bearbeitet. Im Code der v0.7.0 steht die Zahl der Server-Slots standardmäßig auf auto, und auto heißt 4, mit einem einzigen Kontextspeicher, den sich alle teilen. Dieser geteilte Speicher ist das Detail, das man kennen sollte: Mit -c 8192 gestartet, bekommst du 8.192 Token für alle 4 zusammen. Ein langes Gespräch kann also den ganzen Speicher nutzen, 4 lange Gespräche gleichzeitig streiten sich darum. -np legt eine andere Zahl von Slots fest; dann wird der Speicher gleichmäßig auf sie aufgeteilt, außer du setzt zusätzlich --kv-unified.

Ollama bearbeitet 1 Anfrage pro Modell auf einmal: OLLAMA_NUM_PARALLEL steht ab Werk auf 1, und alle weiteren Anfragen warten in einer Warteschlange mit bis zu 512 Plätzen. Für eine Person, die chattet, ist das genau richtig. Du kannst den Wert erhöhen, und hier zeigt der Code den Preis: Ollama verlangt von seinem internen llama-server einen Kontext in der gewählten Größe mal der Zahl paralleler Anfragen. Stellst du 4 bei 4.096 Token Kontext ein, reserviert es Speicher für 16.384 Token.

Wann spielt das eine Rolle? Bei einem Editor-Plugin, das Vervollständigungen anfragt, während du chattest, bei einem Skript, das Fragen parallel schickt, oder wenn 2 Leute im Haus dasselbe Modell nutzen. Tippt nur eine Person eine Frage nach der anderen, bleiben die 4 Slots meist leer, und beide verhalten sich gleich. Und wie viel schneller ist llama.cpp mit 4 laufenden Anfragen? Das haben wir nicht gemessen: Es hängt von Karte, Modell und davon ab, wie viele Anfragen zusammen ankommen.

Kontext: das Maximum des Modells, oder 4.096 Token

Das ist die Werkseinstellung, die im Alltag am meisten ausmacht, und die beiden gehen genau entgegengesetzte Wege.

llama.cpp fängt oben an. Seine Kontextgröße, -c, steht ab Werk auf 0, und das heißt: der längste Kontext, mit dem das Modell trainiert wurde. Danach passt ein Mechanismus namens --fit, ab Werk aktiv, alles an, was du nicht selbst gesetzt hast: Er verkleinert den Kontext bis zu einer Untergrenze von 4.096 Token und verschiebt dann Schichten von der Grafikkarte in den Arbeitsspeicher, mit dem Ziel, auf jedem Gerät 1.024 MiB frei zu lassen. Du bekommst den längsten Kontext, den dein Rechner schafft, manchmal mit einem Teil des Modells auf dem Prozessor, was langsamer ist.

Ollama fängt unten an und entscheidet nach dem Grafikspeicher, den es beim Start findet: unter 23 GiB insgesamt 4.096 Token, ab 23 GiB 32.768, ab 47 GiB 262.144. Auf einer Karte mit 8 oder 12 GB heißt das 4.096 Token für jedes Modell, auch für eines, das auf 262.144 trainiert wurde, solange weder du noch das Modelfile des Modells eine andere Zahl setzt. Ein langes Dokument wird dann stillschweigend abgeschnitten, und das Modell antwortet nur auf den Teil, den es gesehen hat. OLLAMA_CONTEXT_LENGTH ändert den Wert für alle Modelle, num_ctx für ein Modell oder eine Anfrage.

Auch nach der Antwort geht der Speicher unterschiedlich weiter. Ollama entlädt ein Modell nach 5 Minuten ohne Anfrage und gibt den Speicher frei, herrlich auf einem Laptop, auf dem auch noch ein Browser und ein Spiel laufen. llama-server hält das Modell geladen, bis du ihn beendest; --sleep-idle-seconds schickt ihn nach einer Weile schlafen, wenn dir Ollamas Manieren lieber sind.

Installation und erste Antwort

Ollama sind 2 Schritte: der Installer auf macOS oder Windows, oder ein Einzeiler-Skript unter Linux, dann ollama run mit einem Modellnamen. Es lädt das Modell aus seiner eigenen Bibliothek und öffnet einen Chat im Terminal; auf macOS und Windows gibt es zusätzlich eine Desktop-App mit Chatfenster. Dieses Video geht von der Installation bis zum ersten Modell; es entstand mit einer älteren Version, wo es abweicht, gilt also diese Seite.

llama.cpp verlangt vorher eine Entscheidung: welcher Build. Der entspannte Weg ist brew install llama.cpp, das auf Mac und Linux seit dem 16. Oktober 2026 die stabile v0.7.0 installiert. Die Release-Seite auf GitHub bietet 36 Dateien pro Build, je nach System und Grafikkarte, und du nimmst die passende (bei NVIDIA dazu ihre cudart-Datei); winget unter Windows und das Installationsskript des Projekts liefern dagegen einen täglichen Build. Danach 1 Befehl:

llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF -c 8192

Er lädt das Modell von Hugging Face, in der Kompression Q4_K_M, wenn du keine andere angibst, und öffnet den Server samt Chat-Seite unter http://127.0.0.1:9931. Unsere Anleitung zum Einrichten von llama.cpp geht Builds und Optionen durch, die Anleitung zum Einrichten von Ollama macht dasselbe für Ollama.

Willst du die beiden vor der Wahl nebeneinander sehen, macht dieses Video genau das. Es entstand mit anderen Versionen: Wo es von dieser Seite abweicht, gilt die Seite (v0.7.0 und 0.40.10).

Woher die Modelle kommen, ist ein echter Unterschied. Beide lesen GGUF, das Format, das llama.cpp erfunden hat. llama.cpp lädt jede GGUF-Datei, die du ihm gibst, aus jedem Ordner, und -hf lädt von Hugging Face in den Standard-Cache von Hugging Face, den es mit anderen Programmen teilt, die ihn nutzen: Nichts wird doppelt heruntergeladen. Ein Modell in safetensors muss vorher mit dem Skript convert_hf_to_gguf.py aus dem Repository umgewandelt werden. Ollama lädt mit ollama pull aus seiner eigenen Bibliothek, in seinem Schichtformat unter ~/.ollama/models; für eine eigene Datei schreibst du ein Modelfile, das auf eine GGUF-Datei oder einen Ordner mit safetensors zeigt, und führst ollama create aus.

Bei der Hardware hat llama.cpp die längste Liste: fertige Builds für den Prozessor allein, NVIDIA mit CUDA, AMD mit ROCm oder Vulkan, Intel mit SYCL oder OpenVINO, Apple Silicon mit Metal und sogar Android-Handys. Ollama deckt Windows 10 22H2 oder neuer, macOS 14 oder neuer und Linux ab, NVIDIA-Karten ab Compute Capability 5.0, AMD mit ROCm v7 und Vulkan, unter Windows und Linux standardmäßig aktiv. Auf einem Intel-Mac laufen beide nur auf dem Prozessor.

Ein Fenster, eine Chat-Seite oder nur ein Terminal

llama-server bringt eine eigene Chat-Seite mit, ab Werk aktiv, unter derselben Adresse wie die API. Öffne http://127.0.0.1:9931, und da ist sie: deine Unterhaltungen und seit v0.7.0 eine Modellverwaltung. Deine Chats liegen im Speicher deines Browsers, nicht in einem Ordner auf der Festplatte: Löschst du die Websitedaten, sind sie weg, und in einen anderen Browser wandern sie nicht mit. --no-ui schaltet die Seite ab, wenn du nur die API willst.

Ollamas Fenster ist seine Desktop-App auf macOS und Windows, die deine Chats in einer kleinen Datenbank in deinem Benutzerordner speichert. Unter Linux ist Ollama ein Hintergrunddienst plus Terminal; vor seine API setzt du die Chat-Oberfläche deiner Wahl. Witziges Detail: Der llama-server, der in Ollama läuft, hat genau diese Chat-Seite, und Ollama schaltet sie absichtlich ab.

Welche Türen offen sind: 127.0.0.1:9931 gegen 127.0.0.1:11434

Zuerst die gute Nachricht: Ab Werk lauschen beide nur auf deinem eigenen Rechner. llama.cpp v0.7.0 wartet auf 127.0.0.1:9931; bis v0.6.0 war es 8080, und die Docker-Images des Projekts nutzen im Container weiterhin 8080. Ollama wartet auf 127.0.0.1:11434. Niemand in deinem WLAN erreicht einen der beiden, bevor du ihn absichtlich öffnest: --host 0.0.0.0 bei llama.cpp, OLLAMA_HOST=0.0.0.0 bei Ollama.

Der Unterschied liegt in deinem Browser. CORS entscheidet, welche Webseiten einen lokalen Server aus dem Browser heraus nutzen dürfen, und hier ist Ollama der strengere. llama.cpp spiegelt ab Werk jeden Origin zurück und erlaubt Anmeldedaten: Eine Webseite, die du besuchst, kann Anfragen an deinen llama-server schicken und die Antworten lesen, solange er läuft; der Server warnt beim Start selbst davor, mit security: no API key is set and CORS allows all origins. Ollama akzeptiert nur Seiten von localhost, 127.0.0.1 und 0.0.0.0 auf beliebigem Port, dazu ein paar App-Schemata, und antwortet jedem anderen Origin mit 403.

Bei Schlüsseln ist llama.cpp derjenige, der welche hat. --api-key oder die Variable LLAMA_API_KEY verlangt von Clients einen Schlüssel, --api-key-file liest mehrere aus einer Datei. Ollamas lokaler Server hat überhaupt keinen Schlüssel zu prüfen: Seine Verteidigung: nur auf deinem Rechner lauschen, seine kurze CORS-Liste und eine Prüfung des Host-Headers jeder Anfrage. Ein Haken auf der Seite von llama.cpp: Der Schlüssel ändert nichts am CORS. In unserem Test für die Einrichtungsanleitung wurde der Origin auch mit gesetztem Schlüssel zurückgespiegelt; zu macht ihn erst --cors-origins localhost.

Was jedes von sich aus sendet

Hier gewinnt llama.cpp klar. Wir haben den Code seiner Engine, seines Servers, seines Terminal-Chats und seiner Chat-Seite nach Analyse-, Telemetrie- und Tracking-Bibliotheken durchsucht und keine gefunden; v0.7.0 bringt keinen neuen Aufruf mit. Es prüft nicht auf Updates und kennt keine Konten. Ins Internet geht es nur, wenn du es verlangst: Modell-Downloads, von Hugging Face mit -hf oder llama download und von jeder Adresse mit --model-url; als Container-Image verpackte Modelle mit --docker-repo; und llama update, das nur bei Installationen über das Skript des Projekts funktioniert. Liegen deine Modelle auf der Platte, verbietet --offline ihm das Netz ganz.

Auch Ollama hat keine Analyse-Bibliothek im Code. Mit ollama serve allein, wie unter Linux, macht es von sich aus 2 Arten von Aufrufen an ollama.com: einen Katalog empfohlener Modelle alle 4 Stunden und die Steckbriefe seiner Cloud-Modelle beim Start des Servers. OLLAMA_NO_CLOUD=1 schaltet beide ab. Mit der Desktop-App auf macOS oder Windows kommen 2 weitere Arten dazu: eine Update-Prüfung jede Stunde, die keine Einstellung stoppt, und eine Kontoabfrage beim Öffnen der App.

Die leiseste Einrichtung ist also llama.cpp mit --offline, danach ollama serve ohne App und mit OLLAMA_NO_CLOUD=1. Jedes Ziel mit Quelle und Datum steht in unserem Steckbrief zu llama.cpp und im Steckbrief zu Ollama.

Welches wir installieren würden, je nach Fall

• Zum ersten Mal lokale KI, auf beliebigem Rechner: Ollama. Ein Befehl, ein Modell, das sich selbst lädt und entlädt, und von Anfang an ein enges CORS.
• Ein Mac oder Windows-Laptop, und du willst ein Fenster: Ollamas Desktop-App. Die Chat-Seite von llama.cpp ist gut, lebt aber im Browser.
• Lange Kontexte ohne Gefummel: llama.cpp, das vom Maximum des Modells ausgeht; oder Ollama mit von Hand gesetztem OLLAMA_CONTEXT_LENGTH.
• Ein Editor-Plugin, Skripte oder 2 Leute an einem Modell: llama.cpp, mit seinen 4 Slots, --cors-origins localhost und einem Schlüssel.
• Nichts darf den Rechner verlassen: llama.cpp mit --offline.
• Ein Modell, das gestern erschienen ist: ein täglicher Build von llama.cpp, der neue Modellfamilien vor dem stabilen Kanal und vor Ollama bekommt.
• Ein Regal voller GGUF-Dateien in einem Ordner: llama.cpp liest sie, wie sie sind; Ollama braucht ein Modelfile pro Modell.

Klemmt unterwegs etwas, haben wir eine Anleitung für den Fall, dass llama.cpp nicht funktioniert, und eine für den Fall, dass Ollama nicht funktioniert. Schwankst du noch zwischen einer Desktop-App und einem Server für viele? Unsere Vergleiche LM Studio vs. Ollama und vLLM vs. Ollama decken das ab, und der Modellfinder sagt dir, welche Modelle auf deinen Rechner passen.