Kurz gesagt
- llama.cpp v1.0.0 ist die erste 1.0-Version der Bibliothek libllama für die LLM-Inferenz mit C/C++.
- Auch die Tensorbibliothek für maschinelles Lernen ggml wurde auf v1.0.0 aktualisiert.
- Rückwärtsinkompatible API- und ABI-Änderungen werden künftig durch die Hauptversionsnummer gekennzeichnet.
- llama.cpp unterstützt mehr als 150 Varianten von Modellarchitekturen und gängige spekulative Decoding-Verfahren.
Das Team von ggml-org hat am 13. November 2026 im Hugging-Face-Blog die Versionen 1.0.0 der Bibliotheken llama.cpp und ggml angekündigt. Die Projekte zielen darauf ab, multimodale große Sprachmodelle auf unterschiedlicher Hardware auszuführen – vom lokalen Computer bis zum Unternehmensserver. Mit diesen Versionen sollen API- und ABI-Kompatibilität künftig klarer über die Hauptversionsnummern verwaltet werden.
Beide Bibliotheken erreichen Version 1.0.0
llama.cpp stellt mit libllama eine Bibliothek für die Inferenz großer Sprachmodelle mit C und C++ bereit. Die Tensorbibliothek für maschinelles Lernen ggml wird unter dem Namen libggml veröffentlicht. Die öffentlichen Header-Dateien der beiden Projekte finden sich in den Verzeichnissen llama.cpp/include/ beziehungsweise ggml/include/.
Das Team erklärt, dass im Laufe der dreieinhalbjährigen Entwicklung zahlreiche weitere Anwendungen von diesen Bibliotheken abhängig geworden sind. Die Ankündigung von Version 1.0.0 ist daher nicht nur eine Änderung der Versionsnummer, sondern auch ein Versprechen zu einer Versionsstrategie, die es Entwicklern erleichtern soll, Änderungen an den Schnittstellen der Bibliotheken nachzuverfolgen.
Wie werden API- und ABI-Änderungen gekennzeichnet?
Nach den Regeln der semantischen Versionierung für die Projekte von ggml-org erfordern Änderungen, die die öffentliche C-API beeinträchtigen, einen Sprung der Hauptversion. Rückwärtskompatible Funktionen, Aktualisierungen von Backends, Unterstützung für neue Modelle oder API-Erweiterungen erscheinen als kleinere Versionsnummer; Fehlerbehebungen ohne API-Änderungen als Patch-Version.
Diese Richtlinie soll anhand der Versionsnummer erkennen lassen, bei welchen Updates bestehende Integrationen besonders sorgfältig geprüft werden sollten. Das Team kündigt an, API- oder ABI-Inkompatibilitäten durch einen Wechsel der Hauptversion sichtbar zu machen. In der Ankündigung wird allerdings weder ein konkreter Migrationsleitfaden für den Wechsel zu Version 1.0.0 noch eine individuelle Kompatibilitätsliste für jede Integration bereitgestellt.
Unterstützung für Hardware und Modelle
Das zugrunde liegende ggml nutzt spezielle Backends, damit llama.cpp auf verschiedenen Hardwaretypen ausgeführt werden kann. Diese Backends lassen sich als dynamische Bibliotheken kompilieren und bei Bedarf zur Laufzeit laden. Die Ankündigung verweist außerdem auf eine vollständige Liste der unterstützten Backends.
Dem Projekt zufolge unterstützt llama.cpp derzeit mehr als 150 Varianten von Modellarchitekturen sowie gängige spekulative Decoding-Verfahren. Für die Bereitstellung werden Vorabversionen für Linux, macOS, Windows, Android und iOS aufgeführt. Hinzu kommen Docker und Debian für Linux, Homebrew und MacPorts für macOS sowie Winget für Windows. conda-forge deckt Windows, macOS und Linux ab; XCFramework ist für iOS und macOS gelistet. Diese Angaben zeigen die in der Ankündigung genannten Distributionskanäle – sie bedeuten nicht, dass in jedem Kanal gleichzeitig ein stabiles 1.0.0-Paket verfügbar ist.
Bedeutung für Architektur- und Visualisierungsteams
Entwickler, die lokale KI-Tools in ihre eigene Software integrieren, können direkt von der Versionsstrategie von llama.cpp profitieren. Für Architekturbüros und Visualisierungsteams liegt der mögliche Vorteil darin, Updates der Bibliotheken, die in eigens entwickelten lokalen KI-Anwendungen zum Einsatz kommen, kontrollierter bewerten zu können. Die Ankündigung umfasst weder eine Integration in eine bestimmte Architektursoftware noch eine fertige Designfunktion.
Bei der Hardware stehen der breite Plattformansatz und separate Backends im Vordergrund; konkrete Leistungsmessungen für bestimmte Hardware nennt die Quelle jedoch nicht. Teams sollten daher prüfen, ob das verwendete Backend und die Modellarchitektur auf ihren Computern unterstützt werden, und ein Versionsupgrade mit den vorhandenen Integrationen testen. Die aufgeführten Distributionskanäle geben zwar Auskunft über die verfügbaren Bezugswege, doch Lizenzierung, Bedingungen für Unternehmenssupport und Veröffentlichungszeitpläne der Pakete je Kanal werden in der Ankündigung nicht erläutert.
Quellen
1 QuelleQuelltexte werden nicht neu veröffentlicht; kurze Zitate sind gekennzeichnet, der Rest ist eigene Zusammenfassung und Einordnung.
Die Versionen 1.0.0 von llama.cpp und ggml können Teams, die lokale KI-Komponenten in ihre eigenen Tools integrieren, die Versionsverwaltung erleichtern. Besonders in Büros, die dieselbe Bibliothek in mehreren Projekten einsetzen, hilft die Kennzeichnung inkompatibler Änderungen durch eine neue Hauptversion bei der Updateplanung.
Für Architektur- und Visualisierungsteams in der Türkei bedeutet diese Ankündigung allein noch kein fertiges Produktionswerkzeug. Ein praktischer Nutzen entsteht, wenn eine Anwendung oder ein Workflow mit lokalen Modellen entwickelt wird. Statt ein Upgrade vorzunehmen, ohne die Hardwarekompatibilität, das gewählte Backend und den Paketstatus im jeweiligen Distributionskanal zu prüfen, empfiehlt sich ein kontrollierter Test.
Häufige Fragen
Wann wurde llama.cpp v1.0.0 veröffentlicht?
ggml-org hat llama.cpp v1.0.0 am 13. November 2026 angekündigt. Dieselbe Ankündigung umfasste auch ggml v1.0.0.
Welche Änderungen bringt llama.cpp v1.0.0?
Die wichtigste Neuerung: API- und ABI-Inkompatibilitäten werden durch einen Sprung der Hauptversion gekennzeichnet. Die Versionsregeln ordnen kompatible Funktionen und Backend-Updates außerdem kleineren Versionsnummern zu, Fehlerbehebungen ohne API-Änderungen der Patch-Version.
Auf welchen Plattformen lässt sich llama.cpp verwenden?
In der Ankündigung sind Vorabversionen für Linux, macOS, Windows, Android und iOS aufgeführt. Zu den weiteren Distributionsoptionen zählen Docker, Debian, Homebrew, conda-forge, MacPorts, Winget und XCFramework.
