Всем привет! Меня зовут Катерина Цаплина, я 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-инженер — это не тот, кто знает больше названий сервисов, а тот, кто умеет собрать правильную архитектурную модель под конкретный бизнес-контекст.