Mettre en cache les longs préfixes

Toute requête longue paie un coût de préremplissage pour encoder ses jetons avant la génération. Lorsqu'un même préfixe long se répète dans de nombreux appels — une requête système, une spécification d'outil ou un grand document de référence — la mise en cache des requêtes permet au fournisseur de réutiliser l'état d'attention déjà calculé au lieu de le recalculer.

• Les accès au cache réduisent considérablement la latence et le coût de l'entrée.
• Les économies augmentent avec la taille du préfixe et la fréquence de réutilisation.

Les caches s'appuient sur une correspondance exacte du préfixe de jetons depuis le début de la requête. La portion mise en cache s'étend du début jusqu'au premier point de divergence. Modifiez quoi que ce soit au début et tout ce qui suit ne bénéficiera plus du cache.

Conséquence : la disposition qui maximise les accès au cache place d'abord le contenu le plus stable et laisse le contenu le plus variable à la fin.

Organisez le contenu du plus stable au moins stable : les règles système immuables et les définitions d'outils, puis les grandes références stables, ensuite le contexte stable au sein de la session, et enfin l'entrée et la question propres à chaque requête.

• Stable -> début (peut être mis en cache).
• Variable -> fin (seule partie à recalculer).

Ce principe d'ordonnancement unique guide la plupart des gains liés à la mise en cache.

Certains fournisseurs vous permettent de définir des points de coupure explicites pour le cache. Placez-les à la fin de chaque segment stable afin que le système puisse mettre en cache tout ce qui précède. Marquez le plus grand bloc stable (le corpus de référence ou la longue requête système) comme pouvant être mis en cache.

En l'absence de marqueurs explicites, structurez malgré tout la requête selon l'ordre de stabilité afin que la correspondance implicite de préfixe reste utile.

Des changements subtils et involontaires interrompent silencieusement la mise en cache : un horodatage dans la requête système, un identifiant propre à chaque requête injecté au début, des définitions d'outils réordonnées ou un ordre non déterministe des clés JSON. Chacun modifie le préfixe et force un recalcul complet.

Examinez votre préfixe à la recherche de tout ce qui varie entre les appels et déplacez ces éléments après la région mise en cache.

Les caches expirent après une durée de vie définie par le fournisseur, souvent renouvelée à chaque accès. Les défauts à froid se reproduisent si les appels sont trop espacés. Pour les charges de travail en rafales et à haute fréquence, la mise en cache est rentable ; pour les appels rares et dispersés, le cache peut expirer entre deux utilisations.

Adaptez votre profil de trafic au TTL et envisagez des requêtes ping de maintien en vie pour les préfixes importants.

La mise en cache applique généralement une petite majoration pour écrire une entrée de cache et une forte réduction pour la lire. La rentabilité favorise la réutilisation : une écriture amortie sur de nombreuses lectures représente une économie nette importante ; une utilisation unique qui ne fait qu’écrire peut coûter légèrement plus cher.

• Forte réutilisation -> mettez agressivement en cache.
• Préfixes utilisés une seule fois -> la mise en cache peut ne pas être rentable.

Rendez votre invite système et les spécifications de vos outils déterministes et verrouillées sur une version. Triez les définitions d’outils de manière canonique, évitez d’y intégrer des données dynamiques et ne les modifiez que lors de versions publiées délibérément. Un bloc système stable devient une entrée de cache durable, avec un taux d’accès élevé, partagée entre toutes les requêtes.

Traitez le préfixe mis en cache comme un artefact doté d’une version, et non comme une chaîne que vous modifiez au gré de vos envies.

Dans les boucles d’agents, la conversation qui s’allonge constitue un cache naturel : chaque tour prolonge un préfixe que le tour suivant réutilise. Ajoutez les nouveaux tours uniquement à la fin et ne réécrivez jamais les tours précédents, afin que le cache antérieur reste valide.

Lorsque vous devez compacter la conversation, faites-le de manière à créer un nouveau préfixe stable pour les tours suivants, plutôt que de modifier plusieurs fois les anciens.

Instrumentez-le. La plupart des fournisseurs indiquent, pour chaque appel, le nombre de jetons d’entrée mis en cache et celui des jetons non mis en cache. Suivez le taux d’accès au cache et, s’il est faible, examinez le préfixe à la recherche d’une dérive. Une régression du taux d’accès indique généralement l’introduction récente d’une valeur dynamique au début de l’invite.

• Consignez le rapport entre les jetons mis en cache et le nombre total de jetons d’entrée.
• Déclenchez une alerte lorsque le taux d’accès baisse après un déploiement.

Pour maîtriser le coût des préfixes longs : ordonnez le contenu selon sa stabilité, désignez le plus grand bloc stable comme point de mise en cache, éliminez les dérives cachées, verrouillez les blocs système et d’outils sur une version, ajoutez uniquement à la fin dans les boucles d’agents et surveillez le taux d’accès. L’objectif est d’obtenir un grand préfixe réutilisable et une petite queue volatile recalculée à chaque appel.

Vous réutilisez un corpus de référence de 100 000 jetons dans des milliers de requêtes quotidiennes, mais le taux d’accès à votre cache est presque nul.

La mise en cache des invites réutilise le préremplissage d’un préfixe exact et stable, ce qui réduit fortement la latence et le coût des entrées lorsque la réutilisation est fréquente. Ordonnez le contenu en plaçant le plus stable en premier, désignez le grand bloc stable comme point de rupture et repoussez toute volatilité vers la fin. Éliminez les dérives cachées, verrouillez les blocs système et d’outils sur une version, ajoutez uniquement à la fin dans les boucles d’agents et surveillez le taux d’accès afin qu’une régression signale une valeur récemment introduite qui varie au début de l’invite.