2026-03-13 · Mis à jour 2026-07-15

[!NOTE] Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.

LLM Guide d’ingénierie : 45 concepts pour l’inférence, l’entraînement, l’architecture et les opérations

Les systèmes de production LLM s’appuient simultanément sur le matériel GPU, l’ingénierie des systèmes ainsi que la théorie ML. Le même petit nombre de concepts est pertinent que l’on affine les paramètres de TTFT pour un chatbot ou que l’on configure DeepSpeed ZeRO pour une exécution fine-tuning. Ce guide les rassemble en un seul endroit.

TL;DR : Cette référence aborde 45 concepts répartis en huit parties, allant du matériel et de l’inférence jusqu’à l’entraînement, le déploiement et les opérations. Chaque entrée définit le concept, explique son impact pratique, fournit des chiffres pertinents pour illustrer l’échelle d’application, et propose des liens vers des sections connexes. Les données citées couvrent la période allant de 2024 à début 2026.

Ce guide part du principe que le lecteur maîtrise les concepts de base ML (retour par propagation, descente de gradient, softmax) ainsi que certaines connaissances en systèmes informatiques (hiérarchies mémoire, principes fondamentaux des réseaux).

!!! Note « Une remarque sur la portée »

Il s’agit d’une référence détaillée, et non d’un tutoriel linéaire. Utilisez le tableau ci-dessous pour accéder à la section correspondant à votre décision actuelle.

Comment utiliser ce guide en tant que hub

Cette page est conçue de manière intentionnellement large. Utilisez‑la comme une carte de référence, puis passez aux articles plus détaillés une fois que la décision sera arrêtée.

La stratégie offrant les meilleurs rendements consiste généralement à identifier le goulot d’étranglement, à choisir la pile technologique la plus réduite capable de le mettre en évidence, benchmark avec la charge de travail réelle, puis à ajouter de la complexité uniquement là où les données le justifient.

Partie I — Fondements matériels

Les concepts présentés ici — l’intensité arithmétique, la hiérarchie mémoire GPU, ainsi que les termes relatifs au matériel — apparaissent également dans toutes les autres sections de ce guide.

1. Problèmes liés à la mémoire contre problèmes liés aux calculs et le modèle roofline

Le point de départ pour évaluer les performances de LLM est l’intensité arithmétique : pour chaque octet de données que le GPU charge depuis la mémoire, combien de calculs utiles effectue-t-il ? Ce rapport détermine si une opération est limitée par le calcul (en attente du processeur) ou limitée par la mémoire (en attente du chargement des données).

Chaque GPU possède un seuil d’« intensité critique » au-delà duquel sa capacité de calcul atteint précisément l’équilibre avec sa bande passante mémoire. Dans le cas d’une NVIDIA H100 (Fiche technique, 2023):

$\frac{989 \text{ TFLOPS}}{3,35 \text{ TB/s}} \approx 295 \text{ FLOPs/byte}$

Les deux phases de l’inférence LLM se situent de part et d’autre de ce seuil :

• La décodage est limitée par la mémoire. La génération des tokens un par un implique le chargement de la matrice de poids de plusieurs gigaoctets depuis la mémoire afin de l’appliquer à un seul nouveau token. Dans une analyse simplifiée en 16 bits et en lot d’un seul élément, cette opération représente environ 1 FLOP/byte, soit près de 300 fois moins que la limite théorique du H100. Cet écart explique pourquoi le décodage ne peut pas atteindre sa vitesse de traitement maximale dans ce cadre.
• Prefill est limité par les capacités de calcul. Le traitement de l’entrée prompt charge les poids une seule fois, mais les applique simultanément à des centaines ou des milliers de tokens. L’intensité de calcul dépasse largement 295, ce qui sature les unités de traitement.

Afin d’accélérer le décodage, il convient de travailler sur la bande passante mémoire : réduire la taille des poids avec quantification, réduire la charge mémoire KV grâce à GQA et PagedAttention, et augmenter l’intensité avec Grouper les opérations en lots. Afin d’accélérer prefill, il convient de se concentrer sur les calculs bruts : des opérations de GPUs et de FP8 plus rapides.

2. Hiérarchie mémoire GPU

Un GPU dispose de quatre couches mémoire disposées en forme de pyramide : une mémoire principale volumineuse mais lente (HBM) en bas, et des registres de petite taille mais extrêmement rapides en haut. Le transfert de données vers le haut ou vers le bas de cette pyramide constitue le principal goulot d’étranglement. Le point le plus critique se situe entre HBM et la SRAM, celle-ci étant approximativement 10 fois plus rapide.

De la vitesse la plus élevée à la plus faible sur une H100 :

1. Registres — la mémoire la plus rapide, connectée directement aux threads de traitement. C’est ici que les calculs se déroulent réellement ; les données doivent y être chargées afin que les Tensor Cores puissent les utiliser.
2. SRAM (mémoire partagée) — la mémoire de travail avec une vitesse d’environ 33 TB/s.
3. Cache L2 — une couche intermédiaire (50 MB) offrant une bande passante d’environ 12 TB/s. Il agit comme un tampon permettant aux différents SMs qui ont besoin des mêmes poids de ne pas tous devoir les récupérer depuis HBM.
4. HBM3 — la mémoire principale de 80 GB qui stocke les poids du modèle ainsi que KV cache, avec une bande passante d’environ ~3,35 TB/s.

FlashAttention, la fusion de noyaux, ainsi que PagedAttention, permettent toutes de réduire le trafic entre ces couches. Elles conservent les données plus longtemps dans de la SRAM rapide et évitent des transferts répétés vers HBM.

3. Glossaire matériel GPU

Les termes ci‑dessous apparaissent tout au long du reste du guide.

HBM (Mémoire à large bande passante) — Celles-ci sont constituées de dies DRAM empilés et reliés par des vias à travers le silicium (TSVs), montés directement sur le package à côté du die GPU. Générations : HBM2e (A100, 2 TB/s), HBM3 (H100, 3,35 TB/s), HBM3e (H200/B200, 4,8–8 TB/s). Cela est important pour LLMs car la décodage est limitée par la bande passante mémoire ; par conséquent, la bande passante de HBM détermine directement le TPOT.

GDDR (Graphics DDR) — Mémoire graphique traditionnelle (GDDR6, GDDR6X) utilisée dans les cartes graphiques grand public GPUs (RTX 4090, L40S). Sa bande passante est inférieure à celle de HBM, mais son coût par Go est plus faible. Le GDDR6X sur RTX 4090 Il atteint environ 1 TB/s, contre 3,35 TB/s pour le HBM3 de l’H100.

SM (Streaming Multiprocessor) — L’unité de calcul de base des cartes NVIDIA GPUs. Chaque SM intègre des cœurs CUDA, des Tensor Cores, une mémoire partagée (SRAM) ainsi qu’un planificateur de warp. H100 dispose de 132 SMs; L’A100 dispose de 108.

Tensor Cores — Unités spécialisées pour les multiplications matricielles et accumulations intégrées à l’intérieur de chaque SM. Elles accélèrent les multiplications matricielles en précision mixte (FP16, BF16, FP8, INT8), qui constituent le cœur des calculs sur les transformateurs. Les Tensor Cores du H100 offrent 989 TFLOPS en TF32 contre environ 67 TFLOPS uniquement grâce aux cœurs CUDA.

CUDA Cœurs — Unités à virgule flottante et entières à usage général. Elles gèrent les opérations élément par élément, les fonctions d’activation ainsi que les tâches autres que les multiplications matricielles. Les Tensor Cores assument la majeure partie du travail pour LLMs ; les CUDA cœurs s’occupent de tout le reste.

Warp — Un groupe de 32 fils qui s’exécutent en synchronisation sur un SM. C’est la plus petite unité de planification chez NVIDIA GPUs. Spécialisation par courbure Il attribue des déformations différentes aux différentes tâches (chargement de données et calcul) afin de mettre en œuvre une chaîne de traitement.

NVLink — Interconnexion à haute vitesse GPU-à-GPU au sein d’un nœud. NVLink 4.0 (H100) offre 900 GB/s en mode bidirectionnel ; NVLink 5.0 (B200) atteint 1,8 TB/s. Il est indispensable pour le parallélisme tensoriel, où GPUs doit échanger les activations à chaque couche.

InfiniBand — Structure réseau à haute vitesse destinée à la communication entre nœuds GPU. NVIDIA ConnectX-7 Il offre 400 Gb/s par port. Il est utilisé pour assurer le pipeline de parallélisation ainsi que l’entraînement distribué entre les nœuds.

RDMA (Accès direct à la mémoire à distance) — Permet à un GPU de lire/écrire dans la mémoire d’un autre ordinateur sans faire intervenir le CPU, ce qui réduit au minimum la latence. GPUDirect RDMA Permet des transferts directs de GPU vers GPU entre nœuds. Il est utilisé dans les serving déagrégués pour les transferts de KV cache.

NVMe (Non-Volatile Memory Express) — Interface SSD à haute vitesse utilisée pour le déchargement de KV cache ZeRO-Infinity Le transfert de paramètres en arrière-plan lorsque la mémoire GPU/CPU est insuffisante. Les vitesses de lecture séquentielle atteignent 5 à 7 GB/s par disque (PCIe Gen 4), tandis que les modèles plus récents de Gen 5 permettent des débits allant de 10 à 14 GB/s.

TFLOPS / PFLOPS — Opérations en virgule flottante par seconde au niveau téra/péta. 1 TFLOPS équivaut à 10¹² FLOPS. C’est l’unité de référence utilisée pour mesurer le débit de calcul de GPU. La carte H100 atteint 989 TFLOPS en mode TF32 ; FlashAttention-3 réalise quant à elle environ 1,2 PFLOPS en FP8.

Partie II — Fondements de l’inférence

L’inférence correspond à la partie du système que perçoivent réellement les utilisateurs. La latence, le KV cache, le modèle d’exécution en deux phases, l’attention ainsi que la quantification jouent un rôle déterminant dans le fait de déterminer à quelle vitesse, à quel coût et avec quelle fiabilité le service peut être fourni.

4. Latence : TTFT, TPOT et pourcentiles

Temps jusqu’au premier token (TTFT) désigne le délai entre la soumission de la requête et l’apparition du premier token de sortie. Ce temps est déterminé par la phase prefill : le modèle doit traiter l’intégralité du prompt avant de pouvoir générer quoi que ce soit, de sorte qu’un prompts plus long entraîne généralement une augmentation du TTFT. Les objectifs associés varient en fonction du produit ; MLPerf Inference v5.0 Il utilise une limite P99 TTFT de $\leq$ 450 ms pour son scénario interactif Llama 2 70B.

Temps par token de sortie (TPOT) désigne l’intervalle moyen entre les tokens consécutifs à partir du premier. Ce paramètre correspond à la phase de décodage, durant laquelle chaque étape est limitée par la bande passante mémoire :

$\text{TPOT} = \frac{\text{Latence E2E} - \text{TTFT}}{\text{Tokens de sortie} - 1}$

La vitesse moyenne de lecture silencieuse d’un adulte anglophone est d’environ 238 mots par minute pour du texte de non-fiction.Brysbaert, 2019). Les cibles de streaming doivent toujours être déterminées à partir des tests de produit ; MLPerf impose une limite P99 TPOT de $\leq$ 40 ms pour son scénario interactif.

La latence P50 versus P99 est importante, car la médiane masque les valeurs extrêmes. Un système présentant une bonne valeur P50 mais une mauvaise valeur P99 peut souffrir de problèmes liés au regroupement des opérations, à la préemption, à la file d’attente ou à une répartition inégale des charges de travail ; des traces d’exécution sont nécessaires pour les distinguer.

5. Débit : tokens par seconde et le compromis latence/débit

Le débit est mesuré en tokens de sortie par seconde pour les requêtes simultanées. Le nombre de requêtes par seconde n’est pas suffisant à lui seul, car une réponse de 10 tokens et une réponse de 1 000 tokens ont des coûts très différents. Les valeurs publiées pour benchmark varient en fonction du modèle, de la précision, du matériel, de prompt et de la longueur de la sortie, ainsi que du niveau de concurrence et des objectifs de service. Comparez vLLM, SGLang, et TensorRT-LLM en utilisant un seul harness au lieu de combiner leurs résultats principaux.

Le compromis : à une faible concurrence, chaque requête présente une latence élevée, mais le GPU n’est pas suffisamment exploité. L’augmentation de la taille des lots améliore le débit de manière presque linéaire jusqu’à saturation des ressources de calcul, après quoi la latence augmente fortement. Le Goodput, c’est‑à‑dire la fraction de requêtes qui respectent les objectifs SLO, est la métrique qui relie le débit brut à la satisfaction réelle des utilisateurs.

6. KV cache : le goulot d’étranglement à l’origine de la plupart des autres goulots d’étranglement

Lors de la génération auto-régressive, chaque nouveau token prend en compte tous les tokens précédents. Le KV cache stocke les projections de clé et de valeur de chaque token à chaque couche, afin d’éviter une recomputation de complexité $O(n^2)$. Sans lui, générer le token $n$ nécessiterait de faire fonctionner à nouveau le modèle sur l’ensemble des $n-1$ tokens précédents.

Le KV cache représente généralement la principale source de contrainte mémoire, car sa croissance est linéaire en fonction de la longueur de la séquence, de la taille du lot et du nombre de couches :

$KVcache = 2 \times L \times h_{kv} \times d_h \times s \times B \times \text{octets}$

où :

• $L$ = nombre de couches
• $h_{kv}$ = nombre de têtes KV
• $d_h$ = dimension de la tête
• $s$ = longueur de la séquence
• $B$ = taille du lot

Des exemples concrets avec FP16 et une taille de lot de 1 : Llama 3 8B gère 8 192 tokens et consomme environ 1,0 GB de KV cache ; pour 128 K tokens, la consommation monte à 16 GB. Llama 3 70B, quant à lui, nécessite environ 40 GB pour traiter une seule séquence, ce qui représente la moitié de la mémoire VRAM d’une carte H100. Lorsque l’on utilise des tailles de lot typiques en production, KV cache dépasse facilement la capacité de mémoire dédiée au poids du modèle. Les implémentations naïves gaspillent 60–80 % de la mémoire KV allouée en raison de la fragmentation, ce qui constitue un problème majeur. PagedAttention a été conçu pour résoudre.

Les principales optimisations consistent en GQA (moins de têtes KV), quantification KV cache (FP8/INT8), PagedAttention (allocation basée sur des blocs avec moins de <4 % de gaspillage)), ainsi que le transfert de KV cache vers CPU ou NVMe.

7. Prefill versus decode : deux phases, deux goulets d’étranglement

La phase prefill traite l’entrée prompt en parallèle et remplit le KV cache. Les grosses multiplications matricielles qu’elle implique en font une opération fortement limitée par les calculs, de sorte que prefill détermine dans une large mesure le temps nécessaire pour obtenir le premier token (TTFT). La phase de décodage génère un token à la fois. À chaque étape, elle lit les poids du modèle ainsi que le KV cache HBM, rendre la décodage soumise à la bande passante mémoire le principal facteur limitant le temps par token de sortie (TPOT).

Le traitement par blocs prefill divise le prompt en blocs de taille fixe (par exemple, 512 tokens) au lieu de le traiter entièrement d’un seul coup. Un prefill trop long ne bloque plus les demandes de décodage en cours, les tâches gourmandes en calcul et en mémoire peuvent être planifiées simultanément sur le même GPU, ce qui permet aux vLLM benchmarks d’atteindre un taux de productivité accru de +50 %.Agrawal et al., 2024). Le coût est légèrement plus élevé pour la nouvelle demande TTFT.

Décomposition serving des prefill permet leur décodage dans des pools GPU distincts, ce qui autorise chaque pool à cibler un goulot d’étranglement différent. Splitwise et DistServe Décrivez ce schéma. Les pools transfèrent les données du cache KV via une interconnexion rapide telle que RDMA, Ainsi, le coût de communication fait partie intégrante de la conception.

8. GQA et MQA : réduction de la taille de KV cache

Standard Attention à plusieurs têtes (MHA) Chaque tête de requête reçoit sa propre tête K et V. Attention multi-requête (MQA) Il partage une seule tête KV entre toutes les têtes de requête, ce qui représente une réduction extrême. Attention à requête groupée (GQA) Il s’agit d’une solution intermédiaire pratique : des groupes de têtes de requête partagent une seule tête KV.

Llama 3 70B fait appel à 64 têtes de requête mais seulement 8 têtes KV, ce qui représente une réduction de 8x KV cache par rapport à une architecture où chaque tête de requête disposait d’une tête KV. Llama 3.1 405B utilise quant à lui 128 têtes de requête et 8 têtes KV, soit une réduction de 16x selon le même calcul.Meta, 2024). Ainslie et al. indiquent que la qualité atteinte par GQA est proche de celle de MHA dans les modèles qu’ils ont testés, tout en approchant la vitesse offerte par MQA. Un KV cache plus petit permet de gérer des lots plus importants, mais les gains en latence et en débit restent dépendants du noyau ainsi que du type de travail à traiter.

9. Quantification : échanger des bits contre de la vitesse et de la mémoire

La quantification diminue la précision des poids et/ou des activations du modèle. Les principaux compromis :

AWQ (La quantification des poids sensibles à l’activation) permet d’identifier les <1 % de poids les plus importants en analysant les valeurs d’activation, puis applique une mise à l’échelle par canal afin de les protéger. Elle ne nécessite que de 128 à 1 024 tokens de calibration et a remporté le prix du meilleur article lors de la conférence MLSys 2024. GPTQ Il fait appel aux informations du Hessien de deuxième ordre pour une quantification par couche et nécessite davantage de données de calibration. bitsandbytes (La bibliothèque de Tim Dettmers) effectue la quantification lors du chargement du modèle sans étape de prétraitement distincte ; son format NF4 permet d’alimenter QLoRA fine-tuning. Le FP8 sur des matériels de type Hopper réduit la mémoire nécessaire pour stocker les poids par rapport à FP16/BF16, mais la qualité et la vitesse dépendent néanmoins du modèle, de la calibration ainsi que du noyau utilisé.

Le noyau serving peut avoir autant d’importance que l’algorithme de quantification. Dans la comparaison évoquée ci-dessus Section 10, Les mêmes poids quantisés présentent une différence de 2,6 fois en termes de débit de traitement entre les différents noyaux.

Partie III — Optimisations de l’inférence

Cette section porte sur les techniques logicielles permettant de transformer un système d’inférence fonctionnel en un système rapide. Chacune d’elles cible un goulot d’étranglement spécifique : FlashAttention exploite l’écart entre la SRAM et HBM, PagedAttention élimine la fragmentation de KV cache, tandis que le lotage continu maintient GPU actif.

10. Les noyaux CUDA et la fusion de noyaux

Un CUDA kernel est une fonction écrite pour le GPU qui s’exécute en parallèle sur des milliers de threads. Lorsque le CPU appelle un kernel, le GPU répartit les tâches entre eux. SMs: Chaque SM exécute plusieurs tours de travail comprenant 32 cœurs, et chaque cœur traite une portion des données. Toute opération lors de l’inférence LLM, que ce soit la multiplication matricielle ou l’échantillonnage de tokens, se résume en fin de compte à un lancement de noyau. Une seule passe avant dans un modèle de 70 milliards de paramètres déclenche des centaines voire des milliers de lancements de noyaux, et la différence entre un noyau naïf et un noyau optimisé peut déterminer si votre système respecte ses objectifs de latence prévus.

Les principales catégories de noyau dans LLM serving :

• Les noyaux GEMM pour la multiplication matricielle, qui dominent à la fois les opérations prefill et le traitement de décodage.
• Les noyaux d’attention tels que FlashAttention, qui organisent les calculs en blocs afin de rester dans SRAM au lieu de se répandre vers HBM.
• Noyaux fusionnés qui combinent plusieurs opérations (telles que l’addition + la norme de couche ou la projection QKV) en une seule exécution afin d’éviter les allers-retours intermédiaires HBM.
• Noyaux de sampling qui convertissent les logits en identifiants de tokens grâce au sampling top-k, top-p ou à la température.

La qualité du noyau importe souvent davantage que l’algorithme de quantification. Les mêmes poids quantifiés avec INT4 sont distribués via Marlin (un noyau FP16xINT4 optimisé) atteint 712 tokens/s, contre 276 tokens/s pour la version GPTQ classique, soit une différence de 2,6 fois en termes de débit, uniquement grâce à une meilleure utilisation des GPU. Marlin parvient à ce résultat grâce à des récupérations mémoire asynchrones ainsi qu’à des files d’attente en mémoire partagée qui alimentent constamment les Tensor Cores, évitant ainsi l’attente liée aux HBM. Triton Il abaisse la barrière à l’écriture de noyaux personnalisés en permettant de programmer via GPU à l’aide de Python plutôt qu’en utilisant directement le CUDA C++ brut, ce qui rend les optimisations au niveau du noyau accessibles aux ingénieurs ML et non uniquement aux spécialistes GPU. La plupart des optimisations présentées plus loin dans cette section (FlashAttention, noyaux fusionnés, PagedAttention) consistent essentiellement soit en de meilleurs noyaux, soit en des méthodes plus intelligentes pour orchestrer le lancement des noyaux.

La fusion de noyaux combine des opérations séquentielles en un seul noyau GPU et élimine les écritures intermédiaires HBM. Les fusions les plus courantes comprennent la projection QKV, l’attention associée à softmax, ainsi que l’opération addition suivie de RMSNorm.FlashNorm), et l’activation SwiGLU**DeepFusionKernel**). Triton Permet d’ rendre ces noyaux accessibles depuis Python. Les gains précis en termes de nombre d’exécutions et d’utilisation dépendent du graphe du modèle, du compilateur, de GPU, ainsi que de serving et framework ; il convient donc d’analyser en profondeur la pile déployée plutôt que de se fier à un pourcentage universel.

11. FlashAttention : attention en mosaïque pour être stockée en SRAM

La mécanique d’attention standard matérialise l’ensemble de la matrice d’attention $N \times N$ dans HBM, ce qui entraîne une consommation mémoire de $O(N^2)$ et génère un fort trafic mémoire. L’idée sous-jacente à FlashAttention est de ne jamais matérialiser cette matrice du tout. Elle divise les matrices Q, K et V en blocs adaptés pour tenir dans SRAM, Il calcule une attention partielle au sein de chaque tuile, puis fusionne les résultats à l’aide d’une fonction softmax en ligne (en enregistrant de manière incrémentale la valeur maximale et la somme cumulées sur les blocs). La mémoire consommée passe de $O(N^2)$ à $O(N)$, et la consommation en HBM diminue d’un ordre de grandeur.

Chaque version vise le goulot d’étranglement de sa génération GPU :

• FlashAttention v1 (A100, 2022) a démontré que l’approche basée sur le tiling combiné au softmax en ligne fonctionne efficacement. On observe une accélération de 2 à 4 fois par rapport à l’attention classique, mais une utilisation seulement de 25 à 40 % GPU, car le planification des noyaux laisse de nombreux SM inactifs. FlashAttention v2 (A100, 2023) a réorganisé le parallélisme afin de le répartir sur la dimension séquentielle plutôt que sur les lots et les têtes de réseau. Il a atteint une utilisation de 50 à 73 % sur l’A100, soit environ deux fois plus rapide que la version v1.
• FlashAttention v3 (H100 Hopper, 2024) intègre désormais une spécialisation des warps (des warps distincts pour le déplacement des données et les opérations mathématiques) ainsi qu’un pipeline GEMM-softmax afin de superposer les chargements en mémoire aux calculs. On observe une utilisation de 75 à 85 % sur l’H100, avec des performances allant jusqu’à ~1,2 PFLOPS dans FP8. En vedette au NeurIPS 2024. FlashAttention v4 (B200 Blackwell, 2026) aborde un nouveau goulot d’étranglement : sur Blackwell, le débit des cœurs tensoriels augmente à un rythme si rapide que les opérations autres que les matmul (exponentielles softmax, rééchellement) deviennent le facteur limitant. Le logiciel FA4 émule ces fonctions exponentielles au moyen d’approximations polynomiales sur les unités FMA, recourt à un rééchellement conditionnel afin de réduire la charge supplémentaire, et stocke les intermédiaires dans la mémoire tensorielle dédiée de Blackwell (TMEM) plutôt que dans des registres. Le résultat est de 1 605 TFLOPS/s sur le B200 dans BF16, soit 1,3 fois plus rapide que cuDNN 9.13 et 2,7 fois plus rapide que Triton.

Chaque génération rencontrait une limite matérielle différente, et chaque version de FlashAttention était redessinée en partant du noyau afin de surmonter ce problème.

12. FlashDecoding : parallélisation du goulot d’étranglement de décodage

La version standard FlashAttention maintient GPU occupé en répartissant le travail entre la taille du lot et la longueur de la requête. Lors de la décodage, le modèle génère un seul token à la fois (longueur de la requête = 1). Si le produit de la taille du lot par le nombre de têtes d’attention est inférieur au total des unités SM de GPU (108 sur une A100), la plupart des GPU restent inactives, tandis que quelques unités traitent séquentiellement l’historique des tokens.

FlashDecoding Il résout ce problème en ajoutant une nouvelle dimension de parallélisation : la longueur même de la séquence KV. Cette approche divise la KV cache en blocs plus petits et les distribue à tous les processeurs GPU qui seraient sinon inactifs afin d’effectuer des calculs en parallèle, avant de fusionner leurs résultats partiels au moyen d’une réduction log-sum-exp.

Le résultat se traduit par un accélération de 8 fois en termes de vitesse de décodage bout en bout pour les séquences longues (contexte de 64 K), avec un temps de décodage par token restant globalement constant. La génération du token 60 000 reste presque aussi rapide que celle du token 100.

13. Groupeage continu versus groupeage statique

Le batching statique attend que toutes les séquences d’un lot soient terminées avant de lancer la suivante, ce qui fait que les séquences courtes gaspillent des cycles GPU en état d’inactivité une fois arrivées à la fin de la séquence. Le batching continu (introduit par le Article Orca, (OSDI 2022) fonctionne à une granularité au niveau de l’itération : à chaque étape de décodage, les séquences terminées sont supprimées et de nouvelles séquences y sont insérées.

Dans le modèle OPT-13B d’Anyscale benchmark, le lotage statique optimisé a permis d’atteindre un rendement 4 fois supérieur à celui de la méthode de base naïve, tandis que le lotage continu a atteint un rendement 8 fois supérieur ; en combinant le lotage continu avec PagedAttention, vLLM a atteint un rendement de 23 fois supérieur (Anyscale, 2023). Le lotage continu exerce également une pression accrue sur l’allocation des tables KV, d’où sa combinaison fréquente avec une gestion de la mémoire paginée.

14. PagedAttention : mémoire virtuelle pour KV cache

le PagedAttention de vLLM Il applique le principe de la mémoire virtuelle du système d’exploitation à la gestion de KV cache. Le KV cache est divisé en blocs de taille fixe (généralement 16 tokens) ; ces blocs sont alloués sur demande au fur et à mesure que des tokens sont générés, et les positions logiques (successives) correspondent à des emplacements mémoire physiques (dispersés) grâce à des tables de blocs. Plusieurs requêtes partageant un préfixe (system prompts, recherche par faisceau) peuvent faire référence aux mêmes blocs physiques.

Les systèmes précédents gaspillaient 60–80 % de la mémoire KV cache en raison de la fragmentation et des allocations préalables. Les solutions PagedAttention réduisent cette proportion à <4 %, ce qui permet d’augmenter le débit de 2 à 4 fois tout en maintenant la même latence, voire jusqu’à 24 fois par rapport à HuggingFace Transformers.vLLM Blog, 2023).

15. Décodage spéculatif : plusieurs tokens par passe avant

Un petit modèle de draft génère $K$ tokens candidats, puis le grand modèle cible vérifie l’ensemble de ces $K$ tokens en une seule passe forward. Les tokens corrects sont acceptés, tandis que le premier token incorrect est rejeté. La qualité du résultat est mathématiquement identique à celle obtenue avec le modèle cible seul, ce qui constitue donc un accélération sans perte de qualité.

Il fonctionne parce que la décodage de LLM est limité par la bande passante mémoire : vérifier $K$ tokens coûte à peu près autant que de générer 1 token, étant donné que dans les deux cas tous les poids du modèle doivent être chargés une seule fois. Les gains de performance typiques se situent entre 1,5x et 3x, avec des méthodes telles que EAGLE-3 jusqu’à 6,5 fois. Les variantes comprennent Medusa (des têtes de prédiction supplémentaires, sans modèle distinct), une décodage par recherche prompt (correspondance de n-grammes avec l’entrée, libre), ainsi que EAGLE (extrapolation au niveau des caractéristiques).

Lorsque la taille des lots est élevée, les tâches supplémentaires de rédaction préliminaire et de vérification peuvent annuler les avantages obtenus ; un rapport d’évaluation cité indique une ralentissement de 1,4 à 1,8 fois dans ce cas de figure. La décodage spéculatif s’avère le plus prometteur lorsque le lot serving est suffisamment petit et que le taux d’acceptation des versions préliminaires est élevé.

16. Mémorisation des préfixes et réutilisation de KV cache

Au lieu de jeter le KV cache une fois qu’une requête est terminée, le cachage préfixé le conserve afin de pouvoir le réutiliser pour de nouvelles requêtes qui partagent les mêmes tokens de préfixe. Cela réduit les prefill redondants liés aux system prompts, aux exemples à faible quantité d’exemples, au RAG contextuel, ainsi qu’à l’historique des conversations à plusieurs tours.

Cache automatique des préfixes de vLLM SGLang : RadixAttention Il gère un arbre de radicale contenant des tenseurs KV en mémoire cache, avec une granularité au niveau des tokens. Comme ces deux approches dépendent de préfixes identiques sur plusieurs tokens, il est nécessaire de communiquer le taux de hits en même temps que la latence ou le débit.

17. Le streaming en pratique

Transfert en flux continu envoie les tokens au client dès leur génération, sans attendre la réponse complète. De nombreux serving frameworks le rendent disponible via des Server-Sent Events : le client établit une connexion HTTP à long terme, et le serveur envoie chaque token ou lot de tokens progressivement. data: Événement. TTFT permet de déterminer le moment où l’utilisateur voit pour la première fois une sortie ; TPOT aide à évaluer le degré de fluidité perçue. La valeur cible est fixée à travers des tests produits ainsi que selon le modèle d’interaction retenu.

Du côté du client, le streaming impose des décisions de mise en mémoire tampon. Le rendu token par token peut provoquer des fluctuations visuelles, en particulier avec du Markdown ou des blocs de code qui nécessitent un contexte composé de plusieurs tokens pour être formatés correctement. Les approches courantes consistent en une mémoire tampon au niveau des mots (accumuler les tokens jusqu’à la limite d’un espace insécable), une mémoire tampon au niveau des lignes (attendre un saut de ligne avant de rendre), ainsi qu’une mémoire tampon adaptative (rendre immédiatement le texte narratif et mettre en mémoire tampon les blocs de code). stream_options: {"include_usage": true} Le paramètre APIs compatible avec OpenAI renvoie le nombre de tokens présents dans l’événement SSE final, ce qui permet un suivi précis des coûts pour les réponses diffusées en continu.

Chunké prefill C’est ce qui permet au streaming de résister à la charge. Sans cela, une seule requête prefill longue et volumineuse peut bloquer la livraison des tokens pour tous les autres utilisateurs en parallèle.

Partie IV — Architecture du modèle

Comment sont construits les LLMs : le bloc Transformer, la tokenisation, la gestion du contexte, ainsi que les variantes architecturales devenues par défaut. Ceux-ci constituent la base tant pour l’inférence que pour l’entraînement.

18. Fondamentaux de l’architecture Transformer

Un transformeur moderne exclusivement décodant (GPT, Llama) est une pile de couches identiques, chacune comprenant deux sous-blocs : attention et feed-forward. Chaque sous-bloc est entouré d’une connexion résiduelle ainsi que d’une opération de normalisation. Les composants clés :

Multi-Head Attention — mécanisme qui permet à chaque token d’examiner tous les autres tokens afin de déterminer ce qui est pertinent. L’entrée est projetée dans trois matrices : Queries (quoi cherche-t-on ?), Keys (quoi contiens-je ?) et Values (quelles informations transporte-je ?). Les scores d’attention sont ensuite calculés comme suit :

$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$

Le produit scalaire $QK^T$ permet d’évaluer la similarité entre chaque paire de tokens. En le divisant par $\sqrt{d_k}$, on évite que les produits scalaires ne deviennent trop importants (ce qui entraînerait le softmax dans des régions où les gradients tendent vers zéro). Le softmax convertit ces scores en probabilités, et la multiplication par $V$ génère une combinaison pondérée des vecteurs de valeurs. En exécutant cette opération en parallèle sur plusieurs têtes, le modèle peut prendre en compte différentes relations simultanément (une tête pour la syntaxe, une autre pour la co-référence, etc.).

Réseau feed-forward (FFN) — une fois que l’attention a déterminé quels tokens sont pertinents, le FFN décide que faire de ces informations. Les architectures modernes LLMs utilisent SwiGLU au lieu de la FFN ReLU à deux matrices originale :

$\text{SwiGLU}(x) = \text{Swish}(xW_1) \otimes xW_2$

SwiGLU fait appel à trois matrices de poids au lieu de deux, ainsi qu’à une fonction d’activation Swish lisse à la place de ReLU. Il est utilisé par des familles de modèles telles que Llama, Mistral, Qwen et Gemma. La couche FFN représente généralement environ les deux tiers des paramètres totaux du modèle, bien que cette proportion varie en fonction de l’architecture.

Connexions résiduelles — chaque sous-bloc ajoute sa sortie à son entrée : $\text{Sortie} = \text{Entrée} + \text{Sous-couche}(\text{Entrée})$. Sans cette connexion de saut, les gradients disparaissent lors de la rétropropagation à travers 80–128 couches. La connexion résiduelle crée un chemin permettant aux informations et aux gradients de circuler directement des couches précoces vers les couches tardives.

RMSNorm — est couramment utilisé dans les familles modernes de LLM. LayerNorm effectue la normalisation en centrant à nouveau les données (en soustrayant la moyenne) et en rééchelonnant leurs valeurs (en les divisant par l’écart type). RMSNorm Il omet la soustraction de la moyenne et se contente de rééchelonner les valeurs ; l’article correspondant indique des accélérations allant de 7 à 64 % sur les modèles testés, sans aucune perte de performances dans ces expériences. La méthode de pré-normalisation, qui normalise les données avant l’attention ou le FFN, est également fréquemment utilisée, car elle améliore la stabilité des gradients.

Estimation du nombre de paramètres pour un modèle décodeur uniquement :

$\text{Total} \approx V \times d + 12 \times L \times d^2$

où $V$ représente la taille du vocabulaire, $d$ la dimension cachée, et $L$ le nombre de couches. Le terme $V \times d$ correspond à la matrice d’entrée embedding ; le terme $12 \times d^2$ est utilisé pour approximer les poids d’attention ainsi que ceux des fonctions FFN dans chaque couche. Pour Llama 3 8B ($V=128{,}256$, $d=4{,}096$, $L=32$), l’estimation s’élève à environ $0{,}53B + 6{,}44B = 6{,}97B$ de paramètres. La valeur totale publiée de 8,03B est plus élevée, car cette approximation omet des détails architecturaux tels que la largeur exacte des fonctions FFN et la projection de sortie distincte.

19. Pourquoi les architectures à décodage uniquement dominent

Le document d’origine Transformateur En 2017, ces modèles disposaient à la fois d’un encodeur et d’un décodeur. Depuis lors, le domaine s’est divisé en trois familles architecturales, l’une d’entre elles devenant la solution par défaut pour les systèmes génératifs AI.

Les modèles uniquement encodeurs (BERT, RoBERTa) utilisent une attention bidirectionnelle : chaque token prête attention à tous les autres tokens dans les deux sens. Cela permet d’obtenir des représentations riches pour les tâches de compréhension (classification, NER, similarité sémantique), mais ils ne peuvent pas générer de texte de manière autoregressive. Les modèles uniquement encodeurs restent néanmoins dominants en tant que composant central pour embedding modèles, rerankers, ainsi que des classificateurs légers (par exemple, les routeurs basés sur BERT dans RouteLLM).

Les modèles encoder-decoder (T5, BART, le Transformer original) séparent la compréhension de la génération. L’encodeur traite l’entrée complète à l’aide d’une attention bidirectionnelle, puis le décodeur génère la sortie de manière autoregressive en prenant en compte les représentations de l’encodeur via une cross-attention. Cette approche présente un avantage naturel pour les tâches séquence à séquence telles que la traduction, où l’entrée et la sortie sont fondamentalement des séquences différentes. Le modèle T5 de Google a démontré qu’il était possible de formuler n’importe quelle tâche de NLP comme une transformation texte en texte, et les modèles encoder-decoder continuent d’alimenter certains systèmes spécialisés (Whisper pour la reconnaissance vocale, FLAN-T5 pour le suivi d’instructions).

Les modèles seulement décodeurs (GPT, Llama, Mistral, Gemini) emploient une attention causale (unidirectionnelle) : chaque token ne prête attention qu’aux tokens précédents. Ils structurent tout en prédiction du token suivant : l’« entrée » correspond au début de la séquence, tandis que la « sortie » en est la continuation. Voici quatre raisons pour lesquelles cette architecture a prévalu :

1. KV cache d’efficacité. Le KV cache provenant des tokens précédents reste valide tant que de nouveaux tokens sont générés, ce qui vous évite de devoir le supprimer ou de le recalculer. Les modèles encodeur-décodeur doivent gérer deux caches d’attention distincts (auto-attention ainsi que cross-attention sur la sortie de l’encodeur), ce qui augmente la consommation mémoire et complique l’architecture.

2. Simplicité de l’entraînement. L’objectif d’entraînement consiste en une simple prédiction du token suivant à partir de texte brut. Aucune paire de données entrée-sortie (comme c’est le cas pour les modèles de traduction) ni reconstruction de tokens masqués (comme le nécessite BERT) n’est requise. Il est possible d’entraîner sur pratiquement n’importe quel texte provenant d’Internet, de livres ou de code, sans prétraitement particulier, ce qui représente un avantage majeur lorsqu’il s’agit d’augmenter la quantité de données à des trillions de tokens.

3. Simplicité architecturale. Un seul module gère l’ensemble : le même bloc transformateur, répété $L$ fois. Aucune couche d’attention croisée entre encodeur et décodeur, aucune pile d’encodeurs distincte. Cela rend les stratégies de parallélisation plus simples à mettre en œuvre (Section 33), et réduit ainsi la surface d’ingénierie à optimiser. FlashAttention, la quantification et le décodage spéculatif n’ont besoin de cibler qu’un seul schéma d’attention.

4. Apprentissage in-context. Les modèles décodeurs uniquement sont naturellement adaptés à l’apprentissage à partir de quelques exemples, car les exemples, les instructions et la requête ne sont rien d’autre que des tokens au sein de la même séquence. Le modèle ne fait pas de distinction entre « entrée » et « sortie » ; il prédit le token suivant en se basant sur tout ce qui précède. C’est GPT-3 qui a été le premier à démontrer ce phénomène à grande échelle, ce qui a rendu les modèles décodeurs uniquement particulièrement adaptés au rôle d’assistant polyvalent.

20. Mélange d’experts

MoE remplace la FFN dense présente dans chaque couche de transformateur par plusieurs FFN d’experts plus petits, ainsi que par un routeur de gestion léger. Ce routeur calcule un score pour chaque expert (généralement via une fonction softmax appliquée à des projections linéaires apprises) et sélectionne les $k$ meilleurs experts par token. Seuls les experts activés effectuent des calculs ; ainsi, un modèle peut disposer d’une capacité totale énorme tout en maintenant un coût faible par token. Il s’agit donc d’un calcul conditionnel dispersé : les paramètres totaux déterminent ce que le modèle peut représenter, tandis que les paramètres actifs déterminent le coût de son exécution.

L’expert partagé de DeepSeek-V3 est activé pour chaque token. Il fournit une représentation de base sur laquelle les experts redirigés peuvent se spécialiser.

L’entraînement de MoE présente trois problèmes récurrents : le déséquilibre de charge, l’effondrement des experts, et la surcharge liée à la communication pour parallélisme expert. Les modèles traditionnels MoE ajoutent une perte auxiliaire afin de pénaliser le routage déséquilibré, mais cette perte peut entrer en concurrence avec l’objectif principal. DeepSeek-V3 Au lieu de cela, il fait appel à des termes de biais en dehors de la rétropropagation : le système abaisse la note des experts surchargés et élève celle des experts sous-utilisés. L’article montre un meilleur équilibre dans le routage, sans avoir à sacrifier la perte auxiliaire dans sa configuration.

21. Tokenisation : BPE, SentencePiece et tiktoken

LLMs on ne voit pas de texte ; ils perçoivent plutôt des séquences d’identifiants de tokens entiers. Un tokenizer divise le texte brut en tokens (éléments sous-mots) et attribue à chacun d’eux un identifiant. Le choix du tokenizer influence la qualité du modèle, la vitesse d’inférence ainsi que l’équité multilingue.

Encodage par paire de octets (BPE) Il s’agit de l’algorithme courant. Il fusionne itérativement les paires adjacentes les plus fréquentes du corpus d’entraînement. Exemple simplifié :

1. Commencez par un vocabulaire au niveau des caractères : [l, o, w, e, r, _]
2. La paire la plus fréquente est (l, o) → fusionner avec lo → vocabulaire : [l, o, w, e, r, _, lo]
3. La paire suivante la plus fréquente est (lo, w) → fusionner avec low → Le vocabulaire est ajouté. low
4. Poursuivez jusqu’à ce que le vocabulaire atteigne la taille cible (par exemple, 128 K de tokens)

Les mots courants tels que « le » deviennent des tokens uniques, tandis que des mots rares comme « defenestration » sont divisés en fragments sous-mots. ["def", "en", "est", "ration"]Il s’agit d’un compromis entre la taille du vocabulaire et la longueur de la séquence.

Trois implémentations de tokeniseurs couvrent la plupart des cas d’usage en production :

• SentencePiece il traite l’entrée comme un flux binaire brut, sans prétraitement spécifique à une langue (pas de pré-tokenisation basée sur les espaces ou la ponctuation), ce qui en fait une approche agnostique aux langues et est particulièrement important pour les écritures non latines. Il prend en charge à la fois BPE et les unigrammes. Il est utilisé par Llama 1/2, T5 et Mistral. tiktoken Il s’agit du tokeniseur d’OpenAI basé sur Rust qui utilise un traitement au niveau des octets BPE. Son noyau compilé en Rust est 3 à 6 fois plus rapide que les alternatives basées sur Python. Llama 3 est passé de SentencePiece à l’algorithme de tiktoken.
• Hugging Face Tokeniseurs Il s’agit d’une bibliothèque largement utilisée basée sur Rust qui prend en charge BPE, WordPiece et Unigram.

La taille des vocabulaires a augmenté de manière constante, ce qui a des conséquences importantes sur l’efficacité :

Fertilité (tokens par mot) mesure l’efficacité de compression. Plus ce chiffre est bas, mieux c’est : moins de tokens signifie des séquences plus courtes, un coût inférieur et davantage de contenu qui peut tenir dans la fenêtre de contexte. En anglais, cette valeur se situe généralement entre 1,0 et 1,3 token/mot, mais les écritures non latines (chinois, japonais, coréen, arabe) peuvent présenter une valeur 2 à 4 fois plus élevée lorsqu’on utilise des vocabulaires axés sur l’anglais. Pour les utilisateurs ne parlant pas anglais, le même contenu nécessite 2 à 4 fois plus de tokens, ce qui constitue un problème persistant d’équité que des vocabulaires plus larges et mieux équilibrés ne résolvent qu’en partie.

22. Fenêtres de contexte et encodages positionnels

La fenêtre de contexte représente le nombre maximal de tokens qu’un modèle peut traiter lors d’une seule passe en avant. Elle a considérablement augmenté :

Le problème de base réside dans le fait que le mécanisme d’attention traite ses entrées comme un ensemble, et non comme une séquence. Il ne dispose d’aucune notion intégrée concernant l’ordre des mots. Sans informations positionnelles, les expressions « the cat sat on the mat » et « the mat sat on the cat » génèrent des représentations identiques. Les encodages positionnels introduisent cet ordre, permettant ainsi au modèle de savoir où se situe chaque token.

Trois approches courantes sont :

• RoPE (La position rotative Embeddings) encode la position de chaque token en faisant pivoter ses vecteurs de requête et de clé d’un angle proportionnel à cette position. Les tokens proches l’un de l’autre subissent des rotations similaires, ce qui permet à leur produit scalaire (note d’attention) de rester élevé. Les tokens éloignés subissent quant à eux des rotations très différentes, ce qui encode la distance relative. RoPE est la méthode de référence pour presque tous les LLMs modernes ouverts (Llama, Mistral, Qwen), car elle gère efficacement les positions relatives tout en étant peu coûteuse en termes de calculs.

• ALiBi (Prudence avec les biais linéaires) permet d’ignorer les modifications embedding et d’ajouter directement une pénalité aux scores d’attention : plus les deux tokens sont éloignés l’un de l’autre, plus le biais négatif est important. Aucun paramètre appris, aucune computation supplémentaire requise. Cette approche autorise une certaine extrapolation au-delà de la longueur d’entraînement, mais la qualité des résultats se dégrade de manière significative lorsque la taille du contexte dépasse deux fois celle utilisée pendant l’entraînement.

• YaRN (Une autre extension RoPE) permet d’étendre un modèle RoPE au-delà de son contexte d’entraînement. Elle regroupe les dimensions de fréquence en trois catégories et applique des facteurs de mise à l’échelle différents à chacune d’elles. Selon l’étude, ce système nécessite 10 fois moins de tokens fine-tuning ainsi que 2,5 fois moins d’itérations d’entraînement par rapport à la méthode de base basée sur l’interpolation des positions.

Partie V — Entraînement et alignement

C’est durant l’entraînement que les capacités des agents sont développées. Cette section aborde le préentraînement, les méthodes efficaces fine-tuning (LoRA, précision mixte), les lois de scalabilité ainsi que les techniques d’alignement.

23. Préentraînement, fine-tuning, et alignement

Le préentraînement consiste en une prédiction auto-supervisée du token suivant à partir d’un grand corpus. Les ressources informatiques nécessaires pour le mettre en œuvre dépassent de beaucoup plusieurs ordres de grandeur ; Llama 3 405B, Par exemple, on a utilisé $3{,}8 \times 10^{25}$ FLOPs. La apprentissage supervisé fine-tuning (SFT) permet d’adapter le modèle pré-entraîné à des données étiquetées spécifiques à une tâche. Le RLHF / RLAIF exploite des données de préférence pour influencer le comportement : un RLHF pipeline classique collecte des comparaisons, entraîne un modèle de récompense, puis optimise la politique. RLAIF remplace certains jugements humains par des retours générés à l’aide de AI.

Le calcul dépend de la taille du modèle, de la longueur de la séquence, du volume des données, de l’optimiseur ainsi que de la méthode utilisée. PPO contient également plus d’états de modèle que SFT, car une configuration typique inclut des modèles de politique, de référence, de récompense et de critique. J’ai abordé en détail le processus décisionnel complet fine-tuning framework dans LLM Fine-Tuning Guide.

24. LoRA et QLoRA : fine-tuning à efficacité paramétrique élevée

LoRA Il fige les poids pré-entraînés et introduit des matrices à rang faible trainables $A$ ($r \times k$) et $B$ ($d \times r$), de sorte que le poids mis à jour devient $W_0 + BA$. La publication LoRA a permis de réduire le modèle GPT-3 175B à environ 18 millions de paramètres trainables dans sa configuration. Le rang constitue un paramètre de réglage et non une règle déterminant la complexité de la tâche ; il doit être choisi à l’aide d’analyses de qualité et d’impact mémoire. Les adaptateurs LoRA peuvent être intégrés aux poids de base après l’entraînement, afin d’éviter la nécessité d’un chemin d’exécution distinct pour eux lors de l’inférence.

QLoRA Il charge le modèle de base avec une quantification NF4 à 4 bits pendant l’entraînement d’adaptateurs LoRA au sein de BF16. La méthode NormalFloat4 dispose de davantage de niveaux de quantification près de zéro, là où la densité des poids est la plus élevée. Cet article présente le fine-tuning d’un modèle de 65 milliards de paramètres sur une seule carte GPU de 48 Go**, et rapporte des résultats proches de ceux obtenus avec les versions à 16 bits. Ses compromis entre précision runtime et consommation mémoire sont spécifiques à l’ensemble technologique testé.

25. Entraînement en précision mixte

Chaque format à virgule flottante répartit ses bits en trois champs : le signe (toujours 1 bit), l’exposant qui définit la plage dynamique, et la mantisse qui détermine la précision. Un plus grand nombre de bits d’exposant permet une plage plus large de grandeurs représentables, tandis qu’un plus grand nombre de bits de mantisse assure des distinctions plus fines entre des valeurs proches. Les formats entiers ne disposent pas d’exposant du tout et ne représentent que des nombres entiers espacés uniformément au sein d’une plage fixe.

BF16 présente la même plage que FP32, car c’est le champ de l’exposant qui définit cette plage, et BF16 conserve les 8 bits d’exposant de FP32. En revanche, il renonce aux bits de mantisse (7 contre 23), sacrifiant ainsi de la précision afin d’obtenir une réduction de la mémoire de 2 fois, tout en évitant les problèmes de débordement et de sous-débordement qui affectent l’entraînement de FP16. FP16 ne dispose que de 5 bits d’exposant, ce qui limite sa plage à environ 65 K. Les gradients dépassent fréquemment cette valeur, d’où la nécessité, pour l’entraînement de FP16, d’une échellement de la perte : il faut multiplier la perte par une constante importante avant la rétropropagation, puis diviser les gradients par la suite. BF16 rend cet échellement de la perte inutile.

Les formats entiers sont peu utilisés dans l’arithmétique de formation principale, car la rétropropagation nécessite une large plage dynamique. Ils sont cependant fréquemment employés lors de l’inférence, où les poids figés peuvent être mappés sur des échelles calibrées. La quantification des poids INT4 permet de réduire la taille d’un modèle de 7 milliards de paramètres de près de 14 Go à 3,5 Go, en tenant compte des coûts supplémentaires liés à runtime ; il est donc essentiel d’évaluer la qualité du résultat pour le modèle et la méthode choisis.

FP8 d’entraînement sur H100 via Moteur Transformer Il fait appel à E4M3 lorsque la précision est primordiale, et à E5M2 lorsque l’étendue de la plage de valeurs est plus importante. Selon NVIDIA, cela permet d’obtenir un temps d’exécution en temps réel jusqu’à 75 % plus rapide dans une configuration de 175 milliards de paramètres testée. DeepSeek-V3 Il a fait appel à FP8 de précision mixte et a indiqué qu’environ 5,6 millions de dollars de ressources informatiques équivalentes à des frais de location avaient été nécessaires pour sa phase d’entraînement finale, sans compter les dépenses de recherche et développement ni les coûts d’infrastructure.

26. Vérification par points de gradient

Chaque couche du passage en avant génère une sortie intermédiaire désignée sous le nom d’activation :

$\text{Entrée} \rightarrow [\text{Couche 1}] \rightarrow \text{activation}_1 \rightarrow [\text{Couche 2}] \rightarrow \text{activation}_2 \rightarrow [\text{Couche 3}] \rightarrow \text{Sortie}$

En règle générale, toutes les activations doivent rester en mémoire, car la rétropropagation a besoin d’elles pour calculer les gradients. Dans le cas d’un transformateur profond, les activations stockées peuvent consommer plus de mémoire que les poids du modèle eux-mêmes.

Le gradient checkpointing échange des ressources de calcul contre de la mémoire en éliminant la plupart de ces activations et en les recomptant dynamiquement au cours de la rétropropagation. La stratégie standard (Chen et al., 2016) Il divise un réseau composé de $n$ couches en $\sqrt{n}$ segments espacés uniformément et ne conserve que l’activation de bordure de chaque segment. Ces frontières sauvegardées correspondent aux “checkpoints.” Toutes les activations intermédiaires au sein d’un segment sont immédiatement éliminées.

Lorsque le passage en arrière atteint une couche située à l’intérieur d’un segment, ses activations sont recomputées à partir de l’checkpoint le plus proche. Cela permet de réduire la mémoire d’activation de $O(n)$ à $O(\sqrt{n})$, ce qui représente en pratique une réduction de 60 à 70 %, au prix d’environ un passage en avant supplémentaire (soit une augmentation des coûts de calcul d’environ 20 à 33 %). FlashAttention applique le même principe au sein du mécanisme d’attention en s’abstenant de générer la matrice d’attention complète. Il est possible de l’activer dans HuggingFace avec gradient_checkpointing=True.

27. Étapes ZeRO de DeepSpeed

Dans le parallélisme de données classique, chaque GPU contient une copie complète des poids du modèle, des gradients ainsi que des états de l’optimiseur. Pour Adam, chaque paramètre nécessite 2 octets pour le poids FP16, 4 octets pour le poids maître FP32, 4 octets pour la vitesse d’ajustement, 4 octets pour la variance et 2 octets pour le gradient, ce qui représente 16 octets par paramètre. Un modèle de 7,5 milliards de paramètres requiert donc environ 120 Go par GPU, et chaque GPU stocke exactement les mêmes données. Sur 64 GPUs, cela correspond à 64 copies identiques de 120 Go chacune. C’est une perte considérable de ressources.

DeepSpeed ZeRO (L’Optimiseur de zéro redondance) élimine cette duplication en fragmentant ces composants sur GPUs au lieu de les répliquer :

• Étape 1 — partitionnement des états de l’optimiseur. Chaque GPU ne stocke que 1/N des états de l’optimiseur (la vitesse d’Adam et sa variance, soit 8 octets par paramètre). Lorsqu’un GPU doit mettre à jour un poids, il ne met à jour que sa partie correspondante et diffuse ensuite le résultat. La mémoire diminue ainsi de ~120 GB à ~31 GB par GPU.
• Étape 2 — partitionnement des gradients également. Les gradients (2 octets par paramètre) ne sont plus réduits intégralement vers chaque GPU. Chaque GPU reçoit uniquement la portion de gradient dont il a besoin grâce à la technique reduce-scatter. La mémoire passe ainsi à ~16 GB par GPU.
• Étape 3 — partitionnement des poids du modèle également. Chaque GPU ne contient que 1/N des poids FP16. Avant chaque passe avant ou arrière d’une couche, le GPU lance une opération all-gather afin de reconstruire temporairement l’ensemble des poids de la couche à partir de tous les autres GPUs, effectue les calculs nécessaires, puis élimine ces poids une fois utilisés. La mémoire diminue ainsi à ~1,9 GB par GPU.

Le compromis réside dans la communication. La phase 1 ajoute une charge supplémentaire minimale, la phase 2 remplace l’opération all-reduce par reduce-scatter (coût similaire), mais la phase 3 nécessite des appels all-gather avant chaque couche, tant lors des passes avant qu’après, ce qui représente environ 1,5 fois plus de volume de communication par rapport au parallélisme de données standard.

ZeRO-Infinity Il étend la phase 3 en déplaçant les états partitionnés vers de la mémoire CPU telle que la RAM ou même des SSD NVMe, ce qui permet d’entraîner des modèles comptant des billions de paramètres sur des clusters GPU limités. Le prix à payer est une forte diminution de la vitesse (la NVMe est environ 500 fois plus lente que HBM) ; c’est pourquoi ZeRO-Infinity est utilisé lorsque le modèle ne peut réellement pas tenir dans la mémoire GPU + CPU.

28. FSDP : shardage natif PyTorch

Parallélisme de données entièrement shardé (FSDP) Il s’agit de la réponse intégrée de PyTorch à DeepSpeed ZeRO-3. Il fragmente les paramètres, les gradients et les états de l’optimiseur sur des GPUs en suivant le même principe fondamental. La logique de traitement pour chaque couche repose sur une boucle simple :

1. Collecter l’ensemble des paramètres provenant de tous les GPUs (reconstruire temporairement la couche complète).
2. Calculer le passage en avant ou en arrière pour cette couche.
3. Libérer immédiatement les paramètres collectés. Chaque GPU ne conserve que sa propre partie.
4. Réduire-diffuser les gradients afin que chaque GPU n’obtienne que la tranche de gradient qui lui est attribuée.

Comme FSDP est natif de PyTorch, il s’intègre directement aux outils de débogage, aux profileurs et aux autres composants de PyTorch. torch.compile. Les performances par rapport à DeepSpeed ZeRO-3 dépendent de la politique d’emballage des paramètres, de la topologie de communication, des paramètres de décharge et de la taille du modèle ; il convient donc de les comparer sur le même cluster.

FSDP2 (2024–2025) correspond à une réécriture qui améliore torch.compile Intégration visant à améliorer la fusion des noyaux, avec prise en charge de l’entraînement via FP8 TorchAO, et simplifie le API. Tant FSDP que DeepSpeed sont accessibles via HuggingFace Accelerate, ce qui vous permet de basculer entre eux par une seule modification de configuration.

29. Lois de scaling et le piège de Chinchilla

Échelle de Chinchilla (DepthMind, 2022) a identifié, dans le cadre de ses hypothèses, une allocation optimale en termes de ressources informatiques correspondant à environ 20 tokens d’entraînement par paramètre. Cet objectif ne prend pas en compte le coût associé aux étapes ultérieures liées à serving. Si un modèle plus petit, entraîné sur davantage de données, atteint la qualité requise, son utilisation peut s’avérer moins coûteuse tout au long d’un cycle de déduction à grande échelle.

La solution consiste à surapprendre des modèles plus petits à partir de quantités de données bien plus importantes. La progression est frappante :

Pour un modèle mis en production à grande échelle, consacrer plus de ressources de calcul pour l’entraînement à un modèle de taille réduite peut permettre de réduire les coûts tout au long de son cycle de vie. Llama 3 8B illustre cette stratégie, mais le fait qu’elle soit avantageuse dépend de la qualité requise ainsi que du volume prévu d’inference. L’expression « optimal pour Chinchilla » fait référence à l’efficacité en termes de ressources de calcul nécessaires pour l’entraînement, ce qui constitue un objectif distinct des coûts liés au cycle de vie du modèle.

30. RLHF, DPO, GRPO, ainsi que le paysage d’alignement

L’alignement oriente un modèle préentraîné vers les instructions, préférences et politiques de sécurité souhaitées. Il ne garantit pas à lui seul l’exactitude des résultats ni un comportement sûr. Les méthodes présentées ci‑dessous équilibrent la complexité d’implémentation, les exigences en données, l’exploration et la stabilité de l’entraînement.

Le classique RLHF pipeline : SFT → collecter des paires de préférences humaines → entraîner un modèle de récompense à partir de ces paires → affiner la politique grâce à PPO (Optimisation de politique proximale). PPO conserve simultanément 4 copies du modèle en mémoire (politique, modèle de référence, modèle critique/de valeur, modèle de récompense), est sensible aux hyperparamètres, et est sujet au reward hacking, phénomène par lequel le modèle exploite des particularités du modèle de récompense (comme des réponses longues et prétentieuses) au lieu d’améliorer réellement la qualité.

DPO (L’Optimisation directe des préférences) permet d’éviter le modèle de récompense appris ainsi que le cycle d’apprentissage par renforcement en ligne, en optimisant directement une perte basée sur des paires de préférences. Cela simplifie l’entraînement pipeline. La méthode DPO standard est en mode hors ligne : elle s’entraîne à partir d’une dataset fixe et ne explore pas de nouvelles réponses au cours du cycle de mise à jour. L’importance de cette limitation dépend de la tâche et de la couverture des données.

GRPO (Group Relative Policy Optimization, DeepSeek) élimine le critique appris par PPO en générant plusieurs complétions pour chaque prompt et en utilisant des récompenses relatives au groupe comme référence. Cela diminue la charge liée à l’état du modèle par rapport à une configuration typique de PPO. Contrairement à DPO, GRPO fonctionne en mode on-policy : le modèle génère de nouvelles réponses au cours de l’entraînement. DeepSeek-R1 Il combine GRPO avec RLVR (apprentissage par renforcement à partir de récompenses vérifiables), en recourant à des vérifications telles que la résolution de problèmes mathématiques, la compilation de code et les tests unitaires. Ces récompenses sont plus faciles à auditer qu’un score de préférence appris, mais des tests incomplets ou des objectifs substituts peuvent néanmoins être exploités.

31. Distillation : compression des connaissances entre modèles

La distillation des connaissances permet de transférer les capacités d’un grand modèle enseignant vers un modèle étudiant plus petit. La distillation basée sur les logits entraîne l’étudiant à reproduire la distribution des sorties du modèle enseignant. La distillation basée sur les données fait en sorte que le modèle enseignant génère des exemples que l’étudiant peut affiner ultérieurement. Les méthodes basées sur les données sont fréquemment utilisées pour LLMs, car elles fonctionnent indépendamment de l’architecture et peuvent être appliquées même avec des modèles enseignants de type API, toutefois leur efficacité dépend de la qualité du modèle enseignant, de la couverture des données, des mécanismes de filtrage ainsi que des coûts de génération.

DeepSeek-R1 800 000 exemples de raisonnement ont été générés et utilisés pour affiner les modèles Qwen2.5 et Llama 3, en réduisant leur nombre de paramètres de 1,5 milliard à 70 milliards. Selon l’évaluation présentée dans la publication :

• DeepSeek-R1-Distill-Qwen-32B obtient 72,6 % sur AIME 2024 et 94,3 % sur MATH-500, des résultats supérieurs aux chiffres d’o1-mini d’OpenAI rapportés dans la publication.
• DeepSeek-R1-Distill-Qwen-7B atteint 55,5 % sur AIME 2024, ce qui est également meilleur que le résultat obtenu avec le modèle plus petit QwQ-32B-Preview mentionné dans le papier.

Lors des expériences menées sur les modèles de petite taille de DeepSeek-R1, la distillation a montré de meilleures performances que l’approche directe GRPO sur les modèles de base testés. Ce résultat valide l’utilisation de la distillation dans ce cadre spécifique ; il ne permet cependant pas d’établir un classement universel entre la distillation et l’apprentissage par renforcement.

32. Génération de données synthétiques

LLM – Les données d’entraînement générées sont utilisées dans plusieurs schémas récurrents :

• Auto-instruction Il démarre à partir d’un petit ensemble initial d’instructions rédigées par des humains : le LLM génère de nouvelles instructions, entrées et sorties, qui sont filtrées avant d’être réintégrées dans cet ensemble. Alpaca Le projet a utilisé 52 000 exemples provenant de 175 sources d’entraînement et a indiqué un coût de génération d’environ 600 $ ; sa comparaison avec GPT-3.5 n’était qu’une évaluation limitée du projet, et non une équivalence globale.
• Évol-Instruct (WizardLM) prend des instructions existantes et les fait évoluer de manière itérative le long d’axes de complexité (en ajoutant des contraintes, en approfondissant le raisonnement, en rendant les problèmes plus concrets) afin de générer des exemples d’entraînement de plus en plus difficiles.
• Microsoft’s Phi-4** (14B) a fait appel à des données synthétiques pour une grande partie de son préentraînement, notamment pour la génération, la critique, la révision automatique et l’inversion des instructions. Son rapport technique compare les performances obtenues en STEM et en programmation avec celles de modèles plus volumineux sur le dataset benchmarks.

Le risque pertinent ici est le model collapse : lorsque des modèles sont entraînés de manière récursive à l’aide de données synthétiques issues de générations précédentes, les extrémités de la distribution d’origine disparaissent progressivement. Le modèle surestime alors les motifs courants et perd les variations rares mais importantes.Shumailov et al., 2024). Une étude distincte menée par Ahrefs a classé 74,2 % des pages web nouvellement créées au sein de son échantillon de 900 000 pages comme contenant du texte généré par AI ; il s’agit là d’un résultat issu d’un outil de classification fournisseur, et non d’un recensement complet du Web. Les mesures correctives commencent par le mélange de données synthétiques et réelles, le filtrage ainsi que le suivi de l’origine des données, afin de pouvoir mesurer les contenus générés de manière récursive.

Partie VI — Échelle et déploiement

Échelonner d’un GPU à un cluster consiste à répartir les tâches sur plusieurs dispositifs. Cette section aborde les stratégies de parallélisme, la gestion des serving frameworks, le choix des GPU, ainsi que le routage.

33. Quatre formes de parallélisme

Parallélisme tensoriel (PT) consiste à répartir les matrices de poids individuelles sur GPUs et à communiquer généralement après chaque couche. Des liaisons intranœud rapides telles que NVLink en font l’approche la plus pratique au sein d’un même nœud. Un plus grand nombre de fragments diminue la mémoire et les ressources de calcul par appareil, mais augmente les besoins en communication ; il convient donc de choisir le degré en fonction d’une latence benchmark adaptée.

Pipeline Le parallélisme (PP) consiste à répartir séquentiellement les couches sur plusieurs GPUs, en transférant les activations d’une étape à l’autre. Son schéma de communication peut fonctionner entre des nœuds, mais les pipeline bulles ainsi que les temps d’exécution inégaux entre les étapes réduisent l’efficacité globale. Les déploiements de grande envergure combinent souvent le TP au sein d’un même nœud et le PP entre différents nœuds.

Parallélisme des données (PD) consiste à répliquer le modèle serving de manière à ce que chaque réplique traite des requêtes indépendantes, sans nécessiter de communication entre répliques à chaque demande. Cette approche est efficace lorsque le modèle tient dans les limites disponibles et que le trafic peut être équilibré. Lors de l’entraînement, le PD est fréquemment associé à ZeRO ou FSDP afin de partager l’état du modèle.

Expert Parallelism (EP) répartit des experts MoE sur des GPUs en utilisant une communication de type tous-à-tous pour le routage des tokens. Ses performances dépendent de l’équilibre des tokens, de l’emplacement des experts ainsi que de la topologie des interconnexions ; le trafic de type tous-à-tous peut alors devenir le goulot d’étranglement majeur.

Une heuristique de parallélisme de départ :

• Le modèle s’adapte à un seul GPU : on commence par des réplicas indépendants et on mesure l’échelle de DP.
• Le modèle tient sur une seule node : on teste le TP au sein de cette node, puis on crée des réplicas du groupe si la charge de travail l’exige.
• Le modèle couvre plusieurs nodes : on évalue une combinaison de TP et PP en fonction des exigences d’interconnexion et des objectifs de latence.
• Mélange d’experts : on ajoute des EP uniquement lorsque leur disposition est nécessaire.

34. Comparaison de Serving et frameworks

vLLM Il offre une allocation KV paginée, un lotage continu, un API compatible avec OpenAI, ainsi que plusieurs modes de parallélisme. Les mises à jour concernant ses modèles et son matériel sont fréquentes ; il est donc indispensable de vérifier le modèle cible à l’aide de la matrice de compatibilité en vigueur.

SGLang Il intègre RadixAttention afin de réutiliser les préfixes, un planificateur personnalisé ainsi qu’une génération structurée. Les gains de productivité qu’il affiche dépendent du travail à effectuer et des paramètres de configuration ; comparez-le avec vLLM et TensorRT-LLM en utilisant exactement les mêmes prompts, sorties, matériel et objectifs de performance.

TensorRT-LLM Il vise une faible latence par requête grâce à la fusion de graphes CUDA et à l’optimisation des noyaux, tout en offrant un soutien natif pour les FP8/FP4. Les valeurs publiées dépendent du matériel et du modèle, il convient donc de les comparer avec celles des autres frameworks sur un même harness. Le prix à payer est une courbe d’apprentissage plus raide ainsi qu’une surface de déploiement spécifique à NVIDIA.

TGI Il s’intègre à l’écosystème Hugging Face et prend en charge plusieurs backends matériels. Vérifiez l’état actuel des travaux de maintenance ainsi que les fonctionnalités disponibles dans le répertoire avant de le choisir pour une nouvelle déploiement.

Ollama Il met en avant un flux de travail simple basé sur un modèle local. Utilisez-le pour des raisons de commodité lors du développement ; benchmark une autre pile serving lorsque la haute concurrence ou un contrôle explicite des SLO est essentiel.

llama.cpp Il s’agit d’un compilateur portable en C/C++ runtime compatible avec les architectures ARM, x86, Metal, CUDA, ROCm ainsi que Vulkan. GGUF prend en charge plusieurs niveaux de quantification. Les performances varient considérablement en fonction du modèle, du niveau de quantification, du contexte et de backend ; il est donc recommandé d’utiliser l’outil local benchmark adapté à la machine cible.

35. Sélection GPU pour l’inférence

Ce tableau présente un aperçu des prix du matériel et des services cloud en mars 2026. Les étiquettes « Precision » indiquent les capacités offertes par les fournisseurs, et les prix varient en fonction du prestataire, de la région, de la durée du contrat et de la disponibilité ; veuillez les vérifier avant d’effectuer votre achat.

On choisit en premier lieu en fonction de la compatibilité mémoire, puis en fonction du débit mesuré au niveau de la cible de latence. La capacité de 141 GB de l’H200 peut simplifier certaines implémentations de modèles de grande taille, tandis que le B200 intègre un soutien pour FP4, 192 GB de HBM3e, ainsi qu’une génération plus récente de NVLink. Les GPUs basés sur GDDR, plus petits, peuvent s’avérer économiques pour les modèles quantifiés lorsque leurs limites en matière de mémoire et d’interconnexion correspondent à la charge de travail.

Le support natif de quantification du matériel a une influence considérable sur les performances. AWQ et GPTQ (avec des poids INT4) peuvent fonctionner efficacement sur n’importe quelle architecture grâce à une déquantification vers des registres FP16, mais une véritable accélération native via des Tensor Cores dépend de la génération du processeur. Les modèles Hopper (H100/H200) et Ada (L40S/4090) assurent une accélération native des opérations FP8, tandis que le modèle Blackwell (B200) intègre des Tensor Cores FP4 natifs pour obtenir d’importantes améliorations en termes de débit. Tous les modèles GPUs mentionnés prennent en charge les opérations matricielles INT8.

LLM La décodage est souvent limité par la bande passante mémoire, donc HBM La capacité et la bande passante peuvent être plus importantes que les TFLOPS de pointe pour serving charges de travail. Comparer GPUs avec le modèle, la précision, la distribution par lot, la longueur de contexte et l’objectif de latence maintenus constants.

36. Cascading et routage des modèles

Le routage des modèles sélectionne le LLM qui traitera chaque requête en fonction de la complexité ou des capacités prévues. RouteLLM (LMSYS/UC Berkeley, ICLR 2025) indique une réduction des coûts de 85 % sur son environnement MT-Bench, tout en conservant 95 % du niveau de qualité de référence du GPT-4. Le fait que l’utilisation de routeurs soit rentable dépend des prix actuels, de la composition du trafic, des erreurs de routage et du seuil minimal de qualité requis.

Les routeurs vont des classificateurs légers aux juges basés sur LLM. La variante en cascade consiste à utiliser successivement différents modèles : une requête commence par un modèle moins coûteux, puis passe à un modèle plus puissant lorsque la fonction de notation rejette la réponse obtenue. FrugalGPT Les modèles évalués permettent d’obtenir des coûts jusqu’à 98 % inférieurs ou une précision jusqu’à 4 % supérieure. Une mise en production en cascade exige des critères d’escalade calibrés ainsi qu’un suivi rigoureux des requêtes que le modèle économique traite de manière incorrecte.

Partie VII — Applications

Des motifs au niveau de l’application qui transforment les capacités brutes du modèle en systèmes utiles. La récupération de puissance Embeddings permet aux agents d’orchestrer des flux de travail à plusieurs étapes, tandis que RAG ancre les réponses dans des connaissances externes ; enfin, prompt engineering assure la cohérence de l’ensemble.

37. Embedding modèles vs modèles génératifs

Les Embedding transforment du texte en vecteurs à dimension fixe qui permettent de capturer le sens sémantique. Contrairement aux modèles décodeurs génératifs qui produisent des séquences de tokens, ils génèrent un unique vecteur dense (de 768 à 4 096 dimensions) représentant l’ensemble de l’entrée. La plupart des embedding emploient des transformateurs à encodeur uniquement (avec attention bidirectionnelle) plutôt que des décodeurs. L’encodeur traite tous les tokens d’entrée en même temps et produit une représentation contextualisée pour chacun d’eux. Une couche de pooling fusionne ensuite ces représentations par token en un seul vecteur, généralement par moyenne pondérée (en calculant la moyenne de toutes les valeurs embeddings des tokens) ou via le pooling CLS (en utilisant la sortie d’un token de classification spécial). Enfin, le modèle est affiné au moyen d’un apprentissage contrastif : les textes sémantiquement similaires sont rapprochés dans l’espace vectoriel, tandis que ceux qui le sont moins sont éloignés.

Modèles embedding sélectionnés ainsi que leurs scores rapportés (2025–2026) :

Ce tableau associe des rapports de modèle aux versions benchmark, ce qui en fait une liste restreinte plutôt qu’un classement strict. Certains systèmes embedding plus récents emploient des architectures de décodage dotées d’attention bidirectionnelle ainsi que de mécanismes de pooling. D’autres génèrent des embeddings à précision inférieure ou multimodaux. Il convient d’évaluer le langage requis, la modalité, la tâche, la dimension ainsi que le coût serving sur un seul ensemble de récupération.

Apprentissage par représentation Matryoshka (MRL, Kusupati et al., NeurIPS 2022) Permet de rendre les dimensions embedding flexibles. Inspirées des poupées russes, les structures MRL organisent un embedding de telle manière que ses $m$ premières dimensions soient aussi informatives qu’un modèle $m$-dimensionnel entraîné indépendamment. Lors de l’entraînement, au lieu de calculer une seule perte sur l’ensemble du embedding, MRL calcule plusieurs pertes en parallèle à des dimensions espacées de façon logarithmique (64, 128, 256, 512, 1024, 2048, 3072). La perte agrégée incite les dimensions les plus précoces à transmettre des informations sémantiques grossières, tandis que les dimensions ultérieures ajoutent des détails plus fins.

Une fois l’entraînement terminé, un MRL embedding peut être tronqué pour n’utiliser que une dimension de préfixe compatible. Selon OpenAI, le modèle text-embedding-3-large à 256 dimensions affiche de meilleures performances que text-embedding-ada-002 à 1 536 dimensions dans la comparaison MTEB qu’ils ont présentée. Cela permet une réduction de 6 fois de l’espace de stockage nécessaire pour les vecteurs bruts ; par ailleurs, la latence des recherches ainsi que les coûts de base de données dépendent également de l’index, des métadonnées, des mécanismes de filtrage et du matériel utilisé.

Le modèle embedding constitue l’un des composants essentiels au sein d’un RAG pipeline, aux côtés du parsing, du chunking, de la recherche, de reranking, et de la génération. Si aucune preuve pertinente n’est retrouvée, un générateur plus puissant ne pourra pas la restituer de manière fiable.

38. Architecture RAG en environnement de production

La génération augmentée par récupération fournit un LLM composé de documents récupérés au moment de la requête. Elle peut fournir des preuves actuelles ou privées absentes des poids du modèle, mais la récupération ne garantit pas que la réponse utilisera correctement ces preuves. Un système RAG en environnement de production est un pipeline à plusieurs étapes, dont les différentes phases nécessitent une évaluation distincte.

L’ingestion pipeline s’effectue hors ligne. Les documents bruts (PDF, HTML, Markdown, bases de données) sont d’abord analysés afin d’obtenir du texte net, une tâche plus complexe qu’il n’y paraît : l’analyse des seuls PDF peut entraîner la perte de tableaux, de en-têtes et de formats. Ce texte est ensuite divisé en chunks, qui sont intégrés et indexés de manière indépendante.

Le découpage en chunks influence à la fois le taux de rappel lors de la récupération des données et le contexte mis à disposition du générateur. La taille optimale dépend de la structure du document, de la granularité de la requête, des limites imposées par l’embedder ainsi que des contraintes liées à reranker. Les approches les plus courantes consistent en un découpage de taille fixe avec chevauchement, en une séparation récursive le long des frontières du document, ou encore en un découpage sémantique basé sur la similarité déterminée par embedding. Il est préférable de comparer ces méthodes en se basant sur des étiquettes de pertinence au niveau des pages ou des sections, plutôt que d’adopter uniformément une plage de tokens spécifique.

Chaque morceau est ensuite intégré à l’aide d’un modèle similaire à ceux utilisés dans Section 37 et stocké dans une base de données vectorielle (Pinecone, Weaviate, Qdrant, pgvector, etc.).

La récupération pipeline s’effectue au moment de la requête. Commencez par établir une base de référence mesurable, puis ajoutez des étapes lorsque l’analyse des erreurs montre qu’elles permettent de corriger des erreurs réelles de récupération :

• La recherche hybride associe la récupération vectorielle dense à des méthodes de récupération sparses telles que BM25, souvent fusionnées au moyen de Reciprocal Rank Fusion (RRF). La recherche dense gère les paraphrases sémantiques, tandis que la recherche sparsa permet d’identifier des identifiants exacts, des codes d’erreur et des acronymes. Les fournisseurs benchmarks indiquent des améliorations par rapport aux référentiels basés uniquement sur des vecteurs, mais la taille du résultat dépend du corpus ainsi que des étiquettes de pertinence.
• Reranking fait passer les candidats récupérés par un modèle qui évalue simultanément la requête et le document. Cela peut améliorer la pertinence au niveau fin au prix d’une autre appel à un modèle. Il convient d’ajuster en parallèle le nombre de candidats, le nombre conservé et la latence. J’ai abordé en détail le processus multi-étapes complet de pipeline dans Construire une pile de classement de recherche moderne.
• Transformation de la requête permet de réécrire la requête de l’utilisateur avant la recherche afin d’améliorer le taux de rappel. HyDE (Document hypothétique Embeddings) fait appel au LLM pour générer une réponse hypothétique, qui est ensuite intégrée et utilisée dans le processus de recherche. Expansion multi-requêtes consiste à créer plusieurs formulations de la même question. Prompting par recul consiste à poser d’abord une question plus générale afin d’obtenir un contexte plus large.

Les modes de défaillance courants :

• Échec de récupération — le document correct existe mais n’est pas récupéré. Tester le découpage en chunks, la transformation des requêtes, la recherche hybride ainsi que le filtrage par métadonnées dans ce cas d’échec.
• Empoisonnement du contexte — des chunks récupérés non pertinents induisent en erreur le LLM. Tester les reranking, les filtres de contexte et des ensembles conservés plus petits.
• Problème du milieu — le LLM ignore un contexte pertinent situé au milieu d’un prompt long.Liu et al., 2024 Il est apparu que les modèles accordent une attention principale au début et à la fin de la fenêtre de contexte).

GraphRAG (Microsoft, 2024) améliore la récupération vectorielle en intégrant un graphe d’entités et de relations extrait. Cette approche cible les questions à l’échelle du corpus ainsi que celles riches en relations, que la récupération par segmentation simple risquerait de manquer. Le compromis réside dans les efforts supplémentaires nécessaires pour l’extraction, l’indexation, le stockage et l’évaluation.

Les guides destinés aux professionnels indiquent des fourchettes de latence pour embedding, la recherche, reranking et la génération, cependant ces valeurs varient en fonction de la région, du corpus, du matériel ainsi que du modèle utilisé. Il est nécessaire de mesurer chaque étape au sein des traces d’exécution et d’évaluer l’évolution de la qualité avant d’accepter l’augmentation de la latence induite.

39. Architectures d’agents et appel d’outils

Les LLM utilisent des modèles pour sélectionner et ordonner les tool calls au sein d’un état en évolution. Trois schémas d’orchestration utiles sont :

• ReAct — Il alterne la sélection d’actions avec les observations. Il peut s’adapter après chaque tool result, mais une historique croissante entraîne des coûts en tokens et en latence. ReWOO — des plans tool calls contenant des placeholders, qui exécutent des tâches indépendantes en parallèle avant de procéder à la synthèse. La publication correspondante indique des économies de tokens par rapport à ReAct, mais le plan fixe nécessite une voie de récupération explicite en cas de défaillance d’une outil.
• Planner-executor — sépare la phase de planification de l’exécution et permet d’ajouter une politique de replanification après une défaillance. Il autorise la spécialisation des modèles, mais introduit un état d’orchestration ainsi qu’une nouvelle frontière de décision.

Function calling constitue un mécanisme courant pour l’appel d’outils. Les APIs permettent de définir des outils et de renvoyer des arguments structurés, ce qui diminue la nécessité de parser du texte libre. Même si les arguments sont validés selon un schéma, ils peuvent encore sélectionner le mauvais outil ou contenir des valeurs inválides. Le parallélisme function calling peut réduire le nombre d’allers-retours lorsque les opérations sont indépendantes.

Structured output et constrained decoding imposent un schéma en restreignant les tokens disponibles à chaque étape de génération. Des moteurs tels que xgrammar, Utilisé dans vLLM ainsi que dans SGLang, il permet d’éliminer de nombreux problèmes de syntaxe et de parsing avec un faible coût en ressources dans les configurations prises en charge. Il ne garantit cependant pas que les valeurs ou décisions extraites soient exactes. Raisonnement guidé par schéma (SGR) exploite l’ordre des champs ainsi que la structure du schéma afin de rendre l’état intermédiaire inspectable avant la prise de décision finale. Ses trois modèles sont le Cascade (étapes séquentielles), le Routing (types union en tant que commutateurs sémantiques) et le Cycle (listes bornées).

La qualité de sélection des outils, la latence bout en bout et le coût par token se détériorent généralement à mesure que l’ensemble d’outils et la profondeur des actions augmentent. Il convient d’évaluer ces courbes en s’appuyant sur les descriptions réelles des outils ainsi que sur la distribution des échecs. Frameworks comme LangGraph On peut rendre explicites les chemins d’état et de récupération, mais cela n’élimine pas la charge liée à l’évaluation.

40. Prompt engineering pour le environnement de production

L’encadrement en environnement de production constitue un problème d’évaluation : il s’agit de modifier une partie du prompt ou du contexte, puis d’évaluer la qualité de la tâche ainsi que les modes de défaillance. Les techniques présentées ci‑dessous constituent des points de départ courants, mais elles ne suivent pas nécessairement un ordre universel.

Les exemples de type few-shot sont souvent efficaces pour contrôler le format de la sortie. Commencez par 3 à 5 exemples couvrant des entrées vides, des requêtes ambiguës et des réponses composées de plusieurs parties, puis évaluez les résultats sur un ensemble réservé. Ces exemples doivent refléter la véritable distribution des entrées, et non seulement les cas simples. Un nombre accru d’exemples consomme du contexte sans pour autant garantir des améliorations supplémentaires.

Chain-of-thought (CoT), le prompting consiste à demander à un modèle de rendre visibles ses raisonnements intermédiaires avant de fournir une réponse. Kojima et al. ont rapporté des améliorations grâce à l’ajout du suffixe « Let’s think step by step » sur les tâches de raisonnement testées, mais cet effet varie d’un modèle à l’autre, et les nouvelles méthodes de raisonnement APIs peuvent ne pas révéler les traces cachées. En environnement de production, il est préférable d’utiliser une décomposition de la tâche facilement inspectable ou une justification concise lorsque cela est utile pour l’évaluateur. La self-consistency (Wang et al., 2023) Il explore plusieurs chemins de raisonnement et agrège les réponses, acceptant ainsi un coût d’inférence supplémentaire en échange d’une plus grande robustesse sur des tâches appropriées.

Structured output utilisant des schémas JSON explicites (Section 39) élimine de nombreux échecs de parsing. Les moteurs Constrained decoding tels que xgrammar permettent d’imposer la grammaire prise en charge lors de la génération ; toutefois, l’exactitude factuelle et la validité sémantique nécessitent encore une évaluation, et les fonctionnalités de schéma non prises en charge doivent parfois être gérées manuellement.

Prompt chaining consiste à découper une tâche en étapes bien définies, comme par exemple classer l’intention → récupérer le contexte → générer la réponse → valider la sortie. Cette approche permet de localiser les échecs, d’utiliser des modèles différents pour chaque étape, et de mettre à disposition des états intermédiaires pouvant être mémorisés en cache. Cependant, elle introduit également des interfaces supplémentaires ainsi qu’une latence accrue ; il convient donc de la comparer avec une solution basée sur une seule appelation.

La température modifie la distribution d’échantillonnage. Des valeurs faibles constituent un point de départ raisonnable pour la classification ou l’extraction ; des valeurs plus élevées peuvent augmenter la diversité lors de l’idéation. Le comportement exact varie d’un modèle à l’autre APIs et interagit avec top_p, top_k, ainsi que les valeurs par défaut du fournisseur ; il convient donc de parcourir l’ensemble des paramètres pris en charge pour la tâche au lieu de copier une seule plage.

Séparation des messages système et utilisateur permet de maintenir les politiques persistantes distinctes du contenu spécifique à chaque requête. Les modèles de chat ainsi que le réglage des instructions attribuent des priorités différentes à ces rôles, mais ils ne transforment pas un message système en limite d’application stricte. Placez le comportement stable dans le message système, conservez les données non fiables dans le contenu de l’utilisateur ou de l’outil, et appliquez également des contraintes strictes telles que la suppression des données personnelles identifiables en dehors du modèle.

Context engineering étend le travail de prompt à l’assemblage des documents récupérés, des tool results, du historique de conversation ainsi que des exemples. Liu et ses collaborateurs ont observé un effet « perdu au milieu » chez les modèles à contexte long qu’ils ont testés ; par conséquent, la prise en compte de la position doit faire partie de l’évaluation plutôt que d’être considérée comme irrelevante. J’ai abordé le flux de travail plus global dans Context Engineering pour les agents AI.

Partie VIII — Opérations en production

Cette section aborde la limitation de débit, les modes de défaillance, la surveillance, l’optimisation des coûts ainsi que la planification de capacité dans un environnement de trafic réel.

41. Limitation de débit pour les requêtes à coût variable

La limitation de débit traditionnelle basée sur le nombre de requêtes par seconde part du principe que le coût par requête est plus ou moins constant. LLMs vient remettre en question cette hypothèse. Une classification utilisant 10 tokens prompt et une analyse de document nécessitant 100 000 tokens se rendent toutes deux à la même interface API, mais leur coût diffère de quatre ordres de grandeur. Une limitation par RPS permet soit aux requêtes coûteuses de passer sans contrôle, soit aux requêtes peu coûteuses d’être bloquées inutilement.

Les systèmes de production nécessitent une limitation de débit basée sur des tokens appliquée à plusieurs dimensions. OpenAI Limites de demande de documents et de tokens par niveau d’utilisation. Anthropic Il distingue les limites de tokens d’entrée et de tokens de sortie. Les quotas précis ainsi que les algorithmes associés peuvent varier, il convient donc de se référer à la documentation du fournisseur comme source unique de vérité ; l’objectif architectural est de gérer de manière indépendante le budget alloué aux requêtes et aux tokens.

Le schéma d’implémentation pratique repose sur une hiérarchie de limites multidimensionnelle (utilisateur → application → organisation → global), dotée de niveaux de priorité pour les accès premium. Au niveau des requêtes, la technique clé est la réservation d’un budget de tokens : il s’agit d’estimer le nombre total de tokens nécessaires (entrée + max_tokens) au moment de l’admission, déduire la quantité correspondante du pool, puis ajuster le montant une fois la requête terminée en fonction de l’utilisation réelle. Cela permet d’éviter que des requêtes de génération longue durée ne consomment toute la capacité avant même d’avoir commencé à générer du contenu.

Dans le cas des déploiements auto-hébergés, l’équivalent correspond à une bande passante allouée : il s’agit de réserver une capacité dédiée GPU afin d’atteindre les taux de tokens ciblés. Pour les déploiements vLLM, cela signifie configurer un contrôle d’accès basé sur les slots de décodage actifs ainsi que sur la pression KV cache, et non uniquement sur le nombre de requêtes. Section 5 Il explique que tant le débit que les règles d’admission doivent faire l’objet de limites prenant en compte les tokens.

42. Modes de défaillance à prendre en compte dans la conception

LLM serving introduisent des modes de défaillance liés à la longueur variable des séquences, à la mémoire KV ainsi qu’aux opérations de décodage à long terme. Concevez et effectuez des tests de charge sur ces mécanismes de protection avant que le trafic en production ne dépende d’eux.

Épuisement de la mémoire (Out-of-Memory ou OOM) est une panne fréquente. Un modèle de 70 milliards de paramètres FP16 nécessite environ 140 Go rien que pour ses poids, et KV cache, dans le cadre des hypothèses données, peut ajouter près de 40 Go pour une seule séquence à contexte de 128 K. Section 6. L’écart entre la situation où « tout tient en mémoire » et celle de « OOM sous charge » est plus faible qu’il n’y paraît, car un lot de requêtes à contexte long peut consommer plus de mémoire KV que prévu. La prévention repose à la fois sur une réserve de mémoire calculée avec précision, sur la quantification ainsi que sur une allocation KV paginée. Pour les charges de travail soumises à une forte pression sur la mémoire KV, LMCache Il est possible de transférer les données KV vers la mémoire ou le disque CPU ; on peut alors utiliser ses résultats publiés comme point de départ pour gérer la hiérarchie de mémoire locale benchmark.

La préemption se produit lorsque la pression exercée par KV cache force le planificateur à évincer ou à recalculer des tâches. La stratégie exacte dépend de la version et de la configuration de serving. Du point de vue de l’utilisateur, cela se manifeste par une latence globale accrue, sans erreur d’application évidente. Il convient de surveiller le nombre de préemptions et de les corrélater avec l’utilisation des structures KV, la profondeur des files d’attente ainsi que la longueur des requêtes.

La latence de fin de traitement peut augmenter fortement lorsque de gros pré‑remplissages retardent les opérations de décodage. Les données sont traitées par blocs prefill (Section 7) Et le planification consciente de la longueur vise à atténuer cette interférence. Les travaux sur le scheduler Learning-to-Rank ainsi que ceux présentés dans CascadeInfer démontrent des améliorations significatives par rapport aux méthodes de référence, mais les résultats précis dépendent de la distribution de la longueur des requêtes et de la configuration du scheduler.

Les échecs en cascade peuvent survenir lorsque des requêtes lentes alourdissent la file d’attente, que les clients en amont expirent leurs délais de connexion, et que les tentatives de réessai ajoutent encore plus de charge. Les mécanismes de protection comprennent le contrôle d’admission, des limites de concurrence par utilisateur, des plafonds de sortie, des budgets de réessai, ainsi que des disjoncteurs de circuit au niveau du gateway. Une distribution prefill et des groupes de décodage distincts peuvent s’avérer utiles lorsque des tests de charge révèlent une interférence de phase persistante.

43. Surveillance des systèmes LLM

Le LLM diffère du API traditionnel sur quelques points fondamentaux. Chaque requête présente un coût variable, comporte deux phases distinctes présentant des goulots d’étranglement différents, et exige une quantité de mémoire qui dépend à la fois de la longueur de l’entrée et de celle de la sortie générée. Des métriques standard telles que le temps de réponse ou le taux d’erreur ne capturent qu’une partie infime des éléments vraiment importants.

Goodput représente le nombre de requêtes par seconde qui respectent l’ensemble des seuils SLO définis, tels que TTFT, TPOT et la latence totale. Il s’agit d’une mesure globale très utile, car un débit brut peut sembler satisfaisant même si les seuils de latence ne sont pas atteints : un système traitant 100 requêtes par seconde mais échouant à respecter ces seuils pour 40 % d’entre elles présente un goodput de 60. L’optimisation axée sur goodput permet de garder une vision claire de la distribution des performances, au lieu de ne se baser que sur la valeur moyenne.

vLLM expose une interface Prometheus à /metrics Avec des requêtes en cours d’exécution et en attente, KV cache, des distributions de longueur de génération ainsi que des statistiques de cache de préfixes. Les noms des métriques peuvent varier d’une version à l’autre ; il est donc recommandé de lier les tableaux de bord à la version déployée. Une architecture typique fait appel à Prometheus pour la collecte des métriques, à Grafana pour leur visualisation, et à des traces compatibles avec OpenTelemetry au sein des applications et des composants serving.

Les modèles d’alerte utiles comprennent ceux qui suivent. Déterminez leurs seuils à partir de tests de charge et n’imitez pas ces exemples tels quels :

• Sauts brutaux du compteur de préemption — les requêtes sont évincées puis relancées ; les utilisateurs subissent ainsi une doublementation silencieuse de la latence.
• L’utilisation de KV cache approchant la zone de préemption testée — il convient d’augmenter la capacité ou de réduire la charge avant que les évictions ne se multiplient en cascade.
• La profondeur de file d’attente restant constamment supérieure à la limite de lot testée — le mécanisme de contrôle d’admission doit commencer à rejeter les requêtes ou à les déprioriser.
• L’TTFT en hausse tandis que le TPOT reste stable — cette divergence indique en premier lieu un problème lié à la file d’attente, au contrôle d’admission, au réseau ou à la pression prefill, et non à un problème de débit de décodage. Utilisez des traces et des métriques de file d’attente pour faire la distinction entre ces causes possibles.

44. Optimisation des coûts : une stratégie d’effets composés

En tant que vue d’ensemble datée, les prix de mars 2026 API présentaient des écarts considérables selon les différents niveaux de modèles. Les tarifs exacts évoluent rapidement ; il est donc recommandé d’utiliser le calculateur mis à jour par le fournisseur pour prendre une décision d’achat. Ce qui reste constant, c’est le fait que le choix du modèle ainsi que la longueur du résultat peuvent avoir un impact majeur sur le coût, même avant toute optimisation des infrastructures.

Dans l’aperçu de mars 2026 utilisé pour cette section, les tokens de sortie coûtent plusieurs fois plus cher que les tokens d’entrée pour les niveaux de modèle cités. Cette asymétrie reflète le travail de décodage séquentiel décrit précédemment. Section 7. Pour ces structures de tarification, réduire les sorties inutiles peut avoir un impact bien plus significatif que de simplement diminuer le même nombre de tokens d’entrée.

Plusieurs approches peuvent être empilées, mais uniquement après avoir déterminé lesquelles sont adaptées au travail à effectuer :

1. La quantification de FP16 à INT4 permet de réduire la mémoire allouée aux poids de 75 %. Le fait que cela entraîne une baisse des coûts dépend de la vitesse du noyau, de la taille du lot et de l’utilisation du matériel (Section 9).
2. Le routage des modèles envoie le trafic éligible vers des modèles moins coûteux. A Étude de cas du fournisseur Maxim AI A réduction mensuelle de la facture a été constatée, passant de 42 000 $à 29 000$ ; il convient de reproduire le portail de contrôle de qualité avant d’emprunter sa part de routage.Section 36).
3. Prompt le mise en cache permet de réduire les opérations liées à des préfixes répétés. Les remises offertes par les fournisseurs ainsi que les règles de limitation de fréquence évoluent avec le temps ; il convient donc d’associer le taux de hits mesuré aux conditions actuelles.Section 16).
4. Le traitement par lots APIs permet de réduire les coûts pour des tâches non en temps réel telles que les évaluations, la génération de données synthétiques et la classification à grande échelle. Vérifiez les prix actuels ainsi que les délais de traitement.
5. Le hébergement propre peut s’avérer avantageux en cas d’utilisation continue, mais il n’existe pas de seuil de volume de tokens universellement valable pour atteindre l’équilibre économique. Il convient de prendre en compte les coûts liés à l’ingénierie, à l’orchestration, à l’observabilité, à la marge de capacité et aux interventions d’urgence, en plus du coût de location de GPU.

La multiplication des facteurs d’illustration permet d’obtenir une réduction théorique importante, mais les variables d’entrée ne sont pas indépendantes : la quantification affecte le débit de transmission, le routage modifie la composition qualitative du trafic, et le cacheage ainsi que le regroupement s’appliquent uniquement au trafic éligible. Il convient donc d’établir l’estimation à partir des parts de trafic mesurées et de la valider en comparaison avec la facture.

A Rapport sur les fournisseurs 2024 de TrueFoundry Dans ses exemples, cet attribut représente la majeure partie des coûts de déploiement liés à l’ingénierie ML plutôt qu’aux ressources de calcul. Il convient de considérer cette valeur comme un prompt afin d’inclure les coûts de main-d’œuvre et d’exploitation dans le modèle, et non comme un rapport universel.

45. Planification de la capacité et autoscalage

La planification des capacités pour LLM serving doit tenir compte du coût variable des requêtes, des opérations de décodage à long terme, ainsi que de la mémoire dépendante de la séquence d’exécution. En fonction de la charge de travail, la ressource limitante peut être la mémoire KV, la bande passante mémoire, les ressources de calcul, ou l’interconnexion réseau.

Le plafond strict imposé aux requêtes simultanées est le budget mémoire KV cache, et non les FLOPS :

$\text{max séquences simultanées} = \frac{\text{mémoire GPU} - \text{poids du modèle} - \text{coûts d’overhead}}{\text{taille KV cache par séquence}}$

Dans un exemple simplifié de Llama 3 70B INT4, environ 35 GB de poids sur une carte H100 de 80 GB laissent approximativement 40 GB une fois les surcoûts supplémentaires réservés. Avec un contexte de 4K, en supposant 160 MB par séquence, la limite théorique se situe autour de 250 séquences ; avec un contexte de 128K, ce même calcul donne environ cinq séquences. La capacité réelle est encore plus faible lorsqu’on prend en compte le comportement de l’allocateur, les buffers runtime, les variations de longueur des requêtes ainsi que les objectifs de latence définis. C’est pour cette raison que GPU de sélection et optimisation KV cache piloter directement le plan de capacité.

La formule de capacité pour la dimensionnement des flottes :

$\text{exigence GPUs} = \frac{\text{nombre maximal de tokens/min} \times \text{marge de sécurité mesurée}}{\text{débit par GPU dans le cadre des SLO cibles}}$

Ce qui est crucial, c’est d’atteindre l’objectif défini par le SLO. Le débit maximal de tokens et le débit conforme aux exigences du SLO peuvent présenter des écarts importants à mesure que la concurrence augmente. Benchmark doit être évalué en fonction de la distribution réelle prompt ainsi que de la longueur des sorties, aux seuils TTFT et TPOT requis, plutôt qu’en se basant sur une valeur maximale théorique.

La GPU n’est pas suffisante en tant que seul signal d’auto-échelle, car elle peut rester élevée tant pendant un traitement normal que lors d’une surcharge. Il convient de la combiner avec la profondeur de file d’attente, la KV cache, ainsi que la goodput. Les seuils doivent être ajustés à partir de tests de charge ; des valeurs comme 80 % d’utilisation du KV constituent des points de départ, et non des limites universelles. Ces métriques sont présentées dans Section 43.

La mise à l’échelle à zéro permet de s’adapter aux environnements de développement et de staging présentant de longues périodes d’inactivité. Les plateformes d’inférence serverless ainsi que les mécanismes d’auto‑échelle basés sur Kubernetes, comme KEDA, peuvent éliminer cette capacité inutilisée, mais les économies réalisées et le temps de démarrage en mode « cold start » dépendent de la taille du modèle, du cache des images et des poids, ainsi que de l’infrastructure utilisée. Il est indispensable de mesurer le temps de démarrage avant d’appliquer la même politique au trafic de production sensible à la latence.

Le système interconnecté

Ces 45 concepts ne constituent pas une simple collection aléatoire. Ils forment un système interconnecté. La taille de KV cache détermine la taille des lots, la taille des lots influence l’intensité arithmétique, cette dernière contrôle le fait que le décodage soit limité par la mémoire, ce qui à son tour affecte le TPOT, et c’est le TPOT qui définit le débit. GQA réduit KV cache, ce qui permet d’utiliser des lots plus importants, ce qui augmente l’intensité arithmétique et améliore ainsi l’exploitation de GPU. FlashAttention tire parti du fossé de bande passante entre la SRAM et HBM. Le lotage continu résout le problème de l’exploitation des ressources de calcul, mais provoque une fragmentation de la mémoire, problème que PagedAttention vise justement à résoudre. Le prefill en blocs coordonne simultanément les tâches gourmandes en calcul et celles gourmandes en mémoire ; le modèle roofline explique pourquoi cette complémentarité est efficace.

Du point de vue de l’entraînement, le coût lié au cycle de vie peut inciter à former un modèle plus petit sur un nombre accru de tokens, comme le montre Llama 3 8B. GRPO diminue en effet la charge liée à l’état du critique au sein de PPO. Dans la configuration de modèle compact testée pour DeepSeek-R1, la distillation s’est avérée supérieure à l’apprentissage par renforcement direct. Il s’agit là de choix de conception à évaluer, et non d’une recette unique d’entraînement.

Le modèle opérationnel est plus stable que toute courbe de prix : le routage, le cache, la quantification ainsi que l’équipement adapté ne produisent des effets synergiques que lorsque chacun d’eux est évalué en fonction du même objectif de qualité et de latence.

Principes fondamentaux

1. LLM l’inférence comporte deux phases distinctes. Dans les régimes serving courants, prefill privilégie le calcul tandis que la décodage repose davantage sur la bande passante mémoire ; la forme de la charge de travail peut déplacer cette frontière.
2. Le KV cache constitue souvent une contrainte majeure. Sa taille influence la capacité de traitement par lot ainsi que la pression mémoire. GQA, l’affectation paginée et la quantification KV ciblent des aspects différents de cette contrainte.
3. La hiérarchie mémoire GPU explique de nombreuses optimisations. FlashAttention et la fusion de noyaux permettent de réduire les coûteux déplacements de données sans modifier la fonction du modèle.
4. Le lotage continu et PagedAttention fonctionnent en synergie. Une étude publiée indique un débit 23 fois supérieur par rapport à la méthode de référence naïve ; mesurez l’amélioration dans votre pile technologique serving.
5. Un paramétrage optimal pour Chinchilla n’est pas nécessairement optimal pour l’inférence. Par exemple, Llama 3 8B a été entraîné avec environ 1 875 tokens par paramètre afin d’obtenir une inférence moins coûteuse au prix d’un calcul d’entraînement plus important.
6. GRPO et la distillation ont modifié les outils d’alignement. DeepSeek-R1 a montré de meilleurs résultats avec des modèles de petite taille grâce à la distillation par rapport à ses expériences directes basées sur l’apprentissage par renforcement.
7. L’optimisation des coûts ne produit des effets cumulatifs que sur le trafic éligible. La quantification des modèles, le routage, le cacheage ainsi que le lotage APIs nécessitent une évaluation distincte de leur efficacité et de leur qualité avant que leurs économies ne puissent être amplifiées.
8. Serving le matériel doit correspondre au goulot d’étranglement. Les charges de travail à forte intensité de décodage tirent souvent parti de la capacité et de la bande passante HBM ; les charges de travail à forte intensité prefill mettent davantage l’accent sur les ressources de calcul.

Lectures complémentaires

Articles approfondis associés de ce blog, classés par thème :

• LLM Fine-Tuning Guide — quand opter pour le fine-tuning plutôt que RAG ou prompt engineering
• Variantes et formats de fichiers LLM open source — correspondance entre les variantes de modèles et les formats quantisés et le matériel hôte LoRAX Serving – Guide — serving des milliers d’adaptateurs LoRA en environnement de production
• Échelle des grands modèles de langage — stratégies multi-GPU et multi-nœuds Exécution locale LLMs sous macOS — configuration pratique avec llama.cpp et Ollama AI Boucles de raisonnement d’agent en 2026 — Analyse approfondie de ReAct, ReWOO, ainsi que des boucles planificateur-exécuteur
• AI Architecture de mémoire des agents en 2026 — checkpoints, les bases de données vectorielles et la mémoire de documents destinées aux agents à état

Références

Classé par domaine thématique ; les numéros de section sont indiqués entre parenthèses le cas échéant.

Inférence et attention

• FlashAttention : Attention exacte rapide et économe en mémoire, avec prise en compte des opérations d’entrée/sortie - Dao et al., NeurIPS 2022 FlashAttention-2 : Attention plus rapide grâce à un meilleur parallélisme et à une meilleure répartition du travail - Dao, 2023
• FlashAttention-3 : Attention rapide et précise grâce à l’asynchrone et à une faible précision - Shah et al., NeurIPS 2024 Décodage flash pour l’inférence sur des contextes longs - Dao et al., 2023 Gestion efficace de la mémoire pour les grands modèles de langage Serving via PagedAttention - Kwon et al., SOSP 2023
• Orca : Un système distribué Serving pour les modèles génératifs basés sur des transformateurs - Yu et al., OSDI 2022 GQA : Entraînement de l’attention multi-demande généralisée - Ainslie et al., 2023
• Triton : un langage intermédiaire ainsi qu’un compilateur dédié aux calculs de réseaux neuronaux - Tillet et al., MAPL 2019
• FlashNorm : normalisation rapide pour LLMs - 2024
• Fusion profonde des noyaux pour les Transformers - DeepFusionKernel, 2026

Décodage spéculatif

• EAGLE-3 : Amélioration de l’accélération des inférences pour les grands modèles de langage - Li et al., NeurIPS 2025 Medusa : Accélération LLM simple de l’inférence Framework grâce à plusieurs têtes de décodage - ICML 2024

Quantification

• AWQ : Quantification des poids sensible à l’activation pour la compression et l’accélération de LLM - Meilleur article de la conférence MLSys 2024 GPTQ : Quantification post-entraînement précise pour les transformateurs pré-entraînés génératifs - Frantar et al., ICLR 2023
• Marlin : noyau d’inférence à précision mixte (FP16xINT4) LLM - Frantar et al., 2024

Entraînement et fine-tuning

• LoRA : Adaptation à bas rang des grands modèles de langage - Hu et al., ICLR 2022 QLoRA : Ajustement fin efficace de LLMs quantifié - Dettmers et al., NeurIPS 2023
• ZeRO : Optimisations mémoire pour l’entraînement de modèles à des milliards de paramètres - Rajbhandari et al., SC20 ZeRO-Infinity : Dépasser le mur mémoire GPU pour le deep learning à échelle extrême - Rajbhandari et al., 2021
• Self-Instruct : Alignement des modèles de langage avec des instructions auto-générées - Wang et al., ACL 2023
• WizardLM : Permettre aux grands modèles de langage d’obéir à des instructions complexes - Xu et al., ICLR 2024 Rapport technique Phi-4 - Microsoft, 2024 AI Les modèles se dégradent lorsqu’ils sont entraînés sur des données générées de manière récursive. - Shumailov et al., Nature 2024

Alignement

• Optimisation directe des préférences : votre modèle de langage est en réalité un modèle de récompense - Rafailov et al., NeurIPS 2023 DeepSeekMath : Pousser les limites du raisonnement mathématique dans les modèles de langage ouverts - Introduction de GRPO
• DeepSeek-R1 : Incitation des capacités de raisonnement dans LLMs au moyen de l’apprentissage par renforcement - DeepSeek, 2025

Échelle et architecture

• Le troupeau de modèles Llama 3 - Meta, 2024 LLaMA : modèles de langage fondamentaux ouverts et efficaces - Touvron et al. (Meta), 2023
• Llama 2 : versions open source et modèles de chat affinés - Touvron et al. (Meta), 2023 Rapport technique Qwen3 - Qwen Team (Alibaba), 2025 Entraînement de modèles de langage de grande taille optimisés pour les ressources de calcul - Hoffmann et al. (Chinchilla), NeurIPS 2022
• RoFormer : Transformer amélioré doté de mécanismes de positionnement rotatif Embedding - Su et al., 2021 YaRN : extension efficace de la fenêtre de contexte des grands modèles de langage - Peng et al., ICLR 2024 SGLang : exécution efficace de programmes de modèles de langage structurés - Zheng et al., NeurIPS 2024
• Mixtral d’Experts - Jiang et al. (Mistral AI), 2024

Embeddings

• Apprentissage par représentation Matryoshka - Kusupati et al., NeurIPS 2022 pplx-embed-v1 : Dense et contextuel préentraîné par diffusion Embeddings - Perplexité AI, 2026

Architectures d’agents

• ReAct : Synergie entre le raisonnement et l’action dans les modèles de langage - Yao et al., ICLR 2023 ReWOO : Découplage du raisonnement des observations afin d’obtenir des modèles de langage augmentés plus efficaces - Xu et al., 2023

Acheminement

• RouteLLM : Apprentissage de la routage des requêtes LLMs à l’aide de données de préférences - Ong et al., ICLR 2025

Benchmarks

• Résultats de MLPerf Inference v5.0 - MLCommons, avril 2025

Serving architectures

• SARATHI : Inférence LLM efficace grâce à l’utilisation de codes décodés en cascade avec des préremplissages par blocs - Agrawal et al., 2023 (Chunking Prefill)
• Splitwise : Inférence générative LLM efficace grâce à la segmentation en phases - Patel et al., ISCA 2024 (Décomposition Serving)
• DistServe : Désagrégation de Prefill et décodage pour un modèle de langage grand format optimisé pour Goodput Serving - Zhong et al., OSDI 2024 (Modèle Serving déagrégué)

Serving frameworks

• vLLM - Moteur serving basé sur PagedAttention SGLang - RadixAttention et génération structurée
• TensorRT-LLM - Inference optimisée par NVIDIA llama.cpp - Inference portable en C/C++ DeepSpeed - Bibliothèque de formation distribuée Microsoft
• Ollama - Exécuteur local LLM

Opérations

• Planification LLM efficace par apprentissage du classement - Fu et al., NeurIPS 2024 (vLLM-LTR) CascadeInfer : faible latence et équilibrage de charge LLM Serving grâce à un planification sensible à la longueur - 2024
• la métrique Goodput comme indicateur de la productivité ML - Google Cloud, 2024 vLLM Optimisation et réglage - vLLM Documentation vLLM Métriques - vLLM Documentation
• LMCache : gestion de KV Cache pour les LLM Serving - KV cache décharge Limites de débit d’OpenAI - Documentation d’OpenAI API Limites de débit d’Anthropic - Documentation d’Anthropic API