La frontière qui compte n'est plus la taille du modèle
Publié le · LINAGORA
La thèse
Le classement des modèles par nombre de paramètres n'a plus de valeur opérationnelle. Ce qui décide d'un projet, c'est le coût par million de tokens à performance donnée, mesuré sur vos cas d'usage à vous. Cette grandeur ne figure dans aucun classement public, parce qu'elle dépend de vos données.
Le nombre de paramètres a cessé d'être une information
Pendant trois ans, la taille d'un modèle a servi d'indicateur de capacité. Cette période est terminée. Les techniques d'entraînement, la qualité des corpus et les architectures à activation partielle ont brisé la relation entre le nombre de paramètres et la performance utile.
Un modèle compact et bien entraîné dépasse aujourd'hui, sur des tâches précises, des modèles dix fois plus gros publiés dix-huit mois plus tôt. Inversement, un très grand modèle reste supérieur sur les tâches de raisonnement long et de synthèse difficile. Les deux affirmations sont vraies, et c'est exactement pourquoi le classement générique ne vous sert à rien : il moyenne des situations qui n'ont rien à voir avec la vôtre.
La seule question qui décide est celle-ci : quel est le plus petit modèle qui tienne mes exigences sur mes cas d'usage réels, et combien coûte-t-il à faire tourner ?
Un modèle ouvert que presque personne ne peut faire tourner
Un modèle de 2,8 trillions de paramètres peut être ouvert au sens des poids, publiquement téléchargeable, sous une licence permissive, et rester inaccessible en pratique. S'il exige 1,7 téraoctet de mémoire vive graphique, ou seize accélérateurs de dernière génération pour produire une réponse à une latence acceptable, alors le modèle est ouvert et son usage ne l'est pas.
Cette distinction n'est pas un détail juridique. Elle sépare l'ouverture déclarative de l'ouverture effective. Un commun numérique qu'aucune organisation de taille moyenne ne peut exploiter reste un objet de recherche utile, mais il ne fonde aucune indépendance.
C'est pourquoi la disponibilité de modèles ouverts de taille intermédiaire, exploitables sur une infrastructure raisonnable, compte davantage pour l'autonomie européenne que la course au plus grand modèle publié.
Le goulot d'étranglement n'est presque jamais le calcul
L'intuition commune veut que la limite soit la puissance de calcul. Dans la pratique du service en production, elle l'est rarement. Le facteur limitant est la place disponible en mémoire pour tenir les poids et le contexte, la bande passante pour aller chercher les bons octets au bon moment, et le stockage rapide pour alimenter le tout.
Cette réalité a des conséquences directes sur le dimensionnement. Une machine dont les accélérateurs sont sous-utilisés parce qu'ils attendent la mémoire coûte le même prix qu'une machine bien dimensionnée, pour une fraction du débit. Beaucoup de projets achètent de la puissance de calcul là où ils auraient dû acheter de la mémoire et de la bande passante.
Le dimensionnement doit donc partir du profil réel de vos requêtes : longueur des contextes, taux de concurrence, tolérance à la latence. Trois paramètres qui se mesurent chez vous en quelques jours, et qui changent la facture d'un ordre de grandeur.
Le facteur cinquante
À performance comparable sur des tâches réelles, l'écart de prix en sortie entre un très grand modèle propriétaire et un modèle compact optimisé atteint couramment un facteur cinquante. Ce n'est pas une différence d'optimisation à la marge, c'est une différence de nature entre deux décisions d'architecture.
Un écart de cette ampleur ne se rattrape par aucune négociation commerciale. Il se rattrape en amont, au moment où l'on décide quel modèle traite quel type de requête. La plupart des systèmes en production n'ont pas besoin du meilleur modèle disponible pour l'immense majorité de leurs appels : ils en ont besoin pour une fraction identifiable, et cette fraction se mesure.
Le mix de modèles, orchestré par le harnais, est donc d'abord une décision économique. C'est aussi la raison pour laquelle la conception du harnais et le cadrage économique doivent être menés ensemble, et non l'un après l'autre.
Comment mesurer chez vous
Le protocole tient en quatre temps et il ne demande pas de moyens considérables. Constituez un jeu d'évaluation à partir de vos données réelles, incluant les cas difficiles et les cas ambigus, pas seulement les cas de démonstration. Définissez le critère de réussite avec les métiers concernés, en acceptant qu'il soit partiellement subjectif et en le rendant reproductible.
Mesurez ensuite plusieurs modèles sur ce jeu, en enregistrant à la fois le taux de réussite, la latence et le coût par requête. Enfin, calculez le coût par requête réussie, qui est la seule grandeur pertinente : un modèle deux fois moins cher qui échoue une fois sur trois coûte plus cher qu'un modèle qui réussit.
Ce travail prend deux à trois semaines. Il évite des engagements pluriannuels pris sur la foi d'un classement public.
Ce que cela implique pour votre organisation
Cessez de comparer des modèles, comparez des mix de modèles sur vos propres données. Le résultat est presque toujours contre-intuitif, et il est presque toujours favorable à des modèles plus petits que ceux envisagés au départ.
Dimensionnez à partir de la mémoire et de la bande passante, pas de la puissance de calcul. C'est la source d'erreur la plus fréquente et la plus coûteuse des projets de mise à l'échelle.
Calculez un coût total de possession à trois ans pour les trois scénarios possibles : acheter et exploiter, héberger chez soi, confier en service managé. Le scénario le moins cher la première année est rarement le moins cher la troisième.
Enfin, réévaluez tous les six mois. Un écart d'un facteur cinquante ne reste pas stable dans un marché qui bouge à ce rythme.
Le module de conseil associé
Mesurer votre coût par token utile avant de vous engager
Le cadrage économique mesure ce coût sur vos cas d'usage réels, compare plusieurs mix de modèles et dimensionne l'infrastructure correspondante.