Llama.cpp V1.0.0 legt Regeln für die API-Stabilität lokaler KI-Tools fest

ggml-org kündigte llama.cpp v1.0.0 an – damit erhielt das C/C++-Projekt für lokale KI-Inferenz am 13. November 2026 einen verbindlichen Kompatibilitätsrahmen für nachgelagerte Entwickler. Auch die zugrunde liegende ggml-Tensorbibliothek erreichte Version 1.0.0. Das Projekt meldet Unterstützung für mehr als 150 Varianten von Modellarchitekturen und für alle gängigen Methoden der spekulativen Dekodierung.

Versionierung wird zu einer öffentlichen Verpflichtung

Beide Projekte werden künftige Inkompatibilitäten der API auf Quelltextebene und der ABI – der binären Schnittstelle, die kompilierte Anwendungen verwenden – durch Erhöhungen der Hauptversionsnummer signalisieren. Änderungen an der öffentlichen C-API, die die Kompatibilität beeinträchtigen, führen zu einer neuen Hauptversion. Rückwärtskompatible Funktionen, Aktualisierungen von Backends, Unterstützung für Modelle und API-Erweiterungen führen zu einer neuen Nebenversion; Fehlerbehebungen ohne API-Änderungen erhöhen hingegen die Patch-Version.

Die Richtlinie folgt auf 3,5 Jahre Entwicklungsarbeit und die zunehmende Abhängigkeit von den Bibliotheksschnittstellen des Projekts. llama.cpp ermöglicht multimodale LLM-Inferenz über libllama, während ggml die Tensor-Ebene für maschinelles Lernen über libggmlDie Software nutzt Quantisierung, optimierte Backends und portablen C/C++-Code, um Hardware von Verbrauchergeräten bis hin zu Unternehmensservern zu unterstützen.

So erhalten Paketbetreuer und Anwendungsentwickler ein Versionssignal, anhand dessen sie einschätzen können, ob ein Upgrade ihre Integration beeinträchtigen könnte. Die Diskussion der Maintainer vom 7. August 2026 zum Release-Prozess ergänzt eine entsprechende Schutzmaßnahme: Ein offizielles llama.cpp-Release-Tag wird nur erstellt, wenn die darin enthaltene ggml-Kopie mit der veröffentlichten ggml-Kopie identisch ist. Diese Bedingung soll sicherstellen, dass Builds mit einem Release-Tag mit einer systemweit installierten ggml-Version kompatibel sind – so, wie es bei den im Dokument beschriebenen Debian- und Homebrew-Paketen der Fall ist.

Änderungen an Laufzeit, Modellen und Server

Die Versionshinweise zu llama.cpp v1.0.0 verbinden diesen Kompatibilitätsrahmen mit einer umfassenden Bereinigung. Das Release entfernt die veraltete öffentliche API, darunter 35 veraltete Funktionen, und überführt zugleich die API für spekulative NextN-Dekodierung aus dem llama-ext.h Erweiterungsheader in den öffentlichen llama.h Header. Damit wird diese Schnittstelle für spekulative Dekodierung Teil der öffentlichen API, für die die neuen Versionsregeln gelten.

Zu den neuen Inferenzfunktionen gehören OCP-8-Bit-Gleitkomma-Schlüssel-Wert-Caches (FP8), ein Host-Speichercache für Mixture-of-Experts-Modelle (MoE) mit konfigurierbarem CPU-Anteil sowie das Laden externer PLE- oder Engram-Daten aus separaten GGUF-Shards. Zu den neu unterstützten Modellen zählen die Textarchitekturen Kimi-K3.1-Pro, Ripple und xing4_0, die Text-zu-Sprache-Architektur drama-3 sowie die Vision-Unterstützung für MageVL-Cowork und Kimi-K3.1.

Für llama-server behebt das Release Probleme mit serverseitiger Anforderungsfälschung, Cross-Origin Resource Sharing und DNS-Rebinding und beschränkt HF_TOKEN auf Hosts unter huggingface.co. MCP-Toolaufrufe werden abgebrochen, wenn ein Client die Verbindung trennt oder eine Zeitüberschreitung auftritt; der MCP-Server wird darüber benachrichtigt. Ein neuer OpenAI-kompatibler /v1/audio/speech Endpunkt erweitert die Audio-Schnittstelle des Servers.

Die neu gestaltete Weboberfläche bietet benannte Chatgruppen und einen Markdown-Editor mit Live-Vorschau. Die mobilen Layouts berücksichtigen die sicheren Bildschirmbereiche des Geräts und verwenden Dialoge im Vollbildmodus. Im Chat-Editor für Android lässt sich außerdem die virtuelle Tastatur öffnen.

Hardware-Backends und Release-Infrastruktur

Das begleitende ggml-Release v1.0.0 entfernt veraltete APIs und ältere DIAG_MASK-Operationen, ergänzt konfigurierbare YaRN-Trunkierung und FP8-Unterstützung und vermeidet das Hochladen von Scheduler-Eingaben, die nicht gelesen werden. CUDA und Metal erhalten Matrixmultiplikation mit quantisierten Matrizen und wenigen Zeilen sowie Verbesserungen bei der MoE-Fusion. Weitere Ergänzungen für Backends sind ein Intel-Vulkan-Prefill-Kernel für FlashAttention, ein geräteseitiger SYCL-MoE-Scheduler, eine zerlegte Adreno-FlashAttention-Implementierung in OpenCL, neue WebGPU-Kernel und eine erweiterte Abdeckung von Hexagon-Operationen.

Jedes ggml-Backend lässt sich als dynamische Bibliothek kompilieren und optional zur Laufzeit laden. So können Installationen hardwarespezifischen Code auswählen. Vorabversionen gibt es für Linux, macOS, Windows, Android und iOS. Docker, Debian, Homebrew, conda-forge, MacPorts, Winget und XCFramework bieten weitere Vertriebswege, deren Plattformabdeckung variiert.

Um mit dem Entwicklungstempo Schritt zu halten, skalieren Hugging Face Buckets und Jobs laut Team die Kapazitäten für kontinuierliche Integration von Änderungen, die in den master-Branches landen. Die Hardwareunterstützung durch NVIDIA, AMD, Qualcomm, Arm, IBM und Intel ermöglicht zudem mehr selbst gehostete Runner auf wichtigen Hardwareplattformen. Auch die Maintainer integrieren LLMs in ihren Entwicklungszyklus. Dabei nennen sie Codequalität, architektonische Kontrolle und das Verständnis der Implementierungsdetails als ihre Prioritäten.

Für nachgelagerte Projekte macht das Release die Kompatibilität zu einer ausdrücklichen Entwicklungsverpflichtung bei einer schnelllebigen Open-Source-Bibliothek. Versionsregeln können auf inkompatible Änderungen hinweisen; das ausgebaute CI- und Hardware-Runner-Programm hilft dabei, festzustellen, ob reguläre Releases über die Modelle und Hardware hinweg zuverlässig bleiben, die diese Projekte verwenden.