AWS детально про відкритий контрольний план HyperPod InstantStart для агентних операцій

Amazon Web Services детально описала HyperPod InstantStart, відкритий контрольний план, який поєднує оркестрацію Amazon EKS з керованими можливостями Amazon SageMaker HyperPod, у посту у блозі AWS Machine Learning від 4 вересня 2026 року. Проект поєднує веб‑інтерфейс з AI‑агентом, який планує та виконує багатоступеневі операції кластеру за допомогою інструментів Model Context Protocol.

InstantStart працює як єдиний позабендовий контейнер управління у обліковому записі користувача AWS, викликаючи API сервісів AWS та API Kubernetes, не перебуваючи в даних шляхах навчальних завдань або запитів інференції. Кожен створений ним ресурс — це стандартний об’єкт AWS або Kubernetes, який можна переглянути за допомогою AWS Command Line Interface та kubectl. Веб‑інтерфейс, REST API та інструменти MCP, які використовує агент, є трьома обличчями одного контейнера, тому обидва інтерфейси проходять через один бекенд і підлягають однаковим перевіркам.

One Backend Behind Two Interfaces

Основний аргумент дизайну у дописі полягає в тому, що інструменти MCP обгортають власні REST API контрольного плану, а не AWS CLI чи SDK, тому однаково додана перевірка захищає як браузер, так і агента. У веб‑інтерфейсі створення кластера з встановленими залежностями, увімкненим автоматичним відновленням вузлів та підключеним сховищем представлено у вигляді форми та панелі прогресу; у терміналі це один речення природною мовою до конфігурації агента під назвою hypd-inst-agent, створеної для Kiro CLI. Агент потім послідовно виконує роботу: створення контрольного плану EKS, вибір активного кластера, узгодження залежностей, створення кластера HyperPod та налаштування сховища. За словами AWS, створення контрольного плану EKS завершується приблизно за 8‑12 хвилин, і кожен наступний етап записує свій статус і може бути повторений незалежно.

Три правила робочого процесу закодовані в навичках агента проєкту, які у дописі описані як markdown‑плейбуки, версійовані у репозиторії. Агент опитує кожну довготривалу операцію до термінального стану, а не повідомляє про подану заявку. Він задає лише питання рівня прийняття рішень, такі як зона доступності, тип інстанса та тип потужності, розглядаючи CIDR підмереж, таблиці маршрутів та групи безпеки як роботу контрольного плану. І він перевіряє перед створенням, перераховуючи існуючі кластери та запитуючи допустимі зони і типи інстансів перед пропозицією вибору.

Managed Capabilities as Reconciled State

InstantStart створює кластери HyperPod з увімкненим автоматичним відновленням вузлів, завдяки чому HyperPod може перезавантажувати або замінювати несправні вузли на основі свого агента моніторингу здоров’я, базових перевірок стану та додаткових глибоких перевірок, що навантажують GPU та з’єднання Elastic Fabric Adapter перед тим, як вузли приймуть роботу. Коли користувач додає групу інстансів, тип потужності, режим мережевого інтерфейсу та розміщення підмережі фіксуються як одна операція створення; тип потужності та режим інтерфейсу лише для EFA залишаються незмінними протягом усього життя групи. Контрольний план маршрутизує кожен шлях потужності через одну функцію, яка забезпечує обчислювальні підмережі розміром /20 для великих флотів прискорювачів.

Кероване HyperPod автоскейлінг вузлів на базі Karpenter визначає, скільки цієї потужності використовується в будь‑який момент, причому AWS керує самим контролером Karpenter, а вузли запускаються з груп інстансів HyperPod, масштабованих з нуля. У дописі зазначено одне обмеження масштабування: керований Karpenter керує лише групами інстансів HyperPod, а не загальною потужністю Amazon EC2.

Панель «Розширені функції» відкриває керовані можливості HyperPod, включаючи оператор навчання, оператор інференції, кероване багаторівневе контрольне збереження та кероване автоскейлінг, причому кожен перемикач пов’язаний з бекенд‑операцією, що враховує залежності. Увімкнення багаторівневого контрольного збереження створює ланцюжок ідентичності, що охоплює обліковий запис сервісу Kubernetes, роль і політику IAM, довірчі відносини OpenID Connect та анотацію прив’язки; вимкнення видаляє той самий ланцюжок. У дописі також описано контракт explicit‑diff, прийнятий після ранньої помилки: інтерфейс надсилає лише поля, які користувач фактично змінив, а бекенд читає реальний стан кластера і не виконує дії, коли запитаний і фактичний стан вже збігаються.

Training and Inference Paths

Для навчання InstantStart пропонує два шляхи подачі. Оператор навчання HyperPod, встановлений як додаток EKS, додає відновлення помилок на рівні процесу, виявлення завислих завдань через моніторинг шаблонів журналу та виявлення аномалій, при цьому робота подається як ресурси HyperPodPyTorchJob з видимим бюджетом відновлення. Другий шлях — стандартний KubeRay, орієнтований на навантаження, що працюють нативно з Ray, такі як підкріплювальне навчання. Над обома розташовано шар рецептів для простих скриптів PyTorch, LLaMA‑Factory, MS‑Swift та підкріплювального навчання VERL, які спільно використовують один контракт даних, у якому той самий bucket Amazon S3 монтується у середовищі розробки та всередині pod‑ів. Журнали завдань передаються у браузер через WebSocket, а рецепти можуть повідомляти метрики, такі як швидкість навчання, у керований MLflow на Amazon SageMaker AI.

Інференція також має два шляхи. Керований шлях передає життєвий цикл оператору інференції HyperPod, з керованим багаторівневим KV‑кешуванням та інтелектуальними стратегіями маршрутизації, оголошеними разом з кінцевою точкою. Самокерований шлях розгортає контейнер сервісу за вибором користувача, наприклад vLLM або SGLang, як стандартне розгортання Kubernetes, з варіантами сервісу, включаючи зовнішній балансувальник навантаження, внутрішній сервіс кластера та пул моделей з прогрітих GPU‑робітників, які можна переназначити зміною мітки. Для багатокопійного обслуговування SGLang контрольний план може розгорнути маршрутизатор SGLang з кеш‑свідомою маршрутизацією та забезпечити автоскейлінг через Kubernetes Event‑driven Autoscaling.

Agent Tooling and Boundaries

Сервер MCP публікує 38 інструментів, що охоплюють життєвий цикл кластера, групи інстансів, керовані функції, сховище, завантаження моделей, розгортання інференції, завдання та операції над вузлами, згідно з дописом. Кожен інструмент, що змінює стан, називає інструмент статусу, який визначає завершення, і операції зберігають свою фазу до початку опитування, щоб повторна спроба агента не могла повторити зміну. Репозиторій репозиторій GitHub проєкту описує платформу як систему, інтегровану навчанням і інференцією, побудовану на SageMaker HyperPod та стандартній оркестрації EKS, а його README стверджує, що інструменти MCP обгортають API бекенду проєкту для відповідності кращим практикам, тоді як навички агента оркеструють сквозні робочі процеси без жодної локальної налаштування, окрім агента.

У дописі окреслені явні операційні межі. Вбудовані діагностичні навички для NCCL, здоров’я вузлів та помилок створення кластера досліджують лише режим читання, пропонують команди, що змінюють стан, як рекомендації, та ескалують у порядку: дослідження, перезавантаження, заміна. IAM, авторизація Kubernetes, мережеві контролі та бекенд‑перевірка залишаються реальними межами безпеки; агент розширює доступ до контрольного плану без розширення своїх привілеїв. AWS також радить, що еластичне навчання наразі виключає Spot‑інстанси, кероване багаторівневе контрольне збереження та навчання без контрольних точок, а також що квоти використання кластерів SageMaker HyperPod та резервування плану навчання для висококласних типів GPU потрібно узгоджувати перед створенням першого кластера.

Розгортання починається з шаблону CloudFormation, який створює середовище управління, спільний bucket S3 та підтримуючі ролі IAM, при цьому веб‑інтерфейс подається з контейнера на порту 3099 і доступний через сесію перенаправлення портів AWS Systems Manager.