Fiche concept

PagedAttention — Gestion mémoire pour LLM à long contexte

À jour au 2026-07-24T14:00:00Z

Édité par Cédric-Olivier Mâry, éditeur et directeur de la publication — 27 ans d'écosystème SAP. Comment ces pages sont produites, et où intervient l'automatisation.

Qu'est-ce que PagedAttention — Gestion mémoire pour LLM à long contexte ?

PagedAttention emprunte la pagination mémoire virtuelle des OS pour le KV-cache, portant l'utilisation effective de la mémoire GPU de 20-40 % à plus de 96 % — transformant un A100 qui servait moins de 4 requêtes concurrentes à contexte 32k en un serveur de 30 à 50 requêtes.

PagedAttention est la technique de gestion de la mémoire qui a transformé le service des grands modèles de langage à grande échelle, le faisant passer d'un goulot d'étranglement lié à la mémoire à un problème d'ingénierie maîtrisable. Introduite par l'équipe vLLM en 2023, elle reprend l'idée la plus ancienne de la conception des systèmes d'exploitation — la mémoire virtuelle paginée — et l'applique à la ressource qui domine la mémoire GPU pendant l'inférence : le cache KV, le stock courant de vecteurs clés et valeurs que chaque couche du transformeur accumule au fur et à mesure qu'elle génère des tokens.

Ce que c'est et pourquoi c'est important

Pourquoi c'est important

Les moteurs pré-vLLM réservaient un bloc contigu complet dimensionné à la longueur de séquence maximale dès l'admission, gaspillant 60-80 % de la mémoire GPU en fragmentation avec 30-50 requêtes concurrentes de longueurs variables.
Les pages (blocs KV-cache de taille fixe) se mappent à la mémoire physique via une table de blocs par requête, allouées à la demande et libérées individuellement à la fin de la requête — exactement comme le mappage page virtuelle-physique d'un OS.
Des pages au contenu de tokens identique peuvent être partagées entre requêtes, ce qui fonde le prefix-caching et le RadixAttention de SGLang.

Points clés

Applique la pagination mémoire virtuelle de type OS au KV-cache (C160) — blocs de taille fixe de par ex. 16 emplacements tokens mappés via une table de blocs par requête ; libère les pages individuellement à la fin des requêtes.
Remplace l'allocation contiguë qui réservait à l'avance l'espace de séquence max (gaspillant 60-80 % de la mémoire GPU) par une allocation à la demande ; sur un A100 80 Go servant 70B + contexte 32k, l'allocation naïve supporte <4 requêtes concurrentes vs 15-20 sous PagedAttention.
Porte l'utilisation effective de la mémoire GPU de 20-40 % à plus de 96 % sur charges concurrentes de longueurs diverses — le résultat headline de l'article SOSP 2023.
Active le prefix-caching et RadixAttention (SGLang) en autorisant le partage de pages à contenu identique entre requêtes ; un prompt système commun de 2k tokens partagé entre 50 requêtes concurrentes économise 50 × 2k × (taille tenseur KV par token) de mémoire GPU.
Surcoût kernel par étape de 5 à 15 % (gather K/V non contigu vs contigu) en échange de 3 à 5x plus de requêtes concurrentes sur le même matériel — l'arbitrage fondamental.
Fondation qui rend le batching continu (C245) viable sur les charges à long contexte et agentiques — sans allocation paginée, le batching continu ne peut pas admettre de nouvelles requêtes pendant que des requêtes à long contexte occupent de la mémoire contiguë.
Implémenté dans : vLLM (implémentation originale, open-source) · NVIDIA TensorRT-LLM (grade production, optimisé GPU) · SGLang (étend avec RadixAttention) · LMDeploy (Huawei, mobile + edge).
SAP AI Core utilise des moteurs d'allocation paginée compatibles vLLM pour le service de modèles du Generative AI Hub ; le dimensionnement de capacité pour les sessions agents Joule ou SAP AI concurrentes doit tenir compte du budget de pages KV-cache par session.
Impact pratique du prefix-caching : sur un déploiement Joule où toutes les requêtes partagent un prompt contexte SAP de 2k tokens, le prefix-caching réduit le TTFT (time-to-first-token) de 40 à 60 % et la mémoire KV-cache de 30 à 50 % — une réduction de coût substantielle à l'échelle.
Mode d'échec : éviction de page — quand la mémoire GPU est épuisée même avec l'allocation paginée (très longs contextes + forte concurrence), le moteur évacue les pages froides vers la RAM CPU (swap) ; l'éviction ajoute des pics de latence de 100 à 500 ms visibles comme dégradation de la latence p99 ; le signal est un taux de swap élevé dans les métriques vLLM.

Termes employés sur cette page

PagedAttention: Algorithme de gestion mémoire qui divise le KV-cache du LLM en pages de taille fixe mappées via une table de blocs par requête, à l'image de la pagination de mémoire virtuelle des OS ; introduit dans l'article vLLM (Kwon et al., SOSP 2023) ; la technique principale permettant un gain de débit GPU de 3-5x sur des charges LLM concurrentes de longueurs variées.
KV-cache: Les tenseurs clé et valeur de chaque token de la fenêtre de contexte d'un LLM, mis en cache en mémoire GPU pour éviter de recalculer l'attention multi-têtes sur les tokens précédents ; peut occuper 1-10 Go par conversation à long contexte ; le principal goulot d'étranglement mémoire GPU dans le service LLM.
Block table: Structure de données par requête mappant les positions logiques des tokens vers les pages physiques contenant leurs vecteurs K/V ; analogue à une table de pages dans un système de mémoire virtuelle d'OS ; le mécanisme qui découple la longueur de séquence logique de la disposition mémoire physique.
Prefix caching: Réutilisation des mêmes pages de KV-cache pour le préfixe partagé de plusieurs requêtes (p. ex. un system prompt commun ou des exemples few-shot) ; rendu possible par le mécanisme de partage de pages de PagedAttention ; réduit le TTFT de 40-60 % et la mémoire de KV-cache de 30-50 % sur les déploiements Joule où toutes les requêtes partagent un prompt de contexte SAP.
RadixAttention: Extension du partage de pages de PagedAttention à des préfixes partagés arbitraires via un arbre radix, implémentée dans SGLang (Zheng et al., 2023) ; obtient 20-40 % d'économie mémoire supplémentaire par rapport au prefix-caching de base en partageant aussi des sous-chaînes non préfixes.
Page eviction: Le repli lorsque la mémoire GPU est épuisée même avec l'allocation paginée : les pages froides (celles non récemment consultées) sont écrites en RAM CPU et rechargées à la demande ; ajoute des pics de latence de 100-500 ms visibles en dégradation p99 ; le mode de défaillance clé à surveiller via la métrique swap_rate de vLLM.
TTFT (Time to First Token): La latence entre la soumission de la requête et l'apparition du premier token dans la réponse ; la métrique d'expérience utilisateur la plus sensible à la pression mémoire du KV-cache et au prefix-caching ; la cible pour les sessions Joule interactives est un TTFT <500 ms.
Continuous batching: La technique de service LLM (C245) qui admet de nouvelles requêtes en cours de génération plutôt que d'attendre l'achèvement du lot courant ; viable seulement avec PagedAttention, car l'allocation contiguë naïve retient la mémoire jusqu'à ce qu'une séquence complète se termine.

Sources

Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code · les chiffres à citer.

Ouvrir dans l'application →