Amazon Bedrock ahora ofrece caché de prompts para Claude 4.6, una función que puede reducir la latencia de respuesta y el gasto de inferencia para aplicaciones de IA generativa. La capacidad funciona recordando una porción estática de un prompt durante hasta cinco minutos, de modo que las llamadas posteriores omiten el costoso reprocesamiento de ese texto.

Cómo se integra el caché en la cadena de solicitudes

Cuando llega una solicitud de Claude 4.6, cooperan dos capas.

  • Nivel de modelo – Claude 4.6 mantiene un caché de clave-valor (KV) en la memoria de la GPU. La primera vez que el modelo analiza un bloque de instrucciones, almacena la representación interna resultante. En llamadas posteriores que reutilizan el mismo bloque, el modelo puede recuperar la representación en lugar de volver a calcularla.

  • Nivel de Bedrock – Bedrock calcula una huella digital (fingerprint) del segmento estático del prompt. Si una nueva solicitud tiene una huella digital coincidente, Bedrock la dirige directamente a la GPU que ya contiene el estado en caché, omitiendo la etapa de "calentamiento" (warm-up).

Piénselo como cargar una partida guardada en lugar de empezar una nueva cada vez.

Reglas para mantener vivo el caché

  1. Recuento mínimo de tokens – Claude Sonnet 4.6 requiere al menos 1,024 tokens en el segmento en caché; Claude Opus 4.6 necesita 4,096 tokens. Cualquier cantidad menor será ignorada.

  2. Vida útil de cinco minutos – El caché expira tras cinco minutos de inactividad. Cada acierto (hit) reinicia el temporizador, por lo que un flujo constante de llamadas puede mantener el caché vivo indefinidamente.

  3. Orden de los prompts – Bedrock lee el prompt de forma secuencial. Las instrucciones estáticas deben aparecer primero, seguidas de un marcador cachePoint, con todos los mensajes generados por el usuario después de dicho marcador. Cambiar incluso un solo carácter antes del marcador rompe la huella digital y obliga a una lectura en frío (cold read).

Poniendo la función en práctica

La API Bedrock Converse es el punto de entrada. A continuación, se muestra un fragmento de código Python mínimo que demuestra la estructura requerida.

import boto3

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
MODEL_ID = "anthropic.claude-sonnet-4-6"

# Must be >1,024 tokens for Sonnet
BASE_SYSTEM_PROMPT = "Your long instructions here..."

system_configuration = [
    {"text": BASE_SYSTEM_PROMPT},
    {"cachePoint": {"type": "default"}}
]

conversation_history = []

def run_chat_turn(user_input):
    global conversation_history
    conversation_history.append(
        {"role": "user", "content": [{"text": user_input}]}
    )

    response = bedrock.converse(
        modelId=MODEL_ID,
        system=system_configuration,
        messages=conversation_history,
        inferenceConfig={"maxTokens": 500, "temperature": 0.4}
    )

    assistant_message = response["output"]["message"]
    conversation_history.append(assistant_message)

    metrics = response["usage"]
    print(f"Read from cache: {metrics.get('cacheReadInputTokens', 0)}")

El cachePoint le indica a Bedrock dónde termina el segmento inmutable. Después de la primera llamada, la métrica cacheReadInputTokens debería mostrar un valor distinto de cero, confirmando que se utilizó el caché.

Por qué esto debería importarles a los desarrolladores

Separar las instrucciones estáticas de la entrada dinámica del usuario traslada el trabajo de costosos ciclos de GPU a un paso de enrutamiento ligero. Para chatbots, pipelines de generación aumentada por recuperación (RAG) o cualquier servicio que repita el mismo prompt de sistema, el resultado son respuestas más rápidas y recuentos de tokens facturables más bajos. En escenarios de alto rendimiento, incluso una reducción modesta en el tiempo de cómputo puede traducirse en ahorros de costos notables.

Límites y compensaciones

La función solo ayuda cuando el segmento del prompt cumple con los mínimos de tokens y permanece sin cambios. Las aplicaciones que modifican con frecuencia las instrucciones del sistema, o que dependen de prompts cortos, verán pocos beneficios. La ventana de cinco minutos también significa que el tráfico por ráfagas con largos periodos de inactividad puede incurrir repetidamente en lecturas en frío, erosionando la ventaja de latencia. Finalmente, el caché reside en la memoria de la GPU; si múltiples modelos comparten el mismo hardware, la contención podría afectar el rendimiento, aunque Bedrock no expone esos detalles.

Qué observar a continuación

  • Paneles de métricas – Esté atento a cacheReadInputTokens y a la latencia general para verificar que el caché se esté utilizando según lo previsto.
  • Ingeniería de prompts – Diseñar prompts que satisfagan los umbrales de tamaño sin inflar la solicitud es una nueva disciplina para los desarrolladores.
  • Extensiones futuras – Si Bedrock amplía la duración del caché o relaja los límites de tokens, la economía de las conversaciones de larga duración podría cambiar aún más.

Conclusión: El caché de prompts ofrece a los usuarios de Claude 4.6 una palanca concreta para recortar tanto el tiempo de respuesta como el gasto, siempre que puedan asegurar un prompt lo suficientemente grande e inmutable y mantener las llamadas dentro de un intervalo corto. Para cualquier servicio de GenAI que repita las mismas instrucciones de sistema, vale la pena probar la función pronto.