Guide d’ingénierie des LLM : 45 concepts pour les systèmes de production

Viacheslav Dubrov

2026-03-13 · Mis à jour 2026-08-31 · 74 min · Ingénierie des modèles · Infrastructure IA

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

Un service LLM peut manquer son SLO de latence parce que le decode est limité par la bande passante mémoire, parce que le KV cache a consommé le budget de batch, ou parce que la file d’attente masque ces deux problèmes. Un run de fine-tuning peut échouer pour une autre version de la même raison : l’état du modèle ne tient plus dans le hardware. La bonne correction découle du bottleneck, pas de la liste de techniques la plus longue.

Cette page sert de référence aux ingénieurs qui maîtrisent déjà les concepts de base du ML et des systèmes, et qui doivent relier un symptôme de production à la partie correspondante de la stack. Elle couvre 45 concepts répartis entre hardware, inférence, entraînement, déploiement, applications et opérations. Utilisez chaque entrée pour identifier le mécanisme, sa conséquence pratique et la condition qui limite le résultat cité ; consultez ensuite le deep dive associé ou votre propre benchmark pour prendre une décision.

Remarque sur le périmètre

Il s’agit d’une référence, pas d’un tutoriel linéaire. Commencez par la partie qui correspond à la décision à prendre.

Comment utiliser ce guide comme hub

Cette page est volontairement large. Utilisez-la comme carte, puis ouvrez les articles approfondis lorsque la décision devient concrète.

Commencez par le bottleneck, utilisez la stack minimale qui permet de l’exposer, mesurez la charge réelle, et n’ajoutez de la complexité que lorsque les chiffres le justifient.

Partie I — Fondamentaux du hardware

L’intensité arithmétique, la hiérarchie mémoire du GPU et les termes hardware de cette partie expliquent bon nombre des choix présentés plus loin.

1. Limitation par la mémoire ou par le calcul : le modèle Roofline

Le point de départ pour comprendre les performances des LLM est l’intensité arithmétique : pour chaque octet de données chargé depuis la mémoire du GPU, combien de calculs utiles sont effectués ? Ce ratio détermine si une opération est compute-bound (en attente du processeur) ou memory-bound (en attente du chargement des données).

Chaque GPU possède un seuil d’« intensité critique » à partir duquel son débit de calcul maximal rejoint sa bande passante mémoire. Pour un NVIDIA H100 SXM utilisant des Tensor Cores denses en BF16 ou FP16 (989 TFLOPS ; la spécification à 1 979 TFLOPS suppose une sparsité structurée) :

$\frac{989 \text{ TFLOPS}}{3.35 \text{ TB/s}} \approx 295 \text{ FLOPs/byte}$

Le decode en batch-one et le prefill long ou suffisamment batché se situent généralement de part et d’autre de ce seuil :

• Le decode est memory-bound. Générer des tokens un par un impose de charger depuis la mémoire la matrice de poids de plusieurs gigaoctets pour la multiplier par un seul nouveau token. Dans une analyse simplifiée en 16 bits, dense, avec batch-one, l’opération atteint environ 1 FLOP/octet, soit environ 295 fois moins que le seuil Roofline du H100. Cet écart explique pourquoi le decode ne peut pas approcher le débit de calcul maximal dans ce régime.
• Le prefill long ou suffisamment batché est souvent compute-bound. Le traitement de nombreux tokens du prompt réutilise les poids dans de grandes multiplications matricielles, ce qui peut faire passer l’intensité arithmétique au-dessus du seuil Roofline. Les prompts courts et les petits batchs peuvent toutefois rester limités par le trafic mémoire ou l’overhead de lancement des kernels.

Pour accélérer le decode, travaillez sur la bande passante mémoire : réduisez la taille des poids avec la quantification, diminuez l’overhead mémoire du KV avec GQA et PagedAttention, et augmentez l’intensité avec le batching. Pour les prefills longs ou bien batchés, un calcul matriciel plus rapide et un calcul en basse précision peuvent aider ; profilez séparément les workloads de prefill courts.

2. Hiérarchie mémoire du GPU

Un GPU possède quatre niveaux de mémoire organisés comme une pyramide : une mémoire principale volumineuse mais lente (HBM) à la base, et des registres minuscules mais très rapides au sommet. Le déplacement des données dans cette hiérarchie constitue une contrainte majeure de performance.

Du plus rapide au plus lent sur un H100 :

1. Les registres sont la mémoire la plus rapide et sont directement associés aux threads de calcul. Pour le WGMMA de Hopper, la matrice A peut provenir des registres ou de la mémoire partagée, tandis que la matrice B provient de la mémoire partagée.
2. La SRAM (mémoire partagée) est une mémoire de travail rapide sur puce, locale à chaque SM.
3. Le cache L2 est un niveau partagé de 50 Mo. Il peut fournir des données réutilisées par plusieurs SM sans nouveau fetch depuis la HBM.
4. La HBM3 est la mémoire principale de 80 Go qui contient les poids du modèle et le KV cache, avec une bande passante de ~3,35 To/s.

FlashAttention et la fusion de kernels réduisent le trafic HBM en conservant ou en combinant les calculs intermédiaires sur la puce. PagedAttention cible un autre problème : il mappe des blocs KV logiques vers des blocs physiques non contigus de la mémoire GPU, ce qui réduit la fragmentation et permet le partage de blocs.

3. Glossaire du hardware GPU

Les termes ci-dessous apparaissent dans toute la suite de ce guide.

HBM (High Bandwidth Memory) empile des dies DRAM reliés par des vias traversants (TSV) à proximité du die du GPU. Les générations incluent HBM2e (A100, 2 To/s), HBM3 (H100, 3,35 To/s) et HBM3e (H200/B200, 4,8–8 To/s). La bande passante HBM constitue une contrainte directe sur le TPOT dans les régimes de decode memory-bound.

GDDR (Graphics DDR) désigne la mémoire graphique traditionnelle utilisée par les GPU grand public et workstation, comme la RTX 4090 et la L40S. Elle offre une bande passante inférieure à la HBM, mais coûte moins cher par Go. La GDDR6X de la RTX 4090 fournit environ 1 To/s, contre 3,35 To/s de bande passante HBM3 pour le H100.

Un SM (Streaming Multiprocessor) est le bloc de calcul de base d’un GPU NVIDIA. Chaque SM contient des CUDA cores, des Tensor Cores, de la mémoire partagée et un warp scheduler. Le H100 possède 132 SM ; l’A100 en possède 108.

Les Tensor Cores sont des unités spécialisées de multiply-accumulate matriciel intégrées à chaque SM. Elles accélèrent les matmuls en précision mixte qui dominent les calculs des Transformer. Les Tensor Cores du H100 SXM fournissent 494,5 TFLOPS denses ou 989 TFLOPS TF32 sparse ; précisez toujours la précision et le mode de sparsité lorsque vous comparez cette valeur.

Les CUDA Cores sont des unités générales pour les calculs en virgule flottante et entiers. Elles gèrent les opérations élément par élément, les fonctions d’activation et les autres traitements non matriciels pendant que les Tensor Cores exécutent les opérations matricielles prises en charge.

Un warp est un groupe de 32 threads qui s’exécutent en lockstep sur un SM, ce qui en fait l’unité de scheduling la plus petite de NVIDIA. La spécialisation des warps affecte différents warps au déplacement des données et au calcul afin de permettre le chevauchement de ces tâches.

NVLink est l’interconnexion haut débit entre GPU au sein d’un nœud. NVLink 4.0 sur H100 fournit une bande passante bidirectionnelle de 900 Go/s ; NVLink 5.0 sur B200 atteint 1,8 To/s. Cette bande passante est importante pour le tensor parallelism, car les GPU échangent des résultats partiels à chaque couche du Transformer.

InfiniBand est une fabric réseau haut débit pour les communications inter-nœuds. Les adaptateurs InfiniBand de classe ConnectX fournissent la fabric inter-nœuds pour le trafic de pipeline parallelism ou d’entraînement distribué ; la bande passante dépend de l’adaptateur et de la configuration des ports.

RDMA (Remote Direct Memory Access) permet à un périphérique d’accéder à la mémoire d’une autre machine sans faire transiter le chemin de données par un CPU. GPUDirect RDMA prend en charge les transferts directs de GPU à GPU entre nœuds, notamment les transferts de KV cache dans le serving désagrégé.

NVMe (Non-Volatile Memory Express) est l’interface SSD utilisée pour l’offloading du KV cache et l’offloading de paramètres avec ZeRO-Infinity lorsque la mémoire GPU et CPU est insuffisante. La bande passante séquentielle dépend du disque et du workload, et reste très inférieure à celle de la HBM.

TFLOPS et PFLOPS désignent respectivement des billions et des quadrillions d’opérations en virgule flottante par seconde. Un TFLOPS vaut $10^{12}$ FLOPS. Le H100 atteint 989 TFLOPS TF32 sparse sur Tensor Cores, tandis que FlashAttention-3 annonce environ 1,2 PFLOPS en FP8 ; ces valeurs utilisent des formats différents et ne doivent pas être comparées comme s’il s’agissait d’une même métrique.

Partie II — Fondamentaux de l’inférence

L’inférence transforme un modèle en service visible par l’utilisateur. Les concepts suivants distinguent le travail qui retarde le premier token de celui qui ralentit tous les tokens suivants, et exposent les limites mémoire qui sous-tendent ces deux phénomènes.

4. Latence : TTFT, TPOT et percentiles

Le Time to First Token (TTFT) est le délai de bout en bout entre la soumission d’une requête et le premier token produit. Il inclut la mise en file, la tokenisation, le scheduling, le prompt prefill, la première étape de decode et la livraison réseau. Les prompts plus longs augmentent généralement la composante prefill, mais n’importe laquelle de ces étapes peut dominer. Les objectifs dépendent du produit ; MLPerf Inference v5.0 utilise une limite P99 de TTFT de $\leq$ 450 ms pour son scénario interactif Llama 2 70B.

Le Time Per Output Token (TPOT) est l’intervalle moyen entre deux tokens consécutifs après le premier. Il correspond à la phase de decode. Le decode en batch-one ou à faible intensité est généralement limité par la bande passante mémoire, tandis que des batchs suffisamment importants peuvent devenir compute-bound :

$\text{TPOT} = \frac{\text{E2E Latency} - \text{TTFT}}{\text{Output Tokens} - 1}$

Cette définition nécessite au moins deux tokens de sortie ; le TPOT n’est pas défini pour une réponse d’un seul token.

La vitesse moyenne de lecture silencieuse d’un adulte anglophone est d’environ 238 mots par minute pour les textes non fictionnels (Brysbaert, 2019). Les objectifs de streaming doivent toutefois provenir de tests produit ; MLPerf utilise une limite P99 de TPOT de $\leq$ 40 ms pour son scénario interactif.

La latence P50 contre P99 est importante, car la médiane masque la queue de distribution. Un système avec une bonne P50 mais une mauvaise P99 peut souffrir de problèmes de batching, de préemption, de mise en file ou de déséquilibre des workloads ; des traces sont nécessaires pour les distinguer.

5. Débit : tokens par seconde et compromis avec la latence

Le débit se mesure en tokens de sortie par seconde sur l’ensemble des requêtes concurrentes. Le nombre de requêtes par seconde est une métrique moins pertinente seule, car une réponse de 10 tokens et une réponse de 1 000 tokens ont des coûts très différents. Les chiffres publiés varient selon le modèle, la précision, le hardware, les longueurs de prompt et de sortie, la concurrence et le SLO. Comparez vLLM, SGLang et TensorRT-LLM avec un même harness plutôt que de combiner leurs résultats mis en avant.

Le compromis est le suivant : à faible concurrence, chaque requête bénéficie d’une excellente latence, mais le GPU est sous-utilisé. Augmenter la taille du batch accroît le débit presque linéairement jusqu’à la saturation du calcul, après quoi la latence augmente brutalement. Le goodput, c’est-à-dire le débit de requêtes par seconde qui respectent les objectifs de votre SLO, relie le débit brut à l’expérience réelle des utilisateurs.

6. KV cache : le bottleneck derrière la plupart des autres bottlenecks

Lors de la génération autorégressive, chaque nouveau token porte son attention sur tous les tokens précédents. Le KV cache stocke les projections Key et Value de chaque token à chaque couche afin d’éviter $O(n^2)$ recalcul. Sans lui, la génération du token $n$ nécessiterait de réexécuter le modèle sur l’ensemble des $n-1$ tokens précédents.

Le KV cache peut devenir la principale source de pression sur la mémoire variable avec de longues séquences ou une forte concurrence, car il croît linéairement avec la longueur de séquence, la taille du batch et le nombre de couches :

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

où :

• $L$ = nombre de couches
• $h_{kv}$ = nombre de têtes KV
• $d_h$ = dimension d’une tête
• $s$ = longueur de séquence
• $B$ = taille du batch
• $\text{bytes}$ = nombre d’octets par élément mis en cache, déterminé par la précision du KV cache

Exemples concrets en FP16 avec une taille de batch de 1 : Llama 3.1 8B à 8 192 tokens utilise environ 1,0 Go de KV cache ; à 128K tokens, 16 Go. Llama 3.1 70B à 128K tokens nécessite ~40 Go pour une seule séquence, soit la moitié de la VRAM d’un H100. Avec une forte concurrence ou un long contexte, le KV cache peut dépasser la mémoire occupée par les poids du modèle ; le résultat dépend de la longueur de séquence, de la taille du batch actif, de la précision du KV et du nombre de têtes KV. Les implémentations naïves gaspillent 60–80 % de la mémoire KV allouée à cause de la fragmentation ; c’est le problème que PagedAttention a été conçu pour résoudre.

Les principales optimisations sont GQA (moins de têtes KV), la quantification du KV cache (FP8/INT8), PagedAttention (allocation par blocs avec <4 % de gaspillage) et l’offloading du KV cache vers le CPU ou le NVMe.

7. Prefill et decode : deux phases, deux bottlenecks

La phase de prefill traite le prompt d’entrée en parallèle et remplit le KV cache. Les prefills longs ou suffisamment batchés deviennent souvent compute-bound, car ils utilisent de grandes multiplications matricielles ; les prefills courts peuvent rester limités par le trafic mémoire ou l’overhead de lancement des kernels. Le prefill contribue au time to first token (TTFT), avec la mise en file, la tokenisation, le scheduling, la première étape de decode et la livraison réseau. La phase de decode génère un token à la fois. Chaque étape lit les poids du modèle et le KV cache depuis la HBM, ce qui rend le decode en batch-one memory-bound et en fait le principal facteur du time per output token (TPOT).

Le chunked prefill divise le prompt en chunks de taille fixe au lieu de le traiter en une seule fois. Un scheduler peut intercaler ces chunks avec le travail de decode afin qu’un long prompt ne monopolise pas une itération. Sarathi-Serve rapporte de meilleurs compromis débit-latence dans les workloads testés, mais le gain dépend du modèle, du hardware, de la distribution des longueurs de requêtes, de la taille des chunks et de la baseline de comparaison. Le scheduling supplémentaire et des kernels plus petits peuvent augmenter le TTFT de la nouvelle requête.

Le serving désagrégé place le prefill et le decode sur des pools de GPU distincts, permettant à chaque pool de cibler un bottleneck différent. Splitwise et DistServe décrivent ce pattern. Les pools transfèrent les données du KV cache via une interconnexion rapide telle que RDMA, de sorte que le coût de communication fait partie intégrante de la conception.

8. GQA et MQA : réduire la taille du KV cache

La Multi-Head Attention (MHA) standard attribue à chaque tête de requête sa propre tête K et V. La Multi-Query Attention (MQA) partage une seule tête KV entre toutes les têtes de requête, ce qui constitue une réduction extrême. La Grouped-Query Attention (GQA) représente le compromis pratique : des groupes de têtes de requête partagent une tête KV.

Llama 3 70B utilise 64 têtes de requête mais seulement 8 têtes KV, soit une réduction de 8x du KV cache par rapport à la même architecture avec une tête KV par tête de requête. Llama 3.1 405B utilise 128 têtes de requête et 8 têtes KV, soit une réduction de 16x avec le même calcul (Meta, 2024). Ainslie et al. rapportent une qualité GQA proche de celle de MHA dans leurs modèles testés, tout en approchant la vitesse de MQA. Un KV cache plus petit peut permettre des batchs plus importants, mais le gain réel en latence et en débit dépend toujours du kernel et du workload.

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

La quantification réduit la précision des poids du modèle et/ou des activations. Les principaux compromis sont les suivants :

AWQ (Activation-Aware Weight Quantization) identifie les canaux de poids importants à partir des amplitudes d’activation et applique un scaling par canal pour les protéger. Les besoins de calibration dépendent du modèle et de la configuration ; dans une comparaison OPT-6.7B INT3-g128, AWQ a utilisé 16 séquences de calibration contre 192 pour GPTQ. Dans une configuration reproductible, indiquez le nombre et la longueur des séquences. GPTQ utilise des informations approximatives du second ordre pour la quantification couche par couche. bitsandbytes peut quantifier lors du chargement du modèle sans passe de preprocessing séparée ; son format NF4 alimente le fine-tuning QLoRA. La FP8 sur un hardware de classe Hopper divise par deux la mémoire des poids par rapport à FP16/BF16, mais la qualité et la vitesse dépendent toujours du modèle, de la calibration et du kernel.

Le kernel de serving peut compter autant que l’algorithme de quantification. La section 10 présente un résultat Marlin borné et explique pourquoi le gain dépend de la configuration de serving.

Partie III — Optimisations de l’inférence

Les optimisations de cette partie répondent à des contraintes différentes. FlashAttention réduit le trafic HBM de l’attention ; PagedAttention améliore l’allocation du KV ; le continuous batching empêche les séquences terminées de retenir de la capacité de batch.

10. CUDA kernels et fusion de kernels

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 distribue le travail entre ses SM : chaque SM exécute plusieurs warps de 32 threads, et chaque thread traite une portion des données. Toutes les opérations de l’inférence LLM, de la multiplication matricielle à l’échantillonnage des tokens, se résument finalement au lancement de kernels. Un seul forward pass dans un modèle 70B déclenche de centaines à plusieurs milliers de lancements de kernels, et l’écart entre un kernel naïf et un kernel optimisé peut déterminer si le système respecte son SLO de latence.

Les principales catégories de kernels utilisées pour le serving des LLM :

• Kernels GEMM pour la multiplication matricielle, qui domine le calcul du prefill comme du decode.
• Kernels d’attention tels que FlashAttention, qui tuile les calculs pour rester dans la SRAM au lieu de déborder vers la HBM.
• Kernels fusionnés qui combinent plusieurs opérations (par exemple add + layer norm ou projection QKV) en un seul lancement afin d’éviter les allers-retours intermédiaires vers la HBM.
• Kernels d’échantillonnage qui convertissent les logits en IDs de tokens via top-k, top-p ou sampling par température.

La qualité du kernel peut déterminer si des poids compressés apportent réellement un speedup. L’article Marlin rapporte jusqu’à 2,8x de speedup de bout en bout par rapport à sa baseline FP16 pour les configurations vLLM INT4 weight-only testées. Ce résultat est spécifique aux modèles, GPU, tailles de batch et configurations de serving de l’article ; il ne constitue donc pas un gain INT4 universel.

Triton abaisse la difficulté d’écriture de kernels personnalisés en exposant la programmation GPU via Python plutôt qu’en CUDA C++ brut, ce qui rend l’optimisation au niveau kernel accessible aux ingénieurs ML et pas uniquement aux spécialistes GPU. La plupart des optimisations présentées plus loin dans cette partie (FlashAttention, kernels fusionnés, PagedAttention) sont soit de meilleurs kernels, soit des méthodes plus efficaces d’orchestration des lancements de kernels.

La fusion de kernels combine des opérations séquentielles en un seul kernel GPU et évite les écritures intermédiaires en HBM. Les fusions courantes incluent la projection QKV, attention plus softmax, add plus RMSNorm (FlashNorm) et activation SwiGLU (DeepFusionKernel). Triton rend ces kernels accessibles via Python. Les gains exacts en nombre de lancements et en utilisation dépendent du graphe du modèle, du compilateur, du GPU et du serving framework ; profilez donc la stack déployée au lieu de vous fier à un pourcentage universel.

11. FlashAttention : tuiler l’attention pour rester en SRAM

L’attention standard matérialise la matrice d’attention complète $N \times N$ en HBM, ce qui coûte $O(N^2)$ de mémoire et génère beaucoup de trafic mémoire. L’idée de FlashAttention est de ne jamais matérialiser cette matrice. Les matrices Q, K et V sont découpées en blocs qui tiennent dans la SRAM, l’attention partielle est calculée dans chaque tuile, puis les résultats sont fusionnés au moyen d’un softmax online (en suivant progressivement le maximum et la somme courants entre les blocs). La mémoire passe de $O(N^2)$ à $O(N)$, et les lectures HBM diminuent d’un ordre de grandeur.

Chaque version cible le bottleneck de la génération de GPU correspondante :

• FlashAttention v1 (A100, 2022) a démontré que l’idée du tiling associé au softmax online fonctionnait. L’article rapportait un speedup de 2–4x par rapport à l’attention standard, mais seulement 25–40 % d’utilisation GPU, car le scheduling des kernels laissait de nombreux SM inactifs.
• FlashAttention v2 (A100, 2023) a repensé le parallélisme pour le répartir selon la dimension de séquence plutôt que selon le batch et les têtes. Il a atteint 50–73 % d’utilisation sur A100, soit environ 2x plus rapide que v1.
• FlashAttention v3 (H100 Hopper, 2024) a ajouté la warp specialization (warps distincts pour les transferts de données et les calculs) ainsi que le pipelining GEMM-softmax afin de chevaucher les chargements mémoire et le calcul. L’article rapporte jusqu’à 740 TFLOPS/s en FP16 (75 % d’utilisation) et près de 1,2 PFLOPS/s en FP8 sur H100. Spotlight NeurIPS 2024.
• FlashAttention v4 (B200 Blackwell, 2026) s’attaque à un nouveau bottleneck : sur Blackwell, le débit des Tensor Cores augmente si rapidement que les opérations non matricielles (exponentielles du softmax, rescaling) deviennent le facteur limitant. FA4 émule l’exponentielle par logiciel au moyen d’approximations polynomiales sur les unités FMA, utilise un rescaling conditionnel pour réduire l’overhead et stocke les intermédiaires dans la mémoire tensorielle dédiée de Blackwell (TMEM) plutôt que dans les registres. L’article rapporte environ 1,6 PFLOPS sur B200 en BF16, soit 1,3x plus rapide que cuDNN 9.13 et 2,7x plus rapide que Triton dans ses tests.

12. FlashDecoding : paralléliser le bottleneck du decode

FlashAttention standard maintient le GPU occupé en répartissant le travail sur la taille du batch et la longueur de requête. Pendant le decode, le modèle génère exactement 1 token à la fois (longueur de requête = 1). Si la taille du batch multipliée par le nombre de têtes d’attention est inférieure au nombre total de SM du GPU (108 sur un A100), la majeure partie du GPU reste inactive pendant que quelques unités parcourent séquentiellement l’historique des tokens.

FlashDecoding résout ce problème en ajoutant une nouvelle dimension de parallélisation : la longueur de séquence KV elle-même. Il découpe le KV cache en chunks plus petits et les distribue aux processeurs GPU autrement inactifs pour les évaluer en parallèle, puis fusionne les calculs partiels avec une réduction log-sum-exp.

Dans le benchmark batch-one CodeLlama-34B de Stanford, avec des longueurs de séquence comprises entre 512 et 64K tokens, FlashDecoding a atteint jusqu’à 8x de speedup de bout en bout par rapport aux baselines testées et a maintenu la latence de l’attention presque constante jusqu’à 64K. Ce résultat est limité à ce hardware et à ce benchmark, et ne constitue pas une garantie générale pour le decode.

13. Continuous batching contre static batching

Le static batching attend que toutes les séquences d’un batch soient terminées avant de démarrer le suivant ; les séquences courtes laissent donc des cycles GPU inutilisés après avoir atteint la fin de séquence. Le continuous batching (introduit par l’article Orca, OSDI 2022) fonctionne à la granularité de l’itération : à chaque étape de decode, les séquences terminées sont retirées et de nouvelles séquences sont insérées.

Dans le benchmark OPT-13B d’Anyscale, le static batching optimisé a atteint 4x sa baseline naïve, le continuous batching 8x, et vLLM avec continuous batching plus PagedAttention a atteint 23x (Anyscale, 2023). Le continuous batching augmente également la pression sur l’allocation du KV, raison pour laquelle il est souvent associé à une gestion de mémoire paginée.

14. PagedAttention : mémoire virtuelle pour le KV cache

Le PagedAttention de vLLM applique l’idée de mémoire virtuelle des systèmes d’exploitation à la gestion du KV cache. Le KV cache est divisé en blocs de taille fixe (généralement 16 tokens), les blocs sont alloués à la demande au fil de la génération et les positions logiques (séquentielles) sont mappées vers des emplacements mémoire physiques (dispersés) via des block tables. Plusieurs requêtes partageant un préfixe (system prompts, beam search) peuvent pointer vers les mêmes blocs physiques.

Les systèmes antérieurs gaspillaient 60–80 % de la mémoire du KV cache à cause de la fragmentation et de la préallocation. PagedAttention réduit ce gaspillage à <4 %, ce qui permet d’augmenter le débit de 2–4x à latence équivalente et jusqu’à 24x par rapport à HuggingFace Transformers (vLLM Blog, 2023).

15. Speculative decoding : plusieurs tokens par forward pass

Dans le speculative decoding, un petit draft model génère $K$ tokens candidats, puis le grand target model évalue les $K$ positions en un seul forward pass. Le décodeur accepte les tokens du draft de gauche à droite selon des probabilités dérivées des distributions du target et du draft. Après le premier rejet, il échantillonne une correction depuis la distribution résiduelle du target et abandonne les tokens restants du draft. Cette étape modifiée de rejet sampling préserve la distribution de sortie du target dans les limites de l’arithmétique du hardware ; une simple correspondance exacte des tokens ne le garantit pas.

Le gain est le plus probable avec de petits batchs de serving et des longueurs de draft courtes, lorsque le scoring du draft est dominé par le trafic lié aux poids, au KV cache ou aux communications plutôt que par le calcul supplémentaire sur les tokens. L’article original sur le speculative sampling rapportait un speedup de décodage de 2–2,5x pour sa configuration Chinchilla 70B testée ; EAGLE-3 rapportait jusqu’à 6,5x dans ses tests. Les variantes incluent Medusa (têtes de prédiction supplémentaires, sans modèle séparé), le prompt lookup decoding (matching n-gram contre l’entrée, sans forward pass distinct d’un draft model) et EAGLE (extrapolation au niveau des features).

Avec de grandes tailles de batch, le travail supplémentaire du draft et de la vérification peut annuler le gain. Le speculative decoding est surtout prometteur lorsque le batch de serving est assez petit et que le taux d’acceptation du draft est élevé ; mesurez la boucle complète de serving plutôt que le kernel de vérification seul.

16. Prefix caching et réutilisation du KV cache

Au lieu de supprimer le KV cache lorsqu’une requête se termine, le prefix caching le conserve pour le réutiliser sur de nouvelles requêtes partageant les mêmes tokens de préfixe. Cela réduit le prefill redondant pour les system prompts, les exemples few-shot, le contexte RAG et l’historique des conversations multi-tours.

Automatic Prefix Caching de vLLM hashe les blocs KV et utilise une table de hachage globale pour la recherche. RadixAttention de SGLang maintient un arbre radix de tenseurs KV mis en cache avec une granularité au niveau du token. Les deux approches dépendent de préfixes identiques au niveau des tokens ; indiquez donc le taux de hit avec la latence ou le débit.

17. Le streaming en pratique

Le streaming envoie les tokens au client au fur et à mesure de leur génération au lieu d’attendre la réponse complète. De nombreux frameworks de serving l’exposent via les Server-Sent Events : le client ouvre une connexion HTTP longue durée et le serveur transmet chaque token ou batch de tokens sous la forme d’un événement data:. Le TTFT détermine le moment où l’utilisateur voit la première sortie ; le TPOT contribue à la fluidité perçue. Définissez la cible à partir de tests produit et du modèle d’interaction choisi.

Côté client, le streaming impose des décisions de buffering. Afficher les tokens un par un peut provoquer des saccades visuelles, notamment avec le markdown ou les blocs de code qui nécessitent plusieurs tokens de contexte pour être correctement formatés. Les patterns courants sont le buffering au niveau du mot (accumuler les tokens jusqu’à un espace), le buffering au niveau de la ligne (attendre un retour à la ligne) et le buffering adaptatif (afficher immédiatement le texte courant, mais bufferiser les blocs de code). Dans l’API OpenAI Chat Completions, stream_options: {"include_usage": true} ajoute un dernier chunk d’usage avant le message data: [DONE]. Les serveurs compatibles OpenAI peuvent différer ; vérifiez donc l’implémentation sélectionnée.

Le chunked prefill est une façon d’empêcher les longs prefills de bloquer la livraison des tokens aux utilisateurs concurrents. Un scheduling priorisant le decode peut protéger les requêtes en cours, tandis que le serving désagrégé isole le prefill et le decode sur des pools de GPU distincts.

Partie IV — Architecture des modèles

L’architecture détermine l’empreinte mémoire, le comportement de l’attention et la dynamique d’entraînement auxquels les sections serving et training doivent s’adapter.

18. Les fondamentaux de l’architecture Transformer

Un Transformer decoder-only moderne (GPT, Llama) est une pile de couches identiques, chacune composée de deux sous-blocs : attention et feed-forward. Chaque sous-bloc est encapsulé par une connexion résiduelle et une normalisation. Les composants clés sont les suivants :

La Multi-Head Attention permet à chaque token de pondérer les informations provenant des tokens visibles sous le masque d’attention. L’entrée est projetée en trois matrices : Queries (que cherché-je ?), Keys (que contiens-je ?) et Values (quelle information transporté-je ?). Les scores d’attention sont ensuite calculés ainsi :

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

Le produit scalaire $QK^T$ mesure la similarité entre chaque paire de tokens. La division par $\sqrt{d_k}$ empêche les produits scalaires de devenir trop grands, ce qui pousserait le softmax dans des régions où les gradients s’annulent. Le softmax convertit les scores en probabilités, et la multiplication par $V$ produit une combinaison pondérée des vecteurs Value. Exécuter cela en parallèle sur plusieurs têtes permet au modèle de porter son attention sur différentes relations simultanément (une tête pour la syntaxe, une autre pour la coréférence, etc.).

Le Feed-Forward Network (FFN) transforme indépendamment chaque représentation de token après que l’attention a mélangé les informations entre tokens. Les LLM modernes utilisent souvent SwiGLU à la place du FFN ReLU original à deux matrices :

$\text{SwiGLU}(x) = \left(\text{Swish}(xW_{gate}) \odot xW_{up}\right)W_{down}$

SwiGLU possède trois matrices de poids, contre deux pour un FFN ReLU, et utilise l’activation Swish lissée. Llama, Mistral et Qwen l’utilisent ; Gemma utilise une GeGLU approximative. La règle familière des deux tiers s’applique à un bloc full-MHA conventionnel avec $d_{ff} \approx 4d$ : ses deux matrices FFN contribuent environ $8d^2$ paramètres, contre environ $4d^2$ pour l’attention. Il ne s’agit pas d’une estimation générale pour les architectures SwiGLU/GQA. Dans Llama 3 8B, $d=4{,}096$, $d_{ff}=14{,}336$ et huit têtes key/value donnent un FFN de $3d \times d_{ff} \approx 176$M paramètres par couche, contre environ 42M paramètres de projection d’attention : environ 81 % de ces poids de projection, avant les embeddings et la normalisation.

Les connexions résiduelles ajoutent la sortie de chaque sous-bloc à son entrée : $\text{Output} = \text{Input} + \text{Sublayer}(\text{Input})$. Le chemin de skip améliore la propagation du signal et des gradients dans les architectures profondes.

RMSNorm est courante dans les familles modernes de LLM. LayerNorm recentre en soustrayant la moyenne et remet à l’échelle selon l’écart-type. RMSNorm ignore la soustraction de la moyenne et effectue uniquement une remise à l’échelle ; son article rapporte des speedups de 7–64 % sur les modèles testés, sans pénalité de performance dans ces expériences. Le placement pre-norm, qui normalise avant l’attention ou le FFN, est également courant car il améliore la stabilité des gradients.

Estimation du nombre de paramètres pour un modèle decoder-only :

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

où $V$ est la taille du vocabulaire, $d$ la dimension cachée et $L$ le nombre de couches. Le terme $V \times d$ correspond à la matrice d’embedding d’entrée ; le terme $12 \times d^2$ approxime les poids d’attention et du FFN de chaque couche. Pour Llama 3 8B ($V=128{,}256$, $d=4{,}096$, $L=32$), l’estimation est d’environ $0.53B + 6.44B = 6.97B$ paramètres. Le total publié de 8,03B est supérieur, car l’approximation omet des détails d’architecture tels que la largeur exacte du FFN et la projection de sortie distincte.

19. Modèles decoder-only pour la génération généraliste

Le Transformer original (2017) possédait un encoder et un decoder. Depuis, le domaine s’est divisé en trois familles architecturales, dont l’une est devenue la référence pour la generative AI.

Les modèles encoder-only (BERT, RoBERTa) utilisent une attention bidirectionnelle : chaque token porte son attention sur tous les autres tokens dans les deux directions. Cela produit des représentations riches pour les tâches de compréhension (classification, NER, similarité sémantique), mais ils ne peuvent pas générer du texte de manière autorégressive. Les modèles encoder-only restent courants comme backbone de modèles d’embedding, de rerankers et de classifieurs légers (par exemple les routeurs basés sur BERT de RouteLLM).

Les modèles encoder-decoder (T5, BART, le Transformer original) séparent compréhension et génération. L’encoder traite l’entrée complète avec une attention bidirectionnelle, puis le decoder génère la sortie de manière autorégressive en portant son attention sur les représentations de l’encoder via la cross-attention. Cette architecture était naturellement avantageuse pour les tâches sequence-to-sequence telles que la traduction, où l’entrée et la sortie sont deux séquences distinctes. Le T5 de Google a montré que toute tâche NLP pouvait être formulée en text-to-text, et les modèles encoder-decoder alimentent encore certains systèmes spécialisés (Whisper pour la reconnaissance vocale, FLAN-T5 pour le suivi d’instructions).

Les modèles decoder-only (GPT, Llama, Mistral, Gemini) utilisent une attention causale (unidirectionnelle) : chaque token ne porte son attention que sur les tokens précédents. Ils sont courants pour la génération généraliste, car un objectif de modèle de langage causal s’étend sur du texte non apparié, tandis que l’inférence traite les instructions, les démonstrations few-shot et la requête comme des tokens dans un même préfixe. Le bloc decoder répété évite également une pile encoder séparée et un chemin de cross-attention. Les modèles encoder-decoder restent utiles lorsqu’une tâche bénéficie d’un encodage séparé de l’entrée et d’une génération conditionnée par cette représentation, notamment pour la traduction et la reconnaissance vocale.

20. Mixture of experts

MoE remplace le FFN dense de chaque couche Transformer par plusieurs expert FFN plus un gating router léger. Le routeur calcule un score pour chaque expert (généralement un softmax sur des projections linéaires apprises) et sélectionne les experts top-$k$ pour chaque token. Seuls les experts activés calculent, ce qui permet à un modèle d’avoir une capacité totale considérable tout en conservant un coût par token limité. Il s’agit d’un calcul conditionnel sparse : le nombre total de paramètres définit ce que le modèle peut représenter, tandis que les paramètres actifs définissent ce qu’il coûte à exécuter.

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

L’entraînement MoE présente trois problèmes récurrents : déséquilibre de charge, effondrement des experts et overhead de communication pour l’expert parallelism. Les modèles MoE traditionnels ajoutent une loss auxiliaire pour pénaliser le routage déséquilibré, mais cette loss peut entrer en concurrence avec l’objectif principal. DeepSeek-V3 utilise principalement une stratégie sans loss auxiliaire, appliquée au niveau du batch : des termes de biais hors backpropagation diminuent le score des experts surchargés et augmentent celui des experts sous-utilisés. Le modèle applique également une loss d’équilibrage séquentiel complémentaire extrêmement faible pour éviter un déséquilibre extrême au sein d’une séquence. L’article rapporte un meilleur équilibrage du routage sans le compromis associé à la loss auxiliaire principale dans sa configuration.

21. Tokenisation : BPE, SentencePiece et tiktoken

Les LLM ne voient pas du texte. Ils voient des séquences d’IDs de tokens entiers. Un tokenizer découpe le texte brut en tokens (sous-mots) et associe chacun à un ID. Le choix du tokenizer affecte la qualité du modèle, la vitesse d’inférence et l’équité multilingue.

Le Byte Pair Encoding (BPE) est l’algorithme le plus courant. Il fusionne itérativement les paires adjacentes les plus fréquentes du corpus d’entraînement. Exemple simplifié :

1. Commencer avec un vocabulaire au niveau des caractères : [l, o, w, e, r, _]
2. La paire la plus fréquente est (l, o) → fusion en lo → vocabulaire : [l, o, w, e, r, _, lo]
3. La paire suivante la plus fréquente est (lo, w) → fusion en low → le vocabulaire ajoute low
4. Continuer jusqu’à atteindre la taille cible du vocabulaire (par exemple 128K tokens)

Les mots courants comme « the » deviennent des tokens uniques, tandis que les mots rares comme « defenestration » sont découpés en sous-mots tels que ["def", "en", "est", "ration"]. Le compromis porte sur la taille du vocabulaire et la longueur des séquences.

Trois implémentations de tokenizer couvrent la plupart des usages en production :

• SentencePiece s’entraîne directement sur du texte Unicode brut, sans pré-tokenizer spécifique à la langue. Il préserve les espaces au moyen du méta-symbole ▁ et peut éventuellement utiliser des tokens octets UTF-8 comme fallback. Il prend en charge les modèles BPE et unigram et est utilisé par Llama 1/2, T5 et Mistral.
• tiktoken est le tokenizer basé sur Rust d’OpenAI, qui utilise un BPE au niveau des octets. Dans son benchmark GPT-2 publié, il s’exécutait 3–6x plus vite que la configuration GPT2TokenizerFast testée. Llama 3 est passé de SentencePiece à l’algorithme de tiktoken.
• Hugging Face Tokenizers est une bibliothèque largement utilisée, basée sur Rust, qui prend en charge BPE, WordPiece et Unigram.

La fertilité mesure le nombre de tokens produits par un mot ou une autre unité de texte choisie. Elle varie selon le tokenizer exact, la langue, le système d’écriture, la normalisation, le domaine et l’échantillon. Mesurez-la sur un trafic représentatif au lieu de l’extrapoler à partir d’un seul tokenizer ou d’une seule langue.

22. Fenêtres de contexte et encodages positionnels

La fenêtre de contexte est le nombre maximal de tokens qu’un modèle peut traiter lors d’un seul forward pass. Elle a fortement augmenté :

Le self-attention non masqué est permutation-equivariant : réordonner les tokens d’entrée réordonne les sorties de la même manière. Le masque causal d’un decoder limite déjà chaque token à son préfixe visible ; inverser une phrase ne produit donc pas des hidden states identiques. Les encodages positionnels ajoutent des informations explicites sur la position et la distance relative au sein de ce préfixe visible.

Trois approches sont courantes :

• RoPE (Rotary Position Embeddings) fait tourner les vecteurs query et key selon des angles dépendant de la position, de sorte que leur produit scalaire dépende de la position relative. Le contenu du token détermine toujours le score d’attention ; RoPE ajoute l’information positionnelle sans embeddings de position absolue appris. Il est utilisé par des familles de modèles open comme Llama, Mistral et Qwen.

• ALiBi (Attention with Linear Biases) évite de modifier les embeddings et ajoute directement une pénalité aux scores d’attention : plus deux tokens sont éloignés, plus le biais négatif est important. Il ne possède aucun paramètre positionnel appris. Dans l’article original, un modèle 1,3B entraîné avec des séquences de 1 024 tokens obtenait à 2 048 tokens des résultats comparables à ceux d’un modèle à positions sinusoïdales entraîné à 2 048 tokens. Le comportement au-delà des modèles et longueurs testés dans l’article dépend du modèle.

• YaRN (Yet another RoPE extensioN) étend un modèle RoPE au-delà de son contexte d’entraînement. Il regroupe les dimensions de fréquence en trois catégories et les met à l’échelle différemment. L’article rapporte 10x moins de tokens de fine-tuning et 2,5x moins d’étapes d’entraînement que sa baseline d’interpolation positionnelle.

Partie V — Entraînement et alignment

Cette partie distingue l’objectif qui crée les capacités, les techniques qui permettent de faire tenir l’entraînement dans le hardware disponible et les méthodes qui façonnent ensuite le comportement du modèle.

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

Le préentraînement est une prédiction self-supervised du token suivant sur un corpus volumineux. Son coût de calcul peut varier de plusieurs ordres de grandeur ; Llama 3 405B, par exemple, a utilisé $3.8 \times 10^{25}$ FLOPs. Le Supervised Fine-Tuning (SFT) adapte le modèle préentraîné à des données annotées spécifiques à une tâche. RLHF / RLAIF utilise des données de préférence pour façonner le comportement : un pipeline RLHF conventionnel collecte des comparaisons, entraîne un reward model, puis optimise la policy. RLAIF remplace certains jugements humains par des feedbacks générés par une AI.

Le calcul dépend de la taille du modèle, de la longueur des séquences, du volume de données, de l’optimizer et de la méthode. PPO transporte également davantage d’état de modèle que SFT, car une configuration typique inclut les modèles policy, reference, reward et critic. J’ai présenté le framework complet de décision sur le fine-tuning dans le Guide du fine-tuning des LLM.

24. LoRA et QLoRA : fine-tuning efficace en paramètres

LoRA gèle les poids préentraînés et injecte des matrices entraînables de faible rang $A$ ($r \times k$) et $B$ ($d \times r$), de sorte que le poids mis à jour soit $W_0 + BA$. Dans sa configuration, l’article LoRA a réduit GPT-3 175B à environ 18 millions de paramètres entraînables. Le rang est un hyperparamètre, pas une règle de complexité de tâche ; sélectionnez-le au moyen d’un sweep qualité/mémoire. Les adapters LoRA peuvent être fusionnés dans les poids de base après l’entraînement afin d’éviter un chemin d’adapter séparé à l’inférence.

QLoRA charge le modèle de base avec une quantification 4 bits NF4 tout en entraînant les adapters LoRA en BF16. NormalFloat4 place davantage de niveaux de quantification près de zéro, là où la densité des poids est la plus élevée. L’article a fine-tuné un modèle 65B sur un seul GPU de 48 Go et rapporté des résultats proches de ses baselines en 16 bits. Ses compromis runtime et mémoire sont spécifiques à la stack testée.

25. Entraînement en précision mixte

Chaque format en virgule flottante répartit ses bits entre trois champs : signe (toujours 1 bit), exposant (détermine la plage dynamique) et mantisse (détermine la précision). Un plus grand nombre de bits d’exposant offre une plage plus large de magnitudes représentables ; un plus grand nombre de bits de mantisse permet de distinguer plus finement des valeurs proches. Les formats entiers n’ont pas d’exposant et représentent uniquement des nombres entiers régulièrement espacés dans une plage fixe.

BF16 possède la même plage que FP32, car la plage est déterminée par le champ d’exposant, et BF16 conserve les 8 bits d’exposant de FP32. En revanche, il abandonne des bits de mantisse (7 contre 23), échangeant de la précision contre une réduction de mémoire de 2x tout en évitant de nombreux problèmes de plage qui affectent l’entraînement FP16. FP16 ne dispose que de 5 bits d’exposant, ce qui limite sa plage finie à environ 65K. De nombreux gradients sont au contraire trop petits pour FP16 et passent à zéro par underflow. Le loss scaling multiplie la loss avant le backpropagation afin que ces gradients restent représentables, puis les remet à l’échelle avant l’étape de l’optimizer ; le scaling dynamique réduit le facteur en cas d’overflow. La plage d’exposant plus large de BF16 évite généralement cette exigence.

Les formats entiers sont peu courants pour l’arithmétique principale de l’entraînement, car le backpropagation nécessite une large plage dynamique. Ils sont largement utilisés pour l’inférence, où les poids gelés peuvent être mappés vers des échelles calibrées. La quantification INT4 des poids réduit un modèle 7B d’environ 14 Go à 3,5 Go avant l’overhead du runtime ; la qualité doit être mesurée pour le modèle et la méthode choisis.

L’entraînement FP8 sur H100 via Transformer Engine utilise E4M3 lorsque la précision est importante et E5M2 lorsqu’une plage plus large est nécessaire. L’article FP8-LM rapporte que son framework en précision mixte a entraîné GPT-175B 75 % plus rapidement que sa baseline Megatron-LM BF16 et 37 % plus rapidement que NVIDIA Transformer Engine dans la configuration H100 testée. DeepSeek-V3 a utilisé la précision mixte FP8 et rapporté environ $5,6 millions de coût de calcul équivalent à la location pour son run d’entraînement final, hors R&D et infrastructure.

26. Gradient checkpointing

Chaque couche du forward pass produit une sortie intermédiaire appelée activation :

$\text{Input} \rightarrow [\text{Layer 1}] \rightarrow \text{activation}_1 \rightarrow [\text{Layer 2}] \rightarrow \text{activation}_2 \rightarrow [\text{Layer 3}] \rightarrow \text{output}$

Normalement, toutes les activations doivent rester en mémoire, car le backpropagation en a besoin pour calculer les gradients. Pour un Transformer profond, les activations stockées peuvent consommer davantage de mémoire que les poids du modèle eux-mêmes.

Le gradient checkpointing échange du calcul contre de la mémoire en supprimant la plupart des activations puis en les recalculant à la volée pendant le backpropagation. La stratégie standard (Chen et al., 2016) divise un réseau de $n$ couches en $\sqrt{n}$ segments régulièrement espacés et ne sauvegarde que l’activation frontière de chaque segment. Ces frontières sauvegardées sont les « checkpoints ». Toutes les activations intermédiaires d’un segment sont supprimées immédiatement.

Lorsque le backward pass atteint une couche au sein d’un segment, ses activations sont recalculées depuis le checkpoint le plus proche. Avec cette stratégie de segmentation régulière, la mémoire d’activation sauvegardée passe de $O(n)$ à $O(\sqrt{n})$. Les économies réelles et l’overhead de recalcul dépendent du modèle, des frontières des checkpoints, de la longueur de séquence, du framework et de l’implémentation ; mesurez donc les deux sur le run d’entraînement cible. Activez-le dans HuggingFace avec gradient_checkpointing=True.

27. Étapes ZeRO de DeepSpeed

Dans le data parallelism standard, chaque GPU contient une copie complète des poids du modèle, des gradients et des états de l’optimizer. Avec Adam, chaque paramètre occupe 2 octets pour le poids FP16 + 4 octets pour le poids maître FP32 + 4 octets pour le momentum + 4 octets pour la variance + 2 octets pour le gradient, soit 16 octets par paramètre. Un modèle de 7,5B paramètres nécessite environ 120 Go par GPU, et chaque GPU stocke la même chose. Sur 64 GPU, cela représente 64 copies identiques de 120 Go. Un gaspillage considérable.

DeepSpeed ZeRO (Zero Redundancy Optimizer) supprime cette duplication en shardant ces composants entre les GPU au lieu de les répliquer :

• Stage 1 — partitionner les états de l’optimizer. Chaque GPU ne stocke que 1/N des états de l’optimizer (poids maîtres FP32 et premiers et seconds moments d’Adam, 12 octets/paramètre). Lorsqu’un GPU doit mettre à jour un poids, il ne met à jour que sa portion puis diffuse le résultat. Selon les hypothèses ci-dessous, la mémoire passe d’environ 120 Go à ~41,3 Go par GPU.
• Stage 2 — partitionner également les gradients. Les gradients (2 octets/paramètre) ne sont plus all-reduce vers chaque GPU. Chaque GPU ne reçoit que la portion de gradient dont il a besoin via reduce-scatter. Avec les mêmes hypothèses, la mémoire passe à ~28,1 Go par GPU.
• Stage 3 — partitionner également les poids du modèle. Chaque GPU ne conserve que 1/N des poids FP16. Avant le forward ou backward pass de chaque couche, le GPU appelle all-gather pour reconstruire temporairement les poids complets de la couche depuis les autres GPU, effectue le calcul, puis libère les poids rassemblés. Avec les mêmes hypothèses, la mémoire passe à ~15,0 Go par GPU.

Il s’agit de valeurs approximatives d’état du modèle pour un modèle de 7,5B paramètres sur 8 GPU (world size $N=8$), avec poids et gradients FP16 et poids maîtres, momentum et variance Adam FP32. Elles excluent les activations, les buffers all-gather temporaires, la fragmentation de l’allocator et l’overhead du framework/runtime. La base de calcul est $7.5B \times$ octets par paramètre, chaque état n’étant divisé par $N$ que lorsque le tableau l’indique comme partitionné.

Le compromis concerne la communication. Le Stage 1 ajoute un overhead minimal, tandis que le Stage 2 remplace l’all-reduce par un reduce-scatter à un coût similaire. Le Stage 3 nécessite des appels all-gather avant chaque couche, dans les forward et backward passes, soit environ 1,5x le volume de communication du data parallelism standard.

ZeRO-Infinity étend le Stage 3 en déportant les états partitionnés vers la RAM CPU et même vers des SSD NVMe, ce qui peut rendre possible l’entraînement de modèles à plusieurs milliers de milliards de paramètres sur des clusters GPU limités. L’offloading vers le stockage ajoute un coût PCIe et de transfert ; son impact mesuré dépend du disque, de la topologie PCIe, du partitionnement, du prefetch, du chevauchement des transferts et du workload. Utilisez-le pour satisfaire des contraintes de capacité plutôt que de supposer un ralentissement fixe, et profilez la configuration cible.

28. FSDP : sharding natif de PyTorch

Fully Sharded Data Parallel (FSDP) est la réponse intégrée de PyTorch à DeepSpeed ZeRO-3. Il sharde les paramètres, les gradients et les états de l’optimizer entre les GPU selon la même idée centrale. Pour chaque couche, le mécanisme suit une boucle simple :

1. All-gather des paramètres complets depuis tous les GPU (reconstruction temporaire de la couche complète).
2. Calcul du forward ou backward pass de cette couche.
3. Libération immédiate des paramètres rassemblés. Chaque GPU ne conserve que son propre shard.
4. Reduce-scatter des gradients afin que chaque GPU ne reçoive que la portion de gradient qui lui est attribuée.

Comme FSDP est natif de PyTorch, il s’intègre directement aux outils de debugging et aux profilers PyTorch, ainsi qu’à torch.compile. Les performances relatives à DeepSpeed ZeRO-3 dépendent de la politique de wrapping, de la topologie de communication, des paramètres d’offloading et de la taille du modèle ; comparez-les donc sur le même cluster.

FSDP2 (2024–2025) est une réécriture qui améliore l’intégration de torch.compile pour permettre une meilleure fusion de kernels, ajoute le support de l’entraînement FP8 via TorchAO et simplifie l’API. FSDP et DeepSpeed sont tous deux accessibles via HuggingFace Accelerate, ce qui permet de passer de l’un à l’autre avec une seule modification de configuration.

29. Lois d’échelle et piège de Chinchilla

Le scaling Chinchilla (DeepMind, 2022) a identifié, selon ses hypothèses, une allocation compute-optimal proche de 20 tokens d’entraînement par paramètre. Cet objectif n’inclut pas le coût de serving en aval. Si un modèle plus petit entraîné sur davantage de données atteint la qualité requise, il peut coûter moins cher sur l’ensemble de son cycle de vie d’inférence à fort volume.

Une stratégie de coût sur le cycle de vie consiste à entraîner un modèle plus petit sur beaucoup plus de données :

Il s’agit du ratio tokens/paramètre affiché, divisé par le point approximatif de 20 tokens par paramètre du papier Chinchilla. C’est un ratio descriptif, pas un multiplicateur mesuré de qualité ou de coût.

Pour un modèle servi à fort volume, consacrer davantage de calcul d’entraînement à un modèle plus petit peut réduire le coût du cycle de vie. Llama 3 8B illustre cette stratégie, mais sa pertinence dépend de la qualité requise et du volume d’inférence prévu. « Chinchilla-optimal » désigne l’efficacité du compute d’entraînement, qui est un objectif différent du coût du cycle de vie.

30. RLHF, DPO, GRPO et paysage de l’alignement

L’alignment 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 la véracité ni la sûreté du comportement. Les méthodes ci-dessous arbitrent entre complexité d’implémentation, besoins en données, exploration et stabilité de l’entraînement.

Le pipeline RLHF classique : SFT → collecte de paires de préférences humaines → entraînement d’un reward model sur ces paires → fine-tuning de la policy avec PPO (Proximal Policy Optimization). PPO conserve 4 copies du modèle en mémoire simultanément (policy, reference, critic/value model, reward model) et est sensible aux hyperparamètres. Il est également sujet au reward hacking, lorsque le modèle exploite des particularités du reward model, par exemple des réponses longues et formulées avec assurance, au lieu d’améliorer réellement la qualité.

DPO (Direct Preference Optimization) supprime le reward model appris et la boucle de RL online en optimisant directement une loss sur des paires de préférences. Le pipeline d’entraînement est ainsi simplifié. Le DPO standard est offline : il s’entraîne sur un dataset fixe et n’explore pas de nouvelles réponses pendant la boucle 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) supprime le critic appris de PPO en générant plusieurs complétions par prompt et en utilisant des récompenses relatives au groupe comme baseline. Cela réduit la charge d’état du modèle par rapport à une configuration PPO typique. Contrairement à DPO, GRPO est on-policy : le modèle génère de nouvelles réponses pendant l’entraînement. DeepSeek-R1 combine GRPO avec RLVR (reinforcement learning from verifiable rewards), en utilisant des vérifications telles que les réponses 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 et des objectifs proxy peuvent toujours être exploités.

31. Distillation : transférer des connaissances entre modèles

La distillation de connaissances transfère les capacités d’un teacher volumineux vers un student plus petit. La distillation basée sur les logits entraîne le student à reproduire la distribution de sortie du teacher. La distillation basée sur les données demande au teacher de générer des exemples sur lesquels le student est ensuite fine-tuné. Les méthodes basées sur les données sont courantes pour les LLM, car elles fonctionnent entre architectures et avec des teachers accessibles uniquement via API, mais leur valeur est limitée par la qualité du teacher, la couverture des données, le filtrage et le coût de génération.

DeepSeek-R1 a constitué un mélange d’environ 800 000 exemples — environ 600 000 échantillons liés au raisonnement et 200 000 échantillons non liés au raisonnement — puis l’a utilisé pour distiller des modèles Qwen2.5 et Llama 3 de 1,5B à 70B paramètres. Dans l’évaluation de l’article :

• DeepSeek-R1-Distill-Qwen-32B obtient 72,6 % sur AIME 2024 et 94,3 % sur MATH-500, au-dessus des scores OpenAI o1-mini rapportés dans l’article.
• DeepSeek-R1-Distill-Qwen-7B obtient 55,5 % sur AIME 2024, au-dessus du résultat de QwQ-32B-Preview rapporté dans l’article, avec un modèle plus petit.

Dans les expériences de DeepSeek-R1 sur les petits modèles, la distillation a surpassé le GRPO direct sur les modèles de base testés. Ce résultat soutient la distillation dans cette configuration ; il n’établit pas un classement universel entre distillation et RL.

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

Les données d’entraînement générées par des LLM sont utilisées selon plusieurs patterns récurrents :

• Self-Instruct part d’un petit ensemble seed d’instructions écrites par des humains : le LLM génère de nouvelles instructions, entrées et sorties, qui sont filtrées puis réinjectées dans le pool. Le projet Alpaca a utilisé 52 000 exemples générés à partir de 175 seeds. Stanford a indiqué un coût de génération inférieur à $500 and fine-tuning under$100, portant le coût de la première reproduction sous $600 ; sa comparaison avec GPT-3.5 était une évaluation limitée au projet, et non une équivalence générale.
• Evol-Instruct (WizardLM) prend des instructions existantes et les fait évoluer itérativement selon des axes de complexité (ajout de contraintes, approfondissement du raisonnement, concrétisation des problèmes) afin de produire des exemples d’entraînement progressivement plus difficiles.
• Phi-4 (14B) de Microsoft a utilisé des données synthétiques pour une grande partie du préentraînement, notamment pour la génération, la critique, l’auto-révision et l’inversion d’instructions. Son rapport technique compare les performances STEM et coding obtenues à celles de modèles plus grands sur les benchmarks sélectionnés.

Le risque important ici est le model collapse : lorsque des modèles sont entraînés récursivement sur des données synthétiques issues des générations précédentes, les extrémités de la distribution d’origine disparaissent progressivement. Le modèle surestime les patterns courants et perd des variations rares mais importantes (Shumailov et al., 2024). Une étude distincte d’Ahrefs a échantillonné une page anglophone nouvellement détectée par domaine parmi 900 000 pages en avril 2025 et classé 74,2 % d’entre elles comme contenant du texte partiellement généré par une AI. Cette étude d’un fournisseur n’est pas un recensement du Web. La mitigation commence par mélanger données synthétiques et réelles, filtrer les données et suivre leur lineage afin de pouvoir mesurer les contenus générés récursivement.

Partie VI — Passage à l’échelle et déploiement

Lorsqu’un workload ne tient plus sur un seul device ou ne respecte plus son SLO, les choix portent sur la manière de répartir le travail, le runtime qui expose les contrôles nécessaires et la question de savoir si toutes les requêtes ont besoin du même modèle.

33. Quatre formes de parallélisme

Le Tensor Parallelism (TP) répartit les matrices de poids individuelles entre les GPU et communique généralement après chaque couche. Les interconnexions intra-nœud rapides telles que NVLink le rendent particulièrement pratique au sein d’un nœud. Davantage de shards réduisent la mémoire et le calcul par device, mais augmentent les communications ; choisissez donc le degré à partir d’un benchmark de latence.

Le Pipeline Parallelism (PP) répartit séquentiellement les couches entre les GPU et transmet les activations entre les stages. Son pattern de communication peut fonctionner entre les nœuds, mais les bulles du pipeline et les durées inégales des stages réduisent l’utilisation. Les déploiements importants combinent souvent TP au sein d’un nœud et PP entre les nœuds.

Le Data Parallelism (DP) réplique le modèle servi afin que chaque réplique traite des requêtes indépendantes sans communication inter-répliques par requête. Il est efficace lorsque le modèle tient sur le device et que le trafic peut être équilibré. En entraînement, le DP est couramment combiné à ZeRO ou FSDP pour sharder l’état.

L’Expert Parallelism (EP) distribue les experts MoE entre les GPU au moyen de communications all-to-all pour router les tokens. Ses performances dépendent de l’équilibre des tokens, du placement des experts et de la topologie d’interconnexion ; le trafic all-to-all peut devenir le bottleneck dominant.

Heuristique de départ pour le parallélisme :

• Le modèle tient sur un GPU : commencez par des répliques indépendantes et mesurez le scaling DP.
• Le modèle tient dans un nœud : testez le TP au sein du nœud, puis répliquez le groupe si le trafic l’exige.
• Le modèle s’étend sur plusieurs nœuds : testez une combinaison TP et PP en fonction de l’interconnexion et de la cible de latence.
• Mixture of experts : ajoutez l’EP uniquement lorsque le placement des experts l’exige.

34. Comparaison des serving frameworks

vLLM fournit une allocation paginée du KV, du continuous batching, une API compatible OpenAI et plusieurs modes de parallélisme. Son support des modèles et du hardware évolue rapidement ; vérifiez le modèle cible dans la matrice de compatibilité actuelle.

SGLang combine RadixAttention pour la réutilisation des préfixes, un scheduler personnalisé et la génération structurée. Ses gains de débit publiés dépendent du workload et de la configuration ; comparez-le à vLLM et TensorRT-LLM avec des prompts, sorties, hardware et SLO identiques.

TensorRT-LLM cible une faible latence par requête grâce à la fusion des CUDA graphs et à l’optimisation des kernels, avec un support natif de FP8/FP4. Ses chiffres publiés sont spécifiques au hardware et au modèle. Le compromis est une courbe d’apprentissage plus raide et une surface de déploiement spécifique à NVIDIA.

TGI s’intègre à l’écosystème Hugging Face et prend en charge plusieurs backends hardware. Vérifiez l’état actuel de maintenance et des fonctionnalités du repository avant de le sélectionner pour un nouveau déploiement.

Ollama privilégie un workflow local simple pour les modèles. Utilisez-le pour sa commodité en développement ; lorsque la forte concurrence ou le contrôle explicite du SLO compte, benchmarkez une autre stack de serving.

llama.cpp est un runtime portable en C/C++ avec des chemins ARM, x86, Metal, CUDA, ROCm et Vulkan. GGUF prend en charge plusieurs niveaux de quantification. Les performances varient fortement selon le modèle, la quantification, le contexte et le backend ; utilisez l’outil de benchmark local pour la machine cible.

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

Le tableau compare des caractéristiques hardware publiées. Le support d’une précision par le fournisseur ne rend pas directement comparables les chiffres de calcul maximal entre formats ; commencez donc par vérifier que le modèle tient en mémoire et benchmarkez le workload cible. Vérifiez séparément les prix cloud actuels, car ils varient selon le fournisseur, la région, l’engagement et la disponibilité.

Commencez par la capacité mémoire, puis choisissez selon le débit mesuré à la cible de latence. La capacité de 141 Go du H200 peut simplifier certains déploiements de grands modèles, tandis que le B200 ajoute le support FP4, 180 Go de HBM3e et une génération NVLink plus récente. Les GPU plus petits basés sur GDDR peuvent être économiques pour les modèles quantifiés lorsque leurs limites de mémoire et d’interconnexion correspondent au workload.

AWQ et GPTQ servent des modèles 4 bits en déquantifiant les opérations matricielles prises en charge vers un format de calcul tel que FP16 ou BF16. La compatibilité et la vitesse dépendent toujours de l’architecture du modèle, du format de quantification, du backend de serving, du kernel et du GPU ; vérifiez donc la matrice de support du backend et benchmarkez l’artefact exact. Hopper (H100/H200) et Ada (L40S/4090) accélèrent nativement la FP8, et Blackwell (B200) ajoute des Tensor Cores FP4 natifs. Tous les GPU listés prennent en charge les opérations matricielles INT8.

Le decode LLM est souvent memory-bound ; la capacité et la bande passante HBM peuvent donc compter davantage que les TFLOPS de pointe pour les workloads de serving. Comparez les GPU en maintenant constants le modèle, la précision, la distribution des batchs, la longueur de contexte et la cible de latence.

36. Cascading et routage de modèles

Le model routing choisit le LLM qui traitera chaque requête en fonction de sa complexité ou de sa capacité prédite. RouteLLM (LMSYS/UC Berkeley, ICLR 2025) rapporte une réduction de coût de 85 % sur sa configuration MT-Bench tout en conservant 95 % de la baseline de qualité GPT-4. La rentabilité du routage dépend des prix actuels, du mix de trafic, des erreurs du routeur et du niveau de qualité minimal.

Les routeurs vont de classifieurs légers à des juges basés sur des LLM. Le cascading est la variante séquentielle : une requête commence avec un modèle moins cher et escalade lorsqu’une fonction de scoring rejette la réponse. FrugalGPT rapporte jusqu’à 98 % de réduction des coûts ou jusqu’à 4 % d’accuracy supplémentaire sur son pool de modèles évalué. Un cascade de production nécessite des critères d’escalade calibrés et un monitoring des requêtes incorrectement acceptées par le modèle économique.

Partie VII — Applications

Les applications ajoutent leurs propres surfaces de défaillance. La retrieval peut échouer avant même le début de la génération, les agents peuvent choisir une action invalide et une modification de prompt peut améliorer une tâche tout en en dégradant une autre.

37. Modèles d’embeddings contre modèles génératifs

Les modèles d’embeddings encodent le texte en vecteurs de dimension fixe qui capturent sa signification sémantique. Contrairement aux modèles génératifs qui produisent des séquences de tokens, ils renvoient un seul vecteur dense pour l’entrée, généralement de quelques centaines à plusieurs milliers de dimensions. Leurs backbones incluent des Transformer encoder-only bidirectionnels et des modèles dérivés de decoders adaptés à l’apprentissage de représentations. Une couche de pooling réduit souvent les représentations par token à un seul vecteur via un mean pooling, un token de classification spécial ou une méthode last-token propre au modèle. Un fine-tuning contrastif rapproche ensuite les textes sémantiquement similaires et éloigne les textes dissemblables.

Les systèmes d’embeddings actuels couvrent différents besoins de déploiement. Qwen3-Embedding-8B prend en charge des dimensions de sortie configurables et de nombreuses langues. Gemini Embedding 2 accepte du texte, des images, de la vidéo, de l’audio et des documents. pplx-embed-v1-4B étudie les embeddings denses en basse précision. OpenAI text-embedding-3-large prend en charge des embeddings raccourcis via son paramètre dimensions. Ce sont des exemples, pas un classement : évaluez la langue, la modalité, la tâche, la dimension et le coût de serving sur un même jeu de retrieval.

La Matryoshka Representation Learning (MRL, Kusupati et al., NeurIPS 2022) rend les dimensions d’embedding flexibles. Nommée d’après les poupées russes gigognes, MRL structure un embedding de sorte que ses $m$ premières dimensions soient aussi informatives qu’un modèle de dimension $m$ entraîné indépendamment. Pendant l’entraînement, MRL agrège les losses sur un ensemble $O(\log d)$ de dimensions préfixes, généralement des divisions par deux cohérentes ; l’exemple à 2 048 dimensions de l’article utilise $\{8, 16, \ldots, 1024, 2048\}$. La loss agrégée pousse les dimensions initiales à porter les informations sémantiques générales, tandis que les dimensions suivantes ajoutent des détails plus fins.

Après l’entraînement, un embedding MRL peut être tronqué à une dimension préfixe prise en charge. OpenAI rapporte que text-embedding-3-large à 256 dimensions surpasse text-embedding-ada-002 à 1 536 dimensions dans la comparaison MTEB citée. Cela donne une réduction de 6x du stockage brut des vecteurs ; la latence de recherche et le coût de la base de données dépendent également de l’index, des métadonnées, du filtrage et du hardware.

Le modèle d’embedding est un composant important d’une pipeline RAG, aux côtés du parsing, du chunking, de la recherche, du reranking et de la génération. Si les éléments pertinents ne sont pas récupérés, un générateur plus puissant ne peut pas les retrouver de manière fiable.

38. Architecture RAG en production

La Retrieval-Augmented Generation fournit à un LLM des documents récupérés au moment de la requête. Elle peut apporter des éléments actuels ou privés absents des poids du modèle, mais la retrieval ne garantit pas que la réponse utilisera correctement ces éléments. Un système RAG de production est une pipeline en plusieurs étapes, chacune devant être évaluée séparément.

La pipeline d’ingestion s’exécute offline. Les documents bruts (PDF, HTML, Markdown, bases de données) sont d’abord parsés en texte propre, ce qui est plus difficile qu’il n’y paraît : le parsing PDF seul peut perdre les tableaux, les en-têtes et la mise en forme. Le texte est ensuite divisé en chunks, qui sont embed individuellement puis indexés.

Le chunking affecte à la fois le recall de la retrieval et le contexte disponible pour le générateur. Les tailles utiles dépendent de la structure du document, de la granularité de la requête, des limites de l’embedder et de celles du reranker. Les approches courantes sont le fixed-size avec overlap, le recursive splitting selon les frontières du document et le semantic chunking fondé sur la similarité des embeddings. Comparez-les avec des labels de pertinence au niveau de la page ou de la section au lieu d’adopter universellement une seule plage de tokens.

Chaque chunk est ensuite embed avec un modèle comme ceux de la section 37, puis stocké dans une base vectorielle (Pinecone, Weaviate, Qdrant, pgvector, etc.).

La pipeline de retrieval s’exécute au moment de la requête. Commencez par une baseline mesurable, puis ajoutez des étapes lorsque l’analyse des erreurs montre qu’elles corrigent un manque réel :

• La recherche hybride combine une retrieval dense par vecteurs et une retrieval sparse telle que BM25, souvent fusionnées avec la Reciprocal Rank Fusion (RRF). La recherche dense gère les paraphrases sémantiques ; la recherche sparse intercepte les identifiants exacts, les codes d’erreur et les acronymes. Les benchmarks de fournisseurs rapportent des gains par rapport aux baselines vector-only, mais leur ampleur dépend du corpus et des labels de pertinence.
• Le reranking transmet les candidats récupérés à un modèle qui score conjointement la requête et le document. Il peut améliorer la pertinence fine au prix d’un appel de modèle supplémentaire. Le nombre de candidats, le nombre de résultats conservés et la latence doivent être réglés ensemble. J’ai couvert la pipeline multi-stage complète dans Building a Modern Search Ranking Stack.
• La transformation de requête réécrit la requête utilisateur avant la retrieval afin d’améliorer le recall. HyDE (Hypothetical Document Embeddings) demande au LLM de générer une réponse hypothétique, qui est ensuite embed et utilisée pour la retrieval. La multi-query expansion génère plusieurs formulations d’une même question. Le step-back prompting pose d’abord une question plus générale afin de récupérer un contexte plus large.

Les modes de défaillance courants sont les suivants :

• Échec de la retrieval — le bon document existe, mais n’est pas récupéré. Testez le chunking, la transformation de requête, la recherche hybride et le filtrage des métadonnées par rapport au cas manqué.
• Empoisonnement du contexte — des chunks récupérés mais non pertinents induisent le LLM en erreur. Testez le reranking, les filtres de contexte et des ensembles conservés plus petits.
• Lost-in-the-middle — dans les configurations testées de question-réponse multi-document et de retrieval de paires clé-valeur, Liu et al. ont constaté que les performances étaient généralement les meilleures lorsque l’information pertinente apparaissait au début ou à la fin de l’entrée, et plus faibles lorsqu’elle apparaissait au milieu.

GraphRAG (Microsoft, 2024) complète la retrieval vectorielle par un graphe d’entités et de relations extraites. Il cible les questions portant sur l’ensemble du corpus et les relations, que la retrieval par chunks plats peut manquer. Le compromis est un travail supplémentaire d’extraction, d’indexation, de stockage et d’évaluation.

Les guides destinés aux praticiens publient des plages de latence pour l’embedding, la recherche, le reranking et la génération, mais ces chiffres varient selon la région, le corpus, le hardware et le modèle. Mesurez chaque étape dans les traces et évaluez l’évolution de la qualité avant d’accepter la latence ajoutée.

39. Architectures d’agents et tool calling

Les agents LLM utilisent des modèles pour sélectionner et séquencer des tool calls autour d’un état qui évolue. Trois patterns d’orchestration sont particulièrement utiles :

• ReAct — alterne sélection d’actions et observations. Il peut s’adapter après chaque tool result, mais un historique croissant augmente le coût en tokens et la latence.
• ReWOO — planifie les tool calls avec des placeholders, exécute en parallèle les opérations indépendantes, puis synthétise. Son article rapporte des économies de tokens par rapport à ReAct, mais le plan fixe nécessite un chemin explicite de récupération lorsqu’un outil échoue.
• Planner-executor — sépare la planification de l’exécution et peut ajouter une policy de re-planning après un échec. Il permet la spécialisation des modèles, mais ajoute de l’état d’orchestration et une autre frontière de décision.

Le function calling est un mécanisme courant d’invocation d’outils. Les APIs exposent des définitions d’outils et renvoient des arguments structurés, ce qui réduit le besoin de parser du texte libre. Des arguments valides selon le schéma peuvent néanmoins sélectionner le mauvais outil ou contenir des valeurs invalides. Le parallel function calling peut réduire les allers-retours lorsque les opérations sont indépendantes.

Les structured outputs et le constrained decoding imposent un schéma en limitant les tokens disponibles à chaque étape de génération. Des moteurs comme xgrammar, utilisés dans vLLM et SGLang, peuvent supprimer de nombreuses erreurs de syntaxe et de parsing avec un faible overhead dans les configurations prises en charge. Ils ne garantissent pas que les valeurs extraites ou les décisions soient correctes. Le Schema-Guided Reasoning (SGR) utilise l’ordre des champs et la structure du schéma pour rendre l’état intermédiaire inspectable avant la décision finale. Ses trois patterns sont Cascade (étapes séquentielles), Routing (types union comme commutateurs sémantiques) et Cycle (listes bornées).

La qualité de sélection des outils, la latence de bout en bout et le coût en tokens se dégradent généralement lorsque le nombre d’outils et la profondeur des actions augmentent. Mesurez ces courbes avec les descriptions d’outils et la distribution réelle des échecs. Des frameworks tels que LangGraph peuvent rendre explicites l’état et les chemins de récupération, mais ils ne suppriment pas le besoin d’évaluer.

40. Prompt engineering pour la production

Le prompt engineering en production est un problème d’évaluation : modifiez une partie du prompt ou du contexte, puis mesurez la qualité de la tâche et les modes de défaillance. Les techniques ci-dessous sont des points de départ courants, pas un ordre universel.

Les exemples few-shot sont souvent efficaces pour contrôler le format de sortie. Commencez par 3–5 exemples couvrant les entrées vides, les requêtes ambiguës et les réponses multiparties, puis mesurez le résultat sur un jeu de test tenu à l’écart. Les exemples doivent couvrir la distribution réelle des entrées, pas uniquement le happy path. Davantage d’exemples consomment du contexte et ne garantissent pas de gains supplémentaires.

Le prompting chain-of-thought (CoT) demande à un modèle d’exposer son raisonnement intermédiaire avant de répondre. Kojima et al. ont rapporté des gains avec le suffixe « Let’s think step by step » sur leurs tâches de raisonnement testées, mais l’effet varie selon le modèle et les nouvelles APIs de raisonnement peuvent ne pas exposer les traces cachées. En production, préférez une décomposition inspectable de la tâche ou une justification concise lorsqu’elle est utile à l’évaluateur. La self-consistency (Wang et al., 2023) échantillonne plusieurs chemins de raisonnement et agrège les réponses, en échangeant un coût d’inférence supplémentaire contre davantage de robustesse sur les tâches adaptées.

Les structured outputs avec des schémas JSON explicites (section 39) suppriment de nombreuses erreurs de parsing. Les moteurs de constrained decoding comme xgrammar peuvent imposer la grammaire prise en charge pendant la génération ; l’exactitude factuelle et la validité sémantique nécessitent toujours une évaluation, et les fonctionnalités de schéma non prises en charge peuvent encore exiger une gestion dédiée.

Le prompt chaining divise une tâche en étapes ciblées, par exemple classifier l’intention → récupérer le contexte → générer la réponse → valider la sortie. Il peut localiser les échecs, permettre d’utiliser différents modèles à chaque étape et exposer un état intermédiaire pouvant être mis en cache. Il ajoute toutefois des interfaces et de la latence ; comparez-le donc à une baseline en appel unique.

La température modifie la distribution de sampling. Les faibles valeurs constituent un point de départ raisonnable pour la classification ou l’extraction ; des valeurs plus élevées peuvent accroître la diversité pour l’idéation. Le comportement exact diffère selon les APIs de modèles et interagit avec top_p, top_k et les valeurs par défaut du fournisseur ; faites donc un sweep des paramètres pris en charge sur la tâche au lieu de recopier une plage unique.

La séparation des messages system et user isole la policy persistante du contenu propre à chaque requête. Les chat templates et l’instruction tuning donnent à ces rôles des priorités différentes, mais ne transforment pas un message système en frontière d’enforcement. Placez le comportement stable dans le message système, gardez les données non fiables dans le contenu user ou tool et appliquez également les contraintes strictes, telles que la suppression des PII, en dehors du modèle.

Le context engineering élargit le travail sur les prompts à l’assemblage des documents récupérés, des tool results, de l’historique de conversation et des exemples. Liu et al. ont constaté un effet lost-in-the-middle sur les modèles long-context qu’ils ont testés ; la position doit donc faire partie de l’évaluation au lieu d’être considérée comme négligeable. J’ai présenté le workflow plus large dans Context Engineering for AI Agents.

Partie VIII — Opérations en production

Les opérations de production transforment les concepts précédents en limites d’admission, tests de charge, alertes et décisions de capacité sous trafic réel.

41. Rate limiting pour les requêtes à coût variable

Le rate limiting traditionnel en requêtes par seconde suppose un coût à peu près équivalent pour chaque requête. Les LLM remettent cette hypothèse en cause. Un prompt de classification de 10 tokens et une analyse de document de 100K tokens utilisent le même endpoint API, mais diffèrent de quatre ordres de grandeur en coût. Limiter par RPS laisse passer les requêtes coûteuses sans contrôle ou pénalise inutilement les requêtes peu coûteuses.

Les systèmes de production ont besoin d’un rate limiting basé sur les tokens et appliqué sur plusieurs dimensions. OpenAI documente les limites de requêtes et de tokens par niveau d’utilisation. Anthropic sépare les limites de tokens d’entrée et de sortie. Les quotas et algorithmes exacts peuvent évoluer ; considérez donc la documentation du fournisseur comme source de vérité. Le point architectural est de budgéter séparément les requêtes et les tokens.

Le pattern pratique d’implémentation est une hiérarchie de limites multidimensionnelle (utilisateur → application → organisation → global), avec des niveaux de priorité pour les accès premium. Au niveau de la requête, la technique importante est la réservation de budget de tokens : estimer le nombre total de tokens (entrée + max_tokens) au moment de l’admission, le déduire du bucket, puis l’ajuster lorsque la requête se termine avec l’usage réel. Cela empêche une rafale de requêtes générant de longues sorties d’épuiser la capacité avant même de commencer à produire des tokens.

Pour les déploiements self-hosted, l’équivalent est le débit provisionné : réserver une capacité GPU dédiée aux taux de tokens cibles. Avec les déploiements vLLM, cela signifie configurer le contrôle d’admission autour des slots de decode actifs et de la pression sur le KV cache plutôt qu’autour du seul nombre de requêtes. Comme l’explique la section 5, le débit et l’admission nécessitent tous deux des limites tenant compte des tokens.

42. Modes de défaillance à anticiper

Le serving des LLM ajoute des modes de défaillance liés à la longueur variable des séquences, à la mémoire KV et au travail de decode de longue durée. Concevez et testez en charge les défenses avant que le trafic de production n’en dépende.

Le Out-of-Memory (OOM) est une défaillance courante. Un modèle 70B FP16 nécessite environ 140 Go pour les poids seuls, et le KV cache d’une séquence Llama 3.1 70B avec un contexte de 128K peut ajouter environ 40 Go selon les hypothèses de la section 6. L’écart entre « tient en mémoire » et « OOM en charge » est plus faible qu’il n’y paraît, car un batch de requêtes long-context peut consommer plus de mémoire KV que prévu. La prévention combine une réserve mémoire mesurée avec la quantification et l’allocation paginée du KV. Pour les workloads exerçant une forte pression sur le KV, LMCache peut déporter les données KV vers la mémoire CPU ou le disque ; utilisez ses résultats publiés comme point de départ et benchmarkez la hiérarchie mémoire locale.

La préemption se produit lorsque la pression sur le KV cache force le scheduler à évincer ou recalculer du travail. La stratégie exacte dépend de la version et de la configuration du serving. Côté utilisateur, le symptôme est une latence de bout en bout plus élevée sans erreur applicative évidente. Surveillez le nombre de préemptions et corrélez-le à l’utilisation du KV, à la profondeur de la file et à la longueur des requêtes.

La latence de queue peut augmenter lorsque de grands prefills retardent le travail de decode. Le chunked prefill (section 7) et le scheduling tenant compte de la longueur ciblent cette interférence. Les articles sur le Learning-to-Rank scheduler et CascadeInfer rapportent des améliorations par rapport à leurs baselines sur les workloads évalués, mais le résultat exact dépend de la distribution des longueurs de requêtes et de la configuration du scheduler.

Les défaillances en cascade peuvent commencer lorsque les requêtes lentes allongent la file, que les clients en amont expirent et que les retries ajoutent de la charge. Les défenses incluent le contrôle d’admission, des limites de concurrence par tenant, des plafonds de sortie, des budgets de retry et des circuit breakers au niveau de la gateway. Des pools de prefill et de decode désagrégés peuvent aider lorsque les tests de charge révèlent une interférence persistante entre les phases.

43. Monitoring des systèmes LLM

Le monitoring des LLM diffère à plusieurs égards fondamentaux du monitoring d’APIs traditionnelles. Chaque requête a un coût variable, deux phases distinctes avec des bottlenecks différents et une empreinte mémoire qui dépend à la fois de la longueur d’entrée et de celle de la génération. Les métriques standard comme la latence des requêtes et le taux d’erreur manquent la plupart des éléments importants.

Le goodput est le nombre de requêtes par seconde qui respectent tous les seuils SLO définis, tels que le TTFT, le TPOT et la latence totale. C’est une métrique combinée utile, car le débit brut peut sembler sain alors que les SLO de latence échouent : un système traitant 100 requêtes par seconde mais dépassant les seuils sur 40 % d’entre elles a un goodput de 60 requêtes par seconde. Optimiser le goodput permet de conserver la distribution des performances visible au lieu de ne rapporter que la moyenne.

vLLM expose un endpoint Prometheus à /metrics, avec les requêtes en cours et en attente, l’utilisation du KV cache, les distributions de longueur de génération et les statistiques du prefix cache. Les noms des métriques peuvent changer entre les releases ; associez donc les dashboards à la version déployée. Une stack typique utilise Prometheus pour les métriques, Grafana pour la visualisation et des traces compatibles OpenTelemetry entre les composants applicatifs et de serving.

Les patterns d’alerte utiles incluent les suivants. Déduisez leurs seuils des tests de charge plutôt que de reprendre ces exemples tels quels :

• Hausse du nombre de préemptions — le runtime swap ou recalcule du travail, ce qui ajoute de la latence sans erreur applicative.
• Utilisation du KV cache proche de la zone de préemption mesurée — ajoutez de la capacité ou réduisez la charge avant que les évictions ne s’emballent.
• Profondeur de file durablement supérieure à l’enveloppe de batch testée — le contrôle d’admission doit commencer à rejeter ou déprioriser les requêtes.
• TTFT en hausse tandis que le TPOT reste stable — cette divergence indique d’abord un problème de file, d’admission, de réseau ou de pression sur le prefill plutôt qu’un problème de débit du decode. Utilisez les traces et les métriques de file pour les distinguer.

44. Optimisation des coûts : une stratégie cumulative

Les prix des fournisseurs et les ratios de prix entre tokens d’entrée et de sortie évoluent. Récupérez les tarifs actuels avant toute décision d’achat ; le niveau du modèle et la longueur des sorties peuvent dominer la facture avant même les optimisations d’infrastructure.

Plusieurs approches peuvent être combinées, mais seulement après avoir mesuré lesquelles s’appliquent au workload :

1. La quantification de FP16 vers INT4 réduit la mémoire des poids de 75 %. La réduction de facture dépend toutefois de la vitesse du kernel, de la taille du batch et de l’utilisation du hardware (section 9).
2. Le model routing envoie le trafic éligible vers des modèles moins chers. Mesurez le taux de faux positifs du routeur et la qualité de bout en bout avant d’augmenter la part traitée par le modèle économique (section 36).
3. Le prompt caching réduit le travail associé aux préfixes répétés. Les remises fournisseur et le traitement dans le rate limiting évoluent ; combinez donc le taux de hit mesuré avec les conditions actuelles (section 16).
4. Les Batch APIs peuvent réduire le coût des workloads non temps réel tels que les évaluations, la génération de données synthétiques et la classification en masse. Vérifiez les prix et les délais d’exécution actuels.
5. Le self-hosting peut être avantageux avec une utilisation soutenue, mais il n’existe pas de seuil universel de rentabilité selon le volume de tokens. Incluez les coûts d’ingénierie, d’orchestration, d’observabilité, de marge de capacité et d’astreinte, en plus de la location des GPU.

La multiplication des facteurs illustratifs donne une forte réduction théorique, mais les variables ne sont pas indépendantes : la quantification modifie le débit, le routage modifie le mix de qualité, et le caching et le batching ne s’appliquent qu’au trafic éligible. Construisez l’estimation à partir des parts de trafic mesurées et validez-la par rapport à la facture.

45. Capacity planning et autoscaling

Le capacity planning du serving LLM doit tenir compte du coût variable des requêtes, du travail de decode de longue durée et de la mémoire dépendante de la séquence. Selon le workload, la ressource limitante peut être la mémoire KV, la bande passante mémoire, le calcul ou l’interconnexion.

Le plafond mémoire théorique du nombre de requêtes concurrentes provient du budget du KV cache :

$\text{max concurrent sequences} = \frac{\text{GPU memory} - \text{model weights} - \text{overhead}}{\text{per-sequence KV cache size}}$

Pour les calculs de capacité, supposons que le runtime expose un budget KV de 40 GiB pour Llama 3.1 70B avec un KV cache FP16. Chaque séquence de 4K utilise environ 1,25 GiB et chaque séquence de 128K environ 40 GiB. Ce budget permet donc au maximum environ 32 séquences de 4K ou une séquence de 128K avant de tenir compte de l’allocator, du runtime, de la variance du workload et de l’overhead lié au SLO. C’est pourquoi la sélection du GPU et l’optimisation du KV cache pilotent directement le capacity plan.

La formule de capacité pour dimensionner la flotte :

$\text{required GPUs} = \frac{\text{peak tokens/s} \times \text{safety-factor multiplier}}{\text{per-GPU tokens/s at target SLO}}$

Convertissez les deux débits dans la même unité de temps avant de les diviser. Le détail important est « au SLO cible ». Un multiplicateur de marge tel que 1,3 réserve 30 % de headroom ; choisissez-le à partir de la burstiness mesurée, des défaillances et du temps de récupération. Le débit maximal de tokens et le débit respectant le SLO peuvent fortement diverger lorsque la concurrence augmente. Effectuez un benchmark avec la distribution réelle des longueurs de prompts et de sorties, aux seuils TTFT et TPOT requis, plutôt qu’avec un maximum théorique.

L’utilisation GPU ne suffit pas comme unique signal d’autoscaling, car elle peut rester élevée aussi bien pendant un traitement sain qu’en surcharge. Combinez-la avec la profondeur de file, l’utilisation du KV cache et la dégradation du goodput. Réglez les seuils à partir des tests de charge ; des valeurs telles que 80 % d’utilisation du KV sont des points de départ, pas des limites universelles. Ces métriques sont présentées dans la section 43.

Le scale-to-zero peut convenir aux environnements de développement et de staging connaissant de longues périodes d’inactivité. Les plateformes d’inférence serverless et les autoscalers basés sur Kubernetes tels que KEDA peuvent supprimer la capacité inactive, mais les économies et le temps de cold start dépendent de la taille du modèle, du cache de l’image et des poids, ainsi que de l’infrastructure. Mesurez le temps de démarrage avant d’appliquer la même policy à un trafic de production sensible à la latence.

Utilisez le guide pour choisir la prochaine mesure

Les concepts interagissent, mais ils conduisent malgré tout à un petit ensemble de premières mesures utiles. La demande du KV cache contraint la taille du batch en plus de la mémoire des poids, de l’overhead du runtime et de la longueur des requêtes. Des batchs plus grands peuvent augmenter l’intensité arithmétique, tandis que le continuous batching accroît les fluctuations d’allocation du KV et que PagedAttention réduit la fragmentation qui en résulte.

Côté entraînement, le coût du cycle de vie peut favoriser l’entraînement d’un modèle plus petit sur davantage de tokens, comme l’illustre Llama 3 8B. GRPO réduit la charge d’état du critic de PPO. Dans la configuration de petits modèles testée par DeepSeek-R1, la distillation a surpassé le RL direct. Ce sont des options à évaluer, pas une recette.

Le routage, le caching, la quantification et le choix du hardware ne se cumulent que lorsqu’ils sont évalués par rapport à la même cible de qualité et de latence. Choisissez un symptôme, établissez cette baseline et faites en sorte que la modification suivante soit facile à annuler.

Lectures complémentaires

Deep dives associés de ce blog, organisés par thème :

• Guide du fine-tuning des LLM — quand choisir le fine-tuning, le RAG ou le prompt engineering
• Variantes de LLM open source et formats de fichiers — associer les variantes de modèles et les formats quantifiés au hardware
• Guide LoRAX Serving — servir des milliers d’adapters LoRA en production
• Mettre à l’échelle les grands modèles de langage — stratégies multi-GPU et multi-nœuds
• LLM locaux sur macOS — mise en place pratique avec llama.cpp et Ollama
• Boucles de raisonnement des AI agents en 2026 — deep dive sur les boucles ReAct, ReWOO et planner-executor
• Architecture mémoire des AI agents en 2026 — checkpoints, vector stores et mémoire documentaire pour les agents stateful

Références

Organisées par domaine.

Inférence et attention

• FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness - Dao et al., NeurIPS 2022
• FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning - Dao, 2023
• FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision - Shah et al., NeurIPS 2024
• Flash-Decoding for long-context inference - Dao et al., 2023
• Efficient Memory Management for Large Language Model Serving with PagedAttention - Kwon et al., SOSP 2023
• Orca: A Distributed Serving System for Transformer-Based Generative Models - Yu et al., OSDI 2022
• GQA: Training Generalized Multi-Query Attention - Ainslie et al., 2023
• Triton: an intermediate language and compiler for neural network computations - Tillet et al., MAPL 2019
• FlashNorm: Fast Normalization for LLMs - 2024
• Deep Kernel Fusion for Transformers - DeepFusionKernel, 2026

Speculative decoding

• Accelerating Large Language Model Decoding with Speculative Sampling - Chen et al., 2023
• EAGLE-3: Scaling up Inference Acceleration of Large Language Models - Li et al., NeurIPS 2025
• Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads - ICML 2024

Quantification

• AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration - MLSys 2024 Best Paper
• GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers - Frantar et al., ICLR 2023
• Marlin: Mixed-Precision (FP16xINT4) LLM Inference Kernel - Frantar et al., 2024

Entraînement et fine-tuning

• LoRA: Low-Rank Adaptation of Large Language Models - Hu et al., ICLR 2022
• QLoRA: Efficient Finetuning of Quantized LLMs - Dettmers et al., NeurIPS 2023
• ZeRO: Memory Optimizations Toward Training Trillion Parameter Models - Rajbhandari et al., SC20
• ZeRO-Infinity: Breaking the GPU Memory Wall for Extreme Scale Deep Learning - Rajbhandari et al., 2021
• Self-Instruct: Aligning Language Models with Self-Generated Instructions - Wang et al., ACL 2023
• WizardLM: Empowering Large Language Models to Follow Complex Instructions - Xu et al., ICLR 2024
• Phi-4 Technical Report - Microsoft, 2024
• AI models collapse when trained on recursively generated data - Shumailov et al., Nature 2024

Alignment

• Direct Preference Optimization: Your Language Model is Secretly a Reward Model - Rafailov et al., NeurIPS 2023
• DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models - Introduction de GRPO
• DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning - DeepSeek, 2025

Scaling et architecture

• The Llama 3 Herd of Models - Meta, 2024
• LLaMA: Open and Efficient Foundation Language Models - Touvron et al. (Meta), 2023
• Llama 2: Open Foundation and Fine-Tuned Chat Models - Touvron et al. (Meta), 2023
• Qwen3 Technical Report - Qwen Team (Alibaba), 2025
• Training Compute-Optimal Large Language Models - Hoffmann et al. (Chinchilla), NeurIPS 2022
• RoFormer: Enhanced Transformer with Rotary Position Embedding - Su et al., 2021
• YaRN: Efficient Context Window Extension of Large Language Models - Peng et al., ICLR 2024
• SGLang: Efficient Execution of Structured Language Model Programs - Zheng et al., NeurIPS 2024
• Mixtral of Experts - Jiang et al. (Mistral AI), 2024

Embeddings

• Matryoshka Representation Learning - Kusupati et al., NeurIPS 2022
• pplx-embed-v1: Diffusion-Pretrained Dense and Contextual Embeddings - Perplexity AI, 2026

Architectures d’agents

• ReAct: Synergizing Reasoning and Acting in Language Models - Yao et al., ICLR 2023
• ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models - Xu et al., 2023

Routage

• RouteLLM: Learning to Route LLMs with Preference Data - Ong et al., ICLR 2025

Benchmarks

• MLPerf Inference v5.0 Results - MLCommons, avril 2025

Architectures de serving

• Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve - Agrawal et al., OSDI 2024 (Chunked prefill)
• Splitwise: Efficient Generative LLM Inference Using Phase Splitting - Patel et al., ISCA 2024 (Disaggregated Serving)
• DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving - Zhong et al., OSDI 2024 (Disaggregated Serving)

Serving frameworks

• vLLM - Moteur de serving basé sur PagedAttention
• SGLang - RadixAttention et génération structurée
• TensorRT-LLM - Inférence optimisée par NVIDIA
• llama.cpp - Inférence portable en C/C++
• DeepSpeed - Bibliothèque Microsoft d’entraînement distribué
• Ollama - Runtime local pour LLM

Opérations

• Efficient LLM Scheduling by Learning to Rank - Fu et al., NeurIPS 2024 (vLLM-LTR)
• CascadeInfer: Length-Aware Scheduling of LLM Serving with Low Latency and Load Balancing - Yuan et al., 2025
• Goodput metric as measure of ML productivity - Google Cloud, 2024
• vLLM Optimization and Tuning - Documentation vLLM
• vLLM Metrics - Documentation vLLM
• LMCache: KV Cache Management for LLM Serving - Offloading du KV cache
• OpenAI Rate Limits - Documentation de l’API OpenAI
• Anthropic Rate Limits - Documentation de l’API Anthropic