«Одна сессия, один GPU, три агента»: AWS собрала музыкальный конвейер на Bedrock AgentCore Runtime Instances

Что произошло

30 сентября 2026 года в блоге AWS Machine Learning вышел практический разбор музыкального конвейера из трёх агентов на Amazon Bedrock AgentCore Runtime Instances — новой опции вычислений для агентов, которая дополняет серверлесс-MicroVM там, где сессия должна жить днями.

Авторы материала — Evandro Franco, Sayee Kulkarni, Rui Cardoso и Yanis Telaoumaten — формулируют исходную проблему так: одиночный агент, отвечающий на запросы клиентов, спокойно живёт в serverless-среде с короткими сессиями, но когда три агента несколько дней совместно работают над творческим процессом, делят контекст и опираются на результаты друг друга, сессии, упирающиеся в несколько часов, не подходят.

Разбор идёт в формате hands-on: сначала подготовка аккаунта, затем описание трёх агентов (шаг 1), создание capacity provider, который выделяет GPU-инстанс и постоянные тома (шаг 2), разворачивание каждого агента как отдельного runtime (шаг 3), вызов всех трёх с общим идентификатором сессии, чтобы они оказались на одном инстансе (шаг 4), и наконец обновление одного агента без остановки остальных (шаг 5).

На выходе обещан играбельный файл.wav и три отчёта, объясняющие каждое решение.

Чем Runtime Instances отличается от MicroVM

AgentCore предлагает две вычислительные опции для хостинга агентов. MicroVM — серверлесс-вариант: быстрый холодный старт, изоляция сессий и оплата по потреблению. Runtime Instances — новая опция: управляемая AWS инфраструктура EC2 для долгих и постоянных агентских процессов. Обе опции поддерживают кастомные фреймворки (CrewAI, LangGraph, LlamaIndex, Strands Agents), любую фундаментальную модель, интеграцию с MCP и A2A, и обе используют одни и те же runtime-API.

Разница именно в модели вычислений. Сессия MicroVM живёт до 8 часов, сессия Instances — до 14 дней. На одну единицу вычислений MicroVM приходится один агент (соотношение 1:1), тогда как один EC2-инстанс может хостить несколько агентов (1:N). GPU на MicroVM не поддерживается, на Instances доступен на подходящем семействе инстансов. Хранение сессии у MicroVM ограничено сессией, у Instances — постоянные тома Amazon EBS. Цены: у MicroVM оплата по потреблению, у Instances EC2-инстансы работают в вашем аккаунте, и на них действуют ваши AWS Savings Plans и On-Demand Capacity Reservations (ODCR). Масштабирование у MicroVM по требованию, у Instances им управляет capacity provider.

Ключевой механизм — общая сессия. Агент здесь это рабочая нагрузка внутри сессии, и, в отличие от модели MicroVM, одна сессия Instances может держать несколько агентов: если два runtime используют один capacity provider и вызываются с одним и тем же runtimeSessionId, AgentCore размещает их на одном EC2-инстансе, где они делят файловую систему и могут работать над одной задачей.

Три агента одного трека

Composition agent (команда Audio AI) превращает запрос продюсера в музыкальный бриф с помощью Claude Sonnet 4.6 и затем рендерит само аудио генеративной моделью ACE-Step — открытой фундаментальной моделью для генерации музыки, работающей на GPU самого инстанса; агент упакован как контейнерный образ в Amazon ECR.

Delivery agent (Audio Engineering) читает отрендеренный трек с общей файловой системы и измеряет его, после чего просит Claude Sonnet 4.6 подобрать цепочку доставки (EQ, компрессию, лимитирование) именно по результатам измерений, а не «по звуку». Реальный DSP применяется к цепочке, а результат измеряется заново, чтобы подтвердить попадание в цель.

Compliance agent (Release Engineering) независимо перемеряет готовую сдачу, сверяет её с целями, которые заявил delivery agent, и проверяет на гармоническую близость к собственному каталогу студии. Если проверка возражает, агент вызывает composition agent за заменой и перепроверяет снова; поставляется он zip-архивом в Amazon S3, а не контейнером.

Рабочий цикл выглядит так: продюсер запускает трек, composition agent пишет бриф и рендерит аудио на GPU инстанса, delivery agent открывает файл, измеряет, применяет выведенную из измерений цепочку и измеряет повторно, compliance agent перемеряет независимо, сверяет цели и проверяет аудио на совпадения с каталогом, а при флаге просит композитора сгенерировать альтернативу.

Именно Runtime Instances делают это возможным. Сокомещение обеспечивает общий session id: у каждого агента свой runtime, но один и тот же runtimeSessionId на одном capacity provider ставит их на один инстанс с одними и теми же смонтированными томами. GPU — тот самый, который можно использовать: composition agent запускает ACE-Step на NVIDIA L4 инстанса и рендерит 20 секунд 48-кГц стерео примерно за 9 секунд, а модель и её зависимости живут на постоянном томе — собираются один раз на сессию и переиспользуются после ночной остановки. Независимое развёртывание позволяет команде Audio AI выкатывать новый образ композитора, не согласовывая это с двумя другими командами, а многодневная живучесть — начать композицию в понедельник, остановить сессию на ночь и продолжить сдачу во вторник, потому что инстанс простаивает автоматически и возобновляется при следующем вызове. Контейнеры из ECR и пакеты кода из S3 уживаются на одном capacity provider: команды выбирают упаковку под свой процесс.

Что нужно в аккаунте

Прежде чем начинать, авторы перечисляют предпосылки: аккаунт AWS с правами принципала, способного создавать инфраструктуру (в примере создаются IAM-роли, бакет S3, репозитории ECR, а также capacity provider и runtimes AgentCore); установленный и настроенный AWS CLI; VPC минимум с одной подсетью и security group; включённый в консоли Amazon Bedrock доступ к модели Anthropic Claude Sonnet 4.6; установленный Finch или другой OCI-совместимый инструмент для контейнеров; Python 3.10+ и boto3 не ниже 1.36.0 либо botocore не ниже 1.43.72, потому что в более старых версиях нет create_capacity_provider и deploy.py падает.

Отдельно описаны два места, которые чаще всего настраивают неправильно и которые падают непонятно. Во-первых, у функции-точки входа второй параметр обязан называться именно context: SDK разбирает параметры по имени (проверяя params == "context"), и это единственный способ прочитать идентификатор сессии, нужный агентам, чтобы находить файлы друг друга и вызывать друг друга. Во-вторых, объект Agent нужно собирать внутри обработчика, а не на уровне модуля: модульный Agent делится между конкурентными запросами, и Strands отвергает повторный вход ошибкой «Agent is already processing a request». История при этом живёт на томе через FileSessionManager — именно так сессия, возобновлённая через дни, помнит прежние решения.

Как поднимается capacity provider

Capacity provider сообщает AgentCore, какую вычислительную инфраструктуру выделять агентам: указываются типы инстансов и размещение в VPC, а провижининг и жизненный цикл AWS берёт на себя. Нужны две IAM-роли, и различие между ними принципиально: operator role, которую AgentCore принимает, чтобы запускать, помечать и завершать EC2-инстансы и их сетевые интерфейсы от вашего имени (к ней прикрепляется управляемая политика BedrockAgentCoreRuntimeInstancesOperatorRolePolicy), и execution role, которую процесс агента принимает во время работы, чтобы вызывать Bedrock и S3 — её требует CreateAgentRuntime и без неё падает. Обе доверяют bedrock-agentcore.amazonaws.com.

В примере capacity provider создаётся с именем music_production_capacity, и авторы подчёркивают: имена обязаны использовать подчёркивания, дефисы не допускаются. Конфигурация описывает инстанс типа g6.xlarge, VPC-подсети и группы безопасности, тома tracks на 20 GiB и models на 60 GiB (оба gp3 и зашифрованные, у models пропускная способность 500), корневой том с запасом 30 GiB, а также жизненный цикл: idleInstanceTimeout 600 и maxLifetime 86400.

Тут же предупреждение про GPU-ёмкость: если при попытке выделить GPU-инстанс вы получаете InsufficientInstanceCapacity сразу в нескольких зонах доступности, можно переключиться на другой тип GPU-инстанса, например g5.xlarge, поправив allowedInstanceTypes.

Живой прогон одного трека

На шаге развёртывания каждый агент получает свой runtime, а сводятся они воедино в момент вызова: два runtime на одном capacity provider, вызванные с одним runtimeSessionId, попадают на один EC2-инстанс и делят файловую систему — так delivery agent и читает.wav, записанный composition agent. Идентификатор сессии в примере генерируется как music-production- плюс uuid и должен укладываться в 33–100 символов.

На живом инстансе g6.xlarge в регионе us-east-2 прогон занял: подготовка стека моделей (GPU-инстанс, torch и веса) 239 секунд, из них стек готов за 125 секунд; рендер бэк-каталога 66 секунд; композиция 25 секунд, причём сам рендер на NVIDIA L4 занял 8.98 секунды с пиковым потреблением VRAM 7.63 GiB, а аудио получилось 20.062 секунды, 48000 Гц, два канала, −7.5 LUFS и пик 0.42 dBTP; сдача 41 секунда с реальным DSP — на входе те же −7.5 LUFS и пик 0.42 dBTP, на выходе −14.0 LUFS и −3.2 dBTP, то есть цели по громкости достигнуты, а истинный пик удержан; проверка соответствия 28 секунд с вердиктом REVIEW REQUIRED и расстоянием 0.0665 до ближайшего каталожного файла по двум референсам. Все пять шагов обслужил один инстанс, как и задумано.

Важная оговорка о возобновлении: при вызове StopRuntimeSession инстанс автоматически уходит в простой, и, пока он простаивает, плата за вычисления не начисляется; повторный вызов сессии AgentCore возобновляет при условии, что она попадёт в ту же зону доступности. Тома Amazon EBS привязаны к зоне, и если в исходной зоне не хватает ёмкости, тома не переподключатся и живучесть теряется — поэтому авторы советуют AZ-закреплённый ODCR или MODELS_SNAPSHOT_ID, чтобы переразмещённое возобновление могло восстановиться. Жить сессии могут до 14 дней.

Обновление одного агента и уборка

Сильная сторона архитектуры — независимое развёртывание: когда команда Audio AI выпускает новую версию composition agent, она обновляет только свой runtime (update_agent_runtime, у которого обязательны все три аргумента — идентификатор runtime, execution role и артефакт), а delivery и compliance продолжают работать без изменений: ни согласований, ни общего deploy-конвейера, ни риска сломать агента другой команды.

Убирать ресурсы авторы советуют, начиная с сессии: удаление сессии — самый прямой способ остановить начисления за EC2 и Amazon EBS, так как вместе с ней снимаются инстанс, сетевой интерфейс и том. Удаление capacity provider тоже останавливает и удаляет связанные сессии с их постоянным хранилищем, но сначала нужно отвязать от него каждый runtime и его версию, а отвязка асинхронна. После этого удаляются репозитории ECR, артефакты S3, IAM-роли и лог-группы CloudWatch.

Что из этого следует

Вывод, к которому ведут авторы, шире музыки: сокомещение через общие сессии даёт нескольким agent runtime один хост — тот же GPU, тот же локальный том, то же пространство процессов; независимое развёртывание оставляет каждой команде свой жизненный цикл; смешанные типы артефактов позволяют контейнерам и пакетам кода сосуществовать на одной инфраструктуре; многодневная живучесть — останавливать сессии на паузе и возобновлять их вызовом.

Музыка — удобный носитель, но в самой архитектуре музыкального нет: если заменить шаг рендера, та же форма из трёх агентов подходит для рабочих нагрузок GPU-инстансов, которые AWS называет сама, — 3D-рендеринг, симуляция, вывод моделей, обработка медиа, — или для длинной задачи, где конвейер производит большой артефакт, передаёт его второму агенту на преобразование, а третий проверяет результат до выпуска.

Полный рабочий код из этой публикации лежит в репозитории примеров AgentCore на GitHub, а за документацией по Amazon Bedrock AgentCore и паттернами оркестрации Graph, Swarm и Workflow авторы отправляют в соответствующие разделы Strands Agents.