llama.cpp v1.0: Was sich ändert und wie du aktualisierst

Mit llama.cpp v1.0.0 ist am 13. November 2026 erstmals ein stabiler Release nach dem SemVer-Schema erschienen. Änderungen an der öffentlichen C-API, die inkompatibel sind, erfordern ab jetzt eine neue Hauptversion. Auf GitHub ist der Tag als Latest markiert. Die Release Notes beschreiben v1.0 als Aufräum- und Kompatibilitätsrelease mit entfernten APIs, neuen Caches und zusätzlicher Modellunterstützung.

v1.0 ist ein Stabilitätsversprechen – kein Geschwindigkeitsschub

Laut dem Abschnitt zu API-Änderungen in den Release Notes gilt das Kompatibilitätsversprechen für die öffentliche C-API in llama.h. CLI-Flags, Server-Routen und das Verhalten von Nightly-Builds solltest du weiterhin als veränderlich betrachten. Für reproduzierbare Builds verwendest du den Tag v1.0.0; Nightly-Versionen pro Commit – auf der Release-Seite steht neben v1.0.0 auch das Nightly b12359 – sind nur dann sinnvoll, wenn du neuere Fehlerbehebungen brauchst.

„Heißt das, dass künftig auch die CLI-Parameter stabil bleiben, statt sich in jedem Release so stark zu ändern, dass sich letztlich keine App auf den Upstream verlassen kann?“ – u/halvacoffee auf r/LocalLLaMA

Vor dem Upgrade prüfen: 4 Stolperstellen für ältere Skripte und Integrationen

Diese Kompatibilitätsänderungen treffen ältere Setups am häufigsten. Suche zuerst nach den entsprechenden Stellen:

grep -rn "llama_set_warmup\|clip\.h\|--mmap\|--no-mmap\|--defrag-thold\|:8080\|localhost:8080" .

Prüfung 1: Entfernte C-Funktionen – Bindings aktualisieren

Laut den Release Notes entfernt v1.0 insgesamt 35 veraltete Funktionen aus llama.h, darunter llama_set_warmup. Zusätzlich verschwinden das Feld defrag_thold und die Option --defrag-thold. Ein Symbol wird umbenannt: Aus llama_set_embd_state_src wird llama_set_ctx_state_src. Außerdem wandert die NextN-API in llama.h. Die vollständige Liste der entfernten Funktionen findest du im oben verlinkten Release-Changelog.

Prüfung 2: Server-Port 8080 → 9931 – URLs anpassen

llama-server verwendet jetzt standardmäßig http://127.0.0.1:9931. Ältere Beispiele gehen dagegen von 8080 aus, wie auch der Axiomi-Setup-Guide dokumentiert. Passe Health-Checks und die Basis-URLs deiner Editoren an oder übergib --port 8080, wenn das bisherige Mapping erhalten bleiben soll.

Prüfung 3: --mmap wird abgelehnt – auf -lm-Lademodi wechseln

Wenn dein Build bei --mmap mit error: invalid argument: --mmap abbricht, verwendest du stattdessen die dokumentierte Option -lm, --load-mode. Unterstützt werden auto, none, mmap, mlock, mmap+mlock und dio. Starte mit -lm auto und prüfe das Verhalten anschließend mit llama-cli --help sowie einem repräsentativen Ladetest.

Prüfung 4: clip.h ist verschwunden – Vision-Code auf mtmd umstellen

Vision-Integrationen, die auf clip.h basieren, müssen auf das konsolidierte mtmd umgestellt werden. Laut den Release Notes teilt es Rechenpuffer zwischen mehreren Subkontexten. Bevor du deine Vision-Pipelines aktualisierst, solltest du im Abschnitt zur Multi-Modalität des Releases die Hinweise zu den einzelnen Modellen lesen.

Das ist in llama.cpp v1.0 neu

Für lokale Setups sind laut den Release Notes vor allem fünf Neuerungen relevant.

Installation als OpenAI-kompatibler Server

Die folgenden Schritte verwenden die neuen Standardeinstellungen – Port 9931, llama-cli beziehungsweise llama-server und Downloads über -hf – aus der offiziellen Installationsdokumentation und dem Axiomi-Setup-Guide.

1. Installieren:

curl -LsSf https://llama.app/install.sh | sh

Alternativ kannst du einen Paketmanager oder eine vorgefertigte ZIP-Datei von der Release-Seite verwenden. Prüfe die Installation mit llama-cli --version. Bei nicht unterstützter Hardware, eigenen Patches oder noch nicht gemergten Fixes solltest du stattdessen aus dem Quellcode bauen.

2. Im Terminal chatten:

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

Wie im Axiomi-Guide beschrieben, lädt -hf das Modell aus dem Hugging-Face-Cache. Fehlt ein :quant-Suffix, wird Q4_K_M gewählt. Die standardmäßig aktivierte Einstellung --fit on passt nicht gesetzte Werte an den verfügbaren Gerätespeicher an.

3. Eine lokale API bereitstellen:

llama-server -hf ggml-org/Qwen3.5-0.8B-GGUF -c 8192
# open http://127.0.0.1:9931

Zu den verfügbaren Routen gehören /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/messages und /v1/audio/speech (Routenliste von Axiomi). Für einen schnellen Funktionstest:

curl http://localhost:9931/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"Explain GGUF in one sentence."}]}'

Das Python-Beispiel im selben Guide verwendet für einen lokalen Einzelmodell-Server base_url="http://localhost:9931/v1" zusammen mit api_key="no-key". Für die lokale Nutzung solltest du 127.0.0.1 beibehalten.

v1.0, Nightly, Wrapper oder Hosted API: Was passt zu dir?

FAQ

Ist v1.0 stabil, und funktioniert mein bestehendes Setup weiterhin?

Das Stabilitätsversprechen gilt für die öffentliche C-API, nicht für CLI-Flags, Server-Routen oder Nightly-Builds. Suche vor dem Upgrade nach llama_set_warmup, clip.h, --mmap, --defrag-thold und fest hinterlegten Vorkommen von 8080.

Wie viel Speicher braucht ein 8B-Modell?

Die Größentabelle von Tech Insider nennt für ein 8B-Modell in Q4_K_M rund 4,9 GB gegenüber 32,1 GB im unquantisierten Zustand – jeweils vor Kontext und Laufzeitumgebung. Als Faustregel solltest du die Werte auf deinem eigenen System mit llama-bench messen, da sich CPU-Werte kleiner Modelle nicht übertragen lassen.

Für alles, was du auslieferst: v1.0 fest pinnen

Pinnen den Tag in deiner CI, lasse eine Maschine auf Nightly laufen und teste Wrapper vor dem Upgrade erneut gegen den festgelegten Server.