Un poids, c'est un nombre à virgule flottante. Rien de plus. Chaque connexion entre deux neurones d'un réseau porte un de ces nombres, et un grand modèle de langage moderne en compte des milliards — arrangés en énormes matrices, une par couche. Avant le début de l'entraînement, ces matrices sont remplies de valeurs qui ressemblent essentiellement à du bruit aléatoire (nous reviendrons sur l'initialisation dans un instant). Puis le réseau voit des données, calcule à quel point ses prédictions sont fausses via une fonction de perte, et la rétropropagation fait remonter le gradient de cette erreur à travers chaque couche, en poussant chaque poids d'une infime quantité dans la direction qui aurait rendu la prédiction moins fausse. Répétez cela quelques milliards de fois sur des téraoctets de texte et vous obtenez un modèle capable d'écrire de la poésie, d'expliquer la mécanique quantique, ou de déboguer votre code. Les poids sont l'endroit où vit toute cette capacité apprise. Il n'y a pas de stockage de connaissances séparé, pas de base de données de faits — juste des matrices de nombres qui, sous la pression statistique pure, se sont organisées en quelque chose qui ressemble beaucoup à de la compréhension.
Le format dans lequel vous stockez ces nombres compte plus que vous ne pourriez le penser. Les poids en pleine précision utilisent fp32 — virgule flottante sur 32 bits — ce qui vous donne environ 7 chiffres décimaux de précision et une plage dynamique énorme. C'est ce que les chercheurs ont utilisé pendant des années, et c'est encore l'étalon-or de la stabilité numérique. Mais fp32 coûte cher : un modèle de 7 milliards de paramètres en fp32 consomme 28 Go juste pour les poids, avant même de penser aux états de l'optimiseur ou aux activations. La demi-précision fp16 coupe cela en deux, mais sa plage d'exposant limitée le rend sujet aux dépassements et sous-dépassements pendant l'entraînement. C'est là qu'arrive bf16 — bfloat16 — qui conserve la plage d'exposant de fp32 mais tronque la mantisse à 16 bits. Google l'a développé spécifiquement pour l'apprentissage profond, et c'est devenu le standard de fait pour l'entraînement parce qu'il explose rarement numériquement tout en utilisant la moitié de la mémoire de fp32. Pour l'inférence, vous pouvez aller plus loin : la quantification int8 empaquette les poids dans des entiers 8 bits (un quart de la taille de fp32) avec étonnamment peu de perte de qualité, et int4 — pionnier des méthodes GPTQ et AWQ — divise encore par deux. Un modèle 70B qui aurait besoin de 140 Go en fp16 tient dans environ 35 Go en précision 4 bits, et c'est pour cette raison que la quantification est ce qui vous permet de faire tourner des modèles sérieux sur des GPU grand public.
Quand vous téléchargez un modèle, le format du fichier détermine comment ces matrices de poids sont sérialisées sur disque. Pendant des années, le défaut était le format .bin de PyTorch, qui n'est rien d'autre que la sérialisation pickle de Python appliquée à des tenseurs. Ça fonctionne, mais pickle a un problème de sécurité bien connu : un fichier .bin malveillant peut exécuter du code arbitraire au moment du chargement. Hugging Face a créé safetensors spécifiquement pour corriger cela — c'est un format simple, mappé en mémoire, qui ne contient que des données de tenseurs et des métadonnées, sans aucune exécution de code possible. Safetensors charge aussi plus rapidement parce qu'il supporte le chargement paresseux et les lectures sans copie. C'est devenu le standard pour distribuer des modèles sur Hugging Face et au-delà. Puis il y a GGUF, qui est le format utilisé par llama.cpp et l'écosystème plus large de l'inférence locale. GGUF regroupe les poids, la configuration du tokenizer, et les métadonnées du modèle dans un seul fichier autonome, souvent avec quantification intégrée. Si vous faites tourner un modèle localement sur votre portable ou un GPU grand public, vous utilisez presque certainement un fichier GGUF. Version courte : safetensors pour la distribution et l'ajustement fin, GGUF pour l'inférence locale, et .bin uniquement quand vous tombez sur des points de contrôle hérités.
Avant même que l'entraînement ne commence, les valeurs que vous mettez dans ces matrices de poids façonnent tout ce qui suit. Initialisez-les toutes à zéro et le réseau ne peut pas apprendre — chaque neurone d'une couche calcule la même chose, donc les gradients sont identiques et la symétrie ne se brise jamais. Initialisez-les trop grandes et les activations explosent ; trop petites et les gradients s'évanouissent à zéro avant d'atteindre les premières couches. L'initialisation Xavier (2010) a résolu cela pour les réseaux à activations sigmoïde et tanh en mettant à l'échelle les poids initiaux selon le fan-in et le fan-out — le nombre de connexions entrantes et sortantes de chaque couche. L'initialisation Kaiming (2015, du papier de He et al.) a adapté l'idée pour les activations ReLU, qui se comportent différemment parce qu'elles mettent à zéro la moitié de leurs entrées. Les Transformers modernes utilisent typiquement des variantes de celles-ci, parfois avec des facteurs d'échelle supplémentaires ajustés pour les couches d'attention. Il y a aussi l'hypothèse du billet de loterie (Frankle & Carlin, 2019), qui a montré qu'à l'intérieur d'un réseau initialisé aléatoirement, il existe des petits sous-réseaux — des « billets gagnants » — qui peuvent être entraînés isolément pour égaler la performance du réseau complet. L'implication est saisissante : la plupart de ces milliards de poids initiaux pourraient être inutiles, et la bonne initialisation parcimonieuse pourrait théoriquement vous donner le même modèle pour une fraction de la taille. En pratique, trouver de manière fiable ces billets gagnants reste coûteux, mais l'idée a façonné la manière dont les chercheurs pensent à l'élagage et aux architectures efficaces.
Les gens utilisent « poids » et « paramètres » de manière presque interchangeable, et pour la plupart des usages c'est correct — mais techniquement, les paramètres incluent les biais (une petite constante ajoutée après la somme pondérée à chaque neurone) et toute autre valeur apprise comme les échelles de normalisation de couche. Dans un Transformer typique, les biais représentent une fraction infime du total des paramètres, donc quand quelqu'un dit qu'un modèle a 70 milliards de paramètres, ça veut effectivement dire 70 milliards de poids. Le point plus profond, c'est que quand vous téléchargez le fichier de poids d'un modèle, vous téléchargez tout ce que le modèle a appris. L'architecture — combien de couches, à quelle largeur, quelles fonctions d'activation — n'est qu'un plan. Les poids sont le bâtiment lui-même. Deux modèles avec des architectures identiques mais des poids différents se comporteront de manière complètement différente s'ils ont été entraînés sur des données différentes ou pendant des durées différentes. C'est pour ça que « publier les poids » est un acte si significatif : vous ne partagez pas un design, vous partagez le résultat accumulé de millions de dollars de calcul et de mois d'entraînement. La connaissance est dans les nombres.