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

Resumen

El resumen de conclusiones en español que cierra el propio paper:

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 inglés)

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.

Palabras clave: LLM; coste de inferencia; provider-reported usage; caché de prefijos; cluster bootstrap; optimización de prompts.

Resultados

La tabla 2 y la figura 2 separan dos dobles ejecuciones live del SDK de un replay contrafactual del gateway. Los importes usan usage reportado por el proveedor y tarifas de lista versionadas; ninguno es un resultado conciliado con facturas.

El 2,49 % del gateway no procede de un A/B facturado ni de una doble ejecución live: es una estimación contrafactual con baseline parcialmente reconstruida y remuestreo por sesión. En el flujo Sonnet, la precisión observada fue 56/56 en cada brazo y las medianas de latencia fueron 1.969 ms (A) y 2.225 ms (B); estas observaciones no demuestran equivalencia ni no inferioridad. Gemini solo aporta comprobaciones operativas de no ruptura, sin intervalo de ahorro publicable.

Método y base de coste

En los experimentos live del SDK, la condición A sin capa y la B instrumentada usan el mismo modelo y contenido construido. El coste se calcula a partir del usage reportado por el proveedor y las tarifas de lista versionadas vigentes para el análisis. Esto aporta trazabilidad documental a registros de usage y precios, no trazabilidad metrológica estricta ni prueba del importe de una factura. Precios negociados, créditos, impuestos, redondeos y ajustes posteriores quedan fuera de la evidencia.

Los intervalos live usan un bootstrap percentile no paramétrico por clúster con 10.000 remuestreos. La familia, no la solicitud individual, es la unidad de remuestreo: las solicitudes de una familia permanecen juntas y el intervalo del 95 % toma los percentiles empíricos 2,5 y 97,5. El gateway, en cambio, remuestrea sesiones completas. Estos intervalos resumen la variabilidad del diseño observado, pero no toda la deriva temporal, los cambios de modelo o precio ni el error de reconstrucción contrafactual.

Cuatro ledgers y tres bases de evidencia

El informe de ahorro de cada petición (SavingsReport) mantiene cuatro ledgers separados para reducir el doble cómputo y hacer explícita la dependencia de cada mecanismo respecto del tráfico y del proveedor. Los importes no deben sumarse sin definir el estimando.

Un importe es measured cuando lo respaldan directamente el usage del proveedor de esa ejecución y una versión documentada del precio; reference-valued cuando un contrafactual usa una petición anterior equivalente o idéntica bajo condiciones explícitas; y estimated cuando se reconstruye desde logs, cálculos a tarifas de lista u otros supuestos sin esa referencia directa. Un stream sin usage final es unmeasured. Estas etiquetas describen la base de evidencia, no convierten valores de referencia o estimaciones en ahorros verificados en factura.

Limitaciones y trabajo futuro

• Las muestras son pequeñas y usan tráfico construido: 100 familias OpenAI y 31 Anthropic. El gateway cubre 51 sesiones, 13 días y una sola organización; no se demuestra estabilidad temporal ni generalización a otros modelos, proveedores o cargas de producción.
• La atribución en Anthropic requiere un diseño factorial deduplicación × cache_control. También hacen falta un barrido de la tasa de repetición, experimentos jerárquicos de varios días y pruebas prerregistradas y con potencia suficiente de no inferioridad en calidad, frescura y latencia.
• La caché exacta puede reducir frescura y diversidad. No se puede generalizar a tráfico creativo, sensible al tiempo, multi-cliente o semánticamente similar sin nuevos experimentos. El paquete publicado no incluye un compresor general y TOON no se evalúa como optimización distribuida.
• El almacén semántico de referencia está en memoria y hace búsqueda lineal; la coordinación transaccional entre réplicas, la consistencia y la latencia a escala de producción requieren trabajo adicional. El routing actual carece de evidencia de corrección semántica.
• Los cálculos a tarifas de lista no concilian facturas. Los logs privados del gateway, la ausencia de réplica independiente y la condición de desarrollador del autor limitan la verificación. Se necesitan réplica externa, conciliación con precios negociados y créditos, y artefactos inmutables de remuestreo.

En BiVelio Factory

Este paper es el producto 01 del muelle de salida de BiVelio Factory, donde aparecen las aplicaciones, los papers y las empresas que salen de la fábrica. El algoritmo cuyo ahorro mide se explica en BV-SALA · BiVelio Savings Layer.

Descargar y citar

Descargar el paper en PDF (9 páginas, 444 KB, en inglés). El banco público con las pruebas está en savings.bivelio.com.

Cómo citarlo:

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

Para leer el algoritmo con más contexto: BiVelio Savings Layer y el artículo BV-SALA: la capa de coste de LLM, por dentro.