Skip to content

AWS rediseña Bedrock AgentCore para reducir el costo de memoria inactiva y los retrasos de arranque en frío

Respuesta corta

AWS lanzó una nueva versión del runtime de Bedrock AgentCore que libera la memoria en cuanto una sesión de agente deja de usarla, en vez de cobrar por el pico de uso durante toda la sesión, y mantiene la latencia de arranque en frío cerca de 2 segundos sin importar el tamaño del contenedor, frente a hasta 30 segundos en el runtime anterior.

Qué significa para las operaciones

Si tus agentes de soporte o ventas corren sobre Bedrock AgentCore, esto cambia dos cifras que sí importan: la factura de AWS y cuánto espera un cliente cuando un agente inactivo vuelve a activarse. Antes, un agente de larga duración o con picos de uso seguía pagando por su pico de memoria durante toda la sesión, y los arranques en frío empeoraban a medida que crecía la imagen del contenedor o la concurrencia — un problema real para agentes que están callados la mayor parte del día y se disparan en horario laboral. El nuevo runtime factura más cerca del uso real y mantiene los arranques en frío estables en unos 2 segundos sin importar el tamaño de la imagen, así que los equipos que corren varios agentes (un clasificador de soporte, un bot de calificación de leads, un asistente interno de operaciones) pueden dejarlos escalados a cero entre solicitudes sin la penalización de latencia anterior cuando un cliente o un representante los activa en frío. Es un cambio de infraestructura, no una capacidad nueva, pero reduce el costo operativo de exactamente el patrón que usan la mayoría de las empresas de 10 a 200 personas: varios agentes especializados que están mayormente inactivos.

AWS anunció una nueva versión del runtime detrás de Amazon Bedrock AgentCore, la capa de cómputo administrada que usan los equipos para desplegar y operar agentes de IA sin gestionar su propia infraestructura.

El cambio apunta a dos costos que aparecen cuando los agentes pasan de intercambios cortos de chat a trabajo de producción de mayor duración y a menudo inactivo. Primero, la memoria: el runtime original mantenía asignada la memoria pico de una sesión hasta que esta terminaba, incluso después de que el agente dejara de usarla, así que los agentes con picos o de larga duración pagaban por su punto máximo durante todo el tiempo que corrían. El nuevo runtime inicia cada sesión con una huella de memoria pequeña y va incorporando más solo cuando la carga de trabajo lo requiere, liberando memoria una vez que se enfría. AWS indica que la facturación ahora sigue ese uso liberado en lugar del pico.

Segundo, los arranques en frío: antes, poner en marcha un entorno nuevo se volvía más lento cuanto mayor era el tamaño de la imagen del contenedor o la concurrencia. Las propias pruebas de AWS —5.000 invocaciones en frío por agente en cinco tamaños de imagen, usando un agente eco vacío que no llama a ningún modelo ni herramienta— encontraron que la latencia P75 de arranque en frío del runtime original subía de unos 5,4 segundos a casi 30 segundos a medida que aumentaba el tamaño de la imagen. El nuevo runtime prepara y toma una instantánea del entorno una sola vez, y luego restaura esa instantánea para cada instancia nueva, manteniendo la latencia P75 de arranque en frío en aproximadamente 2 segundos desde una imagen de 200 MB hasta una de 2 GB, sin importar el tamaño de la imagen.

AWS describe el efecto neto como una tarifa por unidad más alta pero muchas menos GB-hora facturadas, con la factura total bajando para la mayoría de los agentes porque la huella de memoria se reduce más de lo que sube la tarifa.

Para usar el nuevo runtime, los desarrolladores configuran el parámetro platformVersion en V2 al crear o actualizar un runtime. AWS también listó varias funciones que llegarán próximamente: precios con línea base comprometida (reservando un piso de memoria y permitiendo picos por encima), opciones más grandes de cómputo y almacenamiento, soporte para microVM x86, suspensión y reanudación de sesiones con instantáneas de memoria, e identidad con alcance limitado para agentes desatendidos mediante claves de contexto de sesión, pensada para limitar lo que un agente puede hacer cuando corre sin supervisión humana.

Fuente: AWS Machine Learning Blog

Siguiente paso

Visibility Analyzer

Esto es lo que el Visibility Analyzer mide en un sitio real: qué respuestas te citan, qué páginas el motor no puede recuperar y qué arreglar primero. Ejecutarlo es gratis.

Lanzar una auditoría de visibilidad gratuita

Lanzarlo es gratis. Sin tarjeta.

Precio
Gratis
Duración
Una ejecución, minutos

Plan gratuito: dos análisis al día, sin tarjeta.