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

Publier les poids permet de télécharger les paramètres appris d’un modèle, mais son exploitation dépend encore du matériel, de l’outillage, de la licence et de l’usage prévu. L’ouverture du fichier ne livre pas un service prêt à fonctionner.

Dans son annonce du 17 mars 2024, xAI publie les poids et l’architecture de Grok-1, un mélange d’experts de 314 milliards de paramètres. Le point de contrôle vient du préentraînement achevé en octobre 2023 ; il n’est pas ajusté pour le dialogue. La licence annoncée est Apache 2.0.

L’effet pratique dépend donc de l’équipe qui reçoit ces fichiers. Un laboratoire équipé, une organisation souhaitant les étudier et une petite équipe cherchant un assistant documentaire n’ont pas le même problème.

Je ne déduis ni un prix d’infrastructure ni un taux d’organisations capables de l’héberger de cette annonce. La leçon utile porte sur ce qu’il reste à démontrer : que les poids se chargent, que le modèle répond au besoin et que le service peut être maintenu avec les moyens disponibles.

Devant une publication de poids, je vérifie les besoins de mémoire, les droits d’usage et la capacité de maintenance, puis je demande un essai sur la tâche envisagée. Ces questions orientent l’examen sans remplacer la fiche technique.

La mémoire des poids dépend du nombre de paramètres et de leur représentation. Avec une hypothèse de deux octets par paramètre, 314 milliards donnent environ 628 milliards d’octets, soit 628 Go décimaux pour les poids seuls. Il faut ajouter les buffers, les activations et le contexte. Ce calcul ne dimensionne pas encore un serveur opérationnel.

Un modèle plus petit réduit cette composante. C’est un motif d’intérêt pour Mistral 7B, sans promettre qu’une carte quelconque suffira à tous les usages.

La licence doit couvrir ce que l’équipe prévoit de faire. La licence Apache 2.0, édition de janvier 2004 prévoit notamment des conditions de redistribution et de conservation des avis ; elle ne dispense pas d’examiner les autres droits applicables. La question est aussi développée dans Llama 2 et sa licence.

Enfin, l’absence de version suivante annoncée ne rend pas automatiquement un modèle inutilisable. Elle oblige à identifier qui corrigera l’intégration, suivra les dépendances et décidera d’un remplacement.

J’évalue un modèle à poids ouverts en confrontant ses besoins matériels, sa licence, son outillage et sa maintenance au cas d’usage, avant de lancer un déploiement. Chaque étape peut faire apparaître une limite décisive.

1. Estimer puis mesurer les ressources. Préciser la représentation des poids, la longueur d’entrée, le nombre de requêtes simultanées et le délai acceptable. Un calcul théorique précède un essai réel.
2. Lire la licence pour l’usage prévu. Distinguer étude, service interne, service à des clients et redistribution des fichiers, avec les avis à conserver.
3. Vérifier l’outillage disponible à la date de l’examen. Reproduire un chargement et une génération, puis vérifier les formats, les dépendances et les limites connues.
4. Nommer la maintenance et préparer la sortie. Documenter la configuration, les tests et les conditions de changement de modèle.

Pour Grok-1, le volume des poids justifie de commencer par les ressources. Il ne prouve pas que toute organisation échouera à cette étape. La décision doit porter sur un environnement identifié, et non sur l’expression vague « serveur d’entreprise ».

Un mélange d’experts active seulement une partie du réseau à chaque jeton, mais la disponibilité de tous les poids reste une contrainte distincte du calcul effectivement réalisé. Il faut séparer ces deux budgets.

L’annonce de Grok-1 indique environ un quart des poids actifs par jeton. Cela ne ramène pas automatiquement la mémoire des poids au quart du total. Les experts nécessaires aux jetons suivants doivent être accessibles.

Ils peuvent être répartis entre plusieurs équipements ; un déchargement vers une autre mémoire ajoute des transferts à mesurer. Dire que tous les poids doivent toujours résider dans la mémoire vidéo d’une seule machine serait donc trop catégorique.

Le mécanisme rejoint Mixtral et ses paramètres actifs. Le temps de réponse dépend aussi de l’implémentation, des échanges et de la charge : moins de paramètres actifs ne garantit pas, à lui seul, un délai plus court.

Comparer un grand modèle publié à un petit modèle exige de distinguer la mémoire des poids, les conditions de licence et la qualité mesurée sur la même tâche. La taille ne tranche pas tous les critères.

Ces volumes sont des calculs conditionnels, pas des mesures de mémoire vidéo en exploitation. Changer la représentation des poids ou le contexte change le dimensionnement. La concurrence des requêtes compte également.

Des poids deviennent utilisables dans un projet lorsque les ressources, la licence, l’intégration et la qualité sont vérifiées, avec une responsabilité explicite pour la maintenance du service.

• Des ressources compatibles avec l’usage, mesurées au volume, au contexte et au délai attendus.
• Une licence couvrant le projet, avec les conditions de redistribution et les avis nécessaires.
• Une intégration reproductible, dont les formats et dépendances sont documentés.
• Une qualité vérifiée sur les tâches utiles, y compris les refus et les erreurs.
• Une maintenance tenue par quelqu’un, avec une configuration conservée et une solution de remplacement.

La publication d’un grand modèle peut servir à l’étude, à l’expérimentation et au développement de nouvelles méthodes, même lorsque son hébergement ne convient pas à une petite équipe. Son intérêt ne se réduit pas au déploiement immédiat.

Elle rend possible l’examen d’un objet qu’une équipe n’aurait pas les moyens d’entraîner. Des travaux de compression peuvent aussi chercher à réduire les ressources nécessaires, sans garantir un modèle dérivé ni un calendrier.

La recherche LLM.int8 de 2022 montre une méthode de réduction de mémoire sur les modèles qu’elle étudie. Elle ne prouve pas la qualité d’une version quantifiée de Grok-1. Tout dérivé doit être testé avec ses propres fichiers et sa propre configuration.

Je recommande de suivre ces publications sans annoncer une arrivée certaine de modèles plus petits à qualité comparable. Leur apparition éventuelle ouvre un nouvel arbitrage, pas une migration gratuite.

Une architecture documentée et testable facilite cet arbitrage. Elle doit conserver les interfaces, les critères de sortie et les cas de recette, comme dans sortir du prototype. Une couche d’abstraction réduit certaines dépendances ; remplacer le modèle exige encore une vérification.

La mémoire des poids s’estime à partir du nombre de paramètres et de leur représentation, mais ce calcul doit être complété par les ressources d’exécution et une mesure réelle.

Nombre de paramètres multiplié par octets par paramètre donne une estimation des poids seuls. À deux octets, 70 milliards de paramètres représentent 140 Go décimaux. Ajouter les ressources d’exécution avant de conclure sur le matériel, et mesurer toute configuration quantifiée.

Une stratégie de souveraineté doit partir des données à protéger, des tâches attendues et des moyens d’exploitation, puis vérifier qu’un modèle hébergé répond effectivement à ces contraintes. La taille maximale disponible n’est pas un objectif.

Un modèle modeste peut convenir à certaines extractions ou reformulations. Il ne suffit pas largement à tous les traitements documentaires : qualité, langue, documents et niveau d’erreur acceptable doivent être éprouvés.

Une architecture mixte peut réserver des traitements à l’interne et d’autres à une API, si les flux sont autorisés et correctement séparés. Elle n’offre pas automatiquement plus de souveraineté qu’une autre : accès, stockage, dépendances et maintenance comptent aussi.

Le cadre de départ reste la confidentialité des prompts. Une formation à l’IA peut apprendre à lire ensemble licence, fiche technique et résultats de recette, pour que l’ouverture des poids devienne une décision documentée.

Les erreurs à éviter consistent à confondre accès aux poids et service exploitable, paramètres actifs et ressources totales, ou licence permissive et conformité de tous les usages. Chacune masque un travail encore nécessaire.

• Confondre ouvert et gratuit. Chiffrer matériel, énergie, intégration et exploitation.
• Dimensionner sur les seuls paramètres actifs. Examiner tous les poids et leur placement.
• S’arrêter à la licence. Tester le chargement, le comportement et les autres contraintes du projet.
• Présumer un assistant prêt. Vérifier l’ajustement aux consignes et la qualité sur la tâche.

Un audit IA peut comparer hébergement et API à partir des données, des moyens et des tests disponibles.

Avant d’héberger un modèle ouvert, il faut établir les ressources nécessaires, les droits applicables et la qualité utile, puis comparer ces résultats aux moyens réellement disponibles dans l’organisation.