BV-SALA : au cœur de la couche de coût des LLM

La facture d'un système fondé sur des LLM ne croît pas avec la valeur qu'il produit : elle croît avec les tokens qu'il fait circuler. Et la plupart de ces tokens n'avaient jamais besoin de circuler. Du contexte répété à chaque tour, des outils déclarés qui ne sont jamais appelés, des questions dont la réponse avait déjà été calculée une minute plus tôt. BV-SALA est la couche qui se place devant votre fournisseur et, à chaque requête, répond à une seule question : quelle est l'exécution la moins chère qui respecte encore votre contrat de qualité ?

Cet article explique comment nous abordons cette question : la formalisation, les trois registres dans lesquels tombe toute économie, et la méthode de mesure — qui est, délibérément, la partie la plus stricte du système.

La décision, formalisée

Pour une requête $x$ (prompt, contexte, outils), le fournisseur facture une fonction essentiellement linéaire en tokens :

où $T$ compte les tokens avec le tokenizer du fournisseur lui-même — et non avec une approximation de notre cru — et $c_{\text{in}}, c_{\text{out}}$ sont ses prix en vigueur. BV-SALA dispose d'un catalogue $\Pi$ de transformations de requêtes : supprimer la redondance, élaguer les outils, compresser l'encodage, résoudre sans appeler. Bien choisir est un problème d'optimisation sous contrainte :

La contrainte $Q \ge \tau$ est le contrat de qualité : la transformation la moins chère ne vaut rien si elle dégrade la réponse. Et c'est là que réside la difficulté intrinsèque du problème : $Q$ n'est pas observable avant l'exécution. C'est pourquoi chaque transformation du catalogue porte sa propre garde — elle ne s'applique que lorsqu'elle est rentable, le coût de la décision étant comptabilisé dans l'économie, et non caché à l'extérieur.

Les trois registres

Chaque requête optimisée est attribuée à exactement un registre, selon le mécanisme dominant. Cette partition n'est pas cosmétique : c'est elle qui donne un sens aux chiffres.

Tous les chiffres de cette section proviennent d'une seule exécution, celle-là même que sert aujourd'hui le produit : openai/gpt-4o-mini, 193 paires mesurées, qualité 100 %, artefact d1c8233 du 12 septembre 2026. Chacun est le plancher de l'intervalle de confiance à 95 % de son registre, sur ce modèle ; un pourcentage sans son modèle à côté ne veut rien dire.

01 — Éviter complètement l'appel. Des résolveurs déterministes pour ce qui n'a pas besoin d'un modèle, et le singleflight pour regrouper en une seule exécution des requêtes identiques simultanées. Le catalogue comprend aussi un cache exact, mais l'économie mesurée de ce registre dans l'exécution publiée provient des résolveurs et du singleflight : ce qui n'a pas été mesuré n'est pas annoncé. Plancher du registre sur gpt-4o-mini : 22,0 %.

02 — Retirer ce qu'il n'était pas nécessaire d'envoyer. Outils élagués du catalogue déclaré, récupération sélective au lieu du contexte complet, et suppression du contexte redondant qui circule tour après tour. Plancher du registre sur gpt-4o-mini : 43,2 %.

03 — Compresser ce qui reste. Un encodage plus léger de ce qui doit vraiment circuler — et seulement quand la compression elle-même est rentable. Plancher du registre sur gpt-4o-mini : 20,1 %.

L'économie d'un registre $\ell$ sur l'ensemble $R_\ell$ des requêtes qui lui sont attribuées se définit par rapport à un bras de contrôle — et se mesure face aux deux bras déclarés dans la section suivante :

Trois conséquences directes de la partition. Premièrement : ces chiffres ne s'additionnent pas — chacun porte sur son propre dénominateur, et les présenter agrégés reviendrait à compter deux fois le même euro ; nulle part dans cet article, ni dans le texte ni dans un tableau, ils ne sont additionnés. Deuxièmement : un registre qui ne dépasse pas zéro face aux deux bras de contrôle n'est pas annoncé. Si une transformation n'économise pas de façon démontrable, son chiffre n'existe pas : c'est aujourd'hui le cas de la restriction de la sortie et du registre du cache du fournisseur, tous deux mesurés et sans chiffre à publier. Troisièmement : les trois registres ci-dessus dépassent bien zéro face aux deux bras, et le plancher publié pour chacun est celui de la comparaison avec l'intégration non optimisée.

Comment nous mesurons : le plancher de l'intervalle, pas l'estimation flatteuse

La méthode est la partie du système en laquelle nous avons le plus confiance, parce que c'est celle qui laisse le moins de place à l'interprétation :

1. Le même modèle, trois bras — dont deux de contrôle. Chaque requête est exécutée auprès du fournisseur réel et sur le même modèle : telle que l'enverrait une intégration non optimisée (B0), telle que l'enverrait une intégration qu'une équipe diligente aurait déjà optimisée à la main (B1 : catalogue d'outils réduit, contexte élagué, sans fioritures), et telle que l'envoie BV-SALA. Nous ne comparons jamais des modèles différents ni des périodes différentes. Le chiffre face à B0 dit de combien baisse la facture pour qui part de zéro ; seul le chiffre face à B1 mesure le mérite de la couche, car c'est le seul qui déduit ce que le client aurait déjà pu économiser seul. C'est pourquoi le plafond de ce que nous pouvons promettre est le plus bas des deux planchers, jamais le plus haut.
2. Le coût calculé avec le compteur du fournisseur. Aucune base modélisée : les tokens sont comptés par le tokenizer officiel et les prix sont ceux du fournisseur. Le chiffre que nous publions est celui que vous verriez sur votre facture.
3. L'estimateur est stratifié par scénario, avec un poids égal par scénario. L'agrégat n'est pas calculé sur l'ensemble des échantillons mis en commun : cela laisserait la répartition des répétitions — que l'échantillonneur déplace selon le bruit — décider du chiffre principal, et il suffirait de trop répéter un scénario coûteux et sans économie pour le faire chuter sans que la couche ait rien changé. Chaque scénario pèse 1, et le rééchantillonnage qui produit l'intervalle se fait à l'intérieur de chaque scénario. Réserve déclarée : l'intervalle stratifié est conditionnel à l'ensemble fixe de scénarios et sort donc plus étroit — il répond à une question plus étroite, pas avec plus de confiance.
4. Nous publions le plancher de l'intervalle de confiance à 95 %. Avec $n$ requêtes et une économie d'échantillon $\hat S$, nous publions la borne inférieure unilatérale

c'est-à-dire la valeur que l'économie réelle dépasse avec une confiance de 95 % — jamais l'estimation ponctuelle, toujours plus photogénique. Le $\widehat{\operatorname{se}}$ provient du rééchantillonnage stratifié du point précédent.

À cette aune, l'exécution actuelle — openai/gpt-4o-mini, 193 paires mesurées, qualité 100 %, artefact d1c8233 du 12 septembre 2026 — donne ceci :

Ce que nous publions comme chiffre principal, en revanche, est ≥ 20,0 % sur gpt-4o-mini, en dessous des deux. Le plafond de ce qui peut être promis est le plus bas des deux planchers — celui de B1, car promettre au-dessus reviendrait à vendre comme notre mérite ce que le client avait déjà — et le chiffre principal reste délibérément sous ce plafond, pour qu'il reste vrai quand la prochaine exécution bougera d'une décimale. Le signe $\ge$ n'est pas de la rhétorique : c'est la borne inférieure de l'intervalle, et ce qui est promis ne peut jamais dépasser ce qui a été mesuré.

Aucun chiffre de cache de préfixe n'apparaît ici, et cette absence est délibérée. Quand le préfixe du contexte se répète, le fournisseur facture moins cher la partie répétée : cette remise est la sienne — celle d'Anthropic, avec ses propres règles d'exactitude —, pas la nôtre. Notre rôle est de préparer chaque requête pour que la remise puisse être obtenue, et de l'obtenir sur chacune. La publier comme notre propre économie reviendrait à s'attribuer le travail d'un autre ; et de plus, le registre qui la consigne, une fois mesuré, ne dépasse pas zéro. Il y a donc ici une explication et aucun pourcentage.

Pourquoi le problème est plus difficile qu'il n'y paraît

Trois sources de complexité intrinsèque qui façonnent toute la conception :

La contrainte est stochastique. $Q(\pi(x)) \ge \tau$ se décide avant de voir la réponse. Les transformations agressives (réécriture, compression) ne s'activent que là où les éléments accumulés indiquent qu'elles préservent l'intention ; en cas de doute, la requête part intacte. Nous préférons économiser moins que dégrader en silence.

Le coût de la décision compte. Analyser chaque requête consomme aussi. Toute la comptabilité de BV-SALA est nette : l'économie publiée déduit le coût de la couche elle-même. Un optimiseur qui se paie dans les petites lignes n'est pas un optimiseur.

La validité du cache est sémantique, pas syntaxique. Un cache exact et un singleflight ne sont une économie que si la réponse réutilisée reste valable pour la nouvelle requête. Les clés intègrent tout ce qui conditionne la réponse — modèle, version, outils visibles, contexte effectif — et à la moindre différence, nous appelons.

Sa place dans la littérature

Aucune des transformations du catalogue de BV-SALA n'est, à elle seule, une idée nouvelle — et le dire, citations à l'appui, fait partie de l'honnêteté de cet article. La taxonomie complète a été posée par FrugalGPT dès 2023 : adapter le prompt, approximer le modèle, cascader (Chen et al., 2023). Depuis, chaque branche a mûri de son côté. La compression de prompts est la ligne la plus fournie : LLMLingua rapporte une compression jusqu'à 20x avec peu de perte (Jiang et al., 2023), LongLLMLingua constate que, dans les contextes longs, compresser peut même améliorer la réponse — l'effet lost in the middle — (Jiang et al., 2024), et LLMLingua-2 s'attaque au problème opérationnel laissé ouvert par la première génération : le compresseur lui-même était lent et coûteux (Pan et al., 2024). À l'extrême, les gist tokens compressent à l'intérieur du modèle, jusqu'à 26x (Mu et al., 2023) — plus général que toute compression textuelle, mais seulement si l'on contrôle les poids ; sur une API fermée, qui est le régime de celui qui paie la facture, cela ne s'applique pas. Le routage sensible au coût a mûri en parallèle : Hybrid LLM introduit le niveau de qualité souhaité comme paramètre du routeur (Ding et al., 2024), RouteLLM l'entraîne sur des données de préférence (Ong et al., 2024), et AutoMix ajoute l'autovérification comme porte d'escalade — essayer bon marché, vérifier, et seulement ensuite payer le modèle cher (Aggarwal et al., 2024). L'élagage a lui aussi ses preuves publiées : récupérer systématiquement du contexte est sous-optimal par rapport à une récupération à la demande (Asai et al., 2023; Jeong et al., 2024), et réduire les outils visibles ne fait pas que baisser le coût : cela améliore la précision des appels de fonctions (Paramanayakam et al., 2025).

Le cache vit dans deux mondes qui se parlent à peine. Le monde académique pousse le cache sémantique — GPTCache comme infrastructure (Bang, 2023), SCALM comme première évaluation sur des traces réelles d'échanges humains-LLM (Li et al., 2024) —, qui optimise le taux de succès par similarité d'embeddings et accepte tacitement le risque de servir une réponse qui ne correspond pas. Les fournisseurs, eux, livrent du cache de préfixe sous une discipline d'exactitude stricte : Anthropic exige des segments identiques à 100 % et invalide tout le cache si les définitions d'outils changent (Anthropic, 2026) ; OpenAI facture les écritures en cache à 1,25x le prix de base et les lectures à 0,1x (OpenAI, 2026). Ces deux documents officiels établissent ce que la littérature académique intègre rarement : les économies de cache ont un coût d'écriture — seule une comptabilité nette est donc honnête — et la validité du cache dépend du modèle, de la version et des outils. C'est exactement le schéma de clés de BV-SALA, élevé du rang de bonne pratique à celui d'exigence.

Ce que le domaine a résolu, c'est l'efficacité ; ce qu'il laisse ouvert, ce sont les preuves. Presque tous les chiffres publiés sont des ratios dans le meilleur des cas sur un benchmark — « jusqu'à 20x », « jusqu'à 98 % de réduction des coûts » (Chen et al., 2023), « jusqu'à 40 % d'appels en moins » (Ding et al., 2024) —, sans intervalle de confiance, presque jamais sur du trafic de production, et sans déduire le coût de la machinerie d'économie elle-même. Deux travaux récents indiquent la correction : cost-of-pass propose de mesurer en coût monétaire attendu par solution correcte (Erol et al., 2025), et Miller formalise l'appareil statistique pour comparer rigoureusement deux conditions d'évaluation (Miller, 2024). Aucun travail que nous ayons pu vérifier ne réunit les deux. Ce croisement — la taxonomie de FrugalGPT exécutée avec la discipline de clés des fournisseurs, mesurée avec la statistique de Miller dans la monnaie du cost-of-pass — est le créneau qu'occupe BV-SALA. Disons-le clairement : BV-SALA ne revendique pas de nouvelles transformations ; il revendique une autre classe de preuves sur des transformations connues.

Problèmes ouverts

Au moins cinq problèmes ouverts découlent de la littérature vérifiée, et cette couche les touche tous :

1. La comptabilité nette. LLMLingua-2 existe précisément parce que le compresseur de la première génération était coûteux (Pan et al., 2024), et les écritures en cache sont facturées de 1,25x à 2x le prix de base (Anthropic, 2026) — et pourtant aucun travail publié ne rapporte des économies qui déduisent systématiquement le coût du compresseur, du routeur ou du cache. Le domaine publie des économies brutes.
2. La validité du cache sémantique. Servir une réponse en cache par similarité sans borner formellement les faux succès ou l'obsolescence (Bang, 2023; Li et al., 2024) laisse ouvert le juste milieu : plus de couverture que le cache exact, avec une garantie de validité.
3. La certification statistique de la qualité. Les routeurs sont pilotés par un niveau de qualité souhaité (Ding et al., 2024; Ong et al., 2024), mais le respect n'est pas certifié a posteriori par une inférence à deux échantillons (Miller, 2024). Vérifier des contrats $Q \ge \tau$ sur du trafic réel reste ouvert.
4. L'interaction entre transformations. Le préfixe minimal pouvant être mis en cache chez OpenAI implique que compresser un préfixe peut détruire une remise de cache plus importante (OpenAI, 2026) : les transformations ne sont pas indépendantes, et leur composition optimale n'a pas été étudiée.
5. Du benchmark à la production. Seul SCALM part de traces réelles (Li et al., 2024) ; tout le reste est évalué sur des benchmarks statiques, alors que ce sont précisément la répétition et la dérive du trafic réel qui déterminent les économies atteignables.

Note : les chiffres de cette section et de la précédente (« jusqu'à 20x », « jusqu'à 98 % », prix du cache...) proviennent de la littérature citée et de la documentation officielle des fournisseurs à la date de consultation ; ils décrivent ces travaux, et non des résultats de BV-SALA. Les seuls chiffres propres à BV-SALA sont ceux des trois registres et ceux du tableau de résultats, tous issus de la même exécution : gpt-4o-mini, 193 paires, artefact d1c8233 du 12 septembre 2026.

Où en est-il aujourd'hui

BV-SALA existe comme produit indépendant sur savings.bivelio.com : un SDK sous licence sur npm, une installation en cinq lignes et un mois de calibrage pour commencer — vous ne payez que le siège, nous mesurons tout votre trafic sans prendre de commission, et à la clôture vous recevez le relevé exact de ce qu'il vous aurait coûté. Au sein de BiVelio, c'est la couche Optimize : le même moteur qui décide, requête par requête, quelle part de votre facture d'IA n'avait jamais besoin d'être payée.

Références