Chapitre 1 — La mécanique de la génération de tokens

Premier billet de la tournée chapitre par chapitre de LLM Primer VI : Mettre à l'échelle les systèmes IA. Le chapitre qui affirme que presque toute question difficile dans le service LLM descend d'un seul fait — la boucle qui produit chaque token est limitée par la bande passante mémoire, et le calcul coûteux que vous avez payé reste inactif 99,7 pour cent du temps.

Pourquoi ce chapitre existe

Un LLM est, en opération, un prédicteur du prochain token enveloppé dans une boucle. Des tokens entrent, une distribution de probabilité sur le prochain token sort, un est choisi, ajouté à la séquence, et la boucle recommence. Toute propriété intéressante d'une pile d'inférence — batching, quantification, cache KV, décodage spéculatif, service désagrégé — descend d'un regard rapproché à l'intérieur de cette boucle. La boucle cache deux charges qui partagent le même chemin de code mais sollicitent le matériel de façons opposées. L'une est limitée par le calcul. L'autre est limitée par la bande passante. Sur le même H100. Dans la même passe avant. Nommer précisément cette scission est le premier mouvement du livre, et c'est le cadre auquel chaque chapitre suivant revient.

1.1 La boucle autoregressive est séquentielle par contrainte

Le token t+1 est fonction de chaque token jusqu'à t inclus. Le modèle ne peut pas prédire t+2 tant que t+1 n'a pas été échantillonné, car la prédiction de t+2 exige que t+1 soit intégré à l'entrée. Il n'existe aucun kernel astucieux qui paralléliserait la génération de deux tokens consécutifs pour une même séquence ; le caractère séquentiel est imposé par la structure de dépendance du calcul. Le coût en temps d'horloge d'une complétion à N tokens est donc N fois le coût d'une étape plus un surcoût fixe. Chaque optimisation qui suit dans le livre — batches plus larges, spéculation en avant de la trajectoire, arithmétique moins chère par étape — est une réponse partielle à la question « puisque la boucle doit avancer un token à la fois, comment rendre chaque étape plus rapide ou chaque batch plus large ? » Le modèle n'a pas non plus de calepin externe : il pense en émettant des tokens. La boucle est le seul mécanisme par lequel le modèle s'accorde du temps de réflexion, ce qui explique que la chaîne de pensée et le décodage spéculatif vivent tous les deux dans la même comptabilité.

1.2 Préremplissage et décodage sollicitent la puce de façons opposées

La boucle cache deux phases. Le préremplissage est la première passe avant, qui consomme le prompt de l'utilisateur à la forme [batch, longueur_séquence, dim_cachée]. Chaque produit matriciel opère sur toutes les positions de séquence à la fois ; l'arithmétique croît avec la longueur de séquence ; les poids sont lus depuis la HBM une fois et appliqués à de nombreuses lignes de travail. L'intensité arithmétique est élevée. Le préremplissage est limité par le calcul et exploite les 989 BF16 TFLOP/s du H100. Le décodage est chaque passe avant suivante. La forme d'entrée se réduit à [batch, 1, dim_cachée]. Les poids de chaque couche doivent encore être diffusés depuis la HBM, mais une seule ligne d'arithmétique est effectuée contre eux. L'intensité arithmétique s'effondre de trois ordres de grandeur. Le décodage est limité par la bande passante mémoire. Sur un modèle 70B en BF16, le préremplissage d'un prompt de 2 000 tokens tourne près du plafond de calcul de la puce ; la toute prochaine passe avant — le premier pas de décodage — tourne contre les mêmes 140 Go de poids pour produire un seul token. La puce n'a pas changé. La charge, oui.

1.3 Un utilisateur seul laisse le H100 inactif à 99,7 pour cent

La conséquence est que la génération temps réel pour un utilisateur seul est le pire cas pour un accélérateur de pointe. Un modèle 70B en BF16 sur un H100 SXM décode à environ 24 tokens par seconde — une vitesse de lecture confortable pour l'utilisateur — et la bande passante HBM3 de 3,35 To/s de la puce est entièrement saturée en déplaçant 140 Go de poids par token. Mais à ce rythme, les unités de calcul n'effectuent qu'environ 3,36 TFLOP/s sur les 989 dont elles sont capables. L'utilisation du calcul est de 0,34 pour cent. La puce physique n'est pas mal configurée ; chaque SM lit et multiplie à pleine vitesse, mais les tensor cores sont conçus pour consommer des tuiles de nombreuses lignes contre chaque tuile de poids, et une passe avant à un seul token ne leur donne qu'une ligne. La capacité de calcul est libellée dans une unité (opérations par octet chargé) que la charge ne produit pas. Quelqu'un paye tout de même quatre à huit dollars de l'heure pour la puce entière. L'économie du service LLM est donc l'économie de trouver du travail pour le calcul garé — via le batching, via une bande passante par token moins chère, via la spéculation, via un matériel dont le point d'équilibre correspond à la charge.

Ce que prépare le Chapitre 1

Le reste du livre est la réponse à l'asymétrie nommée ici. Le Chapitre 2 démonte le cache KV — la structure qui permet au décodage d'éviter le recalcul quadratique et qui, au passage, devient le plus gros consommateur unique de VRAM dans un cluster de service. Les Chapitres 3 et 4 parcourent le substrat matériel avec le prisme bande passante contre calcul. Les Chapitres 5 et 6 rétrécissent la charge de bande passante par token en rétrécissant les poids. Le Chapitre 7 traite du batching comme du levier système qui convertit le gâchis lié à la bande passante en débit. Les Chapitres 8 et 9 changent la forme du travail avec la gestion paginée du KV et le décodage spéculatif. Chaque mouvement se lit comme une tentative de remplir le calcul inactif que ce chapitre vient de mesurer.

Prochaine étape — Chapitre 2 : Le défi du cache KV. L'espace de travail qui rend le décodage abordable, et la formule de mémoire qui explique pourquoi les clusters de service manquent de VRAM avant de manquer de calcul.