«Не хватало фактов, а не рассуждений»: AWS показала шесть skills для деплоя моделей Hugging Face на SageMaker AI

Дюжина решений перед первым запросом

18 сентября 2026 года Amazon Web Services опубликовала в блоге Machine Learning разбор того, почему кодинг-агент сам по себе не доводит модель Hugging Face до production. Перед запуском нужно принять около дюжины решений: выбрать serving-контейнер под архитектуру модели, подтвердить актуальный тег образа для своего региона AWS и подобрать instance type под объём памяти модели.

Дальше начинается инфраструктура: нужно настроить autoscaling, чтобы не сжигать GPU-часы на простаивающем endpoint, и поставить алармы Amazon CloudWatch, которые поймают тихие отказы раньше пользователей; после этих решений, по формулировке AWS, SageMaker AI сжимает работу до часов.

AWS прямо называет такие задачи подходящими для кодинг-агентов вроде Kiro и Claude Code, но предупреждает: неуправляемый агент может принять неверные решения и вернуть endpoint, который окажется хрупким, дорогим или незаметно неправильным.

Два теста и две неудачи

В тесте AWS агенты Kiro (Auto или Claude Fable 5) и Claude Code (Opus 4.8) получили одну задачу: развернуть модель Qwen/Qwen3-0.6B на real-time endpoint, сначала записать план в файл и вести журнал каждого действия.

Оба агента сначала выбрали serving-контейнером Text Generation Inference (TGI) — понятный выбор, потому что TGI годами был стандартом и учебные материалы по моделям ведут именно к нему. Но доступная в регионе сборка TGI появилась раньше архитектуры Qwen3 и не смогла загрузить модель: endpoint не прошёл health check, агент поднял версию TGI, развернул заново, снова получил отказ и только после этого перешёл на vLLM — причём каждая неудачная попытка тарифицировала GPU-время.

Второй запрос провалился тише: агенту предложили развернуть мультимодальную mixture-of-experts diffusion-модель, выпущенную за несколько недель до теста, и он снова собрал скрипт на TGI — сервере текстовой генерации без backend для discrete-diffusion модели, которая работает и с изображениями, и с текстом. Ничего не упало громко, а endpoint просто не поднялся бы.

Причину AWS формулирует так: не хватало фактов о развёртывании, а не рассуждений — агент хорошо планировал и отлаживал, но не знал, что новым моделям Qwen нужен vLLM, что для Python 3.13 нет рабочих wheels у большей части ML-стека и что образы контейнеров следует брать из опубликованного каталога AWS Deep Learning Containers. Это знание меняется быстрее, чем обновляются веса моделей, поэтому в AWS вынесли его в редактируемые файлы skills, а не стали ждать, пока его впитает очередной релиз модели.

Шесть skills вместо дюжины решений

Набор состоит из планировщика и пяти подчинённых skills: hf-cloud-sagemaker-deployment-planner оркестрирует остальные — hf-cloud-aws-context-discovery (контекст локального AWS), hf-cloud-python-env-setup (изолированное окружение Python), hf-cloud-sagemaker-iam-preflight (проверка исполняющей роли), hf-cloud-serving-image-selection (семейство контейнера и актуальный image URI) и hf-cloud-sagemaker-production-defaults (развёртывание с autoscaling, алармами и тегами).

Все шесть лежат в открытом репозитории huggingface/skills. Skill — это папка с обязательным файлом SKILL.md, где есть метаданные (как минимум имя и описание) и инструкции, а агент подгружает skill по требованию, когда описание совпадает с текущей задачей; сами skills совместимы с Claude Code, Codex, Gemini CLI и Cursor.

В посте приведён урезанный фрагмент hf-cloud-serving-image-selection: он предписывает предпочитать контейнеры Hugging Face — vLLM Inference для LLM и генеративных реранкеров, vLLM-Omni для мультимодальных моделей, TEI для эмбеддингов и cross-encoder реранкеров — и разрешать образ из каталога AWS DLC.

Что агент делает сам, а что остаётся человеку

Работа разбита на шесть фаз: discovery контекста AWS (профиль, регион, аккаунт, caller identity) только через read-only вызовы; изолированное окружение Python с актуальным boto3; поиск существующей исполняющей роли SageMaker AI с созданием новой только при её отсутствии и наличии прав; выбор контейнера и разрешение image URI из каталога AWS DLC; создание модели, endpoint configuration и endpoint с autoscaling и алармами CloudWatch; затем smoke-тест живого endpoint с отчётом о результате.

Две находки AWS показывают, что агент сохраняет суждение внутри процесса. Когда запрос к Amazon ECR за новейшим тегом образа был отклонён из-за отсутствия разрешения ecr-public:DescribeImages у роли IAM Identity Center, агент не остановил развёртывание, а откатился к заведомо рабочему тегу, который поставляется со skill, и записал причину в журнал.

Во втором случае smoke-тест вернул HTTP 200, но ответ модели так и не пришёл: реплика обрезалась по max_tokens внутри reasoning-блока Qwen3. Агент отметил это в журнале как проблему конфигурации и предложил поднять лимит токенов вместо того, чтобы считать тест пройденным.

Подготовка требует аккаунта AWS с правами на SageMaker AI и исполняющей роли, AWS CLI v2, Python 3.10, 3.11 или 3.12 (3.13 и новее не поддерживаются, потому что большая часть ML-стека ещё не публикует для них wheels), кодинг-агента с поддержкой skills и git.

Цена референсного развёртывания и teardown

В примере AWS модель Qwen/Qwen3-0.6B развёрнута на одном real-time instance ml.g5.xlarge в регионе US East (N. Virginia) (us-east-1), а перед запуском рекомендуется убедиться, что в аккаунте есть квота под этот тип инстанса.

Production defaults, которые skill применяет к каждому endpoint, в примере выглядят так: модель qwen3-06b-internal, конфигурация qwen3-06b-internal-20260904-1913-config и сам endpoint qwen3-06b-internal-20260904-1913 с ценой $1.408 в час за инстанс, autoscaling от 1 до 4 инстансов и три аларма CloudWatch — на 5XX-ошибки вызовов, P99-латентность модели и P99-латентность overhead.

Real-time endpoint тарифицируется непрерывно, пока существует, поэтому в набор входит skill sagemaker-production-defaults со скриптом teardown.py: он удаляет ресурсы развёртывания и подтверждает, что endpoint, конфигурация и модель действительно удалены, а autoscaling-политику и алармы CloudWatch нужно проверить и удалить отдельно, если они остались.

Что это меняет

AWS описывает результат прямо: шесть переиспользуемых agent skills превращают неуправляемого кодинг-агента в такого, который разворачивает модели Hugging Face на endpoint SageMaker AI с готовыми к production возможностями — правильным контейнером, autoscaling, алармами CloudWatch и проверяемым teardown.

Практический смысл здесь не в новой модели, а в способе хранить знание о развёртывании: конкретные версии контейнеров, поддержка Python и требования к железу устаревают быстрее, чем выходят релизы моделей, и переносятся в редактируемые файлы skills, которые можно версионировать вместе с кодом.

Публикация также указывает на альтернативы для тех, кому не нужен собственный агентский сценарий: разворачивать популярные модели Hugging Face из консоли через Amazon SageMaker JumpStart и подбирать инстанс по бенчмаркам с помощью Inference Recommendations. Ограничение набора названо честно: он собирался и тестировался на конкретной ревизии репозитория huggingface/skills, поэтому после обновления репозитория версии skills нужно фиксировать заново.