Remplacer les poids des LLM par une recette : comment on tente de réduire 16 Go de matrices à quelques formules

Un modèle de 8 milliards de paramètres en fp16 pèse environ 16 Go : huit milliards de nombres de deux octets chacun. La version à 70 milliards atteint déjà 140 Go. La quantification à 4 bits ramène un modèle 8B à environ 4–5 Go, mais ce sont toujours les mêmes matrices, simplement avec une précision réduite. Habr AI a publié une analyse d'une idée plus radicale : ne pas stocker les poids eux-mêmes, mais une petite recette qui permet de les calculer.

L'annonce de l'article évoque plusieurs familles de méthodes de ce type. Les détails d'implémentation et les benchmarks ne figurent que dans l'article complet de l'auteur ; nous décrivons donc ci-dessous les approches elles-mêmes et leurs limites connues.

Un réseau qui dessine un réseau

La variante la plus connue est celle des hyperréseaux. L'idée a été décrite dans le travail HyperNetworks de 2016 : un petit réseau reçoit en entrée, par exemple, le numéro d'une couche et un vecteur apprenable, et produit en sortie les poids du grand réseau. Il suffit alors de stocker le générateur et un jeu de vecteurs courts.

Cette approche a un coût évident. Le générateur produit des poids issus d'une famille étroite, et si la tâche réelle exige des matrices « peu commodes », la précision chute. L'entraînement est aussi plus complexe : le gradient traverse deux niveaux de réseaux, et non un seul.

Formules et fractales

La deuxième branche repose sur des descriptions analytiques. Si les poids d'une couche épousent bien une fonction lisse, il suffit d'en stocker les coefficients et de calculer les valeurs à partir des coordonnées de chaque élément de la matrice. C'est le principe des représentations neuronales implicites, comme SIREN pour les images et NeRF pour les scènes.

L'idée fractale vient de la compression d'images de la fin des années 1980. Les blocs de données sont décrits comme des copies transformées d'autres blocs, et l'on stocke un ensemble de règles d'autosimilarité plutôt qu'un tableau. Pour les poids, c'est envisageable tant qu'ils contiennent une structure répétitive. Or les LLM entraînés sont loin de toujours en présenter une.

Les méthodes à base de générateurs de nombres pseudo-aléatoires relèvent de la même logique. Dans le travail SeedLM de 2024, un bloc de poids est approché par une combinaison d'une séquence produite par une courte graine (seed) et de quelques coefficients. On stocke la graine ; le reste est recalculé au chargement.

Le prix à payer

Dans ce domaine, la compacité n'est presque jamais gratuite. Les compromis généraux sont les suivants :

• Mémoire contre calcul. Les poids ne sont plus lus en mémoire mais générés, ce qui ajoute des opérations à chaque couche.
• Précision. Toute approximation introduit une erreur, et les erreurs s'accumulent avec la profondeur du modèle.
• Entraînement. On entraîne soit le modèle directement dans la paramétrisation compressée, soit on le compresse après l'entraînement ; dans ce second cas, la qualité dépend des propriétés des poids concernés.
• Matériel. Les GPU sont optimisés pour la multiplication de matrices denses. Une génération non standard des poids à la volée peut annuler le gain de mémoire.

L'auteur compare la trajectoire des LLM au destin du premier Doom, que l'on a fait tourner sur des calculatrices, des imprimantes et d'autres appareils électroniques du quotidien. Pour l'instant, la LLM n'en est pas là : elle ne tourne pas sur chaque bouilloire, car même un modèle fortement compressé se heurte à la bande passante mémoire, et pas seulement à son volume.

Conclusion pratique

Pour les ingénieurs qui déploient des modèles sur des appareils, la compression par recettes reste une piste de recherche. En production, ce sont toujours la quantification, les adaptateurs LoRA et la distillation qui fonctionnent. Les hyperréseaux et les méthodes à base de graines méritent d'être suivis par ceux qui butent sur la taille de la distribution : pour les applications mobiles, l'inférence dans le navigateur et les systèmes embarqués, même un gain de deux fois sur le stockage peut décider de la faisabilité du déploiement. Avant d'adopter quoi que ce soit, il faut vérifier trois points : la perte de qualité sur ses propres tâches, la latence sur le matériel cible et la complexité du réentraînement.