AWS оновлює середовище виконання Bedrock AgentCore для еластичної пам’яті та швидкого холодного запуску

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

Середовище виконання AgentCore — це керований обчислювальний шар, який надає розробникам повністю кероване середовище для розгортання та запуску агентів без необхідності створювати чи підтримувати інфраструктуру. AWS повідомив, що тисячі команд використовували його для запуску продуктивних агентів з моменту запуску, і що перша версія створила безсерверську основу з ізоляцією сесій, поведінкою масштабування до нуля та ціноутворенням за використання. Така модель споживання зберігається: виставлення рахунків відповідає використанню ресурсів без плати за бездіючу ЦПУ, що чекає на ввід/вивід, а платформа масштабується до нуля, коли агент не має роботи.

Проблеми, які вирішує запуск

У початковому середовищі виконання сесія утримувала виділену пам’ять від моменту виділення до завершення сесії, оскільки ніщо не звільняло її в процесі. AWS зазначив, що це змушувало довготривалі або сплескові агенти оплачувати свій максимальний рівень пам’яті цілодобово, навіть після того, як пам’ять перестала використовуватись, що створювало особливу проблему для агентів, які час від часу навантажуються, але більшу частину дня залишаються бездіяльними.

Другим викликом була поведінка під час запуску. AWS повідомив, що сесія, яка потрапляє в вже ініціалізоване середовище, стартує за менше ніж 100 мілісекунд, але підтримання середовищ достатньо «теплими», щоб гарантувати це, вимагає резервування обчислювальних ресурсів, тому більшість сесій починаються з холодного запуску, який завантажує нове середовище, завантажує образ і ініціалізує агента перед виконанням першого запиту. Ця затримка зростає зі збільшенням розміру образу та рівня паралельності і найгірша під час сплескових навантажень, коли надходить найбільша кількість сесій, а готових середовищ залишаються найменше. За словами AWS, клієнти обходили обидві проблеми, тримаючи резервні середовища готовими, оптимізуючи розподіл пам’яті та зменшуючи потужність, щоб контролювати витрати.

Що вимірювало AWS

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

За такими вимірюваннями AWS повідомив, що нове середовище виконання забезпечило латентність холодного запуску P75 приблизно 2 секунди для образу від 200 МБ до 2 ГБ, оскільки розмір образу не впливає на неї, тоді як латентність оригінального середовища зростала зі збільшенням розміру образу — від приблизно 5,4 секунди до майже 30 секунд. У тесті ехо код агента працював близько 34 мілісекунд при P75, тому майже весь виміряний час становив час запуску платформи. AWS радить приховати час запуску для інтерактивних агентів, розпочинаючи сесію одразу після взаємодії користувача, наприклад коли він відкриває чат, щоб середовище прогрівалося під час набору першого запиту.

Як працює нове середовище виконання

Нове середовище виконання стартує кожну сесію з невеликого профілю пам’яті, а не з повністю виділеного сліду, а потім виділяє та підвантажує додаткову пам’ять за потребою, коли навантаження її використовує. Коли агент звільняє буфери per‑request або дозволяє кешованим даним закінчитися між запитами, платформа повертає пам’ять назад, замість того щоб залишати її зайнятою до завершення сесії. AWS зазначив, що налаштував поведінку звільнення на основі аналізу моделей виділення пам’яті у мільярдах сесій.

Холодні запуски змінюються, оскільки кожен агент завантажується один раз, а потім працює зі знімка. Коли створюється або оновлюється середовище виконання, AgentCore запускає контейнер, чекає, доки він повідомить про здоров’я, і робить знімок працюючого середовища, тому одноразова ініціалізація, така як завантаження артефактів моделі та отримання статичної конфігурації, вже виконана. Кожен новий екземпляр відновлює цей знімок замість ініціалізації з нуля. AWS повідомив, що середовище виконання видаляє кеші та тимчасову пам’ять зі знімка, тому його розмір залишається приблизно стабільним, коли образ контейнера зростає, що підтримує постійну латентність відновлення для широкого діапазону розмірів образу.

Білінг змінюється разом з моделлю пам’яті. Нове середовище виконання стягує плату лише за пам’ять, яку агент активно використовує, завантажену за запитом і звільнену під час бездіяльності, а не за утримання всього образу контейнера в пам’яті протягом усієї сесії. AWS охарактеризував зміни як вищу ставку, застосовану до значно меншої кількості ГБ‑годин, і зазначив, що для більшості агентів обсяг пам’яті зменшується більше, ніж зростає ставка, тому рахунок зменшується.

Версії платформи, регіони та обмеження

Розробники вмикають нове середовище виконання, встановлюючи поле platformVersion у V2 під час створення або оновлення середовища, згідно з Посібником розробника AgentCore. V1 є типовим: пропуск поля під час створення створює середовище V1, а пропуск під час оновлення залишає поточну версію платформи. 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 хвилин бездіяльності, після чого microVM зупиняється, а пам’ять очищується.

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

Після запуску AWS оголосив про кілька можливостей, які будуть доступні: зобов’язуючі базові знижки, що резервують мінімальний обсяг пам’яті на сесію з можливістю сплеску за потреби, орієнтовані на постійно активні сесії; збільшений обсяг RAM, vCPU та сховища сесій; підтримка x86 microVM; призупинення та відновлення з знімком пам’яті плюс хуки середовища для серіалізації стану перед завершенням активної сесії; та ключі контексту сесії, які надають кожній сесії обмежену ідентичність для агентів без нагляду.

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