¿Qué es el almacenamiento en caché de prompts? Mejores prácticas explicadas

Los Modelos de Lenguaje Grande (LLMs) han revolucionado la forma en que interactuamos con la IA, permitiendo tareas complejas como la generación de texto, traducción, respuesta a preguntas y más. Sin embargo, interactuar con estos poderosos modelos, especialmente con solicitudes sofisticadas, puede generar costos computacionales significativos y latencia. Muchas aplicaciones implican enviar solicitudes similares o parcialmente idénticas repetidamente. Imagina un chatbot con un aviso del sistema fijo, una herramienta de análisis de documentos que procesa fragmentos con las mismas instrucciones, o un agente que utiliza definiciones de herramientas consistentes. En estos escenarios, el LLM procesa repetidamente la misma información inicial (el prefijo de la solicitud), desperdiciando computación y aumentando los tiempos de respuesta.

El almacenamiento en caché de solicitudes surge como una poderosa técnica de optimización para abordar esta ineficiencia. Permite a los proveedores de LLM almacenar el estado computacional intermedio asociado con la parte inicial y estática de una solicitud (el prefijo). Cuando las solicitudes posteriores utilizan el mismo prefijo, el modelo puede reutilizar este estado almacenado, omitiendo la computación redundante y procesando solo la nueva parte dinámica de la solicitud (el sufijo). Esto conduce a mejoras sustanciales tanto en latencia como en costos, haciendo que las aplicaciones de LLM sean más rápidas y económicas.

Esta guía proporciona una visión integral sobre el almacenamiento en caché de solicitudes, cómo funciona, sus beneficios, detalles de implementación (enfocándose en la API de Anthropic, que también es relevante para los modelos Claude en AWS Bedrock), consideraciones de precios, limitaciones y mejores prácticas.

Cómo Funciona el Almacenamiento en Caché de Solicitudes: El Mecanismo

En su núcleo, el almacenamiento en caché de solicitudes explota la naturaleza repetitiva de muchas interacciones con LLM. Cuando envías una solicitud a un LLM, el modelo procesa los tokens de entrada secuencialmente para generar una representación interna o estado. El almacenamiento en caché de solicitudes interfiere en este proceso.

1. Fallo de Caché (Primera Solicitud / Prefijo Cambiado): Cuando llega una solicitud con un prefijo de solicitud que no se ha visto recientemente o que no coincide con ninguna entrada de caché existente, el LLM procesa la totalidad de la solicitud como de costumbre. Sin embargo, si el almacenamiento en caché está habilitado para un límite de prefijo específico, el sistema almacena el estado interno del modelo correspondiente a ese prefijo después de procesarlo. Esto se conoce comúnmente como escritura en caché. Se asocia un identificador único, típicamente un hash criptográfico del contenido del prefijo (incluyendo avisos del sistema, definiciones de herramientas y mensajes hasta el punto de caché), que actúa como la clave de caché.
2. Acertar en Caché (Solicitud Posterior): Si una solicitud posterior llega dentro del Tiempo de Vida (TTL) de la caché y su prefijo coincide exactamente con el contenido asociado a una clave de caché almacenada, el sistema recupera el estado interno guardado. El LLM efectivamente avanza rápidamente al final del prefijo sin reprocesarlo. Luego, solo necesita procesar la parte nueva de la solicitud (el sufijo). Esto se conoce como lectura de caché o acierto en caché.

El Prefijo Almacenado en Caché:

Lo que constituye exactamente el "prefijo" depende de la API y de cómo estructuras tu solicitud. Generalmente, incluye las partes estáticas de tu solicitud que pretendes reutilizar a través de las llamadas. Por ejemplo, usando la estructura de la API de Anthropic como referencia:

• Herramientas: Definiciones de herramientas/funciones disponibles.
• Aviso del Sistema: Instrucciones de alto nivel o contexto para el modelo.
• Mensajes: Mensajes iniciales de usuario/asistente, como ejemplos de few-shot o el historial de la conversación.

El orden normalmente es importante (por ejemplo, Anthropic procesa tools, luego system, luego messages). Designas dónde termina el prefijo que se puede almacenar en caché utilizando parámetros específicos de la API.

Características de la Caché:

• Vida Útil (TTL): Las cachés no son permanentes. Tienen un TTL. Por ejemplo, la caché de Anthropic tiene un TTL mínimo de 5 minutos, que se refresca cada vez que se accede a la entrada de caché (un acierto en caché). Si una entrada de caché no se utiliza dentro de su TTL, expira y deberá recrearse en la siguiente solicitud relevante. Actualmente, la mayoría de las implementaciones ofrecen almacenamiento en caché "efímero" con vidas útiles relativamente cortas.
• Alcance y Privacidad: El almacenamiento en caché se diseña con la privacidad en mente. Las cachés suelen estar segregadas a nivel de organización o cuenta. Incluso si dos organizaciones diferentes envían el exacto mismo prefijo de solicitud, no compartirán una entrada de caché. Dentro de una organización, los usuarios que envían prefijos idénticos pueden potencialmente compartir una entrada de caché, mejorando la eficiencia para aplicaciones de equipo. El uso de hashes criptográficos para claves asegura que solo las solicitudes con prefijos idénticos pueden acceder a una caché específica.
• Coincidencia Exacta: El almacenamiento en caché se basa en coincidencias exactas del contenido del prefijo. Cualquier cambio, por pequeño que sea (incluso un espacio en blanco), dentro del prefijo designado resultará en un fallo de caché y requerirá una nueva escritura en caché.

¿Por Qué Usar Almacenamiento en Caché de Solicitudes?

Implementar almacenamiento en caché de solicitudes ofrece ventajas significativas, centradas principalmente en el rendimiento y la eficiencia de costos.

1. Latencia Reducida: Este suele ser el beneficio más inmediato. Al omitir el reprocesamiento de potencialmente miles de tokens de prefijo, el LLM puede comenzar a procesar la nueva información relevante (el sufijo de la solicitud) mucho más rápido. Esto se traduce directamente en tiempos de respuesta más rápidos para el usuario final. Para aplicaciones que requieren interacción en tiempo real, como chatbots o asistentes de código, esta aceleración es crucial. AWS Bedrock informa de reducciones de latencia de hasta el 85% para modelos soportados.
2. Costo Reducido: Las APIs de LLM generalmente cobran en función del número de tokens de entrada y salida procesados. Cuando ocurre un acierto en caché, a menudo se te cobra una tarifa significativamente más baja por los tokens leídos de la caché en comparación con la tarifa estándar de tokens de entrada. Solo pagas la tarifa estándar de entrada por los tokens nuevos en el sufijo (y potencialmente una tarifa ligeramente más alta por la escritura inicial en caché). A lo largo de muchas llamadas con prefijos grandes y estáticos, esto puede llevar a ahorros significativos en costos. AWS Bedrock sugiere que son posibles reducciones de costos de hasta el 90%.
3. Rendimiento Optimizado para Casos de Uso Comunes: El almacenamiento en caché es particularmente impactante para aplicaciones que implican inherentemente repetición de solicitudes:

• Generación Aumentada por Recuperación (RAG) / Preguntas y Respuestas de Documentos: Documentos grandes o fragmentos de contexto a menudo se alimentan repetidamente como parte de la solicitud, mientras que solo cambia la pregunta del usuario. Almacenar en caché el contexto del documento acelera significativamente las preguntas y respuestas sobre ese documento.
• Solicitudes de Pocos Ejemplos: Proporcionar múltiples ejemplos dentro de la solicitud (aprendizaje de pocos ejemplos) mejora el rendimiento del modelo, pero aumenta la longitud de la solicitud. Almacenar en caché estos ejemplos estáticos evita reprocesarlos para cada nueva consulta.
• Flujos de Trabajo Agenciales: Los agentes de IA a menudo dependen de avisos del sistema complejos, instrucciones detalladas y un conjunto fijo de definiciones de herramientas. Almacenar en caché estos elementos constantes acelera la ejecución de tareas, especialmente en procesos de múltiples pasos.
• Chatbots / Conversaciones de Múltiples Rondas: A medida que crece el historial de la conversación, el aviso y las instrucciones iniciales del sistema a menudo permanecen iguales. Almacenar en caché el aviso del sistema y, potencialmente, almacenar en caché de manera incremental las rondas de la conversación, mantiene la interacción rápida incluso a medida que se llena la ventana de contexto.
• Asistentes de Código: El contexto de código estático, la documentación de la biblioteca o las instrucciones de plantilla pueden almacenarse en caché, permitiendo que el asistente se concentre en la consulta de codificación específica del usuario.

1. Integración Sin Problemas: El almacenamiento en caché de solicitudes está diseñado para funcionar junto con otras características de LLM. Por ejemplo, se integra con características de AWS Bedrock como Agentes y Guardrails, permitiéndote aprovechar configuraciones complejas sin incurrir en la penalización completa de latencia por componentes repetidos.

Cómo Habilitar el Almacenamiento en Caché de Solicitudes

El método exacto para habilitar el almacenamiento en caché de solicitudes varía ligeramente entre los proveedores de LLM y sus APIs. Aquí, nos centraremos en la implementación utilizando la API de Mensajes de Anthropic, que es aplicable a los modelos Claude directamente a través de Anthropic o a través de plataformas como AWS Bedrock.

Principio General: Estructura tu Solicitud

La clave es estructurar tus llamadas a la API de tal manera que el contenido estático y reutilizable aparezca primero, seguido del contenido dinámico.

+-------------------------+--------------------------+
|      PREFIJO ESTÁTICO   |     SUFIIJO DINÁMICO     |
| (Aviso del Sistema,      | (Nueva Consulta del Usuario,|
|  Herramientas, Ejemplos  | Última Ronda de Conversación,|
|  de Pocos Ejemplos,      | etc.)                    |
|  Contexto Inicial)       |                          |
+-------------------------+--------------------------+
          ^
          |
   Punto de Ruptura de Caché Aquí

Implementación de la API de Anthropic (cache_control)

Anthropic utiliza el parámetro cache_control dentro del cuerpo de la solicitud de la API de Mensajes para habilitar y gestionar la caché.

• Habilitación: Incluye un objeto cache_control dentro de uno de los bloques que deseas incluir como el final de tu prefijo que se puede almacenar en caché. Actualmente, el único type soportado es "ephemeral".
• Ubicación: Puedes colocar el bloque cache_control en:
• El mensaje del aviso system.
• Un objeto message específico (turno de usuario o asistente).
• Un bloque de definición de tool (menos común, pero posible).
• Orden de Creación de Caché: El prefijo de caché se construye en función del contenido hasta e incluyendo el bloque marcado con cache_control, siguiendo el orden estándar: tools -> system -> messages.
• Múltiples Puntos de Ruptura: Puedes definir hasta 4 puntos de ruptura de caché en una sola solicitud al agregar cache_control a múltiples bloques. El sistema intentará encontrar el prefijo de caché coincidente más largo basado en estos puntos de ruptura potenciales.

Ejemplo (SDK de Python de Anthropic): Almacenando en Caché un Aviso del Sistema

import anthropic

client = anthropic.Anthropic(api_key="YOUR_API_KEY")

# Primera Solicitud (Escritura en Caché)
response1 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            # Este aviso del sistema es el contenido que queremos almacenar en caché
            "text": "Eres un asistente útil especializado en astrofísica. Tu base de conocimientos incluye detalles extensos sobre evolución estelar, cosmología y ciencia planetaria. Responde con precisión y concisión.",
            "cache_control": {"type": "ephemeral"} # Marcado para almacenamiento en caché
        }
    ],
    messages=[
        {
            "role": "user",
            # Esta es la parte dinámica, no almacenada en el prefijo
            "content": "¿Cuál es el límite de Chandrasekhar?"
        }
    ]
)
print("Primera Respuesta:", response1.content)
print("Uso (Escritura):", response1.usage)
# La salida de uso de ejemplo podría verse así:
# Uso(Escritura): Uso(input_tokens=60, output_tokens=50, cache_creation_input_tokens=60, cache_read_input_tokens=0)

# Solicitud Posterior (Acierto en Caché - dentro del TTL, p.ej., < 5 mins después)
response2 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            # EXACTAMENTE el mismo aviso del sistema que antes
            "text": "Eres un asistente útil especializado en astrofísica. Tu base de conocimientos incluye detalles extensos sobre evolución estelar, cosmología y ciencia planetaria. Responde con precisión y concisión.",
            "cache_control": {"type": "ephemeral"} # Marcado de nuevo
        }
    ],
    messages=[
        {
            "role": "user",
            # Nueva consulta dinámica
            "content": "Explica el concepto de energía oscura."
        }
    ]
)
print("\\\\nSegunda Respuesta:", response2.content)
print("Uso (Acierto):", response2.usage)
# La salida de uso de ejemplo podría verse así:
# Uso(Acierto): Uso(input_tokens=8, output_tokens=75, cache_creation_input_tokens=0, cache_read_input_tokens=60)

En este ejemplo:

1. La primera llamada procesa los 60 tokens del aviso del sistema y los 8 tokens del mensaje del usuario. Almacena en caché el aviso del sistema (cache_creation_input_tokens: 60).
2. La segunda llamada encuentra un acierto en caché para el aviso del sistema idéntico (cache_read_input_tokens: 60). Solo necesita procesar los 8 tokens del nuevo mensaje del usuario como entrada estándar (input_tokens: 8).

Ejemplo (Almacenamiento en Caché Incremental en Conversación):

Para almacenar en caché el historial de la conversación, puedes colocar cache_control en el último mensaje que deseas incluir en la caché para el siguiente turno.

# Turno 1 (Usuario pregunta, Asistente responde - Caché Sistema + Turno 1)
response_turn1 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=500,
    system=[{"type": "text", "text": "Mantén una persona amigable."}], # Caché esto también
    messages=[
        {"role": "user", "content": "¡Hola Claude!"},
        {"role": "assistant", "content": "¡Hola! ¿Cómo puedo ayudarte hoy?", "cache_control": {"type": "ephemeral"}} # Caché hasta aquí
    ]
)
# Pretendamos que el usuario agrega otro mensaje para el Turno 2
# Turno 2 (Acierto en Caché para Sistema + Turno 1, Escritura en Caché para Turno 2)
response_turn2 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=500,
    system=[{"type": "text", "text": "Mantén una persona amigable."}], # Mismo aviso del sistema
    messages=[
        {"role": "user", "content": "¡Hola Claude!"}, # Parte del prefijo almacenado en caché ahora
        {"role": "assistant", "content": "¡Hola! ¿Cómo puedo ayudarte hoy?"}, # Parte del prefijo almacenado en caché ahora
        {"role": "user", "content": "Dime un dato curioso."}, # Nuevo contenido dinámico
        {"role": "assistant", "content": "¿Sabías que la miel nunca se estropea?", "cache_control": {"type": "ephemeral"}} # Caché hasta el final del Turno 2
    ]
)
# El uso del Turno 2 mostraría cache_read_input_tokens para Sistema+Turno1
# y cache_creation_input_tokens para los nuevos mensajes de usuario/asistente del Turno 2

Seguimiento del Rendimiento de la Caché:

La respuesta de la API incluye métricas de uso que revelan cómo se utilizó la caché:

• input_tokens: Número de tokens de entrada no almacenados en caché procesados (el sufijo dinámico).
• output_tokens: Número de tokens generados en la respuesta.
• cache_creation_input_tokens: Número de tokens de entrada procesados y escritos en la caché en esta solicitud (ocurre en un fallo de caché).
• cache_read_input_tokens: Número de tokens de entrada cargados desde la caché en esta solicitud (ocurre en un acierto de caché).

Monitorear estos campos es crucial para entender si tu estrategia de almacenamiento en caché es efectiva. Un alto cache_read_input_tokens en relación con cache_creation_input_tokens a lo largo del tiempo indica un almacenamiento en caché exitoso.

AWS Bedrock:

Para modelos como Anthropic Claude accedidos a través de AWS Bedrock, el mecanismo de almacenamiento en caché generalmente se habilita utilizando el mismo parámetro cache_control dentro del cuerpo de solicitud de invocación del modelo (application/json formato pasado a InvokeModel o InvokeModelWithResponseStream). Debes estructurar el cuerpo JSON de acuerdo a los requisitos específicos del modelo (por ejemplo, el formato de la API de Mensajes de Anthropic) e incluir el campo cache_control como se mostró anteriormente. Consulta la documentación específica de Bedrock para el proveedor de modelo que estás utilizando.

¿Cuál es el Precio para el Almacenamiento en Caché de Solicitudes?

El almacenamiento en caché de solicitudes introduce una estructura de precios más matizada en comparación con los costos estándar de tokens. Aunque es beneficioso en general, es importante entender los diferentes tipos de tokens involucrados:

1. Tokens de Entrada Base: Estos son los tokens de entrada estándar que no son parte de un prefijo almacenado en caché (es decir, el sufijo dinámico en un escenario de acierto de caché, o la totalidad de la solicitud si no se utiliza el almacenamiento en caché o falla). Se cobran a la tarifa estándar de tokens de entrada del modelo.
2. Tokens de Escritura en Caché (cache_creation_input_tokens): Cuando un prefijo se procesa por primera vez (o después de un fallo de caché) y se escribe en la caché, los tokens asociados con ese prefijo a menudo se cobran a una tarifa premium. Por ejemplo, Anthropic cobra un 25% más que la tarifa estándar de tokens de entrada por las escrituras en caché. Esto refleja el costo tanto del procesamiento como del almacenamiento de la entrada de caché.
3. Tokens de Lectura en Caché / Tokens de Acierto en Caché (cache_read_input_tokens): Cuando ocurre un acierto en caché, los tokens correspondientes al prefijo cargados desde la caché se cobran a una tarifa significativamente descontada. Por ejemplo, Anthropic cobra solo el 10% de la tarifa estándar de tokens de entrada (un 90% de descuento) por las lecturas en caché. Esto refleja los ahorros computacionales.
4. Tokens de Salida: Los tokens generados por el LLM en respuesta se cobran a la tarifa estándar de tokens de salida del modelo, independientemente de si se utilizó almacenamiento en caché para la entrada.

Tabla de Precios de Ejemplo (Modelos Anthropic Claude - tarifas ilustrativas):

(Nota: Siempre consulta las páginas de precios oficiales de Anthropic y AWS Bedrock para las tarifas más actuales.)

La rentabilidad depende en gran medida de cuántos aciertos de caché obtienes frente a fallos para un prefijo determinado. Si un gran prefijo se reutiliza muchas veces, el costo inicial más alto de la escritura en caché se compensa rápidamente con los ahorros sustanciales de las lecturas en caché posteriores.

Limitaciones del Almacenamiento en Caché de Solicitudes

Aunque es poderoso, el almacenamiento en caché de solicitudes tiene limitaciones y factores a considerar:

Longitud Mínima Almacenable en Caché: Los modelos a menudo tienen un requisito mínimo de tokens para que un prefijo sea elegible para almacenamiento en caché. Las solicitudes más cortas que este límite no pueden almacenarse en caché, incluso si están marcadas con cache_control.

• Anthropic Claude 3.7/3.5 Sonnet & Opus: Mínimo 1024 tokens.
• Anthropic Claude 3.5/3 Haiku: Mínimo 2048 tokens.

Invalidación de Caché (Ruptura de Caché): La caché es extremadamente sensible a los cambios en el prefijo. Cualquier modificación romperá la caché y forzará una nueva escritura:

• Cambiar cualquier contenido de texto dentro de los bloques system, tools o messages designados como parte del prefijo.
• Cambiar el orden o número de definiciones de tool.
• Cambiar parámetros de tool_choice (por ejemplo, cambiar de auto a una herramienta específica).
• Agregar, eliminar o cambiar imágenes dentro de la solicitud (para modelos multimodales).
• Alterar otros parámetros del modelo que afectan el procesamiento inicial también puede romper la caché (por ejemplo, la configuración de pensamiento extendido de Anthropic puede invalidar las cachés de mensajes).

Vida Útil de la Caché (TTL): Recuerda que la caché es efímera (por ejemplo, mínimo de 5 minutos de TTL para Anthropic, refrescada en uso). Los prefijos que no se reutilizan dentro del TTL expiran. Actualmente, no hay forma de limpiar manualmente o extender la caché más allá de su comportamiento automático.

Concurrencia: Si envías muchas solicitudes idénticas de forma concurrente dirigidas a un prefijo antes de que la primera solicitud haya terminado y escrito la entrada en la caché, las solicitudes posteriores pueden resultar en fallos de caché hasta que la primera escritura se complete. Para garantizar aciertos en escenarios paralelos, es posible que debas esperar la primera respuesta antes de enviar otras.

Modelos Soportados: El almacenamiento en caché de solicitudes no está disponible universalmente en todos los modelos o proveedores. Siempre consulta la documentación para el modelo específico que pretendes utilizar. (Actualmente confirmado para varios modelos Claude 3 y 3.5).

Depuración: Identificar cambios sutiles que causan fallos de caché a veces puede ser complicado. Es necesario comparar cuidadosamente el contenido exacto del prefijo entre las llamadas.

Mejores Prácticas para un Almacenamiento en Caché Efectivo

Para maximizar los beneficios del almacenamiento en caché de solicitudes:

1. Estructura las Solicitudes de Manera Inteligente: Coloca la información más estable y reutilizable (avisos del sistema, instrucciones, definiciones de herramientas, documentos de contexto, ejemplos de pocos disparos) al principio de tu secuencia de solicitudes. Coloca la información dinámica y que cambia con frecuencia (consultas de usuarios, últimas rondas de conversación) después del punto de ruptura de caché.
2. Identifica Puntos de Ruptura Óptimos: Usa cache_control (o el mecanismo equivalente) de manera deliberada. Marca el final del bloque más grande posible de contenido realmente estático. Si utilizas múltiples puntos de ruptura (como permite Anthropic), considera diferentes niveles de estabilidad en la estructura de tu solicitud.
3. Monitorea el Uso de la Caché: Revisa regularmente el cache_creation_input_tokens y el cache_read_input_tokens en tus respuestas de API. Aspira a una alta relación de lecturas a escrituras a lo largo del tiempo. Si ves principalmente escrituras, tus prefijos pueden estar cambiando con demasiada frecuencia o pueden estar por debajo de la longitud mínima almacenable en caché.
4. Evita Cambios Innecesarios: Ten en cuenta que incluso cambios pequeños y aparentemente insignificantes en el contenido del prefijo (como agregar un espacio o cambiar la puntuación) romperán la caché. Asegúrate de la consistencia en cómo se generan los prefijos.
5. Considera los Trade-offs de Costos: El almacenamiento en caché es más efectivo para prefijos largos y reutilizados frecuentemente. No almacenes en caché prefijos muy cortos, ya que los ahorros potenciales son mínimos y pueden no compensar la complejidad. Evita almacenar en caché entradas de usuario altamente variables.
6. Prueba e Itera: Experimenta con diferentes estructuras de solicitudes y puntos de ruptura de caché para encontrar la estrategia óptima para la carga de trabajo y patrones de uso específicos de tu aplicación.

Conclusión

El almacenamiento en caché de solicitudes es una técnica de optimización vital para cualquier persona que esté construyendo aplicaciones sobre modelos de lenguaje grande. Al almacenar y reutilizar de manera inteligente el estado computacional de los prefijos de solicitudes estáticas, aborda directamente los desafíos de latencia y costos asociados con solicitudes largas o repetitivas. Comprender cómo funciona el almacenamiento en caché, sus detalles de implementación específicos para tu proveedor de LLM elegido (como el cache_control de Anthropic), las matices de precios asociadas y sus limitaciones te permite diseñar aplicaciones de IA más eficientes, responsivas y económicas. A medida que los casos de uso de LLM crecen en complejidad y escala, aprovechar características como el almacenamiento en caché de solicitudes será cada vez más crucial para construir soluciones sostenibles y de alto rendimiento.