Inférence de LLM du début à la fin : préremplissage, décodification, cache KV et échantillonnage

De la frappe au token diffusé

Ce guide décrit l’ensemble du processus d’inférence — tokenisation, embeddings, mécanisme d’attention, cache KV, échantillonnage, décodage spéculatif — et répond aux questions difficiles à chaque étape. L’objectif est de disposer d’un modèle mental prêt à être expliqué, et non d’une présentation commerciale.

Partie 1 — Deux charges de travail, pas une seule

Q1. Que se passe-t-il entre la touche Entrée et le premier mot ?

Un suivi honnête de bout en bout :

1. Entrée. Une chaîne UTF-8 telle que "Qu’est-ce que la gravité ?" arrive. La pile de traitement l’enveloppe généralement dans un modèle de chat contenant des tokens spéciaux pour les interventions du système, de l’utilisateur et de l’assistant.
2. Tokenisation. Le texte est divisé en fragments de sous-mots et mappé sur des identifiants entiers. Cette étape consiste uniquement en un traitement de chaînes — pas encore d’ réseau neuronal.

Recherche d’incorporation. Chaque ID sélectionne une ligne de la matrice d’incorporation E ∈ ℝ^(V × d_model), ce qui produit un tenseur de taille (seq_len, d_model). Le signal positionnel est ajouté ici ou plus tard au sein de la mécanisme d’attention (RoPE).

Prefill. Chaque token de prompt passe par l’ensemble des N couches du transformateur en même temps. Chaque couche stocke ses projections K et V dans le KV cache. Cette phase est limitée par les calculs.

Tête LM. Seul l’état caché de la position finale est projeté vers la taille du vocabulaire (~128K logits).

Échantillonnage. La fonction softmax transforme les logits en une distribution ; une politique (gourmande, top-k, top-p, température, …) choisit un ID.

Boucle de décodage.Cet ID est ajouté, intégré et transmis à nouveau via la pile avec le cache KV — un nouveau token à chaque étape — jusqu’à ce qu’une règle d’arrêt soit déclenchée.

Détokenisation et flux continu.Les IDs deviennent des fragments de texte ; le serveur peut envoyer des chaînes partielles au client dès qu’elles sont valides.

Le temps nécessaire pour obtenir le premier token correspond presque toujours à l’étape de préremplissage. Tout ce qui suit relève du décodage.

Q2. Pourquoi qualifier l’inférence de deux types de tâches différents ?

Le préremplissage et le décodage se situent aux extrémités opposées du modèle roofline.

Goulot d’étranglement FLOPs / calcul Bande passante mémoire Intensité arithmétique Élevée ~1–2 FLOPs/byte pour le lot 1 Au niveau des tokens Pleine parallélisation Critère de latence TTFT TPOT / ITL Scale avec Longueur du prompt Longueur de la sortie MFU (lot 1) Souvent 40–60% Souvent 1–5%

Au niveau du préremplissage, on charge les poids une seule fois et on les applique à des milliers de vecteurs de tokens. Lors du décodage, on charge à nouveau les mêmes poids pour un seul vecteur — des gigaoctets sont déplacés pour des millions de FLOPs. La GPU attend que l’HBM soit prêt.

Presque tous les trucs de traitement — agrégation des données, cache KV, quantification, décodage spéculatif, FlashDecoding, préremplissage/décodage décentralisé — existent pour alimenter cette unité de calcul assoiffée.

Q3. Quelles métriques de latence sont importantes, et quels paramètres les influencent ?

• TTFT — principalement lié au préremplissage ; augmente avec la longueur du prompt (et pire encore lorsque l’attention devient dominante). Amélioré par un cache de préfixes, un préremplissage en blocs, une attention plus rapide et des prompts plus courts.
• TPOT / ITL — principalement lié au décodage ; correspond approximativement à bytes_per_step / bande passante. Amélioré par la quantification, GQA/MQA, le décodage spéculatif et des modèles plus petits.
• De bout en bout ≈ TTFT + TPOT × nombre de tokens de sortie.
• Rendement (tokens/sec/GPU) — une métrique liée à l’ensemble du système ; de plus grands lots l’améliorent, mais nuisent généralement au TPOT par utilisateur.

Le débit et la latence s’opposent mutuellement. La politique de service consiste à choisir un point sur cette courbe.

Q4. Pourquoi la décodage ne peut-il pas être parallélisé comme le préremplissage ?

La génération est autoregressive : chaque nouveau token dépend de tous les précédents. Le préremplissage connaît déjà l’intégralité du prompt, ce qui permet de calculer les positions ensemble sous un masque causal. Dans le décodage, le « futur » n’existe pas encore.

La décodage spéculatif constitue une solution de contournement : on élabore d’abord des hypothèses peu coûteuses, puis on les vérifie en une passe cible parallèle — transformant ainsi une dépendance séquentielle en vérification parallèle (Partie 8).

Partie 2 — Étapes un et deux : insertion du texte

Q5. Définir un token — et pourquoi les mots entiers ou les caractères bruts représentent des extrêmes inappropriés

Un token est un atome sous-motique appartenant à un vocabulaire fixe. Les extrêmes purs échouent :

• Les vocabulaires de mots sont illimités ; les fautes d’orthographe et les noms rares deviennent <UNK>, ce qui détruit les informations tout en gonflant la taille de la table d’incorporation.
• Les vocabulaires de caractères évitent les éléments hors vocabulaire mais allongent les séquences de 4 à 5 fois, ce qui pénalise le mécanisme d’attention quadratique et oblige les couches initiales à redécouvrir la morphologie.

Les sous-mots trouvent un équilibre : les mots courants restent intacts ; les formes rares se divisent en fragments significatifs ; rien n’est véritablement hors vocabulaire.

Q6. Comment le BPE est-il entraîné ?

L’encodage par paires de bytes part des caractères (ou bytes) et fusionne répétitivement la paire adjacente la plus fréquente jusqu’à atteindre la taille cible du vocabulaire. Ces fusions sont stockées sous forme de liste classée. Lors de l’inférence, les mêmes fusions sont appliquées de manière opportuniste de gauche à droite. L’entraînement repose sur des statistiques basées sur les fréquences, et non sur la descente de gradient — mais la segmentation ainsi obtenue influence tout le processus ultérieur.

Q7. BPE vs WordPiece vs Unigram / SentencePiece

• BPE — fusion par fréquence ; la décodage est déterministe grâce au tableau de fusion.
• WordPiece (époque BERT) — fusions similaires mais évaluées en fonction de la probabilité ; utilise souvent des marqueurs de continuation ##.
• Unigram / SentencePiece — part d’un grand ensemble de candidats et effectue des élagages à l’aide d’un LM unigrammatique ; peut générer des segmentations aléatoires et gère proprement les octets bruts/Unicode sans avoir besoin de pré-tokeniseurs spécifiques à une langue.

Les modèles LLM utilisés en production aujourd’hui penchent vers des variantes BPE ou SentencePiece au niveau des octets.

Q8. Pourquoi BPE au niveau des octets ?

Travailler avec des octets bruts garantit que chaque chaîne peut être encodée — pas de problèmes mystérieux liés à Unicode. Le vocabulaire apprend néanmoins des séquences multi-octets courantes, ce qui permet de conserver l’efficacité pour l’anglais, tandis que les écritures rares passent progressivement à des solutions de secours basées sur des octets.

Q9. Pourquoi les modèles ont-ils du mal à compter les lettres dans « strawberry » ?

Parce que le modèle ne voit jamais les caractères ; il voit des ID de tokens. Si « strawberry » est composé d’un ou deux éléments, l’instruction « compte les r » demande une structure qui a déjà été éliminée avant la première couche. Les tâches au niveau des caractères nécessitent soit un tokeniseur qui conserve les caractères, soit un outil externe.

Q10. Les ID de tokens ont-ils un sens à eux seuls ?

Non. Un ID n’est qu’un index vers le tableau d’embeddings de ce modèle. L’ID 100 dans un tokeniseur n’a aucun rapport avec l’ID 100 dans un autre. Ne mélangez jamais des tokeniseurs provenant de modèles différents.

Q11. Pièges liés aux tokeniseurs en environnement de production

• Les modèles de chat et les tokens spéciaux doivent correspondre à ceux utilisés pendant l’entraînement.
• Les espaces en tête de chaîne deviennent souvent des tokens à part entière — " Hello" ≠ "Hello".

La troncature peut supprimer silencieusement des instructions système si l’on compte les caractères plutôt que les tokens.

Les solutions de secours multilingues basées sur des octets augmentent la longueur et les coûts.

Les tokens spéciaux multimodaux pour images/sons modifient les règles de compression.

Q12. Équilibres entre taille du vocabulaire

Un V plus grand raccourcit les séquences et améliore la couverture multilingue, mais augmente les paramètres d’embedding ainsi que ceux de LM-head (V × d_model pour chacun) et le coût de décodage par softmax. Les valeurs typiques actuelles se situent entre 32K et 150K ; au-delà, on paie plus en mémoire et en bande passante pour des gains de moins en moins significatifs.

Q6. Comment le BPE est réellement entraîné

L’encodage par paires d’octets est une méthode de compression réutilisée pour l’apprentissage du vocabulaire :

1. On initialise le vocabulaire avec des symboles de base (pour un BPE au niveau octet : les 256 octets possibles).
2. On exprime le corpus sous forme de séquences de ces symboles.
3. On compte les paires adjacentes ; on choisit celles qui apparaissent le plus souvent.

Fusionnez cette paire en un nouveau symbole, ajoutez-le au vocabulaire et enregistrez la règle de fusion classée.

Repetez jusqu’à atteindre la taille cible (par exemple ~100K–128K dans les architectures modernes).

Artéfacts : une carte symbole→ID et une liste de fusion ordonnée. L’encodage lors des rejeux d’inférence effectue les fusions de manière gourmande dans cet ordre — de façon déterministe, sans recherche globale de segmentation la plus courte.

Subtilité : les fusions optimisent la frequence, pas la linguistique. ing devient un token parce qu’il est fréquent. L’élégance morphologique est secondaire.

Q7. BPE vs WordPiece vs Unigram / SentencePiece

• BPE (GPT, Llama) : fusions basées sur la fréquence ; encodage déterministe.

WordPiece (époque BERT) : boucle similaire, mais choisit les fusions qui maximisent la probabilité des données d’entraînement selon un modèle unigramme — en évaluant à quel point une paire est informative ensemble par rapport à séparément.

Unigram LM (souvent via SentencePiece ; catégorie T5/Gemma) : on commence avec un ensemble important de tokens et on élimine ceux dont la suppression a le moindre impact sur la probabilité. La segmentation probabiliste permet une régularisation sous-mot (échantillonnage de coupes alternatives pendant l’entraînement).

SentencePiece est une bibliothèque capable d’appliquer BPE ou Unigram. Son avantage pratique réside dans le traitement des caractères bruts avec un marqueur d’espace visible, ce qui rend la tokenisation réversible et sans pré-tokenisation des espaces blancs — essentiel pour le chinois, le japonais et le thaï.

Q8. Le BPE au niveau des octets est important parce que…

Les initiales de caractères Unicode nécessiteraient environ 150 K de symboles de départ et exigeraient encore l’usage de <UNK>. Partir des octets UTF-8 signifie que toute chaîne — emojis, caractères cyrilliques, octets endommagés — peut être encodée. Aucun dépassement de limite.

Cost : les emojis peuvent consommer plusieurs tokens ; les écritures non latines coûtent souvent 2 à 4 fois plus que l’anglais pour exprimer la même signification, ce qui fait que les utilisateurs non anglophones atteignent plus tôt leurs limites de fréquence et leurs plafonds contextuels. Des vocabulaires plus importants (passant de 32 K à 128 K) existent en partie pour réduire cet écart de fiabilité.

Q9. Pourquoi « combien de “r” dans strawberry ? » échoue

Le réseau ne voit jamais de lettres ; il voit des IDs. Si strawberry se compose de plusieurs sous-mots, compter les caractères nécessite de récupérer l’orthographe à partir des embeddings puis de l’agréger — il n’existe pas d’opération native permettant de parcourir les caractères un par un. La même problématique se pose pour les anagrammes, les palindromes, les réversions, ainsi que pour les calculs arithmétiques naïfs lorsque le regroupement des chiffres varie d’un nombre à l’autre. Les tokeniseurs modernes imposent parfois des séparations de chiffres spécifiques afin de rendre les calculs possibles.

Q10. Les IDs de tokens isolément

dudit modèle. Croiser des tokeniseurs n’a aucun sens. Même les IDs « spéciaux » diffèrent d’une famille à l’autre.

Q11. Problèmes qui surviennent en production

Il est obligatoire d’utiliser le modèle de chat d’entraînement ainsi que l’ensemble de tokens spéciaux correspondants. Les espaces en tête des chaînes représentent souvent des tokens réels. Le comptage des caractères utilisé par l’API pour facturer les tokens entraîne une troncature silencieuse des instructions. Les tokens sentinel multimodaux modifient la manière de packager les données. Les clés de cache doivent inclure la version du tokenizer. Une gestion incorrecte des signaux BOS/EOS entraîne des problèmes dans les conditions d’arrêt et les audits de logprob.

Q12. Équilibre entre taille du vocabulaire

Une plus grande valeur de V raccourcit les séquences et facilite le packaging multilingue, mais augmente les paramètres d’embedding, ceux de la tête du modèle linguistique ainsi que le softmax de décodage. Au-delà de ~100K–200K, on paie généralement plus en mémoire et en bande passante pour des améliorations minimes de qualité, sauf si la couverture multilingue l’exige.

Partie 3 — Embeddings

Q13. Embedding : gather vs matmul

La recherche par ligne équivaut à multiplier un vecteur one-hot par E. Les kernels utilisent la méthode gather ; les calculs restent linéaires.

Q14. Contextuel ou non ?

Les lignes d’entrée sont non contextuelles. Le contexte est construit grâce à l’attention entre les couches. Les embeddings de récupération correspondent généralement à des états plus profonds, et non à la ligne de tableau d’entrée.

Q15. Liaison des poids

On partage les poids des embeddings avec la tête du LM (transposition) afin d’économiser des paramètres — pratique courante dans les modèles plus petits. Les grands LM détachent souvent ces poids pour améliorer la qualité. Les têtes liées ne représentent pas une matrice d × V indépendante supplémentaire.

Q16. Information positionnelle

Les embeddings absolus ajoutent des vecteurs par index. RoPE fait pivoter Q/K de sorte que les décalages relatifs apparaissent dans les scores et permettent une meilleure collaboration avec le cache KV. Les schémas de biais relatifs constituent des alternatives ; RoPE domine les nouveaux LLM.

Q17. RoPE et extension au contexte long

La géométrie relative de RoPE permet des extrapolations plus fiables que les tables absolues naïves. Les extensions (interpolation de position, échelle adaptée à NTK, YaRN, etc.) rééchellent les fréquences de rotation afin que des contextes plus longs restent stables sans nécessiter un entraînement à partir de zéro.

Q18. Le facteur √d_model

Lorsque les vecteurs de token et de position sont ajoutés, leurs échelles peuvent entrer en conflit ; multiplier les embeddings par √d_model permet de les équilibrer. Les architectures RoPE basées sur la rotation omettent souvent ce facteur de multiplication.

Partie 4 — Le bloc transformateur

Q19–Q23. Mécanismes d’attention (détaillés)

x → MultiHeadSelfAttention → Add & Norm → FFN → Add & Norm → out

Attention(Q, K, V) = softmax(QKᵀ / √d_k) V

Les requêtes cherchent, les clés annoncent, les valeurs livrent. Le softmax appliqué aux points échelonnés produit des poids de mélange. On divise par √d_k afin que les scores ne saturent pas à mesure que la largeur augmente. De nombreuses têtes diversifient les sous-espaces. Les masques causaux écrivent −∞ dans les futurs interdits, de sorte que la masse du softmax soit exactement nulle — les zéros présents dans le masque pourraient tout de même s’infiltrer. Lors d’une décodage pur avec un cache, l’ensemble des clés ne comporte pas de positions futures, donc le masque est implicite ; la précharge nécessite néanmoins un masquage (ou un noyau causal).

Q24–Q26. Formes, coût, résidus

Les projections ont chacune une taille d’environ d × d (modifiées selon GQA). Les FFN dominent en termes de paramètres avec une expansion d’environ 4 fois. Le coût de l’attention est proportionnel à O(n² d) ; celui des FFN à O(n d²). Pour les prompts courts : contraintes liées aux poids et aux FFN. Pour les contextes longs : l’attention et la mémoire KV prennent le dessus. Les résidus permettent de maintenir des piles profondes entraînables en fournissant des voies de gradient et des ajustements additifs.

Q27–Q30. Normes, largeur des FFN, activations, MoE

RMSNorm élimine le centrage par la moyenne et est moins coûteuse que LayerNorm. La pré-normalisation stabilise les réseaux très profonds par rapport à la normalisation classique post-norm. Les FFN larges (~4 fois) augmentent la capacité par token entre les mélangeurs d’attention. Les non-linéarités empêchent que les opérations linéaires superposées ne s’effondrent ; SwiGLU a remporté de nombreuses expérimentations sur les LLM. Le MoE dirige les tokens vers quelques FFN experts, ce qui permet aux paramètres d’évoluer plus rapidement que les FLOPs par token — consommation mémorielle élevée, calculs moins intensifs.

Q31–Q32. Profondeur/largeur et variantes d’attention

La profondeur permet de répéter le mélange ; la largeur enrichit les caractéristiques. Les laboratoires choisissent en fonction des limites de données et de regroupement. MHA stocke un K/V par élément ; MQA partage un seul K/V entre les requêtes ; GQA partage par groupe ; MLA compresse davantage les KV. Le coût de service a poussé l’industrie à suivre cette séquence.

Partie 5 — Le cache KV

Q33. Qu’est-ce que le cache KV, et pourquoi seulement K et V ?

Lors de l’étape de décodage t, un nouveau token arrive. Sa requête q_t doit consulter les clés et valeurs des positions 1..t. Les clés et valeurs pour 1..t−1 dépendent uniquement des tokens précédents et des poids figés. La causalité garantit que l’introduction du token t ne peut pas réécrire ces tenseurs K/V antérieurs — ils sont immuables — donc ils sont calculés une fois et stockés.

Les requêtes diffèrent : vous n’avez besoin que de q_t pour l’étape actuelle. Les requêtes antérieures ont déjà produit des résultats anciens et ne seront jamais lues à nouveau, donc mettre en cache Q représente un gaspillage de mémoire.

Sans cache, émettre le token t entraînerait la réexécution de tout le préfixe — une opération dont la complexité augmente fortement avec la longueur. Avec le cache, l’attention à chaque étape est proportionnelle à la longueur actuelle et le FFN effectue un travail pratiquement constant par nouveau token. La génération devient alors proportionnelle au nombre d’étapes de décodage plutôt que quadratique en fonction du nombre de passes.

Q34. Déterminer la taille du cache KV à l’aide d’un nombre réel

KV bytes = 2 (K and V)
         × n_layers
         × n_kv_heads × d_head
         × seq_len
         × batch_size
         × bytes_per_element

Imaginons une architecture GQA de type Llama-3–70B : quatre-vingts couches, huit têtes clé/valeur, cent vingt-huit dimensions par tête, stockées sous forme de flottants à deux octets.

Multipliez ces facteurs : deux tenseurs (K et V) × quatre-vingts × huit × vingt-huit sur cent × deux octets donnent environ 320 KB pour chaque token de chaque séquence en temps réel.

Si l’on étend cela à un dialogue de 8 000 tokens, on en arrive à environ 2,6 GB par utilisateur. Avec un contexte de 128 000 tokens, la même formule indique des dizaines de GB — suffisamment pour que seule une conversation occupe une grande partie d’un appareil de classe H100, sans même tenir compte des poids.

Situation contraire sans GQA (64 têtes KV) : le chiffre pour 8 000 tokens monte à environ ~21 GB par séquence. GQA fait toute la différence entre des dizaines d’utilisateurs simultanés et un petit nombre seulement.

Les poids représentent une taxe fixe payée une seule fois. Le cache KV est une taxe par utilisateur, par token, illimitée. Il définit la taille maximale du lot, ce qui influence le débit de traitement, et donc le coût en dollars par million de tokens. C’est pourquoi les diagrammes le désignent comme le goulot d’étranglement majeur de la mémoire.

Q35. Pourquoi le décodage est limité par la mémoire — l’arithmétique

Considérons un modèle de 70B en format fp16 générant un seul token par lot :

• Octets déplacés : ~140 GB de poids plus quelques GB pour le cache KV ≈ 142 GB.
• FLOPs : ≈ 2 × 70e9 × 1 = 140 GFLOPs.
• Intensité : ≈ 1 FLOP/byte.

Durée réelle ≈ 142 GB / 3,35 TB/s ≈ 42 ms → environ 24 tok/s uniquement grâce à la bande passante. Les systèmes réels se situent dans un facteur deux par rapport à cette estimation, ce qui montre à quel point les contraintes liées à la bande passante influencent fortement les performances.

Corollaire : augmenter la taille des lots est presque sans coût pour le trafic lié aux poids tant que l’on n’est pas limité par les ressources de calcul. Passer d’un lot de 1 à 32 permet de réutiliser un même chargement de poids sur 32 séquences, ce qui peut multiplier le débit en tokens. Cette amortisation constitue le facteur économique central dans la fourniture de services basés sur des LLM.

Q36. Si le lotage est « gratuit », pourquoi ne pas utiliser 512 ?

Parce que chaque séquence nécessite sa propre mémoire KV, et la mémoire cache augmente en fonction de lot × longueur_séquence:

GPU memory = model weights + KV cache + activations + fragmentation overhead

Exemple : 140 GB de poids sur 2×H100 (160 GB) laissent environ 20 GB pour la mémoire cache. À un débit de 320 KB/token, cela correspond à environ 65 000 tokens au total pour le lot. Seize utilisateurs avec un contexte de 4 K saturent déjà ce budget.

Ainsi, la taille maximale des enregistrements KV limite la taille des lots, ce qui à son tour limite le débit. La GQA, la MLA, la quantification de la mémoire cache, le pagination et les politiques d’éviction sont des fonctionnalités de débit qui se présentent sous l’apparence de mécanismes de gestion de la mémoire.

Q37. PagedAttention et le problème de fragmentation

Les serveurs naïfs réservent une zone KV contiguë par requête jusqu’à max_seq_len. Cela échoue de deux manières :

• Fragmentation interne — une complétion de 100 tokens qui a réservé 4096 emplacements gaspille la majeure partie de l’allocation.
• Fragmentation externe — des régions libérées de tailles variées laissent des espaces vides dans lesquels on ne peut pas placer de nouvelles zones.

Le gaspillage constaté dans les allocateurs naïfs se situe souvent entre 60 et 80 % de la mémoire KV.

PagedAttention (popularisé par vLLM) reprend l’idée de la mémoire virtuelle du système d’exploitation : des bloques de taille fixe (par exemple 16 tokens), ainsi qu’une table des blocs qui associe les positions logiques aux blocs physiques présents dans le pool. Les blocs sont alloués au fur et à mesure que la longueur du texte augmente.

Avantages :

• La fragmentation diminue → souvent 2–4× plus de séquences simultanées peuvent être traitées sur les mêmes GPU.
• Partage de préfixes / copie sur écriture — de nombreuses requêtes utilisant le même prompt système partagent des blocs physiques tant que leurs suffixes ne diffèrent pas ; idéal pour les agents, les instructions RAG et les exemples de type few-shot.
• Les faisceaux d’échantillons et les échantillons parallèles partagent le préfixe commun au lieu de le cloner.

Le prix à payer est l’indirection ainsi qu’un noyau d’attention qui doit traiter des blocs non contigus.

Q38. Grouper statiquement vs continuellement

Grouper statiquement consiste à attendre que le groupe soit complet, à exécuter toutes les séquences en synchronisation avec la plus longue et à compléter par des tokens inutiles. Les requêtes courtes doivent attendre celles qui sont longues ; les GPU consomment ainsi des cycles inutilement pour ces tokens de complément.

Grouper de manière continue (au niveau des itérations) signifie reconstruire le groupe à chaque étape de décodage : les séquences terminées quittent le groupe, de nouvelles y entrent, et le GPU ne traite que les tokens actifs. La variabilité de la latence diminue fortement et le débit augmente considérablement — c’est une exigence fondamentale des moteurs modernes (vLLM, TensorRT-LLM, etc.).

Q39. Préremplissage en tronçons et désagrégation du préremplissage/décodage

Le préremplissage en tronçons divise les prompts longs en segments intercalés avec les étapes de décodage, ce qui augmente légèrement le TTFT tout en maintenant un TPOT plus stable.

La décomposition va encore plus loin : on effectue le préremplissage sur des groupes optimisés pour le calcul et la décodage sur des groupes optimisés pour la mémoire, en transmettant les paires clé/valeur par le réseau. Cela ajoute de la complexité en termes d’orchestration, mais adapte chaque phase au matériel qu’elle sollicite réellement.

Q40. Réduction des paires clé/valeur au-delà de GQA

Les solutions possibles incluent :

• MQA / GQA / MLA — moins de têtes de paires clé/valeur ou des versions compressées.
• Cachets quantifiés (de type INT8/FP8/NF4) — souvent presque sans perte pour les valeurs clé et valeur.
• Attention ciblée par fenêtres / glissante — suppression de nombreux tokens lorsque la tâche le permet.
• Politiques d’éviction / de streaming pour des contextes extrêmes.
• Réutilisation entre couches : idées de recherche permettant de partager des projections à travers différentes profondeurs.

Chacune de ces solutions compromet un peu en qualité ou en généralité au profit d’avantages importants en termes de mémoire.

Q41. Mémorisation des préfixes — lorsqu’il y a changement d’architecture

Si de nombreuses requêtes partagent un préfixe long et immuable (prompt système, schémas d’outils, contexte persistant récupéré), le stockage en cache des paires clé/valeur de ce préfixe permet d’éviter de le recalculer. Les architectures privilégient donc des préfixes stables et des suffixes modifiables : on place le texte utilisateur volatile à la fin, tandis que le noyau commun reste identique au niveau binaire afin que les clés de cache fonctionnent correctement. Les textes de présentation des produits et les outils de compilation des prompts font alors partie des facteurs influençant les performances.

Q42. Quand le cache KV devient-il invalide ?

À tout moment où des tokens existants sont modifiés, et non simplement ajoutés : lors de la régénération en cours de conversation, de la réécriture d’un prompt système, du changement des définitions d’outils, ou de l’application de modifications non causales. Les caches de préfixes doivent être indexés selon l’identité exacte des tokens (ainsi que la version du modèle). Les paramètres de sampling ne rendent pas les paires K/V invalides — ils modifient simplement la manière dont les logits deviennent le prochain ID — mais changer l’adaptateur du modèle, le modèle de brouillon ou l’échelle RoPE en cours d’exécution peut le faire.

Partie 6 — Tête du LM (linéaire + softmax)

Q43. Quel est le rôle de la tête du LM et quelles en sont les formes

Le dernier bloc émet h ∈ ℝ^(seq_len × d_model). Après une norme finale, une transformation linéaire produit des logits de vocabulaire :

logits = h @ W_lm      W_lm ∈ ℝ^(d_model × V)

Pour d_model = 4096 et V = 128 000, W_lm contient 524 M de paramètres et génère un vecteur de 128 K d’éléments par position évaluée.

Q44. Des logits pour chaque position pendant la décodage ?

Non. Le préremplissage peut évaluer de nombreuses positions pour l’entraînement ou certaines API spécifiques, mais la décodage ordinaire n’a besoin que de l’état caché de la dernière position. Les positions précédentes ont déjà choisi leurs tokens.

Q45. Coût de la tête du LM lors de la décodage

Chaque étape multiplie un vecteur d par d × V — ce qui représente environ 2 × d × V FLOPs ainsi qu’une lecture complète d’un encodage potentiellement non lié. Lorsque V est élevé, cela rivalise avec une tranche d’FFN, ce qui justifie l’utilisation de softmax adaptatif, du partage parallèle du vocabulaire et d’encodages liés lorsque c’est acceptable.

Q46. Logits vs probabilités

Les logits sont des scores non bornés. Le softmax les normalise :

p_i = exp(z_i) / Σⱼ exp(z_j)

N’oubliez pas l’invariance au décalage : ajouter une constante à tous les logits ne modifie pas les probabilités — c’est le fondement des implémentations stables et de la température en tant que rééchellement des différences.

Q47. Softmax numériquement stable

L’expression naïve exp(z_i) provoque un débordement en fp16 pour des logits modérés et peut ramener toute une ligne à zéro, générant ainsi 0/0. La solution consiste d’abord à soustraire la valeur maximale de la ligne :

p_i = exp(z_i − max(z)) / Σⱼ exp(z_j − max(z))

Le terme le plus grand devient exp(0) = 1 ; les autres se situent dans l’intervalle (0, 1]. Les algorithmes en ligne (comme FlashAttention) combinent cela avec des opérations matmul afin d’éviter de générer des matrices de scores énormes.

Q48. Perplexité

La perplexité correspond à exp(moyenne des logarithmes négatifs de vraisemblance) sur les tokens — elle indique à quel point le modèle est « surpris ». Elle est calculée à partir de la même étape de logits/softmax. Une perplexité plus faible dans un domaine suggère une meilleure calibration des tokens suivants, mais ce n’est pas une mesure directe de l’utilité ou de la sécurité du modèle.

Partie 7 — Stratégies d’échantillonnage

Après la partie LM, on dispose d’un vecteur de logits. L’échantillonnage permet à ce vecteur de devenir l’ID suivant.

Q49. Décodage gourmand — et pourquoi il déçoit

La méthode gourmande choisit toujours argmax. Elle est déterministe et peu coûteuse, mais souvent banale ou têtue au niveau local : des tokens à haute probabilité dès le début peuvent piéger la séquence dans des boucles répétitives à forte probabilité, que les humains jugent pires que des alternatives à probabilité légèrement inférieure. Utilisez-la pour des tâches d’extraction fragiles ; évitez-la comme valeur par défaut pour du texte prosaïque ouvert.

Q50. Pourquoi pas la recherche par faisceau ?

La recherche par faisceau conserve les B meilleures hypothèses partielles. Elle est utile lorsque l’objectif est court et contraint (style traduction). Pour les conversations ouvertes, elle produit généralement du texte générique et sûr à haute probabilité, nécessite B× en termes de calcul, et interagit mal avec la diversité de type nucleus. La plupart des applications d’LLM l’ont abandonnée au profit de la méthode d’échantillonnage.

Q51. Top-k

Conservez uniquement les k logits les plus importants, renormalisez-les, puis effectuez un échantillonnage. C’est simple, mais k est peu adaptatif : parfois la masse de probabilité en dehors du top-k reste importante ; parfois le top-k inclut des éléments inutiles lorsque la distribution est très marquée. Un k fixe ne peut pas s’adapter à ce degré de marquage.

Q52. Top-p (noyau)

Classez selon la probabilité, conservez l’ensemble le plus petit dont la masse cumulative est ≥ p, puis effectuez un échantillonnage. Lorsque le modèle est sûr de lui, le noyau se rétrécit ; lorsqu’il hésite, il s’élargit. C’est cette capacité d’adaptation qui explique pourquoi le top-p a remplacé le top-k fixe comme paramètre par défaut dans de nombreux systèmes. Une valeur typique de p se situe entre 0,9 et 0,95, en fonction du produit concerné.

Q53. Température — mathématiques et intuition

p_i = exp(z_i / T) / Σⱼ exp(z_j / T)

Divisez les logits par T avant d’appliquer la fonction softmax.

• T → 0 — les écarts explosent ; la distribution se réduit au résultat de l’argmax (méthode gourmande).
• T = 1 — distribution du modèle non normalisée.

T > 1 — aplatissement ; plus de surprise et risque d’incohérence.

Dans la mise en œuvre, la température ne « crée pas de hasard » par elle-même — elle modifie simplement la distribution à partir de laquelle le échantillonneur tire.

Q54. Ordre : température contre troncature

Appliquez d’abord la température aux logits, puis effectuez une sélection top-k / top-p sur la distribution résultante (ou tronquez les probabilités tempérées de manière équivalente). Tronquer avant d’appliquer la température change les extrémités de la distribution et constitue généralement une combinaison incorrecte. Documentez l’ordre utilisé par votre serveur ; des substitutions silencieuses modifient le comportement.

Q55. Pénalités de répétition, de fréquence et de présence

• Répétition / fréquence — atténuez le poids des tokens déjà vus, souvent en fonction de leur nombre d’apparitions.
• Presence — pénalisez un token une seule fois s’il est apparu ne serait-ce qu’une fois, quel que soit son nombre d’apparitions.

Ils luttent contre les boucles dans la décodage créatif, mais peuvent nuire à une répétition intentionnelle (code, poésie, phrases juridiques). Préférer des pénalités légères et des règles de cessation strictes plutôt qu’un entravement agressif.

Q56. Au-delà de top-p

Min-p : seuils par rapport à la probabilité maximale (p_i ≥ min_p × p_max), qui fonctionnent mieux lorsque la température est élevée et que les masses sont diffuses. Mirostat et les contrôleurs similaires visent un niveau de surprise. La production typique reste axée sur la température + top-p, tandis que min-p gagne en importance.

Q57. La température à 0 varie encore — pourquoi ?

Même les architectures « gourmandes » diffèrent selon :

• Des réductions GPU non déterministes et des noyaux fusionnés.
• Des schémas de lotisation différents ou en lot continu.
• Des chemins spéculatifs et des implémentations softmax numériquement différentes.
• Des pénalités par défaut du côté serveur, des chaînes de cessation et des modèles.

Bruit de routage MoE si activé.

La méthode gourmande et stable en bits exige des noyaux verrouillés, une taille de lot de 1 et des versions logicielles identiques — ce qui est rare dans les flottes multi-locataires.

Q58. Forcer l'utilisation de JSON ou d’un schéma

Les options possibles sont les suivantes :

1. Forcer l’utilisation de JSON (fragile).
2. Décodage restreint / masques grammaticaux — annuler les tokens illégaux à chaque étape (regex, schéma JSON, CFG).
3. Appeler des API de outils/fonctions qui analysent des canaux latéraux plutôt que du texte libre.
4. Réparation a posteriori (dernier recours).

Le décodage restreint constitue la solution fiable pour les systèmes où la validité est obligatoire.

Q59. Évaluation des paramètres d’échantillonnage

Fixez le modèle et testez les paramètres de température/top-p sur un ensemble étiqueté : succès de la tâche, toxicité, diversité (distinct-n), taux de répétition, latence. Préférez une évaluation hors ligne associée à un test A/B en ligne avec des métriques de produit claires. Ne faites pas de réglages sur une seule requête soigneusement choisie.

Partie 8 — Décodage spéculatif

Q60. Idée principale

provisoire peu coûteux propose plusieurs tokens futurs ; le modèle cible les vérifie en une seule itération parallèle sur l’ensemble des tokens provisoires. Le préfixe accepté devient la sortie ; en cas de première réjection, on sélectionne un remplaçant dans la distribution cible et on élimine le reste. On utilise la majeure partie de la capacité du modèle cible pour des vérifications parallèles plutôt que pour des étapes séquentielles d’un seul token.

Q61. Pourquoi la distribution de sortie reste inchangée

L’acceptation utilise des ratios entre la cible p et le brouillon q de manière à ce que les tokens acceptés ainsi que le rééchantillonnage résiduel reconstituent exactement p:

P(emit x) = q(x)·min(1, p(x)/q(x)) + P(reject)·p'(x)

Le chemin accepté contribue avec min(q,p) ; le rééchantillonnage résiduel comble max(0, p−q). La somme donne p. Par conséquent, le décodage spéculatif est sans perte par rapport au rééchantillonnage cible ordinaire — ce qui accélère le système, sans constituer une approximation du modèle.

Q62. Accélération attendue

Avec un taux d’acceptation α et une longueur de brouillon k, le nombre de tokens attendus par itération cible est :

E[tokens] = (1 − α^(k+1)) / (1 − α)

Même si chaque token de brouillon échoue, on obtient néanmoins un token lors de la phase de vérification de la cible. Avec un coût de brouillon c par rapport à une étape cible :

speedup ≈ E[tokens] / (1 + k·c)

Exemple : α=0,8, k=4 → attente d’environ 3,36 tokens ; avec c=0,05 → environ 2,8×. Les victoires publiées se situent souvent dans la fourchette 2–3×. Une valeur élevée de k entraîne des retombées décroissantes, car la probabilité de survie diminue selon α^k.

Q63. Lorsque la spéculation nuit

Baixe acceptation (prompts difficiles, changement de domaine, brouillon faible), coût trop élevé du brouillon, ou noyaux incapables de vérifier en parallèle de manière efficace. Dans ce cas, les coûts supplémentaires dépassent les avantages — on bloque l’opération en fonction de la valeur mesurée de α.

Q64. Cache KV en cas de rejet

Enregistrement des entrées du cache relatives à l’objectif de rollback (et au brouillon) pour les positions rejetées. Les implémentations limitent la longueur des points de contrôle et tronquent les données ; les erreurs à cet égard corrompent l’attention future. Les tokens acceptés conservent leurs valeurs K/V.

Q65. Variantes modernes

Medusa / génération à plusieurs têtes, générateurs au niveau des caractéristiques de style aigle, génération à partir de recherches dans les prompts ou de n-grams issus du contexte lui-même, ainsi que générateurs en cascade. Même principe de vérification par rapport à la cible.

Q66. Attention arborescente

Les générateurs peuvent proposer un arbre de candidats, et non seulement une chaîne linéaire. L’attention arborescente vérifie plusieurs branches en une seule passe cible, augmentant le nombre d’acceptations attendues par appel lorsque la création de branches est peu coûteuse.

Partie 9 — Détokeniseur et flux continu

Q67. La détokenisation n’est pas une simple carte inverse

Les détokeniseurs doivent annuler les marqueurs d’espacement, gérer les fallbacks en octets, composer des graphèmes multi-token et éviter d’émettre du UTF-8 incomplet. La détokenisation en flux continu stocke les données dans un buffer jusqu’à ce qu’un caractère ou une partie complète puisse être émise sans risque — sinon, les clients voient des caractères de remplacement.

Q68. Comment fonctionne le flux continu et qu’est-ce qui doit être mesuré

Les serveurs émettent des tokens (ou des chaînes partielles) au fur et à mesure de leur génération. Mesurez le TTFT, le TPOT ainsi que le temps nécessaire pour atteindre le premier caractère lisible après le débouclage du tampon de détokenisation. L’expérience utilisateur du client tient davantage compte de ce dernier chiffre que des timestamps bruts des tokens.

Q69. Les séquences de fin sont complexes

Ces séquences peuvent traverser les limites entre tokens (\n\n par rapport à un seul token contenant deux sauts de ligne). Il faut vérifier le texte décodé (ou une fenêtre de tokens bien définie), et non seulement l’égalité des identifiants. En cas de chevauchement avec des séquences de fin partiellement générées, il est nécessaire de revenir en arrière afin que le texte de fin ne soit pas affiché.

Q70. Qu’est-ce qui met fin à une génération ?

EOS / identifiants spéciaux de fin, chaînes de fin correspondantes, limites maximales de tokens, annulation par le client ou mécanisme de surveillance du serveur. Préférez un traitement explicite de l’EOS conforme au modèle de chat.

Partie 10 — FlashAttention, quantification, roofline

Q71. FlashAttention — affirmations précises

FlashAttention calcule l’attention sans matérialiser toute la matrice de scores n × n dans HBM, en utilisant des techniques de découpage et des statistiques softmax en temps réel. Cela réduit la consommation mémoire et permet des séquences plus longues ou des lots plus importants. Il ne modifie pas le résultat mathématique de l’attention (à part les aspects numériques) ; il s’agit d’un algorithme conscient des contraintes de stockage, et non d’un modèle différent.

Q72. Aide-t-il au décodage ?

Le décodage avec mémoire cache utilise souvent une longueur q égale à 1 pour interagir avec les clés n mémorisées — l’avantage classique de FlashAttention (des scores carrés très importants) est donc moindre. Les variantes (FlashDecoding, etc.) aident encore à optimiser les chemins de bande passante pour les données KV, mais le décodage reste dominé par la charge liée aux poids à moins que le lot ne soit de grande taille.

Q73. Quantification

Stocker/compter les poids (et parfois les activations/KV) dans des formats plus restreints (FP8, INT8, INT4, …). La mémoire et la bande passante diminuent approximativement avec la largeur en bits ; la perte de qualité dépend de la méthode utilisée (GPTQ, AWQ, quantification lisse, …). Selon les notes pratiques : 8 bits est souvent presque gratuit ; 4 bits coûte un peu plus, parfois au niveau du bruit de référence — mesurez toujours sur vos tâches.

Q74. La courbe de toit en un paragraphe

Tracer les FLOPs atteignables en fonction de l’intensité arithmétique. La précharge se situe près du plafond de calcul ; la décodage en lot 1 se trouve près du plafond de bande passante à environ 1 FLOP/byte. Les optimisations qui augmentent l’intensité (grouper les opérations, utiliser moins de bits par FLOP utile) vous rapprochent du sommet de la courbe ; les accélérations purement liées aux noyaux ne peuvent pas dépasser le plafond auquel vous êtes confronté.

Q75. Diviser un grand modèle sur plusieurs GPU

Parallélisme tensoriel : divise les matrices en sous-ensembles au sein des couches (nécessite une interconnexion rapide). Parallélisme par pipeline : attribue des plages de couches aux différents nœuds (risque de bulles). Parallélisme expert : divise les experts du MoE en sous-ensembles. Parallélisme par réplique/données : copie le modèle pour améliorer la bande passante. Les déploiements réels combinent ces approches ; les données KV doivent être partitionnées ou répliquées de manière cohérente avec la structure d’attention.

Partie 11 — Chiffres de référence

• Poids en fp16 de 70 milliards : 70e9 × 2 ≈ 140 GB.
• FLOPs en phase avancée : ~2 × paramètres × tokens (ordre de grandeur).
• KV par token (Llama-3-70B-class GQA) : ~deux · nombre de couches · nombres de têtes KV · dimension de la tête · taille en octets, soit environ un tiers de mégaoctet par token.

Décodage par lots – tok/s : ~bande passante / weight_bytes (classe H100 : dizaines de tok/s en fp16 avant les autres solutions).

Embedding + tête de LM non liée à V=128K, d=4096 : environ 524 M de paramètres chacun.

Paramètres d’attention vs FFN : environ 1:2 dans un bloc standard (4d² contre ~8d²).

Partie 12 — Précautions concernant les diagrammes

Les diagrammes pédagogiques courants omettent : les modèles de chat avant la tokenisation, l’impact de GQA/MQA sur la largeur KV, les détails de l’ordre d’échantillonnage, le tampon de détokenisation, les tables KV paginées, ainsi que les boucles de vérification spéculatives. Considérez ces diagrammes comme des cartes, et non comme des contrats.

Conclusion

L’inférence est un processus allant des octets au texte en flux continu, où le préremplissage est limité par les capacités de calcul tandis que la décodification l’est par la bande passante ; le caché KV domine la mémoire utilisée par plusieurs utilisateurs, et chaque optimisation majeure — GQA, pagination, agrégation continue, quantification, FlashAttention, spéculations — vise à transférer les tâches vers les points forts du matériel sans modifier le modèle mathématique au-delà de ce qui est prévu.

Analyse approfondie A — Comparaison pratique des coûts de préremplissage et de décodification

Lorsque vous déterminez la taille d’une flotte de GPU, partez de la répartition des ressources par niveau. Les tâches à chargement préalable apprécient particulièrement les cœurs tensoriels : des prompts longs dans les fonctionnalités d’aide au codage ou les exports RAG peuvent montrer un usage efficace des MFU si les noyaux sont performants. Les tâches de décodage au premier lot ressemblent à des tests de mémoire accidentels — les mêmes poids de 70 milliards de paramètres sont traités en un seul passage par l’HBM pour une seule opération GEMV. C’est pourquoi un produit qui génère des réponses de 500 tokens semble lent même sur les GPU haut de gamme, à moins d’appliquer des techniques de lotage, de quantification ou de décodage spéculatif.

Les régressions TTFT indiquent généralement que les prompts se sont allongés (histoire, RAG, schémas d’outils) sans mise en cache des préfixes. Les régressions TPOT indiquent généralement que le lotage a échoué, que la bande passante a diminué ou que la pression sur les structures KV a contraint à l’utilisation de petits lots. La latence globale n’est pas un paramètre unique : raccourcir les réponses aide à réduire les temps TPOT de N fois ; la mise en cache des prompts du système aide à améliorer les performances TTFT ; le décodage spéculatif aide aux temps TPOT lorsque le taux d’acceptation est élevé.

Les métriques de débit affichées sur les tableaux de bord sont faciles à manipuler avec des lots énormes qui pénalisent les utilisateurs interactifs. Il convient de publier à la fois le nombre de tokens par seconde et par GPU, ainsi que les valeurs p50/p95 du TPOT dans un mélange réaliste. Le lotage continu permet de maintenir le GPU actif sans les inconvénients liés aux lots statiques ; le préremplissage en blocs empêche qu’un seul prompt de 32 K ne bloque le décodage des autres.

Le préremplissage et le décodage séparés représentent l’admission architecturale que ces deux tâches nécessitent des machines différentes. Les nœuds de préremplissage peuvent disposer d’un traitement plus intensif, tandis que les nœuds de décodage ont besoin de capacité mémoire et de bande passante pour gérer les données KV. Le réseau doit transférer ces données efficacement, sinon on perd l’avantage. Toute équipe ne devrait pas mettre en place cette architecture dès le début — mais chacune doit comprendre pourquoi ce schéma existe.

Approfondissement B — Tokeniseur et coûts multilingues

L’universalité des BPE au niveau des octets est à la fois un atout et une source de problèmes. Les applications de chat en anglais sous-estiment les coûts liés à l’utilisation avec des langues comme l’hindi ou le thaï, ainsi qu’avec du texte social riche en emojis. Si votre modèle de marge suppose un nombre déterminé de tokens par seconde pour l’anglais, son expansion multilingue peut entraîner des dépenses cachées. Préférez des tokeniseurs offrant une couverture multilingue plus large lorsque ce type de trafic est important ; mesurez le nombre de tokens par cluster graphémique sur des corpus réels, et non sur du texte fictif comme le lorem ipsum.

Les modèles de chat font partie intégrante de l’identité du modèle. Une seule erreur dans l’utilisation d’un token spécial de fin peut provoquer des générations incohérentes ou des coupures prématurées. Stockez la version du modèle de template à côté de la révision du modèle dans votre registre. Lorsque vous déboguez le problème « le modèle ignore la instruction système », tokenisez les deux parties et comparez leurs identifiants avant de blâmer les poids du modèle.

Les politiques de chiffres sont importantes pour les agents de tableurs et les tuteurs en mathématiques. Si 1000 et 1 000 sont traités différemment, les algorithmes de colonnes deviennent comme des billets de loterie. Préférez des tokeniseurs dotés de règles explicites concernant les chiffres lors de la création de calculatrices basées sur des LLM, ou redirigez les opérations arithmétiques vers des outils spécialisés.

Décryptage approfondi C — Attention, GQA et mémoire

L’histoire de l’attention multi-têtes repose sur la spécialisation dans des limites budgétaires. Celle du GQA concerne les octets KV. Le passage de l’MHA au GQA peut réduire la taille du cache d’environ le rapport entre le nombre de têtes de requête et le nombre de groupes KV — souvent de 4 à 8 fois — avec une perte de qualité modeste lorsqu’il est entraîné pour cela. Le MQA représente l’extrême ; le MLA et les méthodes de compression similaires visent le même goulot d’étranglement mais avec des approches algébriques différentes.

Le masquage causal avec l’infini négatif n’est pas une question de pédanterie : toute valeur de masque finie entraîne des fuites d’informations. Les erreurs de formation qui permettent accidentellement une attention future créent des modèles qui semblent performants sur les métriques imposées par l’entraîneur mais échouent en usage autoregressif réel. Les noyaux utilisés lors de la décodage, qui supposent que le plan d’organisation du cache correspond à la géométrie d’entraînement (nombre de têtes, base RoPE, facteur de mise à l’échelle), posent problème.

Les résidus et la normalisation préalable expliquent pourquoi les architectures composées de 80 à 100 couches sont monnaie courante. Lorsqu’une architecture personnalisée les supprime « pour simplifier », on peut s’attendre à de l’instabilité lors de l’entraînement plutôt qu’à des avantages réels. Le mécanisme de contrôle de SwiGLU constitue un paramètre d’ajustement dont les effets sur la mémoire doivent être pris en compte — il est essentiel de savoir si votre architecture l’intègre ou non.

Décryptage approfondi D — Gestion des pages KV et stratégie de préfixe

PagedAttention reconsidère les données KV comme un ensemble de blocs. Les conséquences en termes de calcul sont les suivantes :

• Les frameworks d’agents utilisant de très longs prompts partagés devraient normaliser ce préfixe afin que les hachages des blocs se chevauchent.

Les bibliothèques à faible quantité d’exemples doivent conserver les exemples dans un ordre stable ; le mélange aléatoire entraîne une diminution des accès au cache.

Les champs de personnalisation doivent être placés après le noyau partagé.

Les outils de débogage doivent afficher les taux d’accès à la table des blocs de la même manière que les CDN affichent les ratios d’accès au cache.

L’invalidation du cache par préfixe est un problème de correction, et non seulement un problème de performance. Si le schéma d’un outil change mais que la clé du cache l’ignore, le modèle utilise des données KV obsolètes pour de nouvelles instructions — ce qui provoque des pannes subtiles mais graves. Incluez l’ID du tokeniseur, le hash du modèle, l’ID de LoRA et l’échelle RoPE dans la clé.

L’éviction en cas de pression mémoire nécessite une politique : utilisation du principe LRU pour les conversations inactives, plafonds stricts sur le contexte, ou compression par résumé. Quelle que soit votre choix, exposez-le au produit — une troncation silencieuse constitue une faille de confiance.

Décryptage approfondi E — Softmax, échantillonnage et déterminisme

Le softmax stable est obligatoire pour les chemins en fp16/bf16. Les noyaux fusionnés masquent l’opération max-subtract, mais le code de recherche personnalisé rencontre toujours des problèmes d’overflow. La perplexité reste un indicateur utile pour détecter les changements dans la distribution lorsque l’on modifie des noyaux ou des schémas de quantification : des pics indiquent que la distribution a changé.

La composition du échantillonnage doit faire l’objet de tests unitaires : température, puis troncature, puis pénalités, enfin tirage aléatoire. Changez l’ordre dans un fichier de test et observez comment les résultats attendus divergent. La décodage contraint pour JSON doit faire l’objet de tests de charge ; la génération de masques peut devenir gourmande en ressources CPU si elle est implémentée de manière naïve.

Prétendre que une température nulle équivaut à un comportement déterministe relève d’une affirmation marketing, et non d’une garantie mathématique sur les GPU réels. Si vous avez besoin d’un enregistrement de qualité d’audit, enregistrez les identifiants échantillonnés (ou les graines de générateur aléatoire ainsi que les noyaux verrouillés du lot 1). Pour la plupart des applications, une reproductibilité au sein d’une même version est suffisante — documentez-le.

Approfondissement F — Opérations de décodage spéculatif

La spéculation sans perte est puissante car les responsables de produit craignent une dégradation de la qualité. Néanmoins, les équipes opérationnelles doivent suivre le taux d’acceptation par catégorie de prompt. La complétion automatique du code est souvent bien acceptée, tandis que les conversations créatives ou ouvertes ne le sont pas nécessairement. Une longueur de brouillon adaptative en fonction des acceptations récentes est préférable à une estimation statique.

La spéculation arborescente est utile lorsque le brouillon peut proposer des alternatives à faible coût. Les tests de correction en cas de rollback KV doivent faire partie du CI : il faut rejeter délibérément les exécutions en cours et s’assurer que les attentions suivantes correspondent à une référence non spéculative.

Les modèles de brouillon doivent partager le tokenizer (ou une correspondance compatible) avec la cible. Des tokenizers incompatibles génèrent des données inutiles invisibles, donnant l’impression que la spéculation a rendu le modèle moins performant.

Approfondissement G — Expérience utilisateur en streaming et arrêts

Les utilisateurs perçoivent la fluidité grâce aux caractères détokenisés, et non aux IDs bruts. Stockez temporairement jusqu’à ce que l’Unicode soit valide ; éliminez les données en cas d’espace blanc lorsque c’est possible pour améliorer l’expérience utilisateur dans les chats. Les séquences de terminaison qui chevauchent des tokens nécessitent une annulation minutieuse afin que le client ne voie jamais le texte de terminaison. Les limites maximales de tokens devraient ajouter un signal clair de continuation si le produit permet de poursuivre.

Décryptage approfondi H — FlashAttention et quantification lors du traitement

FlashAttention permet des précharges plus longues et des lots plus denses en économisant de la mémoire HBM. Soulignez ce point sans prétendre pour autant qu’il modifie les principes de décodage. La quantification est l’outil clé : moins d’octets par poids chargé augmente le nombre effectif de tokens par seconde. Validez cela avec votre ensemble d’évaluation — en particulier pour les appels aux outils et le rappel de contextes longs — avant d’affirmer que la version 4 bits est disponible.

La logique liée à la ligne de toit garantit l’honnêteté des arguments : si vous êtes limité par la bande passante, acheter plus de TFLOPS sans augmenter la bande passante (ou réduire le nombre d’octets) est décevant. Si vous êtes limité par les capacités de calcul lors du préremplissage, des GEMM améliorés et un planification en blocs sont plus importants que la réduction du volume des données KV.

Analyse approfondie I — Les réalités des multi-GPU

La parallélisation tensorielle nécessite des interconnexions rapides, sinon elle stagne lors des opérations de réduction globale. La parallélisation en pipeline requiert des micro-groupes de données pour masquer les retards. Le mélange de ces approches avec un agrégation continue et des données KV paginées explique pourquoi les moteurs d’inférence sont constitués de bases de code très volumineuses. Lorsque quelqu’un propose simplement de diviser le modèle en parties, demandez quelle dimension est concernée et ce qui arrive à la structure des données KV.

Analyse approfondie J — Assemblage du pipeline

Un chemin de demande à mémoriser :

1. Template plus tokenisation sur le CPU
2. Embedding et préremplissage avec attention causale, écriture des données KV (GPU, limité par les capacités de calcul)

Tête LM en dernière position puis échantillonnage (GPU avec politique CPU)

Boucle de décodage avec cache, lotification continue, spéculation optionnelle (GPU, limité par la bande passante)

Détokenisation, vérifications de fin, flux sur CPU

Libération ou mise en réserve des blocs KV dans l’allocateur

Chaque optimisation correspond à une flèche dans cette liste. Si vous ne pouvez pas pointer vers la flèche, vous ne raisonnez pas encore sur l’inférence — vous collectez simplement des idées.

Précisions supplémentaires en style FAQ

L’augmentation de la température améliore-t-elle la créativité de manière mesurable ? Elle augmente l’entropie de la distribution des tokens suivants. Le fait que les humains qualifient le résultat de créatif dépend de la tâche ; mesurez-le avec des indicateurs de diversité et de qualité, et non uniquement en fonction de l’impression générale.

La cupidité est-elle jamais justifiée ? Oui — la classification en tant que génération, l’extraction structurée avec décodage contraint, ainsi que certains outils d’évaluation. Le dialogue ouvert n’est généralement pas le cas.

Pouvez-vous supprimer la mémoire cache KV et recalculer ? Toujours, mais au prix d’un coût quadratique. Les appareils embarqués fonctionnent parfois avec de courtes fenêtres sans cache ; les serveurs ne devraient presque jamais le faire.

Pourquoi les diagrammes montrent-ils softmax à l’intérieur de l’attention et à nouveau au niveau du tête du LM ? Des softaxes différents : l’un mélange les valeurs à l’intérieur d’une couche ; l’autre transforme les logits du vocabulaire en une distribution catégorielle pour l’échantillonnage. Même famille de fonctions, tâches différentes.

Que doit mémoriser en premier un nouvel ingénieur ? Les goulets d’étranglement liés au préremplissage et au décodage, la formule des octets KV par token, TTFT versus TPOT, et le fait que le lotage échange la latence contre le débit. Tout le reste découle de ces quatre idées.

Guide approfondi — Noyaux de préremplissage et leviers TTFT

La qualité du préremplissage des services dépend principalement de la vitesse à laquelle on peut transformer une requête en un cache KV prêt à l’emploi. Les noyaux d’attention, les chemins MLP fusionnés et la façon dont la requête est divisée en parties déterminent la forme de la courbe TTFT. Lorsque les requêtes partagent un même préfixe, le cacheage de ce préfixe transforme les coûts répétés de préremplissage en des recherches rapides ; sinon, chaque nouvelle session doit payer le prix plein.

Le préremplissage par segmentation est à la fois un outil d’équité et un outil de réduction de la latence. Sans lui, l’ingestion de 40 000 tokens peut bloquer le décodage pour tous les autres utilisateurs sur la GPU. Avec lui, les flux interactifs continuent de fonctionner tandis que le travail long avance par étapes. Le compromis est un TTFT légèrement plus élevé pour le travail long lui-même — ce qui est généralement acceptable.

Le choix de l’emplacement du préfixe relève d’une décision liée au produit. Placez le texte utilisateur volatile après la partie fixe afin que les clés de cache restent stables. Si le service marketing réécrit quotidiennement le message système, considérez cela comme un événement de mise à jour du cache et attendez que le temps TTFT augmente jusqu’à ce que la nouvelle partie fixe devienne à nouveau fréquemment utilisée.

Décortiquage approfondi — Expliquer mathématiquement la consommation de bande passante

Imaginez que vous lisiez l’ensemble des poids de HBM une fois par token généré, avec une taille de lot égale à un. L’intensité arithmétique diminue fortement, ne laissant qu’une multiplication-accumulation utile par octet transféré. Le matériel conçu pour des opérations GEMM intensives semble inactif car il attend les contrôleurs de mémoire. Le regroupement des opérations permet d’utiliser à nouveau chaque chargement de poids sur plusieurs séquences ; la quantification réduit la charge elle-même ; la vérification spéculative transforme plusieurs étapes séquentielles en une seule vérification parallèle. Ce sont différentes manières d’atteindre le même objectif.

Lorsqu’on affirme qu’un noyau est « 2 fois plus rapide » pour le décodage, demandez sous quel toit cette personne se trouve. Si les performances sont limitées par la bande passante, une simple optimisation des ALU ne peut pas atteindre un facteur 2. S’ils indiquent également une réduction du nombre de octets transférés, croyez-les après avoir vu une capture d’écran issue d’un outil de profilage.

Décortiquement approfondi — Politiques de service et SLO

Rédigez des SLO distincts pour le TTFT et le TPOT. Une mise à jour qui améliore le débit tout en doublant le p95 TPOT constitue une régression pour l’expérience utilisateur du chat, même si le tableau de bord des capacités le montre positivement. Les paramètres de lotage continu (nombre maximal de tokens par lot, file d’attente maximale, priorité entre décodage et préremplissage des blocs) sont les paramètres concrets qui sous-tendent ces SLO.

Décortiquement approfondi — Liste de vérification des opérations du tokeniseur

Au préalable de promouvoir un modèle :

1. Geler les fichiers de tokenisation ainsi que le texte des modèles de chat dans le même stockage d’artefacts que les poids du modèle.
2. Faire des tests de validation sur un petit nombre de chaînes multilingues et d’emojis afin de détecter d’éventuelles anomalies liées à la longueur des tokens.
3. Faire des tests de validation sur des chaînes contenant beaucoup de chiffres si le produit effectue des calculs mathématiques.
4. Vérifier que les identifiants des tokens de fin correspondent bien aux marqueurs de fin du modèle.
5. Vérifier que les outils de calcul de logprob utilisent le même tokenizer que celui employé pour l’inférence.

En omettant l’un de ces points, vous tenterez de diagnostiquer des problèmes de « qualité du modèle » qui sont en réalité dus à une dérive dans l’emballage du modèle.

Guide approfondi — Les variantes d’attention en tant que chronologie

Les premiers modèles de langage utilisaient une mémoire de travail complète et en payaient le coût via la cache. La pression liée à la production a donné naissance au MQA, puis au GQA en tant que compromis adopté par la plupart des points de contrôle avancés. Les approches MLA et les idées similaires basées sur des tableaux KV à faible rang poursuivent la même logique : conserver la richesse des requêtes tout en réduisant ce qui est stocké pour chaque token antérieur. Lors de la lecture d’un article, il faut traduire les affirmations en termes de « octets par token KV » et de « delta de qualité dans nos évaluations » — le langage marketing relatif à une « attention efficace » n’a sinon aucun sens.

Décortiquage approfondi — KV paginé et comportement multi-locataires

Les calculs liés à la fragmentation sont extrêmement complexes avec des réservations contiguës. La pagination transforme ce problème en un problème d’allocation avec des blocs fixes. Les clusters multi-locataires doivent suivre les échecs d’allocation, récupérer de la latence grâce aux tables de blocs et surveiller le taux de hits préfixés. Une chute soudaine du taux de hits indique souvent un changement dans l’espace réservé aux modèles ou une mise à jour silencieuse du tokenizer.

Le partage par copie sur écriture entre les faisceaux et les échantillons parallèles n’est pas optionnel pour le décodage de type recherche ; sans cela, vous multipliez inutilement la mémoire par la largeur du faisceau.

Guide approfondi — Échantillonnage pour les produits

Paramètres par défaut adaptés à la tâche :

• Extraction / arguments de l’outil : température basse, décodage contraint, méthode gourmande ou noyau réduit.
• Soutien par chat : température modérée, noyau autour de la bande commune 0,9, faible pénalité de répétition en cas d’apparition de boucles.
• Brainstorming créatif : température plus élevée, prise en compte de min-p, avertissements plus insistants pour l’utilisateur concernant la variance.

Enregistrez la tuple d’échantillonnage avec chaque réponse pour les tickets de support. Sans cela, il est impossible de répondre à des questions du type « Le modèle a dit X hier ».

Guide approfondi — Déploiement du décodage spéculatif

Déployez derrière un drapeau. Mesurez l’acceptation par point de terminaison. Désactivez lorsque α tombe en dessous du point d’équilibre dérivé de votre coût préliminaire c et de la longueur préliminaire k. Conservez à jamais une partie du trafic de test non spéculative — c’est votre référence de qualité fiable.

Vérifiez que les chemins de rejet nettoient bien les données KV. Ajoutez un test de chaos qui force des rejets au milieu de la séquence sous charge.

Guide approfondi — Détails du protocole de streaming

Décidez si le format de transmission transmet des tokens, des chaînes détokenisées, ou les deux. Les clients qui effectuent une re-tokenisation différemment ne s’accorderont pas sur les limites. Préférez une détokenisation côté serveur avec des événements “flush” explicites lorsque un cluster graphémique complet est prêt. Documentez comment les séquences de finition sont supprimées afin que le code d’interface ne les traite pas deux fois.

Guide approfondi — Tests d’acceptation de la quantification

Au préalable de mettre en œuvre des poids à 4 bits en production :

• Exécuter le jeu de tests standard eval.
• Exécuter les fixtures de appel d’outils.
• Exécuter les tests à contexte long.
• Comparer les tests de refus et de sécurité si applicable.
• Comparer les valeurs p95 TPOT et VRAM.

Si la qualité est dans l’épsilon convenu et que les gains en latence sont réels, procéder à la mise en production. Sinon, rester sur 8 bits pour ce modèle.

Démonstration approfondie — Réponses aux exercices sur le tableau blanc en prose

La mémoire nécessaire pour un point de contrôle fp16 à soixante-dix milliards de paramètres représente environ cent quarante gigaoctets rien que pour les poids. Une passe avant coûte de l’ordre de deux FLOPs par paramètre par token. La croissance des tables KV est linéaire en fonction du nombre de tokens actifs ainsi que du nombre de têtes clé/valeur stockées. La vitesse de décodage par lot suit la bande passante mémoire divisée par le nombre d’octets traités à chaque étape. Les tables d’incorporation et les têtes de langage non liées peuvent chacune consommer des centaines de millions de paramètres avec de grands vocabulaires — il ne s’agit pas d’erreurs d’arrondi. À l’intérieur d’un bloc, le chemin feed-forward possède souvent environ deux fois plus de paramètres de projection que l’attention.

Décortiquage approfondi — Enseigner l’honnêteté des diagrammes

Lorsque vous dessinez le flux de travail pour les nouveaux arrivants, commentez les éléments omis : les modèles, le pagination, le lotage continu, la spéculation et les buffers de détokenisation. Sinon, les ingénieurs mettent en œuvre le diagramme et sont surpris par les résultats en production.

Addendum final — À quoi ressemble une tâche « terminée » pour le responsable de l’inférence

Vous pouvez expliquer, sans diapositives, pourquoi un incident donné a nui à TTFT par rapport à TPOT. Vous pouvez estimer la mémoire KV nécessaire pour un objectif de concurrence et de contexte donné. Vous pouvez indiquer quel mécanisme — traitement par lots, quantification, GQA, spéculative execution, cache de préfixes — s’applique au symptôme observé. Vous considérez les tokeniseurs et les modèles comme des dépendances versionnées. C’est là la maîtrise opérationnelle requise pour l’inférence de modèles LLM ; tout le reste relève de détails que vous pouvez retrouver ailleurs.

Récit d’étude de cas — Un service interactif de 70B

Supposons que vous mettiez à disposition un modèle de chat de 70B en format fp16 sur une paire de GPU à forte capacité mémoire. Seuls les poids occupent déjà environ cent quarante gigaoctets, ce qui signifie que la mémoire est presque pleine avant même le début de toute conversation. L’espace restant doit couvrir les données KV de toutes les sessions en cours, les activations ainsi que la fragmentation mémoire due à l’allocation.

Récit d’étude de cas — Boucles d’agent et clés de cache

Un agent envoie le même schéma d’outil à chaque tour. Si le JSON du schéma est sérialisé avec un ordre de clés instable, les hachages préfixes échouent et vous devez recharger des milliers de tokens à chaque étape. L’encodage JSON canonique devient alors un outil d’optimisation des inférences. De même, insérer le profil de l’utilisateur avant le schéma empêche le partage entre utilisateurs ; l’insérer après permet de conserver la structure commune de l’outil.

Récit d’étude de cas — Décodage spéculatif sur le code versus la messagerie

Sur un point de terminaison de complétion de code, un petit modèle préliminaire entraîné sur des données similaires accepte la plupart des tokens ; la latence globale diminue d’environ deux fois. Sur un point de terminaison créatif ouvert, l’acceptation des tokens chute drastiquement et le même modèle préliminaire gaspille des ressources. L’utilisation de flags fonctionnels par route est plus efficace qu’un interrupteur de spéculation global.

Récit d’étude de cas — Erreurs de séquence d’arrêt

Une équipe met un arrêt à une barrière Markdown. La moitié du temps, la barrière correspond à un seul token ; l’autre moitié, elle est divisée. Les utilisateurs voient des backticks à la fin. La correction vérifie les fenêtres de texte décodé et annule l’intervalle d’arrêt. Les arrêts basés uniquement sur l’ID du token étaient la cause racine du bug.

Récit d’étude de cas — La surprise de la quantification

Les poids à quatre bits ont amélioré le taux de tokens par seconde d’environ 40 % sur un chemin de décodage limité en mémoire. Les évaluations via des outils ont perdu trois points. Le compromis : utiliser 8 bits pour les chemins liés aux outils, et 4 bits pour les brouillons de blogs longs. Un artefact de modèle, deux profils de diffusion — rendu possible par le routage au niveau du gateway.

Liste de contrôle pratique — Prêt pour le lancement

• [ ] L’histoire de Roofline est documentée pour le préremplissage et le décodage
• [ ] Les octets KV/token sont mesurés sur le vrai point de contrôle
• [ ] La concurrence × le budget de contexte correspondent à la mémoire GPU avec une marge
• [ ] Le lotage continu est activé avec une politique de priorité pour le décodage

[ ] Les clés de cache préfixées incluent le modèle de template, le tokenizer, LoRA et l’échelle RoPE

[ ] La tuple de génération aléatoire est enregistrée pour chaque réponse

[ ] Décodage contraint pour tout contrat JSON

[ ] Détokenisation en flux continu pour les buffers UTF-8 incomplets

[ ] Séquences de fin testées à travers les limites des tokens

[ ] Décodage spéculatif activé en fonction du taux d’acceptation mesuré

[ ] Quantification validée via des évaluations spécifiques à la tâche

[ ] Le plan parallèle des tenseurs/pipelines correspond à la réalité interconnectée

Liste de contrôle pratique — Tri des incidents

1. TTFT ou TPOT est-il défectueux ?
2. La longueur du prompt ou la composition du lot a-t-elle changé ?
3. La mémoire KV est-elle proche de la limite maximale ?
4. Les versions du tokenizer/template ont-elles évolué ?
5. Une flag de noyau/quantification a-t-elle changé ?
6. La spéculative decoding fonctionne-t-elle mal ?
7. Sommes-nous limités par la bande passante ou les ressources de calcul selon le profil ?

Travaillez la liste dans l’ordre ; la plupart des pages indiquant que « le modèle est lent aujourd’hui » se résolvent à l’étape quatre.

Glossaire en un seul endroit

TTFT — temps jusqu’au premier token émis après le début de la demande. TPOT / ITL — temps moyen entre les tokens successifs. Prefill — traitement parallèle de la requête permettant de remplir les tables KV. Decode — étapes autoregressives qui émettent de nouveaux tokens. KV cache — clés/valeurs stockées pour les tokens précédents. GQA — attention aux requêtes groupées réduisant le nombre de têtes KV. PagedAttention — allocation des tables KV par blocs. Nucleus (top-p) — troncature adaptative de la queue des probabilités. Speculative decoding — accélération par ébauche puis vérification. Roofline — modèle reliant l’intensité aux FLOPs max par rapport à la bande passante.

Paragraphe de synthèse finale

Considérez l’inférence comme une ligne de production. Les tokeniseurs définissent les zones de stockage des composants. Les embeddings et les blocs représentent les machines. Le cache KV est l’inventaire en cours de traitement qui occupe de l’espace de stockage pour chaque commande ouverte. L’échantillonnage constitue un contrôle qualité pour chaque unité. Le streaming correspond au quai de livraison. La décodage spéculatif représente une voie d’inspection parallèle. Si vous optimisez une station sans tenir compte de l’inventaire et de la bande passante, vous créez des piles de travail inachevé ainsi que des clients mécontents — même si chaque station « semble plus rapide » isolément.

Appendice — Comparaison des modèles mentaux que vous entendrez lors des entretiens

Les intervieweurs vous demandent souvent de concilier trois slogans : « les transformateurs sont parallèles », « la décodage est séquentiel » et « l’attention est quadratique ». Tous sont vrais dans des contextes différents. L’entraînement et le préremplissage exploitent le parallélisme entre des positions déjà existantes. Le décodage ne peut pas inventer à l’avance des tokens futurs sans spéculations. Le terme quadratique de l’attention est le plus important lorsque la longueur de la séquence est grande par rapport aux multiplications matricielles déterminées par la largeur. Une réponse solide précise d’abord le contexte avant de citer le slogan.

Un autre piège courant consiste à assimiler le nombre de paramètres à la vitesse de décodage. Les paramètres déterminent le nombre d’octets déplacés à chaque étape ; la disposition (GQA), le type de données et le regroupement décident de la manière dont ces octets se traduisent en tok/s. Deux modèles de 70 B peuvent présenter une différence de 2× en termes de latence interactive après avoir pris en compte ces facteurs.

Un troisième piège consiste à considérer l’échantillonnage comme « simplement du RNG ». La température, le troncement, les pénalités et les contraintes modifient chacune la distribution catégorielle ; le RNG ne fait que choisir parmi ce qui reste. Pour diagnostiquer des résultats étranges, il faut d’abord enregistrer cette tuplique.

Appendice — Équations minimales à mémoriser

KV bytes ≈ 2 × layers × kv_heads × head_dim × bytes × seq_len × batch. L’intensité pour la décodage en batch-1 ≈ 2 × params / weight_bytes ≈ O(1) FLOP/byte pour du fp16 dense. Nombre de tokens spéculatifs attendus par vérification ≈ (1 − α^(k+1)) / (1 − α). Stabilité de la softmax : soustraire le max avant l’explosion. Masque causal : écrire −∞, et non zéro, dans les scores interdits.

Si vous pouvez redériver ces formules au tableau noir et expliquer chaque symbole, vous dépassez déjà la plupart des explications vagues.

Appendice — Où aller plus en profondeur ensuite

Après cette visite des pipelines, les étapes logiques suivantes sont : lire un chemin d’allocation de type PagedAttention dans un moteur en cours d’exécution, analyser une étape de préremplissage et une étape de décodage à l’aide d’un outil de profilage fourni par le fabricant, et mettre en œuvre une petite boucle de décodage gourmande avec un cache KV explicite en NumPy ou PyTorch afin de comprendre les structures des données. Ces exercices transforment les concepts présentés précédemment en mémoire musculaire sans nécessiter un ensemble complet d’outils de formation.

Une dernière étape — Relier les métriques aux problèmes des utilisateurs

Lorsqu’un ticket de support indique « l’IA est lente », il faut interpréter cette remarque. Si un indicateur de chargement apparaît avant tout texte, il s’agit probablement de problèmes liés à la longueur du prompt, aux préfixes non utilisés, à une congestion lors du préremplissage ou à l’absence de cache. Si le texte s’affiche rapidement mais ensuite apparaît progressivement, il s’agit probablement de problèmes liés à une surcharge des lots, à une mémoire KV qui oblige à utiliser de très petits lots, à des poids non quantifiés sur une carte à bande passante limitée, ou au désactivement de la spéculation sur une route qui fonctionnait auparavant correctement.

Lorsque le ticket indique « les réponses se sont détériorées après mardi », comparez les tuples d’échantillonnage, les hachages de modèles et les flags de quantification avant de réentraîner quoi que ce soit. Les régressions de service se font constamment passer pour des régressions d’intelligence.

Lorsque le ticket mentionne « l’outil invente du JSON », cessez d’ajuster la température et utilisez une décodage contraint. L’échantillonnage ne peut pas imposer une grammaire ; le masquage, en revanche, le peut.

Les réunions de planification des capacités se déroulent mieux lorsque quelqu’un écrit trois chiffres au tableau : octets par token KV, concurrence cible, contexte cible. Multipliez, ajoutez l’empreinte mémoire, comparez avec la mémoire GPU. Les discussions sur la « magie de l’IA » s’arrêtent ; commence alors le calcul des besoins en ressources.

C’est là l’objectif de cette présentation complète du pipeline : remplacer le mystère par des indicateurs mesurables, et ces indicateurs par des leviers que vous pouvez actionner.

Dernière remarque sur le périmètre

Cette réécriture reste dans le cadre du processus d’inférence : ce qui se passe une fois que les poids existent, lorsque un client envoie du texte, et avant que l’équipe opérationnelle ne commence à parler d’ajustement fin. Les problématiques liées au temps d’entraînement — mélanges de données, optimiseurs, calendriers d’entraînement parallèles — sont extrêmement importantes, mais elles relèvent d’un autre sujet. Si vous parvenez à garder en tête, sous pression, la séparation préremplissage/décodage, la charge liée aux KV et la composition de l’échantillonnage, vous disposez déjà du cadre sur lequel s’appuient ces autres aspects.

Exercice pour le lecteur

Prenez une demande de production issue de vos journaux. Notez le nombre de tokens d’entrée, le nombre de tokens de sortie, ainsi que la valeur TTFT/TPOT observée si vous les avez. Estimez la mémoire KV en utilisant la formule par token adaptée à la structure des couches et de la tête de votre modèle. Déterminez si la demande était plus proche d’un préremplissage limité par les calculs ou d’une décodage limité par la bande passante. Citez un paramètre — cache de préfixes, taille du lot, quantification, GQA ou spéculative — qui aurait pu influencer positivement la métrique qui vous importe le plus. Si vous pouvez effectuer cet exercice sans relire cet article, la réécriture a rempli son objectif.

Gardez une petite fiche personnelle : pré-remplissage contre décodage, formule des octets KV, TTFT contre TPOT, et ordre d’échantillonnage. Consultez-la avant les analyses de capacité et avant de blâmer le modèle pour des erreurs de fonctionnement. De tels petits habitudes se combinent pour former une intuition fiable. Exercez-vous à expliquer le processus à haute voix en moins de deux minutes ; la fluidité sous pression temporelle est le véritable test de la compréhension. Exercez-vous à expliquer le processus à haute voix en moins de deux minutes ; la fluidité sous pression temporelle est le véritable test de la compréhension. Exercez-vous à expliquer le processus à haute voix en moins de deux minutes ; la fluidité sous pression temporelle est le véritable test de la compréhension.