llama.cpp auf dem eigenen Rechner einrichten, und sehen, was es sendet

Für llama.cpp laden Sie 1 fertigen Build für Ihren Rechner herunter oder installieren es mit Homebrew, und dann genügt 1 Befehl: llama serve -hf, gefolgt von einem Modellnamen. Er lädt das Modell herunter und öffnet einen OpenAI-kompatiblen Server samt Chatseite im Browser, alles auf 127.0.0.1:9931 (8080 in v0.6.0 und älteren Versionen), und von sich aus sendet er nichts irgendwohin. 2 Dinge sollten Sie ab Tag 1 setzen: eine Kontextgröße mit -c 8192 und ein engeres CORS mit --cors-origins localhost.

Wir geben es zu: Bei diesem Programm schlägt unser Herz am schnellsten. llama.cpp ist die Engine ganz unten im Stapel, der C/C++-Code, auf dem die meisten lokalen KI-Programme aufbauen, und es direkt zu starten fühlt sich an, als würde man den Deckel abnehmen und in den Motor schauen. Es ändert sich auch schneller als alles andere, was wir hier behandeln. Diese Seite nutzt die stabile Version v0.7.0, veröffentlicht am 15. Oktober 2026, und den täglichen Build b11321, veröffentlicht am 1. Oktober 2026 um 14:09 UTC. Jede Voreinstellung hier haben wir im Code von b11321 und von v0.5.0 nachgelesen und im Code von v0.6.0 am 6. Oktober 2026 sowie von v0.7.0 am 16. Oktober 2026 erneut geprüft: Geändert hat sich nur der Port, 9931 statt 8080. Außerdem haben wir den offiziellen Linux-Build auf unserem eigenen Server gestartet, um zu sehen, was er tut.

llama.cppProgramm-Datenblatt→

Was llama.cpp ist, und der neue Befehl llama

llama.cpp führt Sprachmodelle aus, die als GGUF-Dateien gespeichert sind, ein Format, das dieses Projekt selbst geschaffen hat, und zwar auf fast jeder Hardware: Apple Silicon über Metal, NVIDIA über CUDA, AMD über ROCm oder Vulkan, Intel über SYCL oder OpenVINO und ganz normale Prozessoren ohne Hilfe. Es ist quelloffen unter der MIT-Lizenz, und Engine, Server und Weboberfläche liegen in 1 Repository. Das Programm-Datenblatt llama.cpp: was es nach Hause sendet und ob prüfbar übernimmt das Audit; diese Anleitung ist die praktische Seite davon.

Die große Neuerung von 2026 ist eine einzige ausführbare Datei namens llama. Ihre sichtbaren Unterbefehle sind:

• llama serve: der HTTP-Server, mit der OpenAI-kompatiblen API und der Weboberfläche.
• llama cli: ein Chat im Terminal.
• llama download: holt ein Modell, ohne etwas zu starten.
• llama version, llama licenses und llama help. llama help all listet zusätzlich bench, quantize, perplexity und ein paar weitere.

Die klassischen llama-server und llama-cli stecken weiterhin im Linux-Paket, das wir entpackt haben, direkt neben llama, also funktionieren ältere Anleitungen weiter. In b11321 gibt llama --version die Zeile 0.5.0-dev (build 11321, commit b0aca3c65) aus: Ein täglicher Build ist die stabile Version plus alles, was seitdem hinzugekommen ist.

Klicken Sie lieber, als zu tippen, bringen Sie LM Studio und seinen lokalen Server einrichten, und sehen, was es sendet und Ollama lokal einrichten, prüfen, ob es läuft, und sehen, was es sendet mit weniger Entscheidungen zur ersten Antwort. llama.cpp ist für den Moment gedacht, in dem Sie an jedem Regler selbst drehen wollen.

Stabil oder täglich: welche Version Ihnen jeder Installer gibt

llama.cpp hat 2 Kanäle. Der stabile trägt Tags wie v0.7.0; der tägliche veröffentlicht jedes Mal einen nummerierten Build, bNNNNN, wenn sich der Hauptzweig bewegt. Zwischen dem 30. September um 10:32 UTC und dem 1. Oktober um 14:09 UTC waren es 30 Stück. Jeder Installer folgt einem anderen Stand, und am 1. Oktober 2026 sah das so aus:

Installer	Befehl	Version am 1. Oktober 2026
Homebrew (Mac und Linux)	brew install llama.cpp	0.5.0, der stabile Kanal
Skript von llama.app (Mac und Linux)	curl -fsSL https://llama.app/install.sh | sh	b11200, ein täglicher Build
winget (Windows)	winget install llama.cpp	b11193, ein täglicher Build
GitHub-Releases (alle Systeme)	herunterladen und entpacken	b11321, der tägliche Build, dem diese Anleitung folgt; v0.5.0 zeigt auf den Build b11146

Formel-API von Homebrew, Paketmanifeste von winget, das Installationsskript von llama.app und die Releases-API von GitHub, gelesen am 1. Oktober 2026 zwischen 14:52 und 14:59 UTC. Am 6. Oktober 2026 lieferte Homebrew bereits 0.6.0, die am Vortag veröffentlichte stabile Version; seit dem 16. Oktober 2026 liefert es 0.7.0.

Homebrew ist der ruhige Weg: Sie bekommen die stabile Version, mit Paketen für Apple Silicon und für Linux auf x86_64 und arm64. Das Skript von llama.app ist das, welches die README des Projekts inzwischen an erster Stelle nennt. Es lädt kleine Testprogramme herunter, die erst nach CUDA suchen, dann nach ROCm, dann nach Vulkan, und sonst auf den Prozessor zurückfallen; den passenden Build installiert es nach ~/.llama-app und kopiert ihn nach ~/.local/bin/llama. Auf einem Mac sucht es nach den Chips M1 bis M5 (und dem A18); auf einem Intel-Mac bricht das Skript mit No prebuilt llama binary is available for your system ab, also: Für Ihr System gibt es keine fertige Binärdatei. Es ist außerdem die einzige Installation, in der llama update funktioniert, und zwar, indem es dasselbe Skript erneut ausführt. winget verteilt tägliche Builds, nicht den stabilen Kanal.

Welchen Build Sie für Ihren Rechner herunterladen

Der Build b11321 auf GitHub umfasst 35 Dateien. Die meisten Menschen brauchen genau 1 davon:

Ihr Rechner	Die Datei, die Sie nehmen (b11321)	Größe
Mac mit Apple Silicon	llama-b11321-bin-macos-arm64.tar.gz, mit eingebautem Metal	11,8 MB
Linux mit NVIDIA-Karte	llama-b11321-bin-ubuntu-cuda-13.4-x64.tar.gz (oder cuda-12.8-x64), dazu die passende Datei mit den cudart-…-Bibliotheken	152,2 MB + 440,2 MB
Windows mit NVIDIA-Karte	llama-b11321-bin-win-cuda-13.4-x64.zip (oder cuda-12.4-x64), dazu cudart-llama-bin-win-cuda-13.4-x64.zip	152,8 MB + 423,5 MB
AMD, Intel oder andere GPUs	der vulkan-Build: ubuntu-vulkan-x64 oder win-vulkan-x64. Builds für ROCm 10.0 gibt es für Linux und Windows	31,5 MB / 33,2 MB
Keine nutzbare GPU	ubuntu-x64 oder win-cpu-x64	17,5 MB / 19,3 MB

Dateinamen und Größen aus den Anhängen des Releases b11321 auf GitHub, gelesen am 1. Oktober 2026.

Einen Build für Intel-Macs gibt es, aber das Projekt kompiliert ihn mit ausgeschaltetem Metal, also läuft llama.cpp auf einem Intel-Mac nur auf dem Prozessor. Wenn Sie zwischen unseren Rechnern wählen: Die 3, die wir in den Beispielen weiter unten verwenden, sind diese:

PC mit RTX 4060 8 GBHardware-Datenblatt→ PC mit RTX 3060 12 GBHardware-Datenblatt→ Mac mit M4 und 16 GB Unified MemoryHardware-Datenblatt→

Entpacken Sie die Datei, öffnen Sie ein Terminal in diesem Ordner und führen Sie ./llama --version aus. Unter Linux liegen die Bibliotheken direkt neben dem Programm; wir haben den CPU-Build aus seinem eigenen Ordner gestartet, mit LD_LIBRARY_PATH auf genau diesen Ordner. Möchten Sie jemandem bei einer Installation zuschauen, bevor Sie selbst loslegen, ist dieser Rundgang eine gute Begleitung. Die Befehle ändern sich mit jedem Build: Wo Video und diese Seite voneinander abweichen, folgt diese Seite dem Build b11321.

Das erste Modell: llama serve -hf und llama cli

Der Befehl aus der README des Projekts:

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

-hf nimmt ein Repository von Hugging Face, auf Wunsch mit einer Kompression nach einem Doppelpunkt, etwa :Q4_K_M. Ohne Angabe wählt llama.cpp Q4_K_M, dieselbe Kompression, mit der wir unsere Modellgrößen rechnen, oder die erste Datei im Repository, falls es kein Q4_K_M gibt. Hat das Modell einen Bildteil, kommt seine mmproj-Datei mit (--no-mmproj lässt sie weg). Dann öffnen Sie http://127.0.0.1:9931 im Browser, und die Chatseite ist da. Das ist die Adresse der stabilen v0.7.0 und der täglichen Builds seit b11521 (9. Oktober 2026). v0.6.0 und ältere Versionen sowie ältere tägliche Builds wie b11321 aus der Tabelle oben lauschen auf 8080, ebenso eine Homebrew-Installation von vor dem 16. Oktober 2026, die Ihnen 0.6.0 lieferte: Damit öffnen Sie also http://127.0.0.1:8080, oder Sie starten mit --port 9931, dann gelten alle Adressen auf dieser Seite unverändert.

Für einen Chat im Terminal stattdessen:

llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF

Und um die API aus einem anderen Terminal zu prüfen:

curl http://127.0.0.1:9931/health
curl http://127.0.0.1:9931/v1/models

Für einen OpenAI-Client ist die Basis-URL http://127.0.0.1:9931/v1.

Ganz ohne Modell startet llama serve trotzdem. Wir haben es ausprobiert: Es gab starting server in router mode. models will be automatically loaded on-demand aus, also einen Router-Modus, der Modelle erst bei Bedarf lädt, listete die Modelle in seinem Cache auf (0 bei einem frischen Konto) und lud sie auf Anfrage, ab Werk bis zu 4 gleichzeitig. Außerdem meldete es router mode enabled – do not expose to untrusted environments, also die Warnung, den Router-Modus nicht in unsichere Umgebungen zu stellen. Ein guter Rat, den der übernächste Abschnitt in Befehle übersetzt.

Bricht llama.cpp hier oder später mit einem Fehler ab, geht unser Leitfaden zu llama.cpp-Fehlern 8 davon einzeln durch, jeweils mit der genauen Meldung und der Lösung.

Speicher: ab Werk der volle Kontext, und was --fit daraus macht

Das ist die Voreinstellung, die viele überrascht. Die Kontextgröße von llama.cpp, -c, steht ab Werk auf 0, was loaded from model bedeutet, also aus dem Modell übernommen: der längste Kontext, für den das Modell trainiert wurde. Bei qwen3-4b-2507 sind das 262.144 Tokens.

Was passiert, wenn das nicht passt, unterscheidet sich von vLLM, das dann den Start verweigert. llama.cpp hat --fit, ab Werk eingeschaltet, und es passt jede Einstellung an, die Sie nicht selbst gesetzt haben, in dieser Reihenfolge: Zuerst verkleinert es den Kontext, bis zu einer Untergrenze von 4.096 Tokens; dann entscheidet es, wie viele Schichten auf die GPU kommen, legt den Rest in den Arbeitsspeicher des Systems und lässt auf jedem Gerät 1.024 MiB frei. -ngl, die Zahl der Schichten auf der GPU, steht ab Werk auf auto und überlässt diese Entscheidung damit --fit; auch Flash Attention, -fa, steht ab Werk auf auto.

Der Server startet also, aber nicht unbedingt mit dem Kontext, den Sie erwartet haben, und womöglich mit einem Teil des Modells auf dem Prozessor, was langsamer ist. Die Abhilfe: sagen, was Sie wollen.

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

Unser Modellfinder und unsere Rechner-Datenblätter rechnen alles mit 8.192 Tokens, und mit -c 8192 verhält sich llama.cpp genau so wie die Zahlen auf unserer Website. So groß ist der Unterschied auf unseren 3 Beispielrechnern, jedes Modell in Q4_K_M:

Rechner (Speicher für das Modell)	Modell	Bedarf bei 8.192 Tokens	Bedarf beim eigenen Maximum des Modells	Längster Kontext, der passt (Cache in 16 Bit)
RTX 4060 8 GB (7,20 GiB)	qwen3-4b-2507	4,20 GiB	43,73 GiB bei 262.144 (davon 36,0 GiB Cache)	16.384
RTX 4060 8 GB (7,20 GiB)	qwen3-8b	6,56 GiB, knapp	11,66 GiB bei 40.960	8.192
RTX 3060 12 GB (11,20 GiB)	gemma4-12b	7,82 GiB	16,35 GiB bei 262.144	65.536
Mac mit M4 und 16 GB (13,00 GiB)	gpt-oss-20b	11,77 GiB, knapp	16,83 GiB bei 131.072	32.768

Unsere Rechnung mit der Engine hinter unserem Modellfinder: Modelldatei in Q4_K_M, dazu der KV-Cache aus dem tatsächlichen Attention-Aufbau jedes Modells, dazu Speicher zum Rechnen; Modelldaten vom 30. September (bei gemma4-12b vom 15. Oktober) und Rechnerdaten vom 1. Oktober 2026. „Längster Kontext“ ist der größte Wert aus 4.096, 8.192, 16.384 … bis zum Maximum des Modells, der noch passt. Das ist nicht der eigene --fit-Algorithmus von llama.cpp, der zusätzlich Schichten in den RAM verlagern kann.

qwen3-4b-2507Modell-Datenblatt→ gemma4-12bModell-Datenblatt→

Keines der 4 Modelle passt mit seinem eigenen Maximum auf den Rechner in seiner Zeile. Verlangen Sie auf einer 4060 den vollen Kontext von qwen3-4b-2507, bräuchte es mehr als das 5-Fache der Karte (ein 4B-Modell mit Rechenzentrumsträumen, man muss es fast gernhaben).

Soll llama.cpp Ihnen lieber Bescheid sagen, statt selbst zu entscheiden, schaltet --fit off die Anpassung ab, und -ngl all verlangt alle Schichten auf der GPU. Auch ein ausdrückliches -c 0 schaltet das Kürzen des Kontexts ab: Sie bekommen den vollen Kontext, oder die Schichten wandern in den RAM.

Wie Sie es abschotten: offenes CORS, kein Schlüssel und ein neuer Port

Ab Werk lauscht llama serve nur auf 127.0.0.1, auf Port 9931 (8080 in v0.6.0 und älteren Versionen). Wir haben den Socket auf unserem Server geprüft: nichts auf den anderen Netzwerkschnittstellen. Das ist die gute Nachricht, und damit steht llama.cpp an der Seite von Ollama, LM Studio und MLX, nicht an der von vLLM.

Der Rest braucht Ihre Aufmerksamkeit:

• Kein Schlüssel. Wer den Port erreicht, kann ihn benutzen.
• CORS spiegelt jeden Ursprung, mit Credentials. Wir haben eine Anfrage mit dem Header Origin: https://some-site.example geschickt, und der Server antwortete mit Access-Control-Allow-Origin: https://some-site.example und Access-Control-Allow-Credentials: true. Auf gut Deutsch: Eine Webseite, die Sie in Ihrem Browser öffnen, kann Anfragen an Ihren lokalen Server schicken und die Antworten lesen, solange er läuft. Der Server warnt beim Start selbst davor: security: no API key is set and CORS allows all origins, also kein API-Schlüssel gesetzt und CORS für alle Ursprünge offen.
• Die Chatseite ist an, ab Werk, auf demselben Port.

Was es schließt:

export LLAMA_API_KEY="ein-langer-zufallsstring"
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF -c 8192 --cors-origins localhost

• --cors-origins localhost lässt nur Seiten mit ihm sprechen, die von localhost ausgeliefert werden. Eine Liste genauer Ursprünge, durch Kommas getrennt, geht ebenfalls.
• LLAMA_API_KEY oder --api-key sorgt dafür, dass Clients den Schlüssel als Bearer-Token mitschicken müssen. Die Variable hält den Schlüssel aus der Prozessliste heraus. --api-key-file liest mehrere Schlüssel aus einer Datei.
• --no-ui schaltet die Chatseite ab, wenn Sie nur die API wollen.

Der Port. Der angekündigte Wechsel ist jetzt auch im stabilen Kanal angekommen: Der Standardport ist 9931 in v0.7.0, veröffentlicht am 15. Oktober 2026, und in den täglichen Builds seit b11521 (9. Oktober). v0.6.0 und die früheren Builds lauschen auf 8080 und geben dabei notice: server default port will be changed to :9931 in a future release aus; seit b11521 fehlt dieser Hinweis. Seit dem 16. Oktober 2026 installiert Homebrew 0.7.0: Ist bei Ihnen noch eine ältere 0.6.0 installiert, bringt Sie brew upgrade von 8080 auf 9931. Die Docker-Images des Projekts behalten 8080 im Container. Hängen Ihre Skripte an 8080, schreiben Sie --port 8080 hinein, dann verschiebt ihn kein Update. --host akzeptiert außerdem den Pfad zu einem UNIX-Socket, der auf .sock endet, und seit v0.5.0 mehrere Adressen, durch Kommas getrennt.

Was llama.cpp von sich aus sendet, und was hinausgeht, wenn Sie es verlangen

Von sich aus: nichts. Wir haben den Code von Build b11321, aus dem Engine, Server, Terminal-Client und Weboberfläche bestehen, nach Bibliotheken für Analyse, Telemetrie und Tracking durchsucht und keine gefunden. Die Adressen, die in diesem Code stehen, sind Links in Meldungen und Hilfetexten, dazu die Dienste unten, und jeder davon wird erst kontaktiert, wenn Sie den Befehl dazu geben. Als wir den Server ohne Modell und mit leerem Home-Ordner gestartet haben, zeigte sein Log keine einzige ausgehende Anfrage, und der Ordner blieb leer. Das ist, was wir gelesen und im Log gesehen haben; den Netzwerkverkehr haben wir nicht mitgeschnitten.

Was hinausgeht, wenn Sie es verlangen:

• Modell-Downloads mit -hf, --model-url oder llama download gehen an huggingface.co. Die Anfrage weist das Programm als llama-cpp/ plus Build-Nummer und Commit aus und trägt Ihr HF_TOKEN mit, falls Sie eines gesetzt haben.
• Modelle, die als Container-Images verpackt sind, gehen nur mit --docker-repo an die Registry von Docker.
• llama update lädt, nur bei Installationen über das Skript von llama.app, genau dieses Skript erneut herunter und führt es aus.

Wo die Modelle landen. Im Standard-Cache von Hugging Face, ~/.cache/huggingface/hub, mit derselben Ordnerstruktur, die die Werkzeuge von Hugging Face selbst verwenden: Ein Modell, das Sie schon mit einem anderen Programm geladen haben, wird also nicht doppelt heruntergeladen. LLAMA_CACHE, HF_HUB_CACHE oder HF_HOME verschieben ihn. Liegen Ihre Modelle dort, zwingt --offline (oder LLAMA_ARG_OFFLINE=1) llama.cpp, den Cache zu nutzen, und unterbindet den Netzzugriff.

Wo die Chats landen. Die Chatseite speichert Ihre Gespräche im Speicher Ihres Browsers, nicht in einem Ordner auf dem Server, so steht es in unserem Audit im Datenblatt. Löschen Sie die Website-Daten im Browser, sind sie weg. Der Prompt-Cache des Servers liegt im RAM, ab Werk höchstens 8.192 MiB, und wird nicht auf die Platte geschrieben, sofern Sie es nicht verlangen.

Die Reihenfolge, die Ihnen ein funktionierendes und abgeschottetes llama.cpp hinterlässt:

1. Den Kanal wählen: brew install llama.cpp für die stabile Version oder den genauen Build für Ihren Rechner von der Releases-Seite auf GitHub.
2. Mit llama --version prüfen und die Build-Nummer notieren.
3. LLAMA_API_KEY vor dem ersten llama serve setzen.
4. Mit -c 8192 --cors-origins localhost starten und --port 8080 ergänzen, falls irgendetwas am alten Port hängt (seit v0.7.0 ist 9931 der Standard).
5. Passt das Modell nur knapp, -ctk q8_0 -ctv q8_0 ergänzen, bevor Sie den Kontext senken.
6. Sobald Ihre Modelle heruntergeladen sind, --offline ergänzen.

Die anderen Anleitungen dieser Reihe behandeln MLX auf dem Mac mit mlx-lm einrichten, und sehen, was es sendet und vLLM auf dem eigenen Rechner einrichten, und sehen, was es sendet, und die 5 Programme stehen direkt nebeneinander unter 5 Programme für lokale KI: Telemetrie, Aufrufe, Audit. Wenn Sie zwischen llama.cpp und Ollama schwanken, das intern den Server von llama.cpp startet, stellt unser Vergleich llama.cpp vs. Ollama ihre Werkseinstellungen nebeneinander.