HotKV a réduit de 70 % l’utilisation de tokens de Claude dans notre benchmark Banking77

Un cache sémantique promet de réduire les dépenses de LLM en répondant depuis la mémoire aux questions répétées et similaires au lieu d’appeler le modèle. Nous l’avons mesuré de bout en bout : les mêmes 3 000 requêtes de support client, envoyées deux fois à chacun de quatre modèles Claude, une fois directement au modèle et une fois avec HotKV devant, le cache de prompts propre à Anthropic restant activé dans les deux exécutions. Voici exactement ce que nous avons exécuté et ce que nous avons constaté, y compris ses limites.

En bref. HotKV a réduit d’environ 70 % les appels au modèle, les tokens d’entrée plus de sortie et le coût de l’API sur chacun des quatre modèles. L’essentiel vient des questions qui se répètent à l’identique. La couche sémantique ajoute environ 12 points. Au seuil de similarité par défaut de 0,81, les réponses en cache ont été jugées adaptées à la question exacte moins souvent que les réponses fraîches, de 5,8 à 10,7 points de pourcentage. Sur le seul modèle pour lequel nous avons fait varier le seuil (Sonnet 5.5), un seuil de 0,88 ou plus n’a montré aucun écart de ce type.

Mise à jour du 12 octobre 2026 : cet article présente désormais notre exécution plus large sur quatre modèles Claude actuels. Il remplace une exécution antérieure de 1 500 requêtes sur GPT et Claude Sonnet 5, qui avait mesuré environ 60 % de tokens en moins, ce que nous ne présentons plus.

Ce que nous avons testé

La charge de travail

Nous avons rejoué des questions de support client issues du jeu de test de Banking77 (PolyAI, CC BY 4.0), un jeu de données public de courtes questions bancaires étiquetées selon 77 intentions. Il a été présenté dans Casanueva et al., 2020. Les 3 000 requêtes ont été tirées avec une graine fixe. La popularité des intentions suit une distribution de Zipf d’exposant 1,0, un biais synthétique dans lequel quelques intentions reviennent bien plus souvent que les autres, et la question au sein d’une intention est choisie uniformément, avec répétitions. Les 77 intentions apparaissent, et 1 264 des 3 000 requêtes sont des questions distinctes (comptées en rejouant le générateur de requêtes à graine fixe). La banque et sa politique de support sont fictives. Nous avons rédigé une politique d’environ 2 200 tokens, envoyée comme prompt système à chaque requête, qui demande de deux à quatre phrases courtes.

Modèles et réglages

Nous avons exécuté claude-fable-5-1, claude-opus-5-5, claude-sonnet-5-5 et claude-haiku-5-5. Fable 5.1 et Opus 5.5 ont tourné à leur réglage d’effort le plus bas, car leur réflexion ne peut pas être désactivée. Sonnet 5.5 a tourné avec la réflexion préalable désactivée, son réglage le plus bas, et Haiku 5.5 avec la réflexion désactivée. La sortie maximale était de 2 000 tokens pour Fable et Opus et de 400 pour Sonnet et Haiku, et chaque réponse s’est terminée normalement au lieu d’être coupée. Huit requêtes s’exécutaient à la fois dans les deux modes, les appels n’étaient pas diffusés en streaming, et chaque condition a été exécutée une fois.

Les deux exécutions

• Référence : chaque requête va directement au modèle, avec le cache de prompts d’Anthropic activé (cache_control sur le prompt système, durée de vie par défaut de cinq minutes). C’est la référence configurée utilisée ici, et non une affirmation selon laquelle toutes les optimisations côté fournisseur auraient été épuisées.
• Avec HotKV : HotKV se place devant le même trafic et le même prompt système, le cache démarrant vide.

Ce que nous avons compté

Chaque décompte de tokens provient du bloc usage de la réponse de l’API : entrée hors cache, lectures et écritures du cache, et sortie (réflexion incluse). Les tokens d’embedding sont comptés à part. Les coûts utilisent les prix catalogue d’Anthropic du 11 octobre 2026, incluent les appels d’embedding pour les recherches sémantiques et excluent l’hébergement et l’exploitation de HotKV. Ils ne tiennent pas lieu de devis aux tarifs actuels.

Comment fonctionne le cache

Pour chaque question, HotKV tente deux recherches avant l’appel au modèle :

1. Correspondance exacte : un GET sur une clé SHA-256 construite à partir du modèle, de la version du prompt système et de la question normalisée (en minuscules, espaces réduits). Elle attrape une question posée avec des mots identiques.
2. Correspondance sémantique : un appel SCACHE.GET avec un embedding de la question (OpenAI text-embedding-3-small, similarité cosinus). Elle cherche une question similaire. Un score de similarité seul ne peut pas garantir que la réponse en cache convient.

Seul un échec sur les deux atteint le modèle, et sa réponse est ensuite écrite dans le cache avec SET et SCACHE.SET. Le seuil de similarité pour un succès sémantique a été fixé à 0,81 avant l’exécution. Nous l’avons choisi sur une partition d’entraînement Banking77 distincte, comme la valeur la plus basse, par pas de 0,01, dont les succès sémantiques pointaient vers la même intention au moins 98 % du temps (98,2 % sur ce jeu). Dans cette exécution, sur le jeu de test intact, de 96,7 % à 96,8 % des succès sémantiques correspondaient à l’intention de la question posée : 30 ou 31 succès d’intention erronée par modèle sur 926 à 936.

Résultats

Appels, tokens et coût

Sur l’ensemble des quatre modèles, les appels sont passés de 12 000 à 3 588, les tokens ont baissé de 70,1 % et le coût de 69,6 %. Environ 70 % des requêtes ont été servies depuis le cache sur chaque modèle : environ 39 % par correspondance exacte et 31 % par correspondance sémantique.

Les appels, les tokens et les dollars baissent ensemble parce que HotKV supprime des appels entiers. Lisez le chiffre des tokens avec prudence : de 90 % à 93 % des tokens comptés sont des lectures de cache du même prompt de politique de 2 200 tokens, qu’Anthropic facture à une petite fraction du prix d’entrée normal. Les tokens de sortie ne représentent que 6 % à 9 % des tokens, mais de 73 % à 92 % du coût de référence.

Vitesse

Le temps de réponse médian sur l’ensemble de l’exécution est passé de 2,7 secondes à 127 ms sur Fable 5.1, de 2,9 secondes à 126 ms sur Opus 5.5, de 1,8 seconde à 128 ms sur Sonnet 5.5 et de 1,4 seconde à 125 ms sur Haiku 5.5, soit de 11 à 23 fois plus rapide. Une question répétée est revenue en une médiane d’environ 0,05 ms, mesurée par un client Python via loopback sur la même machine que HotKV : c’est donc un chiffre local et non un chiffre réseau. Une question reformulée, servie depuis le cache sémantique, a pris environ 130 ms, presque entièrement l’appel à l’API d’embedding.

La médiane sur l’ensemble de l’exécution se situe dans cette plage des succès sémantiques, car les succès exacts (environ 39 % des requêtes) sont trop peu nombreux pour porter la médiane à eux seuls, alors que les succès exacts et sémantiques réunis (70 %) dépassent la moitié. L’extrémité lente bouge moins : 30 % des requêtes appellent encore le modèle. Le 99e centile était d’environ 6,4 secondes avec HotKV contre 6,6 secondes sans lui sur Fable 5.1, et à peu près identique sur Haiku 5.5. Il était plus bas sur Opus 5.5 (4,7 secondes contre environ 6) et sur Sonnet 5.5 (2,7 secondes contre 3,3). Les appels n’étaient pas diffusés en streaming ; ce sont donc des temps jusqu’à la réponse complète, et non jusqu’au premier token.

Préchauffage

Le cache démarre vide ; les premières requêtes atteignent donc encore le modèle. La part de requêtes servies depuis le cache était d’environ 52 % sur les mille premières requêtes et d’environ 81 % sur les mille dernières.

D’où vient l’économie

L’essentiel de l’économie vient de la simple répétition. Un cache à correspondance exacte seul aurait nécessité au plus 1 264 appels au modèle sur 3 000, un par question distincte, soit environ 58 % de moins. La couche sémantique a porté ce chiffre à environ 70 %, et contribue donc pour environ 12 points sur cette charge de travail. C’est aussi la partie qui porte le risque sur la qualité des réponses, comme le montre la section suivante. Cela est déduit de la séquence de requêtes et des journaux, et non d’une exécution mesurée à part.

Qualité des réponses

Un succès sémantique signifie la même intention, et non la même bonne réponse. Pour mesurer l’exactitude, nous avons fait juger chaque succès sémantique par un autre modèle Claude. Le juge voyait la question du client et deux réponses dans un ordre aléatoire : la réponse en cache servie par HotKV, et la réponse fraîche que le même modèle avait donnée à cette question exacte lors de l’exécution de référence. Il indiquait si chaque réponse répondait correctement à cette question exacte. Opus 5.5 a jugé les réponses de Fable 5.1, de Sonnet 5.5 et de Haiku 5.5, et Fable 5.1 a jugé Opus 5.5 : aucun modèle n’a donc noté sa propre sortie.

Au seuil par défaut

À 0,81, une réponse en cache convenait à la question exacte moins souvent qu’une réponse fraîche du même modèle, de 5,8 à 10,7 points de pourcentage. Les succès sémantiques représentent environ 31 % des requêtes ; sur l’ensemble des réponses, et en comptant les succès exacts comme neutres, cela représente donc environ 2 à 3 points (1,8 à 3,3). Les juges diffèrent par leur sévérité ; comparez donc les réponses en cache et fraîches uniquement au sein d’un même modèle.

Relever le seuil

Nous avons réexécuté Sonnet 5.5 à quatre autres seuils, chacun à partir d’un cache vide, avec le même juge. Le coût de référence était de 5,51 $.

À partir de 0,88, les réponses en cache n’ont pas montré de déficit par rapport aux réponses fraîches, tout en réduisant encore le coût de 64 % à 0,88 et de 61 % à 0,90. Les preuves sont minces. À 0,90, l’intervalle à 95 % de la différence va d’environ 4 points en défaveur à 7 points en faveur des réponses en cache, la ligne 0,95 ne compte que 50 succès, et chaque ligne juge un sous-ensemble différent de succès. Il s’agit d’un seul modèle, d’un seul juge et d’une exécution par seuil ; ce n’est donc ni la preuve d’une qualité équivalente ni celle d’un seuil sûr universel.

Questions presque identiques

Le vrai risque tient aux questions qui paraissent presque identiques mais appellent des réponses différentes, comme un dépôt par opposition à un retrait. Nous avons demandé à Opus 5.5 de rédiger 119 paires, chacune composée d’une vraie question du jeu d’entraînement et d’une version dont un détail décisif est modifié, et nous avons compté combien de questions modifiées franchiraient le seuil face à un cache contenant uniquement l’original. Ces paires sont conçues pour être difficiles, n’ont pas été relues par une personne, et montrent un pire cas plutôt que la fréquence à laquelle il se produit dans le trafic réel.

Relever le seuil réduit le risque sans l’éliminer. Même à 0,90, 25 % des paires volontairement proches correspondraient, et moins de vraies reformulations correspondent aussi.

Ce que cela donne à grande échelle

En extrapolant le coût mesuré par requête à 1 million de requêtes par jour sur un mois de 30 jours, et en supposant le même profil de trafic, on obtient ces chiffres mensuels :

• claude-fable-5-1 : environ 303 100 $ sans HotKV, 91 800 $ avec, soit environ 211 300 $ économisés.
• claude-opus-5-5 : environ 146 000 $ sans HotKV, 45 000 $ avec, soit environ 101 000 $ économisés.
• claude-sonnet-5-5 : environ 55 100 $ sans HotKV, 16 600 $ avec, soit environ 38 500 $ économisés.
• claude-haiku-5-5 : environ 2 700 $ sans HotKV, 800 $ avec, soit environ 1 900 $ économisés.

Il s’agit d’un calcul à partir du coût mesuré par requête, et non d’une autre exécution mesurée. Il exclut l’hébergement, et la capacité nécessaire pour ce volume n’a pas été mesurée. Sur les 3 000 requêtes que nous avons exécutées, l’économie n’est que de 0,19 $ pour Haiku 5.5 et de 21,12 $ pour Fable 5.1. Les quatre modèles ont tourné avec des réponses courtes, et Fable 5.1 et Opus 5.5 à leur effort le plus bas ; des réponses plus longues ou plus gourmandes en raisonnement donneraient donc plus de valeur à chaque appel évité.

Limites

Ce n’est pas une affirmation générale du type « HotKV vous fait économiser 70 % ». C’est ce que nous avons mesuré sur cette charge de travail, et c’est elle qui fait le gros du travail.

• Les économies suivent la répétition. Avec toutes les intentions équiprobables au lieu d’une distribution de Zipf, le coût a baissé de 56 % sur Sonnet 5.5 et Haiku 5.5. Avec 3 000 questions toutes différentes, il a baissé de 38 %, entièrement grâce aux correspondances sémantiques entre des questions différentes de la même intention, dont Banking77 regorge. Une charge de travail sans question répétée ou similaire n’économise rien.
• Trafic synthétique. Les tirages sont indépendants : pas de rafales, de sessions ni de contexte multi-tours. Un seul jeu de données public de courtes questions bancaires, une politique fictive rédigée pour ce test, et un ensemble fini d’environ 3 080 questions de test.
• Un modèle juge les réponses. Aucun humain ne les a relues, il n’y avait pas de second juge, et chaque juge est un modèle Claude. Les réponses fraîches ont échoué au test du juge « la réponse convient » dans 1 % à 21 % des cas, ce qui en fait un critère strict.
• Même intention ne veut pas dire même réponse. Le seuil de 0,81 a été calibré sur des étiquettes d’intention, et non sur la qualité des réponses. Le balayage de seuils et le test des questions presque identiques couvrent un seul modèle et un seul modèle d’embedding.
• Petit banc de test. Une exécution par condition, un seul serveur à quatre vCPU avec le client sur la même machine, et un cache qui n’a pas été préchauffé avant les exécutions avec HotKV.
• Les coûts sont des coûts d’API. Ils excluent l’hébergement et l’exploitation de HotKV. Validez la qualité des réponses sur vos propres questions, et utilisez le cache exact ou des réponses fraîches lorsque la réutilisation sémantique ne convient pas.

Les chiffres par modèle figurent aussi sur la page IA.

Essayez par vous-même

Le cache à correspondance exacte de ce test utilise de simples GET et SET, que toutes les offres HotKV incluent. Le cache sémantique (SCACHE.*) est fourni avec l’offre Performance et les offres supérieures (tarifs). Commencez sur HotKV Cloud et dirigez votre trafic existant vers lui, ou contactez les ventes si vous souhaitez d’abord étudier les chiffres pour votre propre charge de travail.