llama.cpp passe en version 1.0 et annonce comment ses interfaces évolueront

Les équipes de llama.cpp et de ggml ont publié leurs versions 1.0 le 13 novembre. Elles annoncent que les prochaines ruptures de leurs interfaces publiques entraîneront un changement de numéro majeur. Ça donne un repère aux développeurs dont les applications s’appuient sur ces bibliothèques pour exécuter des modèles localement. La version 1.0 retire déjà des fonctions qui étaient dépréciées.

Le moteur et les modèles jouent des rôles différents

llama.cpp fait fonctionner des modèles de langage sur des machines qui vont de l’ordinateur personnel au serveur. Un modèle contient les paramètres acquis pendant l’entraînement. Le moteur se charge de l’exécuter sur le matériel disponible. ggml fournit une partie des opérations de calcul utilisées par le moteur. Les deux projets publient donc une bibliothèque distincte avec ses propres interfaces.

Ce découpage aide à comprendre un déploiement local. Une application peut proposer plusieurs modèles à partir du même moteur. Elle peut aussi continuer à utiliser un modèle existant quand elle met le moteur à jour. Les capacités et les prérequis dépendent des deux choix. notre article sur l’exécution locale de LFM2.5 montre par ailleurs que l’exécution locale d’un modèle et celle des services qu’il appelle sont deux choses différentes.

Le numéro majeur indique désormais une rupture

Dans l’annonce de l’équipe ggml-org, l’équipe explique comment elle compte appliquer le versionnage sémantique. Une rupture de l’interface C publique déclenche un changement de version majeure. Une fonctionnalité compatible ou la prise en charge d’un nouveau modèle relève d’une version mineure. Un correctif sans modification de l’interface relève d’une version de maintenance.

L’équipe annonce aussi qu’elle signalera les incompatibilités de l’interface binaire. Ce point intéresse les applications qui chargent une bibliothèque compilée. Un programme peut avoir besoin d’être reconstruit si la façon dont il échange avec cette bibliothèque change. Le numéro majeur permet de savoir quand vérifier ces dépendances et la disponibilité des paquets correspondants.

Ce qu’une application doit vérifier en passant à 1.0

les notes de version de llama.cpp signale la suppression de fonctions publiques déjà dépréciées et le déplacement de certaines interfaces vers l’en-tête public principal. Les développeurs d’une application existante doivent vérifier quelles fonctions elle appelle avant de remplacer sa bibliothèque. Une personne qui lance un modèle depuis une interface graphique dépend surtout de la version empaquetée par son application.

L’équipe annonce prendre en charge plus de 150 variantes d’architecture. Elle s’appuie sur plusieurs moteurs de calcul pour les systèmes et les composants compatibles. Ce nombre décrit la couverture du projet. Il ne dit pas qu’un modèle donné tient dans la mémoire de n’importe quel ordinateur. Le format du modèle et le niveau de quantification peuvent changer cette contrainte.

Le passage à 1.0 aide surtout à suivre la compatibilité entre les versions. Par exemple, un outil qui exécute un petit modèle sur plusieurs systèmes peut vérifier séparément la mise à jour de son moteur et celle de ses modèles. Pour les personnes qui utilisent déjà un outil local, l’effet arrivera au moment où cet outil adoptera la nouvelle bibliothèque. L’annonce ne promet pas un gain de vitesse uniforme. Elle donne aux équipes une manière plus claire de prévoir ce qui peut changer lors d’une mise à jour.