Qu'est-ce que la mise en cache des invites ?
La plupart des applications LLM envoient le même bloc de texte au début de chaque requête : une longue invite système, un ensemble de définitions d'outils, quelques exemples ou un morceau de contexte de référence. Normalement, vous payez intégralement jeton d'entrée prix de ce bloc à chaque appel, même s'il ne change jamais.
Mise en cache rapide permet au fournisseur de stocker cette stabilité préfixe après le premier appel et, lors des appels ultérieurs commençant par exactement le même SMS, facturez-le à une petite fraction du tarif normal, souvent autour de 10% (une remise d'environ 90%). Vous payez toujours le prix fort pour la partie qui modifie chaque appel (la véritable question de l'utilisateur), mais les frais généraux fixes deviennent presque gratuits.
Calculateur d'économies de mise en cache rapide →Comment cela fonctionne entre les fournisseurs
Il existe deux grandes saveurs, et la différence compte pour votre facture.
Mise en cache explicite (par exemple Anthropic)
Vous marquez où se termine le préfixe pouvant être mis en cache. Le premier appel écrit le cache et coûte un peu plus qu'un jeton d'entrée normal - généralement environ 1.25× le débit d'entrée - car le fournisseur doit stocker le préfixe traité. Chaque appel ultérieur qui le réutilise est un lecture du cache, facturé environ 0.1× le débit d’entrée. La cache a un durée de vie (TTL) - souvent quelques minutes - qui s'actualise à chaque fois qu'il est touché, de sorte qu'un flux constant de trafic le maintient au chaud.
Mise en cache automatique (par exemple OpenAI et autres)
Le fournisseur détecte pour vous les préfixes répétés et applique une réduction sans prime d'écriture en cache ni modification de code. C'est plus simple, mais vous avez moins de contrôle : vous ne pouvez pas forcer un cache de longue durée, et les règles de réduction et d'éligibilité sont définies par le fournisseur (généralement entrant en vigueur une fois qu'un préfixe dépasse une longueur minimale).
| Cache explicite | Cache automatique | |
|---|---|---|
| Qui décide de ce qui est mis en cache | Vous (marquez le préfixe) | Fournisseur (détecte les répétitions) |
| Coût d'écriture du cache | ~1,25× entrée, une fois | Aucun |
| Coût de lecture du cache | ~0,1× entrée | À prix réduit (défini par le fournisseur) |
| Contrôle sur TTL | Oui | Non |
Les multiplicateurs sont des valeurs publiées typiques et varient selon le modèle et le fournisseur. Confirmez-les toujours sur la page de tarification du fournisseur.
Le compromis écriture/lecture — quand cela porte ses fruits
Avec un cache explicite, vous payez une petite prime unique pour écrire, puis bénéficiez d'une remise importante sur chaque lecture. La mise en cache est donc payante une fois que vous réutiliser le préfixe suffisamment de fois pour compenser le coût d'écriture. Le seuil de rentabilité est rapide : la prime d'écriture n'est que d'environ 0,25 × l'entrée supplémentaire, tandis que chaque lecture permet d'économiser environ 0,9 × l'entrée - vous êtes donc en avance après environ deux réutilisations du même préfixe. Après cela, chaque coup représente presque de pures économies.
Les ingrédients qui font de la mise en cache une victoire évidente :
- Un grand préfixe répété — plus il y a de jetons fixes, plus la remise est importante en termes absolus.
- Volume d'appels élevé — de nombreuses requêtes partagent le même préfixe dans la fenêtre TTL.
- Un préfixe stable — le bloc réutilisé est identique octet par octet à chaque appel.
Les applications de récupération augmentée, les assistants de codage avec de grandes invites système et le chat multi-tours correspondent tous à cette forme. Voir les tactiques plus larges dans le guide pour réduire votre facture API LLM.
Un exemple concret
Dis que tu as un Invite système de 2 000 jetons (instructions + définitions d'outils + quelques exemples) qui sort à chaque demande, et vous faites 100 000 appels. Supposons un prix d'entrée de 3 $ par million de jetons, un taux de lecture du cache de 0,1 × (0,30 $/M) et un taux d'écriture du cache de 1,25 × (3,75 $/M). Nous ignorerons ici la question et le résultat de l'utilisateur par appel, car la mise en cache ne les modifie pas.
Sans mise en cache
Chaque appel paie le plein tarif pour les 2 000 jetons de préfixe :
100 000 × 2 000 = 200 000 000 jetons × 3 $/M = $600.
Avec mise en cache
Le préfixe est écrit une fois et lu sur les 99 999 autres appels (en pratique, il est réécrit à chaque expiration du TTL, mais avec un trafic constant et négligeable) :
- 1 écriture : 2 000 jetons × 3,75 $/M ≈ $0.0075
- 99 999 lectures : ~200 000 000 jetons × 0,30 $/M ≈ $60
Total ≈ $60 contre 600 $ — un ~90 % de réduction sur la partie répétée de la facture, pour le prix d'une ligne marquant la fin du préfixe. Sur des charges de travail réelles, le préfixe est souvent plus grand et les appels plus fréquents, de sorte que l'économie absolue est encore plus importante.
Calculateur du coût des jetons →Estimez vos économies →Les pièges à surveiller
- Tout avant le changement de pièce doit être identique. Mise en cache des correspondances sur un préfixe exact. Un horodatage, un nom d'utilisateur ou un exemple de commande mélangée près du haut invalide la correspondance et vous payez silencieusement le plein prix.
- Expiration de la durée de vie. Si le trafic est clairsemé et que l'intervalle entre les appels dépasse la durée de vie du cache, le préfixe expire et l'appel suivant paie à nouveau le coût d'écriture. Les charges de travail intenses et à faible volume en bénéficient le moins.
- Les petits préfixes n'en valent pas la peine. En dessous de la longueur minimale de mise en cache d'un fournisseur – ou lorsque le bloc fixe ne contient que quelques centaines de jetons – les économies sont minimes et la prime d'écriture peut vous laisser dans une situation légèrement pire.
- Mettez les éléments stables en premier. La structure invite de sorte que l'invite système, les outils et le contexte immuables précèdent l'entrée volatile de l'utilisateur ; la mise en cache ne peut couvrir que la première série de jetons identiques.
Questions fréquemment posées
Combien la mise en cache des invites permet-elle d’économiser ?
Lors d'une lecture du cache, la plupart des fournisseurs facturent les jetons mis en cache à environ 10 % du taux d'entrée normal, soit une réduction de 90 % sur la partie répétée de votre invite. Le chiffre exact varie selon le fournisseur, mais c'est avec un préfixe volumineux et stable réutilisé pour de nombreux appels que les économies sont les plus importantes.
La mise en cache rapide coûte-t-elle plus cher à mettre en place ?
Avec les caches explicites (comme celui d'Anthropic), le premier appel qui écrit le cache coûte légèrement plus cher qu'un jeton d'entrée normal - généralement environ 1,25 fois le débit d'entrée. Vous récupérez cette prime d'écriture dès que vous réutilisez le préfixe plusieurs fois, après quoi chaque accès est facturé au tarif de lecture très réduit.
Quand la mise en cache rapide n’en vaut-elle pas la peine ?
La mise en cache n'est utile que lorsqu'un préfixe volumineux est identique d'un appel à l'autre et réutilisé avant l'expiration du cache. Un préfixe court, une invite qui modifie chaque appel ou un faible volume d'appels signifie que le coût d'écriture n'est jamais récupéré. Dans ces cas, la mise en cache ajoute une surcharge au lieu d'économiser de l'argent.
Référence pédagogique uniquement : les taux de cache, les durées de vie et les longueurs minimales sont des estimations ; confirmer les conditions actuelles sur la page de tarification de chaque fournisseur.