AWS перестаёт считать память агента по пиковому значению за всю сессию

AWS сделала общедоступной новую версию Amazon Bedrock AgentCore Runtime. Главное изменение здесь — не новая абстракция для агентов, а модель исполнения и тарификации, лучше подходящая для сессий, в которых потребление памяти растёт, снижается и затем надолго замирает.

AgentCore Runtime V2 начинает работу с меньшим профилем памяти, выделяет дополнительную память по потребности и возвращает её, когда приложение её освободило или она стала неактивной. По данным AWS, неактивная память высвобождается через 120 секунд. В прежней модели пиковое потребление памяти сессии могло оставаться экономически значимым до её завершения. V2 делает важной именно кривую потребления памяти внутри сессии.

Для долгих ИИ-сессий это существенное изменение. Сессия может временно собрать большой буфер для поиска, удерживать промежуточные результаты инструментов, ждать ответа модели или простаивать между действиями пользователя. Пиковое потребление может быть оправдано, но не описывать её потребности на оставшееся время. Если считать, будто пик сохраняется всегда, временное рабочее состояние превращается в постоянную инфраструктурную статью затрат.

Что изменилось — и что осталось прежним

V2 стала общедоступной 18 сентября 2026 года. Для её выбора нужно задать platformVersion со значением V2. Автоматической миграции нет: если поле не указано, версией по умолчанию остаётся V1. На старте V2 доступна в Северной Вирджинии, Огайо, Орегоне, Ирландии и Токио. AWS CloudFormation и AWS CDK пока не позволяют задать platformVersion.

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

Однако V2 — не универсальный способ снизить расходы, а результат холодного старта не равен задержке ответа приложения от начала до конца. AWS указывает для V2 $0,1276 за vCPU-час и $0,0169 за GB-час против $0,0895 и $0,00945 для V1. Тарифы за единицу выше. Экономия появится только тогда, когда сокращение оплачиваемых ресурсо-часов — прежде всего часов возвращённой памяти — перекроет эту разницу.

Новой единицей анализа становится кривая памяти

Команды обычно описывают ИИ-сервис через запросы, токены, вызовы моделей, среднюю длительность сессии и иногда пиковую конкурентность. Эти показатели по-прежнему нужны. Но для выбора между двумя версиями runtime их уже недостаточно.

Нужно спрашивать не только: «Сколько памяти требуется сервису?» Точнее будет так: «Как долго ему нужен каждый дополнительный объём памяти и когда этот объём можно освободить?» Нагрузка, которая ненадолго достигает высокого выделения, затем освобождает память и остаётся активной ещё несколько минут, имеет другой экономический профиль V2, чем нагрузка, постоянно удерживающая состояние около пика. Поэтому у двух сервисов с одинаковым пиком памяти и одинаковой длиной сессии счета могут заметно различаться.

“V2 делает временное потребление памяти операционной переменной. Если описывать нагрузку только её пиковым выделением, можно не увидеть ни издержек, ни экономии.

Особенно это важно там, где runtime координирует неравномерную работу. Этапы поиска могут материализовать документы и эмбеддинги; выполнение инструментов — создавать крупные промежуточные объекты; многошаговые процессы — удерживать контекст в ожидании внешних систем. Из этого не следует, что любую такую нагрузку нужно переносить на V2. Следует измерить, действительно ли живая память снижается между всплесками и достаточно ли быстро код освобождает ненужное состояние, чтобы механизм возврата памяти дал эффект.

Снимки запуска требуют ревизии приложения

Восстановление из снимка меняет ещё одну операционную границу: что безопасно делать при старте. Значения, созданные при инициализации, наследуются экземплярами, восстановленными из снимка. Поэтому AWS рекомендует не создавать в стартовом коде значения, специфичные для запроса, истекающие со временем или уникальные.

Это не редкий крайний случай, а практическое инженерное ограничение. Учётные данные, полученные при инициализации, могут истечь. Идентификатор запроса, созданный там, перестаёт быть уникальным для запроса. Метка времени, которая должна отражать текущую работу, может описывать только подготовленную среду. В инициализации должны оставаться переиспользуемый код и стабильная конфигурация; в обработке запроса — значения, корректность которых зависит от конкретного запроса, экземпляра или момента времени.

Это разделение задаёт и полезный объект тестирования. Перед включением V2 стоит перечислить побочные эффекты инициализации и отнести каждый к одной из групп: стабильный и общий; обновляемый после восстановления; либо нужный только на пути обработки запроса. Миграция завершена не тогда, когда развёртывание прошло успешно, а когда восстановленные экземпляры не несут устаревшего стартового состояния, меняющего поведение приложения.

Результат холодного старта нужно читать узко

Опубликованный AWS бенчмарк обнадёживает, но намеренно ограничен. Компания по 5 000 раз запускала с холодного состояния пустого echo-агента для каждой версии и каждого размера образа. Для образов от 200 МБ до 2 ГБ V2 показала примерно двухсекундный P75 холодного старта, а V1 — от примерно 5,4 секунды до почти 30 секунд.

Измерение включало передачу по публичному интернету от клиента EC2 в us-west-2 к runtime в us-east-1. В него не входила работа модели и инструментов. Следовательно, это конкретный результат о запуске платформы в данной конфигурации, а не оценка времени ответа, которое увидит пользователь production-агента с поиском, инференсом, внешними API и собственной инициализацией.

Практический урок — в методике. Нужно измерять распределение холодных стартов для реального образа и фактической региональной схемы, а затем отдельно учитывать запуск платформы, инициализацию приложения, работу модели и задержку инструментов. Одно число «первого ответа» скрывает компонент, который действительно требует внимания.

Решение о миграции должно опираться на измерения

V2 предлагает более эластичный вариант runtime, но одновременно убирает основания сравнивать версии только по прайс-листу или размеру контейнера. Решение должно строиться на трассах, похожих на production-нагрузку.

• Записывайте выделение и освобождение памяти на всём протяжении сессии, а не только пиковую резидентную память.
• Измеряйте, как долго память остаётся неактивной после всплесков; AWS указывает, что V2 возвращает её через 120 секунд.
• Сравнивайте оплачиваемые vCPU-часы и GB-часы по тарифам V1 и V2 на репрезентативной смеси трафика.
• Тестируйте холодный старт отдельно от работы модели и инструментов — для реально используемых размеров образов и регионов.
• Проверьте стартовый код на кэшированные учётные данные, метки времени, случайные значения, идентификаторы запросов и другое состояние, которое нельзя безопасно наследовать.

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