AWS перерабатывает Bedrock AgentCore Runtime для эластичной памяти и быстрых холодных запусков

Amazon Web Services объявила новый runtime AgentCore 18 сентября 2026 г., переработанную версию управляемого вычислительного слоя в Amazon Bedrock AgentCore, которую компания заявляет, освобождает память по мере завершения сеансов агентов и обеспечивает стабильные времена холодного запуска независимо от размера образа контейнера или уровня параллельности.

AgentCore runtime — это управляемый вычислительный слой, предоставляющий разработчикам полностью управляемую среду для развертывания и запуска агентов без необходимости создания или поддержки инфраструктуры. AWS сообщил, что тысячи команд используют его для запуска производственных агентов с момента запуска, а первая версия создала безсерверную основу с изоляцией сеансов, поведением масштабирования до нуля и моделью оплаты по использованию. Эта модель потребления сохраняется: биллинг привязан к использованию ресурсов без оплаты простоя процессора, ожидающего ввода‑вывода, а платформа масштабируется до нуля, когда у агента нет работы.

Проблемы, которые решает запуск

В оригинальном runtime сеанс удерживал выделенную ему память с момента выделения до завершения сеанса, поскольку ничего не освобождало её в процессе. AWS отметил, что это заставляло длительно работающих или всплеск‑активных агентов платить за их пиковый уровень памяти круглосуточно, даже после того как память переставала использоваться, что особенно проблематично для агентов, которые время от времени резко нагружаются, но большую часть дня находятся в простое.

Поведение при запуске было второй проблемой. AWS сообщил, что сеанс, попадающий в уже инициализированную среду, стартует менее чем за 100 мс, но поддержание среды в «теплом» состоянии требует резервирования вычислительных ресурсов, поэтому большинство сеансов начинается с холодного запуска, который загружает новую среду, скачивает образ и инициализирует агента до выполнения первого запроса. Эта задержка растёт с размером образа и уровнем параллельности и достигает максимума при всплесках трафика, когда приходит наибольшее количество сеансов, а готовых сред остаётся минимум. По данным AWS, клиенты обходили обе проблемы, поддерживая готовые резервные среды, оптимизируя распределение памяти и сокращая мощность, чтобы контролировать затраты.

Что измерил AWS

Чтобы изолировать влияние самой платформы на холодный запуск, AWS протестировал пустой эхо‑агент, который возвращает полученный ввод и не вызывает ни модели, ни инструменты. Python‑клиент на экземпляре Amazon EC2 в регионе us-west-2 вызывал агентов в us-east-1 через публичный интернет без VPC‑пиринга, используя SDK boto3, поэтому каждое измерение на стороне клиента включало круговой путь между двумя регионами AWS поверх собственного времени запуска платформы. Компания отправила по 5 000 холодных вызовов на каждый агент для обеих версий runtime и пяти размеров образов, в рамках стандартных квот аккаунта.

По измерениям AWS сообщил, что новый runtime обеспечивает P75‑задержку холодного запуска около 2 секунд при образе от 200 МБ до 2 ГБ, поскольку размер образа на неё не влияет, тогда как у оригинального runtime задержка увеличивалась с ростом образа от примерно 5,4 секунд до почти 30 секунд. В тесте эхо‑агент собственный код работал примерно 34 мс при P75, так что почти всё измеренное время приходилось на запуск платформы. AWS предлагает скрывать время запуска для интерактивных агентов, начиная сеанс сразу после взаимодействия пользователя, например при открытии чата, чтобы среда прогревалась во время ввода первого запроса.

Как работает новый runtime

Новый runtime запускает каждый сеанс с небольшого профиля памяти вместо полностью выделенного следа, а затем выделяет и подгружает дополнительную память по требованию по мере обращения к ней рабочей нагрузкой. Когда агент освобождает буферы запросов или позволяет кэшированным данным истечь между запросами, платформа возвращает эту память, а не оставляет её занятой до завершения сеанса. AWS сообщил, что настроил поведение освобождения памяти на основе анализа паттернов выделения в миллиардах сеансов.

Холодные запуски меняются, потому что каждый агент загружается один раз, а затем работает из снимка. При создании или обновлении runtime AgentCore запускает контейнер, ждёт, пока он сообщит о здоровом состоянии, и захватывает снимок работающей среды, поэтому одноразовая инициализация, такая как загрузка артефактов модели и получение статической конфигурации, уже выполнена. Каждый новый экземпляр восстанавливает этот снимок вместо инициализации с нуля. AWS сообщил, что runtime удаляет кэши и временную память из снимка, поэтому его размер остаётся примерно постоянным по мере роста образа контейнера, что поддерживает стабильную задержку восстановления при широком диапазоне размеров образов.

Биллинг меняется вместе с моделью памяти. Новый runtime взимает плату за память, которую агент активно использует, загружая её по запросу и освобождая в простое, а не за удержание всего образа контейнера в памяти на протяжении всей сессии. AWS охарактеризовал изменение как более высокую ставку, применяемую к гораздо меньшему количеству ГБ‑часов, и отметил, что для большинства агентов объём памяти снижается сильнее, чем растёт ставка, поэтому счёт уменьшается.

Версии платформы, регионы и ограничения

Разработчики включают новый runtime, задавая значение поля platformVersion равным V2 при создании или обновлении runtime, согласно AgentCore Руководство разработчика. V1 является значением по умолчанию: при создании, если поле не указано, создаётся runtime V1, а при обновлении отсутствие поля сохраняет текущую версию платформы runtime. V2 доступен в регионах us-east-1, us-east-2, us-west-2, eu-west-1 и ap-northeast-1.

Поскольку создание или обновление V2 подготавливает и делает снимок среды, эти операции продолжаются несколько минут, прежде чем среда выполнения достигнет состояния READY, тогда как среда V1 готова за секунды. AgentCore делает снимок при первом здоровом ответе от эндпоинта /ping контейнера, и если контейнер не сообщает о здоровом состоянии в течение 120 секунд после запуска, создание завершается ошибкой проверки здоровья. В руководстве также указано, что V2 в настоящее время ограничивает общий размер переменных окружения 1,5 KB для прямых развертываний кода и 2,5 KB для контейнерных агентов, по сравнению с 4 KB в V1, и что AWS CloudFormation и AWS CDK пока не поддерживают установку platformVersion.

Снимки привязаны к версиям и эндпоинтам среды выполнения, а не управляются напрямую. AgentCore создает снимок, когда эндпоинт указывает на версию, и удаляет его, когда ни один эндпоинт не указывает на неё; удаление может занимать до 8 часов, что является максимальной продолжительностью сессии, поскольку сессии, уже работающие на снимке, продолжаются до завершения. Сессии работают в выделенных микровиртуальных машинах (microVM) с изолированными ресурсами CPU, памяти и файловой системы, сохраняются до 8 часов и завершаются после 15 минут бездействия, после чего микровиртуальная машина уничтожается, а память очищается.

Дорожная карта и начало работы

После запуска AWS объявила о нескольких предстоящих возможностях: гарантированные базовые скидки, которые резервируют минимальный объём памяти на сессию с возможностью мгновенного «всплеска» по требованию, ориентированные на постоянные всегда‑активные сессии; увеличенный объём ОЗУ, vCPU и хранилища сессий; поддержка микровиртуальных машин x86; приостановка и возобновление с созданием снимка памяти плюс хуки среды выполнения для сериализации состояния перед завершением активной сессии; а также ключи контекста сессии, предоставляющие каждой сессии ограниченную идентичность для бесконтрольных агентов.

AWS направила разработчиков к руководству AgentCore Developer Guide, репозиторию примеров AgentCore на GitHub и сопутствующему примеру нагрузочного теста, демонстрирующему задержку холодного старта новой среды выполнения в собственном аккаунте AWS пользователя.