HotKV redujo el uso de tokens de Claude en un 70 % en nuestro benchmark de Banking77

Una caché semántica promete reducir el gasto en LLM respondiendo desde la memoria las preguntas repetidas y similares en lugar de llamar al modelo. Lo medimos de extremo a extremo: las mismas 3000 solicitudes de atención al cliente, enviadas dos veces a cada uno de cuatro modelos Claude, una directamente al modelo y otra con HotKV delante, con la propia caché de prompts de Anthropic activada en ambas ejecuciones. Aquí está exactamente lo que ejecutamos y lo que encontró, incluidos los puntos en los que se queda corto.

En resumen. HotKV redujo las llamadas al modelo, los tokens de entrada más salida y el costo de la API en alrededor de un 70 % en cada uno de los cuatro modelos. La mayor parte proviene de las preguntas que se repiten exactamente. La capa semántica aporta unos 12 puntos más. Con el umbral de similitud por defecto de 0,81, se consideró que las respuestas en caché encajaban con la pregunta exacta entre 5,8 y 10,7 puntos porcentuales menos a menudo que las respuestas nuevas. En el único modelo en el que probamos distintos umbrales (Sonnet 5.5), un umbral de 0,88 o superior no mostró esa diferencia.

Actualizado el 12 de octubre de 2026: este artículo presenta ahora nuestra ejecución más amplia con cuatro modelos Claude actuales. Sustituye a una ejecución anterior de 1500 solicitudes con GPT y Claude Sonnet 5 que midió alrededor de un 60 % menos de tokens, y que ya no presentamos.

Qué probamos

La carga de trabajo

Reprodujimos preguntas de atención al cliente de la partición de prueba (test split) de Banking77 (PolyAI, CC BY 4.0), un conjunto de datos público de preguntas bancarias breves etiquetadas con 77 intenciones. Se presentó en Casanueva et al., 2020. Las 3000 solicitudes se extrajeron con una semilla fija. La popularidad de las intenciones sigue una distribución de Zipf con exponente 1,0, un sesgo sintético en el que unas pocas intenciones aparecen mucho más a menudo que las demás, y la pregunta dentro de una intención se elige de forma uniforme, con repeticiones. Aparecen las 77 intenciones, y 1264 de las 3000 solicitudes son preguntas distintas (contadas reproduciendo el generador de solicitudes con semilla). El banco y su política de soporte son ficticios. Escribimos una política de unos 2200 tokens, enviada como prompt del sistema en cada solicitud, que pide de dos a cuatro frases breves.

Modelos y ajustes

Ejecutamos claude-fable-5-1, claude-opus-5-5, claude-sonnet-5-5 y claude-haiku-5-5. Fable 5.1 y Opus 5.5 se ejecutaron con su ajuste de menor esfuerzo, porque su razonamiento no se puede desactivar. Sonnet 5.5 se ejecutó con el razonamiento inicial desactivado, su ajuste más bajo, y Haiku 5.5 con el razonamiento deshabilitado. La salida máxima fue de 2000 tokens para Fable y Opus y de 400 para Sonnet y Haiku, y todas las respuestas terminaron con normalidad en lugar de quedar cortadas. Se ejecutaron ocho solicitudes a la vez en ambos modos, las llamadas no se transmitieron en streaming y cada condición se ejecutó una vez.

Las dos ejecuciones

• Línea base: cada solicitud va directamente al modelo, con la caché de prompts de Anthropic activada (cache_control en el prompt del sistema, vida útil por defecto de cinco minutos). Esta es la línea base configurada que se usó aquí, no una afirmación de que se hayan agotado todas las optimizaciones del lado del proveedor.
• Con HotKV: HotKV se sitúa delante del mismo tráfico y del mismo prompt del sistema, con la caché empezando vacía.

Qué contamos

Cada recuento de tokens procede del bloque usage de la respuesta de la API: entrada sin caché, lecturas y escrituras de caché, y salida (incluidos los tokens de razonamiento). Los tokens de embeddings se cuentan aparte. Los costos usan los precios de lista de Anthropic del 11 de octubre de 2026, incluyen las llamadas de embeddings de las búsquedas semánticas y excluyen el alojamiento y las operaciones de HotKV. No son una cotización de los precios actuales.

Cómo funciona la caché

Para cada pregunta, HotKV prueba dos búsquedas antes de llamar al modelo:

1. Coincidencia exacta: un GET sobre una clave SHA-256 construida a partir del modelo, la versión del prompt del sistema y la pregunta normalizada (en minúsculas, con los espacios en blanco colapsados). Detecta una pregunta formulada con las mismas palabras.
2. Coincidencia semántica: una llamada SCACHE.GET con un embedding de la pregunta (text-embedding-3-small de OpenAI, similitud del coseno). Busca una pregunta similar. Una puntuación de similitud por sí sola no puede garantizar que la respuesta en caché encaje.

Solo un fallo en ambas llega al modelo, y su respuesta se escribe de vuelta con SET y SCACHE.SET. El umbral de similitud para un acierto semántico se fijó en 0,81 antes de la ejecución. Lo elegimos en una partición de entrenamiento (train split) de Banking77 aparte, como el valor más bajo, en pasos de 0,01, cuyos aciertos semánticos apuntaban a la misma intención al menos el 98 % de las veces (98,2 % allí). En esta ejecución, en la partición de prueba sin tocar, entre el 96,7 % y el 96,8 % de los aciertos semánticos coincidieron con la intención de la pregunta formulada: 30 o 31 aciertos de intención equivocada por modelo, de un total de 926 a 936.

Resultados

Llamadas, tokens y costo

En los cuatro modelos, las llamadas pasaron de 12.000 a 3588, los tokens bajaron un 70,1 % y el costo un 69,6 %. Alrededor del 70 % de las solicitudes se respondieron desde la caché en todos los modelos: aproximadamente el 39 % por coincidencia exacta y el 31 % por coincidencia semántica.

Las llamadas, los tokens y los dólares bajan a la vez porque HotKV elimina llamadas enteras. Lee la cifra de tokens con cuidado: entre el 90 % y el 93 % de los tokens contados son lecturas de caché del mismo prompt de política de 2200 tokens, que Anthropic factura a una pequeña fracción del precio normal de entrada. Los tokens de salida son solo entre el 6 % y el 9 % de los tokens, pero entre el 73 % y el 92 % del costo de la línea base.

Velocidad

El tiempo de respuesta mediano de toda la ejecución pasó de 2,7 segundos a 127 ms en Fable 5.1, de 2,9 segundos a 126 ms en Opus 5.5, de 1,8 segundos a 128 ms en Sonnet 5.5 y de 1,4 segundos a 125 ms en Haiku 5.5, es decir, entre 11 y 23 veces más rápido. Una pregunta repetida volvió con una mediana de unos 0,05 ms, medida por un cliente de Python a través de loopback en la misma máquina que HotKV, por lo que es una cifra local y no de red. Una pregunta reformulada, atendida desde la caché semántica, tardó unos 130 ms, casi todos ellos por la llamada a la API de embeddings.

La mediana de toda la ejecución se sitúa dentro de esa banda de aciertos semánticos porque los aciertos exactos (alrededor del 39 % de las solicitudes) son demasiado pocos para sostener la mediana por sí solos, mientras que los aciertos exactos y semánticos juntos (70 %) superan la mitad. El extremo lento se mueve menos: el 30 % de las solicitudes siguen llamando al modelo. El percentil 99 fue de unos 6,4 segundos con HotKV frente a 6,6 segundos sin él en Fable 5.1, y aproximadamente igual en Haiku 5.5. Fue menor en Opus 5.5 (4,7 segundos frente a unos 6) y en Sonnet 5.5 (2,7 segundos frente a 3,3). Las llamadas no se transmitieron en streaming, así que estos son tiempos hasta la respuesta completa, no hasta el primer token.

Calentamiento

La caché empieza vacía, así que las primeras solicitudes todavía llegan al modelo. La proporción de solicitudes atendidas desde la caché fue de alrededor del 52 % en las primeras mil solicitudes y de alrededor del 81 % en las últimas mil.

De dónde viene el ahorro

La mayor parte del ahorro es simple repetición. Una caché de coincidencia exacta por sí sola habría necesitado como máximo 1264 llamadas al modelo de 3000, una por cada pregunta distinta, es decir, alrededor de un 58 % menos. La capa semántica lo llevó a alrededor del 70 %, así que aporta aproximadamente 12 puntos en esta carga de trabajo. Es también la parte que conlleva el riesgo para la calidad de las respuestas, como muestra la siguiente sección. Esto se deriva de la secuencia de solicitudes y de los registros, no de una ejecución medida aparte.

Calidad de las respuestas

Un acierto semántico significa la misma intención, no la misma respuesta correcta. Para medir la corrección hicimos que un modelo Claude distinto evaluara cada acierto semántico. El evaluador veía la pregunta del cliente y dos respuestas en orden aleatorio: la respuesta en caché que HotKV sirvió y la respuesta nueva que el mismo modelo dio a esa pregunta exacta en la ejecución de línea base. Indicaba si cada respuesta respondía correctamente a esa pregunta exacta. Opus 5.5 evaluó las respuestas de Fable 5.1, Sonnet 5.5 y Haiku 5.5, y Fable 5.1 evaluó las de Opus 5.5, de modo que ningún modelo evaluó su propia salida.

Con el umbral por defecto

Con 0,81, una respuesta en caché encajó con la pregunta exacta entre 5,8 y 10,7 puntos porcentuales menos a menudo que una respuesta nueva del mismo modelo. Los aciertos semánticos son alrededor del 31 % de las solicitudes, así que, sobre el conjunto de las respuestas y contando los aciertos exactos como neutros, eso son aproximadamente de 2 a 3 puntos (de 1,8 a 3,3). Los evaluadores difieren en rigor, así que compara las respuestas en caché con las nuevas solo dentro de un mismo modelo.

Subir el umbral

Volvimos a ejecutar Sonnet 5.5 con otros cuatro umbrales, cada uno desde una caché vacía, con el mismo evaluador. El costo de la línea base fue de 5,51 US$.

A partir de 0,88, las respuestas en caché no mostraron un déficit frente a las nuevas, y aun así redujeron el costo un 64 % con 0,88 y un 61 % con 0,90. La evidencia es escasa. Con 0,90, el intervalo del 95 % para la diferencia va desde unos 4 puntos peor hasta 7 puntos mejor, la fila de 0,95 tiene solo 50 aciertos, y cada fila evalúa un subconjunto distinto de aciertos. Es un solo modelo, un solo evaluador y una sola ejecución por umbral, así que no es una prueba de calidad equivalente ni de un umbral seguro universal.

Preguntas casi idénticas

El riesgo real son las preguntas que parecen casi idénticas pero necesitan respuestas distintas, como depositar frente a retirar. Hicimos que Opus 5.5 escribiera 119 pares, cada uno con una pregunta real de la partición de entrenamiento más una versión con un detalle decisivo cambiado, y contamos cuántas de las preguntas modificadas superarían el umbral frente a una caché que contuviera solo la original. Estos pares están construidos para ser difíciles, no los revisó ninguna persona, y muestran un peor caso, no la frecuencia con la que ocurre en el tráfico real.

Subir el umbral reduce el riesgo pero no lo elimina. Incluso con 0,90, el 25 % de los pares deliberadamente cercanos coincidiría, y también coinciden menos paráfrasis verdaderas.

Qué significa esto a gran escala

Extrapolando el costo medido por solicitud a 1 millón de solicitudes al día durante un mes de 30 días, y suponiendo el mismo patrón de tráfico, se obtienen estas cifras mensuales:

• claude-fable-5-1: unos 303.100 US$ sin HotKV, 91.800 US$ con él, unos 211.300 US$ ahorrados.
• claude-opus-5-5: unos 146.000 US$ sin HotKV, 45.000 US$ con él, unos 101.000 US$ ahorrados.
• claude-sonnet-5-5: unos 55.100 US$ sin HotKV, 16.600 US$ con él, unos 38.500 US$ ahorrados.
• claude-haiku-5-5: unos 2700 US$ sin HotKV, 800 US$ con él, unos 1900 US$ ahorrados.

Esto es aritmética sobre el costo medido por solicitud, no otra ejecución medida. Excluye el alojamiento, y no se midió la capacidad necesaria para ese volumen. Con las 3000 solicitudes que ejecutamos, el ahorro es de solo 0,19 US$ para Haiku 5.5 y de 21,12 US$ para Fable 5.1. Los cuatro modelos se ejecutaron con respuestas cortas, y Fable 5.1 y Opus 5.5 con su menor esfuerzo, de modo que las respuestas más largas o con mucho razonamiento harían que cada llamada evitada valiera más.

Limitaciones

Esto no es una afirmación general de que “HotKV te ahorra un 70 %”. Es lo que medimos con esta carga de trabajo, y la carga de trabajo hace la mayor parte del trabajo.

• El ahorro sigue a la repetición. Con todas las intenciones igual de probables en lugar de sesgadas según Zipf, el costo bajó un 56 % en Sonnet 5.5 y en Haiku 5.5. Con 3000 preguntas todas distintas bajó un 38 %, enteramente por coincidencias semánticas entre preguntas diferentes de la misma intención, de las que Banking77 tiene muchas. Una carga de trabajo sin preguntas repetidas ni similares no ahorra nada.
• Tráfico sintético. Las extracciones son independientes: sin ráfagas, sesiones ni contexto de varios turnos. Un conjunto de datos público de preguntas bancarias breves, una política ficticia escrita para esta prueba y un conjunto finito de unas 3080 preguntas de prueba.
• Un modelo evalúa las respuestas. Ninguna persona las revisó, no hubo un segundo evaluador y todos los evaluadores son modelos Claude. Las respuestas nuevas no superaron la prueba de “encaja” del evaluador entre el 1 % y el 21 % de las veces, así que es un listón exigente.
• Misma intención no es misma respuesta. El umbral de 0,81 se calibró con etiquetas de intención, no con la calidad de las respuestas. El barrido de umbrales y la prueba de preguntas casi idénticas abarcan un modelo y un modelo de embeddings.
• Banco de pruebas pequeño. Una ejecución por condición, un único servidor de cuatro vCPUs con el cliente en la misma máquina, y una caché que no se calentó antes de las ejecuciones con HotKV.
• Los costos son costos de API. Excluyen el alojamiento y las operaciones de HotKV. Valida la calidad de las respuestas con tus propias preguntas y usa la caché exacta o respuestas nuevas allí donde la reutilización semántica no sea adecuada.

Las cifras por modelo también están en la página de IA.

Pruébalo tú mismo

La caché de coincidencia exacta de esta prueba usa simples GET y SET, que todos los planes de HotKV incluyen. La caché semántica (SCACHE.*) viene con el plan Performance y superiores (precios). Empieza en HotKV Cloud y dirige tu tráfico actual hacia él, o habla con ventas si quieres repasar primero las cifras para tu propia carga de trabajo.