D’abord, savoir ce qu’on attaque
Avant d’empiler les optimisations, il faut nommer ce qu’on cherche à réduire. La facture d’un LLM servi se décompose en quatre postes, et chaque technique en vise un : la confondre avec une autre, c’est tirer le mauvais levier.
Les poids sont l’empreinte fixe du modèle : indépendante du contexte, elle se paie une fois. Le KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire est l’empreinte qui grandit avec la conversation, et en contexte long, c’est lui qui domine, souvent loin devant les poids. Pour un modèle de 8 milliards de paramètres en GQA, comptez de l’ordre de 4 Go de cache à 32K tokens, 16 Go à 128K, près de 128 Go à un million, là où les poids, eux, restent figés autour de 16 Go en 16 bits. Le calcul par token détermine la vitesse et le coût énergétique de chaque token généré. Et l’utilisation du matériel (la part du GPU réellement exploitée) décide du débit qu’on tire d’une carte donnée.
La suite est rangée par ces quatre postes. Pour deux d’entre eux, la GQA et la MLA, on déplie le mécanisme ici même, parce qu’ils n’ont pas (encore) leur propre dossier ; pour les autres, on résume l’idée et on renvoie à l’article qui la détaille.
Attaquer les poids : la quantification
Le levier le plus direct sur les poids, c’est de coder chaque paramètre sur moins de bits. Un modèle stocké en 16 bits passe en 8, en 4, voire moins, et son empreinte fond d’autant. La quantification Réduction du nombre de bits codant chaque poids d'un modèle (de 16 bits vers 8, 4, voire moins). Elle divise l'empreinte mémoire d'autant, au prix d'une perte de précision contrôlée, sans changer le nombre de paramètres. Approfondir dans le glossaire moderne ne se contente plus d’arrondir après coup : les formats à blocs ( FP8 Format à virgule flottante 8 bits. Format de travail polyvalent pour l'inférence (et l'entraînement) sur GPU récents. Divise par 2 l'empreinte mémoire et le débit nécessaires par rapport au FP16, pour une perte de précision marginale sur la plupart des modèles. Approfondir dans le glossaire , MXFP4, NVFP4) partagent un facteur d’échelle entre plusieurs valeurs pour tenir en 4 bits sans effondrer la précision, et la quantification entraînée ( QAT Quantization-Aware Training. Plutôt que de comprimer un modèle déjà entraîné (et d'en subir la perte de précision), on le réentraîne brièvement en simulant la quantification, pour qu'il apprenne à vivre en basse précision (souvent int4). Réduit fortement la dégradation par rapport à une quantification post-entraînement naïve. ) réentraîne le modèle à vivre en basse précision. C’est le levier à tirer en premier quand ce sont les poids qui ne rentrent pas.
Détails dans nos dossiers sur les précisions FP8/FP6/FP4, les dialectes FP4, la quantification GGUF de llama.cpp et le calcul de la VRAM nécessaire.
Attaquer le KV cache : là où tout se joue en contexte long
C’est le poste qui explose quand le contexte s’allonge, donc celui qui concentre les techniques les plus utiles. Trois familles le visent, par trois voies différentes.
GQA et MQA : partager les têtes clés/valeurs. Dans l’attention classique (Multi-Head Attention), chaque tête de requête possède sa propre paire clé/valeur, et le KV cache pèse donc nombre de têtes × couches × longueur. La MQA (Multi-Query Attention), proposée dès 2019, pousse le bouchon à l’extrême : toutes les têtes de requête partagent une seule paire K/V. Le cache est divisé par le nombre de têtes, un gain énorme, mais la qualité en souffre et l’entraînement devient moins stable. La GQA Grouped-Query Attention. Variante de l'attention où plusieurs têtes de requête partagent un même couple de têtes clé/valeur, au lieu d'une paire K/V par tête. Réduit d'autant la taille du KV cache et la bande passante mémoire, pour une perte de qualité faible. Cas extrême : la MQA (Multi-Query Attention), une seule paire K/V pour toutes les têtes. (Grouped-Query Attention, 2023) est l’interpolation devenue standard : on regroupe les têtes par paquets, chaque paquet partageant une paire K/V. Le nombre de groupes place le curseur entre la mémoire (un seul groupe, c’est la MQA) et la qualité (autant de groupes que de têtes, c’est la MHA d’origine). Llama-2 70B était encore en MHA ; Llama-3 8B ramène 32 têtes de requête à 8 têtes K/V, soit un cache divisé par quatre, sans perte notable. C’est aujourd’hui le réducteur de KV le plus universel : un modèle récent qui s’en passe est l’exception.
MLA : compresser plutôt que partager. DeepSeek a introduit avec V2 une autre voie : la MLA Multi-head Latent Attention. Mécanisme d'attention de DeepSeek (V2) qui compresse conjointement les clés et valeurs de toutes les têtes en un vecteur latent de faible dimension, mis en cache à la place des K/V complets et reprojeté à la volée. Réduit le KV cache plus fortement que la GQA, à qualité préservée. (Multi-head Latent Attention). Au lieu de réduire le nombre de paires K/V, elle les compresse. Une projection « descendante » réduit les clés et valeurs de toutes les têtes à un seul vecteur latent de faible dimension ; c’est ce vecteur qu’on met en cache, pas les K/V complets, et une projection « montante » les reconstruit à la volée au moment du calcul. Le gain est spectaculaire : DeepSeek-V2 revendique un KV cache réduit d’environ 93 % par rapport à l’attention pleine, à qualité égale ou supérieure : un latent de l’ordre de 576 valeurs là où une GQA comparable en stockerait quatre fois plus. Le diable se cache dans un détail : cette compression est incompatible avec l’application directe de RoPE (l’encodage de position), ce qui oblige DeepSeek à greffer à côté une petite composante « RoPE découplée ». GQA partage, MLA compresse ; et la compression l’emporte quand on peut assumer la complexité d’implémentation.
Fenêtre glissante : borner ce qu’on regarde. La troisième voie ne réduit ni le nombre ni la dimension, mais la portée : une couche à fenêtre glissante n’attend que les derniers tokens, ce qui plafonne son cache à la taille de la fenêtre. C’est l’idée que Gemma pousse le plus loin, en n’utilisant l’attention globale qu’une couche sur six.
La fenêtre glissante locale/globale est détaillée dans notre dossier Gemma.
Attaquer le calcul par token
Réduire la mémoire ne suffit pas si chaque token coûte trop cher à calculer. Deux familles s’attaquent au calcul lui-même.
Le MoE Mixture-of-Experts. Architecture où le réseau est découpé en de nombreux « experts » dont un routeur n'active qu'un petit sous-ensemble par token. Le calcul par token suit le nombre de paramètres actifs ; la mémoire, elle, suit le nombre total, car tous les experts doivent rester résidents en VRAM, prêts à être sollicités. Approfondir dans le glossaire (Mixture-of-Experts) découpe le réseau en nombreux experts dont un routeur n’active qu’une fraction par token. Le calcul par token suit alors le nombre de paramètres actifs, pas le total : un modèle de 744 milliards de paramètres peut n’en activer que 40.
L’attention sparse, elle, ne calcule l’attention que sur un sous-ensemble sélectionné de tokens, au lieu de tout le contexte. La DeepSeek Sparse Attention ( DSA DeepSeek Sparse Attention. Mécanisme d'attention introduit par DeepSeek qui ne calcule l'attention que sur un sous-ensemble sélectionné de tokens du contexte, au lieu de relire tout le passé. Réduit fortement le coût en calcul et en mémoire du contexte long, au prix d'un indexeur qui décide quoi regarder. ) en est l’exemple récent : un indexeur léger choisit les tokens pertinents avant l’attention, ramenant un coût quadratique près du linéaire, souvent combinée à la MLA pour réduire à la fois le calcul et le cache.
Le MoE et son piège mémoire sont développés dans notre dossier GLM-5.2 ; le pipeline d’attention compressée, dans notre dossier sur le serving de DeepSeek-V4.
Changer d’architecture : les SSM
Les techniques précédentes optimisent l’attention. Une famille entière propose plutôt de s’en passer : les modèles à espace d’états ( SSM State Space Model (modèle à espace d'états). Architecture de séquence qui remplace l'attention par une récurrence : un état caché de taille fixe résume le passé et se met à jour à chaque token. Calcul linéaire en longueur et mémoire constante, au prix d'un rappel exact plus faible que l'attention. ), Mamba en tête, remplacent le KV cache croissant par un état caché de taille constante. Plus de cache qui enfle, au prix d’un rappel exact plus faible, ce qui fait des architectures hybrides (un tronc SSM + quelques couches d’attention) le format réellement gagnant.
Le mécanisme, le mur du rappel et les hybrides sont traités dans notre dossier SSM, Mamba et hybrides.
Mieux utiliser le matériel
Dernier poste, souvent négligé : la part du GPU réellement exploitée. Trois techniques, déjà couvertes ailleurs, y travaillent. FlashAttention Implémentation tile-by-tile de l'attention qui évite de matérialiser la matrice d'attention complète en HBM. Réduit drastiquement la consommation mémoire et accélère le calcul, particulièrement sur longs contextes. Trois versions (v1/v2/v3), chacune optimisée pour une génération de GPU. Approfondir dans le glossaire calcule l’attention par tuiles sans matérialiser la matrice complète en mémoire, ce qui économise la VRAM et accélère le calcul. Le batching continu Ordonnancement à l'itération : ajouter et retirer des requêtes du batch à chaque pas de génération, au lieu d'attendre qu'un batch entier se termine. Formalisé par Orca (OSDI 2022), popularisé par vLLM. Multiplie par 2 à 4 le débit d'un serveur d'inférence sous forte concurrence. Approfondir dans le glossaire ajoute et retire des requêtes du lot à chaque pas de génération, au lieu d’attendre qu’un lot entier finisse, et multiplie le débit sous forte concurrence. Et la disaggregation Séparation du pipeline d'inférence en phases distinctes (prefill, decode) exécutées sur des nœuds spécialisés. Permet d'affecter du matériel compute-bound au prefill et du matériel memory-bound au decode, au lieu de faire tourner les deux sur le même GPU sous-utilisé sur l'une des deux phases. sépare les phases de prefill et de decode sur des nœuds spécialisés, pour ne pas faire tourner du matériel compute-bound et memory-bound sur la même carte sous-utilisée.
Voir nos dossiers sur les runtimes d’inférence, le KV cache et la disaggregation en production.
La carte, d’un coup d’œil
| Technique | Ressource visée | Gain typique | Dossier |
|---|---|---|---|
| Quantification (FP8/FP4, QAT) | Poids | ÷2 à ÷4 sur les poids | FP8/FP4, GGUF |
| GQA / MQA | KV cache | ÷ nombre de groupes | détaillé ici |
| MLA | KV cache | compression latente forte | détaillé ici |
| Fenêtre glissante | KV cache | cache plafonné à la fenêtre | Gemma |
| MoE | Calcul / token | calcul ≈ params actifs | GLM-5.2 |
| Attention sparse (DSA) | Calcul + KV | quadratique → ~linéaire | DeepSeek-V4 |
| SSM / hybrides | Architecture | cache éliminé (état constant) | SSM & Mamba |
| FlashAttention, batching, disaggregation | Matériel | débit ×2 à ×4 | Runtimes |
Diagnostiquer le goulot avant de choisir
Cette carte ne sert à rien si l’on ne sait pas où l’on a mal. Avant de tirer un levier, mesurez la ressource qui sature, elle n’est pas toujours celle qu’on croit.
Poids ou KV cache ? Les poids sont fixes et faciles à estimer : environ 2 octets par paramètre en 16 bits, soit ~16 Go pour un 8B. Le KV cache, lui, suit une formule simple : 2 (clés + valeurs) × couches × têtes K/V × dimension de tête × longueur × octets par valeur. Pour un Llama-3 8B en GQA et FP16, cela fait environ 0,13 Mo par token, anodin sur un prompt court, mais 64 Go à 500 000 tokens. Règle empirique : en dessous de quelques milliers de tokens, ce sont les poids qui dominent ; au-delà, le cache prend le dessus, et c’est lui qu’il faut viser en priorité.
Prefill ou decode ? Une inférence a deux phases aux profils opposés. Le prefill Phase initiale d'une inférence LLM : tous les tokens du prompt sont traités d'un coup. Intensité arithmétique élevée, le GPU sature ses Tensor Cores. C'est l'inverse du decode qui suit. Approfondir dans le glossaire traite tout le prompt d’un coup : il sature les unités de calcul, il est compute-bound : les leviers qui l’aident réduisent le calcul (attention sparse, FlashAttention). Le decode Phase de génération autorégressive d'un LLM : un token est produit à la fois, en relisant tout le KV cache. Intensité arithmétique très basse, le GPU passe l'essentiel du temps à attendre la mémoire. Un service d'inférence réel est presque toujours dominé par le decode. Approfondir dans le glossaire génère un token à la fois en relisant tout le cache : il passe l’essentiel de son temps à attendre la mémoire, il est memory-bound, et là ce sont la réduction du cache (GQA, MLA, fenêtre glissante) et la quantification des poids qui paient. Un service dominé par de longues générations est presque toujours limité par le decode, donc par la mémoire : commencez par là.
Pour aller plus loin
Trois familles qu’on n’a pas dépliées ici, mais qui méritent le détour.
La quantification extrême : BitNet entraîne le modèle avec des poids ternaires (−1, 0, +1, soit ~1,58 bit par poids). À ce régime, les multiplications de matrices dégénèrent en simples additions, et l’empreinte des poids s’effondre, au prix d’un changement d’architecture qu’on ne peut pas appliquer après coup.
Les attention sinks (StreamingLLM) : une fenêtre glissante seule s’effondre dès que les premiers tokens sortent du cache, car le softmax y « déverse » son excédent d’attention. Garder en permanence ces quelques tokens-puits restaure la stabilité jusqu’à des millions de tokens, une stabilité de génération, à ne pas confondre avec une mémoire du contexte au-delà de la fenêtre.
L’éviction de KV (H2O, SnapKV) : plutôt que de tout conserver, on jette en cours de route les entrées de cache dont l’historique d’attention montre qu’elles ne servent plus. Une compression dynamique du cache, complémentaire de la GQA et de la MLA, qui agissent, elles, en amont.
Autant de pistes pour qui a déjà épuisé les leviers principaux.
Conclusion : un problème, plusieurs leviers
Il n’existe pas de « meilleure » technique d’efficacité, seulement des leviers adaptés à des goulots. Si ce sont les poids qui débordent, quantifiez. Si c’est le KV cache en contexte long, regardez du côté de la GQA, de la MLA ou de la fenêtre glissante. Si c’est le calcul par token qui plombe la facture, le MoE et l’attention sparse entrent en jeu. Et si vous voulez sortir du paradigme du cache, les SSM vous y attendent.
La compétence réelle, ce n’est pas de connaître une technique, c’est de diagnostiquer la ressource qui sature avant de choisir. Un serveur d’inférence sérieux en empile plusieurs, chacune sur le poste qu’elle sait alléger. Cette carte n’est qu’un point de départ : à vous de la lire en fonction de votre propre goulot.
Sources et méthode
Cet article est une synthèse cartographique ; chaque technique renvoie au dossier qui la traite en détail et en cite les sources primaires. Étiquettes : fait vérifié (source primaire), estimation (ordre de grandeur).
- Fait : GQA / MQA : partage des têtes K/V ; Llama-3 8B = 8 têtes K/V pour 32 têtes de requête.
- Fait : MLA : compression latente du KV (DeepSeek-V2, latent ~576 vs ~2048 pour une GQA comparable). Cf. dossier DeepSeek-V4.
- Fait : Fenêtre glissante locale/globale (Gemma 5:1), MoE (params actifs vs totaux), attention sparse (DSA), SSM (état constant) : voir les dossiers dédiés (Gemma, GLM-5.2, DeepSeek-V4, SSM & Mamba).
- Fait : FlashAttention, batching continu, disaggregation : voir Runtimes, KV cache, disaggregation.
- Pistes : BitNet (poids ternaires ~1,58 bit), StreamingLLM (attention sinks), H2O / SnapKV (éviction de KV) : familles non détaillées ici.
Note de méthode. Cet article est le hub d’une série : il cartographie et renvoie. Les chiffres précis et leurs sources vivent dans les dossiers liés. Le rangement « par ressource attaquée » est un cadre pédagogique : beaucoup de techniques agissent sur plusieurs postes à la fois (l’attention sparse réduit calcul et cache, par exemple).
Crédit image. Photo d’en-tête : puces mémoire d’une carte graphique par Gormé, CC BY-SA 3.0, via Wikimedia Commons.
