llama.cpp erreicht Version 1.0: Meilenstein für lokale KI auf dem eigenen Rechner

Das Open-Source-Werkzeug llama.cpp, auf dem auch Ollama und LM Studio aufbauen, ist in Version 1.0.0 erschienen. Neben neuen Modellen wie Kimi K3.1 Pro und Ripple bringt das Release FP8-Unterstützung, einen Experten-Cache für MoE-Modelle und viele Sicherheitskorrekturen am eingebauten Server.

Tools 13. Nov. 2026 6 Min. Lesezeit Quelle: Merkliste: ggml-org/llama.cpp
Symbolbild, KI-generiert

Worum es geht

Das Open-Source-Projekt llama.cpp hat am 13. November 2026 die Version 1.0.0 veröffentlicht. Zeitgleich wurde auch die Rechenbibliothek ggml, auf der llama.cpp aufbaut, auf 1.0.0 gesetzt. Damit springt das Projekt erstmals auf eine „Eins vor dem Komma“. Die vorherige nummerierte Version v0.9.0 ist erst vom 4. November. Der passende fortlaufende Build hat die Nummer b12359. Herunterladen kannst du alles auf der Release-Seite bei GitHub.

Die Release-Notiz selbst ist knapp: „Neue Version wurde veröffentlicht“ und „Mehr Infos um 15 Uhr MEZ“. Warum die Entwickler genau jetzt auf 1.0 gehen und ob damit Zusagen zur Stabilität verbunden sind, steht dort noch nicht. Ausführlich ist dagegen das Änderungsprotokoll seit v0.9.0 mit weit über 200 Einträgen. Was darin steckt, fassen wir hier zusammen.

Was llama.cpp ist und warum es so wichtig ist

llama.cpp ist ein schlankes Programm in C++, mit dem man Sprachmodelle auf normaler Hardware laufen lassen kann: auf dem Laptop, dem Gaming-PC, dem Mac oder sogar dem Smartphone. Das Projekt ist 2023 entstanden. Laut einem Blogbeitrag von NVIDIA hat es keine externen Abhängigkeiten und geht sehr sparsam mit Speicher um. Die Modelle liegen dabei im eigens dafür entwickelten Dateiformat GGUF, also einer einzelnen Datei, die das Modell samt Zusatzinfos enthält. Meist sind sie quantisiert: Das Modell wird verkleinert, indem seine Zahlen gröber gespeichert werden.

Viele Nutzer haben llama.cpp schon verwendet, ohne es zu wissen. Laut NVIDIA bauen beliebte Programme wie Ollama und LM Studio darauf auf, ebenso über 50 weitere Anwendungen, etwa der KI-Assistent Leo im Brave-Browser, die lokalen Modelle in Opera oder der Programmierassistent Sourcegraph Cody. NVIDIA selbst hat Optimierungen beigesteuert, zum Beispiel CUDA Graphs. Dabei werden Rechenschritte auf der Grafikkarte vorab gebündelt, damit zwischen ihnen weniger Leerlauf entsteht. Nach NVIDIAs eigenen Messungen schaffte eine RTX 4090 mit Llama 3 8B damals rund 150 Token pro Sekunde.

Neue Modelle: Kimi K3.1 Pro, Ripple und mehr Audio

Im Änderungsprotokoll stehen mehrere neue Modelle:

  • Kimi K3.1 Pro von Moonshot, als Textmodell und mit Bildverständnis („Kimi K3.1 vision“)
  • Ripple des Anbieters ricursiveai
  • xing4_0, MageVL-Cowork und Korrekturen für HunyuanVL, MiniCPM-V und die Qwen-VL-Bildmodule
  • Drama-3 als Sprachausgabe (Text-to-Speech) sowie eine Temperatur-Einstellung für Pocket TTS über die API
  • Audio-Eingabe als Datenstrom für Gemma 4

Wie lange es dauert, bis ein neues Modell bei normalen Nutzern ankommt, zeigt ein Blogbeitrag des japanischen Autors YaroTech auf note.com. Er hatte zunächst geschrieben, Ripple-65B werde noch nicht unterstützt, musste das aber korrigieren: Die Unterstützung war schon am 6. November in den Hauptzweig eingeflossen, Kimi K3.1 Pro folgte am 7. November mit Build b12180. In v0.9.0 waren beide noch nicht enthalten. Der Autor beschreibt fünf Stufen von „unterstützt“: Vorschlag, Übernahme in den Hauptzweig, tägliche Builds (b-Nummern), nummerierte Releases und schließlich die Aktualisierung in Programmen wie Ollama oder LM Studio. Mit v1.0.0 sind beide Modelle jetzt auf Stufe 4 angekommen.

Der Autor ordnet auch die Größen ein: Kimi K3.1 Pro ist insgesamt etwa 1,56 TB groß. Inoffizielle GGUF-Dateien von Freiwilligen liegen zwischen 580 GB und 1,51 TB und sind teils als „sehr experimentell“ gekennzeichnet. Auf einen Rechner mit 128 GB Arbeitsspeicher passt das nicht. Für Ripple-65B nutzte er eine Q3_K_M-Datei mit 31 GB. Sein Fazit für Kimi lautet: Die Werkzeuge sind fertig, aber es gibt keinen Platz dafür.

Technik unter der Haube: FP8, Experten-Cache und neue Hardware

Der Großteil der Änderungen betrifft Geschwindigkeit und Hardware-Unterstützung:

  • FP8-KV-Cache: Der KV-Cache ist das Kurzzeitgedächtnis des Modells für den bisherigen Gesprächsverlauf. Er kann jetzt im kompakten 8-Bit-Gleitkommaformat gespeichert werden. Bei langen Texten spart das Grafikspeicher. Dazu kommt OCP-FP8-Unterstützung unter CUDA.
  • MoE-Cache: Mixture-of-Experts-Modelle bestehen aus vielen Teilnetzen („Experten“), von denen pro Wort nur wenige rechnen. Ein neuer Cache hält häufig genutzte Experten auf der Grafikkarte. Fehlt ein Experte dort, rechnet stattdessen der Prozessor. Die Strategie zum Behalten heißt „LRFU/MQ-ähnlich“ und mischt, wie kürzlich und wie oft ein Experte gebraucht wurde. Ein Skript zum Feineinstellen liegt bei. Interessant ist das vor allem für Grafikkarten mit wenig Speicher.
  • NVIDIA: Mehrere Optimierungen für NVFP4-Modelle (ein 4-Bit-Format von NVIDIA), schnellere Matrixrechnungen bei kleinen Stapelgrößen, CUDA 13.5 für die Release-Builds und eine Korrektur für ältere Maxwell-Karten.
  • AMD: Optimierungen für RDNA3/4 unter Vulkan, ein besserer BLAS-Arbeitsspeicher unter ROCm und ein Rechenbaustein für Rechenzentrumskarten der CDNA2-Generation.
  • Intel: Ein Flash-Attention-Kernel für Vulkan beim Einlesen von Texten (Flash Attention ist ein speichersparendes Rechenverfahren für den Aufmerksamkeitsmechanismus), dazu viele SYCL-Korrekturen und ein MoE-Planer direkt auf der Grafikkarte.
  • Mobil und exotisch: Qualcomm Hexagon (Q5_0/Q5_1, Windows auf ARM), Adreno-Grafik über OpenCL, WebGPU, RISC-V-Chips von SpacemiT und IBMs zDNN-Beschleuniger.
  • Apple: Metal-Korrekturen gegen Speicherzugriffe außerhalb gültiger Bereiche und gebündelte MoE-Berechnung für DeepSeek-V4/V4.1 und GLM.

Dazu kommen Aufräumarbeiten. Einträge wie „llama : prune“, „ggml : prune“ und „examples : clean-up old/obsolete stuff“ deuten darauf hin, dass zum Versionssprung alter Ballast entfernt wurde. Wer eigene Skripte mit älteren Beispielprogrammen nutzt, sollte das prüfen.

Server und Weboberfläche: mehr Funktionen, mehr Sicherheit

Der eingebaute llama-server ist längst mehr als eine reine Programmierschnittstelle. Neu ist ein mit OpenAI kompatibler Endpunkt /v1/audio/speech für Sprachausgabe. Die Realtime-API wurde verbessert und meldet Fehler jetzt, statt abzustürzen. Werkzeugaufrufe über MCP (ein Standard, mit dem KI-Modelle externe Werkzeuge nutzen) werden abgebrochen, wenn der Client die Verbindung trennt.

Besonders wichtig sind die Sicherheitskorrekturen:

  • Eine SSRF-Lücke im CORS-Proxy und bei Medien-Adressen wurde geschlossen. SSRF bedeutet, dass ein Angreifer den Server dazu bringt, Anfragen an interne Adressen zu schicken.
  • Ein Schutz gegen DNS-Rebinding wurde ergänzt. Dabei lockt eine bösartige Website den Browser auf den lokalen Server um.
  • Werkzeuge müssen ausdrücklich freigeschaltet werden, wenn der Server nicht nur lokal erreichbar ist.
  • Der Hugging-Face-Zugangsschlüssel wird nur noch an huggingface.co-Adressen geschickt.

Wer llama-server im Heimnetz betreibt, sollte deshalb aktualisieren.

Auch die Weboberfläche hat einiges dazubekommen: Chats lassen sich in benannten Gruppen ordnen, es gibt ein Werkzeug zum Durchsuchen alter Chats, einen Markdown-Editor mit Live-Vorschau, Vorschaubilder für PDF-Anhänge und eine Bedienung, die sich auf dem Smartphone wie eine App anfühlen soll.

Was nicht drin ist: das Beispiel NUMA

Wie das Projekt Prioritäten setzt, zeigt ein älterer Beitrag bei Semiconductor Engineering. Darin beschreibt Arm einen Patch für Server mit mehreren NUMA-Knoten, also Prozessorgruppen mit jeweils eigenem Speicher. Auf einem Neoverse-N2-System brachte er bei der Textgenerierung bis zu 55 Prozent mehr Tempo (41,15 statt 26,52 Token pro Sekunde). Der Patch wurde laut dem Beitrag geprüft, aber nicht übernommen, weil das Interesse an Server- und Cloud-Szenarien gering sei. llama.cpp bleibt also klar auf lokale Nutzung ausgerichtet.

Einordnung

Der Sprung auf 1.0 ist vor allem ein Symbol: Ein Projekt, auf dem ein großer Teil der lokalen KI-Welt steht, sieht sich offenbar als ausgereift. Technisch ist v1.0.0 eher eine dichte Sammlung von Verbesserungen als ein radikaler Umbau. Für Nutzer zählen am meisten der MoE-Cache und der FP8-KV-Cache für knappen Grafikspeicher, die Unterstützung neuer Modelle und die Sicherheitskorrekturen am Server.

Offen ist bisher, was die angekündigten „weiteren Infos“ enthalten: ob es Zusagen zur Stabilität der Programmierschnittstelle gibt, wie stark die Aufräumarbeiten bestehende Projekte betreffen und wie schnell Ollama und LM Studio nachziehen. Wer die neuen Modelle sofort nutzen will, kann llama.cpp direkt installieren. Wer auf seine gewohnten Programme setzt, muss auf deren Updates warten. Und bei Riesenmodellen wie Kimi K3.1 Pro gilt weiterhin: Unterstützung heißt nicht, dass sie auf einen normalen Heim-PC passen.

Quellen

#llama.cpp#lokale ki#open source#gguf#moe
Originalquelle lesen

Frag den KI-Assistenten

Fragen zu diesem Artikel, zur Installation oder zu Hintergründen? Unser Assistent kennt diese Seite und läuft auf unserem eigenen Rechner, nicht in einer fremden Cloud.

Verbinde …

Der Assistent ist eine KI (Gemma 4) und kann sich irren – wichtige Angaben bitte in der Quelle prüfen. Fragen werden nur zum Beantworten genutzt und nach einer Stunde gelöscht. Bitte keine persönlichen Daten eingeben.

Kommentare

Was meinst du dazu? Schon ausprobiert? Schreib es hier, ohne Anmeldung.

  1. Kommentare werden geladen …

Kommentare sind öffentlich. Links sind nicht erlaubt, beleidigende Beiträge löschen wir. Deinen eigenen Kommentar kannst du in diesem Browser jederzeit wieder löschen. Mehr dazu in der Datenschutzerklärung.