Подробности AWS об открытом контролл‑плейне HyperPod InstantStart для операций агентов

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

InstantStart работает как единственный контейнер управления вне канала данных внутри учётной записи AWS пользователя, вызывая API сервисов AWS и API Kubernetes, не находясь в пути данных обучающих задач или запросов вывода. Каждый создаваемый им ресурс — стандартный объект AWS или Kubernetes, который остаётся доступным для просмотра через AWS Command Line Interface и kubectl. Веб‑UI, REST API и инструменты MCP, используемые агентом, представляют три грани одного контейнера, поэтому оба интерфейса проходят через один бекенд и проходят одинаковые проверки.

Один бекенд за двумя интерфейсами

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

Три правила рабочего процесса закодированы в навыках агента проекта, которые в посте описаны как markdown‑плейбуки, версионируемые в репозитории. Агент опрашивает каждую длительную операцию до конечного состояния, а не просто сообщает о поданном запросе. Он задаёт только вопросы уровня принятия решений, такие как зона доступности, тип инстанса и тип ёмкости, рассматривая CIDR подсетей, таблицы маршрутизации и группы безопасности как работу контрольной плоскости. И он проверяет перед созданием, перечисляя существующие кластеры и запрашивая допустимые зоны и типы инстансов перед предложением вариантов.

Управляемые возможности как согласованное состояние

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

Управляемое автмасштабирование узлов на основе Karpenter в HyperPod решает, какая часть этой ёмкости работает в каждый момент, при этом AWS управляет самим контроллером Karpenter, а узлы запускаются из групп инстансов HyperPod, масштабируемых с нуля. В посте отмечено одно ограничение области: управляемый Karpenter управляет только группами инстансов HyperPod, а не общим ёмкостным пулом Amazon EC2.

Панель «Advanced Features» раскрывает управляемые возможности HyperPod, включая оператор обучения, оператор вывода, управляемое многоуровневое контрольное сохранение и управляемое автмасштабирование, при этом каждый переключатель сопоставлен с зависимым от зависимостей бэкенд‑операцией. Включение многоуровневого контрольного сохранения создаёт цепочку идентичности, охватывающую учётную запись сервиса Kubernetes, роль и политику IAM, доверительные отношения OpenID Connect и аннотацию привязки; отключение удаляет ту же цепочку. В посте также описан контракт explicit‑diff, принятый после раннего бага: интерфейс отправляет только те поля, которые пользователь действительно изменил, а бэкенд читает фактическое состояние кластера и не выполняет действий, если запрошенное и реальное состояние уже совпадают.

Пути обучения и вывода

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

Вывод также имеет два пути. Управляемый путь передаёт жизненный цикл оператору вывода HyperPod, с управляемым многоуровневым KV‑кешированием и интеллектуальными стратегиями маршрутизации, объявленными рядом с конечной точкой. Самостоятельный путь разворачивает контейнер обслуживания по выбору пользователя, например vLLM или SGLang, как стандартный деплоймент Kubernetes, с вариантами сервиса, включающими внешний балансировщик нагрузки, внутренний сервис кластера и пул моделей из «тёплых» GPU‑рабочих, которые можно переназначить изменением метки. Для многорепликовой службы SGLang контролл‑плейн может развернуть маршрутизатор SGLang с кеш‑осознанной маршрутизацией и управлять автмасштабированием через Kubernetes Event‑driven Autoscaling.

Инструменты агента и границы

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

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

Развёртывание начинается с шаблона CloudFormation, который создаёт управляемую среду, общий S3‑бакет и поддерживающие роли IAM, при этом веб‑интерфейс обслуживается из контейнера на порту 3099 и доступен через сессию перенаправления портов AWS Systems Manager.