Tres niveles de caché para dejar de pagar dos veces la misma respuesta de un LLM
El patrón es el de toda la vida: huella de las entradas, comparar y saltarse el trabajo si nada cambió. Aplicado a las llamadas a modelos, evita pagar tokens por respuestas que ya tienes.
Un LLM puede responder mil veces a la misma pregunta y cobrarte las mil. La salida no está en afinar el prompt, sino en no llamar al modelo cuando la respuesta ya existe y sigue siendo válida: se calcula una huella de todo lo que podría cambiar el resultado y, si coincide con la de una respuesta guardada, se devuelve directamente.
La idea tampoco es nueva. En los pipelines de datos nocturnos pasa lo mismo: un job recalcula agregaciones que no han cambiado desde la ejecución anterior, pasa todos sus chequeos y consume cómputo para nada. Nadie lo nota porque nada falla; sale a la luz en una revisión de costes, cuando alguien ve que buena parte del cómputo aguas arriba está respondiendo una pregunta cuyas entradas nunca se movieron.
Prompt caching no es lo mismo que cachear respuestas
Conviene separar dos cosas que se confunden. El prompt caching del proveedor reutiliza el cálculo del prompt y cobra las lecturas elegibles a precio reducido, pero la generación de salida se sigue facturando. Lo que se plantea aquí es otra cosa: guardar la respuesta en tu propia infraestructura y no invocar al modelo en absoluto. Como la facturación va por tokens y muchas APIs tratan una petición duplicada como una petición nueva, la diferencia se nota en la cuenta.
El tráfico repetido aparece solo: usuarios que convergen en preguntas parecidas, jobs por lotes que repiten el mismo texto aburrido en cada ejecución, pruebas de prompt engineering en desarrollo y en CI que lanzan la misma entrada una y otra vez, y agentes con tool calling que golpean la misma herramienta de base de conocimiento varias veces al día.
Exacto, semántico e híbrido
El primer nivel es el más simple: normalizar el cuerpo de la petición, pasarlo por un hash criptográfico como SHA-256 y buscar ese hash en un almacén en memoria tipo Redis. Si hay coincidencia, se devuelve sin esperar a la inferencia. Funciona cuando los lotes son acotados y predecibles, que es el caso de los pipelines por lotes, las ejecuciones de CI y las tareas de resumen repetitivas.
El segundo nivel cubre las paráfrasis. La consulta se pasa por un modelo de embeddings, el vector va a una base de datos vectorial y las consultas nuevas se buscan por similitud de coseno. Un punto de partida habitual es un umbral entre 0,90 y 0,95, pero es un número para calibrar contra consultas reales, no un valor por defecto. Ojo con las herramientas: unas devuelven similitud, que sube hacia 1, y otras distancia, que baja hacia 0, así que hay que confirmar contra qué se está comparando el umbral. Y un umbral laxo mete respuestas equivocadas: una pregunta sobre el tiempo en una ciudad no se puede confundir con la misma pregunta sobre otra ciudad solo porque el coseno salga alto.
El tercer nivel encadena los dos: primero el almacén exacto y, solo si falla, la búsqueda semántica. Cuando esta acierta, el resultado se promociona al almacén exacto bajo el hash de la consulta nueva que lo disparó, de modo que esa paráfrasis y su respuesta pasan a ser un acierto exacto la próxima vez. El TTL se hereda del registro original para no resucitar respuestas caducadas.
La clave de todo esto no es solo el texto de la consulta. También entran el contexto y los documentos del prompt, el modelo y sus ajustes, la versión de cualquier fuente recuperada y el ámbito de acceso de quien llama. Dos preguntas idénticas sobre documentos distintos, o hechas por usuarios con permisos distintos, no pueden compartir entrada en la caché.
El ahorro real depende de cuánto tráfico repetido tenga cada carga de trabajo, así que lo sensato es medirlo antes de montar nada. Una caché con las claves mal definidas ahorra poco y devuelve respuestas que no tocan.
