Comment la mise en cache des préfixes réduit-elle le travail lié aux invites répétées sur un serveur d’IA domestique ?

La mise en cache des préfixes évite de retraiter les mêmes prompts en réutilisant l’état clé-valeur déjà calculé pour une séquence initiale de tokens identique.

Sur un serveur IA domestique, ce préfixe partagé peut être une politique système, un schéma d’outils, un document volumineux, un ensemble d’instructions pour le foyer ou un historique de conversation récurrent. La première requête doit toujours payer le coût complet du préremplissage, mais les requêtes suivantes qui correspondent peuvent en ignorer une grande partie. Le principal avantage est un chemin de préremplissage plus court et un premier token plus rapide, pas une génération gratuite.

Sans cache, les prompts récurrents recalculent le même préremplissage

Avant de générer une réponse, un modèle autorégressif traite les tokens d’entrée et construit l’état clé-valeur utilisé lors du décodage ultérieur. Un long prompt système, un schéma d’outils, l’en-tête d’un document ou un bloc d’instructions partagé peut donc nécessiter le même travail de préremplissage à chaque requête.

Prompt Cache formalise cette possibilité en réutilisant les états d’attention de segments de prompts qui se chevauchent. Sur un serveur IA domestique, la partie répétée peut compter des milliers de tokens, même si l’utilisateur n’ajoute qu’une seule phrase.

Sans réutilisation, le GPU ou le CPU effectue de nouveau ces opérations matricielles et relit les mêmes poids du modèle pour le même préfixe. La sortie peut être identique, mais le serveur doit tout de même payer le coût de configuration computationnelle.

Un cache de préfixe stocke l’état KV d’un préfixe déjà traité

Après la première requête compatible, le moteur d’exécution peut conserver l’état KV associé au préfixe partagé. Une requête ultérieure commence par vérifier si sa séquence initiale de tokens correspond aux blocs mis en cache.

Le cache automatique des préfixes de vLLM identifie les blocs à partir des tokens du bloc et du préfixe qui le précède. Les requêtes correspondantes peuvent pointer vers les mêmes blocs physiques du cache au lieu d’allouer et de calculer un état en double.

L’objet réutilisable n’est ni la réponse finale ni un résumé sémantique générique. Il s’agit d’un état d’attention spécifique au modèle pour un préfixe exact et compatible.

Un accès au cache ignore le préremplissage partagé, mais traite toujours le nouveau suffixe

Lorsque le préfixe correspond, le moteur d’exécution peut partir de l’état d’attention stocké et évaluer uniquement les nouveaux tokens situés après la limite mise en cache. Un assistant domestique doté d’un prompt système stable peut ainsi éviter un travail répété avant chaque commande courte.

LMCache décrit la réutilisation du cache KV entre les requêtes de LLM comme une optimisation de la couche de service, et non comme une modification des poids du modèle.

Le nouveau message utilisateur doit toujours être prérempli, et chaque token généré nécessite toujours un calcul de décodage. La mise en cache des préfixes réduit principalement le travail redondant avant le début de la génération.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Les préfixes longs et stables offrent le gain de délai avant le premier token le plus important

Un cache économise du travail à proportion de la partie qui aurait autrement été recalculée. Réutiliser un préfixe de 2 000 tokens contenant des instructions et un document est plus avantageux que réutiliser une salutation de dix tokens.

La conception du service SGLang utilise une réutilisation structurée du KV pour accélérer les charges de travail à préfixe partagé. L’équivalent sur un serveur domestique peut être une politique d’agent récurrente, un catalogue d’outils, un ensemble de connaissances du foyer ou un modèle de document.

C’est pourquoi il faut évaluer la mise en cache des préfixes avec le délai avant le premier token et le débit de préremplissage, et pas seulement avec le nombre de tokens par seconde pendant la génération. La phase de décodage peut rester presque inchangée, tandis que la réponse commence plus rapidement.

De petites modifications du prompt peuvent interrompre la réutilisation à la limite d’un bloc

Un cache est généralement exact en ce qui concerne les tokens et l’état du modèle. Réordonner les définitions d’outils, insérer un horodatage variable au début, changer d’adaptateur ou modifier le prompt système peut rendre les blocs suivants inéligibles à la réutilisation.

Les recommandations de déploiement de Hugging Face distinguent la planification du préremplissage et du décodage. Placer le contenu stable au début du prompt permet de rendre réutilisable une plus grande partie de ce préremplissage.

Les applications doivent donc éviter d’insérer des données volatiles au début d’un préfixe par ailleurs stable lorsque ces mêmes informations peuvent être placées plus loin.

La capacité du cache et l’éviction définissent les limites sur un serveur domestique

Les blocs KV consomment de la mémoire, si bien que le serveur ne peut pas conserver indéfiniment tous les préfixes. Les conversations simultanées, les contextes longs et plusieurs modèles se partagent le même pool de mémoire et peuvent évincer les anciens états réutilisables.

L’explication de ZimaSpace sur la mise en cache des modèles et la latence des réponses à chaud présente la hiérarchie globale des caches. La mise en cache des préfixes n’en constitue qu’une couche et ne doit pas être confondue avec le fait de conserver les poids du modèle en mémoire.

Mesurez le taux d’accès au cache, le nombre de tokens réutilisés, le délai avant le premier token, le débit de préremplissage, l’utilisation de la mémoire KV et le taux d’éviction au niveau réel de concurrence au sein du foyer.

La documentation NVIDIA de TensorRT-LLM décrit la réutilisation du cache KV comme une optimisation du service avec la même limite fondamentale : l’état réutilisable n’est utile que tant que les blocs correspondants restent disponibles.