Comment concevoir des invites LLM prenant en charge le cache sur OpenAI, Anthropic et Gemini

La mise en cache des invites n'est utile que lorsque les mêmes jetons sont réutilisés au bon endroit, pendant suffisamment longtemps et selon la sémantique du fournisseur que vous appelez réellement. Les équipes n’en profitent souvent pas car elles traitent la mise en cache comme une fonctionnalité de modèle plutôt que comme un problème d’architecture de requête. Ils placent des horodatages en haut de chaque invite, entrelacent les résultats de récupération spécifiques à la requête avec des schémas d'outils réutilisables ou optimisent pour un fournisseur tout en augmentant silencieusement les coûts pour un autre.

La solution pratique consiste à intégrer la mise en cache des invites au compilateur de requêtes de passerelle. La passerelle doit séparer les invites stables des requêtes volatiles, compiler les instructions de cache spécifiques au fournisseur et mesurer le coût et la latence par préfixe pouvant être mis en cache. Cela est particulièrement important dans un environnement multimodèle, où OpenAI, Anthropic et Gemini exposent différents comportements de mise en cache, champs de comptabilité, durées de vie et coûts de configuration.

Commencez par l'unité pouvant être mise en cache, pas par le fournisseur

L'unité réutilisable n'est généralement pas l'invite entière. Il s'agit d'un préfixe ou d'un objet contextuel créé à partir de données d'invite partagées par de nombreuses requêtes. Dans un LLM d'entreprise de production API, ces éléments incluent souvent la politique de la plate-forme, la politique de l'organisation, les instructions d'application, les définitions d'outils, les règles de format de réponse, les instructions de l'agent de codage ou les conseils de corpus statique.

La partie volatile est le matériel qui change par requête : la tâche actuelle de l'utilisateur, les ID de requête, les horodatages, la fin de la conversation, les passages RAG fraîchement récupérés, les données spécifiques au compte et l'outil unique. résultats. Si un contenu volatile apparaît avant un contenu stable, cela peut interrompre la réutilisation des préfixes ou forcer le fournisseur à traiter une invite volumineuse comme nouvelle.

Fait : les implémentations des fournisseurs diffèrent. OpenAI documents invitent à la mise en cache en tant que réutilisation d'un préfixe partagé, avec une comptabilité par jeton mis en cache. Son article public sur la mise en cache des invites indique que la mise en cache automatique commence à un préfixe de 1 024 jetons et augmente par incréments de 128 jetons, et que les entrées du cache sont généralement effacées après 5 à 10 minutes d'inactivité et dans l'heure suivant la dernière utilisation. Anthropic documente les points d'arrêt de cache explicites et recommande de placer cache_control sur le dernier bloc partagé, comme les invites système ou les définitions d'outils. Gemini documente la mise en cache contextuelle en tant que fonctionnalité payante avec le nombre de jetons mis en cache renvoyés dans les métadonnées d'utilisation pour les opérations de cache et les appels de génération qui utilisent un cache.

Recommandation : concevez votre représentation d'invite interne autour des blocs stables et des blocs volatils avant de mapper quoi que ce soit aux API du fournisseur.

Compilez les requêtes du plus stable au plus volatile

A Le compilateur de requêtes prenant en compte le cache doit trier le matériel de manière à ce que la plus grande section réutilisable apparaisse avant la section spécifique à la requête. Un ordre par défaut pratique est :

1. Politique de sécurité et de conformité de la plate-forme.
2. Politique de l'organisation ou du locataire.
3. Instructions sur le rôle et les tâches de l'application.
4. Schémas d'outils et règles d'utilisation des outils.
5. Connaissances statiques ou documents de référence de longue durée.
6. Conversation historique qui est réutilisé à travers les tours.
7. Passages récupérés ou autre contexte spécifique à la requête.
8. La tâche utilisateur actuelle.
9. Métadonnées éphémères nécessaires uniquement pour cet appel.

Cet ordre n'est pas une vérité universelle. Certains fournisseurs ou modèles peuvent réagir différemment lorsque les instructions bougent. La priorité politique et la qualité des comportements comptent toujours.Traitez l'ordre tenant compte du cache comme une modification contrôlée : exécutez des tests de régression d'invite avant et après la modification de la disposition.

Exemples de blocs d'invite internes

{
  "blocks": [
    {"id": "platform_policy:v7", "stability": "global", "kind": "system"},
    {"id": "org_policy:acme:v3", "stability": "tenant", "kind": "system"},
    {"id": "support_agent:v12", "stability": "app", "kind": "instructions"},
    {"id": "crm_tools:v5", "stability": "app", "kind": "tool_schema"},
    {"id": "kb_static:returns:v2", "stability": "workflow", "kind": "context"},
    {"id": "conversation_tail", "stability": "session", "kind": "history"},
    {"id": "retrieved_docs", "stability": "request", "kind": "rag"},
    {"id": "user_task", "stability": "request", "kind": "user"}
  ]
}

Le compilateur peut hacher le préfixe stable après l'avoir rendu. Ce hachage devient la clé de jointure pour l'analyse du cache : modèle, locataire, application, hachage de préfixe pouvant être mis en cache, version d'invite, choix de durée de vie, jetons d'entrée non mis en cache, jetons d'entrée mis en cache, jetons d'écriture dans le cache le cas échéant, jetons de sortie, latence et coût final.

Utiliser des adaptateurs de fournisseur au lieu d'une seule hypothèse de cache

Un seul indicateur "activer le cache" est trop vague pour les opérations multi-fournisseurs. La passerelle doit exposer une stratégie de cache interne et la compiler dans un comportement spécifique au fournisseur.

OpenAI Adaptateur

Pour OpenAI, optimisez les préfixes partagés répétés et la comptabilité d'utilisation. Le compilateur de requêtes doit conserver le matériel stable au début et éviter les petites différences à l’intérieur de la première étendue pouvant être mise en cache. Suivez les jetons d'entrée mis en cache à partir des champs d'utilisation du fournisseur. Le cas échéant, suivez également les jetons d'écriture du cache afin que le grand livre des coûts puisse comparer la création et la réutilisation du cache.

La mise en cache étant orientée préfixe, la tâche opérationnelle importante consiste à empêcher la dérive des préfixes. Deux invites qui se ressemblent pour les humains peuvent différer car un horodatage, un ID de build, un ordre aléatoire des outils ou une personnalisation du locataire ont été affichés en haut.

Anthropic Adaptateur

Pour Anthropic, compilez des points d'arrêt de cache explicites. Placez cache_control sur le dernier bloc qui doit être partagé avec les demandes de suivi. Les bons candidats sont les instructions système volumineuses, les définitions d’outils ou le contexte de référence stable. Les mauvais candidats sont les messages utilisateur ponctuels, les charges utiles de tâches en cours ou les extraits de code RAG spécifiques à une requête.

Fait : Anthropic documente une durée de cache par défaut de 5 minutes et une durée de cache d'une heure disponibles moyennant un coût supplémentaire. Cela fait de la sélection TTL une décision économique. Un long cache peut avoir du sens pour les agents de codage interactifs, la révision de documents en plusieurs étapes ou la prise en charge des copilotes avec des pauses entre les tours. Cela peut s'avérer inutile pour une tâche ponctuelle peu répétitive.

Gemini Adaptateur

Pour Gemini, traitez la mise en cache contextuelle comme une décision en matière de ressources. Créez du contenu en cache lorsque la réutilisation attendue justifie les coûts d'installation et de stockage, puis référencez ce cache à partir des appels de génération. Ceci est différent du fait de s'appuyer uniquement sur un cache de préfixes automatique. L'adaptateur doit posséder le cycle de vie du cache, la durée de vie, les métadonnées et la politique de nettoyage.

Geminiles caches contextuels de style sont souvent les meilleurs pour un contexte volumineux et stable que de nombreuses requêtes réutiliseront : un long manuel de politiques, un extrait de catalogue de produits statique, un environnement d'outil d'agent de codage fixe ou un flux de travail de révision qui pose de manière répétée des questions sur le même ensemble de documents.

Mesurez l'économie du cache, pas seulement l'impact. Rate

Le taux d'accès au cache est utile, mais ce n'est pas suffisant. Un taux de réussite élevé sur un petit préfixe peut économiser peu. Un taux de réussite plus faible sur un préfixe de politique et d’outils très important peut être plus important.Certains fournisseurs exposent des coûts d'écriture ou de configuration du cache, et ces coûts peuvent effacer les économies si la réutilisation est faible.

Capturez ces champs pour chaque requête lorsque le fournisseur les expose ou lorsque la passerelle peut les estimer :

• Fournisseur et modèle.
• Client, application, environnement et identité de clé API.
• Version du modèle d'invite et préfixe pouvant être mis en cache. hash.
• Politique TTL ou durée du cache.
• Jetons d'entrée non mis en cache.
• Jetons d'entrée mis en cache.
• Jetons d'écriture ou de création de cache lorsque disponibles.
• Jetons de sortie.
• Délai jusqu'au premier jeton et total latence.
• Version du prix catalogue du fournisseur utilisée pour le calcul des coûts.
• Si la requête faisait partie d'une session interactive, d'un travail par lots, d'une boucle d'agent ou d'un appel ponctuel.

Calculez ensuite la valeur du cache par charge de travail, et non globalement. Un copilote de support, un agent de codage, un réviseur de documents et un synthétiseur ponctuel ont des modèles de réutilisation différents. Les cumuls doivent indiquer les dollars économisés, les dollars dépensés en écriture de cache, le changement de latence et le taux de réussite par hachage de préfixe.

Un modèle de retour sur investissement simple suffit pour démarrer :

expected_savings =
  expected_reuses
  * cacheable_tokens
  * (uncached_input_price - cached_input_price)

net_value =
  expected_savings
  - cache_write_or_setup_cost
  - operational_overhead

Ce modèle est intentionnellement simple. Il doit être utilisé comme une porte avant d'activer des caches explicites ou de longue durée, et non comme un substitut à la mesure de la production.

Ajouter des règles de charpie pour les disjoncteurs de cache

La plupart des échecs de cache proviennent d'habitudes de construction rapides, et non de bogues du fournisseur. Ajoutez des règles de passerelle lint qui s'exécutent avant que les requêtes n'atteignent le fournisseur.

Affichez les horodatages en haut des invites. Si le modèle a besoin de l'heure actuelle, placez-la après le préfixe réutilisable ou transmettez-la en tant que bloc de requête tardive.

Signalez les ID aléatoires dans les messages système. Les ID de corrélation appartiennent aux métadonnées ou aux journaux, et non au préfixe d'invite stable.

Indique les schémas d'outils ordonnés dynamiquement. Triez les outils et les propriétés du schéma de manière déterministe avant le rendu. Une liste d'outils qui change l'ordre à chaque requête peut détruire la réutilisation même lorsque l'ensemble d'outils est logiquement identique.

Marquer le RAG spécifique à la requête avant les outils stables. Les passages récupérés sont souvent volatiles. Placez d'abord les instructions stables et les schémas d'outils, puis les passages récupérés, à moins que des tests rapides ne prouvent qu'un autre ordre est requis.

Signalez la personnalisation spécifique à l'utilisateur dans la politique partagée. La stratégie de locataire peut être mise en cache au sein d'un locataire, mais les préférences utilisateur et l'état actuel du compte ne le sont généralement pas.

Avertir le désabonnement de la version du modèle. Si chaque déploiement modifie les espaces, les commentaires ou le texte d'instruction inutilisé, le hachage du préfixe pouvant être mis en cache change. Versionnez délibérément les modèles d'invite et évitez les modifications inutiles des grands blocs stables.

Gérez les charges de travail RAG avec soin

RAG est l'endroit où les équipes mettent souvent trop de cache. Les instructions de récupération stables, les règles de citation, les schémas d'outils et les descriptions de corpus peuvent être réutilisables. Les passages récupérés eux-mêmes sont généralement spécifiques à la demande. Si vous placez les passages récupérés avant les instructions stables, vous réduisez la réutilisation. Si vous mettez en cache l'intégralité du contexte alors que les passages sont peu susceptibles d'être répétés, vous risquez de payer des frais d'écriture ou de configuration sans suffisamment de hits futurs.

Il existe des exceptions. Un flux de révision juridique, un flux de travail de support ou un assistant de document produit peut interroger à plusieurs reprises le même ensemble de documents au cours d'une seule session. Dans ce cas, un cache à durée de vie plus longue pour le contexte du document peut être utile.La décision doit dépendre du nombre de réutilisations attendu, de la durée du cache, de la taille du contexte du document et de la tendance des utilisateurs à poser plusieurs questions sur le même contenu.

Recommandation : classez le contexte RAG dans l'un des trois types suivants : guidage de corpus statique, contexte de session réutilisable ou extraits de code récupérés ponctuels. Mettez en cache uniquement les deux premiers par défaut.

Valider le comportement avant d'optimiser le coût

Déplacer le contenu plus tard dans une invite peut améliorer la réutilisation du cache, mais cela peut également modifier le comportement du modèle. Par exemple, déplacer les règles de l’outil après l’historique des conversations peut réduire leur influence. Déplacer la politique sous le contenu récupéré peut affaiblir la priorité des instructions. La normalisation des schémas peut affecter la sélection des outils si les descriptions changent.

Utilisez des tests de régression avant de déployer des mises en page prenant en charge le cache. Au minimum, testez :

• Priorité des instructions pour la politique de sécurité et de conformité.
• Sélection d'outils sur des tâches connues.
• Validité de sortie structurée lorsque des schémas sont impliqués.
• Qualité des réponses sur des exemples RAG représentatifs.
• Latence et coût sur des tâches répétées. tours.
• Comptabilité d'utilisation spécifique au fournisseur.

Pour les workflows à haut risque, effectuez une comparaison fantôme : disposition originale des invites par rapport à la disposition prenant en compte le cache, même modèle, mêmes entrées, avec des vérifications humaines ou automatisées pour les modifications de sortie inacceptables. Les économies de coûts ne sont pas utiles si le compilateur de requêtes modifie le comportement commercial d'une manière que les équipes n'ont pas approuvée.

Choisissez les charges de travail de manière sélective

La mise en cache des invites est plus efficace lorsque les invites sont longues et répétées. De bons points de départ incluent des agents de codage dotés de schémas d'outils volumineux, des copilotes d'assistance avec des instructions lourdes en termes de politiques, des flux de révision de documents avec des questions répétées sur le même matériel, des agents lourds en outils et des assistants d'entreprise avec de grands blocs de gouvernance.

Les candidats faibles incluent des invites ponctuelles courtes, des invites hautement personnalisées où le début de la requête change à chaque fois, des tâches d'administration peu fréquentes et des workflows où les jetons de sortie dominent le coût total. Dans ces cas-là, d'autres optimisations peuvent être plus importantes : des invites plus courtes, une meilleure récupération, un routage de modèle, un traitement par lots ou des limites de sortie plus strictes.

Prédiction : la sémantique de mise en cache du fournisseur continuera de diverger. La mise en cache automatique des préfixes, les points d'arrêt explicites, les ressources contextuelles payantes, la comptabilité d'écriture du cache et la tarification TTL resteront probablement inégales entre les plates-formes.Les équipes qui centralisent la compilation des requêtes et la télémétrie au niveau de la passerelle pourront s'adapter plus rapidement que celles qui intègrent une logique de mise en cache spécifique au fournisseur dans le code de l'application.

Liste de contrôle de mise en œuvre

• Créez un modèle de bloc d'invite interne avec des étiquettes de stabilité : global, locataire, application, workflow, session et requête.
• Restituez les blocs de manière déterministe, y compris l'ordre des outils et les propriétés du schéma. order.
• Déplacez les champs volatiles hors du préfixe stable.
• Calculez un hachage de préfixe pouvant être mis en cache après le rendu.
• Ajoutez des adaptateurs de fournisseur pour OpenAI la réutilisation du préfixe, Anthropic points d'arrêt du cache et Gemini ressources de cache de contexte.
• Enregistrez les jetons d'entrée non mis en cache, les jetons d'entrée mis en cache et les jetons d'écriture du cache. le cas échéant, les jetons de sortie, la latence, le modèle, le locataire, l'application, le hachage de préfixe et la durée de vie.
• Créez des tableaux de bord pour les dollars nets économisés, le coût d'écriture/de configuration, le taux de réussite et la latence par charge de travail.
• Ajoutez des règles de charpie pour les horodatages, les ID aléatoires, le placement RAG volatile, l'ordre dynamique des outils et la personnalisation dans les blocs partagés.
• Exécutez des tests de régression de comportement rapide avant de modifier mise en page de production.
• Activez d'abord la mise en cache pour les charges de travail très répétitives, puis développez-la en fonction du retour sur investissement mesuré.

Conclusion

La conception d'invites prenant en compte le cache n'est pas seulement un formatage d'invites. Il s'agit d'une fonctionnalité de passerelle : rendu déterministe, conception de préfixes stables, compilation spécifique au fournisseur, peluchage et télémétrie des coûts. Les équipes qui en bénéficieront le plus seront celles qui seront en mesure de répondre à trois questions pour chaque charge de travail : quelle partie de la requête est réellement réutilisable, comment ce fournisseur facture-t-il la réutilisation et le cache a-t-il amélioré le coût ou la latence de bout en bout sans modifier le comportement ?

Commencez par un workflow à répétition élevée. Séparez les blocs stables des blocs volatils, ajoutez une gestion du cache spécifique au fournisseur, mesurez les aspects économiques, puis généralisez. Cette solution évite le mode de défaillance courant : activer une fonctionnalité de cache sans savoir si cela permet d'économiser de l'argent, d'ajouter de la latence ou simplement de déplacer les coûts vers un autre domaine comptable.

Lecture connexe

• observabilité LLM indépendante du fournisseur