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:

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:

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.

Todas las cifras de esta sección salen de una sola tirada, la misma que sirve hoy el producto: openai/gpt-4o-mini, 193 parejas medidas, calidad 100 %, artefacto d1c8233 del 12 de septiembre de 2026. Cada una es el suelo del intervalo de confianza al 95 % de su libro y sobre ese modelo; un porcentaje sin su modelo al lado no significa nada.

01 — Evitar la llamada por completo. Resolutores deterministas para lo que no necesita un modelo y singleflight para colapsar peticiones idénticas concurrentes en una sola ejecución. El catálogo incluye además una caché exacta, pero el ahorro medido de este libro en la tirada publicada sale de los resolutores y del singleflight: lo que no se midió no se anuncia. Suelo del libro en gpt-4o-mini: 22,0 %.

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. Suelo del libro en gpt-4o-mini: 43,2 %.

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. Suelo del libro en gpt-4o-mini: 20,1 %.

El ahorro de un libro $\ell$ sobre el conjunto $R_\ell$ de peticiones atribuidas a él se define contra un brazo de control — y se mide contra los dos que se declaran en la sección siguiente:

Tres 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; en ninguna frase ni tabla de este artículo aparecen sumadas. Segunda: un libro que no despeja el cero contra los dos brazos de control no se anuncia. Si una transformación no ahorra de forma demostrable, su cifra no existe: hoy es el caso de la restricción de salida y del libro de caché del proveedor, medidos los dos y sin cifra que publicar. Tercera: los tres libros de arriba sí despejan el cero contra los dos brazos, y el suelo que se publica de cada uno es el de la comparación contra la integración sin optimizar.

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, tres brazos — dos de ellos, controles. Cada petición se ejecuta contra el proveedor real y con el mismo modelo: tal cual la enviaría una integración sin optimizar (B0), tal cual la enviaría una integración que un equipo diligente ya habría optimizado a mano (B1: catálogo de herramientas recortado, contexto podado, sin florituras) y tal cual la envía BV-SALA. Nunca comparamos modelos distintos ni épocas distintas. La cifra contra B0 dice cuánto baja la factura de quien parte de cero; solo la cifra contra B1 mide mérito de la capa, porque es la única que descuenta lo que el cliente ya podía ahorrarse él solo. Por eso el techo de lo que podemos prometer es el menor de los dos suelos, nunca el mayor.
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. El estimador es estratificado por escenario, con peso igual por escenario. El agregado no se calcula sobre todas las muestras juntas: eso deja que el reparto de repeticiones —que el muestreador mueve según el ruido— decida el titular, y basta con repetir de más un escenario caro y de ahorro nulo para hundirlo sin que la capa haya cambiado nada. Cada escenario pesa 1, y el remuestreo que produce el intervalo se hace dentro de cada escenario. Caveat declarado: el intervalo estratificado es condicional al conjunto fijo de escenarios y por eso sale más estrecho — responde a una pregunta más estrecha, no con más confianza.
4. Se publica el suelo del intervalo de confianza del 95 %. Con $n$ peticiones y ahorro muestral $\hat S$, publicamos la cota inferior unilateral

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. La $\widehat{\operatorname{se}}$ sale del remuestreo estratificado del punto anterior.

Con esa vara de medir, la tirada vigente —openai/gpt-4o-mini, 193 parejas medidas, calidad 100 %, artefacto d1c8233 del 12 de septiembre de 2026— da esto:

El titular que publicamos, en cambio, es ≥ 20,0 % en gpt-4o-mini, por debajo de los dos. El techo de lo prometible es el menor de los dos suelos —el de B1, porque prometer por encima sería vender como mérito nuestro lo que el cliente ya tenía— y el titular se queda deliberadamente por debajo de ese techo, para que siga siendo cierto cuando la próxima tirada mueva un decimal. El signo $\ge$ no es retórica: es la cota inferior del intervalo, y lo prometido nunca puede pasarse de lo medido.

Aquí no aparece ninguna cifra de caché de prefijo, y la ausencia es deliberada. Cuando el prefijo del contexto se repite, el proveedor cobra más barato lo repetido: ese descuento lo pone él —Anthropic, con sus propias reglas de exactitud—, no nosotros. Nuestra parte es preparar cada petición para que el descuento se pueda pedir, y pedirlo en todas. Publicarlo como ahorro propio sería apuntarse mérito ajeno; y además el libro contable que lo recoge, medido, no despeja el cero. Por eso aquí hay explicación y no porcentaje.

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.

Posición en la literatura

Ninguna transformación del catálogo de BV-SALA es, por separado, una idea nueva — y decirlo con las citas delante es parte de la honestidad de este artículo. La taxonomía completa la enumeró FrugalGPT ya en 2023: adaptar el prompt, aproximar el modelo, encadenar en cascada (Chen et al., 2023). Desde entonces, cada rama ha madurado por su cuenta. La compresión de prompts es la línea más profunda: LLMLingua reporta hasta 20× de compresión con poca pérdida (Jiang et al., 2023), LongLLMLingua descubre que en contexto largo comprimir puede incluso mejorar la respuesta — el efecto lost in the middle — (Jiang et al., 2024), y LLMLingua-2 ataca el problema operativo que la primera generación dejó abierto: que el propio compresor era caro y lento (Pan et al., 2024). En el extremo, los gist tokens comprimen dentro del modelo hasta 26× (Mu et al., 2023) — más general que cualquier compresión textual, pero solo si controlas los pesos; sobre una API cerrada, que es el régimen de quien paga factura, no aplica. El enrutado por coste maduró en paralelo: Hybrid LLM introduce el nivel de calidad deseado como parámetro del router (Ding et al., 2024), RouteLLM lo entrena con datos de preferencias (Ong et al., 2024) y AutoMix añade la auto-verificación como puerta de escalada — intentar barato, verificar, y solo entonces pagar caro (Aggarwal et al., 2024). Y la poda tiene su propia evidencia publicada: recuperar contexto siempre es subóptimo frente a hacerlo bajo demanda (Asai et al., 2023; Jeong et al., 2024), y reducir las herramientas visibles no solo abarata sino que mejora el acierto del function calling (Paramanayakam et al., 2025).

La caché vive en dos mundos que apenas se hablan. La academia empuja la caché semántica — GPTCache como infraestructura (Bang, 2023), SCALM como primera evaluación sobre trazas reales humano-LLM (Li et al., 2024) — que optimiza el hit ratio por similitud de embeddings y asume, tácitamente, el riesgo de servir una respuesta que no corresponde. Los proveedores, en cambio, despliegan caché de prefijo con disciplina de exactitud estricta: Anthropic exige segmentos 100 % idénticos e invalida la caché entera si cambian las definiciones de herramientas (Anthropic, 2026); OpenAI cobra la escritura a 1,25× el precio base y la lectura a 0,1× (OpenAI, 2026). Esos dos documentos oficiales establecen algo que la literatura académica rara vez incorpora: el ahorro de caché tiene coste de escritura — luego solo una contabilidad neta es honesta — y su validez depende de modelo, versión y herramientas. Es exactamente el esquema de claves de BV-SALA, elevado de buena práctica a requisito.

Lo que el campo tiene resuelto es la eficacia; lo que tiene abierto es la evidencia. Casi toda cifra publicada es un ratio de mejor caso sobre benchmark — «hasta 20×», «hasta 98 % menos coste» (Chen et al., 2023), «hasta 40 % menos llamadas» (Ding et al., 2024) — sin intervalo de confianza, casi nunca sobre tráfico de producción, y sin descontar el coste de la propia maquinaria de ahorro. Dos trabajos recientes apuntan la corrección: cost-of-pass propone medir en coste monetario esperado por solución correcta (Erol et al., 2025), y Miller formaliza el aparato estadístico para comparar dos condiciones de evaluación con rigor (Miller, 2024). Ningún trabajo que hayamos podido verificar une ambas cosas. Ese cruce — la taxonomía de FrugalGPT ejecutada con la disciplina de claves de los proveedores, medida con la estadística de Miller en la moneda de cost-of-pass — es el hueco que BV-SALA ocupa. Conviene decirlo tal cual: BV-SALA no reclama transformaciones nuevas; reclama evidencia de otra clase sobre transformaciones conocidas.

Problemas abiertos

De la literatura verificada se siguen, al menos, cinco problemas abiertos que esta capa toca de lleno:

1. Contabilidad neta. LLMLingua-2 existe precisamente porque el compresor de la primera generación era caro (Pan et al., 2024), y la escritura de caché se factura a 1,25×–2× el precio base (Anthropic, 2026) — pero ningún trabajo publicado reporta ahorros descontando sistemáticamente el coste del compresor, el router o la caché. El campo publica ahorros brutos.
2. Validez de la caché semántica. Servir una respuesta cacheada por similitud sin acotar formalmente los falsos aciertos ni la obsolescencia (Bang, 2023; Li et al., 2024) deja abierto el punto intermedio: más cobertura que la caché exacta, con garantía de validez.
3. Certificación estadística de la calidad. Los routers gobiernan por un nivel de calidad deseado (Ding et al., 2024; Ong et al., 2024), pero el cumplimiento no se certifica a posteriori con inferencia de dos muestras (Miller, 2024). Verificar contratos $Q \ge \tau$ sobre tráfico real sigue abierto.
4. Interacción entre transformaciones. El mínimo cacheable de OpenAI implica que comprimir un prefijo puede destruir un descuento de caché mayor (OpenAI, 2026): las transformaciones no son independientes, y su composición óptima no está estudiada.
5. Del benchmark a producción. Solo SCALM parte de trazas reales (Li et al., 2024); todo lo demás se evalúa en benchmarks estáticos, cuando la repetición y la deriva del tráfico real son justo lo que determina el ahorro alcanzable.

Nota: las cifras de esta sección y la anterior («hasta 20×», «hasta 98 %», precios de caché…) provienen de la literatura citada y de la documentación oficial de los proveedores a fecha de consulta; describen esos trabajos, no resultados de BV-SALA. Las cifras de BV-SALA son únicamente las de los tres libros contables y las de la tabla de resultados, todas de la misma tirada: gpt-4o-mini, 193 parejas, artefacto d1c8233 del 12 de septiembre de 2026.

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 mes de calibración para empezar — pagas solo el asiento, medimos todo tu tráfico y no cobramos comisión, y al cierre ves el extracto exacto de lo que habría costado. 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.

Referencias