Toutes les publications

Grok : des poids publiés ne sont pas des poids exploitables

Modèles ouvertsInfrastructureSouverainetéCoût2024-03-1710 min

Publier des poids et rendre un modèle utilisable sont deux choses distinctes. L'écart se mesure en mémoire vidéo, et il est plus grand qu'annoncé.

Une publication qui ne change pas la pratique

Grok-1 est publié avec ses poids, trois cent quatorze milliards de paramètres, et pratiquement aucune organisation ne dispose du matériel pour le faire tourner. L'annonce est réelle ; son effet pratique est proche de zéro.

Charger un modèle de cette taille exige plusieurs centaines de giga-octets de mémoire vidéo, soit un ensemble de cartes graphiques haut de gamme dont le prix se compte en centaines de milliers d'euros. Ce n'est pas un obstacle de compétence : c'est un obstacle d'immobilisation.

La leçon utile n'est pas sur ce modèle en particulier. Elle porte sur la lecture des annonces d'ouverture : « poids publiés » ne signifie ni « utilisable », ni « économique », ni « autorisé ».

Écart entre la taille d'un modèle publié et ce qu'une équipe peut héberger
La taille des poids détermine la mémoire nécessaire, donc le coût d'entrée.

Les trois questions à poser devant toute publication de poids

Combien de mémoire faut-il, que permet la licence, et qui maintiendra le modèle dans un an. Ces trois questions filtrent la quasi-totalité des annonces sans qu'il soit nécessaire de lire une fiche technique.

La mémoire nécessaire se calcule simplement : environ deux octets par paramètre en précision réduite, davantage en précision complète. Un modèle de sept milliards de paramètres tient sur une carte accessible ; un modèle de trois cents milliards demande une infrastructure de centre de données.

La licence détermine ce qu'on a le droit de faire, et notamment de redistribuer, le point développé dans Llama 2 : la licence compte autant que le modèle.

La maintenance est la question la plus négligée. Un modèle publié sans engagement de suite est un objet figé : pas de correctif, pas de version suivante, pas de communauté nécessairement. Bâtir un système dessus revient à accepter qu'il ne progressera plus.

Ce qui rend réellement un modèle ouvert utilisable

  • Une taille compatible avec du matériel accessible, ce qui situe la barre autour de quelques dizaines de milliards de paramètres au maximum.
  • Une licence qui couvre l'usage prévu, y compris la redistribution si le modèle doit être livré à un client.
  • Un écosystème d'outillage : formats de quantification, serveurs d'inférence, versions réduites publiées par la communauté.
  • Une suite annoncée. Un modèle sans version suivante est une impasse à moyen terme, quel que soit son niveau actuel.

Le rôle réel de ces publications

Une publication de poids très volumineux sert la recherche et la pression concurrentielle, pas le déploiement en entreprise. C'est un usage légitime, à condition de ne pas se tromper sur sa portée.

Elle permet aux laboratoires d'étudier des modèles qu'ils ne pourraient pas entraîner. Elle exerce une pression sur les fournisseurs propriétaires, qui doivent justifier leur tarification. Elle alimente les travaux de compression et de distillation qui produiront, dix-huit mois plus tard, des modèles bien plus petits de qualité comparable.

Ce dernier point est le plus intéressant pour une entreprise. Ce qui compte n'est pas la publication elle-même mais ce qu'elle rend possible en aval : des modèles réduits, exploitables sur du matériel ordinaire, qui héritent d'une partie des capacités du grand.

La conclusion pratique est donc de suivre ces publications sans en attendre un effet immédiat, et de reprendre l'arbitrage quand des versions réduites apparaissent.

Ce décalage de dix-huit mois entre la publication d'un très grand modèle et la disponibilité de dérivés exploitables est devenu régulier. Il constitue un horizon de planification utile : une organisation qui construit aujourd'hui une architecture réversible pourra en profiter sans projet, alors qu'une architecture liée à un fournisseur devra être réécrite. C'est le premier des verrous décrits dans sortir du prototype.

Le calcul de mémoire à faire en trente secondes

Multiplier le nombre de paramètres par deux octets pour obtenir la mémoire minimale en précision réduite, puis ajouter la place du contexte. Un modèle de soixante-dix milliards de paramètres demande donc au moins cent quarante giga-octets, soit plusieurs cartes, pas une.

Ce que ça implique pour une stratégie de souveraineté

Une stratégie de souveraineté fondée sur les modèles ouverts doit viser la taille exploitable, pas la taille maximale disponible. C'est le contresens que je rencontre le plus souvent dans les dossiers publics.

L'objectif n'est pas d'héberger le plus gros modèle possible, mais de traiter en interne les données qui ne doivent pas sortir. Pour l'essentiel de ces traitements, extraction, classification, recherche documentaire, reformulation, un modèle de taille moyenne suffit largement.

Le réglage efficace consiste donc à héberger un modèle modeste pour tout ce qui touche aux données protégées, et à recourir à une API pour le reste. Cette architecture mixte donne davantage de souveraineté réelle qu'un projet d'hébergement ambitieux qui n'aboutira pas. Le cadre de décision figure dans confidentialité : ce qu'on a le droit de mettre dans un prompt.

Questions fréquentes

Comment savoir si un modèle publié est hébergeable ?

En multipliant le nombre de paramètres par deux octets pour la précision réduite, puis en ajoutant la place du contexte. Au-delà de quelques dizaines de milliards de paramètres, l'infrastructure devient celle d'un centre de données.

Une publication de poids sert-elle à quelque chose pour une entreprise ?

Indirectement. Elle alimente les travaux de compression qui produiront, un an plus tard, des modèles réduits exploitables sur du matériel ordinaire. C'est en aval que l'effet se matérialise.

Faut-il viser le plus gros modèle ouvert disponible ?

Non. Une stratégie de souveraineté vise la taille exploitable : un modèle moyen hébergé pour les données protégées, une API pour le reste, donne plus de souveraineté réelle qu'un projet ambitieux qui n'aboutit pas.

Que vérifier avant de bâtir sur un modèle ouvert ?

La mémoire nécessaire, la licence pour l'usage prévu, l'existence d'un outillage de quantification, et l'annonce d'une version suivante. Un modèle sans suite est une impasse à moyen terme.