BV-SALA: la capa de cost de LLM, per dins

La factura d'un sistema amb LLM no creix amb el valor que produeix: creix amb els tokens que mou. I la major part d'aquests tokens no calia moure'ls. Context repetit a cada torn, eines declarades que mai no es fan servir, preguntes la resposta de les quals ja es va calcular fa un minut. BV-SALA és la capa que es col·loca davant del teu proveïdor i, a cada petició, respon una sola pregunta: quina és l'execució més barata que encara compleix el teu contracte de qualitat?

Aquest article explica com pensem aquesta pregunta: la formalització, els tres llibres comptables on cau cada estalvi, i la metodologia de mesura — que és, deliberadament, la part més estricta del sistema.

La decisió, formalitzada

Per a una petició $x$ (prompt, context, eines), el proveïdor cobra una funció essencialment lineal en tokens:

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

on $T$ compta tokens amb el tokenitzador del mateix proveïdor — no amb una aproximació nostra — i $c_{\text{in}}, c_{\text{out}}$ són els seus preus vigents. BV-SALA disposa d'un catàleg $\Pi$ de transformacions de la petició: eliminar redundància, podar eines, comprimir la codificació, resoldre sense cridar. Triar bé és un problema d'optimització amb restricció:

$$\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ó $Q \ge \tau$ és el contracte de qualitat: la transformació més barata no val res si degrada la resposta. I aquí hi ha la dificultat intrínseca del problema: $Q$ no és observable abans d'executar. Per això cada transformació del catàleg porta la seva pròpia guarda — s'aplica només si surt a compte, amb el cost de decidir comptabilitzat dins de l'estalvi, no amagat fora.

Els tres llibres comptables

Cada petició optimitzada s'atribueix a exactament un llibre comptable, segons el mecanisme dominant. Aquesta partició no és cosmètica: és el que permet que les xifres signifiquin alguna cosa.

01 — Evitar la crida per complet. Resolutors deterministes per al que no necessita un model, memòria cau exacta per al que ja s'ha respost i singleflight per col·lapsar peticions idèntiques concurrents en una sola execució. Estalvi mesurat del llibre: 17,9 %.

02 — Treure el que no calia enviar. Eines podades del catàleg declarat, recuperació selectiva en lloc de context complet, i eliminació del context redundant que viatja torn rere torn. Estalvi mesurat: 38,6 %.

03 — Comprimir el que queda. Codificació més lleugera del que sí que ha de viatjar — i només quan la compressió mateixa surt a compte. Estalvi mesurat: 45,1 %.

L'estalvi d'un llibre $\ell$ sobre el conjunt $R_\ell$ de peticions atribuïdes a ell es defineix contra el braç ingenu:

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

Dues conseqüències directes de la partició. Primera: aquestes xifres no se sumen — cadascuna parla sobre el seu propi denominador, i presentar-les agregades seria comptar el mateix euro dues vegades. Segona: un pas el llibre del qual no supera el zero no apareix publicat. Si una transformació no estalvia de manera demostrable, la seva xifra no existeix.

Com mesurem: el terra de l'interval, no l'estimació afalagadora

La metodologia és la part del sistema de la qual més ens refiem, perquè és la que menys marge d'interpretació deixa:

1. Mateix model, dos braços. Cada petició s'avalua com l'enviaria la teva aplicació (braç ingenu) i com l'envia BV-SALA. Mai no comparem models diferents ni èpoques diferents.
2. Cost cotitzat amb el comptador del proveïdor. Sense línia base modelada: els tokens els compta el tokenitzador oficial i els preus són els del proveïdor. El número que publiquem és el que veuries a la teva factura.
3. Es publica el terra de l'interval de confiança del 95 %. Amb $n$ peticions i estalvi mostral $\hat S$, publiquem la cota inferior unilateral

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

és a dir, el valor que l'estalvi real supera amb un 95 % de confiança — mai l'estimació puntual, que sempre és més fotogènica.

Amb aquesta vara de mesurar, els resultats publicats avui són:

El signe $\ge$ del primer no és retòrica: és la cota inferior de l'interval. I la segona xifra il·lustra el llibre 01 en el seu millor terreny — quan el prefix del context es repeteix, la memòria cau del proveïdor converteix tokens cars en tokens barats, i el comptador del mateix proveïdor ho certifica.

Per què el problema és més dur del que sembla

Tres fonts de complexitat intrínseca que condicionen tot el disseny:

La restricció és estocàstica. $Q(\pi(x)) \ge \tau$ es decideix abans de veure la resposta. Les transformacions agressives (reescriptura, compressió) només s'activen on l'evidència acumulada indica que preserven la intenció; en el dubte, la petició viatja intacta. Preferim estalviar menys que degradar en silenci.

El cost de decidir compta. Analitzar cada petició també consumeix. Tota la comptabilitat de BV-SALA és neta: l'estalvi publicat descompta el cost de la mateixa capa. Un optimitzador que es paga a si mateix amb la lletra petita no és un optimitzador.

La correcció de la memòria cau és semàntica, no sintàctica. Una memòria cau exacta i un singleflight només són estalvi si la resposta reutilitzada continua sent vàlida per a la petició nova. Les claus incorporen tot el que condiciona la resposta — model, versió, eines visibles, context efectiu — i davant de qualsevol diferència, es crida.

On és això avui

BV-SALA està productivitzat com a producte independent a savings.bivelio.com: SDK amb llicència a npm, instal·lació en cinc línies i un mode només-mesura per començar — primer et diem què estalviaries amb el teu trànsit real, sense canviar res del teu codi. Dins de BiVelio és la capa Optimize: el mateix motor que decideix, petició a petició, quant de la teva factura d'IA no calia pagar.