Comment fonctionne un LLM (bonus 3) : pourquoi des petits modèles

Un modèle est fait de ses paramètres, des nombres appris pendant l’entraînement, et ces nombres prennent de la place. Un modèle de 3,8 milliards de paramètres pèse, en 16 bits, environ 7,6 Go (calcul de la section 2) : il peut tenir sur un ordinateur portable. Un modèle de 405 milliards demande plusieurs cartes graphiques rien que pour être chargé en mémoire. Pourquoi viser petit, alors que les annonces portent surtout sur les plus grands ?

La même question peut être posée à un modèle qui tourne dans un centre de calcul, ou à un modèle installé sur un ordinateur portable. Le second répond sans connexion, et la question ne quitte pas l’appareil ; le premier dispose de bien plus de paramètres. Ce bonus compare ce que l’on gagne et ce que l’on perd, sans slogan : « petit » ne veut dire ni « mauvais », ni « gratuit ».

Ce bonus reprend deux notions déjà posées : le tableau d’architectures de l’épisode 5 et le coût d’entraînement de l’épisode 1, avec son ordre de grandeur 6 × N × D (N : nombre de paramètres ; D : nombre de tokens d’entraînement), marqué estimé.

1. Pourquoi plus petit ?

Le calcul nécessaire croît avec le nombre de paramètres. Avec la formule 6 × N × D du premier épisode (estimation), un modèle deux fois plus petit, entraîné sur les mêmes données, demande environ deux fois moins de calcul. C’est une estimation, pas une mesure.

La mémoire compte aussi. Pour répondre, les poids doivent être chargés en mémoire. Souvent, c’est le premier obstacle, avant le calcul lui-même (section 2).

L’exécution locale, enfin. Hors ligne, les données ne quittent pas l’appareil. Une fois le modèle téléchargé, une requête ne passe plus par un service distant. Le matériel reste à la charge de l’utilisateur.

La latence, c’est le délai avant la première réponse. Un modèle plus petit répond souvent plus vite. Cette vitesse dépend du matériel et de la bande passante mémoire (le débit auquel les poids sont lus). Aucune vitesse n’est chiffrée ici : elle dépend trop du matériel.

2. La mémoire des poids

Un bit est une valeur 0 ou 1. Un octet regroupe 8 bits. Un paramètre est stocké sur 16, 8 ou 4 bits, soit 2, 1 ou 0,5 octet. Ces tailles donnent la mémoire des seuls poids. Ici, un Go (gigaoctet) vaut 10⁹ octets, comme dans l’épisode 1.

Pour 8 milliards de paramètres : 8 × 10⁹ × 2 = 16 × 10⁹ octets, soit 16 Go en 16 bits ; 8 × 10⁹ × 1 octet = 8 Go en 8 bits ; 8 × 10⁹ × 0,5 octet = 4 Go en 4 bits.

Comparaison avec une carte NVIDIA H100 : selon la fiche du fabricant, elle a 80 Go de mémoire. Les poids en 16 bits occupent 20 % de cette mémoire (calcul : 16 / 80), et en 4 bits 5 % (4 / 80). Sur un ordinateur portable fictif de 16 Go, les poids en 16 bits prendraient toute la mémoire. Ce n’est pas possible en pratique, car le système et les autres programmes en ont besoin. 8 Go en 8 bits en prennent la moitié, et 4 Go en 4 bits un quart.

Même calcul pour 70 milliards de paramètres : 140 Go en 16 bits, soit au moins deux cartes de 80 Go (140 / 80 = 1,75) ; 70 Go en 8 bits ; 35 Go en 4 bits, de quoi tenir sur une seule carte de 80 Go.

Ces chiffres ne comptent que les poids. Il faut y ajouter le cache de calcul (les données gardées pendant la réponse), les activations (les valeurs calculées à chaque étage du modèle) et les petits tableaux d’échelle de la quantification (arrondi des poids, section 3). Le besoin réel est donc plus élevé. C’est la même logique que pour Llama 3 405B, dont les poids seuls pèsent 810 Go en 16 bits (épisode 5).

3. La quantification : arrondir les poids

Quantifier, c’est arrondir chaque poids à l’un des niveaux d’une grille plus petite. Avec 4 bits, il y a 16 niveaux possibles, de −8 à 7. Plus il y a de niveaux, moins l’arrondi se voit.

Exemple fictif, avec quatre poids inventés (w désigne un poids). L’échelle s est la taille d’un pas de la grille : s = plus grande valeur absolue / 7 = 1,27 / 7 ≈ 0,1814. Chaque poids est divisé par s, arrondi à l’entier le plus proche, puis multiplié de nouveau par s.

L’erreur moyenne de cet exemple (écart moyen entre poids d’origine et poids reconstruit) : (0,087 + 0,053 + 0,050 + 0) / 4 = 0,0475.

Le petit poids 0,05 devient 0. C’est le piège à retenir : un poids faible peut disparaître. Cette erreur ne reste pas isolée. Elle se propage dans les calculs suivants, couche après couche. Cet exemple montre le mécanisme, pas l’effet sur un modèle réel.

Des méthodes publiées existent. GPTQ (Frantar et al., 2022, arXiv 2210.17323) quantifie les poids après l’entraînement. LLM.int8() (Dettmers et al., 2022, arXiv 2208.07339) fait l’inférence (l’utilisation du modèle pour répondre) en 8 bits, en traitant à part certaines valeurs extrêmes. Ce sont des références de méthode : elles ne fournissent ici aucun chiffre de qualité.

Ce que le texte ne chiffre pas : le pourcentage de qualité perdue par un modèle quantifié.

4. Les lois d’échelle, sans leur faire dire plus

Une loi d’échelle relie la perte d’un modèle (l’erreur que l’entraînement cherche à réduire) à sa taille, à la quantité de données et au calcul. Kaplan et al. (2020, arXiv 2001.08361) décrivent une loi de puissance pour ces grandeurs. Leur conclusion, en 2020 : à budget de calcul fixé, mieux vaut entraîner un très grand modèle sur une quantité modérée de données, et l’arrêter bien avant la convergence (le point où la perte ne baisse plus guère).

Hoffmann et al. (2022), avec Chinchilla (arXiv 2203.15556), montrent que la taille du modèle et le nombre de tokens doivent croître ensemble : à calcul égal, les grands modèles de l’époque étaient entraînés sur trop peu de données. C’est une correction de la lecture de 2020.

Le modèle Chinchilla lui-même compte 70 milliards de paramètres, entraînés sur 1 400 milliards de tokens (publié, même article), soit 20 tokens par paramètre (calcul). C’est l’origine du repère usuel « environ 20 ». L’article ne l’énonce pas comme une règle : c’est un ordre de grandeur pour lire un chiffre, pas une consigne de conception.

Le ratio tokens par paramètre se calcule : tokens d’entraînement divisés par paramètres. Trois exemples, avec leurs sources :

• GPT-3, 175 milliards de paramètres, 300 milliards de tokens (Brown et al., 2020, arXiv 2005.14165, publié) : 300 × 10⁹ / 175 × 10⁹ ≈ 1,7.
• Llama 3 405B, 15,6 billions de tokens (Grattafiori et al., 2024, arXiv 2407.21783, publié) : 15,6 × 10¹² / 405 × 10⁹ ≈ 38,5, en comptant les tokens d’entraînement publiés, avec répétitions possibles.
• Phi-3-mini, 3,8 milliards de paramètres, 3,3 billions de tokens (Abdin et al., 2024, arXiv 2404.14219, publié) : 3,3 × 10¹² / 3,8 × 10⁹ ≈ 868.

Llama 3 405B (environ 38,5 tokens par paramètre) et Phi-3-mini (environ 868) dépassent ce repère ; GPT-3 (environ 1,7) reste très en dessous. Un petit modèle entraîné sur beaucoup de données n’est pas un échec. C’est souvent un choix, fait pour l’usage visé.

5. Ce qu’un petit modèle perd, et ce qu’il garde

Un petit modèle n’est pas un grand modèle en miniature. Selon les tendances observées, il retient moins de faits rares et tient moins bien les raisonnements longs. Mais une partie de sa qualité vient des données et de l’entraînement, pas seulement de la taille.

Ce qu’il garde, selon un usage courant : la grammaire, la reformulation, le résumé de textes courts, l’aide à l’écriture simple. Il s’agit d’une tendance d’usage, pas d’une mesure.

Quelques modèles publiés, avec leur taille annoncée :

• Phi-3-mini : 3,8 milliards de paramètres (arXiv 2404.14219). Ses auteurs attribuent une part de ses résultats au choix des données d’entraînement. Le titre du rapport annonce un modèle capable de tourner sur un téléphone : aucune vitesse n’est mesurée ici.
• Gemma (Gemma Team, 2024, arXiv 2403.08295) : deux tailles publiées, 2 et 7 milliards de paramètres.
• Mistral 7B (Jiang et al., 2023, arXiv 2310.06825) : 7 milliards de paramètres. Selon le résumé, il dépasse Llama 2 13B sur les benchmarks évalués par les auteurs.
• Llama 3 8B : 8 milliards de paramètres, retenus ici pour la mémoire ; l’architecture est décrite à l’épisode 5.

Un score moyen de benchmark cache les tâches où le petit modèle échoue. Un benchmark ne mesure ni la fiabilité sur vos propres documents, ni le ton, ni les erreurs graves rares. Ce texte ne donne donc aucun pourcentage de perte entre un grand et un petit modèle.

6. Quatre pièges de lecture

• « Petit » ne veut pas dire « moins cher à tout » : un petit modèle utilisé beaucoup peut coûter autant, ou plus, qu’un gros modèle utilisé peu.
• Un chiffre de mémoire ne compte ni le cache ni les activations : le besoin réel est plus élevé.
• La quantification n’est pas gratuite : c’est un arrondi, et ses effets dépendent de la tâche.
• Un ratio tokens par paramètre n’est pas une règle de conception : c’est la lecture d’un résultat, et les choix actuels s’en éloignent.

7. Un petit modèle est-il une archive compressée ?

La question est juste sur un point : un modèle est bien une forme de compression. Mais c’est une compression avec perte (on ne retrouve pas le texte d’origine), qui garde des régularités plutôt que des textes. Il ne restitue pas ses textes d’entraînement, sauf passages très répétés. L’épisode 1 (section 6) a posé cette idée ; elle est reprise ici pour les petits modèles. Il faut d’abord séparer deux choses. La quantification (section 3) arrondit les poids sur moins de bits. La compression des régularités des données, elle, se fait pendant l’entraînement.

Le zip, le JPEG, le lecteur qui a tout lu

Le zip (exemple imaginaire) : la phrase « Le chat dort sur le canapé. » répétée cent fois se réduit à quelques lignes, et la décompression redonne les cent phrases. Ce qui éclaire : une information se compresse quand elle se répète. Ce qui trompe : un modèle ne décompresse pas ses textes d’entraînement ; il produit, en général, du texte nouveau à chaque réponse.

Le JPEG (exemple imaginaire) : une photo d’une prairie de dix mille brins d’herbe, réduite à quelques dizaines de kilo-octets. On reconnaît la prairie, pas chaque brin ; un brin unique peut disparaître. Ce qui éclaire : on garde la structure et l’on perd les détails rares. Ce qui trompe : la photo réduite est une copie dégradée ; le modèle n’a pas la prairie, il a des régularités qui lui servent à écrire, parfois faux avec assurance.

Le lecteur qui a tout lu (exemple imaginaire) : un lecteur qui a lu « Le Petit Prince » vingt fois en retient trois idées, sans citer une phrase. Ce qui éclaire : une compression qui garde le sens et abandonne les formulations. Ce qui trompe : le lecteur a une mémoire de ses lectures et un but ; le modèle n’a ni souvenir ni intention.

Des boutons, pas des fiches

Un paramètre n’est pas une case qui contient un fait. Morris et al. (2025, arXiv 2505.24832) estiment la mémorisation à environ 3,6 bits par paramètre. Réserve importante : cette mesure porte sur de petits modèles de type GPT, de 500 000 à 1,5 milliard de paramètres, entraînés sur des données aléatoires. L’extension aux grands modèles n’est pas mesurée : c’est une estimation, pas une constante.

Si cette valeur valait pour un modèle de 8 milliards de paramètres, cela ferait environ 3,6 Go, contre 16 Go en 16 bits. Ce calcul est une conséquence de l’hypothèse, non une mesure. Il dit que le modèle ne peut pas tout garder : il garde surtout des régularités.

La mémorisation (retenir des données précises) ne dit rien de la généralisation, qui est la part utile, ni de la qualité des réponses.

La compression n’est pas magique

Une suite de vingt lettres « A » se décrit par « 20 × A ». Une suite de vingt lettres tirées au hasard n’a pas de raccourci. On ne compresse donc que ce qui se répète, et les textes humains sont très réguliers. Delétang et al. (2023, arXiv 2309.10668) relient prédiction et compression : un modèle prédictif peut servir de compresseur. Leurs mesures portent sur des jeux de données et des modèles donnés. Aucun taux de compression n’est repris ici.

Il existe une exception observée. Carlini et al. (arXiv 2012.07805, publié à USENIX Security 2021) décrivent l’extraction de passages mémorisés depuis un modèle de langage. Ils l’ont observée sur des modèles et des passages donnés. Elle ne décrit pas le fonctionnement général du modèle.

8. Deux exercices

Exercice 1 (tenir sur un ordinateur). Un modèle de 3,8 milliards de paramètres doit tenir dans 8 Go de mémoire disponible, poids seuls. Quelles précisions (16, 8, 4 bits) respectent cette limite ? Corrigé : 3,8 × 10⁹ × 2 = 7,6 Go en 16 bits : oui, mais il ne reste que 0,4 Go, insuffisant en pratique. 3,8 Go en 8 bits : oui, avec une marge de 4,2 Go. 1,9 Go en 4 bits : oui. La réponse attendue est 8 ou 4 bits, avec une remarque sur le cache et les activations.

Exercice 2 (lire un ratio, chiffres inventés). Un modèle de 7 milliards de paramètres est entraîné sur 140 milliards de tokens. Calculez le ratio. Que devient-il si le même modèle est entraîné sur 2 000 milliards de tokens ? Corrigé : 140 × 10⁹ / 7 × 10⁹ = 20, le repère de Chinchilla. Avec 2 000 milliards de tokens : 2 000 / 7 ≈ 285,7. Un ratio ne dit rien de la qualité finale : il décrit seulement un équilibre entre taille et données.

9. Et après ?

Une question reste ouverte : peut-on transmettre à un petit modèle une partie de ce qu’un grand modèle sait faire ? La réponse est dans le bonus 4, « La distillation ».

Mini-glossaire

• Paramètre : nombre appris pendant l’entraînement ; le modèle est fait de ses paramètres.
• Octet, bit : un bit est une valeur 0 ou 1 ; un octet regroupe 8 bits. Un Go vaut 10⁹ octets dans ce texte.
• Quantification : arrondi des poids à une grille de niveaux plus petite, pour réduire la mémoire.
• Mémoire vive (RAM) et mémoire de carte graphique : où se chargent les poids pour répondre.
• Inférence : utilisation d’un modèle déjà entraîné, pour produire une réponse.
• Latence : délai entre la question et le début de la réponse.
• Lois d’échelle : relations approximatives entre perte, taille, données et calcul.
• Token : unité de texte manipulée par le modèle, déjà posée au premier épisode.
• Ratio tokens/paramètre : nombre de tokens d’entraînement divisé par le nombre de paramètres.
• Benchmark : ensemble de tâches et de scores, qui ne couvre qu’une partie des usages réels.

Références

• Morris et al., « How much do language models memorize? », 2025 (arXiv 2505.24832) : capacité de mémorisation estimée sur de petits modèles et des données aléatoires (mesure à réserver), en anglais.
• Delétang et al., « Language Modeling Is Compression », 2023 (arXiv 2309.10668) : un modèle prédictif comme compresseur, en anglais.
• Carlini et al., « Extracting Training Data from Large Language Models », USENIX Security 2021 (arXiv 2012.07805) : extraction de passages mémorisés, en anglais.
• Abdin et al., « Phi-3 Technical Report », 2024 (arXiv 2404.14219) : 3,8 milliards et 3,3 billions de tokens pour la version mini.
• Gemma Team, « Gemma », 2024 (arXiv 2403.08295) : 2 et 7 milliards.
• Jiang et al., « Mistral 7B », 2023 (arXiv 2310.06825) : 7 milliards.
• Kaplan et al., « Scaling Laws for Neural Language Models », 2020 (arXiv 2001.08361) : loi de puissance, sans ratio chiffré.
• Hoffmann et al., « Training Compute-Optimal Large Language Models », 2022 (arXiv 2203.15556) : croissance conjointe ; Chinchilla, 70 milliards de paramètres et 1 400 milliards de tokens, soit 20 tokens par paramètre (calcul).
• Brown et al., « Language Models are Few-Shot Learners », 2020 (arXiv 2005.14165) : GPT-3, 175 milliards de paramètres, 300 milliards de tokens.
• Grattafiori et al., « The Llama 3 Herd of Models », 2024 (arXiv 2407.21783) : 15,6 billions de tokens pour Llama 3 405B, publié (déjà cité à l’épisode 5).
• Frantar et al., « GPTQ », 2022 (arXiv 2210.17323) : référence de méthode de quantification.
• Dettmers et al., « LLM.int8() », 2022 (arXiv 2208.07339) : référence de méthode de quantification.
• NVIDIA, fiche de la carte H100 : 80 Go de mémoire, valeur donnée par le fabricant.