Notre banc A/B, en public. Mesurez-nous.

Ce qui est mesuré, et comment

• Deux bras, la même requête. A va directement au fournisseur, sans la couche ; B passe par la couche avec sa configuration par défaut. Même prompt, même échantillonnage, même plafond de sortie.
• Le coût est compté par le fournisseur. Chaque bras est valorisé à partir de l<code>usage</code> que lAPI renvoie à chaque appel, au prix catalogue. L'économie est 1 − coût(B) / coût(A) de la même exécution, pas ce que la couche dit d'elle-même.
• Intervalles au 95 %. Chaque harnais les calcule (rééchantillonnage par familles de questions, Wilson pour les taux de refus). Un intervalle qui traverse zéro veut dire « indiscernable de zéro », et nous le disons.
• Le paquet que vous installez. Le bras B exécute la source du tag 0.4.31 ; son dist/index.js est identique octet pour octet à celui du tarball npm (sha256 b52f99cacf9804ecd3153e56f26ec3adcdc2510d52a8446a369ecf914e0b5731).
• Pas de raccourcis. Chaque harnais surveille les hôtes auxquels il parle et porte un plafond de dépense par modèle écrit dans le code. Un modèle qui n'a pas pu être mesuré apparaît comme « non mesuré », avec le motif.

Quatre batteries, jeux de données publics, figés

Économie mesurée par modèle

GSM8K, avec un flux de requêtes où 30 % sont des répétitions exactes et 20 % des paraphrases. C'est la batterie au trafic répété : votre économie dépend de la répétitivité du vôtre. Sans répétitions, voir « Ce qui ne fait pas économiser ».

D'où vient l'économie, position par position : « depuis le cache exact » est ce que A a payé sur les requêtes que la couche a servies sans appeler le fournisseur ; « dans les appels » est la différence sur celles qui l'ont effectivement atteint, surtout le cache de préfixe du fournisseur (plus une part de variation de la sortie). Les deux s'additionnent pour donner l'économie totale.

L'exactitude est mesurée sur les questions avec une réponse publiée ; les variantes avec un nombre modifié servent uniquement à vérifier que la couche ne renvoie jamais la réponse d'une autre question.

Garanties, comptées

Ce qui ne fait pas économiser

Sans répétitions, l'économie est ≈ 0 %. Nous le publions quand même, parce que c'est ce que vous verrez si votre trafic ne se répète pas.

MT-Bench est un chat en deux tours avec une couche neuve à chaque question : il n'y a rien que le cache puisse réutiliser, et le prompt n'atteint presque jamais le minimum requis par le fournisseur pour mettre un préfixe en cache. Dans BFCL, chaque appel d'outil est différent. Ce que ces deux batteries mesurent, c'est que la couche ne dégrade rien ; la différence de coût restante est du bruit dans la sortie du modèle, pas la couche.

État par modèle et batterie

Chaque cellule montre l'exécution sur la version la plus haute de la couche. Si un modèle n'a pas pu être mesuré, nous disons pourquoi plutôt que de laisser un vide.

Bugs trouvés par le banc

Le banc n'est pas là pour bien paraître : il est là pour trouver les bugs avant vous. Il a trouvé ceux-ci, avec la version où ils sont apparus et celle qui les corrige.

1. Le cache sémantique non calibré servait la réponse d'une autre question 0.4.30 → 0.4.31

   Avec le cache sémantique non calibré, une variante avec un autre nombre (« three baskets » contre « two baskets ») pouvait recevoir la réponse de la question originale. Compté sur les variantes de GSM8K.

   • Trouvé dans la 0.4.30 : 15 sur 111. gsm8k.json
   • Corrigé dans la 0.4.31 (#383).
   • Vérifié en direct sur la 0.4.31 : 0 sur 198.

2. La couche réduisait le catalogue d'outils sans aucun signal pour le faire 0.4.30 → 0.4.31

   Dans les conversations à plusieurs tours, le bras B envoyait moins d'outils que le bras A alors que rien n'indiquait lesquels étaient inutiles. Compté sur les conversations multi-tours de BFCL.

   • Trouvé dans la 0.4.30 : 20 sur 20. bfcl.json
   • Corrigé dans la 0.4.31 (#382).
   • Vérifié en direct sur la 0.4.31 : 0 sur 83.

3. Certains refus écrits en texte étaient mis en cache 0.4.31 → 0.4.32

   Un refus que le modèle écrit en texte (sans le signal de l'API) pouvait être mis en cache, répété et crédité comme une économie. Compté dans les prompts XSTest.

   • Trouvé dans la 0.4.31 : 39 sur 2 824. xstest-0431-claude.jsonxstest-0431-gama-alta.jsonxstest-0431.json
   • Corrigé dans la 0.4.32 (#393, #401).
   • En attente d'être remesuré en direct sur la 0.4.32.

4. Un filtre de contenu de Gemini était mis en cache comme une réponse 0.4.31 → 0.4.32

   Gemini signale son filtre avec un motif d'arrêt qui lui est propre, que la couche ne reconnaissait pas comme un refus, si bien qu'elle pouvait le mettre en cache et le répéter. Compté dans les prompts XSTest.

   • Trouvé dans la 0.4.31 : 6 sur 508. xstest-0431-gama-alta.json
   • Corrigé dans la 0.4.32 (#402).
   • En attente d'être remesuré en direct sur la 0.4.32.

5. Gemini ne passait pas par la couche 0.4.31 → 0.4.32

   La couche envoyait un champ propre à l'API OpenAI à tout endpoint compatible, et Gemini le rejette : toutes les requêtes du bras B échouaient. Compté dans les requêtes GSM8K.

   • Trouvé dans la 0.4.31 : 504 sur 504. gsm8k-0431-gama-alta.json
   • Corrigé dans la 0.4.32 (#402).
   • En attente d'être remesuré en direct sur la 0.4.32.

6. Avec Gemini 3, le deuxième tour avec outils échouait 0.4.31 → 0.4.32

   La couche ne renvoyait pas la signature de pensée que Gemini 3 exige à chaque appel d'outil, si bien que le tour suivant était rejeté. Compté dans les continuations multi-tours de BFCL.

   • Trouvé dans la 0.4.31 : 50 sur 50. bfcl-0431-gama-alta.json
   • Corrigé dans la 0.4.32 (#402).
   • En attente d'être remesuré en direct sur la 0.4.32.

Comment le reproduire

Le code du banc n'est pas encore public ; la méthode l'est, et elle tient en cinq étapes. Avec vos propres clés de fournisseur, vous pouvez la refaire et comparer chiffre par chiffre avec nos rapports.

1. Le jeu de données. Téléchargez chaque jeu de données public au commit du tableau ci-dessus et vérifiez le sha256 de chaque fichier avant de l'utiliser. S'il ne correspond pas, ce n'est pas le même jeu de données.
2. La couche. Installez @bivelio/savings-layer depuis npm dans la version indiquée par le rapport et vérifiez le sha256 de dist/index.js : chaque rapport porte le sien.
3. Deux bras par prompt. A va directement au fournisseur ; B envoie le même prompt, au même modèle et avec le même plafond de sortie, à travers la couche dans sa configuration par défaut. Une partie des prompts est répétée ou paraphrasée, comme dans le trafic réel, et l'ordre A/B est tiré au sort.
4. Le coût, c'est le fournisseur qui le dit. Additionnez ce que chaque bras est facturé d'après le usage renvoyé par le fournisseur, à son tarif publié. L'économie est 1 − coût B / coût A, avec son intervalle.
5. La qualité, dans la même exécution. Notez de la même façon les réponses des deux bras (réponse exacte pour GSM8K, appel d'outil pour BFCL, refus ou non pour XSTest, un juge pour MT-Bench) et comparez-les au rapport JSON de la même batterie et de la même version.

Les rapports

Chaque exécution laisse un rapport JSON avec sa conception, ses limites et chaque appel mesuré : usage, coût par bras et classification de la réponse. Ils sont servis depuis ce site.

Les rapports sont servis tels que le banc les a écrits, à une exception près : les données sur l'environnement de la personne qui a mesuré (chemins de disque, adresses e-mail) sont retirées. Pour XSTest, aucun texte de réponse n'est publié, seulement sa classification.