Как компании строят MLOps без собственной ML-платформы: managed-сервисы

Всем привет! Меня зовут Катерина Цаплина, я AI Architect и программный эксперт курса «MLOps для разработки и мониторинга моделей». Работаю на стыке ML, инфраструктуры и корпоративной архитектуры в крупной промышленной компании и на практике вижу, насколько непросто выстраивать такие процессы в реальной организации.  

Это четвёртая и финальная статья цикла о том, как компании реализуют MLOps. В предыдущих частях мы разобрали, как компании могут строить MLOps в целом, рассмотрели пример внутренней ML-платформы Uber Michelangelo и на примере Netflix Metaflow разобрались, как workflow-фреймворки помогают навести порядок в ML-разработке.

Сегодня разберём ещё одну альтернативу собственной платформе: managed-сервисы облачных провайдеров. На примерах Google Vertex AI, Yandex DataSphere и Yandex AI Studio рассмотрим, как они устроены и чем будут полезны команде и бизнесу. И, наконец, подведём итог всей серии статей. 

Где мы остановились 

В статье об Uber Michelangelo мы пришли к простому выводу: создание платформы уровня Michelangelo требует серьёзных вложений. Собственная платформенная команда, развитая инфраструктура, многолетняя эволюция внутренних процессов — большинству компаний такой путь не нужен и не окупится. 

Поэтому на практике компании чаще выбирают один из двух более лёгких подходов: 

• workflow-фреймворки 

• или managed-платформы облачных провайдеров.

Workflow-фреймворки помогают навести порядок на этапе разработки: превратить разрозненные ноутбуки и скрипты в воспроизводимый вычислительный процесс с историей запусков, хранением артефактов и контролем зависимостей между шагами. Хороший первый шаг, но лишь часть задач жизненного цикла моделей. Вычислительные ресурсы, хранение, развёртывание и мониторинг по-прежнему остаются на стороне команды. 

По мере роста числа моделей и команд этого перестаёт хватать. Когда нужен не просто воспроизводимый процесс обучения, а полноценный контур управления жизненным циклом — от данных до мониторинга в продакшене, компании начинают смотреть в сторону managed-платформ облачных провайдеров. 

Managed-подход: когда платформу предоставляет облако 

Идея простая: вместо того чтобы собирать ML-инфраструктуру из отдельных компонентов, компания получает готовый платформенный слой как сервис. Обучение моделей, оркестрация пайплайнов, реестр моделей, развёртывание и мониторинг — всё это уже встроено и доступно через API, SDK и веб-интерфейс. 

Один из самых известных представителей такого подхода — Google Vertex AI. Архитектурно он во многом напоминает Uber Michelangelo, но с принципиальным отличием. 

Если в Michelangelo весь платформенный слой создаёт и поддерживает внутренняя инженерная команда Uber, то в Vertex AI эту роль берёт на себя облачный провайдер. Компания получает готовые сервисы для обучения, развёртывания и эксплуатации моделей и может сосредоточиться на моделях и бизнес-задачах, а не на построении инфраструктуры.

Внутренняя модель Vertex AI

Если посмотреть на Vertex AI изнутри, становится заметно, что архитектурно он во многом напоминает внутренние ML-платформы крупных компаний.

На уровне данных команды обычно используют сервисы экосистемы Google Cloud — например, Cloud Storage и BigQuery. Поверх них располагается ML-контур Vertex AI, который включает обучение моделей, эксперименты, пайплайны, реестр моделей, сервисы инференса и мониторинг. 

Фактически Google уже собрал для пользователя основные сущности жизненного цикла модели в единый платформенный слой. Поэтому работа с Vertex AI выглядит не как управление отдельными инфраструктурными компонентами, а как работа с готовыми объектами: заданиями обучения, экспериментами, пайплайнами, моделями и эндпоинтами. 

В последние годы этот платформенный контур существенно расширился в сторону генеративного ИИ. Помимо сервисов для классического жизненного цикла ML-моделей, Vertex AI теперь включает Vertex AI Studio, доступ к Gemini-моделям, инструменты для построения RAG-сценариев и AI-агентов, средства оценки качества генеративных систем и другие сервисы для создания AI-приложений. Это отражает общий тренд развития платформ: от управления отдельными моделями к построению и эксплуатации полноценных AI-систем.

Управляемые вычисления: Training Job 

Когда инженеру необходимо обучить модель, он не разворачивает вычислительную инфраструктуру самостоятельно. Вместо этого создаётся объект Training Job, в котором описываются: образ контейнера, параметры обучения, требования к вычислительным ресурсам, конфигурация запуска. 

После этого платформа автоматически создаёт необходимую инфраструктуру и выполняет задачу. С точки зрения пользователя обучение выглядит как вызов API или SDK. С точки зрения платформы это полноценный управляемый жизненный цикл вычислительного задания.

Именно здесь хорошо видно различие между workflow-фреймворком и managed-подходом. В Metaflow пользователь описывает процесс и самостоятельно выбирает вычислительную среду. В Vertex AI вычислительная среда уже встроена в платформу.

Например, если дата-сайентисту нужно обучить модель на нескольких GPU, не нужно самостоятельно разворачивать Kubernetes-кластер, подготавливать вычислительные узлы или заниматься распределением ресурсов. Достаточно создать Training Job и указать параметры вычислений. Большая часть инфраструктурной сложности скрыта внутри платформы.  

Эксперименты и воспроизводимость 

Experiments — компонент для отслеживания запусков, параметров и результатов. Он позволяет связывать между собой: параметры запуска, метрики, артефакты, результаты экспериментов, модели. Это помогает избежать ситуации, когда десятки запусков существуют отдельно друг от друга и спустя несколько месяцев уже невозможно понять, какой из них привёл к появлению продакшен-модели.

Таким образом воспроизводимость становится встроенной функцией платформы, а не дополнительным сервисом, который команда должна разворачивать самостоятельно.

Пайплайны как управляемая оркестрация 

В Pipelines пользователь описывает процесс подготовки данных, обучения, оценки качества и регистрации модели как последовательность связанных шагов, а выполнение этого процесса, хранение его состояния и управление жизненным циклом пайплайна реализуются средствами Vertex AI. 

В результате инженер продолжает работать с привычным Python-кодом и ML-логикой, а большая часть инфраструктурной и эксплуатационной работы переносится на уровень сервисов платформы. Пайплайн становится не просто набором скриптов, а управляемым объектом, который можно запускать повторно, отслеживать и интегрировать в общий жизненный цикл модели. 

Model Registry и Endpoint

После обучения модель может быть зарегистрирована в Model Registry. Модель перестаёт быть просто файлом в хранилище и становится управляемой сущностью платформы: с версией, метаданными, историей изменений, жизненным циклом и связями с экспериментами и пайплайнами. 

Следующим шагом становится развёртывание через Endpoint. Endpoint в Vertex AI представляет собой управляемую точку доступа к модели, которая обеспечивает: масштабирование, балансировку нагрузки, версионирование, распределение трафика между версиями модели.

С точки зрения архитектуры именно здесь заканчивается жизненный цикл модели как артефакта и начинается её эксплуатация как сервиса.

Мониторинг как часть платформы

Ещё одна характерная особенность managed-подхода — встроенный мониторинг. В Vertex AI мониторинг не собирается вручную из отдельных компонентов. Платформа уже содержит механизмы наблюдения за моделями.

Например, Model Monitoring поддерживает:

• отслеживание drift по признакам;

• контроль training-serving skew;

• анализ распределений данных;

• мониторинг качества инференса.

Это хороший пример того, как в managed-подходе даже наблюдаемость становится частью платформенного слоя.

Что получает бизнес

Ценность Vertex AI заключается в сокращении пути от идеи до продакшен-модели. Компания получает готовый платформенный слой для обучения, оркестрации, регистрации моделей, развёртывания, мониторинга. Это позволяет быстрее масштабировать ML-практику и существенно снизить объём инфраструктурной работы.

Компромисс тоже очевиден: часть контроля над архитектурой и инфраструктурой передаётся облачному провайдеру, а зависимость от его экосистемы становится выше. 

Сегодня Vertex AI используется тысячами организаций по всему миру. Среди известных пользователей платформы упоминаются General Motors, Wayfair, Deutsche Bank, Mayo Clinic и другие компании, использующие её для задач прогнозирования, рекомендательных систем, аналитики данных и генеративного ИИ. 

Это делает Vertex AI одним из наиболее показательных примеров managed-подхода, где значительная часть платформенной сложности уже реализована облачным провайдером и доступна через готовые сервисы и API.

Vertex AI vs Metaflow: разные уровни абстракции 

Если Metaflow представляет собой workflow layer, то Vertex AI можно рассматривать как platform layer as a service. Metaflow помогает организовать вычисления и эксперименты. Vertex AI предоставляет готовый платформенный контур управления основными ML-сущностями. 

Именно поэтому эти решения не являются прямыми конкурентами. Они находятся на разных уровнях архитектурной абстракции и отвечают на разные потребности организаций.

Для команды, которой необходимо стандартизировать процесс разработки, может быть достаточно workflow-фреймворка. Для компании, которая хочет быстро получить полноценную ML-платформу без многолетнего строительства собственной инфраструктуры, managed-подход становится вполне естественным выбором.

Не только Vertex AI

За последние годы практически все крупные облачные провайдеры начали развивать собственные управляемые платформы для машинного обучения. Несмотря на различия в интерфейсах и наборах сервисов, общая идея остаётся одинаковой: предоставить командам готовый платформенный слой для обучения, развёртывания и эксплуатации моделей без необходимости самостоятельно строить значительную часть инфраструктуры.

Наиболее известные представители этого класса: 

• Vertex AI исторически развивался как единая облачная платформа полного цикла, объединяющая обучение моделей, эксперименты, пайплайны, реестр моделей, сервисы инференса и инструменты для генеративного ИИ.

• Amazon SageMaker во многом решает похожие задачи, но традиционно делает более сильный акцент на интеграцию с экосистемой AWS и поддержку крупных производственных ML-нагрузок.

• Azure Machine Learning тесно интегрирован с сервисами Microsoft Azure и корпоративными инструментами управления данными, безопасностью и DevOps-процессами.

• Yandex DataSphere и Yandex AI Studio реализуют похожую модель в экосистеме Yandex Cloud, сочетая классические сценарии машинного обучения с сервисами для генеративного ИИ и агентных приложений.

С архитектурной точки зрения различия между этими платформами обычно связаны не столько с базовыми возможностями, сколько с экосистемой провайдера, набором интеграций, подходами к безопасности, управлению ресурсами и поддержкой конкретных сценариев использования.

Yandex DataSphere и Yandex AI Studio 

Для российских команд интерес представляет ещё один вопрос: как аналогичные архитектурные идеи реализуются в локальной облачной экосистеме. 

За последние годы российские провайдеры также начали развивать собственные managed-платформы для машинного обучения и генеративного ИИ. Хотя набор сервисов и экосистемы отличаются от решений Google, AWS или Microsoft, базовая архитектурная идея остаётся той же: предоставить командам готовый платформенный слой для работы с моделями и вычислениями. 

Здесь роль управляемой ML-платформы выполняет не один сервис, а связка Yandex DataSphere и Yandex AI Studio. DataSphere ориентирован на классический ML-контур: разработку моделей, запуск вычислений, обучение и развёртывание. AI Studio закрывает другой класс задач — работу с большими языковыми моделями, агентными сценариями и генеративными AI-приложениями. 

В этом одно из заметных отличий от Vertex AI. Если Google развивает единую платформу, объединяющую классический ML и GenAI-сервисы, то в экосистеме Yandex Cloud эти направления разделены между двумя специализированными продуктами.

DataSphere: управляемая среда для ML-разработки

С архитектурной точки зрения DataSphere можно рассматривать как managed-среду для полного жизненного цикла ML.

Для пользователя всё начинается с привычного JupyterLab, однако за этим интерфейсом скрывается готовый платформенный слой. При создании проекта автоматически выделяются вычислительные ресурсы, подготавливается рабочее окружение и предоставляется доступ к инфраструктурным сервисам. Инженеру не нужно вручную поднимать виртуальные машины, устанавливать зависимости или настраивать базовую вычислительную среду. 

Работа в DataSphere обычно развивается по такому сценарию:

• разработка и эксперименты в Notebook;

• запуск тяжёлых вычислений через DataSphere Jobs;

• публикация модели через DataSphere Inference.

Получается естественный путь от исследования к эксплуатации внутри одного управляемого контура.

DataSphere Jobs позволяют запускать Python-приложения, ML-пайплайны и пакетные вычисления вне ноутбуков, а платформа берёт на себя подготовку окружения и выполнение задач. Концептуально Jobs близок к Training Job в Vertex AI. 

Для развёртывания моделей используется DataSphere Inference. Сервис поддерживает как классические ML-модели, так и произвольные Docker-образы, а для инференса использует Triton Inference Server. Благодаря этому модель перестаёт быть просто результатом эксперимента и становится полноценным сервисом со своим жизненным циклом. 

Дополнительно DataSphere включает доступ к foundation-моделям семейства YandexGPT, YandexART и ряду open-source моделей. Это хорошо показывает современную тенденцию: граница между классическим MLOps и инфраструктурой генеративного ИИ постепенно исчезает. 

Подробнее: «Машинное обучение и анализ данных — Yandex DataSphere», «Yandex DataSphere | Yandex Cloud — Документация».

AI Studio: от моделей к ИИ-приложениям

Если DataSphere ориентирован на ML-разработку и вычисления, то AI Studio решает другую задачу — создание GenAI- и агентных приложений. В центре внимания здесь уже не модели как таковые, а более высокоуровневые сущности:

• foundation-модели;

• агенты;

• инструменты;

• RAG-сценарии;

• интеграции с внешними системами;

• многокомпонентные ИИ-приложения.

Для этого в AI Studio доступны Model Gallery, Agent Atelier, MCP Hub, Workflows, OpenAI-совместимые API и инструменты для работы с embeddings. 

Особенно интересен MCP Hub — слой интеграции, который позволяет подключать к агентам базы знаний, корпоративные API и внешние сервисы через Model Context Protocol (MCP). Это хорошо иллюстрирует современный сдвиг индустрии: если раньше платформы строились вокруг моделей, то теперь всё чаще — вокруг AI-систем и агентов. 

В свою очередь Workflows позволяют описывать уже не процессы обучения моделей, а поведение самих AI-приложений: последовательности действий, обращения к инструментам, ветвления и интеграционные сценарии.

Подробнее: Yandex AI Studio, Документация AI Studio.

Сегодня DataSphere и AI Studio используются тысячами организаций для построения ML- и GenAI-решений.

По данным Яндекса, платформой AI Studio пользуются более 40 тысяч клиентов, а число развёрнутых на ней AI-агентов превышает 7,5 тысячи. Это делает связку DataSphere и AI Studio одним из наиболее заметных примеров managed-подхода к ML и генеративному ИИ на российском рынке. 

Подробнее: «Поддержка, HR и финансы: как российский бизнес использует ИИ-агентов», «Клиенты Yandex AI Studio увеличили потребление генеративных нейросетей в облаке в пять раз».

Подведём итоги

Если посмотреть на Uber Michelangelo, Netflix Metaflow, Google Vertex AI, Yandex DataSphere и Yandex AI Studio вместе, становится понятно: это решения, появившиеся в разном организационном и технологическом контексте. Их не стоит сравнивать по принципу «какое лучше». 

Гораздо полезнее воспринимать их как разные ответы на один и тот же вопрос: как организовать жизненный цикл моделей и AI-систем так, чтобы машинное обучение перестало быть набором разрозненных экспериментов и стало управляемым производственным процессом. 

• Michelangelo, как внутренняя корпоративная ML-платформа, показывает путь компании, в которой ML уже стал критически важной частью бизнеса. Это пример внутренней корпоративной платформы, где MLOps становится отдельной инженерной дисциплиной.

• Metaflow, как workflow-фреймворк, показывает другой подход. Здесь фокус смещён с централизованного управления продакшеном на воспроизводимость исследований и вычислений. Это не платформа полного цикла, а инженерный слой, который помогает командам системно работать с экспериментами, артефактами и вычислительными процессами.

• Vertex AI представляет managed-модель для классического ML. Здесь облачный провайдер берёт на себя роль платформенной команды и предоставляет готовый control plane для основных ML-сущностей: обучения, экспериментов, пайплайнов, моделей и инференса.

Если смотреть на эти примеры вместе, речь не столько о выборе инструмента, сколько о выборе архитектурной стратегии. Попытка построить собственную Michelangelo слишком рано почти всегда приводит к переусложнению и росту затрат. Попытка долго жить в режиме «ноутбуки, скрипты и ручные договорённости» при большом количестве моделей почти всегда заканчивается хаосом. 

Главный вывод прост: 

Универсального правильного решения для MLOps не существует — существует только архитектурная стратегия, подходящая для конкретного бизнеса, команды и уровня зрелости.

Если вам интересны MLOps, ML-платформы и промышленная эксплуатация моделей, обратите внимание на наш курс «MLOps для разработки и мониторинга моделей» от Яндекс Практикума. На курсе подробно разбираем полный жизненный цикл ML-систем: организацию ML-проектов, управление данными и версиями моделей, воспроизводимость экспериментов, контейнеризацию, CI/CD, оркестрацию, мониторинг инфраструктуры и моделей. 

И напоследок мысль, которая, на мой взгляд, хорошо отражает суть всей серии статей:

Хороший MLOps-инженер — это не тот, кто знает больше названий сервисов, а тот, кто умеет собрать правильную архитектурную модель под конкретный бизнес-контекст.