Construire un LLM : le cours de Stanford qui démonte les illusions

Les cinq briques, et les trois qui comptent

Yann Dubois ouvre sur une liste : architecture, loss et algorithme d'entraînement, données, évaluation, systèmes. Puis il annonce qu'il ne parlera pas de l'architecture. D'abord parce que la littérature sur les Transformers est pléthorique, ensuite parce que ce n'est pas là que se joue la partie.

Son constat est frontal et vaut confession personnelle : le monde académique — dont il fait partie — se concentre sur les architectures et les fonctions de perte parce que c'est intellectuellement plaisant. L'industrie, elle, se concentre sur les données, l'évaluation et les systèmes. Et c'est l'industrie qui a raison.

Ce cadrage revient plus tard sous la forme de la « bitter lesson » de Richard Sutton : si la compute augmente mécaniquement et si les scaling laws tiennent, seule compte la capacité d'une architecture à absorber du calcul. Les petites variations d'activation ne déplacent que l'intercept de la courbe — autant attendre la génération de GPU suivante.

Pré-entraînement : le tokenizer, ce mal-aimé

Le rappel théorique est rapide : un modèle de langage est une distribution de probabilité sur des séquences de tokens, décomposée par la règle des probabilités en chaîne. L'entraînement se réduit à une classification du token suivant avec une cross-entropy, équivalente à maximiser la log-vraisemblance du texte.

Le vrai sujet, c'est le tokenizer. Les mots ne résistent ni aux fautes de frappe ni au thaï ; les caractères produisent des séquences trop longues pour une complexité quadratique. Le byte-pair encoding fusionne itérativement les paires les plus fréquentes, pour aboutir à des tokens de trois à quatre lettres en moyenne.

Dubois insiste sur les conséquences concrètes. Les nombres mal tokenisés — « 327 » comme token unique — empêchent le modèle de raisonner par composition en arithmétique. GPT-4 a changé sa tokenisation du code, notamment pour les quatre espaces d'indentation Python, qui étaient traités bizarrement. Beaucoup de chercheurs aimeraient s'en débarrasser, mais il faudrait d'abord des architectures qui ne scalent pas quadratiquement avec la longueur.

Les données : « tout internet » n'existe pas

Common Crawl agrège aujourd'hui environ 250 milliards de pages, soit un pétaoctet. Dubois affiche une page au hasard : du HTML, une phrase tronquée sur des serveurs « high performance », rien qui ressemble à Wikipédia. « Internet propre » est une formule creuse.

Le pipeline réel enchaîne extraction du texte depuis le HTML (les maths sont un cauchemar), filtrage des contenus indésirables via des listes noires interminables, déduplication à l'échelle, filtrage heuristique, puis filtrage par modèle. L'astuce élégante : entraîner un classifieur à reconnaître les pages citées en référence par Wikipédia, et sur-pondérer ce qui leur ressemble.

Vient ensuite la pondération par domaine — plus de code car cela semble aider le raisonnement, plus de livres, moins de divertissement — puis un overfitting final sur des données de très haute qualité pendant la décroissance du learning rate.

Les ordres de grandeur : de 150 milliards de tokens il y a quelques années à 15 000 milliards pour Llama 3. Sur une équipe Llama d'environ 70 personnes, Dubois estime qu'une quinzaine travaille sur les données. Le secret industriel s'explique autant par la concurrence que par le risque juridique : personne ne veut admettre avoir entraîné sur des livres.

Scaling laws et facture : 75 millions de dollars

Les scaling laws inversent la méthode. L'ancien pipeline consistait à entraîner trente modèles un jour chacun et à garder le meilleur — donc à mettre en production un modèle entraîné un seul jour. Le nouveau : trouver une recette de scaling, tuner les hyperparamètres sur de petits modèles pendant trois jours, extrapoler, puis entraîner le modèle final vingt-sept jours.

Chinchilla a formalisé l'allocation optimale : 20 tokens par paramètre pour minimiser la loss à compute constant. Mais les entreprises doivent aussi payer l'inférence, ce qui pousse vers des modèles plus petits entraînés plus longtemps — environ 150 tokens par paramètre pour les modèles réellement déployés.

Le calcul de coin de table sur Llama 3 400B est le moment le plus concret du cours. 15,6 trillions de tokens, 3,8e25 FLOPs — soit deux fois moins que le seuil de 1e26 de l'executive order Biden, ce qui n'est probablement pas un hasard. 16 000 H100, environ 70 jours, 26 millions d'heures GPU (Meta annonce 30 millions), ~52 M$ de location, ~25 M$ de salaires, total autour de 75 M$.

Sur le climat, Dubois relativise : environ 4 000 tonnes de CO2 équivalent, soit 2 000 allers-retours JFK–Londres. Énorme dans l'absolu, marginal à l'échelle du secteur — jusqu'à GPT-6 ou GPT-7, où un facteur 100 changerait la donne. Et aucun signe empirique de plateau dans les courbes, à ce jour.

Post-training : de la complétion à l'assistant

GPT-3 à qui l'on demande « explique l'alunissage à un enfant de six ans » répond « explique la théorie de la gravité à un enfant de six ans » : sur internet, les questions se suivent, les réponses viennent rarement. Le post-training sert à corriger ce comportement.

Le supervised fine-tuning applique la même loss que le pré-entraînement, sur des réponses écrites par des humains. Surprise contre-intuitive : passer de 2 000 à 32 000 exemples n'apporte presque rien. Le modèle n'apprend rien de nouveau, il apprend à privilégier un type d'utilisateur déjà modélisé. Dubois rappelle Alpaca : 175 paires humaines, 52 000 paires générées par text-davinci-003, un fine-tuning de LLaMA 7B.

Le RLHF corrige trois défauts du SFT : le plafond des capacités humaines de rédaction, le coût, et surtout l'hallucination — si l'humain cite une référence que le modèle n'a jamais vue, on lui apprend littéralement à inventer des références plausibles. On passe donc du clonage de comportement à la maximisation de préférence.

PPO exige un reward model puis de la RL, avec son cortège de clipping et de rollouts mal documentés. DPO, proposé à Stanford, réduit tout cela à du maximum likelihood : maximiser la réponse préférée, minimiser l'autre, avec des garanties d'équivalence des optima globaux. Performances comparables, et c'est aujourd'hui le standard open source.

Évaluer l'ouvert, et faire tourner la machine

Après alignement, la perplexité ne veut plus rien dire : le modèle n'est plus une distribution mais une politique optimisée pour produire une sortie. Reste Chatbot Arena, où des utilisateurs anonymes comparent deux modèles à l'aveugle — fiable, mais lent, coûteux et biaisé vers des questions techniques.

AlpacaEval remplace l'humain par GPT-4 comme juge : 98 % de corrélation avec Chatbot Arena, moins de trois minutes et moins de 10 dollars par évaluation. Le biais de longueur reste le point noir : le même GPT-4 passe de 50 % à 64,4 % de win rate si on lui demande d'être verbeux, et tombe à 20 % si on lui demande d'être concis. D'où un contrôle statistique de la longueur.

Sur les données humaines, les chiffres font mal : environ 300 $ pour 1 000 comparaisons, et seulement 66 % d'accord entre annotateurs sur une tâche binaire — y compris entre les cinq auteurs du papier, après trois heures de discussion sur les critères. Les LLM juges sont 50 fois moins chers et plus proches du mode humain, parce qu'ils ont moins de variance.

La partie systèmes, expédiée en cinq minutes, retient deux idées. La précision mixte : poids stockés en 32 bits, calculs en 16 bits, parce qu'en deep learning la décimale n'a aucune importance. Et l'operator fusion : chaque ligne PyTorch fait un aller-retour vers la mémoire globale du GPU, d'où l'intérêt de `torch.compile`, qui réécrit le code et double environ la vitesse. Même Meta ne dépasserait pas 45 % d'utilisation théorique des FLOPs.