llama.cpp 1.0 : ce que garantit la nouvelle numérotation pour l'IA locale, et ce qu'elle ne couvre pas

En une phrase : Avec sa version 1.0.0 du 13 novembre 2026, llama.cpp promet que son API C ne cassera plus sans changement de version majeure : une garantie utile pour qui intègre l’IA locale dans un logiciel, mais qui ne couvre ni le serveur HTTP, ni les builds quotidiens que distribuent encore Winget et l’application Llama.

llama.cpp est la bibliothèque libre qui exécute des modèles de langage sur un ordinateur personnel plutôt que dans le nuage. Après trois ans et demi de développement, son équipe, rattachée à Hugging Face depuis l’annonce du 20 février 2026, a publié le 13 novembre 2026 llama.cpp v1.0.0 et sa bibliothèque de calcul ggml v1.0.0. Le billet d’annonce ne présente pas cette version comme une nouveauté technique, mais comme un engagement envers les développeurs qui dépendent du projet. Voici ce que dit cet engagement, ce qu’il exclut, et ce qu’il change selon la manière dont on installe llama.cpp.

La règle : la version 2 signalera la casse

Le billet du 13 novembre fixe trois cas, valables pour tous les projets de l’organisation ggml-org qui suivent la numérotation sémantique. Le tableau reprend les règles publiées par l’équipe.

La garantie porte sur les en-têtes publics de deux bibliothèques, libllama et libggml, et le billet l’étend à l’ABI, l’interface binaire : en principe, un programme compilé contre la 1.0 peut charger une 1.x sans être recompilé. C’est ce qui intéresse un éditeur de logiciel ou un distributeur de paquets. Le billet annonce que l’équipe sera « plus stricte » pour rendre ces frontières visibles (traduction Le Latent).

Pour arriver à une base stable, la 1.0 commence par casser. La demande de fusion n° 30565, fusionnée le 12 novembre 2026, retire llama_set_warmup, les 35 fonctions marquées dépréciées dans llama.h, le paramètre defrag_thold et l’option --defrag-thold. Elle remonte dans llama.h 18 fonctions de l’API de décodage spéculatif jusque-là reléguées dans un en-tête annexe, et renomme llama_set_embd_state_src en llama_set_ctx_state_src. Un logiciel qui appelait encore une de ces fonctions ne compile plus avec la 1.0.

Ce que la promesse ne couvre pas

Trois choses restent hors du périmètre, et ce sont souvent celles que touche un utilisateur.

Le serveur et ses options. La règle vise l’API C. L’outil llama-server, qui expose les modèles en HTTP sur le modèle de l’API d’OpenAI, n’est pas cité dans les règles de numérotation, et la 1.0 en change justement le comportement (voir plus bas). Ses options de ligne de commande non plus : --defrag-thold disparaît dans cette version, selon la note de version.

Les builds quotidiens. Le dépôt publie toujours, à partir de sa branche principale, des builds numérotés bNNNNN d’après le numéro de commit. La discussion n° 1579, qui décrit depuis le 7 août 2026 le processus de publication, les appelle « nightly development builds ». Ils contiennent une copie interne de ggml qui « peut s’écarter » de la version publiée. Les versions vX.Y.Z, elles, ne sont créées que si cette copie est identique à ggml publié, ce qui garantit la compatibilité avec un ggml installé sur le système. Le build b12377 est paru le 14 novembre 2026 à 10 h 46 (heure de Paris), d’après GitHub, après la 1.0.0 : les deux circuits coexistent.

Le fichier du modèle. Une API stable ne dit rien de ce que contient le fichier GGUF chargé. Un fichier de poids peut être modifié pour cacher un comportement, comme l’a montré Microsoft Research avec Lazarus ; la numérotation de llama.cpp engage son code, pas les fichiers qu’il charge.

Selon l’installation, deux mondes

La discussion n° 1579 recense les canaux de distribution et leur politique. Nous avons relevé leur version le 14 novembre 2026 vers 11 h (heure de Paris).

Pour Winget et le script d’installation de llama.app, la discussion n° 1579 indique que ces canaux « publient les builds quotidiens au lieu des versions officielles », avec une question encore ouverte : « passer aux versions officielles ? » (traduction Le Latent). L’application Llama pour Mac fait de même : sa version 0.47.0, parue le 5 novembre 2026, « met à jour le moteur en b12110 ». La version Windows, d’après son dépôt, utilise le llama.exe déjà installé ou en télécharge un. Autrement dit, quelqu’un qui passe par l’application Llama ou par winget reçoit le code le plus récent, nouveaux modèles compris, mais sans la garantie de la 1.0. C’est rarement gênant pour un usage personnel ; ça l’est davantage pour une équipe qui veut savoir quelle version tourne sur ses postes.

L’écart joue aussi dans l’autre sens. La version officielle précédente, v0.9.0 du 4 novembre 2026, ajoutait la prise en charge de Mistral Large 4, dont nous avons détaillé le rapport technique. Debian sid en est encore à la 0.7.0, d’après son paquet source : un modèle récent peut y être absent.

Le serveur durci, au prix de quelques usages

La 1.0 regroupe plusieurs changements de sécurité de llama-server, fusionnés entre le 6 et le 12 novembre 2026. Ils comptent surtout pour qui fait tourner le serveur ailleurs que sur sa seule machine, notamment dans Docker avec --host 0.0.0.0, comme le montre la documentation du serveur (l’écoute par défaut reste 127.0.0.1).

• Outils et MCP verrouillés sur le réseau. Activer les outils du serveur ou des serveurs MCP sur une adresse autre que la boucle locale, sans clé d’API, est désormais refusé avec une erreur ; il faut l’option --allow-unauthenticated-tools, réservée aux « réseaux de confiance », selon la demande n° 32113. Un outil qui lit des fichiers ou lance des actions, ouvert sans authentification, donne ces pouvoirs à quiconque atteint le port.
• Plus d’accès aux adresses locales par défaut. Le proxy CORS ne peut plus joindre que des adresses publiques, et une image passée par URL ne peut plus venir d’une adresse privée sans l’option --media-allow-private-urls. La demande n° 32115 cite le cas d’un média stocké sur un NAS du réseau local, désormais bloqué par défaut, et explique que ces accès étaient prévus pour un serveur isolé, alors que « beaucoup de déploiements » tournent directement sur l’ordinateur de l’utilisateur.
• Jeton Hugging Face limité. Avant la demande n° 31730, un HF_TOKEN exporté dans l’environnement était envoyé à n’importe quel serveur indiqué par --model-url ; il est maintenant réservé aux hôtes huggingface.co.

Les mainteneurs ne présentent pas tous ces changements comme des failles. Dans la demande n° 32113, l’auteur écrit qu’« aucun » de ces points n’est « vraiment une vulnérabilité », mais que l’équipe est « forcée de dégrader un peu l’ergonomie » face aux remarques répétées (traduction Le Latent, texte de la demande n° 32113). Pour l’utilisateur, l’effet est le même : une configuration qui fonctionnait en 0.9 peut refuser de démarrer en 1.0.

Ce qu’on ne sait pas encore

• Quand Winget et llama.app passeront aux versions officielles : la question est notée comme à faire dans la discussion n° 1579, sans date ; rien n’est dit pour l’application Llama pour Mac.
• Le rythme des versions officielles : ni le billet ni la discussion ne disent à quelle fréquence sortiront les 1.x, alors que les builds de développement se succèdent plusieurs fois par jour sur la page des versions.
• La durée de maintenance d’une version majeure : rien n’indique combien de temps la branche 1 recevra des correctifs après une future 2.0.

Pour un développeur, la consigne est simple : viser les tags v1.x.y (ou Homebrew) et non les builds bNNNNN, remplacer les fonctions retirées, et relire la configuration du serveur avant de monter de version. Pour un utilisateur de l’application Llama pour Mac, rien à faire, sinon savoir qu’elle embarque un build de développement. La différence entre logiciel libre et modèle à poids ouverts, et ce que fait un agent IA avec des outils, sont expliqués dans la rubrique Comprendre.