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

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

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

Почему собственная платформа не для всех

Давайте на мгновение вернёмся к теме предыдущей статьи. 

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

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

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

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

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

Workflow-подход: когда нужен порядок, но не нужна платформа

Одним из наиболее интересных представителей workflow-подхода является Metaflow — open-source фреймворк, разработанный в Netflix для организации и управления ML-проектами. Его основная идея: превратить процесс разработки моделей из набора разрозненных ноутбуков и скриптов в воспроизводимый и управляемый процесс. 

Проблема, которую он решает, знакома большинству команд:

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

Metaflow решает эту проблему через концепцию workflow.

Workflow в Metaflow — это граф шагов (steps), где каждый шаг представляет собой изолированный фрагмент Python-кода с явными входами и выходами. Разработчик описывает полный процесс обработки данных, обучения и оценки модели как единую последовательность связанных этапов. 

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

Однако для Metaflow процесс — не просто последовательность шагов. Чтобы обеспечить воспроизводимость, отслеживаемость и возможность вернуться к любому эксперименту спустя месяцы или даже годы, фреймворк формирует вокруг вычислений собственную объектную модель.

Объектная модель Metaflow

Важная особенность Metaflow заключается в том, что workflow рассматривается не просто как запуск скрипта, а как набор связанных сущностей:

• центральная сущность — Flow: описание процесса в виде графа шагов;

• каждый запуск такого процесса становится отдельным Run;

• внутри Run выполняются отдельные Step;

• конкретное выполнение шага представлено сущностью Task;

• результаты сохраняются в виде Data Artifacts.

С точки зрения пользователя всё выглядит как обычный Python-код. Но внутри каждый эксперимент превращается в набор связанных объектов со своей историей, параметрами, состоянием и артефактами. Такая модель позволяет Metaflow хранить не только результаты вычислений, но и весь контекст их получения.

Архитектура Metaflow

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

Как видно на схеме, архитектура Metaflow разделяет вычисления, хранение результатов и управление метаданными.

За выполнение шагов процесса отвечает Runtime. В зависимости от конфигурации вычисления могут выполняться локально на машине разработчика, в AWS Batch или в Kubernetes-кластере. При запуске Metaflow формирует пакет кода (Code Package), сохраняет его снимок (Code Snapshot) и передаёт выполнение в выбранную вычислительную среду.

Результаты работы шагов сохраняются в Datastore. Здесь хранятся модели, датасеты, метрики и другие артефакты процесса. В качестве хранилища обычно используются объектные сервисы, например Amazon S3.

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

Такое разделение даёт важное архитектурное преимущество: вычисления, данные и служебная информация существуют независимо друг от друга и могут масштабироваться отдельно. Например, модель может обучаться в Kubernetes-кластере, артефакты сохраняться в объектное хранилище, а история запусков — храниться в отдельном сервисе метаданных.

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

Разделение логики и инфраструктуры

Архитектура Metaflow отражает ещё один важный принцип: описание вычислительного процесса не зависит от среды его выполнения.

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

Именно в этом заключается один из ключевых архитектурных принципов Metaflow: отделить описание вычислений от конкретной вычислительной среды. Благодаря этому команды могут постепенно масштабировать нагрузку — от локальных экспериментов до кластерных вычислений — не переписывая ML-процессы при каждом изменении инфраструктуры.

Workflow как Python-код

Интересно, что Netflix сознательно отказался от отдельного языка описания пайплайнов. Вместо YAML-файлов или собственного DSL workflow описывается обычным Python-кодом. Упрощённый пример может выглядеть так:

from metaflow import FlowSpec, step
class TrainingFlow(FlowSpec):
    @step
    def start(self):
        self.data = load_data()
        self.next(self.train)
    @step
    def train(self):
        self.model = train_model(self.data)
        self.next(self.evaluate)
    @step
    def evaluate(self):
        self.metrics = evaluate_model(self.model)
        self.next(self.end)
    @step
    def end(self):
        print("Done")

Разработчик описывает этапы вычислений через методы класса и связывает их между собой с помощью self.next(). При этом Metaflow автоматически создаёт объект Run, отслеживает выполнение шагов, сохраняет параметры, артефакты и историю запусков. 

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

Управление окружениями и ресурсами

Ещё одна сильная сторона Metaflow — управление окружениями и вычислительными ресурсами через декораторы. Например:

from metaflow import conda, resources
@conda(libraries={"pytorch": "2.1.0"})
@resources(cpu=4, memory=16000, gpu=1)
@step
def train(self):
  	...

Зависимости окружения и требования к ресурсам становятся частью описания процесса и версионируются вместе с кодом. Описание ресурсов при этом не привязано к конкретной вычислительной среде: одна и та же логика может выполняться локально, в облаке или в Kubernetes-кластере без изменения пользовательского кода. 

Это помогает сохранять воспроизводимость вычислений и упрощает масштабирование ML-проектов по мере роста нагрузки. 

Архитектурные границы Metaflow

Важно не приписывать Metaflow то, чего он изначально не обещает. Его сильная сторона — организация разработки, экспериментов и вычислений. Он хорошо интегрируется с системами оркестрации и инфраструктурными платформами, однако сам по себе не является платформой управления продакшен-инференсом уровня крупных корпоративных решений.

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

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

Не только Metaflow

Metaflow — не единственный представитель workflow-подхода. В индустрии существует целое семейство инструментов, решающих схожую задачу: к таким решениям относятся Flyte, Prefect, Dagster и другие. При этом внутри самого класса существуют заметные различия.

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

Flyte ориентирован на более масштабные production-grade ML-пайплайны и тесную интеграцию с Kubernetes. Prefect и Dagster выросли из задач оркестрации данных и постепенно расширились в сторону MLOps.

Особый случай представляет Kubeflow. Несмотря на наличие workflow-компонентов, его обычно рассматривают не как отдельный workflow-фреймворк, а как попытку построить полноценную ML-платформу поверх Kubernetes.

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

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

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

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

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

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

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

Сегодня Metaflow используется не только в Netflix. Среди известных пользователей проекта упоминаются 23andMe, CNN, SAP, Realtor​.​com, Goldman Sachs, DoorDash и другие компании. По данным команды проекта, Metaflow применяется сотнями организаций и поддерживает тысячи ML- и AI-проектов в различных отраслях — от электронной коммерции и медиасервисов до финансового сектора и здравоохранения.

По мере роста числа моделей и команд многие организации начинают искать следующий уровень абстракции — готовую платформу, которая предоставляет основные ML-сущности и инфраструктурные сервисы в виде управляемого сервиса. 

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

В следующей статье разберём этот подход подробнее. На примерах Google Vertex AI, Yandex DataSphere и Yandex AI Studio рассмотрим, как managed-платформы устроены изнутри, в чём их преимущества и чем они отличаются от workflow-фреймворков. А также подведем итог всей серии статей.

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