Que change PagedAttention dans l’allocation de mémoire KV des LLMs ?
Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
PagedAttention permet au cache d’attention d’une requête d’occuper des blocs de mémoire distincts de taille fixe plutôt qu’une seule grande allocation contiguë. Une table de blocs associe les positions logiques des tokens de la requête à des blocs physiques. Cela réduit le besoin de réserver à l’avance la longueur maximale possible de la séquence d’une requête.
Le principal avantage est une allocation de mémoire KV plus souple pour les requêtes simultanées. Cela ne réduit pas la quantité de données de clés et de valeurs nécessaire pour chaque token stocké.
Calculer l’espace inutilisé dans les blocs
Prenons une implémentation illustrative avec des blocs de 16 tokens. Une séquence de 35 tokens nécessite trois blocs, soit de la place pour 48 tokens. Treize positions du dernier bloc restent inutilisées : environ 27% des positions allouées pour cette courte séquence.
Seul le dernier bloc peut être partiellement rempli. À mesure que les séquences s’allongent, cet espace inutilisé représente une fraction plus faible de leur allocation. La taille réelle des blocs et les dispositions prises en charge dépendent du runtime, du backend d’attention et de la version.
L’article sur PagedAttention décrit la conception de la correspondance et de l’allocation. Des blocs supplémentaires sont alloués à mesure qu’une séquence s’allonge, puis libérés quand la requête se termine, au lieu de réserver une grande plage contiguë par requête.
Le partage exige plus que l’allocation
Plusieurs requêtes peuvent référencer le même bloc de cache compatible. La mise en cache des préfixes trouve des blocs réutilisables pour des préfixes identiques ; la gestion de la copie à l’écriture permet aux requêtes de diverger sans corrompre l’état partagé. Une disposition par blocs le permet, mais ne fournit pas automatiquement une politique de recherche dans le cache et ne garantit pas la réutilisation entre requêtes.
La présentation initiale de vLLM rapportait 60–80% de gaspillage avec les anciennes méthodes d’allocation utilisées pour la comparaison, et moins de 4% pour les charges PagedAttention mesurées. Le calcul ci-dessus pour une courte séquence montre pourquoi ce chiffre inférieur à 4% ne constitue pas une limite supérieure universelle. Les comparaisons montrant de forts gains de débit incluent aussi des différences dans l’ensemble du runtime ; elles ne doivent donc pas être attribuées à la seule allocation.
Mesurez les blocs alloués, les positions de tokens utilisées, les évictions ou préemptions et la capacité en requêtes simultanées. Comparez les mêmes longueurs et la même précision de cache. Si les seules données KV dépassent déjà la mémoire disponible, l’allocation par blocs ne peut pas faire disparaître ces données ; il peut aussi être nécessaire de réduire le nombre de têtes KV, d’utiliser une quantification du cache prise en charge ou de réduire la charge de travail.
Guide d’ingénierie : PagedAttention contient un exemple de table de blocs.