Vous aurez peut-être remarqué que certains fournisseurs proposent des prix spécifiques pour les tokens mis en cache.
Voyons ce que cela signifie concrètement.
Le prompt caching est une technique d'optimisation qui consiste à réutiliser des calculs déjà effectués pour un même prompt. Dans un modèle de type Transformer, chaque token est calculé en fonction des tokens qui le précèdent.
Cela implique qu'un même début de prompt produira les mêmes calculs internes (dans des conditions identiques).
Donc ce qu'on doit comprendre, c'est que ce caching, dans la majorité des implémentations actuelles, ne peut s'activer que si le début d'un prompt reste strictement identique.
Certains fournisseurs comme OpenAI ou Anthropic peuvent activer ce mécanisme automatiquement ou manuellement à partir d'un certain volume de tokens.
Faisons une expérience simple. On génère une chaîne aléatoire et on la place :
- une fois au début du prompt
- une fois à la fin du prompt
pour voir si le caching fait une différence. Voici le pseudo-code utilisé avec le modèle gpt 5.4 the openai :
1. Charger un grand texte fixe
2. Créer le modèle d’IA
3. Répéter 4 fois :
- Générer un ID aléatoire
- Envoyer au modèle deux versions :
A) ID au début + grand texte
B) ID à la fin + grand texte
- Pour chaque version, afficher :
• le nombre total de tokens
• les tokens venant du cache
Voici les logs obtenus après exécution :
Variable au début -- Token Total: 2233, Token cache utilisé: 0 Variable à la fin -- Token Total: 2232, Token cache utilisé: 0 (le cache n'existe pas encore) Variable au début -- Token Total: 2238, Token cache utilisé: 0 Variable à la fin -- Token Total: 2237, Token cache utilisé: 2176 Variable au début -- Token Total: 2232, Token cache utilisé: 0 Variable à la fin -- Token Total: 2232, Token cache utilisé: 2176 Variable au début -- Token Total: 2228, Token cache utilisé: 0 Variable à la fin -- Token Total: 2227, Token cache utilisé: 2176 ...
Dans un des cas, aucun cache ne s'active : les 10 appels coûtent environ ≈ 0.055 €.
Dans l'autre cas, 9 des dix appels sont servis depuis le cache, le coût devient ≈ 0.0125 €.
Et bien sûr, l'écart se creuse quand le nombre d'appel augmente.
Bon, dans cet exemple le gain est évidemment énorme vu qu'on triche un peu : le contenu que l'on peut mettre en cache représente 97% de la requête et la sortie n'est qu'un seul mot (on demande au LLM de répondre uniquement par oui), ce qui est rarement le cas, mais on voit que la différence peut être considérable selon l'utilisation.
Et dans certains cas, il serait même préférable de rajouter plus de token dans le prompt juste pour activer le cache si le seuil requis n'est pas atteint.
Particularité d'Anthropic
Le prix des tokens mis en cache est plus élevé que celui des tokens non cachés, ce qui signifie que, techniquement, il est possible de dépenser plus avec une très mauvaise utilisation des caches. Bien sûr, en règle générale, le system prompt et les skills ne changent pas à chaque appel, donc c'est un cas qui ne devrait pas arriver.
C'est sûrement aussi pour cela qu'il faut activer le caching manuellement dans l'appel de l'API, alors qu'OpenAI le fait automatiquement puisqu'il n'y a pas de prix différenciés.
Une autre particularité est la possibilité de cacher pendant 1 heure au lieu de 5 minutes, pour un coût deux fois supérieur au tarif normal. Au départ, je m'étais dit que c'était destiné aux cas de haute fréquence d'appels sur une longue durée, mais le TTL (Time To Live) du cache de 5 minutes est réinitialisé à chaque utilisation.
Donc un cache actif peut rester valide tant qu'il est régulièrement sollicité. Ce cache d'1 heure vise plutôt des flux longs ou intermittents plutôt que des usages à haute fréquence (c'est aussi écrit dans la documentation).
Pour Claude Code, même si on a généralement beaucoup plus de tokens lus qu'écrits (en regardant les champs cache_creation_input_tokens et cache_read_input_tokens), il y a encore une recherche plus approfondie à faire sur la façon dont les messages et prompts sont structurés. Par exemple, si les instructions des skills sont ajoutées au system prompt, celà veut dire qu'on perd le cache de la conversation (rappel : d'un point de vue API, on envoie à chaque message toute la conversation qui a eu lieu). Si elles sont rajoutées à la fin, on garde le cache mais on perd la fiabilité du modèle.
L'utilisation du cache dans les APIs d'Antropic et Claude Code mériterait un deuxième article plus approfondi, vu les possibilités de personnalisation pour tester différents cas d'usage.
Conclusion
Au final, les différences d’implémentation entre fournisseurs montrent que le sujet est encore en évolution.
Entre cache automatique, TTL variables, tarif différencié ou activation manuelle, il n’existe pas encore de standard.
Bien que ce sujet soit peu documenté (Mistral n'a même pas de documentation publique sur le sujet alors que cela existe aussi chez eux), il n’est pas anodin et peut impacter le choix du fournisseur de modèle, au vu des économies possibles.
