BV-SALA: la capa de cost de LLM, per dins
BV-SALA se situa entre la teva aplicació i l'API del model i, a cada petició, tria l'execució més barata que encara compleix el teu contracte de qualitat. Aquest article formalitza aquesta decisió com un problema d'optimització amb restricció, recorre els tres llibres comptables de l'estalvi —evitar la crida, treure el que no calia, comprimir el que queda— i explica la part menys glamurosa i més important: com mesurem. Mateix model en tres braços —dos d'ells controls: una integració sense optimitzar i una altra ja optimitzada a mà—, cost cotitzat amb el tokenitzador del mateix proveïdor, estimador estratificat per escenari i publicació del terra de l'interval de confiança al 95 %, mai de l'estimació afalagadora.
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ó (prompt, context, eines), el proveïdor cobra una funció essencialment lineal en tokens:
on compta tokens amb el tokenitzador del mateix proveïdor — no amb una aproximació nostra — i són els seus preus vigents. BV-SALA disposa d'un catàleg 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ó:
La restricció é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: 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.
Totes les xifres d'aquesta secció surten d'una sola tirada, la mateixa que
serveix avui el producte: openai/gpt-4o-mini, 193 parelles mesurades,
qualitat 100 %, artefacte d1c8233 del 12 de setembre de 2026. Cadascuna és
el terra de l'interval de confiança al 95 % del seu llibre i sobre
aquell model; un percentatge sense el seu model al costat no significa res.
01 — Evitar la crida per complet. Resolutors deterministes per al que no
necessita un model i singleflight per col·lapsar peticions idèntiques
concurrents en una sola execució. El catàleg inclou a més una memòria cau
exacta, però l'estalvi mesurat d'aquest llibre en la tirada publicada surt
dels resolutors i del singleflight: el que no s'ha mesurat no s'anuncia.
Terra del llibre en gpt-4o-mini: 22,0 %.
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. Terra del llibre en gpt-4o-mini:
43,2 %.
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. Terra del llibre
en gpt-4o-mini: 20,1 %.
L'estalvi d'un llibre sobre el conjunt de peticions atribuïdes a ell es defineix contra un braç de control — i es mesura contra els dos que es declaren a la secció següent:
Tres 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; en cap frase ni taula d'aquest article no apareixen sumades. Segona: un llibre que no supera el zero contra els dos braços de control no s'anuncia. Si una transformació no estalvia de manera demostrable, la seva xifra no existeix: avui és el cas de la restricció de sortida i del llibre de memòria cau del proveïdor, tots dos mesurats i sense cap xifra a publicar. Tercera: els tres llibres de dalt sí que superen el zero contra els dos braços, i el terra que es publica de cadascun és el de la comparació contra la integració sense optimitzar.
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:
- Mateix model, tres braços — dos d'ells, controls. Cada petició s'executa contra el proveïdor real i amb el mateix model: tal com l'enviaria una integració sense optimitzar (B0), tal com l'enviaria una integració que un equip diligent ja hauria optimitzat a mà (B1: catàleg d'eines retallat, context podat, sense floritures) i tal com l'envia BV-SALA. Mai no comparem models diferents ni èpoques diferents. La xifra contra B0 diu quant baixa la factura de qui parteix de zero; només la xifra contra B1 mesura mèrit de la capa, perquè és l'única que descompta el que el client ja podia estalviar-se tot sol. Per això el sostre del que podem prometre és el menor dels dos terres, mai el major.
- 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.
- L'estimador és estratificat per escenari, amb pes igual per escenari. L'agregat no es calcula sobre totes les mostres juntes: això deixa que el repartiment de repeticions —que el mostrejador mou segons el soroll— decideixi el titular, i n'hi ha prou de repetir de més un escenari car i d'estalvi nul per enfonsar-lo sense que la capa hagi canviat res. Cada escenari pesa 1, i el remostreig que produeix l'interval es fa dins de cada escenari. Caveat declarat: l'interval estratificat és condicional al conjunt fix d'escenaris i per això surt més estret — respon una pregunta més estreta, no amb més confiança.
- Es publica el terra de l'interval de confiança del 95 %. Amb peticions i estalvi mostral , publiquem la cota inferior unilateral
é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. La surt del remostreig estratificat del punt anterior.
Amb aquesta vara de mesurar, la tirada vigent —openai/gpt-4o-mini, 193
parelles mesurades, qualitat 100 %, artefacte d1c8233 del 12 de setembre de
2026— dona això:
| Comparació · model | Terra de l'IC 95 % |
|---|---|
enfront de B0, integració sense optimitzar · gpt-4o-mini | ≥ 23,2 % menys factura |
enfront de B1, integració ja optimitzada a mà · gpt-4o-mini | ≥ 22,9 % menys factura |
El titular que publiquem, en canvi, és ≥ 20,0 % en gpt-4o-mini, per sota
dels dos. El sostre del que es pot prometre és el menor dels dos terres —el de
B1, perquè prometre per damunt seria vendre com a mèrit nostre el que el
client ja tenia— i el titular es queda deliberadament per sota d'aquest
sostre, perquè continuï sent cert quan la tirada següent mogui un decimal. El
signe no és retòrica: és la cota inferior de l'interval, i el que es
promet mai no pot passar-se del que s'ha mesurat.
Aquí no hi apareix cap xifra de memòria cau de prefix, i l'absència és deliberada. Quan el prefix del context es repeteix, el proveïdor cobra més barat el que es repeteix: aquest descompte el posa ell —Anthropic, amb les seves pròpies regles d'exactitud—, no nosaltres. La nostra part és preparar cada petició perquè el descompte es pugui demanar, i demanar-lo en totes. Publicar-lo com a estalvi propi seria apuntar-se mèrit aliè; i a més el llibre comptable que el recull, un cop mesurat, no supera el zero. Per això aquí hi ha explicació i no percentatge.
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. 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 se situa en la literatura
Cap transformació del catàleg de BV-SALA no és, per separat, una idea nova — i dir-ho amb les cites al davant forma part de l'honestedat d'aquest article. La taxonomia completa la va enumerar FrugalGPT ja el 2023: adaptar el prompt, aproximar el model, encadenar en cascada (Chen et al., 2023). Des de llavors, cada branca ha madurat pel seu compte. La compressió de prompts és la línia més profunda: LLMLingua reporta fins a 20x de compressió amb poca pèrdua (Jiang et al., 2023), LongLLMLingua descobreix que en context llarg comprimir pot fins i tot millorar la resposta — l'efecte lost in the middle — (Jiang et al., 2024), i LLMLingua-2 ataca el problema operatiu que la primera generació va deixar obert: el mateix compressor era car i lent (Pan et al., 2024). A l'extrem, els gist tokens comprimeixen dins del model fins a 26x (Mu et al., 2023) — més general que qualsevol compressió textual, però només si controles els pesos; sobre una API tancada, que és el règim de qui paga la factura, no aplica. L'encaminament per cost va madurar en paral·lel: Hybrid LLM introdueix el nivell de qualitat desitjat com a paràmetre del router (Ding et al., 2024), RouteLLM l'entrena amb dades de preferències (Ong et al., 2024) i AutoMix hi afegeix l'autoverificació com a porta d'escalada — provar barat, verificar, i només llavors pagar car (Aggarwal et al., 2024). I la poda té la seva pròpia evidència publicada: recuperar context sempre és subòptim davant de fer-ho sota demanda (Asai et al., 2023; Jeong et al., 2024), i reduir les eines visibles no només abarateix sinó que millora l'encert del function calling (Paramanayakam et al., 2025).
La memòria cau viu en dos mons que gairebé no es parlen. L'acadèmia empeny la cau semàntica — GPTCache com a infraestructura (Bang, 2023), SCALM com a primera avaluació sobre traces reals humà-LLM (Li et al., 2024) — que optimitza el hit ratio per similitud d'embeddings i assumeix, tàcitament, el risc de servir una resposta que no correspon. Els proveïdors, en canvi, despleguen cau de prefix amb disciplina d'exactitud estricta: Anthropic exigeix segments 100 % idèntics i invalida la cau sencera si canvien les definicions d'eines (Anthropic, 2026); OpenAI cobra l'escriptura a 1,25x el preu base i la lectura a 0,1x (OpenAI, 2026). Aquests dos documents oficials estableixen una cosa que la literatura acadèmica rarament incorpora: l'estalvi de cau té cost d'escriptura — per tant només una comptabilitat neta és honesta — i la seva validesa depèn de model, versió i eines. És exactament l'esquema de claus de BV-SALA, elevat de bona pràctica a requisit.
El que el camp té resolt és l'eficàcia; el que té obert és l'evidència. Gairebé tota xifra publicada és una ràtio de millor cas sobre benchmark — «fins a 20x», «fins a un 98 % menys de cost» (Chen et al., 2023), «fins a un 40 % menys de crides» (Ding et al., 2024) — sense interval de confiança, gairebé mai sobre trànsit de producció, i sense descomptar el cost de la mateixa maquinària d'estalvi. Dos treballs recents apunten la correcció: cost-of-pass proposa mesurar en cost monetari esperat per solució correcta (Erol et al., 2025), i Miller formalitza l'aparell estadístic per comparar dues condicions d'avaluació amb rigor (Miller, 2024). Cap treball que hàgim pogut verificar no uneix les dues coses. Aquest encreuament — la taxonomia de FrugalGPT executada amb la disciplina de claus dels proveïdors, mesurada amb l'estadística de Miller en la moneda de cost-of-pass — és el forat que BV-SALA ocupa. Convé dir-ho tal qual: BV-SALA no reclama transformacions noves; reclama evidència d'una altra classe sobre transformacions conegudes.
Problemes oberts
De la literatura verificada se'n segueixen, com a mínim, cinc problemes oberts que aquesta capa toca de ple:
- Comptabilitat neta. LLMLingua-2 existeix precisament perquè el compressor de la primera generació era car (Pan et al., 2024), i l'escriptura de cau es factura a 1,25x-2x el preu base (Anthropic, 2026) — però cap treball publicat no reporta estalvis descomptant sistemàticament el cost del compressor, el router o la cau. El camp publica estalvis bruts.
- Validesa de la cau semàntica. Servir una resposta desada per similitud sense acotar formalment els falsos encerts ni l'obsolescència (Bang, 2023; Li et al., 2024) deixa obert el punt intermedi: més cobertura que la cau exacta, amb garantia de validesa.
- Certificació estadística de la qualitat. Els routers es governen per un nivell de qualitat desitjat (Ding et al., 2024; Ong et al., 2024), però el compliment no es certifica a posteriori amb inferència de dues mostres (Miller, 2024). Verificar contractes sobre trànsit real segueix obert.
- Interacció entre transformacions. El mínim d'OpenAI per poder desar un prefix implica que comprimir-lo pot destruir un descompte de cau més gran (OpenAI, 2026): les transformacions no són independents, i la seva composició òptima no està estudiada.
- Del benchmark a producció. Només SCALM parteix de traces reals (Li et al., 2024); tota la resta s'avalua en benchmarks estàtics, quan la repetició i la deriva del trànsit real són justament el que determina l'estalvi assolible.
Nota: les xifres d'aquesta secció i de l'anterior («fins a 20x», «fins a un 98 %», preus de cau...) provenen de la literatura citada i de la documentació oficial dels proveïdors a data de consulta; descriuen aquells treballs, no resultats de BV-SALA. Les xifres de BV-SALA són únicament les dels tres llibres comptables i les de la taula de resultats, totes de la mateixa tirada:
gpt-4o-mini, 193 parelles, artefacted1c8233del 12 de setembre de 2026.
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 mes de calibratge per començar — pagues només el seient, mesurem tot el teu trànsit i no cobrem comissió, i al tancament veus l'extracte exacte del que hauria costat. 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.
Referències
- #bv-sala
- #llm
- #cost
- #benchmarking
- #optimització

