Sunday Latte : Pourquoi l’intelligence artificielle demande autant de calcul

Une question légère, une machine lourde

Vous tapez une question de quelques mots. Quelques secondes plus tard, une réponse soignée s'affiche. Vu de votre côté de l'écran, l'échange semble ne presque rien peser : un clavier, une courte attente, un paragraphe. Pourtant, derrière cette légèreté, il y a des salles entières de processeurs spécialisés, des mémoires rapides, des réseaux taillés pour déplacer des masses de données et des installations de refroidissement dignes d'une usine. Des entreprises planifient de nouvelles alimentations électriques autour de ces machines. D'où vient une telle disproportion ?

Posons d'abord le cadre. L'intelligence artificielle ne se réduit pas aux grands modèles de langage. Un petit système qui surveille des capteurs ou filtre des messages tourne très bien sur du matériel modeste. Cet épisode s'intéresse aux grands modèles qui produisent du texte morceau par morceau, et à ce qui, dans les méthodes actuelles, les rend aussi gourmands.

Il y a en réalité deux factures à comprendre. La première se paie pendant l'entraînement : le modèle parcourt d'immenses quantités de texte et ajuste sans relâche les valeurs numériques que l'on appelle des poids. La seconde arrive à chaque utilisation : pendant l'inférence, ces poids sont appliqués à la question, puis à chaque fragment de la réponse. L'une est un investissement concentré, l'autre une dépense plus petite, mais répétée indéfiniment.

Ni l'une ni l'autre ne correspond à un acte de pensée unique. Toutes deux sont faites d'opérations élémentaires répétées à une échelle vertigineuse. Et l'arithmétique n'est qu'une partie de l'histoire : les nombres doivent circuler dans la mémoire et, quand le modèle occupe plusieurs machines, voyager de l'une à l'autre. Un processeur puissant qui attend ses données est un équipement hors de prix en train de ne rien faire.

La bonne question n'est donc pas simplement de savoir pourquoi il faut des puces rapides. C'est de comprendre pourquoi les méthodes actuelles exigent autant de répétitions, pourquoi le déplacement des données devient un embouteillage, et pourquoi rendre chaque opération moins chère ne suffit pas à faire disparaître l'appétit d'ensemble.

Quand la langue devient du calcul

Au fond, un modèle de langage est une très grande fonction numérique apprise. Le texte y entre découpé en tokens : un token peut être un mot, un morceau de mot ou un signe de ponctuation. Chacun devient un vecteur, c'est-à-dire une liste ordonnée de nombres. Ces nombres ne sortent d'aucun dictionnaire ; ce sont des coordonnées apprises, qui permettent au modèle de manipuler des relations entre les éléments du texte.

Les vecteurs traversent ensuite de nombreuses couches. Un mécanisme central s'appelle l'attention : le modèle fabrique plusieurs représentations de chaque position et les compare au reste du contexte. Un pronom peut ainsi dépendre d'un nom apparu bien plus tôt, une conclusion s'appuyer sur une prémisse lointaine. D'autres transformations retravaillent ensuite chaque position, couche après couche.

L'essentiel de ce travail prend la forme de multiplications de matrices, de grands tableaux rectangulaires de nombres que l'on multiplie et que l'on additionne. Une multiplication suivie d'une addition ne coûte presque rien. La démesure vient de la répétition : sur toute la largeur du modèle, dans toutes les couches, pour chaque token et pour chaque requête. C'est comme poser des carreaux de mosaïque. En coller un est un jeu d'enfant ; en couvrir tous les murs d'une ville est un chantier.

Cette forme de travail explique le rôle des accélérateurs. Un processeur classique est un généraliste, conçu pour des tâches variées. Un processeur graphique, ou une puce spécialement construite pour ce genre de calcul, consacre bien davantage de silicium à exécuter d'innombrables opérations numériques en parallèle, parfois dans des formats de nombres compacts quand le modèle le supporte. Ce n'est pas un ordinateur plus rapide en tout ; son avantage n'apparaît que si le travail se laisse organiser en grands blocs réguliers.

Encore faut-il l'alimenter. Le chiffre spectaculaire de la fiche technique décrit un sommet atteint dans des conditions idéales. Une cuisine peut employer des centaines de cuisiniers, ils ne serviront pas des centaines de plats si chaque ingrédient passe par un unique passe-plat étroit. Dans ces systèmes, la mémoire et les liaisons entre machines jouent souvent le rôle du passe-plat.

Apprendre à force de corrections

L'entraînement coûte cher parce que le modèle ne se contente pas de lire les textes une seule fois.

Prenons un lot d'exemples. Le modèle commence par prédire : dans le préentraînement habituel, il tente de deviner le token suivant à partir de ceux qui précèdent. Ses prédictions sont comparées au texte réel, et cette comparaison produit une mesure d'erreur, que l'on appelle la perte.

Vient ensuite l'étape dont l'usage ordinaire n'a pas besoin. La rétropropagation remonte les calculs en sens inverse et détermine comment de petites retouches de chaque poids modifieraient cette erreur. Un algorithme d'optimisation se sert de ces gradients pour ajuster les poids. Puis un nouveau lot arrive, et tout recommence : prédire, mesurer, corriger, mettre à jour, à travers un corpus gigantesque.

L'entraînement additionne donc le calcul vers l'avant qui produit une réponse, le calcul en sens inverse qui répartit la responsabilité de l'erreur, et la mise à jour elle-même. Il réclame aussi beaucoup plus de mémoire que les poids seuls. Il faut conserver, ou recalculer plus tard, quantité de résultats intermédiaires, et stocker en plus les gradients et l'état interne de l'optimiseur. Recalculer économise de la place, mais rajoute de l'arithmétique. Un modèle qui tient sur quelques machines une fois terminé peut en occuper bien davantage pendant qu'il apprend.

Pour un modèle dense classique, une première approximation utile dit que le travail d'entraînement croît à la fois avec le nombre de paramètres et avec le nombre de tokens vus. Doublez le modèle à données constantes, et chaque token devient plus coûteux. Gardez le modèle et doublez la matière, et l'entraînement s'allonge d'autant. L'approximation néglige bien des choses, du tri des données aux essais infructueux, mais elle explique pourquoi un entraînement moderne se planifie comme un budget plutôt que comme une recette.

Une précision, enfin. Les poids ne rangent pas des phrases dans des tiroirs ; ils capturent des régularités statistiques. Le modèle ne feuillette pas ses données d'entraînement à chaque réponse. C'est ce qui lui permet de formuler du neuf, et c'est aussi ce qui lui permet d'affirmer avec aplomb quelque chose de faux. Le calcul rend cet apprentissage possible ; il ne choisit ni les bonnes données ni le bon objectif.

Grandir en équilibre

L'augmentation du calcul a produit de vrais progrès, mais seulement quand elle était dépensée avec discernement.

Des chercheurs ont observé que l'erreur moyenne des modèles de langage suivait des courbes étonnamment régulières. À mesure que grandissaient la taille du modèle, la quantité de données et le calcul d'entraînement, la perte diminuait de façon prévisible, du moins dans les plages étudiées. On parle de lois d'échelle. Le mot loi promet trop : il s'agit de régularités mesurées sur certaines familles de modèles, pas de garanties physiques. Rien n'assure que chaque capacité utile progresse au même rythme que la moyenne.

Ces études ont aussi révélé du gaspillage. Imaginez consacrer presque tout le budget à un modèle géant, puis arrêter l'entraînement avant qu'il ait vu assez de texte pour exploiter sa capacité. Un modèle plus petit, nourri de plus de données, peut faire mieux pour le même prix.

La comparaison entre deux modèles de recherche l'a rendu concret. Le modèle Chinchilla comptait environ soixante-dix milliards de paramètres, quand un modèle antérieur en comptait environ deux cent quatre-vingts milliards. Avec un budget d'entraînement comparable, Chinchilla a vu à peu près quatre fois plus de données, et il a obtenu de meilleurs résultats sur les évaluations publiées. La morale n'est pas qu'il existe une taille magique valable pour toujours. C'est que le nombre de paramètres, à lui seul, mesure très mal la façon dont un budget a été employé.

La qualité des données complique encore le dosage. Un océan de textes répétés, trompeurs ou mal choisis ne vaut pas la même quantité de matière variée et pertinente. L'architecture et l'usage prévu comptent aussi. Un modèle plus compact destiné à répondre des milliards de fois peut mériter un entraînement plus long, si chaque réponse ultérieure devient moins chère.

Et l'échelle obéit à des rendements décroissants. Une loi de puissance peut décrire un progrès continu tout en disant que chaque nouvelle amélioration exige de multiplier les ressources. Une baisse régulière de l'erreur moyenne ne garantit pas non plus un progrès régulier sur chaque savoir-faire utile. Les lois d'échelle sont des cartes de territoires déjà mesurés, pas la promesse qu'assez de machines viendront à bout de mauvaises données, d'un objectif mal choisi ou d'une limite qu'aucune expérience n'a encore atteinte.

L'embouteillage invisible

À un moment, le modèle ne tient plus sur un seul accélérateur.

Comptons seulement les poids stockés. Soixante-dix milliards de valeurs, conservées sur deux octets chacune, occupent déjà environ cent quarante gigaoctets. L'entraînement exige beaucoup plus d'espace encore, pour les gradients, l'état de l'optimiseur et les résultats intermédiaires. Un grand entraînement doit donc répartir le travail sur de nombreuses machines.

Il existe plusieurs découpages. Des appareils différents peuvent traiter des lots différents. Ils peuvent héberger des couches différentes, ou se partager les tranches d'une même matrice géante. Les modèles dits creux peuvent orienter chaque token vers un groupe de paramètres spécialisés, que l'on appelle des experts. Chaque découpage résout un problème de mémoire ou de calcul, et crée en échange de la communication. Les appareils s'échangent des gradients, des activations ou des tokens, et s'attendent mutuellement à des points de synchronisation. Ajouter des puces augmente le calcul théorique tout en rendant la coordination plus délicate ; un appareil qui patiente devant un voisin plus lent, c'est de la performance promise qui s'évapore.

Le même dénivelé existe à l'intérieur d'une seule puce. Tout près des unités de calcul se trouve une mémoire minuscule et fulgurante. Plus loin, une mémoire à haut débit bien plus vaste, mais plus lente. La capacité décide si les données tiennent ; la bande passante décide à quelle vitesse elles arrivent. Ce sont deux goulets différents, souvent confondus sous le seul mot mémoire.

Une réorganisation moderne du calcul d'attention illustre l'enjeu mieux que n'importe quelle plaquette commerciale. Elle réordonne le même calcul exact pour lire et écrire moins souvent dans la grande mémoire, quitte à recalculer délibérément certains résultats intermédiaires au lieu de les conserver. Davantage d'opérations, moins de trafic, et le tout se termine plus tôt, avec une empreinte mémoire réduite. Compter les opérations ne suffit donc pas à prédire la vitesse. Parfois, le chemin le plus rapide n'est pas celui qui calcule le moins : c'est celui qui circule le moins.

Après la touche Entrée

L'entraînement s'achève sur un jeu de poids. Les utiliser, c'est l'inférence, et elle a son propre rythme.

Le système commence par digérer la question et le contexte déjà accumulé. Dans cette phase de lecture, de nombreux tokens peuvent être traités en parallèle : un long contexte représente un gros bloc de travail, mais un bloc qui occupe bien l'accélérateur.

Puis la génération démarre. Le modèle produit un token, l'ajoute à la séquence, et s'appuie sur la séquence allongée pour produire le suivant. Chaque nouveau pas dépend du précédent : impossible de connaître le dixième mot avant d'avoir choisi ceux qui le précèdent. Cette dépendance rend la sortie en partie sérielle, quelle que soit la puissance disponible.

Pour ne pas tout recalculer à chaque pas, le système conserve certains résultats intermédiaires de l'attention, souvent décrits comme des clés et des valeurs. Ce cache est l'état de travail de la conversation en cours ; ce n'est ni le savoir appris du modèle ni une mémoire permanente. Il grossit avec la longueur du contexte. Multipliez cette croissance par des milliers d'utilisateurs simultanés, et une mémoire qui semblait généreuse se remplit vite. L'espace libre peut même se fragmenter en morceaux inutilisables, et le répartir finement devient un métier en soi.

Les services regroupent donc les requêtes pour occuper les accélérateurs. Un lot plus grand améliore le débit, puisque les poids servent à plusieurs demandes à la fois. Mais débit et latence sont deux promesses différentes. Attendre de constituer un lot commode arrange l'exploitant et agace la personne qui fixe un écran vide.

Il existe des astuces pour desserrer le goulet sériel. Dans le décodage spéculatif, un petit modèle propose plusieurs tokens plausibles que le grand modèle vérifie d'un coup. Quand la proposition tient, plusieurs positions avancent ensemble sans changer la réponse que le grand modèle aurait donnée.

Ces techniques réduisent le coût d'une tâche donnée. Elles n'effacent pas la seconde facture. Chaque question, chaque token lu, chaque token produit, chaque nouvel essai réclame du travail. Une réponse isolée peut rester bon marché pendant qu'un service utilisé sans relâche par des millions de personnes devient une énorme machine d'inférence. Le coût concentré de l'entraînement et le coût récurrent de l'usage ne se comparent que sur la durée : selon le trafic, la taille du modèle, la longueur des réponses et le temps passé en service, l'un ou l'autre peut l'emporter. Décréter un vainqueur universel serait trompeur.

Prendre le temps de réfléchir

Le calcul d'une réponse ne dépend plus seulement de la taille de la question et du texte visible. Certains systèmes peuvent consacrer davantage de travail à un problème difficile avant de répondre.

Les moyens sont variés. Le modèle peut dérouler un cheminement interne plus long, revenir sur une étape douteuse, ou produire plusieurs solutions candidates. Un autre composant, une sorte de vérificateur, peut comparer ces candidates et en choisir une. Toutes ces stratégies dépensent du calcul au moment de l'usage, plutôt que de tout miser sur un entraînement plus lourd.

L'échange peut être avantageux. Des expériences ont montré qu'un budget de réflexion bien réparti permettait parfois à un modèle plus petit de dépasser un modèle bien plus grand sur certains problèmes. Mais bien réparti est l'expression décisive. La stratégie utile dépend de la difficulté. Une question facile ne gagne rien à des dizaines de tentatives. Une question hors de portée produira des dizaines de variantes de la même erreur. Entre les deux, une révision ou une sélection soignée peut tout changer.

Et il ne faut pas confondre longueur et raisonnement. Le texte supplémentaire est un coût, qui peut transporter du travail utile, de la répétition ou de la confusion. Un vérificateur n'aide que s'il sait réellement distinguer une solution solide d'une solution qui a seulement l'air convaincante. Il faut une méthode pour décider quand continuer, quand explorer d'autres pistes et quand s'arrêter. Là aussi, les premiers contrôles rapportent souvent plus que les vingtièmes.

Cela change l'économie d'une réponse. Deux demandes aux réponses visibles également brèves peuvent avoir mobilisé des quantités de calcul très différentes. Et cela fait du calcul une décision de produit : rapide et suffisant pour une demande de routine ; lent et appliqué quand le problème est ardu et que l'enjeu justifie l'attente.

Puissance, énergie et prix

Les débats sur l'intelligence artificielle glissent volontiers de la puissance à l'énergie, aux émissions et à l'argent comme s'il s'agissait de synonymes. Ce n'en sont pas.

La puissance est un rythme instantané. L'énergie est ce rythme accumulé dans le temps. Un accélérateur récent peut tirer plus de puissance en pleine activité et pourtant consommer moins d'énergie pour une tâche, s'il la termine bien plus tôt. Un appareil modeste mais lent peut dépenser davantage en travaillant longtemps.

Les émissions ajoutent une couche. La même électricité n'a pas le même impact selon le lieu, l'heure et la manière dont elle est produite, et la fabrication du matériel pèse aussi. Le prix est encore autre chose. Une facture d'informatique en nuage couvre les puces, la mémoire, le réseau, les bâtiments, le refroidissement, le personnel, le financement, la capacité de réserve et la marge du fournisseur. Ce n'est pas un compteur électrique.

Même un chiffre baptisé énergie par question dépend du périmètre retenu. Un grand fournisseur a mesuré la requête textuelle médiane de son service en conditions réelles, en comptant les accélérateurs actifs, les processeurs hôtes et leur mémoire, les machines maintenues en attente pour la fiabilité et les frais généraux du centre de données. Son résultat dépassait le double de l'estimation qu'un périmètre plus étroit donnait dans la même étude. Aucun des deux chiffres n'était malhonnête : ils répondaient à des questions comptables différentes. Et ils valaient pour un fournisseur, un produit, une répartition de requêtes, une période et une méthode, pas pour toute l'intelligence artificielle.

La nature de la demande compte tout autant. Une courte classification, l'analyse d'un long document et un problème de raisonnement n'ont pas d'empreinte commune. Il faut aussi séparer l'échelle individuelle de l'échelle collective. Une requête brève pèse peu, mais des millions de requêtes concentrées dans une même région peuvent peser lourd sur un réseau électrique local, même quand la part mondiale paraît sage. À l'inverse, diviser la consommation de tous les centres de données par un nombre supposé de questions n'a aucun sens : ces centres font bien d'autres choses, et les usages diffèrent énormément.

Enfin, l'entraînement et l'inférence méritent des colonnes séparées. Un modèle expérimental rarement sollicité aura surtout payé son apprentissage. Un modèle très utilisé accumulera une facture de service bien supérieure. Sans connaître le modèle, son trafic, la longueur de ses réponses et sa durée de vie, il n'y a pas de vainqueur universel.

Assez de calcul, bien employé

L'efficacité peut progresser à presque chaque étage de cette histoire.

De meilleures données atteignent une cible avec moins d'entraînement. Des modèles plus petits suffisent aux tâches simples, et la distillation permet à un modèle compact d'apprendre une partie du comportement d'un plus grand. La quantification stocke et manipule certaines valeurs sur moins de bits, ce qui réduit le trafic en mémoire quand le matériel s'y prête et que la qualité reste acceptable. Les architectures à experts n'activent qu'une partie d'un grand modèle pour chaque token. De meilleurs algorithmes limitent les allers-retours en mémoire, la gestion des caches et le regroupement des requêtes tirent davantage du matériel de service, le décodage spéculatif accélère la génération, et les nouvelles puces fournissent plus de travail utile par unité d'énergie.

Aucun de ces gains n'est imaginaire. Aucun n'est illimité. Une précision trop réduite peut abîmer un modèle. Les experts inactifs doivent quand même être stockés, et il faut acheminer chaque token vers le bon. Les grands lots peuvent allonger l'attente individuelle. Et une optimisation qui supprime un goulet en révèle souvent un autre.

Surtout, l'efficacité d'une tâche fixe ne dicte pas la demande totale. Si une réponse devient dix fois moins chère, davantage de gens utiliseront le service. Les applications enverront des contextes plus longs, produiront plusieurs candidats, s'attaqueront à des travaux jusque-là trop coûteux. Une équipe de recherche réinvestira le calcul économisé dans une expérience plus ambitieuse. Le prix de la tasse peut baisser pendant que le café en sert beaucoup plus.

C'est pourquoi les deux récits extrêmes échouent. Il est faux de dire que l'efficacité règle d'elle-même la question des ressources. Il est tout aussi faux de traiter un grand calcul comme un gaspillage du seul fait de sa taille. La vraie question est ce que le calcul accomplit, quelles alternatives existent, et si l'amélioration vaut les ressources supplémentaires.

Revenons à la petite question du début. La réponse semblait sans effort parce que la machinerie restait cachée : des poids façonnés par d'innombrables corrections, des matrices appliquées couche après couche, des nombres en transit dans les mémoires et les réseaux, et un service décidant combien de travail cette demande méritait.

Le calcul est l'un des ingrédients essentiels de l'intelligence artificielle actuelle. Il ne remplace ni de bonnes données, ni un objectif sain, ni une évaluation fiable, ni le jugement. Le but n'est pas d'en dépenser le plus possible. C'est d'avoir assez de calcul, bien employé, pour obtenir une réponse qui en vaille la peine.