Llama.cpp V1.0.0 établit des règles de stabilité de l’API pour les outils d’IA locaux

ggml-org a annoncé llama.cpp v1.0.0 le 13 novembre 2026, dotant ce projet d’inférence locale en IA écrit en C/C++ d’un contrat formel de compatibilité à l’intention des développeurs en aval. La bibliothèque de tenseurs sous-jacente ggml a également atteint la version 1.0.0. Le projet indique prendre en charge plus de 150 variantes d’architectures de modèles et toutes les principales méthodes de décodage spéculatif.

La gestion des versions devient un engagement public

Les deux projets signaleront les futures incompatibilités de l’API au niveau du code source et de l’ABI — l’interface binaire utilisée par les applications compilées — par une augmentation du numéro de version majeure. Toute modification incompatible de l’API publique en C entraîne une augmentation de version majeure. Les fonctionnalités rétrocompatibles, les mises à jour des moteurs d’exécution, la prise en charge de modèles et les ajouts à l’API entraînent une augmentation de version mineure, tandis que les corrections de bogues sans modification de l’API entraînent une augmentation du numéro de correctif.

Cette politique fait suite à 3,5 ans de développement et à une dépendance croissante aux interfaces de bibliothèque du projet. llama.cpp permet l’inférence multimodale de LLM par l’intermédiaire de libllama, tandis que ggml fournit la couche de tenseurs d’apprentissage automatique par l’intermédiaire de libggml. Le logiciel s’appuie sur la quantification, des moteurs d’exécution optimisés et du code C/C++ portable pour cibler des appareils allant des ordinateurs grand public aux serveurs d’entreprise.

Cela fournit aux responsables de paquets et aux développeurs d’applications un indicateur de version pour évaluer si une mise à niveau risque de compromettre leur intégration. La discussion sur le processus de publication des responsables du projet, le 7 août 2026, ajoute une mesure de protection connexe : une étiquette de publication officielle de llama.cpp n’est créée que lorsque la copie interne de ggml est identique à la version publiée de ggml. Cette condition vise à garantir que les versions compilées à partir d’une étiquette de publication restent compatibles avec une installation de ggml à l’échelle du système, comme celles utilisées par les paquets Debian et Homebrew mentionnés dans le document.

Modifications du moteur d’exécution, des modèles et du serveur

Les notes de version de llama.cpp v1.0.0 accompagnent ce contrat d’un important nettoyage. La version supprime l’API publique obsolète, dont 35 fonctions dépréciées, tout en faisant passer l’API de décodage spéculatif NextN de l’ llama-ext.h en-tête d’extension à l’en-tête public llama.h en-tête. Ce changement intègre cette interface de décodage spéculatif à l’API publique régie par les nouvelles règles de gestion des versions.

Les nouvelles fonctionnalités d’inférence comprennent des caches clé-valeur en virgule flottante 8 bits (FP8) OCP, un cache en mémoire hôte pour les modèles à mélange d’experts (MoE) avec une part du processeur configurable, ainsi que le chargement de données PLE ou engram externes à partir de fragments GGUF distincts. Les ajouts de modèles couvrent les architectures textuelles Kimi-K3.1-Pro, Ripple et xing4_0, la synthèse vocale texte-parole drama-3, ainsi que la prise en charge de la vision pour MageVL-Cowork et Kimi-K3.1.

Pour llama-server, la version corrige les problèmes de falsification de requêtes côté serveur, de partage de ressources entre origines et de rebinding DNS, et restreint HF_TOKEN aux hôtes huggingface.co. Les appels d’outils MCP sont annulés lorsqu’un client se déconnecte ou expire, et le serveur MCP en est informé. Un nouveau point de terminaison compatible avec OpenAI /v1/audio/speech étend l’interface audio du serveur.

La nouvelle interface Web ajoute des groupes de discussion nommés et un éditeur Markdown avec aperçu en direct. Les mises en page mobiles tiennent compte des zones de sécurité de l’appareil et utilisent des fenêtres de dialogue en plein écran, tandis que l’éditeur de discussion Android peut ouvrir le clavier virtuel.

Moteurs d’exécution matériels et infrastructure de publication

La version complémentaire ggml v1.0.0 supprime les API obsolètes et les anciennes opérations DIAG_MASK, ajoute la prise en charge de la troncature YaRN configurable et de FP8, et évite de téléverser les entrées du planificateur qui ne sont pas lues. CUDA et Metal bénéficient d’améliorations de la multiplication matricielle quantifiée pour les matrices comportant peu de lignes, ainsi que de la fusion MoE. Les autres ajouts aux moteurs d’exécution comprennent un noyau FlashAttention de préremplissage Intel Vulkan, un planificateur MoE SYCL exécuté sur l’appareil, une implémentation décomposée de FlashAttention pour Adreno dans OpenCL, de nouveaux noyaux WebGPU et une prise en charge élargie des opérations Hexagon.

Chaque moteur d’exécution ggml peut être compilé sous forme de bibliothèque dynamique et, en option, chargé à l’exécution, ce qui permet aux installations de sélectionner le code adapté au matériel. Les artefacts de préversion couvrent Linux, macOS, Windows, Android et iOS. Docker, Debian, Homebrew, conda-forge, MacPorts, Winget et XCFramework offrent d’autres canaux de distribution, dont la couverture des plateformes varie.

Pour soutenir le rythme de développement, l’équipe indique que Hugging Face Buckets et Jobs augmentent la capacité d’intégration continue pour les modifications apportées aux branches master. La prise en charge matérielle de NVIDIA, AMD, Qualcomm, Arm, IBM et Intel permet également d’utiliser davantage d’exécuteurs autohébergés sur les principales plateformes matérielles. Les responsables du projet intègrent aussi les LLM à leur cycle de développement et indiquent que leurs priorités sont la qualité du code, la maîtrise de l’architecture et la compréhension des détails d’implémentation.

Pour les projets en aval, cette version fait de la compatibilité une obligation explicite de développement pour une bibliothèque libre qui évolue rapidement. Les règles de gestion des versions peuvent signaler les changements incompatibles ; le développement des tests d’intégration continue et du parc d’exécuteurs matériels aide à déterminer si les versions régulières restent fiables avec les modèles et le matériel utilisés par ces projets.