Caché de Bedrock: hasta un 90% si el prefijo no cambia

Para aprovechar la caché de prompts de Amazon Bedrock, coloca primero el contenido que se repite —instrucciones, herramientas y documentos—, marca después el límite de la caché y deja al final la pregunta o los datos variables. Las llamadas posteriores solo pueden reutilizar la parte almacenada si conservan el mismo prefijo y la entrada no ha caducado.

El ahorro del 90% es un máximo, no una previsión para cualquier carga. La página de prompt caching de Amazon Bedrock cifra la reducción potencial en hasta un 90% de coste y un 85% de latencia para modelos compatibles; el resultado real depende de cuánto contexto se reutiliza, cuántas llamadas aciertan y qué tarifas se aplican a escrituras y lecturas.

Construir un prefijo que pueda reutilizarse

Ordena la solicitud de lo más estable a lo más variable. Las definiciones de herramientas, las instrucciones del sistema y el contexto documental compartido deben preceder al punto de caché; la petición actual, los resultados de herramientas y el estado específico del turno deben aparecer después.

En un chat documental, el documento y las reglas de respuesta pueden formar el prefijo, mientras cada pregunta queda en la parte variable. En un agente, el bloque reutilizable puede contener las instrucciones permanentes y los esquemas de herramientas, pero no resultados recién obtenidos ni identificadores de la ejecución actual.

Evita introducir antes del límite marcas de tiempo, identificadores de petición, datos personalizados u objetos serializados en un orden inestable. La coincidencia depende tanto del contenido como de su posición: modificar una sección temprana puede invalidar las posteriores aunque el documento principal no haya cambiado.

Elegir caché implícita o explícita

La caché implícita intenta encontrar automáticamente prefijos aptos, sin que la solicitud incluya puntos de control. Es una operación de esfuerzo razonable: repetir una entrada idéntica no garantiza un acierto. La caché explícita permite señalar el final del contenido reutilizable, pero tampoco convierte toda solicitud apta en un acierto asegurado.

La documentación de modelos y límites de Bedrock muestra que el mecanismo, la API, el mínimo de tokens, el número de puntos y el TTL dependen del modelo. GPT-5.6 Sol, Terra y Luna admiten puntos explícitos desde 1.024 tokens mediante Responses API y un TTL predeterminado de 30 minutos; en la familia Claude, los mínimos y la compatibilidad con cinco minutos o una hora varían según la versión. Amazon Nova ofrece caché implícita para prompts de texto y algunos modelos también permiten control explícito.

No reutilices sin comprobarlo un ejemplo de una familia de modelos en otra. En Converse API, los modelos compatibles expresan el límite mediante un bloque cachePoint; GPT-5.6 utiliza prompt_cache_breakpoint en Responses API. Si el prefijo no alcanza el mínimo del modelo, la inferencia puede completarse, pero el contenido no se almacena.

Colocar los puntos y ajustar el TTL

Empieza con un único punto inmediatamente después del bloque estático. Añade otros solo cuando existan capas con ritmos de cambio distintos, por ejemplo herramientas comunes para toda la aplicación, instrucciones de un cliente y un documento de sesión. Separarlas permite conservar la parte más estable cuando cambia una capa posterior.

El TTL debe cubrir el intervalo habitual entre llamadas, no el máximo imaginable. Cinco minutos pueden bastar para una ráfaga de consultas; una hora resulta útil cuando una persona o un agente tarda más en enviar la siguiente petición, aunque la escritura prolongada puede costar más. Cada acierto renueva la vigencia y, tras una pausa superior al TTL, la llamada siguiente puede generar otra escritura.

En inferencia entre regiones, el enrutamiento puede aumentar las escrituras. Por eso conviene segmentar las mediciones por aplicación, cuenta, región, modelo, TTL y versión del prefijo en vez de mezclar toda la carga en una sola tasa de aciertos.

Calcular cuándo compensa

Para un prefijo de T tokens usado en N solicitudes, llama P a la tarifa normal de entrada, W a la tarifa de escritura y R a la de lectura. Sin caché, el coste comparable del prefijo es N × T × P. Con una escritura inicial y N−1 aciertos, es T × W + (N−1) × T × R.

La caché ahorra cuando N es mayor que (W−R) ÷ (P−R), siempre que P sea superior a R. Esta fórmula presupone una sola escritura, aciertos completos y ausencia de expiraciones; si el prefijo cambia o caduca, hay que sumar las nuevas escrituras.

El ejemplo técnico de AWS compara una escritura de cinco minutos a 1,25 veces la tarifa normal, una lectura a 0,1 veces y una escritura de una hora a 2 veces. Con esos valores, la opción de cinco minutos compensa desde la segunda solicitud total y la de una hora desde la tercera, si todas las llamadas posteriores aciertan antes de caducar. Es un ejemplo aritmético: el cálculo de producción debe usar las tarifas del modelo y del TTL elegidos.

Medir lecturas, escrituras y latencia

Registra por solicitud los tokens normales de entrada, los escritos y los leídos desde caché. En Converse API, inputTokens representa la entrada no almacenada; el total se obtiene sumándolo a cacheWriteInputTokens y cacheReadInputTokens. En Responses API cambian los nombres de los campos, por lo que la instrumentación debe adaptarse a la interfaz usada.

Tasa de aciertos: solicitudes con lecturas de caché frente a solicitudes aptas.
Relación lectura/escritura: tokens leídos divididos por tokens escritos; un valor bajo puede indicar expiraciones o prefijos inestables.
Proporción reutilizada: tokens leídos frente a la entrada total, porque un acierto pequeño puede aportar poco ahorro.
Coste efectivo: entrada normal, escrituras y lecturas valoradas con sus tarifas respectivas.
Latencia: distribución del tiempo hasta el primer token y de la duración total, no solo sus promedios.

Una prueba mínima comienza con una llamada que escriba el prefijo y continúa con varias preguntas distintas que mantengan intacta la parte anterior al punto de caché. La presencia de un punto de control no demuestra un acierto: la decisión debe basarse en los contadores de uso y en suficientes lecturas para amortizar las escrituras dentro del TTL real.

La caché de Bedrock ahorra hasta un 90%, si el prefijo no cambia