AWS связала MLflow с SageMaker Model Registry для управления AI-моделями

От журнала экспериментов к реестру кандидатов

AWS расширила синхронизацию между managed MLflow в Amazon SageMaker AI и SageMaker AI Model Registry. Когда специалист регистрирует модель в MLflow, сервис создаёт соответствующие Model Package Group и версию пакета в реестре. Вместе с записью переносятся метрики обучения и оценки, готовая к развёртыванию inference specification и lineage исходного MLflow run.

Смысл изменения — убрать разрыв между средой, где команда сравнивает эксперименты, и системой, где организация решает, какая модель может перейти в production. Data scientists сохраняют привычный MLflow как рабочую систему для runs и logged models, а governance officers получают единое представление о зарегистрированных кандидатах без ручной повторной регистрации и переноса контекста.

Синхронизацию нужно включить явно

Model Registry sync остаётся opt-in возможностью. При создании или обновлении MLflow app администратор задаёт режим `AutoModelRegistrationEnabled`; по умолчанию автоматическая регистрация выключена. Service role приложения также нужны права на создание Model Package Groups и версий, добавление тегов и запись lineage. Поэтому одна настройка интерфейса не заменяет корректную IAM-конфигурацию.

После включения поток становится синхронным: регистрация модели в MLflow создаёт объект в Model Registry. В реестр попадает не только ссылка на артефакт. Inference specification описывает container image URI, `ModelDataUrl` в Amazon S3 и поддерживаемые типы instances для real-time inference. Это превращает запись кандидата в пакет, который можно предметно проверить перед допуском к развёртыванию.

Две роли разделены IAM-ограничениями

В одноаккаунтной схеме AWS разделяет data scientist и governance officer не разными AWS-аккаунтами, а IAM guardrails. Первый обучает, логирует, регистрирует и переводит модели между рабочими стадиями из Jupyter notebook и MLflow. Второй работает в Models view SageMaker Studio: изучает синхронизированные метрики и lineage, продвигает версию к production и одобряет её для deployment.

Показанный guardrail запрещает роли data scientist выполнять `sagemaker:UpdateModelPackage`, когда целевая стадия равна `production`. Право продвижения остаётся у governance officer. После одобрения Model Package Group можно дополнительно пометить ресурсным тегом `frozen=true` и связать его с IAM deny condition, чтобы зафиксировать проверенную модель от дальнейших изменений.

Что именно видит проверяющий

В SageMaker Studio проверяющий получает связанные элементы одного процесса: training metrics, evaluation metrics, inference specification и lineage. Это важнее простого списка версий, потому что решение о выпуске можно сопоставить с конкретным run, результатами оценки и технической конфигурацией сервинга. Одобренную версию затем разворачивает ML engineer, обычно через CI/CD pipeline.

Плагин `sagemaker-mlflow` версии 0.5.0 добавляет логирование inference container image вместе с моделью. В артефактах также фигурируют `sagemaker_inference_specification.json` и `serving_input_example.json`. Таким образом, воспроизводимость deployment зависит не только от весов, но и от зафиксированного образа, обработчика и ожидаемого входа.

Автоматизация не отменяет контроль

Синхронизация ускоряет доставку кандидата в реестр, но не делает модель автоматически пригодной для production. AWS сохраняет отдельный этап review и approval: governance officer должен изучить данные и только затем изменить lifecycle stage. Само развёртывание также остаётся отдельной операцией, выполняемой после одобрения.

Это принципиальная граница решения. Новый механизм автоматизирует передачу модели и её контекста, а не заключение о качестве или безопасности. Если метрики неполны, evaluation не соответствует целевому сценарию или lineage указывает на неподходящие данные, наличие записи в Model Registry не должно трактоваться как разрешение на запуск. Реестр становится местом принятия решения, но содержание решения остаётся ответственностью организации.

Для одного аккаунта — минимальная базовая схема

Описанная в первой части архитектура рассчитана на организацию, где разработка и governance находятся в одном AWS-аккаунте. Её преимущества — меньше инфраструктурных связей и единый набор объектов; главный механизм разграничения — роли, condition keys и resource tags. Для старта AWS опубликовала notebook и вспомогательные scripts в официальном репозитории примеров.

Для компаний с несколькими development accounts этой схемы недостаточно: аккаунт сам становится границей изоляции, а артефакты и права приходится передавать между контурами. Именно поэтому AWS рассматривает одноаккаунтный вариант как фундамент, поверх которого строятся две более сложные cross-account топологии — централизованная и гибридная.