Comment fonctionne un LLM (1/6) : c’est quoi, au juste ?
Qui a écrit cette série ?
Cette série a été pilotée, critiquée et validée par Alex, qui en a fixé le plan, les règles de sources et le ton. Les textes ont été rédigés en co-écriture avec Claude (Anthropic) : Claude a proposé des plans, des calculs, des sources et des formulations, qu’Alex a relus, corrigés ou refusés. Alex est responsable du contenu publié.
Vous avez déjà tapé une question dans une IA et vu la réponse s’écrire mot après mot, comme si quelqu’un la tapait en face de vous. L’impression est forte, et elle est trompeuse : derrière, il n’y a ni bibliothécaire qui cherche la page, ni cerveau qui réfléchit au sens où nous l’entendons, mais une répétition très simple, faite des milliards de fois.
Cette série veut démonter la machine sans magie. Le premier épisode pose les bases : ce que fait réellement un grand modèle de langage (LLM, Large Language Model), pourquoi sa réponse varie, ce que sont les tokens, comment il apprend et ce que coûte cet apprentissage, et pourquoi il paraît intelligent alors qu’il ne l’est peut-être pas. Des exemples, des schémas et quelques calculs, à la portée de tous.
À la fin de cet épisode, vous saurez :
• ce qu’un LLM fait à chaque étape : il attribue une probabilité à chaque morceau de texte possible pour la suite, puis en tire un au hasard ;
• ce qu’est un token : un morceau de texte, associé à un numéro, qui sert d’unité de lecture et de comptage ;
• ce qu’est un entraînement : une procédure qui règle des paramètres pour réduire une perte, c’est-à-dire l’écart entre la prédiction et le token qui figurait réellement dans le texte ;
• pourquoi « plausible n’est pas vrai » : une réponse peut être probable dans la langue sans être juste.
1. Ce que fait vraiment un LLM
Essayez de compléter cette phrase : « Le chat dort sur le… ». Vous avez pensé à « canapé », « tapis » ou « lit » en une fraction de seconde. Vous n’avez consulté aucune liste de phrases : vous avez deviné la suite à partir de ce que vous savez du monde et du français.
Un LLM fait exactement cela, à une échelle qui change tout. À partir du texte déjà écrit, il attribue une probabilité à chaque morceau de texte possible pour la suite. Il en tire un au hasard, selon ces probabilités, l’ajoute au texte, puis recommence avec le texte un peu plus long.
Voici, pour la phrase ci-dessus, ce que le modèle pourrait calculer à une étape donnée. Les pourcentages sont fictifs, choisis pour l’exemple :
Voilà l’essentiel : le modèle ne « sait » pas la réponse. Il attribue un pourcentage à chaque suite possible. Ici, le canapé gagne, mais le tapis et le lit restent plausibles. Il n’écrit donc pas la phrase entière à l’avance : il avance pas à pas, en boucle.
Une réponse de dix paragraphes représente ainsi des milliers de petites décisions, chacune consistant à deviner le morceau suivant à partir de tout ce qui a déjà été écrit.
2. Pourquoi la même question donne des réponses différentes
Si l’on tirait toujours le mot le plus probable, le modèle répondrait la même chose à chaque fois. Or, dans la plupart des outils, on obtient des réponses différentes d’un essai à l’autre. C’est le tirage qui introduit la variation.
Reprenons la distribution précédente. Sur 100 tirages, le canapé sort environ 38 fois, le tapis 22 fois, le lit 17 fois. Donc P(canapé) = 38/100 = 0,38, et P(tapis ou lit) = 22/100 + 17/100 = 0,39. Le canapé est le choix le plus fréquent, mais il n’est pas garanti : sur 1 000 tirages, on attend environ 380 « canapé », 220 « tapis » et 170 « lit ». Les résultats réels varient un peu d’une série à l’autre.
Trois tirages successifs, pour la même phrase de départ (exemple illustratif) :
| Essai | Mot tiré | Phrase obtenue |
|---|---|---|
| 1 | canapé | Le chat dort sur le canapé. |
| 2 | tapis | Le chat dort sur le tapis. |
| 3 | canapé | Le chat dort sur le canapé. |
Le réglage appelé température joue sur cette variation : une température basse rend le modèle plus prévisible (il privilégie les mots les plus probables), une température haute le rend plus inventif, et donc plus risqué. C’est pour cela qu’une même question peut donner des réponses un peu différentes à chaque essai.
3. Le token, la brique de base
Le modèle ne lit pas des mots. Il lit des tokens : des morceaux de texte, chacun associé à un numéro dans une liste. Pourquoi ne pas utiliser simplement les mots ? Parce que la liste serait infinie : les noms propres, les fautes, les nombres, les mots composés, les langues entières, les mots nouveaux. Les tokens permettent de couvrir n’importe quel texte avec une liste de taille raisonnable.
Un token peut être un mot entier, une partie de mot, une syllabe, un espace ou un signe de ponctuation. Voici un découpage illustratif de la phrase « Le chat dort sur le canapé. » :
Trois remarques à garder en tête :
- le découpage dépend du modèle : deux modèles ne couperont pas un même texte de la même façon ;
- un mot courant tient souvent en un seul token (« chat », par exemple), alors qu’un mot rare, long ou un nom propre se découpe en plusieurs morceaux ;
- pour une même idée, un texte en français produit souvent davantage de tokens qu’un texte en anglais. C’est un ordre de grandeur, pas une règle.
Un même texte peut être découpé différemment selon l’outil de découpage (tokenizer, voir glossaire). Une phrase de quatre mots, comme « Je pousse en arbre », peut ainsi donner cinq tokens avec un outil et sept avec un autre (exemple illustratif, non mesuré). Le nombre de tokens d’un texte n’est donc pas une propriété du texte seul : il dépend aussi du modèle qui le lit.
Pour le modèle, un token n’est qu’un numéro.
Quand le modèle « voit » le mot « canapé », il reçoit en réalité une suite d’identifiants numériques. Il n’a pas d’orthographe ni de lettres sous les yeux, sauf si l’information est encodée dans les tokens eux-mêmes. C’est pour cela qu’il peut se tromper sur le nombre de lettres d’un mot, ou sur son orthographe, alors qu’il rédige des phrases correctes.
Les limites de longueur et les tarifs des services d’IA se comptent en tokens, pas en mots ni en pages : c’est la raison pratique à retenir.
4. Ce qu’un LLM n’est pas
Trois confusions reviennent sans cesse. Les écarter tout de suite évite bien des malentendus.
Ce n’est pas une base de données de phrases
Pendant l’entraînement, le modèle ne range pas les textes dans un fichier qu’il irait consulter. Ce qu’il conserve, ce sont des paramètres : des nombres, ajustés pour que ses prédictions collent mieux aux textes vus. Le savoir est donc réparti dans ces nombres, pas rangé quelque part. Cette idée se compare à la différence entre un carnet de recettes et le goût qu’un cuisinier a acquis à force de cuisiner : le second ne retrouve pas une recette par cœur, il recompose des plats à partir de ce qu’il sait.
GPT-3, publié en 2020, comptait 175 milliards de paramètres (article arXiv 2005.14165). Ce sont des milliards de réglages, dont aucun, pris isolément, ne contient une phrase lisible.
Ce n’est pas un moteur de recherche
Quand vous posez une question, le modèle ne va pas chercher une page sur internet. Il produit une suite de morceaux à partir de ses paramètres. Certains services lui ajoutent un outil de recherche à côté : c’est une fonction rajoutée au système, pas le modèle lui-même. Sans cet outil, il répond à partir de ce qu’il a appris pendant son entraînement.
Ce n’est pas un vérificateur de faits
Le modèle optimise la vraisemblance d’une suite de mots, pas sa vérité. Il peut donc produire une référence bibliographique qui a toutes les apparences d’un vrai article, avec un auteur plausible, une revue plausible et une année plausible, sans que rien de tout cela n’existe. C’est ce qu’on appelle une hallucination.
Plausible n’est pas vrai
Une réponse fluide et bien construite signale seulement que la suite est probable dans la langue. Elle ne dit rien de sa justesse. Il faut vérifier les dates, les chiffres, les noms et les sources, surtout quand ils semblent parfaits.
5. L’entraînement en détail
Jusqu’ici, on a écrit que le modèle « apprend ». Cette section explique ce que recouvre ce mot : des données, du calcul, de l’électricité et du matériel. Chaque chiffre est étiqueté publié (annoncé par le fournisseur ou dans un article) ou estimé (calcul ou estimation d’un tiers).
En bref
L’entraînement ajuste des milliards de paramètres sur des milliers de milliards de tokens, avec des milliers de cartes graphiques (GPU, des puces qui calculent en parallèle) pendant des semaines. Les termes techniques sont définis dans le glossaire en fin d’article.
5.1 Ce qu’est un entraînement
Un entraînement règle les paramètres d’un modèle pour réduire une perte : l’écart entre ce que le modèle prédit et ce qui figurait réellement dans le texte. Pour un LLM, la mesure est simple : quelle probabilité le modèle a-t-il donnée au token qui suivait vraiment ?
L’entraînement répète toujours les mêmes quatre gestes :
- on prend un lot (batch) de textes découpés en tokens ;
- le modèle donne une probabilité au token attendu, à chaque position, ce qui produit une perte ;
- la rétropropagation indique, pour chaque paramètre, dans quel sens le corriger ;
- les paramètres sont mis à jour d’un tout petit pas, selon la descente de gradient : on suit la pente de la perte, comme une bille qui roule vers le fond d’une vallée.
Une étape, c’est un lot traité suivi d’une mise à jour. Un entraînement enchaîne un très grand nombre d’étapes. Image utile : régler des milliards de boutons, chacun d’un tout petit cran, à chaque nouvelle portion de texte.
Une précision importante : deviner le token suivant est le cœur de l’entraînement des LLM les plus répandus, mais pas toute l’histoire. Après cette étape, les modèles grand public passent par un réglage supplémentaire, avec retours humains ou méthodes équivalentes. Nous y reviendrons dans le dernier épisode.
Voici un exemple, avec des valeurs fictives. La phrase d’entraînement est « Le chat dort sur le canapé. », avec le mot « canapé » masqué. Le modèle donne au bon mot une probabilité de 0,10 : il préfère « tapis ». La perte se calcule avec le logarithme (noté ln) de cette probabilité : on prend −ln(0,10), soit environ 2,30. Plus la probabilité du bon mot est faible, plus la perte est grande. On corrige ensuite les paramètres pour que « canapé » devienne plus probable. Au tour suivant, sa probabilité passe à 0,38, et la perte tombe à −ln(0,38) ≈ 0,97.
5.2 Les données : quelle quantité ?
La quantité de données se compte en tokens. Pour GPT-3, publié en 2020, le modèle a été entraîné sur environ 300 milliards de tokens (publié, article arXiv 2005.14165). Le corpus (l’ensemble des textes disponibles) était plus grand que ce qui a été vu pendant l’entraînement : chaque source a reçu un poids, c’est-à-dire une part des tokens vus. Le tableau donne les parts du mélange d’entraînement et le volume de chaque source :
| Source | Taille du corpus | Part des tokens d’entraînement |
|---|---|---|
| Common Crawl (pages web filtrées) | 410 milliards de tokens | 60 % |
| WebText2 (pages web sélectionnées) | 19 milliards | 22 % |
| Livres 1 | 12 milliards | 8 % |
| Livres 2 | 55 milliards | 8 % |
| Wikipédia | 3 milliards | 3 % |
Pour Llama 3 405B, un modèle de Meta publié en 2024, le chiffre publié est de 15,6 billions de tokens, soit 15 600 milliards, environ cinquante fois plus que GPT-3 (publié, arXiv 2407.21783). Ce sont des tokens vus pendant l’entraînement, qui peuvent inclure des répétitions. Le volume de texte brut correspondant est d’environ 62 To (estimé, avec 4 octets par token : voir glossaire).
Pour donner un ordre d’idée en livres : avec l’hypothèse de 130 000 tokens par livre (100 000 mots, soit environ 1,3 token par mot en moyenne), 15,6 billions de tokens représentent environ 120 millions de livres (estimé). Avec 200 000 tokens par livre, on obtient 78 millions : le résultat dépend fortement de cette hypothèse.
Le volume ne suffit pas : les données sont filtrées, dédupliquées et réparties entre langues, codes et domaines. Le mélange compte autant que la quantité.
5.3 Les sources et le filtrage
Un ordre d’idée : les grands corpus publics se mesurent en milliers de milliards de tokens. Les tailles de texte brut sont données en octets (Go, To, voir glossaire). Le tableau donne quelques corpus, avec leur taille telle que publiée.
| Corpus | Taille | Date | Statut |
|---|---|---|---|
| The Pile (EleutherAI) | 825 Gio de texte brut | 2020 | publié (arXiv 2101.00027) |
| C4 (utilisé pour T5) | environ 750 Go | 2019 | publié (arXiv 1910.10683) |
| RefinedWeb (Falcon) | environ 5 000 milliards de tokens ; extrait public de 600 milliards | 2023 | publié (arXiv 2306.01116) |
| FineWeb (Hugging Face) | 15 000 milliards de tokens | 2024 | annoncé par ses auteurs (arXiv 2406.17557) |
| FineWeb-Edu | 1 300 milliards de tokens | 2024 | annoncé (même source) |
| Dolma (AI2) | 3 000 milliards de tokens | 2024 | publié (arXiv 2402.00159) |
| Common Crawl, crawl de février 2026 | 2,1 milliards de pages ; 363 TiB non compressés | 2026 | publié (commoncrawl.org) |
| Wikipédia en français (dump) | environ 7 Go compressés | 2026 | publié (dumps.wikimedia.org) |
| Project Gutenberg | 79 755 livres électroniques | non daté | publié (gutenberg.org) |
| The Stack v1.1 (code) | 6 To | 2022 | publié (bigcode-project.org) |
Le filtrage est une étape lourde. Le schéma ci-dessous résume les étapes de FineWeb et FineWeb-Edu : du texte extrait du web jusqu’aux tokens retenus. Le volume brut avant filtrage est rarement publié.
Pour FineWeb, la préparation suit les étapes suivantes (d’après l’article des auteurs) : extraction du texte depuis des instantanés du web (snapshots) issus de Common Crawl ; filtrage de la langue et de la qualité ; suppression des pages et des passages répétés, repérés notamment avec MinHash ; découpage en tokens. Chaque étape supprime une part des données.
Ce qu’il faut retenir : un corpus de quelques milliers de milliards de tokens représente plusieurs téraoctets de texte brut. Les données sont collectées, filtrées, dédupliquées, puis découpées en tokens avant d’être utilisées. Le filtrage est lourd : dans FineWeb-Edu, 1 300 milliards de tokens sont retenus sur 15 000 milliards (chiffres annoncés par les auteurs de FineWeb).
5.4 Le calcul : combien d’opérations ?
Une formule approchée, très utilisée dans la littérature (Kaplan et al., 2020, arXiv 2001.08361), donne le nombre d’opérations d’un entraînement : environ 6 × N × D, où N est le nombre de paramètres et D le nombre de tokens. Une opération est un calcul élémentaire, comme une multiplication. Le facteur 6 regroupe le calcul vers l’avant et le calcul vers l’arrière (estimation).
| Modèle | Paramètres | Tokens | Opérations (estimation) |
|---|---|---|---|
| GPT-3 (2020) | 175 milliards | 300 milliards | ≈ 3 × 10²³ |
| Llama 3 405B (2024) | 405 milliards | 15,6 billions | ≈ 3,8 × 10²⁵ |
Concrètement, 3,8 × 10²⁵ opérations, c’est un 38 suivi de 24 zéros. Aucun humain ne peut effectuer ce calcul : il est réparti sur des milliers de GPU, en parallèle, pendant des semaines.
5.5 Le matériel et le réseau
L’entraînement se fait sur des GPU, des cartes graphiques conçues pour calculer en parallèle. Llama 3 405B a été entraîné sur jusqu’à 16 000 GPU H100 de NVIDIA. Chacun consomme jusqu’à 700 W et dispose de 80 Go de mémoire (publié, arXiv 2407.21783, section 3.3.1).
Les GPU sont regroupés dans des serveurs de huit GPU chacun : il en faut environ 2 000 (estimé). La puissance maximale de l’ensemble atteint environ 20 MW, hors refroidissement (estimé). Cette puissance se consomme en continu : le parc tourne jour et nuit pendant toute la durée de l’entraînement.
Les GPU doivent aussi se parler en permanence : à chaque étape, ils mettent en commun leurs gradients. Si le réseau est lent, ils attendent, et ce temps perdu se paie : le matériel est mobilisé, qu’il calcule ou non. Les liaisons, très rapides, sont détaillées dans l’encadré « Pour les curieux » en fin de section.
5.6 La durée, les pannes et l’énergie
Meta a publié l’historique de l’entraînement de Llama 3 405B. Il couvre une fenêtre d’observation de 54 jours de pré-entraînement, avec 466 interruptions, dont 419 non planifiées (publié, arXiv 2407.21783, section 3.3.4). Ce n’est pas la durée totale de l’entraînement. Sur cette fenêtre, cela fait une interruption environ toutes les 2,8 heures (calcul à partir des chiffres publiés). Les GPU ont causé 58,7 % des pannes non planifiées (publié).
Un entraînement n’est donc pas une machine qui tourne sans accroc. Il faut détecter les pannes, reprendre à partir de points de sauvegarde (checkpoints) et réorganiser les GPU : c’est un travail d’exploitation à part entière.
L’énergie consommée par les seuls GPU de Llama 3 405B est estimée à environ 21,6 GWh (estimé). Un GWh vaut un million de kWh. Pour comparer : cela représente environ 5 400 logements français pendant un an, sur la base d’une hypothèse de 4 000 kWh par an et par logement (estimé). Ce chiffre est un plancher : il ne compte ni les processeurs, ni les réseaux, ni le refroidissement.
Pour GPT-3, l’article ne donne pas de chiffre d’énergie : les entreprises publient rarement ce type de donnée.
5.7 Le coût : bien plus que l’électricité
Le coût d’un entraînement de pointe n’est pas publié de façon homogène. Epoch AI, un institut qui suit ces chiffres, estime (publication du 3 juin 2024) que le coût amorti du matériel et de l’énergie du dernier entraînement de pointe a été multiplié par environ 2,4 par an depuis 2016 (estimation annoncée par Epoch, intervalle à 95 % : 2,0 à 3,1). Dans le coût de développement, le matériel représente de 47 à 67 %, la recherche et développement de 29 à 49 %, et l’énergie seulement de 2 à 6 % (estimé, même source). Le coût tient donc surtout au matériel et aux équipes.
5.8 À retenir sur l’entraînement
| Élément | Ordre de grandeur | Statut |
|---|---|---|
| Données, GPT-3 | 300 milliards de tokens | publié |
| Données, Llama 3 405B | 15,6 billions de tokens | publié |
| Calcul, Llama 3 405B | ≈ 3,8 × 10²⁵ opérations | estimé |
| GPU, Llama 3 405B | jusqu’à 16 000 H100 à 700 W | publié |
| Serveurs | environ 2 000 serveurs à 8 GPU | estimé |
| Puissance maximale | environ 20 MW, hors refroidissement | estimé |
| Fenêtre d’observation, Llama 3 405B | 54 jours de pré-entraînement, 466 interruptions | publié |
| Énergie, Llama 3 405B | environ 21,6 GWh (GPU seuls) | estimé |
Ce que l’entraînement ne fait pas
Une fois ces milliers de GPU arrêtés, le modèle ne se réentraîne pas en discutant avec vous. Ce qui reste, ce sont des paramètres figés. Il n’y a pas de mémoire de vos conversations dans le modèle lui-même.
Pour les curieux : détails techniques
La formule. Pour Llama 3 405B : 6 × 405 milliards × 15,6 billions ≈ 3,8 × 10²⁵ opérations (estimé).
Le serveur. Un DGX H100 de NVIDIA regroupe huit GPU et consomme jusqu’à environ 10 kW (documentation NVIDIA). Pour 2 000 serveurs : environ 20 MW au maximum. Les seuls GPU, à 700 W chacun, absorbent environ 11 MW ; le reste vient des processeurs, de la mémoire et des ventilateurs (estimé). Le TDP (puissance thermique de conception) est la valeur que le constructeur indique pour dimensionner le refroidissement : ce n’est pas une mesure exacte de la consommation.
Les liaisons. À l’intérieur d’un serveur, NVLink relie les GPU directement, jusqu’à 900 Go/s par GPU (fiche NVIDIA H100, publiée par le constructeur). Entre serveurs, les cartes InfiniBand atteignent jusqu’à 400 Gb/s chacune (fiches des cartes, source secondaire) ; huit cartes par serveur donnent environ 3,2 Tb/s. Comme un octet vaut 8 bits, 400 Gb/s font 50 Go/s.
Le réseau à chaque étape. L’opération all-reduce fait que chaque GPU reçoit la somme des gradients de tous les autres. Un réseau trop lent fait donc perdre du temps de calcul (estimé).
L’énergie, en détail. La carte modèle de Meta donne environ 30,84 millions d’heures GPU pour Llama 3 405B (estimé à partir de cette source). À 0,7 kW par GPU, cela fait environ 21,6 GWh, GPU seuls (estimé).
Les disques. Le tableau suppose des disques de 24 To ou de 30 To, entiers, sans RAID ni formatage : c’est une hypothèse de calcul, et une borne basse (estimé).
| Volume de texte brut | Disques de 24 To | Disques de 30 To |
|---|---|---|
| 15 To | 1 | 1 |
| 60 To | 3 | 2 |
| 1 Po (1 000 To) | 42 | 34 |
Combien de livres ? Un roman de 300 pages représente environ 0,6 à 1 Mo de texte brut (hypothèse : environ 2 000 caractères par page). Donc 15 To, c’est de l’ordre de 15 à 25 millions de romans ; 60 To, environ 60 à 100 millions ; 1 Po, environ 1 à 1,7 milliard (estimé).
Un entraînement ne « stocke » pas ces données une fois pour toutes : il les lit en flux, et les serveurs ont besoin d’un débit suffisant pour les alimenter.
6. Un LLM contient-il tout le savoir humain ?
Une question revient souvent, et elle mérite une réponse précise. Un LLM est-il une sorte de compression géante de tout ce qui a été écrit ? La réponse tient en trois points.
Un modèle garde des réglages, pas des textes
Un LLM n’est pas une bibliothèque de textes qu’il pourrait ouvrir. Après l’entraînement, il reste un ensemble de paramètres, c’est-à-dire de nombres figés. Le modèle Llama 3 405B (publié, Meta, 2024) en compte 405 milliards. Si chacun est stocké sur 16 bits, soit 2 octets, le fichier pèse environ 810 Go (estimé : 405 milliards × 2 octets). Cette hypothèse de 16 bits est un ordre de grandeur (estimé).
En face, son entraînement a porté sur 15,6 billions de tokens de texte (publié). En comptant en moyenne 4 octets par token (hypothèse, valable surtout pour l’anglais), cela représente environ 62 To de texte brut (estimé). Le texte d’entraînement est donc environ 77 fois plus volumineux que le modèle (estimé). Le modèle ne peut pas être une archive : il est bien trop petit pour contenir ce qu’il a lu.
Une compression avec pertes
Une photo compressée en JPEG ne garde pas chaque pixel. Elle conserve assez d’information pour reconnaître la scène, et jette le reste. En 2023, l’écrivain Ted Chiang a décrit ChatGPT comme « un JPEG flou du Web » (The New Yorker) : l’allure générale est là, les détails ont disparu, et ceux qui reviennent sont reconstruits de façon approximative.
La comparaison a ses limites. Un JPEG stocke des pixels, c’est-à-dire un état précis de l’image. Un LLM stocke des régularités : quels morceaux de texte apparaissent ensemble, et dans quelles situations. Il ne garde donc pas l’original, il garde ce qui se répète. Des chercheurs ont même montré qu’un modèle de langage peut servir de compresseur (Delétang et al., 2023). Cette différence explique pourquoi il reformule une idée très répandue avec aisance, et pourquoi il peut inventer un détail précis qui n’a jamais existé.
Le savoir absent
Le texte d’entraînement n’est pas tout le savoir humain. Une grande partie n’a jamais été écrite : savoir-faire transmis à l’oral, traditions locales, conversations privées, archives non numérisées.
Le texte disponible est aussi inégal : les langues peu documentées sont peu représentées, et les contenus publics sont filtrés (langue, qualité, doublons).
Les faits rares posent un problème particulier. Kandpal et al. (2022) ont montré que la précision d’un modèle sur un fait augmente avec le nombre de documents qui parlent de ce fait dans les données d’entraînement. Un fait cité dans quelques pages est donc retenu moins bien qu’un fait répété partout.
Dernière limite : la date de coupure. Les données s’arrêtent à un moment donné. Le modèle ne connaît pas ce qui s’est passé après, sauf si un outil externe lui apporte l’information.
La réponse nuancée
Alors, un LLM contient-il tout le savoir humain ? Non : il a été entraîné sur une part du texte public écrit, très filtrée, avec des faits rares mal couverts, et il ne connaît ni le savoir jamais écrit ni ce qui s’est passé après sa date de coupure.
Trois façons de répondre : oui, non, nuancé
Oui, il contient tout le savoir humain. Cette réponse suppose que le modèle stocke ses textes d’origine, ce que les chiffres ci-dessus excluent. C’est la plus fragile : elle confond un modèle et une bibliothèque.
Non, il ne contient rien d’utile. Cette réponse sous-estime la compression : un modèle entraîné sur des milliers de milliards de tokens retient des régularités réelles, et les ignorer empêche de savoir ce qu’il sait.
Nuancé : il contient une part du savoir écrit, déformée et inégale. Cette réponse précise quoi, pour quelles langues, quels faits et à quelle date. Elle est plus longue, mais chacune de ses parties peut être contrôlée.
7. Pourquoi cela ressemble à de l’intelligence
Pour bien prédire la suite d’un texte sur la physique, il faut souvent avoir capté quelque chose de la physique. Pour écrire une lettre de réclamation convaincante, il faut une idée de ce qu’est une réclamation. La prédiction, poussée assez loin, oblige donc à capter une partie de la structure du monde décrite par le langage.
Il y a aussi un réflexe humain. En 1966, le programme ELIZA, conçu par Joseph Weizenbaum, imitait un psychothérapeute en reformulant les phrases de l’utilisateur. Des personnes ont pourtant attribué à ce programme une compréhension réelle. Notre tendance à prêter une intention à quiconque parle avec fluidité joue encore aujourd’hui.
Les chercheurs ne tranchent pas. Certains y voient une forme de modélisation du monde ; d’autres répondent que ces modèles reproduisent des régularités statistiques du langage, sans rien comprendre au sens humain. Cette série ne tranche pas non plus : elle donne les outils pour se faire un avis.
Trois questions à se poser devant une réponse
1. Est-ce que je peux vérifier cette affirmation par une source indépendante ?
2. Est-ce que la réponse est fluide parce qu’elle est juste, ou parce qu’elle est simplement probable ?
3. Est-ce que je lui prête une intention qu’elle n’a pas forcément ?
8. À retenir, et la suite
- Un LLM attribue une probabilité à chaque morceau possible, en tire un au hasard, l’ajoute, puis recommence.
- Le tirage fait varier les réponses ; la température règle son audace.
- Il lit des tokens : des morceaux de texte, chacun associé à un numéro.
- Il s’entraîne en réduisant une perte, sur des milliers de milliards de tokens, avec des milliers de GPU pendant des semaines : une dépense d’énergie et de matériel considérable.
- Il ne stocke pas des textes, mais des paramètres ajustés pendant l’entraînement, puis figés.
- Sa fluidité ne prouve ni la justesse ni la compréhension : plausible n’est pas vrai.
Une question reste ouverte. Comment « chat » et « chaton », deux tokens différents, peuvent-ils être rapprochés par une machine qui ne manipule que des nombres ? Et que veut dire, pour un nombre, « être proche de » un autre ?
C’est la question de l’épisode 2 : les vecteurs, ou comment transformer chaque token en une suite de nombres dont la position dans un espace à des milliers de dimensions porte une partie du sens.
Lire la suite : « Comment fonctionne un LLM (2/6) : les vecteurs ».
Pour voir ces mécanismes à l’œuvre dans un cas concret, l’article « Écrire avec un LLM en 2026 » raconte comment un LLM a été utilisé pour ce blog.
Dans cette série
- 1/6 : C’est quoi, au juste ? (vous êtes ici)
- 2/6 : Les vecteurs, quand le sens devient géométrie
- 3/6 : L’attention
- 4/6 : Du neurone artificiel aux réseaux
- 5/6 : Le Transformer en entier
- 6/6 : De la prédiction à la conversation
- Bonus 1 : La chaîne de raisonnement
- Bonus 2 : Le mélange d’experts
- Bonus 3 : Pourquoi des petits modèles
- Bonus 4 : La distillation, ou apprendre d’un professeur
- Bonus 5 : Et demain ?
- Bonus 6 : Pourquoi les LLM sont si bons avec le code informatique ?
- Bonus 7 : La carte comme langage ?
Glossaire
- All-reduce : opération par laquelle les GPU mettent en commun leurs gradients : chacun reçoit la somme de ceux de tous les autres, pour appliquer la même mise à jour.
- Checkpoint (point de sauvegarde) : copie des paramètres prise pendant l’entraînement, pour reprendre après une panne.
- Common Crawl : archive publique de pages web, mise à jour régulièrement par une association à but non lucratif.
- Corpus : ensemble de textes rassemblés pour l’entraînement d’un modèle.
- Descente de gradient : méthode qui modifie les paramètres d’un petit pas dans le sens qui fait baisser la perte, comme une bille qui descend une pente.
- Entraînement : procédure qui répète des prédictions sur des textes et ajuste les paramètres pour réduire la perte.
- GPU (processeur graphique) : puce capable d’effectuer un très grand nombre de calculs en parallèle ; l’entraînement d’un grand modèle en mobilise des milliers.
- H100 : modèle de GPU de NVIDIA, très utilisé pour l’entraînement des grands modèles.
- InfiniBand : technologie de réseau très rapide entre serveurs.
- Logarithme : fonction mathématique (notée ln). Ici, −ln d’une probabilité sert à mesurer la perte : plus la probabilité est petite, plus la perte est grande.
- Lot (batch) : groupe de textes traités ensemble lors d’une même étape d’entraînement.
- MinHash : méthode qui calcule de courtes empreintes de textes, pour repérer les pages presque identiques.
- NVLink : liaison directe et très rapide entre les GPU d’un même serveur.
- Octet et unités : un octet vaut 8 bits. Go (gigaoctet) = 10⁹ octets ; To (téraoctet) = 10¹² ; Po (pétaoctet) = 10¹⁵. Gio (gibioctet) et TiB (tébioctet) sont les versions en base 2 (2³⁰ et 2⁴⁰ octets), un peu plus grandes. Gb/s et Go/s sont des débits : gigabits et gigaoctets par seconde.
- Octets par token : hypothèse de conversion pour estimer un volume de texte brut à partir d’un nombre de tokens. 4 octets par token est un ordre de grandeur pour le texte anglais ; il varie selon la langue et l’outil de découpage.
- Paramètre : nombre réglable à l’intérieur du modèle, ajusté pendant l’entraînement ; un LLM en compte des milliards.
- Perte : mesure de l’écart entre la probabilité donnée au token réellement présent et la certitude ; plus elle est grande, plus la prédiction était mauvaise.
- Pile (The Pile) : corpus de textes assemblé en 2020 par EleutherAI à partir de sources variées.
- Pré-entraînement : première phase d’entraînement, sur de très grands corpus, qui apprend à prédire le token suivant ; les modèles grand public subissent ensuite un réglage supplémentaire.
- Probabilité : nombre entre 0 et 1 (ou pourcentage) qui mesure la chance qu’un token suive le texte déjà écrit ; pour une même position, les probabilités de tous les tokens possibles totalisent 100 %.
- RAID : regroupement de plusieurs disques qui protège contre la panne d’un disque, au prix d’une partie de la capacité.
- Rétropropagation : calcul qui indique, pour chaque paramètre, dans quel sens le modifier pour réduire la perte.
- TDP (puissance thermique de conception) : valeur que le constructeur indique pour dimensionner le refroidissement ; ce n’est pas une mesure exacte de la consommation.
- Token : morceau de texte (mot entier, fragment de mot, espace, signe de ponctuation) auquel le modèle associe un numéro.
- Tokenizer : outil qui découpe un texte en tokens et les convertit en numéros, selon une liste fixée à l’avance.
Pour aller plus loin
- Ashish Vaswani et al., « Attention Is All You Need », 2017. arXiv : https://arxiv.org/abs/1706.03762 (en anglais, article fondateur de l’architecture Transformer).
- Grégoire Delétang et al., « Language Modeling Is Compression », 2023. arXiv : https://arxiv.org/abs/2309.10668 (en anglais).
- Nikhil Kandpal et al., « Large Language Models Struggle to Learn Long-Tail Knowledge », 2022. arXiv : https://arxiv.org/abs/2211.08411 (en anglais).
- Ted Chiang, « ChatGPT Is a Blurry JPEG of the Web », The New Yorker, 2023 (en anglais).
- Epoch AI, « How much does it cost to train frontier AI models? », 3 juin 2024. https://epoch.ai/blog/how-much-does-it-cost-to-train-frontier-ai-models (en anglais).
- Pablo Villalobos et al., « Will We Run Out of Data? », Epoch AI, 2024. https://epoch.ai/publications/will-we-run-out-of-data-limits-of-llm-scaling-based-on-human-generated-data (en anglais).
- 3Blue1Brown, série de vidéos sur les réseaux de neurones. https://www.youtube.com/@3blue1brown