Décodage de la mise en cache des invites : des principes de PagedAttention à une réduction des coûts et une amélioration de l’efficacité multipliées par 10 Cet article de @dejavucoder explore les principes fondamentaux de la mise en cache des invites, en particulier ceux basés sur la technologie PagedAttention du projet @vllm_project. S'appuyant sur sa propre expérience et les difficultés rencontrées lors du développement, l'auteur corrige de nombreuses idées reçues sur les mécanismes de mise en cache et propose des suggestions d'optimisation très pratiques. Idée fausse et réalité : la mise en cache est globale, et non privée. Idée fausse : l’auteur (comme beaucoup d’entre nous) pensait initialement que la mise en cache des invites était basée sur les « sessions utilisateur ». Autrement dit, seuls les messages suivants du même utilisateur dans la même boîte de dialogue pouvaient utiliser les messages précédemment mis en cache. La vérité est la suivante : la mise en cache des invites est basée sur le contenu, et non sur l'utilisateur. • Logique de base : Tant que les invites système ou les définitions d'outils sont un texte parfaitement cohérent, le cache généré par l'utilisateur A peut être entièrement réutilisé par l'utilisateur B. • Importance : Cela signifie que dans les scénarios de forte concurrence, tant que le préfixe est cohérent, le système peut atteindre une « réutilisation globale », réduisant considérablement les calculs redondants. Pourquoi la mise en cache est-elle nécessaire ? (Coût vs. vitesse) Le processus de raisonnement du LLM est divisé en deux étapes, et comprendre cette différence est essentiel pour comprendre la valeur de la mise en cache : • Étape de pré-remplissage : Cette étape traite le grand nombre d’invites que vous saisissez et calcule leur cache de paires clé-valeur. Ce processus est gourmand en ressources de calcul et consomme beaucoup de puissance informatique. • Phase de décodage : génération des jetons de réponse un par un. Ce processus est gourmand en mémoire et en bande passante. • Sans mise en cache : à chaque requête, même si les 90 % premières invites sont identiques, le modèle doit être recalculé pour le préremplissage, ce qui est à la fois lent et coûteux. • Accès direct au cache : permet d'éviter le calcul fastidieux du préremplissage, réduisant ainsi par 10 le coût de la saisie des jetons et améliorant considérablement la vitesse de génération du premier caractère. Présentation technique : PagedAttention La gestion traditionnelle du cache par clé-valeur est très inefficace, car elle nécessite la pré-allocation d'un grand bloc de mémoire vidéo contiguë, ce qui entraîne facilement fragmentation et gaspillage. vLLM introduit le concept de gestion de la mémoire par pagination, propre au système d'exploitation. • Blocs : Au lieu d'allouer de grands blocs de mémoire contigus, le système divise le cache KV en « blocs » de taille fixe. Ces blocs peuvent être dispersés et non contigus au sein de la mémoire vidéo physique. • Le hachage par blocs – la clé d’une mise en cache efficace : Comment le système sait-il que « ce passage a déjà été calculé » ? Il calcule la valeur de hachage du bloc. • Dépendance au bloc parent : la valeur de hachage d’un bloc dépend non seulement de son propre contenu, mais aussi de la valeur de hachage du bloc précédent. • Réaction en chaîne : Ce mécanisme est similaire à une blockchain. La valeur de hachage actuelle ne correspondra que si toutes les données « depuis le début » sont parfaitement cohérentes. Cela garantit l’exactitude de la causalité : il est impossible de réutiliser un segment intermédiaire ; le préfixe doit correspondre exactement. • Recherche globale : Lorsqu'une nouvelle requête arrive, le système calcule le hachage de bloc de son mot d'invite et le recherche dans la table de hachage globale. Si une correspondance est trouvée, il pointe directement vers un bloc mémoire existant, sans qu'il soit nécessaire d'effectuer d'autres calculs. Conseils pratiques pour les développeurs : Comment « tromper » le système pour qu’il accède au cache ? Pour optimiser le taux d'accès au cache, il faut que le système traite les différentes requêtes comme « identiques ». L'article propose plusieurs règles d'or : • Conserver un préfixe stable. Placez tout le contenu statique (invites système, définitions d'outils, exemples de texte) au tout début. • Contre-exemple : si vous placez « heure actuelle » ou « nom d’utilisateur » au début de l’invite, toute la chaîne de hachage est rompue dès le départ, et le contenu suivant, même s’il est identique, ne peut pas être réutilisé dans le cache. • Sérialisation déterministe Lors de l'utilisation du format JSON pour transmettre des données (par exemple, pour des appels utilitaires), l'ordre des clés doit rester constant. Conseil : Utilisez `json.dumps(..., sort_keys=True)` en Python. En effet, `{ "a": 1, "b": 2 }` et `{ "b": 2, "a": 1 }`, bien qu'identiques sur le plan sémantique, génèrent des chaînes différentes, ce qui peut entraîner un échec de cache. • Mode ajout uniquement Lors de la gestion de l'historique des dialogues à plusieurs tours, essayez d'ajouter du nouveau contenu uniquement à la fin. Ne modifiez ni ne tronquez l'historique en cours, car toute modification au milieu invalidera la chaîne de cache suivante. • Soyez vigilant face aux modifications apportées aux définitions d'outils. Ces définitions sont souvent ajoutées aux invites système par le modèle. Si vous activez/désactivez dynamiquement différents outils pour différents utilisateurs, le préfixe changera, ce qui invalidera le cache. Résumer L'essence de la mise en cache des invites ne réside pas dans la « mémoire », mais dans la « réutilisation des résultats de calcul ». La compréhension des mécanismes sous-jacents de blocs et de chaînes de hachage permet aux développeurs de comprendre pourquoi les « préfixes » sont si importants. En résumé : placez toujours les éléments immuables (commandes système, documents de référence, listes d’outils) au début et les éléments variables (questions des utilisateurs, variables dynamiques) à la fin. Lire le texte original
