Reducir costos y latencia en Amazon Bedrock con prompt caching

Por qué importa el prompt caching

Enviar la misma información de contexto repetidamente a los modelos fundacionales puede inflar los costos de entrada y aumentar la latencia. Amazon Bedrock ofrece prompt caching para guardar un estado parcial del procesamiento de entrada y reutilizarlo en solicitudes posteriores. En muchos escenarios esto puede reducir los costos de los tokens de entrada hasta en 90% cuando hay coincidencias en cache (cache hits), sin sacrificar la calidad del modelo o del prompt.

Para una audiencia empresarial y de producto en América Latina esto es especialmente relevante: aplicaciones con documentos grandes, asistentes que consultan una base de código o flujos RAG (Retrieval Augmented Generation) que repiten el mismo contexto son candidatos claros para ahorrar dinero y mejorar la experiencia del usuario.

Beneficios clave

• Reducción de costos de tokens de entrada hasta en 90% por lectura de cache (cache read).
• Mejora en el tiempo hasta el primer token (TTFT), porque el modelo puede retomar generación desde un estado cacheado.
• Conservación de la calidad del prompt y del contexto: no es necesario recortar prompts ni limitar ventanas de contexto para ahorrar.
• Flexibilidad operativa: control de caducidad (TTL) por punto de cache para equilibrar frescura y ahorro.

Cómo funciona (visión general técnica)

La funcionalidad se activa incluyendo un marcador cachePoint en la solicitud a la API Converse de Amazon Bedrock. Bedrock evalúa si el contenido que precede al marcador coincide con una entrada existente en la cache:

• Si hay cache hit, el modelo salta el reprocesamiento de esos tokens y continúa la generación desde el estado guardado.
• Si hay cache miss, el modelo procesa el contenido completo y escribe un snapshot en la cache para futuras peticiones.

Cuatro conceptos determinan el comportamiento real:

• Alcance de cache: las entradas se limitan por cuenta AWS y región.
• Umbrales de tokens: cada checkpoint debe superar un mínimo de tokens para activarse (por ejemplo, Anthropic Claude Sonnet 4.5 y 4.6 requieren 1,024 tokens, Opus requiere 4,096).
• TTL (time-to-live): las entradas expiran según el TTL pedido; por defecto 5 minutos, con algunos modelos que permiten hasta 1 hora.
• Sintaxis consistente: la sintaxis cachePoint en la API Converse es la misma entre familias de modelos soportadas, como Anthropic y Amazon Nova.

Impacto en costos y modelo de precios

Prompt caching introduce dos categorías adicionales de tokens respecto a los tokens de entrada y salida standard:

• cacheWriteInputTokens: tokens escritos a cache en la primera solicitud. Su costo es 25% mayor que el input estándar (1.25x).
• cacheReadInputTokens: tokens leídos desde cache en solicitudes posteriores. Su costo es 90% menor que el input estándar (0.1x).
• cacheWriteInputTokens (1-hour TTL): escritura de cache con TTL de 1 hora tiene un costo 100% mayor (2x) sobre el input estándar.

En cargas de trabajo donde hay contexto repetido, los ahorros en costos de entrada pueden llegar a un ~75% en el ejemplo clásico: un documento de 10,000 tokens preguntado 10 veces. La primera petición hace una escritura a cache; las siguientes nueve leen de cache a precio reducido, suponiendo que ocurren dentro del TTL.

Es importante recordar que solicitudes fuera del TTL provocarán una nueva escritura a cache y reducirán los ahorros netos.

Seis escenarios prácticos de uso

A continuación describo patrones de aplicación desde lo más común hasta integraciones más avanzadas, basados en los ejemplos y capacidades que ofrece Bedrock.

1) Cache de contenido de mensajes

Ideal para documentos largos que se consultan repetidamente (RAG, manuales, especificaciones de producto, bases de código). Coloquen un cachePoint entre el documento estático y las preguntas dinámicas. La cache evita re-enviar todo el texto para cada consulta.

Ventaja: ahorros directos y respuesta más rápida.

2) Cache de system prompts

Para asistentes con una personalidad, instrucciones o configuraciones globales, guarden el system prompt en cache. Esto reduce reprocesamiento cuando múltiples conversaciones comparten las mismas instrucciones base.

Ventaja: coherencia de comportamiento sin costo recurrente por tokens.

3) Cache de definiciones de herramientas

En flujos agentic o con herramientas (tool schemas), las definiciones de herramientas suelen ser estáticas. Al cachearlas, las invocaciones sucesivas de agentes evitan reprocesar esos esquemas.

Ventaja: mejora en latencia y menores costos en arquitecturas server-driven.

4) Cache con TTL mixto

No todo el contexto tiene la misma caducidad. Asignen TTLs distintos a capas: documentos que cambian con baja frecuencia pueden tener TTL largos; prompts o datos sensibles pueden usar TTLs cortos. La API permite especificar ttl en cachePoint (nota: para usar ttl se requiere boto3 >= 1.43.0).

Ventaja: balance entre frescura y ahorro.

5) Aislamiento por tenant

En aplicaciones multi-tenant, implementen separación de cache por inquilino para evitar fugas de datos entre clientes y facilitar control de TTL/costos por cliente.

Ventaja: seguridad y control financiero por cuenta/cliente.

6) Integración con LangChain

Si usan LangChain, Bedrock permite integrar prompt caching en los flujos del framework. Esto facilita incorporar la cache en pipelines existentes sin rediseñar la aplicación.

Ventaja: adopción rápida en stacks que ya usan LangChain.

Consideraciones prácticas y recomendaciones

• Evalúen qué partes del contexto son realmente repetidas: cacheen documentos largos, instrucciones y esquemas de herramientas, no contenido que cambia por usuario.
• Ajusten TTL según patrones de uso y sensibilidad de la información. TTL por defecto es 5 minutos; algunos modelos admiten hasta 1 hora.
• Revisen los umbrales mínimos de tokens por checkpoint para el modelo elegido (p. ej. Sonnet 4.5/4.6: 1,024 tokens; Opus: 4,096 tokens).
• Monitoricen cache hits vs misses: los beneficios dependen de la tasa de aciertos dentro del TTL. En workloads distribuidos entre regiones, la frecuencia de escrituras puede aumentar por routing cross-region.
• Para pruebas y despliegue, aseguren acceso al modelo desde la cuenta y región apropiada (el ejemplo usa Anthropic Claude Sonnet 4.5) y tengan boto3 actualizado si usan parámetros de ttl.

Conclusión

El prompt caching en Amazon Bedrock es una herramienta poderosa para reducir costos de token y mejorar latencia en aplicaciones con contexto repetido, sin sacrificar la riqueza del prompt. Para equipos en América Latina que construyen asistentes, RAG, agentes o integraciones con LangChain, incorporar caching a nivel de infraestructura puede traducirse en ahorros operativos sustanciales y una experiencia de usuario más ágil. Evalúen patrones de uso, definan TTLs apropiados y monitoreen la tasa de hits para maximizar los beneficios.