Prompt caching en LLMs: guía práctica para reducir costo y latencia en agentes de IA

Qué vas a lograr

El objetivo no es “activar una caché” y asumir que todo será más barato. El objetivo es identificar qué parte del contexto de una aplicación de IA se repite, hacerla reutilizable y medir si baja el costo y la latencia sin perjudicar la calidad.

Esto es especialmente relevante en chatbots de catálogo, asistentes de soporte, agentes internos y automatizaciones que envían una y otra vez las mismas instrucciones, definiciones de herramientas, políticas o documentación.

Qué es el prompt caching

Una aplicación con un LLM suele enviar instrucciones y contexto antes de la pregunta variable. Cuando ese prefijo es grande y se repite, procesarlo desde cero es trabajo repetido. El prompt caching permite reutilizar partes compatibles de ese contexto.

La idea práctica es separar lo estable de lo variable: políticas, instrucciones, catálogos relativamente estáticos y esquemas de herramientas primero; conversación, consulta y datos que cambian después.

OpenAI ha ampliado en GPT-6 la capacidad de observar y controlar mejor esa reutilización. La consecuencia de ingeniería es importante: el contexto pasa a ser un recurso cuyo comportamiento podemos medir.

Cuándo tiene sentido

Un buen candidato tiene muchas solicitudes que comparten un prefijo importante. Por ejemplo, un chatbot de una tienda puede reutilizar reglas de atención, descripción del negocio, políticas y definiciones de herramientas.

No aporta lo mismo cuando cada petición es completamente distinta o casi todo el prompt cambia. Tampoco conviene reorganizar una aplicación solo para perseguir un porcentaje de caché si el volumen es pequeño.

Implementación paso a paso

1. Mide antes de cambiar

Registra tokens de entrada, costo estimado, latencia y, cuando el proveedor lo exponga, tokens o porcentaje servido desde caché. Sin línea base no puedes demostrar ahorro.

2. Divide el contexto

Clasifica cada bloque como estable, semiestable o variable. Coloca primero el contenido estable y evita datos dinámicos innecesarios dentro de ese prefijo.

3. Mantén estable lo reutilizable

Versiona instrucciones y herramientas de manera deliberada en lugar de reconstruirlas de forma distinta en cada llamada.

4. Separa los datos vivos

Precios, stock, pedidos o datos del cliente deberían llegar desde herramientas o consultas cuando se necesitan. No conviertas el prompt base en una copia permanente de la base de datos.

5. Compara antes y después

Ejecuta conversaciones representativas. Compara costo por solicitud, latencia, tasa de caché y calidad. El ahorro válido es el que aparece en tus métricas, no el porcentaje máximo anunciado.

Ejemplo: chatbot de catálogo

Imagina una tienda cuyo asistente repite instrucciones, políticas, estructura del catálogo y definiciones de herramientas en cada turno. Una arquitectura más eficiente mantiene un bloque estable con identidad, reglas y herramientas; consulta catálogo, stock y precio mediante herramientas; y coloca al final la pregunta y el contexto variable del cliente.

El experimento correcto es ejecutar el mismo conjunto de preguntas con ambas arquitecturas y comparar tokens procesados, latencia, costo y exactitud.

Cómo comprobar que funciona

Crea un log con solicitudes, tokens de entrada, tokens reutilizados, costo medio, latencia p50/p95 y fallos. Añade pruebas de calidad para comprobar que la optimización no elimina contexto necesario.

Errores comunes

Mezclar timestamps, IDs aleatorios o datos cambiantes en el bloque estable; enviar información que una herramienta podría consultar bajo demanda; y cambiar continuamente las instrucciones base.

Un porcentaje de descuento de tokens del proveedor tampoco equivale automáticamente al mismo ahorro en la factura total. Depende de la mezcla de tokens, modelos, volumen y patrón real de reutilización.

Aplicación empresarial

En una tienda online, esta técnica puede aplicarse a asistentes de catálogo y soporte que reutilizan las mismas instrucciones y políticas. En sistemas internos, puede servir a agentes que comparten reglas y definiciones de herramientas en muchas ejecuciones.

Antes de adoptarla, compara costo por solicitud, latencia y calidad con un conjunto representativo de tareas. Mantén la optimización solo si las mediciones muestran una mejora sin perder exactitud.

Conclusión

Si tu aplicación repite mucho contexto, mide primero, estabiliza el prefijo reutilizable, mueve los datos vivos a herramientas y vuelve a medir. El objetivo es demostrar ahorro real manteniendo la calidad.

Fuente y alcance

Consultar la fuente original. Fuente revisada el 13 de octubre de 2026. Las propuestas de aplicación de esta guía son recomendaciones editoriales; no son resultados medidos en nuestros proyectos.