Illustration conceptuelle originale réalisée avec l’aide de l’IA pour SPKE. Les branches représentent la réutilisation et l’expiration, pas des performances mesurées.
Partir de la charge de travail
Une application pose dix questions sur le même document. Son développeur voit un tarif avantageux pour les tokens d’entrée en cache et s’attend à une baisse comparable de la facture. Ce raisonnement élude les questions essentielles : le préfixe réutilisable a-t-il réellement été écrit dans le cache ? Chaque requête lui correspondait-elle ? Et la réutilisation a-t-elle eu lieu avant son expiration ?
Notre conclusion : il faut comparer le coût par tâche validée avec un enchaînement réaliste des requêtes, et non la plus forte remise annoncée sur le cache. Cette analyse s’appuie sur la documentation officielle vérifiée le 22 octobre 2026 et sur un calcul explicitement hypothétique. SPKE n’a pas réalisé de benchmark des fournisseurs. Cette documentation non datée est mise à jour en continu ; la date de vérification n’est ni une date de publication ou d’annonce ni une date d’entrée en vigueur.
Une comparaison utile entre la Chine et les États-Unis
Les fournisseurs américains OpenAI et Anthropic, ainsi que le fournisseur chinois DeepSeek, proposent des moyens de contrôle différents. Leur pays d’origine ne permet pas de prédire la bonne configuration pour une application. Il faut comparer le modèle exact, l’API, la durée de validité du cache et la charge de travail.
Le guide actuel d’OpenAI distingue GPT-5.6 et les modèles ultérieurs des modèles précédents : les modèles plus récents appliquent des tarifs majorés pour les écritures en cache et définissent les limites auxquelles une recherche dans le cache est possible. Il n’est plus prudent de supposer, de manière générale, que les écritures en cache chez OpenAI ne coûtent rien de plus. Guide OpenAI
Anthropic indique des tarifs d’écriture différents selon que la durée de validité du cache est de cinq minutes ou d’une heure, tandis que les tarifs de lecture varient selon le modèle. Une remise unique à l’échelle du fournisseur ne suffit donc pas pour établir un budget. Tarifs Anthropic
L’exemple de DeepSeek montre qu’après A+B, A+C ne trouve pas de correspondance dans le cache, avant qu’un préfixe commun A enregistré puisse servir à A+D. La simple répétition du texte ne suffit pas. Cache DeepSeek
Ces différences suggèrent une question d’achat plus utile que « quel pays propose l’IA la moins chère ? » : quelle implémentation réutilise de façon fiable nos requêtes réelles, avec la qualité dont nous avons besoin ? Il s’agit d’une comparaison technique, pas d’un classement des capacités nationales.
Une remise n’est pas une baisse de facture
Voici un calcul simplifié, et non une offre tarifaire. Considérons uniquement un préfixe identique et éligible à la mise en cache. Soit n le nombre total de requêtes, première écriture comprise ; w le multiplicateur du prix d’écriture ; et r le multiplicateur du prix de lecture, par rapport au tarif des entrées ordinaires. Supposons une écriture et n−1 lectures complètes réussies, sans expiration ni réécriture.
Coût sans cache, en unités normalisées : n. Coût avec cache : w + (n−1) × r. Pour 0 ≤ r < 1, la mise en cache est moins chère lorsque n > (w−r)/(1−r).
Avec les valeurs hypothétiques w = 1.25 et r = 0.1, dix requêtes coûtent 2.15 unités au lieu de 10. L’économie sur le préfixe est de 78.5%, alors que chaque lecture coûte 90% de moins. Avec w = 2 et r = 0.1, il faut au moins trois requêtes au total pour économiser ; avec w = 1.25, deux suffisent.
Il s’agit d’un seuil idéal qui ne porte que sur le préfixe. Les entrées dynamiques, les sorties générées, les outils, les nouvelles tentatives et les écritures répétées peuvent modifier le résultat à l’échelle de la tâche. Une configuration qui réduit la facture du préfixe mais exige davantage de corrections peut être perdante au total. Avant d’établir un budget, remplacez les multiplicateurs hypothétiques par les tarifs actuels du modèle exact.
Trois formes de réutilisation
Premier cas : une conversation séquentielle enrichit un historique conservé. Deuxième cas : des questions indépendantes partent d’un document commun. Troisième cas : un lot de requêtes parallèles démarre à froid, avant qu’un cache réutilisable soit prêt. Un même volume de tokens répétés ne rend pas ces charges de travail équivalentes.
Chez Anthropic, le cache devient disponible après le début de la première réponse, et la fenêtre de cinq minutes commence au lancement de la requête. Le moment du lancement et la longueur des réponses ont donc leur importance. Cache Anthropic
Notre recommandation de conception consiste à séparer les documents de référence stables des questions changeantes, à conserver des limites cohérentes et à tester l’enchaînement réel des requêtes. N’insérez pas d’horodatage ni d’identifiant de requête avant le contenu stable sans en vérifier l’effet. N’ajoutez pas aveuglément des appels de préchauffage : ils consomment des ressources, et les utilisateurs ne feront peut-être jamais la requête suivante.
Un plan de validation avant le déploiement
Utilisez le même ensemble de tâches assorties d’exigences de qualité dans quatre conditions : démarrage à froid, réutilisation d’un cache chaud, pauses réalistes et trafic simultané. Il s’agit d’un plan de test proposé, pas d’une expérience que nous avons menée.
- Consignez le modèle et sa version, l’API, la structure des requêtes, les paramètres du cache et le niveau de service. Gardez des contenus et des critères de qualité comparables.
- Ramenez les champs d’utilisation du fournisseur à trois catégories communes : entrées ordinaires, écritures en cache et lectures du cache. Vérifiez ce que chaque champ inclut avant de les additionner, afin d’éviter les doubles comptages. Si un fournisseur ne distingue que les entrées avec ou sans correspondance dans le cache, n’inventez pas de frais d’écriture distincts.
- Calculez le coût total par tâche validée, y compris les tentatives infructueuses, les sorties et les outils. Signalez aussi les tâches rejetées, pour que des échecs moins coûteux ne puissent pas embellir le chiffre principal.
- Mesurez le délai jusqu’au premier token et la latence de bout en bout, en incluant les cas les plus lents, par exemple avec le p95. Présentez séparément les résultats à froid et à chaud.
- Ne faites varier qu’un facteur à la fois : limite du préfixe, pause ou concurrence. Conservez une référence et documentez la cause des défauts de correspondance dans le cache.
Ce qu’il faut acheter, et ce qu’on ne peut pas en déduire
Choisissez une configuration qui respecte les exigences de qualité et de latence au plus faible coût mesuré par tâche. Un taux élevé de correspondances dans le cache ne constitue pas, à lui seul, un critère de réussite : un prompt répété surdimensionné peut améliorer ce taux tout en rendant chaque tâche inutilement coûteuse.
Pour les équipes qui comparent des API chinoises et américaines, l’acquis réutilisable est une charge de travail reproductible et un relevé de coûts normalisé. Ni un faible prix des tokens en cache ni une correspondance dans le cache ne prouvent que les réponses sont meilleures. Cet article établit une méthode de décision ; il ne désigne pas de fournisseur gagnant.