Colocar un proxy con caché entre tu aplicación y el proveedor del modelo de lenguaje es una de esas optimizaciones que parecen obvias en cuanto alguien las menciona, y sin embargo muchos equipos tardan meses en implementarlas porque el diseño correcto tiene más aristas de las que parecen. Durante 2025 ha habido suficientes despliegues reales como para tener ya una bibliografía decente de patrones que funcionan y de trampas que hay que evitar. Vale la pena hacer un recorrido honesto porque la diferencia entre una caché bien hecha y una mal hecha puede ser un ahorro del setenta por ciento en tokens frente a una experiencia de usuario degradada que nadie detecta hasta que es tarde.
El punto de partida
La tesis es sencilla: muchas peticiones que tu aplicación envía al modelo son repetidas o casi repetidas. Si detectas la repetición y devuelves la respuesta anterior sin llamar al proveedor, ahorras los tokens de esa petición. En aplicaciones con preguntas frecuentes, conversaciones sobre documentación, plantillas de generación recurrentes, los porcentajes de repetición pueden ser altísimos, y el retorno sobre el esfuerzo de montar una caché es enorme.
La complicación aparece cuando se intenta definir qué significa petición repetida. El caso trivial es cuando el texto de entrada es idéntico, byte a byte. Esa caché exacta es fácil de implementar y captura valor real en algunos escenarios. Pero la mayoría de peticiones interesantes tienen pequeñas variaciones: espacios distintos, nombres sustituidos, fechas diferentes. Una caché exacta ignora estas similitudes y las trata como peticiones nuevas, dejando ahorro sobre la mesa.
De ahí nacen las distintas variedades de caché: exacta, normalizada, semántica, jerárquica. Cada una tiene su lugar y su conjunto de riesgos. La clave es entender cuál aplica a qué caso y qué precauciones exige.
Caché exacta
Es el patrón más simple: hash del texto completo de la petición como clave, respuesta como valor. Se implementa en veinte líneas sobre Redis o Memcached. Funciona bien cuando las peticiones llegan de sistemas automatizados con entradas deterministas, cuando la aplicación genera peticiones idénticas por diseño, o cuando los usuarios preguntan exactamente lo mismo repetidamente.
El caso claro de éxito es el de aplicaciones que usan el modelo para procesar datos estructurados. Un sistema que extrae entidades de facturas, que clasifica correos electrónicos, que resume fragmentos de texto predefinidos: todos ellos tienen alta tasa de repetición exacta y la caché simple captura buen porcentaje del tráfico.
Las limitaciones son conocidas: cualquier variación de entrada invalida la caché. Un espacio extra, una coma distinta, una mayúscula cambiada bastan para fallar. Para mitigar esto se aplica normalización antes del hash: trim, colapso de espacios, minúsculas selectivas. Esto mejora la tasa de acierto sin cambiar la semántica y es casi siempre rentable.
Caché semántica
El siguiente paso es reconocer peticiones similares aunque no idénticas. “¿Cuál es el horario del soporte?” y “¿A qué hora atiende el soporte?” son la misma pregunta con distintas palabras. Una caché semántica captura esta equivalencia embebiendo la petición con un modelo pequeño, buscando en un índice vectorial peticiones anteriores cercanas, y reutilizando la respuesta si la similitud supera un umbral.
Esta aproximación tiene ventajas enormes y riesgos igualmente grandes. La ventaja es que captura muchísimo más tráfico que la caché exacta, particularmente en aplicaciones conversacionales donde los usuarios formulan cosas parecidas de forma variada. El riesgo es la falsa equivalencia: dos preguntas que parecen similares semánticamente pueden requerir respuestas distintas por algún detalle sutil. Un umbral demasiado bajo produce respuestas incorrectas, un umbral demasiado alto aporta poco sobre la caché exacta.
La calibración del umbral es empírica. Hay que recoger pares de peticiones reales, etiquetar cuáles son verdaderamente equivalentes y cuáles no, y ajustar el umbral en esa frontera. Este proceso es trabajo serio y tiene que repetirse periódicamente si la distribución de peticiones cambia. Sin esta disciplina la caché semántica es una mina: funciona aparentemente bien durante meses y un día empieza a devolver respuestas inadecuadas a usuarios reales.
Una mitigación útil es verificar la respuesta cacheada antes de devolverla. Una llamada al modelo barato con la nueva petición y la respuesta candidata como contexto: “¿esta respuesta es correcta para esta petición? Sí o no”. Esta verificación añade coste pero protege contra falsos positivos, y en muchos despliegues el ahorro neto sigue siendo sustancial.
Caché jerárquica
En aplicaciones con conversaciones largas, el patrón más interesante es cachear no la petición completa sino partes estructurales: la instrucción de sistema, el contexto de la aplicación, los documentos recuperados. Los proveedores grandes de modelos han introducido en 2024 y 2025 mecanismos de caché de prompt integrados en su plataforma que hacen esto de forma nativa: marcas algún fragmento como cacheable, y si una petición posterior lo reutiliza, la parte cacheada se cobra a un precio reducido.
Anthropic introdujo caché de prompt en agosto de 2024, OpenAI siguió con caché automático poco después, y Google también tiene su variante. Cada proveedor tiene detalles distintos sobre mínimos, expiración, precio, pero la idea compartida es la misma: reconocer que el contexto repetido no tiene que pagarse repetidamente.
Esta caché jerárquica es complementaria a las anteriores, no sustituta. Una aplicación bien diseñada puede combinar caché exacta local para peticiones triviales, caché semántica para equivalencias, y caché de prompt del proveedor para la parte común de contextos largos. Cada capa captura un tipo distinto de repetición y los ahorros se suman.
Trampas operativas
La trampa más frecuente es la privacidad. Si tu aplicación cachea respuestas a peticiones que contienen datos personales, estás almacenando esos datos de forma potencialmente inesperada. Hay que tener políticas claras: qué se cachea, durante cuánto, con qué mecanismos de borrado. Un incidente público en el que la caché devuelve a un usuario datos de otro usuario es difícil de reparar reputacionalmente.
La segunda trampa es la invalidación. Si tu aplicación depende de datos cambiantes, una respuesta cacheada hace tres días puede estar obsoleta. Hay que definir tiempo de vida corto para respuestas sensibles al tiempo, mecanismos de invalidación explícita cuando los datos subyacentes cambian, y políticas que eviten cachear consultas que dependen del momento actual. Una caché que devuelve información desactualizada es peor que no tener caché.
La tercera trampa es la degradación silenciosa. Una caché que funciona mal no se detecta fácilmente porque devuelve respuestas que parecen razonables. Sin métricas de calidad ejecutadas regularmente sobre muestras de tráfico cacheado, un equipo puede creer que todo va bien durante meses mientras los usuarios reciben respuestas subóptimas. Esta vigilancia es obligatoria si se introduce caché semántica.
La cuarta trampa es tratar la caché como optimización en lugar de como componente arquitectónico. Una caché cambia las propiedades del sistema: latencia, consistencia, comportamiento bajo fallos. Hay que diseñar para estos cambios desde el inicio y no instalar una caché como último parche cuando la factura del proveedor sube.
Métricas que importan
Tres métricas permiten evaluar la salud de una caché. La tasa de acierto es la primera: qué porcentaje de peticiones se resolvió desde la caché. Sin un número decente aquí, la caché no está aportando valor. Un diez por ciento suele ser el umbral por debajo del cual no compensa la complejidad; un cuarenta o más ya es claramente rentable.
La segunda métrica es el ahorro efectivo en tokens. La tasa de acierto es proxy, pero el número real es cuántos tokens se habrían enviado al proveedor si no estuviese la caché. Esto se calcula multiplicando el acierto por el tamaño medio de petición y se convierte a euros o dólares directamente.
La tercera métrica es la calidad percibida tras aplicar la caché. Se ejecuta una evaluación automatizada sobre peticiones reales con y sin caché, comparando resultados. La caída de calidad tiene que estar por debajo de un umbral aceptable. Si esta métrica no se vigila regularmente, la caché puede estar degradando la aplicación de forma invisible.
Mi lectura
Las cachés para modelos de lenguaje son una de las optimizaciones con mejor retorno sobre esfuerzo en 2025. Las herramientas están maduras, los patrones están bien documentados, y los proveedores grandes ofrecen caché de prompt nativa que elimina parte del trabajo. Un equipo que no ha introducido caché y que tiene una factura de modelos significativa probablemente está dejando ahorros claros sobre la mesa.
Dicho eso, la diferencia entre una caché bien hecha y una mal hecha es grande. Empezar por caché exacta normalizada es prudente: aporta ahorro inmediato con riesgo mínimo y sirve como base para evaluar si merece la pena subir a semántica. Añadir caché de prompt del proveedor cuando sea aplicable captura otro tramo sin riesgo adicional. Solo pasar a caché semántica cuando se haya construido la disciplina de medición necesaria.
La pregunta que usaría como control antes de desplegar es si el equipo sabe cómo detectar si la caché está devolviendo respuestas malas. Si la respuesta es no, la caché no está lista para producción aunque técnicamente funcione. Si la respuesta es sí, con métricas automáticas y revisiones periódicas, entonces la caché es una palanca enorme y el ahorro puede ser la diferencia entre una aplicación económicamente viable y una que se come el margen. Esa disciplina es lo que separa las cachés que ahorran dinero de las que ahorran dinero a costa de otra cosa.
