Module 2 — Préentraînement : données, jetons et lois d'échelle

Le module précédent a présenté les grandeurs qui gouvernent un LLM. Celui-ci descend d'un cran : que fait-on réellement pendant le préentraînement, avec quelles données, et selon quel budget optimal ? Pour notre assistant de support, nous n'entraînerons pas nous-mêmes un modèle de fondation — le coût rend l'opération inaccessible à toute équipe qui n'y consacre pas des millions d'euros. Mais comprendre ce qui a été fait avant que le modèle nous arrive détermine ce que nous pouvons en attendre, notamment la qualité du français.

Ce que le modèle apprend, en une objectif unique

Le préentraînement d'un LLM autorégressif tient dans une seule fonction de perte : prédire le jeton suivant, sur des milliers de milliards de jetons, avec une entropie croisée. Pour une séquence de jetons $x_1, x_2, \ldots, x_T$ , la perte s'écrit

\mathcal{L} = -\sum_{t=1}^{T} \log P_\theta(x_t \mid x_1, \ldots, x_{t-1}).

Rien d'autre. Aucune étiquette humaine, aucune tâche définie. Toute la puissance apparente vient de ce que le corpus est immense, hétérogène et représente une part significative du texte écrit disponible. Le modèle n'« apprend » pas à traduire, à résumer ou à raisonner : il apprend à continuer un texte, et ces compétences émergent parce qu'elles sont nécessaires pour continuer certains textes.

Un corpus n'est pas un tas de pages web

La qualité d'un LLM se joue autant dans le filtrage du corpus que dans l'architecture. Un corpus brut issu du web est plein de spam publicitaire, de contenu généré automatiquement, de fautes systématiques et de pages presque identiques. Le pipeline typique enchaîne cinq étapes.

Extraction du texte depuis le HTML, avec suppression des menus, publicités et pieds de page.
Détection de langue par un classifieur léger (fastText), pour trier les documents.
Filtrage de qualité par un modèle qui note chaque document sur une échelle apprise depuis une petite référence.
Dédoublonnage exact puis approximatif, souvent par empreintes MinHash sur des fenêtres glissantes.
Détoxication et retrait des données personnelles identifiables.

Le dédoublonnage est le point le plus déterminant en pratique. Un article passé sur cinquante blogs qui se copient les uns les autres serait vu cinquante fois par le modèle et pèserait autant qu'une œuvre unique. En dédoublonnant, on ne réduit pas seulement la taille du corpus : on augmente sa diversité effective, ce qui vaut plus que le volume brut.

# Illustration : dédoublonnage exact sur un petit corpus
from hashlib import blake2b

def empreinte(doc: str) -> str:
    return blake2b(doc.strip().encode("utf-8"), digest_size=16).hexdigest()

def dedoublonner(docs):
    vus, resultat = set(), []
    for d in docs:
        e = empreinte(d)
        if e not in vus:
            vus.add(e)
            resultat.append(d)
    return resultat

corpus = ["texte A", "texte B", "texte A", "texte C"]
print(len(dedoublonner(corpus)))   # 3

Pour les milliers de milliards de jetons d'un vrai préentraînement, cette logique passe à l'échelle avec des empreintes MinHash et un stockage sur disque, mais l'idée est la même.

La loi de Chinchilla, ou comment allouer le budget

En 2022, une étude de DeepMind sur le modèle Chinchilla a réfuté une croyance largement répandue : ce n'était pas la taille des modèles qui devait grossir en priorité, mais leur volume de données. Pour un budget de calcul $C$ fixé, la performance est maximale quand $N$ et $D$ suivent approximativement

D \approx 20 \cdot N,

autrement dit environ vingt jetons par paramètre. Un modèle de 7 milliards de paramètres a donc besoin d'à peu près 140 milliards de jetons pour être « compensé », et les modèles récents vont bien au-delà — jusqu'à 15 000 milliards de jetons pour 8 milliards de paramètres — parce que la performance continue de progresser au-delà du strict optimum de calcul, tant que les jetons de qualité sont disponibles.

Paramètres $N$	Jetons optimaux $D$	Calcul $6 N D$	Ordre de grandeur GPU-heures A100
1 milliard	20 milliards	$1{,}2 \times 10^{20}$	≈ 5 000
7 milliards	140 milliards	$5{,}9 \times 10^{21}$	≈ 250 000
70 milliards	1 400 milliards	$5{,}9 \times 10^{23}$	≈ 25 000 000

Ces ordres de grandeur expliquent pourquoi l'entraînement d'un modèle de 70 milliards de paramètres est réservé à quelques acteurs, et pourquoi le marché s'organise autour de « poids ouverts, préentraînement fermé » : on partage le résultat parce qu'on ne peut pas partager le processus.

Le français dans les corpus, un point aveugle

Les grands corpus publics — Common Crawl, C4, RefinedWeb — sont massivement anglophones. La part de français y est de l'ordre de 3 à 5 pour cent selon les extractions, et celle des autres langues romanes du même ordre. Cette asymétrie a deux conséquences très concrètes pour un assistant destiné à un public francophone :

Le vocabulaire du tokeniseur est optimisé pour l'anglais ; un même paragraphe en français utilise souvent 30 à 50 pour cent de jetons de plus. Cela renchérit la latence et le coût par requête (module 10).
Les fautes typographiques françaises — apostrophes droites au lieu de courbes, accents oubliés — sont abondantes dans les données brutes et le modèle les reproduit.

Un modèle multilingue de conception, entraîné avec un objectif explicite d'équilibre, corrige la première asymétrie. Un affinage sur un jeu français propre (module 3) corrige la seconde. Aucune des deux corrections n'est gratuite ; elles sont l'un des arguments les plus solides pour choisir un modèle ouvert que l'on peut adapter, plutôt qu'un modèle propriétaire dont on subit les décisions de tokenisation.

Le rapport données-modèle est un piège

On lit souvent qu'« un modèle plus grand est meilleur ». La loi de Chinchilla dit exactement le contraire quand le budget est fixé : à coût de calcul égal, un modèle plus petit entraîné plus longtemps bat un modèle plus grand sous-entraîné. Un modèle de 70 milliards de paramètres vu par 200 milliards de jetons est en général moins bon qu'un modèle de 20 milliards vu par 700 milliards de jetons, malgré une taille trois fois plus faible.

Coût en calcul, en énergie, en carbone

Le coût d'un préentraînement se lit à trois niveaux. Le calcul brut, en FLOP, se convertit en GPU-heures selon le débit soutenu de l'accélérateur — de l'ordre de $3 \times 10^{14}$ FLOP par seconde pour un A100 en précision bfloat16. À 250 000 heures GPU pour un 7 milliards, cela représente plusieurs centaines de milliers d'euros de location cloud. À cela s'ajoutent l'énergie consommée (quelques centaines de MWh) et le carbone associé, très variable selon le pays d'hébergement — un même entraînement émet trois à quinze fois plus de CO₂ selon que le réseau électrique est renouvelable ou pas.

Ce troisième chiffre est de plus en plus scruté par les entreprises soumises à des exigences de reporting environnemental. Pour notre assistant, une décision d'apparence purement technique — utiliser un modèle déjà préentraîné plutôt que d'en entraîner un — évite typiquement l'équivalent de plusieurs centaines de vols long-courrier en émissions. C'est un argument à mettre en face de la tentation « mais nous aimerions notre propre modèle ».

Le bon niveau d'intervention

Pour un assistant de support, aucune équipe raisonnable n'entraîne un modèle de fondation. On part d'un modèle ouvert récent (module 1), on l'affine sur nos données (module 3), on l'aligne si nécessaire (module 4). Cette division du travail explique la forme actuelle du marché ; ne pas la respecter, c'est se ruiner en calcul pour un modèle inférieur à ce qu'on obtient gratuitement.

En résumé

Le préentraînement d'un LLM se réduit à prédire le jeton suivant sur un immense corpus ; toutes les capacités observées émergent de cette seule objectif.
Le filtrage et surtout le dédoublonnage du corpus comptent autant que l'architecture ; la diversité effective des données pèse plus que le volume brut.
La loi de Chinchilla fixe un rapport d'environ 20 jetons par paramètre à budget de calcul donné ; ignorer ce rapport gaspille l'entraînement.
Les corpus étant majoritairement anglophones, un modèle destiné au français paie une pénalité de tokenisation et de qualité que seul un affinage ciblé peut corriger.

Module suivant : comment transformer un modèle de base, qui ne fait que continuer un texte, en un modèle instruit qui suit des consignes.

Ce que le modèle apprend, en une objectif unique​

Un corpus n'est pas un tas de pages web​

La loi de Chinchilla, ou comment allouer le budget​

Le français dans les corpus, un point aveugle​

Coût en calcul, en énergie, en carbone​

En résumé​