Comment la mise en cache des préfixes réutilise les prompts des LLM et les tokens en cache
Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
La mise en cache des préfixes réutilise l’état d’attention d’un préfixe de prompt antérieur compatible. Une nouvelle requête ne traite que la partie restante absente du cache, au lieu de refaire tous les calculs du prompt. Elle aide les charges de travail qui répètent des instructions système, des exemples, des documents ou des préfixes de conversation.
La correspondance porte sur les tokens et l’état du modèle. Une formulation similaire, du texte répété plus loin dans un prompt ou les mêmes tokens avec un autre adaptateur ne suffisent pas à établir une correspondance valide dans le cache.
Ce qui doit correspondre
Dans un transformer causal, les clés et les valeurs d’un token conservées en cache dépendent des tokens qui le précèdent. Réutiliser un passage répété plus loin après avoir modifié un passage antérieur reviendrait à réutiliser des états dépendant d’un autre contexte.
| Réutilisation envisagée | Vérification |
|---|---|
| system prompt identique | Identifiants de tokens exacts et état du modèle compatible |
| Document répété | Préfixe précédent identique, ainsi que le document |
| Conversation poursuivie | Messages antérieurs, gabarit et tokens inchangés |
| Même texte avec un autre adaptateur | Identité de l’adaptateur et règles de compatibilité du cache |
| prompt multimodal | Identité des images ou des médias, et pas seulement les tokens de substitution |
La conception du cache de préfixes de vLLM calcule une empreinte à partir des tokens d’un bloc, de son préfixe parent et d’identifiants supplémentaires tels que LoRA et l’état multimodal. Elle réutilise des blocs complets ; un dernier bloc incomplet ne constitue pas automatiquement une correspondance dans le cache. Des valeurs de salt peuvent aussi séparer les requêtes qui ne doivent pas partager d’état en cache.
RadixAttention de SGLang organise les préfixes réutilisables dans un arbre radix. La représentation diffère, mais un état de préfixe compatible reste nécessaire.
Mesurer le travail de prefill évité
La mise en cache des préfixes évite surtout de refaire les calculs du prompt. Elle ne supprime ni le décodage ni son attention sur l’historique disponible. Les calculs économisés ne garantissent pas non plus un meilleur TTFT pour chaque requête : l’attente en file et les requêtes avec un cache froid subsistent.
Comparez séparément les requêtes avec un cache froid et celles dont le préfixe répété est déjà en cache. Enregistrez les tokens réutilisés, pas seulement la proportion de requêtes ayant trouvé une correspondance quelconque. Une correspondance couvrant 32 tokens et une autre couvrant 8,000 tokens évitent des quantités de travail différentes. Mesurez la mémoire conservée par le cache, les évictions et la latence selon la longueur du préfixe.
Placez les instructions stables avant les données propres à la requête lorsque cet ordre préserve le prompt prévu. Intégrez la compatibilité des locataires et des adaptateurs à la politique de cache. Indiquez l’état du cache chaque fois que vous publiez des résultats de serving.
Guide d’ingénierie : mise en cache des préfixes relie le mécanisme de réutilisation à l’allocation KV.