Amazon обновила AgentCore runtime — управляемый слой вычислений внутри Amazon Bedrock AgentCore, на котором разработчики разворачивают и запускают ИИ-агентов. Сервис существует с момента запуска платформы, и за это время им воспользовались тысячи команд для агентов в продакшене. Новая версия меняет два параметра: управление памятью и предсказуемость запуска.
Агенты перестали быть экспериментом. Они обрабатывают заявки, пишут и проверяют код, координируют работу между системами и работают часами без присмотра. Часть из них выросла из чат-ботов, где обмен занимал секунды. Затем появились агенты для программирования, которые держат контекст минутами и часами. Сейчас формируется третий тип — постоянные агенты, запускаемые событиями, работающие без наблюдения и подающие сигнал только по завершении задачи или при необходимости решения человека. Таких агентов становится заметно больше: они встроены в продукты, стоят за повседневными функциями и всё чаще запускаются другими агентами.
| Параметр | До обновления | После обновления |
|---|---|---|
| Управление памятью | Удерживается на пиковом уровне до конца сессии | Освобождается в момент завершения сессии |
| Время холодного старта | Растёт с размером образа и числом одновременных сессий | Одинаково независимо от размера контейнера и нагрузки |
| Биллинг | Оплата пика памяти и простоя CPU | Оплата фактического потребления ресурсов |
Первая версия AgentCore runtime заложила основу для всего этого спектра: serverless-модель, изоляция сессий, масштабирование до нуля и оплата только за использованное. Две вещи делают эту модель привлекательной для команд. Первая — платить нужно только за потребление, а не за простой CPU в ожидании ввода-вывода. Вторая — платформа масштабируется до нуля: когда агент не работает, ничего не запущено и не тарифицируется. Вместе это позволяет дёшево держать множество агентов, большую часть времени простаивающих, и так же дёшево запускать одного, который занят постоянно.
С переходом агентов к постоянной работе та же модель столкнулась с двумя ограничениями. Память стоит дорого, и до сих пор оплачивался её пик: сессия удерживала память с момента выделения до завершения, потому что ничто не освобождало её по ходу. Для длительного или неравномерного агента это означало оплату высокой точки всё время работы, даже после того как память переставала использоваться. Для агента, который всплесками активен, но большую часть дня простаивает, разница между оплатой пика круглосуточно и оплатой реального потребления становится существенной.
Второе ограничение — время запуска. Каждой новой сессии нужно стартовать до начала работы, поэтому быстрый и предсказуемый запуск важен для опыта пользователя. Особенно когда человек ждёт агента, приостановленного для ввода и которому нужно возобновиться. Сессия, попадающая на уже инициализированное окружение, стартует менее чем за 100 миллисекунд, но поддержание окружений в горячем состоянии означает резерв вычислений. Поэтому большинство сессий начинается с холодного старта: загрузка свежего окружения, вытягивание образа и инициализация агента до первого запроса. Эта задержка растёт с размером образа и числом одновременных сессий, и хуже всего при всплесках трафика — именно тогда, когда сессий больше всего, а готовых окружений меньше. Эту несогласованность и ощущает ожидающий пользователь.
Обходные пути, к которым прибегали команды, тяжёлые: они держат запасные окружения наготове, чтобы запросы не упирались в холодный старт, и вручную оптимизируют память. Новая версия AgentCore runtime переносит эту работу на платформу. Память освобождается обратно в момент завершения сессии, а не удерживается на пиковом уровне. Время холодного старта остаётся одинаковым независимо от размера контейнера и параллельной нагрузки. Serverless-модель сохраняется, но становится более эластичной: счёт следует за фактической работой агента.
Для команд, которые держат агентов в продакшене, это меняет экономику. Агент, активный всплесками, перестаёт платить за пик круглосуточно. Агент, к которому обращается человек, получает предсказуемое время отклика при возобновлении. А разработчикам больше не нужно строить собственную машинерию для прогрева окружений и ручного управления памятью — эту часть берёт на себя управляемый слой вычислений.
