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

Всем привет! Меня зовут Катерина Цаплина, я 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 Архитектура фреймворка состоит из нескольких независимых слоёв: слоя выполнения вычислений, хранилища артефактов и отдельного контура метаданных. Именно их сочетание обеспечивает воспроизводимость экспериментов, отслеживаемость запусков и переносимость вычислений между различными средами выполнения. Верхнеуровневая архитектура 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, оркестрацию процессов, мониторинг инфраструктуры и моделей. Начать учиться можно бесплатно.