BV-SALA Savings Layer: Verifiable Measurement of Cost Savings in Large Language Model Applications

Résumé

Le résumé des conclusions en espagnol qui clôt le paper lui-même (cité dans sa langue d'origine) :

Este trabajo presenta una evaluación delimitada de BV-SALA basada en usage reportado por el proveedor y tarifas de lista versionadas, con trazabilidad documental y sin afirmar trazabilidad metrológica ni conciliación de facturas. Las ejecuciones live del SDK usaron bootstrap percentile por clúster con 10.000 remuestreos: 31,5% [25,7; 36,7] en OpenAI (100 familias, 200 solicitudes) y 75,1% [69,3; 79,6] en Anthropic (31 familias, 62 solicitudes). En Anthropic, unos 41 puntos porcentuales corresponden al efecto de caché de prefijo habilitado mediante cache_control en el brazo instrumentado; el baseline tenía cero cache-read y el brazo B, 72.447 tokens. El 2,49% [1,50; 3,57] del gateway procede de una reproducción contrafactual separada de 19.779 solicitudes, 51 sesiones y 13 días, con baseline parcialmente reconstruida, no de una doble ejecución live. Se distinguen importes measured, reference-valued y estimated; la telemetría incluye recuentos, costes y metadatos permitidos. La precisión Sonnet fue 56/56 en cada brazo y la latencia mediana de llamadas al proveedor fue 1.969 ms (A) y 2.225 ms (B), sin demostrar no inferioridad. El umbral económico usa F como fee mensual total y r = 0,315/0,30 como razón en un único punto, no como pendiente validada. Las muestras pequeñas, la deriva temporal, la frescura de la caché exacta, la organización única, la condición de desarrollador de los autores y los logs gateway privados limitan las conclusiones. Quedan para trabajo futuro el diseño factorial, el barrido de ρ, experimentos jerárquicos de varios días, pruebas de no inferioridad, replicación externa y conciliación con facturas.

Abstract (original, en anglais)

Cost claims for large language model (LLM) optimizations require explicit workloads, uncertainty, and a documented cost basis. This paper presents BV-SALA Savings Layer, an in-process SDK and local gateway that combine provider-reported usage with versioned list prices and separate four savings ledgers. Live SDK double-runs used a percentile cluster bootstrap with 10,000 resamples. On GSM8K-derived traffic, gpt-4o-mini showed a 31.5% cost reduction (95% CI: 25.7–36.7; 100 families, 200 requests per arm) and claude-sonnet-5 showed 75.1% (95% CI: 69.3–79.6; 31 families, 62 requests per arm). The Anthropic arm included 41 percentage points from a prefix-cache effect enabled by cache_control in the instrumented condition, not a pre-existing provider discount. A separate counterfactual replay of 19,779 gateway requests estimated 2.49% (95% CI: 1.50–3.57); it was not a live double-run or invoice reconciliation. We distinguish measured, reference-valued, and estimated amounts, state quality and latency observations without claiming non-inferiority, and present only provisional economic extrapolations.

Mots-clés : LLM ; coût d'inférence ; provider-reported usage ; cache de préfixe ; cluster bootstrap ; optimisation de prompts.

Résultats

Le tableau 2 et la figure 2 séparent deux doubles exécutions live du SDK d'un rejeu contrefactuel de la passerelle. Les montants s'appuient sur l'usage déclaré par le fournisseur et sur des tarifs publics versionnés ; aucun n'est un résultat rapproché des factures.

Les 2,49 % de la passerelle ne proviennent ni d'un A/B facturé ni d'une double exécution live : c'est une estimation contrefactuelle avec une ligne de base partiellement reconstruite et un rééchantillonnage par session. Dans le flux Sonnet, la précision observée a été de 56/56 dans chaque bras et les latences médianes de 1 969 ms (A) et 2 225 ms (B) ; ces observations ne démontrent ni équivalence ni non-infériorité. Gemini n'apporte que des vérifications opérationnelles de non-régression, sans intervalle d'économies publiable.

Méthode et base de coût

Dans les expériences live du SDK, la condition A sans couche et la condition B instrumentée utilisent le même modèle et le même contenu construit. Le coût est calculé à partir de l'usage déclaré par le fournisseur et des tarifs publics versionnés en vigueur pour l'analyse. Cela apporte une traçabilité documentaire aux enregistrements d'usage et de prix, pas une traçabilité métrologique stricte ni la preuve du montant d'une facture. Les prix négociés, les crédits, les taxes, les arrondis et les ajustements ultérieurs restent hors du champ des preuves.

Les intervalles live utilisent un bootstrap percentile non paramétrique par grappe avec 10 000 rééchantillonnages. La famille, et non la requête individuelle, est l'unité de rééchantillonnage : les requêtes d'une même famille restent ensemble et l'intervalle à 95 % retient les percentiles empiriques 2,5 et 97,5. La passerelle, elle, rééchantillonne des sessions complètes. Ces intervalles résument la variabilité du plan observé, mais pas toute la dérive temporelle, les changements de modèle ou de prix, ni l'erreur de reconstruction contrefactuelle.

Quatre registres et trois bases de preuve

Le rapport d'économies de chaque requête (SavingsReport) tient quatre registres séparés pour limiter le double comptage et rendre explicite la dépendance de chaque mécanisme au trafic et au fournisseur. Les montants ne doivent pas être additionnés sans définir l'estimande.

Un montant est measured lorsqu'il repose directement sur l'usage du fournisseur pour cette exécution et sur une version documentée du prix ; reference-valued lorsqu'un contrefactuel utilise une requête antérieure équivalente ou identique sous des conditions explicites ; et estimated lorsqu'il est reconstruit à partir de journaux, de calculs aux tarifs publics ou d'autres hypothèses sans cette référence directe. Un flux sans usage final est unmeasured. Ces étiquettes décrivent la base de preuve ; elles ne transforment pas des valeurs de référence ou des estimations en économies vérifiées sur facture.

Limites et travaux futurs

• Les échantillons sont petits et utilisent du trafic construit : 100 familles chez OpenAI et 31 chez Anthropic. La passerelle couvre 51 sessions, 13 jours et une seule organisation ; ni la stabilité temporelle ni la généralisation à d'autres modèles, fournisseurs ou charges de production ne sont démontrées.
• L'attribution chez Anthropic exige un plan factoriel déduplication × cache_control. Il faut aussi un balayage du taux de répétition, des expériences hiérarchiques sur plusieurs jours et des tests de non-infériorité préenregistrés et suffisamment puissants sur la qualité, la fraîcheur et la latence.
• Le cache exact peut réduire la fraîcheur et la diversité. Il n'est pas possible de généraliser à un trafic créatif, sensible au temps, multiclient ou sémantiquement similaire sans nouvelles expériences. Le paquet publié n'inclut pas de compresseur général et TOON n'est pas évalué comme une optimisation distribuée.
• Le magasin sémantique de référence est en mémoire et effectue une recherche linéaire ; la coordination transactionnelle entre répliques, la cohérence et la latence à l'échelle de la production exigent un travail supplémentaire. Le routage actuel n'a pas de preuve de correction sémantique.
• Les calculs aux tarifs publics ne rapprochent pas les factures. Les journaux privés de la passerelle, l'absence de réplication indépendante et la qualité de développeur de l'auteur limitent la vérification. Il faut une réplication externe, un rapprochement avec les prix négociés et les crédits, et des artefacts de rééchantillonnage immuables.

Dans BiVelio Factory

Ce paper est le produit 01 du quai de sortie de BiVelio Factory, où figurent les applications, les publications et les entreprises qui sortent de la fabrique. L'algorithme dont il mesure les économies est expliqué dans BV-SALA · BiVelio Savings Layer.

Télécharger et citer

Télécharger le paper en PDF (9 pages, 444 Ko, en anglais). Le banc public avec les preuves se trouve sur savings.bivelio.com.

Comment le citer :

Vidal, Adrián (2026). BV-SALA Savings Layer: Verifiable Measurement of Cost Savings in Large Language Model Applications. BiVelio Inc - research.bivelio.com, August 2026. https://bivelio.com/es/research/papers/bv-sala-savings-layer

Pour lire l'algorithme avec plus de contexte : BiVelio Savings Layer et l'article BV-SALA : au cœur de la couche de coût des LLM.