Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Almacenamiento en caché de peticiones para una inferencia de modelos más rápida

El almacenamiento en caché de peticiones es una característica opcional que puede utilizar con los modelos compatibles en Amazon Bedrock para reducir la latencia de la respuesta de inferencia y los costos de los tokens de entrada. Al agregar partes de su contexto a una caché, el modelo puede usar la caché para omitir el recálculo de las entradas, lo que permite a Bedrock compartir los ahorros de cómputo y reducir las latencias de respuesta.

El almacenamiento en caché de peticiones puede ser útil cuando tiene cargas de trabajo con contextos largos y repetitivos que se reutilizan con frecuencia para múltiples consultas. Por ejemplo, si tiene un chatbot en el que los usuarios pueden cargar documentos y hacer preguntas sobre ellos, el modelo puede tardar mucho tiempo en procesar el documento cada vez que el usuario proporciona información. Con el almacenamiento en caché de peticiones, puede almacenar en caché el documento para que las futuras consultas que contengan el documento no tengan que volver a procesarlo.

Al utilizar el almacenamiento en caché de peticiones, se le cobrará una tarifa reducida por los tokens leídos desde la memoria caché. Según el modelo, los tokens escritos en la memoria caché pueden cobrarse a una tarifa superior a la de los tokens de entrada no almacenados en caché. Los tokens que no se lean o escriban en la memoria caché se cobran según la tarifa de token estándar de ese modelo. Para obtener más información, consulte la página de Precios de Amazon Bedrock.

Funcionamiento

Si decide utilizar el almacenamiento en caché de peticiones, Amazon Bedrock crea una caché compuesta por puntos de control de caché. Son marcadores que definen la subsección contigua de la petición que desea almacenar en caché (lo que suele denominarse “prefijo de petición”). Estos prefijos de petición deben ser estáticos entre las solicitudes; si se modifica el prefijo de petición en solicitudes posteriores, se producirá una pérdida de memoria caché.

Los puntos de control de caché tienen un número mínimo y máximo de tokens, según el modelo específico que utilice. Solo puede crear un punto de control de caché si el prefijo de petición total cumple con el número mínimo de tokens. Por ejemplo, Claude 3.7 Sonnet requiere al menos 1024 fichas por punto de control de caché, mientras que, Claude Opus 4.5 Claude Opus 4.6Claude Haiku 4.5, y Claude Sonnet 4.5 requiere al menos 4096 fichas por punto de control de caché. Esto significa que, para un modelo con un mínimo de 1024 fichas, el primer punto de control de la memoria caché se puede definir después de 1024 fichas y el segundo punto de control de la memoria caché se puede definir después de las 2048 fichas. Si intenta añadir un punto de control de caché antes de alcanzar el número mínimo de tokens, la inferencia se seguirá realizando correctamente, pero el prefijo no se almacenará en caché. La caché tiene un tiempo de vida útil (TTL), que se restablece cada vez que se accede a ella correctamente. Durante este período, se conserva el contexto de la memoria caché. Si no se realiza ningún acceso a la caché en la ventana TTL, la caché caduca. Muchos modelos admiten un TTL de 5 minutos. Compruebe la tarjeta de modelo de su modelo para ver las condiciones exactas del TTL.

Puede utilizar el almacenamiento en caché de peticiones cada vez que obtenga inferencia de modelos en Amazon Bedrock para los modelos compatibles. Las siguientes características de Amazon Bedrock admiten el almacenamiento en caché de peticiones:

Las API le proporcionan la mayor flexibilidad y un control detallado sobre la caché de peticiones. Puede establecer un punto de control de caché individual dentro de sus peticiones. Puede añadirlo a la caché creando más puntos de control de caché, hasta el número máximo de puntos de control de caché permitido para el modelo específico. Para obtener más información, consulte Modelos y regiones compatibles, y límites.

Modelos y regiones compatibles, y límites

El almacenamiento rápido en caché está disponible en todas AWS las regiones en las que están disponibles los modelos compatibles. Para comprobar la disponibilidad de los modelos por región, consulteDisponibilidad regional por modelos.

En la siguiente tabla se muestran los modelos compatibles junto con su número mínimo de tokens, número máximo de puntos de control de caché y los campos que permiten puntos de control de caché.

Para ver qué modelos admiten el almacenamiento rápido en caché, consulte la sección Modelos de un vistazo y, a continuación, elija el modelo que le interese. En la siguiente tabla se muestra el almacenamiento rápido en caché de los modelos que no están presentes en Models-at-a-Glance.

Para usar la opción TTL de 1 hora con los modelos compatibles (Claude Opus4.5, yClaude Sonnet 4.5)Claude Haiku 4.5, especifica el ttl campo en el punto de control de la caché. En la API de Converse, "ttl": "1h" añádelo a tu objeto. cachePoint En la InvokeModel API para los modelos Claude, añade algo "ttl": "1h" a tu cache_control objeto. Si no se proporciona ningún ttl valor, se aplica el comportamiento de almacenamiento en caché predeterminado de 5 minutos. El TTL de 1 hora es útil para sesiones de larga duración o escenarios de procesamiento por lotes en los que desee mantener la caché durante períodos prolongados.

Amazon Nova ofrece un almacenamiento en caché de peticiones automático para todas las peticiones de texto, incluidos los mensajes User y System. Este mecanismo puede proporcionar beneficios de latencia cuando las peticiones comienzan con partes repetitivas, incluso sin una configuración explícita. Sin embargo, para ahorrar costos y garantizar beneficios de rendimiento más sistemáticos, recomendamos optar por el almacenamiento en caché de peticiones explícito.

Gestión de caché para modelos de Anthropic

Para los modelos Claude, Amazon Bedrock ofrece un enfoque simplificado de administración de la memoria caché que reduce la complejidad de colocar manualmente los puntos de control de caché. En lugar de tener que especificar las ubicaciones exactas de los puntos de control de caché, puede utilizar la administración automática de caché con un único punto de interrupción al final del contenido estático.

Al habilitar la administración simplificada de la memoria caché, el sistema comprueba automáticamente si se ha accedido a la memoria caché en los límites de los bloques de contenido anteriores y analiza hasta aproximadamente 20 bloques de contenido desde el punto de interrupción especificado. Esto permite que el modelo encuentre el prefijo coincidente más largo de la caché sin necesidad de que usted prediga las ubicaciones óptimas de los puntos de control. Para usarlo, coloque un único punto de control de caché al final del contenido estático, antes de cualquier contenido dinámico o variable. El sistema encontrará automáticamente la mejor coincidencia en la caché.

Para un control más detallado, puede seguir utilizando varios puntos de control de caché (hasta cuatro para los modelos Claude) para especificar los límites exactos de la caché. Debe utilizar varios puntos de control de caché si almacena en caché secciones que cambian con diferentes frecuencias o si desea tener más control sobre qué es exactamente lo que se almacena en caché.

Mejores prácticas para utilizar la gestión de caché en modelos antrópicos

Si tiene mensajes que se utilizan con una cadencia normal (es decir, mensajes del sistema que se utilizan con más frecuencia que cada 5 minutos), siga utilizando la memoria caché de 5 minutos, ya que se seguirá actualizando sin coste adicional.

La memoria caché de 1 hora se utiliza mejor en los siguientes escenarios:

Puedes usar controles de caché de 1 hora y 5 minutos en la misma solicitud, pero con una restricción importante: las entradas de caché con TTL más largos deben aparecer antes que los TTL más cortos (es decir, una entrada de caché de 1 hora debe aparecer antes que cualquier entrada de caché de 5 minutos).

Gestión de caché para modelos de OpenAI

Los modelos OpenAI de Amazon Bedrock admiten el almacenamiento rápido en caché a través de la API de respuestas en el punto final. bedrock-mantle El comportamiento del almacenamiento en caché varía según la generación del modelo.

GPT-5.6 modelos

GPT-5.6 Sol (openai.gpt-5.6-sol), Terra (openai.gpt-5.6-terra) y Luna (openai.gpt-5.6-luna) introducen puntos de interrupción explícitos en la caché de solicitudes, lo que le permite controlar con precisión qué partes de la solicitud se almacenan en caché. Esto resulta especialmente útil para los flujos de trabajo de los agentes, en los que las instrucciones del sistema, las definiciones de las herramientas y los archivos de referencia se repiten en muchas llamadas y solo cambian las entradas más recientes.

Características clave:

Interpretación de la respuesta

El objeto de uso de la respuesta incluye dos campos específicos de la memoria caché:

Si cached_tokens es mayor que cero y cache_write_tokens igual a cero, la solicitud coincidió totalmente con una entrada de caché existente: no se produjeron nuevas escrituras y usted obtuvo el máximo ahorro de costes.

Mejores prácticas para usar la administración de caché en los modelos GPT 5.6

GPT-5.5 y modelos anteriores

Para los modelos OpenAI anteriores a GPT-5.6 (como openai.gpt-5.5 yopenai.gpt-5.4), el almacenamiento rápido en caché es automático. No es necesario añadir ningún parámetro especial: el sistema almacena automáticamente en caché los prefijos de texto aptos de 1.024 fichas o más. La escritura en caché no conlleva ningún coste adicional en estos modelos.

Características clave:

Mejores prácticas para usar la administración de caché en modelos anteriores GPT-5.5

Introducción

En las siguientes secciones se muestra una breve descripción de cómo utilizar la característica de almacenamiento en caché de peticiones para cada método de interacción con los modelos a través de Amazon Bedrock.