Nuestro banco A/B, abierto. Mídenos.

Qué se mide y cómo

• Dos brazos, la misma petición. A va directa al proveedor, sin la capa; B pasa por la capa con su configuración por defecto. Mismo prompt, mismo muestreo y mismo tope de salida.
• El coste lo cuenta el proveedor. Cada brazo se valora con el usage que devuelve el API en cada llamada, al precio de lista. El ahorro es 1 − coste(B) / coste(A) de la misma tirada, no lo que la capa dice de sí misma.
• Intervalos al 95 %. Los calcula cada arnés (remuestreo por familias de preguntas, Wilson en las tasas de negativa). Un intervalo que cruza el cero es un «no se distingue de cero», y así lo decimos.
• El paquete, el que se instala. El brazo B corre el fuente de la etiqueta 0.4.31; su dist/index.js es idéntico byte a byte al del tarball de npm (sha256 b52f99cacf9804ecd3153e56f26ec3adcdc2510d52a8446a369ecf914e0b5731).
• Sin atajos. Cada arnés vigila los hosts a los que habla y lleva un tope de gasto por modelo escrito en código. Un modelo que no se pudo medir sale como «no medido», con su motivo.

Cuatro baterías, datasets públicos fijados

Ahorro medido por modelo

GSM8K, con un flujo de peticiones en el que un 30 % son repeticiones exactas y un 20 % paráfrasis. Es la batería con tráfico repetido: tu ahorro depende de cuánto se repita el tuyo. Sin repeticiones, mira «Lo que no ahorra».

Origen del ahorro, posición a posición: «de la caché exacta» es lo que A pagó en las peticiones que la capa sirvió sin llamar al proveedor; «en las llamadas» es la diferencia en las que sí llegaron, sobre todo caché de prefijo del proveedor (más algo de variación de la salida). Las dos suman el ahorro total.

La exactitud se mide sobre las preguntas con respuesta publicada; las variantes con una cifra cambiada solo sirven para comprobar que la capa no entrega la respuesta de otra pregunta.

Garantías, contadas

Lo que no ahorra

Sin repeticiones, el ahorro es ≈ 0 %. Lo publicamos igual, porque es lo que vas a ver si tu tráfico no se repite.

MT-Bench es chat de dos turnos con una capa nueva por pregunta: no hay nada que la caché pueda reutilizar y el prompt casi nunca llega al mínimo que el proveedor exige para cachear un prefijo. En BFCL cada llamada a herramientas es distinta. Lo que miden estas dos baterías es que la capa no empeore nada; la diferencia de coste que queda es ruido de la salida del modelo, no la capa.

Estado por modelo y batería

Cada celda enseña la tirada de la versión más alta de la capa. Si un modelo no se pudo medir, se dice por qué, en vez de dejar el hueco.

Fallos que el banco encontró

El banco no está para salir bien en la foto: está para encontrar los fallos antes que tú. Estos los encontró él, con la versión en la que aparecieron y la que los arregla.

1. La caché semántica sin calibrar servía la respuesta de otra pregunta 0.4.30 → 0.4.31

   Con la caché semántica sin calibrar, una variante con otro número («three baskets» frente a «two baskets») podía recibir la respuesta de la pregunta original. Contado sobre las variantes de GSM8K.

   • Encontrado en la 0.4.30: 15 de 111. gsm8k.json
   • Arreglado en la 0.4.31 (#383).
   • Verificado en vivo con la 0.4.31: 0 de 198.

2. La capa recortaba el catálogo de herramientas sin señal para hacerlo 0.4.30 → 0.4.31

   En conversaciones de varios turnos, el brazo B enviaba menos herramientas que el A aunque nada indicaba cuáles sobraban. Contado sobre las conversaciones multi-turno de BFCL.

   • Encontrado en la 0.4.30: 20 de 20. bfcl.json
   • Arreglado en la 0.4.31 (#382).
   • Verificado en vivo con la 0.4.31: 0 de 83.

3. Algunas negativas escritas como texto se guardaban en caché 0.4.31 → 0.4.32

   Una negativa que el modelo escribe como texto (sin la señal del API) podía guardarse en caché, repetirse y acreditarse como ahorro. Contado en prompts de XSTest.

   • Encontrado en la 0.4.31: 39 de 2824. xstest-0431-claude.jsonxstest-0431-gama-alta.jsonxstest-0431.json
   • Arreglado en la 0.4.32 (#393, #401).
   • Pendiente de volver a medir en vivo con la 0.4.32.

4. Un filtro de contenido de Gemini se cacheaba como respuesta 0.4.31 → 0.4.32

   Gemini señala su filtro con un motivo de parada propio que la capa no reconocía como negativa, así que podía cachearlo y repetirlo. Contado en prompts de XSTest.

   • Encontrado en la 0.4.31: 6 de 508. xstest-0431-gama-alta.json
   • Arreglado en la 0.4.32 (#402).
   • Pendiente de volver a medir en vivo con la 0.4.32.

5. Gemini no pasaba por la capa 0.4.31 → 0.4.32

   La capa enviaba un campo propio del API de OpenAI a cualquier endpoint compatible, y Gemini lo rechaza: todas las peticiones del brazo B fallaban. Contado en peticiones de GSM8K.

   • Encontrado en la 0.4.31: 504 de 504. gsm8k-0431-gama-alta.json
   • Arreglado en la 0.4.32 (#402).
   • Pendiente de volver a medir en vivo con la 0.4.32.

6. Con Gemini 3, el segundo turno con herramientas fallaba 0.4.31 → 0.4.32

   La capa no devolvía la firma de pensamiento que Gemini 3 exige en cada llamada a herramientas, así que el turno siguiente se rechazaba. Contado en continuaciones multi-turno de BFCL.

   • Encontrado en la 0.4.31: 50 de 50. bfcl-0431-gama-alta.json
   • Arreglado en la 0.4.32 (#402).
   • Pendiente de volver a medir en vivo con la 0.4.32.

Cómo reproducirlo

El código del banco todavía no es público; el método sí, y cabe en cinco pasos. Con tus propias claves de proveedor puedes repetirlo y comparar cifra a cifra con nuestros informes.

1. El dataset. Descarga cada dataset público en el commit de la tabla de arriba y comprueba el sha256 de cada fichero antes de usarlo. Si no cuadra, no es el mismo dataset.
2. La capa. Instala @bivelio/savings-layer desde npm en la versión que dice el informe y comprueba el sha256 de dist/index.js: cada informe lleva el suyo.
3. Dos brazos por prompt. A va directo al proveedor; B manda el mismo prompt, al mismo modelo y con el mismo tope de salida, a través de la capa con su configuración por defecto. Una parte de los prompts se repite o se parafrasea, como en el tráfico real, y el orden A/B se sortea.
4. El coste lo dice el proveedor. Suma lo que factura cada brazo según el usage que devuelve el proveedor, a su tarifa publicada. El ahorro es 1 − coste B / coste A, con su intervalo.
5. La calidad, en la misma tirada. Puntúa igual las respuestas de los dos brazos (respuesta exacta en GSM8K, llamada a herramienta en BFCL, negativa o no en XSTest, juez en MT-Bench) y compáralas con el informe JSON de la misma batería y versión.

Los informes

Cada tirada deja un informe JSON con su diseño, sus limitaciones y cada llamada medida: usage, coste por brazo y clasificación de la respuesta. Se sirven desde esta web.

Los informes se sirven tal como los escribió el banco, con una excepción: se quitan los datos del entorno de quien midió (rutas de disco, correos). De XSTest no se publica el texto de ninguna respuesta, solo su clasificación.