Optimisation des coûts : mise en cache rapide

Gains :

• Expliquer la logique de correspondance des préfixes de la mise en cache des invites
• Augmente l'accès au cache en plaçant le contexte fixe en premier et le contexte variable après
• Peut calculer l'économie d'écriture/lecture du cache et le seuil de rentabilité

Un produit LLM semble bon marché en prototype ; Quand on monte à l'échelle, la facture surprend. Dans la plupart des charges de travail, la majeure partie de la facture provient du même contexte fixe qui est envoyé encore et encore avec chaque requête : une longue invite système, un livre de règles, une documentation de référence. La mise en cache rapide élimine exactement ce gaspillage. Dans cette unité, vous apprendrez comment fonctionne le cache, comment organiser l'invite d'accès et comment calculer le seuil de rentabilité de l'économie du cache. Lorsqu’il est installé correctement, il peut à lui seul réduire votre facture de moitié, voire même moins.

Comment fonctionne le cache ? La seule règle immuable

La mise en cache des invites est une correspondance de préfixe. Le fournisseur stocke temporairement les jetons qu'il a traités depuis le début de votre invite. Si l'invite démarre par le même préfixe lors de la requête suivante, cette partie commune n'est pas recalculée ; C'est beaucoup moins cher à lire que le cache.

Une règle immuable en découle : si un seul octet change n'importe où dans le préfixe, l'intégralité du cache devient invalide à partir de ce point. Autrement dit, le contenu fixe doit être au début et le contenu variable à la fin. Si vous mettez une ligne au début de l'invite système qui change à chaque requête, comme « Date d'aujourd'hui : 18.07.2026 », tout ce qui se trouve derrière ne pourra pas entrer dans le cache.

L'ordre de traitement est généralement le suivant : outils → invite système → messages. Vous placez le point de cache (point d'arrêt) à la fin de la section fixe.

Économie du cache

Cache a trois niveaux de prix :

• Écriture du cache : stockage pour la première fois. ~ 1,25x le prix d'entrée normal (pour 5 minutes de stockage).
• Lecture du cache : Lecture sur les requêtes ultérieures. ~0,1 fois le prix normal des intrants, soit un dixième.
• Entrée normale : la partie qui n'entre pas dans le cache et est traitée au coût total à chaque fois.

Seuil de rentabilité : la première demande paie une prime d'écriture (1,25 ×). Dès la deuxième requête, la lecture (0,1×) entre en jeu. En gros, vous serez au coude à coude sur deux demandes ; Après, ce sont des économies nettes. Plus le contexte fixe est grand et plus il est réutilisé de requêtes, plus le gain devient important.

Scénario

Le cache fonctionne-t-il ?

Grande invite système fixe, des milliers de requêtes

Oui – revenus les plus élevés

Beaucoup de questions sur les mêmes documents de référence

Oui

Texte court complètement différent pour chaque demande

Non, le bonus d'écriture est gaspillé

Demande unique

Non, pas de lecture du tout

Date/ID changeant à chaque demande à l'invite du système

Non : le préfixe est cassé, le résultat est nul

Étape par étape : comment configurer une invite de réponse ?

1. Séparez la constante et la variable. Quel contenu ne change jamais (invite système, livre de règles, documentation) ? Qu'est-ce qui change à chaque demande (question de l'utilisateur, date, identifiant) ?
2. Mettez la constante au début. Lors du traitement, la pièce qui vient en premier (outils, système) doit être stable.
3. Mettez la variable à la fin. Dernière question actuelle de l'utilisateur.
4. Placez le panneau au bout de la bordure. Mettez le point de cache dans le dernier bloc de la partie fixe.
5. Vérifiez le succès. Vérifiez si cache_read_input_tokens est supérieur à zéro dans le champ d'utilisation de la réponse. Si zéro, il y a un perturbateur caché dans le préfixe.

{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user", "content": "{{user_current_question}}" } ]}

Astuce : Ne devinez pas les accès au cache, mesurez-les. Si usage.cache_read_input_tokens est toujours nul sur les requêtes consécutives, un disjoncteur silencieux (datetime.now() à l'invite du système, JSON non ordonné, liste d'outils changeant à chaque requête) est en cours d'exécution. Comparez l'invite brute des deux requêtes octet par octet et trouvez la différence.

Perturbateurs silencieux

Modèles typiques qui corrompent le cache sans le savoir :

# BREAKER : intégration d'informations dans l'invite système qui changent à chaque requête "Date d'aujourd'hui : {{maintenant}}. Vous êtes un assistant..." ← le préfixe change à chaque requête, le hit est zéro# VRAI : déplacez la variable vers le système de messages : "Vous êtes un assistant..." ← une constante entre les messages de cache : [{role: user, content: "Aujourd'hui, c'est {{now}}. Question : ..."}] ← variable à la fin

Autres disjoncteurs : JSON trié différemment à chaque requête (conserver les clés dans un ordre fixe), liste des outils variant selon l'utilisateur (les outils sont traités en premier ; rien ne va dans le cache s'ils changent), modification du modèle en cours de conversation (les caches sont spécifiques au modèle).

Invite faible/Invite forte (structure conviviale pour le cache)

# Système FAIBLE (construction de contournement de cache) : "Date : 18.07.2026 14:32. Utilisateur : Ahmet (id 8842). Vous êtes un robot de support. Règles : ...(2000 jetons)..."

# Système FORT (structure conviviale pour le cache) : "Vous êtes un robot de support. Règles : ... (2000 jetons, ne change jamais)..." [signe du cache] messages : [ { rôle : utilisateur, contenu : "Date : 18.07.2026 14:32. ID utilisateur : 8842. Question : comment puis-je lancer mon remboursement ?" }]

Dans la version faible, le bloc de règles de 2 000 jetons est traité au coût total à chaque requête. Dans la version forte, le même bloc est écrit une fois et lu sur toutes les demandes ultérieures pour un dixième du prix.

Trois mini-étuis

Cas 1 — Mise en cache du livre de règles. Une automatisation comptable ajoutait le règlement de 12 000 jetons à chaque facture ; 5 000 demandes par jour. L'entrée sans cache coûte environ 180 $ par jour. Ils ont gardé le livre de règles constant et l'ont mis en cache : les premières requêtes payaient une prime en écriture, les lectures suivantes 0,1×. Le coût des intrants a chuté d’environ 90 % à environ 18 $ par jour.

Cas 2 — Coût de la ligne de date cachée. Une équipe a installé une cache mais n’a obtenu aucun résultat ; cache_read_input_tokens était toujours nul. Raison : Il y avait datetime.now() dans la première ligne de l'invite système, le préfixe changeait à chaque requête. Lorsque nous avons déplacé la date vers le message utilisateur, le taux de réussite a soudainement augmenté de 0 % à 94 %.

Cas 3 — Cache égaré. Une application de recherche envoyait des requêtes courtes complètement différentes à chaque requête ; Ils ont ajouté avec empressement un panneau de cache. Sans préfixe commun, chaque requête ne payait qu'une prime d'écriture, pas de lecture, ce qui augmentait le coût. Ils ont enlevé le panneau. Leçon : le cache ne paie que s'il existe un préfixe volumineux et constant qui est réutilisé.

Erreurs courantes

• Mélange de constante et de variable : lorsque le contenu de la variable est dans le préfixe, le hit est réinitialisé.
• Intégration de la date/ID dans l'invite système : le perturbateur silencieux le plus courant.
• Ne pas mesurer le hit : si cache_read_input_tokens n'est pas coché, le gaspillage ne sera pas remarqué.
• Ajout de cache lorsqu'il n'y a pas de préfixe public : Vous ne payez que la prime d'écriture, le coût augmente.
• Modification de la liste ou du modèle du véhicule : Le préfixe est cassé dès le début ; tout est réécrit.
• Oublier la taille minimale du cache : les caches très courts (moins de ~1 à 4 000 jetons selon le modèle) n'entreront pas dans le cache en silence.

Plus profond : conception du cache par type de charge de travail

Le gain réel de la mise en cache varie en fonction de la nature de votre charge de travail ; alors apprenez d’abord à connaître votre trafic. Trois modèles typiques et une installation correcte :

Invite système commune, questions différentes. Modèle d'entreprise le plus courant : une grande invite système (rôle, règles, peut-être un document de référence) avec des centaines de questions d'utilisateurs différentes. Ici, la partie fixe (système) est initialement mise en cache ; chaque nouvelle question ne paie le plein prix que pour sa petite partie. Le gain est très élevé car la grande partie est récitée de manière répétée au dixième du prix.

Monologue à plusieurs tours. Au fur et à mesure qu’une conversation se prolonge, chaque nouveau tour s’appuie sur tout l’historique précédent. Si vous mettez le flag cache à la fin du dernier tour, chaque requête réutilise le préfixe de conversation précédente ; les hits s’accumulent à mesure que la conversation se développe. Cela réduit considérablement le coût des longues sessions d’assistance.

Le préfixe partagé est le dernier élément à modifier. Plusieurs requêtes partagent un large ensemble de priorités fixes (ensemble d’échantillons, instructions) mais sont séparées par une seule question à la fin. Vous placez le pointeur de cache à la fin de la partie partagée ; Sinon, chaque requête écrirait son propre cache séparé et rien ne serait lu.

Attention : le cache dépend du modèle et d'une certaine taille minimale. Les très petits préfixes (moins de quelques milliers de jetons, selon le modèle) n'entreront pas silencieusement dans le cache même si vous les signalez — cache_creation_input_tokens reste nul. De plus, la modification du modèle en cours de conversation invalide l'intégralité du cache ; Si une tâche différente nécessite un modèle bon marché, conservez le flux principal dans un modèle et placez la tâche secondaire dans un appel séparé.

En résumé

La mise en cache des invites est une correspondance de préfixe : le contenu fixe doit être au début, le contenu variable doit être à la fin. Pour un contexte volumineux et réutilisé, le coût de lecture représente un dixième du prix total, soit à peu près le seuil de rentabilité en deux requêtes. L'erreur la plus courante consiste à corrompre le préfixe en intégrant des données variables dans l'invite système ; Vous vérifiez le hit en le mesurant dans le champ d'utilisation.

Tâche de candidature

Choisissez une charge de travail. (1) Divisez le contenu en deux colonnes : « ne change jamais » et « change à chaque demande ». (2) Redessinez la structure de l'invite, en mettant la partie constante au début et la partie variable à la fin. (3) Estimez la taille du jeton de la partie fixe et comparez le coût mensuel avec/sans cache. (4) Notez à partir de quel champ (cache_read_input_tokens) vous vérifierez le résultat.

liste de contrôle

• [ ] Je peux expliquer que le cache est une correspondance de préfixe et la seule règle immuable.
• [ ] Je peux augmenter la précision en mettant le contenu fixe au début et la variable à la fin.
• [ ] Je connais l'économie de l'écriture/lecture et le seuil de rentabilité à deux demandes.
• [ ] Je peux reconnaître les perturbateurs silencieux (date, JSON non ordonné, liste de véhicules changeante).
• [ ] Je peux vérifier le résultat avec usage.cache_read_input_tokens.