BV-SALA: la capa de coste de LLM, por dentro

La factura de un sistema con LLM no crece con el valor que produce: crece con los tokens que mueve. Y la mayor parte de esos tokens no hacía falta moverlos. Contexto repetido en cada turno, herramientas declaradas que nunca se usan, preguntas cuya respuesta ya se calculó hace un minuto. BV-SALA es la capa que se coloca delante de tu proveedor y, en cada petición, responde a una sola pregunta: ¿cuál es la ejecución más barata que todavía cumple tu contrato de calidad?

Este artículo cuenta cómo pensamos esa pregunta: la formalización, los tres libros contables en los que cae cada ahorro, y la metodología de medición — que es, deliberadamente, la parte más estricta del sistema.

La decisión, formalizada

Para una petición $x$ (prompt, contexto, herramientas), el proveedor cobra una función esencialmente lineal en tokens:

$$C(x) \;=\; c_{\text{in}} \cdot T_{\text{in}}(x) \;+\; c_{\text{out}} \cdot T_{\text{out}}(x)$$

donde $T$ cuenta tokens con el tokenizador del propio proveedor — no con una aproximación nuestra — y $c_{\text{in}}, c_{\text{out}}$ son sus precios vigentes. BV-SALA dispone de un catálogo $\Pi$ de transformaciones de la petición: eliminar redundancia, podar herramientas, comprimir la codificación, resolver sin llamar. Elegir bien es un problema de optimización con restricción:

$$\pi^{*} \;=\; \operatorname*{arg\,min}_{\pi \,\in\, \Pi} \; \mathbb{E}\big[\, C(\pi(x)) \,\big] \qquad \text{s.a.} \qquad Q(\pi(x)) \,\ge\, \tau$$

La restricción $Q \ge \tau$ es el contrato de calidad: la transformación más barata no vale nada si degrada la respuesta. Y aquí está la dificultad intrínseca del problema: $Q$ no es observable antes de ejecutar. Por eso cada transformación del catálogo lleva su propia guarda — se aplica solo si sale a cuenta, con el coste de decidir contabilizado dentro del ahorro, no escondido fuera.

Los tres libros contables

Cada petición optimizada se atribuye a exactamente un libro contable, según el mecanismo dominante. Esta partición no es cosmética: es lo que permite que las cifras signifiquen algo.

01 — Evitar la llamada por completo. Resolutores deterministas para lo que no necesita un modelo, caché exacta para lo ya respondido y singleflight para colapsar peticiones idénticas concurrentes en una sola ejecución. Ahorro medido del libro: 17,9 %.

02 — Quitar lo que no hacía falta enviar. Herramientas podadas del catálogo declarado, recuperación selectiva en lugar de contexto completo, y eliminación del contexto redundante que viaja turno tras turno. Ahorro medido: 38,6 %.

03 — Comprimir lo que queda. Codificación más ligera de lo que sí tiene que viajar — y solo cuando la compresión misma sale a cuenta. Ahorro medido: 45,1 %.

El ahorro de un libro $\ell$ sobre el conjunto $R_\ell$ de peticiones atribuidas a él se define contra el brazo ingenuo:

$$S_\ell \;=\; 1 \;-\; \frac{\sum_{x \in R_\ell} C\big(\pi^{*}(x)\big)}{\sum_{x \in R_\ell} C(x)}$$

Dos consecuencias directas de la partición. Primera: estas cifras no se suman — cada una habla de su propio denominador, y presentarlas agregadas sería contar el mismo euro dos veces. Segunda: un paso cuyo libro no despeja el cero no aparece publicado. Si una transformación no ahorra de forma demostrable, su cifra no existe.

Cómo medimos: el suelo del intervalo, no la estimación halagadora

La metodología es la parte del sistema de la que más nos fiamos, porque es la que menos margen de interpretación deja:

1. Mismo modelo, dos brazos. Cada petición se evalúa como la enviaría tu aplicación (brazo ingenuo) y como la envía BV-SALA. Nunca comparamos modelos distintos ni épocas distintas.
2. Coste cotizado con el contador del proveedor. Sin línea base modelada: los tokens los cuenta el tokenizador oficial y los precios son los del proveedor. El número que publicamos es el que verías en tu factura.
3. Se publica el suelo del intervalo de confianza del 95 %. Con $n$ peticiones y ahorro muestral $\hat S$, publicamos la cota inferior unilateral

$$S_{\text{pub}} \;=\; \hat S \;-\; z_{0.95}\,\widehat{\operatorname{se}}\big(\hat S\big)$$

es decir, el valor que el ahorro real supera con un 95 % de confianza — nunca la estimación puntual, que siempre es más fotogénica.

Con esa vara de medir, los resultados publicados hoy son:

El signo $\ge$ del primero no es retórica: es la cota inferior del intervalo. Y la segunda cifra ilustra el libro 01 en su mejor terreno — cuando el prefijo del contexto se repite, la caché del proveedor convierte tokens caros en tokens baratos, y el contador del propio proveedor lo certifica.

Por qué el problema es más duro de lo que parece

Tres fuentes de complejidad intrínseca que condicionan todo el diseño:

La restricción es estocástica. $Q(\pi(x)) \ge \tau$ se decide antes de ver la respuesta. Las transformaciones agresivas (reescritura, compresión) solo se activan donde la evidencia acumulada indica que preservan la intención; en la duda, la petición viaja intacta. Preferimos ahorrar menos que degradar en silencio.

El coste de decidir cuenta. Analizar cada petición también consume. Toda la contabilidad de BV-SALA es neta: el ahorro publicado descuenta el coste de la propia capa. Un optimizador que se paga a sí mismo con la letra pequeña no es un optimizador.

La correctitud de la caché es semántica, no sintáctica. Una caché exacta y un singleflight solo son ahorro si la respuesta reutilizada sigue siendo válida para la petición nueva. Las claves incorporan todo lo que condiciona la respuesta — modelo, versión, herramientas visibles, contexto efectivo — y ante cualquier diferencia, se llama.

Dónde está esto hoy

BV-SALA está productivizado como producto independiente en savings.bivelio.com: SDK con licencia en npm, instalación en cinco líneas y un modo solo-medición para empezar — primero te decimos qué ahorrarías con tu tráfico real, sin cambiar nada de tu código. Dentro de BiVelio es la capa Optimize: el mismo motor que decide, petición a petición, cuánto de tu factura de IA no hacía falta pagar.