L'équipe de llama.cpp a publié le 13 novembre la version 1.0.0 de llama.cpp et de la bibliothèque de tenseurs sur laquelle il repose, ggml, dans un billet du blog Hugging Face signé Daniel Bevenius, Georgi Gerganov et merve. Le numéro compte moins que l'engagement qui l'accompagne. Désormais, annoncent les projets, toute modification cassant l'API ou l'interface binaire sera signalée par un changement de version majeure, afin que les nombreuses applications bâties sur ces bibliothèques voient où se situent les limites.
llama.cpp est une implémentation en C et C++ qui permet d'exécuter des modèles de langage, y compris multimodaux, sur du matériel allant de l'ordinateur portable grand public au serveur d'entreprise, grâce à la quantification et à des backends optimisés qui rendent l'inférence peu coûteuse. L'équipe indique que le projet a environ trois ans et demi et que de nombreuses applications en dépendent déjà. La version 1.0.0 concerne les deux bibliothèques : libllama, dont les en-têtes publics se trouvent dans le dossier include de llama.cpp, et libggml, dont les en-têtes sont sous ggml/include. GitHub affiche des étiquettes v1.0.0 pour les deux dépôts le 13 novembre, après une longue série de publications de llama.cpp numérotées par build, comme b12360.
Le billet détaille les règles de versionnement, valables pour tous les projets ggml-org qui utilisent le versionnement sémantique. Une modification incompatible de l'API C publique d'un dossier include fait monter le numéro majeur. Une fonctionnalité rétrocompatible, une mise à jour de backend, la prise en charge d'un nouveau modèle ou l'ajout d'un appel d'API font monter le numéro mineur. Une correction de bogue sans effet sur l'API fait monter le numéro de correctif. Pour les développeurs qui lient leur code à libllama, cette dernière distinction est le gain concret : le travail sur les modèles et les backends, où se concentre l'essentiel des changements, ne devrait plus imposer de réécriture à chaque mise à jour.
L'annonce aborde aussi la distribution. L'équipe énumère des artefacts de préversion pour Linux, macOS, Windows, Android et iOS, des images Docker pour Linux, des paquets via Debian, Homebrew, conda-forge, MacPorts et Winget, ainsi qu'un XCFramework pour iOS et macOS. Elle renvoie les mainteneurs de paquets vers une discussion expliquant comment intégrer les projets ggml-org à leurs chaînes de publication, ce qui laisse penser qu'elle souhaite voir davantage de distributions suivre des versions étiquetées plutôt que des builds continus.
Côté méthode de travail, les auteurs écrivent qu'ils continuent d'intégrer des modèles de langage à leur propre flux de développement, mais que la qualité du code, la maîtrise de l'architecture et la compréhension des détails d'implémentation restent des priorités. Ils disent investir davantage dans l'intégration continue, en s'appuyant sur HF Buckets et HF Jobs de Hugging Face pour augmenter la capacité de test derrière chaque changement qui arrive sur les branches principales. Le soutien matériel de NVIDIA, AMD, Qualcomm, Arm, IBM et Intel permet de disposer de runners auto-hébergés sur les grandes plateformes. Le billet précise que llama.cpp prend en charge plus de 150 variantes d'architecture et toutes les méthodes courantes de décodage spéculatif, et que chaque backend de ggml peut être compilé en bibliothèque dynamique et chargé à l'exécution.
Il s'agit d'une annonce de politique de publication faite par les mainteneurs eux-mêmes, non d'une évaluation indépendante. Le billet ne liste aucune nouvelle fonctionnalité de la 1.0.0 et ne donne aucun chiffre de performance. Son importance est organisationnelle : elle lie les interfaces publiques du projet à une règle de compatibilité explicite, que les projets dépendants mettront à l'épreuve dès l'arrivée de la prochaine version majeure.