La bibliothèque d'inférence locale llama.cpp a publié la v1.0.0, et la bibliothèque de tenseurs ggml, sur laquelle elle repose, passe elle aussi en 1.0. L'équipe du projet explique sur le blog de Hugging Face que cette version vise à offrir une base plus stable aux développeurs qui en dépendent : désormais, dès que l'API publique ou l'ABI de llama.cpp et de ggml devient incompatible, cela se traduira par un changement de version majeure.
Ces dernières années, llama.cpp était publié presque uniquement sous forme de numéros de build commençant par b : chaque fusion de code dans la branche principale produit un nouveau build, et le compteur dépasse aujourd'hui b12000. Après la 1.0, cette numérotation ne s'arrête pas et continue d'être produite sous forme de préversions ; ce qui change, c'est qu'il existe désormais en plus une ligne de versions officielles assortie d'un engagement, entre lesquelles les utilisateurs peuvent choisir selon leurs besoins.
Les numéros de version ont enfin un sens
Les règles énoncées par le blog sont directes : MAJOR correspond aux changements qui cassent l'interface C publique du répertoire ./include ; MINOR, aux nouvelles fonctionnalités ou à la prise en charge de nouveaux modèles, rétrocompatibles ; PATCH ne corrige que des bogues sans toucher à l'interface. Elles s'appliquent à tous les projets de ggml-org. L'équipe écrit que, les utilisateurs étant de plus en plus nombreux, elle rendra ces frontières visibles de façon plus stricte à l'avenir.
Pour repartir sur des bases propres, la 1.0 commence par un grand nettoyage : suppression d'un lot d'interfaces publiques marquées comme obsolètes depuis longtemps, renommage de certaines fonctions et ajout de nouveaux champs dans la structure des paramètres de contexte ; du côté de ggml, les API obsolètes et l'ancien opérateur DIAG_MASK disparaissent aussi. Pour les développeurs qui lient llama.cpp comme bibliothèque dans leurs produits, cette mise à niveau demande de modifier le code une fois ; ensuite, en suivant les versions mineures, ils n'ont plus à craindre qu'une interface disparaisse soudainement dans tel ou tel build.
Ce que cette version ajoute
Outre les règles de versionnage, la 1.0 apporte elle-même de nombreuses nouveautés :
- Le cache KV prend en charge le FP8 ; un cache d'experts MoE placé en mémoire hôte fait son apparition, avec une part de calcul confiée au CPU configurable ;
- La prise en charge de modèles comme Kimi-K3.1-Pro est ajoutée, et Kimi-K3.1 peut traiter des entrées image ;
- llama-server gagne l'interface de synthèse vocale /v1/audio/speech, à utiliser avec le modèle TTS drama-3 ;
- Côté serveur, des failles SSRF, CORS et DNS rebinding ont été corrigées ; les appels d'outils sans authentification et l'accès aux URL privées doivent désormais être activés explicitement, et HF_TOKEN n'est envoyé qu'à huggingface.co.
Ce dernier point est le plus concret pour ceux qui hébergent leurs propres services. llama-server sert souvent d'interface locale compatible OpenAI placée dans le réseau interne, voire exposée directement sur Internet ; si les appels d'outils sont ouverts par défaut, la surface de risque s'élargit d'autant. Passer à une activation explicite redonne le choix à ceux qui déploient.
Le cache d'experts MoE vise quant à lui la forme actuelle des modèles. La plupart des grands modèles de cette année reposent sur une architecture à mélange d'experts : le nombre total de paramètres se chiffre souvent en centaines de milliards, mais seule une petite partie est activée à chaque étape. Quand la mémoire vidéo ne peut pas contenir tous les experts, déplacer ceux dont on n'a pas besoin pour l'instant vers la mémoire hôte et en confier une part du calcul au CPU est un compromis courant pour faire tourner de gros modèles MoE sur des cartes graphiques grand public. Cette option est maintenant intégrée à la branche principale, et les utilisateurs n'ont plus à chercher des forks tiers.
Face à la voie des centres de données
Les frameworks d'inférence se répartissent aujourd'hui en deux voies. vLLM, SGLang et leurs semblables visent les GPU de centres de données et se disputent le débit par lots et la concurrence ; llama.cpp cherche à faire fonctionner les modèles sur smartphones, ordinateurs portables et stations de travail, en s'appuyant sur la quantification pour faire tenir de gros modèles dans une mémoire limitée et en combinant CPU et GPU.
La liste des backends le montre : CUDA, Metal, Vulkan, WebGPU, HIP d'AMD, SYCL d'Intel, Hexagon de Snapdragon et MUSA de Moore Threads y figurent tous, et chaque backend peut être compilé en bibliothèque dynamique et chargé à l'exécution selon les besoins. Selon le blog, le projet prend déjà en charge plus de 150 variantes d'architectures de modèles. Les frameworks de centres de données courent après le matériel le plus récent, llama.cpp après la longue traîne d'appareils ; les deux publics se recoupent peu.
Le projet compte environ 135 000 étoiles et 25 600 forks sur GitHub. L'équipe travaille actuellement chez Hugging Face ; le blog remercie HF pour la puissance de calcul fournie à l'intégration continue et cite aussi le soutien matériel de NVIDIA, AMD, Qualcomm, Arm, IBM et Intel. Que l'engagement de versionnage soit tenu dépendra de la capacité des prochaines versions mineures à ne pas modifier l'interface en douce.
Sources : blog de Hugging Face, page des versions de llama.cpp sur GitHub, CocoLoop, README du dépôt llama.cpp ; la page des versions confirme les nouveautés de la 1.0, l'étendue du nettoyage des interfaces et la liste des backends.