llama.cpp funktioniert nicht? 8 Fehler, die genaue Meldung und die Lösung

Wenn llama.cpp streikt, nennt das Log meist den Schuldigen: ein belegter Port (8080 oder 9931, je nach Build), ein Build ohne GPU-Unterstützung, ein Modell, das neuer ist als Ihr Build, eine Datei, die kein GGUF ist, zu wenig Speicher, ein zu großer Kontext, eine unlesbare Chat-Vorlage oder ein altes CMake-Flag. Hier sind alle 8, mit Lösung.

llama.cpp ist die Engine unter vielen lokalen KI-Programmen, und sie direkt zu starten, fühlt sich an, als hätte man den Deckel von der Maschine genommen: volle Kontrolle, jedes Flag in Ihrer Hand. Der Preis dafür: Wenn etwas schiefgeht, übersetzt Ihnen niemand die Meldung. Wir haben jede Meldung dieser Anleitung am 15. und 16. Oktober 2026 im Code von llama.cpp v0.7.0 geprüft, der stabilen Version vom 15. Oktober (Build b11669), und im Code des täglichen Builds b11658. Ausgelöst haben wir diese Fehler heute auf keinem Rechner: Sie stammen direkt aus dem Quellcode, Zeile für Zeile. Installation und erstes Modell stehen in unserer Anleitung zur Einrichtung von llama.cpp; diese Seite setzt dort an, wo jene aufhört.

llama.cppProgramm-Datenblatt→

„couldn’t bind HTTP server socket“: Der Port ist belegt (und welcher Port überhaupt?)

Sie starten den Server, und er bricht sofort ab mit:

… start: couldn't bind HTTP server socket, hostname: 127.0.0.1, port: 9931

Auf dieser Adresse und diesem Port lauscht schon etwas anderes: eine zweite Kopie von llama.cpp, die Sie in einem anderen Terminal vergessen haben, ein Programm, das denselben Port nutzt, oder der vorige Lauf, der sich noch nicht ganz verabschiedet hat. Die Lösung: Entweder Sie beenden den anderen Prozess, oder Sie wählen mit --port 8081 einen anderen Port (jede freie Nummer geht).

Und jetzt kommt die Wendung, die diesen Monat viele erwischt. Der Standardport hat sich geändert. Bis zur v0.6.0, die Homebrew bis zum 16. Oktober 2026 installierte, lauscht der Server auf 8080. Seit dem täglichen Build b11521 (9. Oktober 2026) und in der stabilen v0.7.0 (15. Oktober) lauscht er standardmäßig auf 9931. Haben Sie einen täglichen Build oder die v0.7.0 installiert (auch per brew install oder brew upgrade seit dem 16. Oktober), klopfen Ihr Lesezeichen im Browser und jede App, die auf http://127.0.0.1:8080 zeigt, jetzt an eine leere Tür, und die Fehlermeldung verrät Ihnen davon nichts. Zwei Auswege: Starten Sie mit --port 8080, um die alte Adresse zu behalten, oder stellen Sie Ihre Apps auf 9931 um. Sobald das Modell geladen ist, schreibt der Server eine Zeile wie listening on http://127.0.0.1:9931 ins Log: Vertrauen Sie dieser Zeile, nicht Ihrem Gedächtnis.

Unter Linux zeigt ss -ltnp | grep 9931 (oder 8080), wer den Port hält; unter macOS lsof -i :9931; unter Windows netstat -ano | findstr 9931.

„warning: no usable GPU found, --gpu-layers option will be ignored“

Sie haben mit -ngl Schichten auf der Karte verlangt, und llama.cpp antwortet:

warning: no usable GPU found, --gpu-layers option will be ignored
warning: one possible reason is that llama.cpp was compiled without GPU support
warning: consult docs/build.md for compilation instructions

Die Meldung ist ehrlich: Meistens läuft bei Ihnen ein reiner CPU-Build. llama.cpp veröffentlicht für jeden Beschleuniger ein eigenes Paket: CPU, CUDA, Vulkan, ROCm, SYCL, OpenVINO für Windows und Linux, und Metal für Macs mit Apple Silicon. Haben Sie das „cpu“-Zip heruntergeladen, ist die Karte absichtlich unsichtbar. Laden Sie das Paket, das zu Ihrer Karte passt (bei NVIDIA das CUDA-Paket zusammen mit dem passenden cudart-Paket), oder bauen Sie mit der richtigen Option neu (siehe den CMake-Abschnitt weiter unten).

Wird die Karte erkannt, steht das früh im Log, in einer Zeile wie ggml_cuda_init: found 1 CUDA devices (Total VRAM: …). Keine solche Zeile und auch keine Warnung? Dann haben Sie -ngl gar nicht angegeben (Standardwert auto), die Warnung hatte also keine Gelegenheit zu erscheinen, und wahrscheinlich läuft ein reiner CPU-Build. Starten Sie einmal mit -ngl all: Fehlt dem Build die GPU-Unterstützung, sagt Ihnen das die Warnung oben.

Zwei Fälle, in denen auch das richtige Paket nicht reicht. Auf einem Mac mit Intel-Prozessor ist das offizielle Binary ohne Metal gebaut und läuft deshalb nur auf der CPU. Und auf einer AMD-Karte läuft das CUDA-Paket nur auf der CPU: Dort brauchen Sie das ROCm- oder das Vulkan-Paket.

„unknown model architecture“: Das Modell ist neuer als Ihr Build

Das Modell lädt herunter, und dann bricht das Laden ab mit:

llama_model_load: error loading model: unknown model architecture: 'xxxx'

gefolgt von failed to load model. Die GGUF-Datei sagt, zu welcher Modellfamilie sie gehört, und Ihr Build kennt diese Familie noch nicht. Die Datei ist nicht kaputt: Es ist ein Kalenderproblem. llama.cpp nimmt fast jede Woche neue Familien auf, und ein Modell, das letzten Dienstag erschienen ist, braucht einen Build von nach letztem Dienstag.

Die Lösung ist ein Update. Da llama.cpp im Schnitt etwa 16 Builds am Tag veröffentlicht (481 in den 30 Tagen bis zum 23. Oktober 2026), ist „der neueste“ ein bewegliches Ziel, und das ist hier eine gute Nachricht: Der Build, der Ihr Modell kennt, existiert wahrscheinlich schon. Über Homebrew bekommen Sie den stabilen Kanal, der den täglichen Builds ein paar Wochen hinterherhinken kann; ist das Modell sehr neu, nehmen Sie einen täglichen Build von der Release-Seite oder über den Installer. Kennt auch der neueste Build den Namen nicht, wird das Modell noch nicht unterstützt: Nehmen Sie solange eine andere Quantisierung einer unterstützten Familie.

„invalid magic characters … expected ‘GGUF’“ oder „failed to load model“

Diese Meldung ist kurz:

gguf_init_from_reader: invalid magic characters: 'xxxx', expected 'GGUF'

Jede GGUF-Datei beginnt mit den 4 Buchstaben GGUF. Fehlen sie, liest llama.cpp kein GGUF. Die üblichen Verdächtigen: Sie haben auf eine .safetensors-Datei oder einen ganzen Hugging-Face-Ordner gezeigt (llama.cpp lädt nur GGUF), Sie haben die Download-Seite statt der Datei gespeichert, oder der Download ist auf halbem Weg stehen geblieben. Bekommen Sie stattdessen failed to read magic, ist die Datei leer oder fehlt.

Die allgemeinen Meldungen failed to load model from … und failed to load model '…' kommen immer mit einer genaueren Zeile direkt darüber: Lesen Sie die. Ein Tippfehler im Pfad ist eine häufige Ursache.

Am einfachsten umgehen Sie das alles, indem Sie llama.cpp das Modell selbst holen lassen: -hf user/model:Q4_K_M lädt das GGUF von Hugging Face in den gemeinsamen Cache, jedes Mal mit der richtigen Datei.

qwen3-8bModell-Datenblatt→

„cudaMalloc failed: out of memory“ oder „failed to allocate buffer for kv cache“

Auf einer NVIDIA-Karte sieht zu wenig Speicher so aus:

ggml_backend_cuda_buffer_type_alloc_buffer: allocating … MiB on device 0: cudaMalloc failed: out of memory

und manchmal, direkt nachdem das Modell geladen ist:

failed to allocate buffer for kv cache

Auf einem Mac lautet dieselbe Wand failed to allocate Metal buffer of … bytes (out of memory). Die erste Zahl sagt Ihnen, wie viel reserviert werden sollte; die Ursache ist eine von dreien. Die Gewichte des Modells passen nicht auf die Karte (etwa ein 14B-Modell auf 8 GB). Der Kontext-Cache passt nicht (mehr dazu weiter unten). Oder etwas anderes belegt die Karte: ein Spiel, ein Browser mit Hardwarebeschleunigung, eine weitere Kopie von llama.cpp, Ollama im Hintergrund.

Die Lösungen, die einfachste zuerst: Schließen Sie die anderen Programme; senken Sie den Kontext mit -c 8192; lassen Sie mit einem kleineren -ngl weniger Schichten auf der Karte (der Rest wandert in den RAM, langsamer, aber es läuft); speichern Sie den Cache mit -ctk q8_0 -ctv q8_0 in 8 Bit; oder wechseln Sie zu einer kleineren Quantisierung desselben Modells. Der Modellfinder sagt Ihnen vorab, welches Modell in welcher Quantisierung mit dem gewünschten Kontext auf Ihre Karte passt.

„failed to fit params to free device memory“: Der Standardkontext ist das Maximum des Modells

Das ist das Problem, das nicht nach einem Problem aussieht. llama.cpp startet, antwortet, und trotzdem stimmt etwas nicht: Es ist langsamer als erwartet, oder ein langes Dokument kommt mit request (… tokens) exceeds the available context size (… tokens), try increasing it zurück. Schuld ist der Standardkontext. Ab Werk lädt llama.cpp den vollen Kontext, mit dem das Modell trainiert wurde (genau das bedeutet -c 0), und dann passt ein Mechanismus namens --fit, standardmäßig aktiv, die Sache an den freien Speicher an: Zuerst verkleinert er den Kontext, bis zu einer Untergrenze von 4.096 Tokens, dann verschiebt er Schichten von der Karte in den RAM und lässt dabei immer 1.024 MiB pro Gerät frei. Jeder Schritt landet auf Trace-Ebene im Log, mit dem Standard-Log sehen Sie also nicht, warum; Sie sehen nur das Ergebnis, in einer Zeile wie n_ctx_seq (32768) < n_ctx_train (40960) -- the full capacity of the model will not be utilized. Scheitert die Anpassung selbst, kommt eine Warnung:

failed to fit params to free device memory: …

Das Gegenmittel: Entscheiden Sie den Kontext selbst, statt das --fit zu überlassen. Wählen Sie den Kontext, den Ihre Aufgabe braucht (8.192 Tokens reichen für Chat locker; lange Dokumente brauchen mehr), schreiben Sie ihn mit -c hin, und wenn Sie auf derselben Karte mehr davon wollen, ergänzen Sie -ctk q8_0 -ctv q8_0, was den Cache fast halbiert. Unsere Anleitung zur Einrichtung von llama.cpp und die Seite zur RTX 3060 nutzen denselben Rechner.

PC mit RTX 3060 12 GBHardware-Datenblatt→

„chat template parsing error“: Die Vorlage des Modells lässt sich nicht lesen

Das Modell lädt, aber der Server stoppt, bevor er zu lauschen beginnt, und im Log steht:

… init: chat template parsing error: …
please consider disabling jinja via --no-jinja, or use a custom chat template via --chat-template
for example: --no-jinja --chat-template chatml

Direkt danach folgt exiting due to model loading error. Jedes Modell bringt sein eigenes Rezept mit, um ein Gespräch in Text zu verwandeln, und llama.cpp liest es mit seiner Jinja-Engine, inzwischen standardmäßig aktiv (das alte Flag --jinja braucht es nicht mehr). Manche GGUF-Dateien enthalten Vorlagen mit Konstrukten, die sie noch nicht lesen kann. Die Meldung nennt Ihnen gleich beide Auswege: --no-jinja fällt auf die eingebauten Vorlagen zurück, und --chat-template chatml (oder ein anderer eingebauter Name) erzwingt eine. Läuft dasselbe Modell in einem neueren Build, machen Sie lieber ein Update: Die Unterstützung für Vorlagen verbessert sich fast so schnell wie die für Modelle.

Antworten, die wie Kauderwelsch aussehen, die Rollennamen wiederholen oder nie aufhören, gehören zur selben Problemfamilie, nur ohne Fehlermeldung: Probieren Sie zuerst ein GGUF aus dem offiziellen Repository des Modells.

Was die Vorlage wirklich an das Modell schickt, kann Ihnen der Server selbst zeigen. In diesem Video öffnet ein Entwickler die eingebaute Weboberfläche des Servers, schaltet das ausführliche Log ein und liest den genauen Prompt, den das Modell erhält, nachdem die Vorlage angewendet wurde:

CMake: „LLAMA_CUBLAS is deprecated, use GGML_CUDA instead“

Bauen Sie llama.cpp selbst nach einem alten Rezept, stoppt CMake schon beim ersten Schritt:

LLAMA_CUBLAS is deprecated, use GGML_CUDA instead

Das hier ist ein harter Fehler: Der Build geht nicht weiter. Die GPU-Optionen sind schon vor langer Zeit vom Präfix LLAMA_ zu GGML_ umgezogen, und alte Build-Befehle verwenden noch die alten Namen. Der moderne Befehl für NVIDIA lautet cmake -B build -DGGML_CUDA=ON und danach cmake --build build --config Release. Die anderen alten Namen (LLAMA_CUDA, LLAMA_METAL, LLAMA_NATIVE, LLAMA_SYCL…) funktionieren vorerst noch, mit einer Warnung wie LLAMA_CUDA is deprecated, use GGML_CUDA instead; stellen Sie sie um, bevor auch sie aufhören zu funktionieren.

Wo wir schon dabei sind: Ältere Builds nannten die Programme auch main und server. Diese Namen gibt es nicht mehr. Das heutige Paket enthält llama, mit llama serve und llama cli, und liefert weiterhin llama-server und llama-cli als eigene Programme mit. Scheitert ein Skript mit „command not found“, ist es meist nur das.

Und wenn Ihr Problem nicht dabei ist

3 Gewohnheiten lösen das meiste vom Rest. Notieren Sie die Build-Nummer, bevor Sie jemanden um Hilfe bitten: Viele Antworten hängen davon ab. Starten Sie neu mit dem kleinsten Modell, das Sie haben, und -c 4096: Läuft das, liegt das Problem beim Speicher, nicht bei llama.cpp. Und probieren Sie dasselbe GGUF in einem Programm, das es mit llama.cpp ausführt, etwa Ollama oder LM Studio: Läuft es dort, vergleichen Sie die Flags. Unser Vergleich llama.cpp vs. Ollama listet die Einstellungen auf, die Ollama für Sie wählt, etwa den Kontext und die Zahl gleichzeitiger Anfragen. Unsere Anleitungen für den Fall, dass Ollama nicht funktioniert und dass vLLM nicht funktioniert, behandeln deren eigene Fehler.

Wenn Sie lieber mit einer sauberen Installation neu anfangen, startet ein anderer Entwickler in diesem Video llama.cpp in Docker (mit einem Image für die CPU und einem für NVIDIA-Karten), von der ersten GGUF-Datei bis zum Server und seiner Weboberfläche. Es wurde mit Port 8080 und den Flags von damals aufgenommen: Weicht ein Befehl darin von dieser Seite ab, halten Sie sich an die Seite.