Die lokale Inferenzbibliothek llama.cpp hat v1.0.0 veröffentlicht, und die zugrunde liegende Tensor-Bibliothek ggml ist zeitgleich auf 1.0 gewechselt. Das Projektteam schreibt im Hugging-Face-Blog, die Version solle Entwicklern, die davon abhängen, ein stabileres Fundament bieten: Sobald sich die öffentliche API oder ABI von llama.cpp und ggml inkompatibel ändert, schlägt sich das künftig in einer neuen Hauptversionsnummer nieder.
In den vergangenen Jahren wurde llama.cpp fast ausschließlich über Build-Nummern mit vorangestelltem b veröffentlicht: Jeder Merge in den Hauptzweig erzeugt einen neuen Build, inzwischen steht der Zähler bei über b12000. Nach 1.0 endet diese Zählung nicht, sie läuft weiter als Vorabversion. Neu ist eine zusätzliche, verbindliche Versionslinie, zwischen der Nutzer je nach Bedarf wählen können.
Versionsnummern haben jetzt eine Bedeutung
Die Regeln im Blog sind eindeutig: MAJOR steht für Änderungen, die die öffentliche C-Schnittstelle im Verzeichnis ./include brechen, MINOR für abwärtskompatible neue Funktionen oder Modellunterstützung, PATCH für reine Fehlerbehebungen ohne Eingriff in die Schnittstelle. Das gilt für alle Projekte unter ggml-org. Das Team schreibt, da immer mehr Menschen die Software nutzen, wolle man diese Grenzen künftig strenger sichtbar machen.
Für einen sauberen Start hat 1.0 zunächst aufgeräumt: Eine Reihe längst als veraltet markierter öffentlicher Schnittstellen wurde entfernt, einige Funktionen wurden umbenannt, und die Struktur der Kontextparameter hat neue Felder erhalten. Auch auf der ggml-Seite fielen veraltete APIs und der alte DIAG_MASK-Operator weg. Wer llama.cpp als Bibliothek in eigene Produkte einbindet, muss für dieses Upgrade einmal Code anpassen; danach genügt es, den Minor-Versionen zu folgen, ohne fürchten zu müssen, dass eine Schnittstelle in irgendeinem Build plötzlich verschwindet.
Was in dieser Version neu ist
Neben den Versionsregeln bringt 1.0 selbst eine ganze Reihe von Neuerungen:
- Der KV-Cache unterstützt FP8; neu ist ein MoE-Expertencache im Hauptspeicher des Hosts, bei dem sich der Anteil der CPU-Berechnung konfigurieren lässt;
- Neu hinzugekommen ist die Unterstützung für Modelle wie Kimi-K3.1-Pro; Kimi-K3.1 kann Bildeingaben verarbeiten;
- llama-server erhält mit /v1/audio/speech eine Schnittstelle zur Sprachsynthese, die mit dem TTS-Modell drama-3 zusammenarbeitet;
- Auf der Serverseite wurden SSRF-, CORS- und DNS-Rebinding-Probleme behoben; Tool-Aufrufe ohne Authentifizierung und der Zugriff auf private URLs müssen nun ausdrücklich aktiviert werden, und HF_TOKEN wird nur noch an huggingface.co gesendet.
Der letzte Punkt ist für alle, die selbst Dienste betreiben, der praktischste. llama-server wird oft als lokale OpenAI-kompatible Schnittstelle im internen Netz betrieben, mitunter sogar direkt ins Internet gestellt; sind Tool-Aufrufe standardmäßig offen, wächst die Angriffsfläche entsprechend. Die ausdrückliche Aktivierung gibt die Entscheidung zurück an diejenigen, die den Dienst betreiben.
Der MoE-Expertencache zielt auf die derzeit gängige Modellform. Die meisten großen Modelle dieses Jahres nutzen eine Mixture-of-Experts-Architektur: Die Gesamtparameterzahl liegt oft bei mehreren hundert Milliarden, pro Schritt wird aber nur ein kleiner Teil aktiviert. Passen nicht alle Experten in den Grafikspeicher, ist es ein gängiger Kompromiss, die gerade nicht benötigten in den Hauptspeicher auszulagern und anteilig von der CPU rechnen zu lassen, um große MoE-Modelle auf Consumer-Grafikkarten zu betreiben. Dies ist nun im Hauptzweig gelandet, Nutzer müssen nicht mehr zu Forks von Drittanbietern greifen.
Der Vergleich mit der Rechenzentrumsseite
Inferenz-Frameworks teilen sich heute in zwei Richtungen. vLLM, SGLang und ähnliche Frameworks zielen auf Rechenzentrums-GPUs und konkurrieren über Batch-Durchsatz und Parallelität; llama.cpp will Modelle auf Smartphones, Notebooks und Workstations zum Laufen bringen, presst große Modelle per Quantisierung in begrenzten Speicher und nutzt CPU und GPU gemischt.
Das zeigt sich an der Backend-Liste: CUDA, Metal, Vulkan, WebGPU, AMDs HIP, Intels SYCL, Snapdragon Hexagon und MUSA von Moore Threads sind dabei, und jedes Backend lässt sich als dynamische Bibliothek bauen und zur Laufzeit bei Bedarf laden. Laut Blog werden bereits mehr als 150 Varianten von Modellarchitekturen unterstützt. Rechenzentrums-Frameworks jagen der neuesten Hardware hinterher, llama.cpp bedient die lange Schleppe an Geräten; die Nutzerkreise überschneiden sich kaum.
Das Projekt hat auf GitHub rund 135.000 Sterne und 25.600 Forks. Das Team arbeitet inzwischen bei Hugging Face; der Blog dankt HF für die CI-Rechenleistung und nennt außerdem Hardwareunterstützung von NVIDIA, AMD, Qualcomm, Arm, IBM und Intel. Ob das Versionsversprechen hält, hängt davon ab, ob die nächsten Minor-Versionen heimlich Schnittstellen ändern.
Quellen: Hugging-Face-Blog, GitHub-Release-Seite von llama.cpp, CocoLoop, README des llama.cpp-Repositorys; die Release-Seite bestätigt die neuen Funktionen von 1.0, den Umfang der Schnittstellenbereinigung und die Backend-Liste.