Как компании строят MLOps: три архитектурных подхода

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

Это первая статья из цикла о том, как компании реализуют MLOps. Она будет полезна тем, кто строит или развивает ML-процессы в компании и хочет разобраться, почему под словом MLOps часто скрываются довольно разные практики и решения. 

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

Как внедрить MLOps в компании? И что из опыта ^[2] больших технологических компаний может быть применимо в российских реалиях?

На первый взгляд кажется, что это просто вопрос правильной сборки из знакомых технологий: MLflow для трекинга экспериментов, Airflow для пайплайнов, Docker и Kubernetes для деплоя, Prometheus и Grafana для мониторинга. Остаётся только связать всё это вместе — и кажется, что основная часть работы уже сделана. 

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

Ответ на вопрос «как внедрить MLOps» оказывается разным в зависимости от компании и конкретного случая. Именно поэтому полезно разбирать индустриальные примеры. Они позволяют увидеть, какие модели реализации MLOps вообще существуют и в каком контексте каждая из них оказывается уместной и достаточной.

Зарубежный опыт особенно важен, потому что крупные международные компании раньше других столкнулись с ML в промышленном масштабе и успели публично описать свои решения.

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

К вопросу о том, насколько зарубежный опыт применим в российских реалиях, мы ещё вернёмся в следующих статьях — уже на уровне конкретных реализаций. А пока вернёмся к основам.

Три индустриальные реализации MLOps

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

Условно можно выделить три основных подхода:

• инженерные workflow-фреймворки, 

• внутренние корпоративные ML-платформы, 

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

Это не конкурирующие продукты, а скорее разные архитектурные ответы на одну и ту же задачу — как превратить машинное обучение ^[3] из набора экспериментов в устойчивую производственную систему. Рассмотрим их по порядку.

Workflow-фреймворки: когда проблема не в продакшене, а в хаосе разработки

Первый частый путь — не строить сразу тяжелую платформу, а сначала навести порядок в процессе разработки моделей. Дело в том, что во многих компаниях боль ^[4] появляется не с инференсом, а гораздо раньше. 

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

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

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

Хороший пример такого подхода — Netflix Metaflow. Его мы рассмотрим в одной из следующих статей. Это open-source фреймворк, который позволяет описывать ML-процессы как граф шагов прямо в Python. Metaflow берёт на себя передачу данных между шагами, сохранение артефактов и метаданных, а также историю запусков. 

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

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

Внутренние ML-платформы: когда машинное обучение перестаёт быть набором инструментов

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

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

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

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

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

В следующей статье мы подробно разберём её архитектуру и посмотрим, как такие системы устроены изнутри.

Здесь важно одно: корпоративная ML-платформа — это уже не просто «удачно собранный стек», а отдельный продукт внутри компании. У него есть своя команда и свои стандарты, которые нужно постоянно развивать и поддерживать.

Ограничения подхода. Собственная платформа — не универсальный ответ. Для многих компаний это может быть слишком тяжёлый путь по стоимости, срокам и объёму поддержки. Часто это происходит, когда:

• ML-команд немного,

• инфраструктура не требует сложной кастомизации,

• нет жёстких требований к размещению вычислений и данных,

• важно быстрее запускать ML-проекты, чем полностью контролировать инфраструктуру.

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

Managed-платформы: когда часть MLOps уже собрана за вас

Третий сценарий — опереться на managed-платформу облачного провайдера. Вместо многомесячной или даже многолетней сборки собственной платформы команда получает готовую среду — целиком или по частям. 

Обучение моделей, запуск пайплайнов, хранение версий, сервисы инференса и базовый мониторинг уже доступны внутри облачной платформы и доступны через API, SDK и веб-интерфейсы.

С инженерной точки зрения ^[5] это выглядит так: вместо того чтобы самостоятельно собирать ML-контур из отдельных компонентов, команда работает с готовыми сущностями вроде training jobs, pipelines, model registry или inference endpoints. А всё, что находится под капотом, берёт на себя провайдер: масштабирование вычислений, выделение ресурсов, отказоустойчивость и так далее.

Именно так устроены, например, Google Vertex AI, Amazon SageMaker, а в российском облачном ландшафте — Yandex DataSphere и Yandex AI Studio. О них мы тоже поговорим в будущих статьях.

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

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

Почему у MLOps нет единого правильного сценария

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

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

Обычно выбор подхода определяется довольно простыми вещами:

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

2. Ресурсы. Собственная платформа — это отдельный внутренний продукт, который нужно проектировать, развивать и поддерживать. На это нужны и люди, и время.

3. Модель ответственности за инфраструктуру. Если компания хочет полный контроль над вычислениями, данными, деплоем и внутренними стандартами, она естественным образом движется в сторону собственного платформенного слоя. Если же важнее быстрее получить рабочий контур и сократить объём инфраструктурной рутины, может оказаться гораздо разумнее managed-подход.

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

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

В будущих статьях мы рассмотрим не только сами инструменты, но и разные архитектурные модели, которые за ними стоят: от платформенного подхода Uber Michelangelo до workflow-логики Netflix Metaflow и managed-экосистем. Инструменты могут отличаться очень сильно, но бизнес-запрос в основе обычно один и тот же: быстрее выводить модели в прод, не терять воспроизводимость, контролировать качество и не утонуть в инфраструктурной сложности.

В следующей статье подробнее разберём один из самых известных примеров внутренней ML-платформы — Uber Michelangelo — и посмотрим, как такие системы устроены изнутри.