El almacenamiento en caché de prompts reduce los costos de inferencia de IA hasta un 90 por ciento, y la mayoría de los equipos no lo usan bien

La mayoría de los equipos que pagan por acceso a la API de modelos de lenguaje grandes (LLM) están dejando entre un 50 y un 90 por ciento de ahorro potencial sobre la mesa, aunque el mecanismo para capturarlo existe en producción desde hace más de un año. El almacenamiento en caché de prompts permite que un proveedor de API reutilice el cómputo que ya realizó para las partes invariables de una solicitud —instrucciones del sistema, definiciones de herramientas (tools), documentos de referencia largos— en lugar de reprocesarlas en cada llamada.

El problema no es que el caché de prompts no funcione. Es que la mayoría de los equipos de ingeniería estructuran sus prompts de una forma que lo anula antes de que tenga oportunidad de ayudar, y luego concluyen que la función "no tuvo impacto" en su caso de uso.

Cómo funciona realmente el caché

Cuando un modelo transformer procesa un prompt, calcula pares clave-valor (KV) para cada token de entrada: las representaciones internas que el modelo usa para predecir el siguiente token. Este cálculo es la parte costosa de la inferencia y escala con la longitud de la entrada. El caché de prompts almacena estos pares KV en los servidores del proveedor tras una primera solicitud, indexados exactamente al mismo prefijo de tokens que los produjo.

En una solicitud posterior, si el nuevo prompt comparte ese mismo prefijo, el proveedor omite recalcular los pares KV de la parte compartida y solo procesa los tokens nuevos añadidos al final. La implementación de Anthropic, por ejemplo, cobra aproximadamente un 10 por ciento de la tarifa base de tokens de entrada por lecturas de caché y cerca de un 25 por ciento más que la tarifa base por la escritura inicial del caché —una compensación que se amortiza rápidamente para cualquier prefijo reutilizado más de un par de veces. El caché automático de prompts de OpenAI aplica un descuento del 50 por ciento en tokens de entrada cacheados sin costo de escritura separado, y el caché de contexto de Google en los modelos Gemini funciona de forma similar mediante un objeto de caché explícito que se crea y referencia.

De dónde viene el ahorro real

El ahorro no es teórico. Un agente de atención al cliente que incluye un prompt de sistema de 3.000 tokens, un extracto de base de conocimiento de producto de 5.000 tokens y un conjunto de definiciones de herramientas de 2.000 tokens en cada llamada, paga por 10.000 tokens de entrada antes de que la pregunta real del usuario —quizás 50 tokens— entre siquiera en escena. En una aplicación de alto volumen que procesa decenas de miles de solicitudes al día, esta sobrecarga eclipsa el costo marginal de la consulta en sí.

Con el caché correctamente configurado, ese prefijo de 10.000 tokens se calcula una vez y luego se lee del caché en cada llamada posterior dentro de la ventana de vida útil del caché (TTL, normalmente 5 minutos en el nivel estándar de Anthropic, extensible hasta una hora en algunos proveedores). El efecto práctico para un pipeline RAG con una ventana de contexto recuperado grande, o un agente con un esquema extenso de llamadas a herramientas, es una reducción del 60 al 80 por ciento en el costo efectivo de entrada, sin cambiar la calidad del modelo, el comportamiento de salida ni ninguna latencia que un usuario pudiera notar. La latencia en realidad mejora ligeramente, ya que los tokens cacheados omiten por completo el forward pass.

El error que mata la tasa de aciertos del caché

El caché de prompts solo funciona con coincidencias exactas de prefijo. Si un solo token cambia en cualquier punto antes del límite cacheado, toda la entrada de caché falla (miss) y el proveedor recalcula desde cero. Aquí es donde la mayoría de las implementaciones se sabotean a sí mismas silenciosamente.

El patrón de fallo más común: colocar contenido dinámico —una marca de tiempo, un ID de sesión, una lista de documentos recuperados en orden aleatorio— cerca del inicio del prompt, antes de las instrucciones estáticas del sistema y las definiciones de herramientas. Cada solicitud tiene entonces un prefijo único, y el caché nunca tiene oportunidad de acumular aciertos. La solución es mecánica pero requiere disciplina: estructurar cada prompt para que el contenido estático vaya primero (instrucciones del sistema, ejemplos few-shot, esquemas de herramientas, documentos de referencia estables) y el contenido variable al final (el mensaje real del usuario, la fecha actual si es necesaria, el estado específico de la sesión).

Un segundo error común es la personalización excesiva del prompt. Los equipos que inyectan preferencias específicas del usuario o detalles de cuenta directamente en el prompt del sistema —en lugar de pasarlos como un bloque separado y claramente delimitado después del prefijo cacheable— destruyen su propia tasa de aciertos de caché a cambio de una mejora de calidad marginal que a menudo ni siquiera es medible. Si los datos de personalización cambian por usuario o por sesión, deben ir después del límite del caché, no entrelazados en las instrucciones compartidas.

El contexto recuperado es el caso más difícil

Las aplicaciones RAG enfrentan una tensión arquitectónica genuina: todo el propósito de la recuperación es mostrar documentos diferentes para consultas diferentes, lo que por definición rompe la coincidencia de prefijo en el propio contenido recuperado. La solución de mayor impacto aquí no es cachear los fragmentos recuperados, sino cachear todo lo que los rodea. Mantén el prompt del sistema, las instrucciones de recuperación y la especificación del formato de salida en un prefijo estable, y trata los documentos recuperados como el sufijo variable. Los equipos que ejecutan bibliotecas de herramientas grandes pueden obtener una ganancia adicional cacheando el bloque de definiciones de herramientas por separado del contenido recuperado, ya que los esquemas de herramientas rara vez cambian dentro de una sesión aunque la consulta sí lo haga.

Medirlo correctamente

Los paneles de los proveedores suelen reportar los conteos de tokens de lectura y escritura de caché por separado de los tokens de entrada estándar, lo que facilita calcular la tasa de aciertos real: lecturas de caché divididas entre el total de tokens elegibles para prefijo. Los equipos deben rastrear explícitamente este número en lugar de inferir el ahorro a partir de la factura total, ya que una tasa de aciertos baja puede ocultarse tras una factura aparentemente razonable si el volumen de solicitudes también fluctúa.

Conclusiones prácticas

Audita primero la estructura de tu prompt: el contenido estático (instrucciones del sistema, esquemas de herramientas, documentos de referencia) debe ir antes de cualquier contenido variable por solicitud, sin excepciones.
No personalices dentro del prefijo cacheable: inyecta los datos específicos del usuario como un bloque claramente separado después de las instrucciones compartidas.
En pipelines RAG, cachea el andamiaje estable alrededor del contenido recuperado, no el contenido recuperado en sí.
Rastrea la tasa de aciertos de caché como una métrica explícita, no como algo inferido del gasto total.
Revisa la ventana TTL de tu proveedor y los patrones de tráfico: los vacíos de tráfico más largos que la ventana TTL forzarán una nueva escritura de caché sin importar la estructura del prompt.