Модели и платформы ИИ
AWS AgentCore Runtime получила поддержку более крупных сессий и монтирования файловых систем

Amazon Web Services 12 ноября 2026 года расширила возможности среды выполнения нового поколения Amazon Bedrock AgentCore Runtime: теперь она поддерживает более крупные сессии агентов, тарификацию с фиксированной базовой нагрузкой и динамическое монтирование файловых систем. По данным AWS, обновления обеспечивают запуск сессий до 15 раз быстрее при сохранении аппаратной изоляции.
Обновлённая среда выполнения доступна в регионах AWS в Северной и Южной Америке, Европе и Азиатско-Тихоокеанском регионе. AgentCore Runtime — это управляемый вычислительный уровень платформы AgentCore, предназначенной для создания агентов на основе различных фреймворков и моделей; платформа также включает средства аутентификации, контроля доступа и наблюдаемости.
Релиз последовал за представлением AgentCore Runtime V2 18 сентября 2026 года, в которой появились запуск на основе снимков состояния и освобождение памяти. Тогда AWS сообщила, что увеличение вычислительных ресурсов и объёма хранилища, а также тарификация с фиксированной базовой нагрузкой появятся позднее. Теперь эти возможности составляют значительную часть обновления, наряду с монтированием файловых систем.
Более крупные сессии без предварительно подготовленных пулов
Теперь каждая сессия может использовать до 8 виртуальных процессоров и 32 ГБ памяти, а также поддерживать образы контейнеров размером до 10 ГБ. По данным AWS, вычислительная мощность в четыре раза выше, чем в предыдущей версии, а сессии запускаются менее чем за две секунды независимо от размера образа и уровня параллелизма. Это избавляет клиентов от необходимости самостоятельно управлять предварительно подготовленными пулами или заранее создавать кластеры для сокращения задержек при холодном запуске.
Для запуска восстанавливается снимок состояния, а не выполняется повторная инициализация. AgentCore один раз подготавливает работоспособное окружение контейнера, сохраняет его состояние после инициализации и восстанавливает этот снимок для каждого нового экземпляра. Благодаря этому такие операции, как загрузка артефактов модели и получение статической конфигурации, не повторяются при каждом холодном запуске.
Вице-президент по инженерным вопросам Coinbase Сивэй Шэнь описал результаты в промышленной эксплуатации: «После перехода на среду выполнения AgentCore нового поколения холодный запуск сессий агентов сократился почти с минуты до менее чем пяти секунд — даже в периоды пиковой нагрузки. Кроме того, задержки запуска продолжительностью более 30 секунд исчезли, а недельный объём работы агентов при этом более чем удвоился».
Mission Cloud сообщила, что первоначальное сравнение одинаковой нагрузки запросами на естественном языке в обеих версиях среды выполнения показало, что холодный запуск запросов на получение выводов стал быстрее на 35%, запуск проверки работоспособности — на 77%, а измеренная стоимость работы среды выполнения на один вызов снизилась на 17%. Агент извлекает сведения об объектах недвижимости и продажах, не требуя от пользователей работы со сложными системами данных.
Освобождение памяти и тарификация с фиксированной базовой нагрузкой
AWS также меняет порядок тарификации памяти в периоды простоя. Среда выполнения освобождает память в течение нескольких минут после того, как агент перестаёт её использовать, и уменьшает ресурсы простаивающего агента до нуля. По данным AWS, для агентов с несколькими последовательными взаимодействиями и естественными паузами потребление памяти на сессию может снизиться до 68%. Это решает проблему прежней модели, при которой плата начислялась исходя из пикового объёма памяти, выделенного для сессии, даже после того, как память переставала использоваться.
Для постоянно работающих агентов тариф с фиксированной базовой нагрузкой устанавливает минимальный объём памяти на сессию, за который взимается плата, и при необходимости позволяет увеличить его до четырёх раз. По описанию AWS, предсказуемая ставка для стабильных рабочих нагрузок соответствует тарифам на микровиртуальные машины AWS Lambda; для нерегулярных нагрузок и сценариев с уменьшением ресурсов до нуля сохраняется оплата по фактическому потреблению.
Zuora сообщила, что в ряде случаев новая среда выполнения сократила объём памяти на один вызов примерно на 60%, позволяя обрабатывать больше запросов при стабильной задержке.
Хранилище, изоляция и ограничения развёртывания
Каждая сессия по-прежнему работает в отдельной аппаратно изолированной микровиртуальной машине Firecracker, имеющей собственные идентификатор, политику доступа и журнал аудита. Теперь агенты могут динамически подключать файловую систему и сохранять в ней результаты работы, например в хранилище Amazon S3 с поддержкой FUSE. По данным AWS, на протяжении всей задачи данные остаются в пределах доверенной зоны сессии и защищены единым набором средств контроля. Таким образом, изоляция распространяется не только на вычислительную среду.
В объявленную доступность не входит ограничение доступа к папкам хранилища на уровне отдельных сессий. AWS сообщает, что к мероприятию re:Invent учётные данные с метками сессий будут привязывать каждую сессию к отдельной папке хранилища, обеспечивая более детальный контроль при монтировании.
В актуальной документации V2 также описаны различия в развёртывании. V2 по-прежнему нужно включать отдельно, поскольку по умолчанию используется V1, если только platformVersion не задано значение V2; создание среды выполнения V2 или внесение в неё изменений занимает несколько минут, пока AWS подготавливает снимок состояния, а контейнер должен сообщить о готовности через свою /ping конечную точку в течение 120 секунд. Это время настройки не связано с задержкой холодного запуска сессии.
Сессии могут работать до восьми часов, но завершаются после 15 минут бездействия, по истечении этого срока или при нарушении работоспособности. Состояние сессии временное; при её завершении микровиртуальная машина уничтожается, а память очищается.
В этом релизе вычислительные ресурсы сессий, тарификация памяти и данные задач объединены в единой модели управляемой среды выполнения. Пока не реализована лишь детальная изоляция хранилища: ограничение доступа к хранилищу на уровне отдельных сессий — последний шаг к распространению гарантии изоляции среды выполнения с процесса исполнения на сохранённые результаты работы агентов.












