Урок 6: MLOps on-prem — MLflow + DVC + BentoML без облака

Чему вы научитесь

• Собирать on-prem MLOps-стек без Databricks, SageMaker и других облачных зависимостей
• Разделять tracking, data versioning, serving и monitoring — и не ждать, что один инструмент закроет всё
• Понимать, где MLflow действительно нужен, где достаточно DVC, а где уже пора в Kubeflow/KServe
• Не попадать в лицензионные ловушки вроде Seldon Core v2 под BSL
• Выстраивать MLOps так, чтобы он проходил и по санкционному контуру, и по TCO, и по требованиям ИБ

On-prem MLOps в промышленности — это не попытка «быть моднее Silicon Valley». Это инфраструктурная необходимость. Если у вас чувствительные производственные данные, ограничения по ПД, коммерческая тайна или санкционный риск, вы не можете строить жизненный цикл модели вокруг внешнего SaaS. Но и самодельный набор скриптов — тоже не путь. Нужна минимально дисциплинированная платформа.

Из каких слоёв состоит on-prem MLOps

Рабочая комбинация, которая обычно не ломается

Если говорить жёстко, большинству предприятий не нужен «идеальный MLOps». Им нужен стек, который можно реально администрировать своей командой.

Самая практичная базовая комбинация выглядит так:

• MLflow — tracking и model registry;
• DVC — version control для данных и артефактов;
• BentoML — быстрое заворачивание модели в сервис;
• KServe — если сервис надо стандартизировать на Kubernetes;
• Evidently / Alibi Detect — наблюдаемость и drift;
• self-hosted GitLab — CI и единый контур исходников.

MLflow в официальном репозитории прямо позиционируется как open-source AI engineering platform для models, LLMs и agents, с registry, observability и evaluation (mlflow/mlflow). Это уже давно больше, чем просто «трекер метрик».

DVC закрывает другую проблему: не «как логировать run», а как понимать, на каких данных и артефактах этот run вообще был получен. Это критично в промышленности, где через шесть месяцев у вас уже никто не помнит, на каком выгруженном historian-срезе обучалась модель (iterative/dvc).

Почему BentoML часто удобнее старта с KServe

KServe — отличный стандартный слой сервинга на Kubernetes. Но он раскрывается тогда, когда у вас уже есть платформенная команда, нормальный K8s и понятная практика выкладки моделей.

BentoML полезен раньше. Он даёт понятный Python-фреймворк, чтобы завернуть модель в сервис, собрать контейнер и сделать предсказуемый deployment-путь (bentoml/BentoML).

Практический подход такой:

• на первом production-контуре сервисуете модель через BentoML;
• когда сервисов становится много и нужен единый K8s serving layer, выносите их в KServe.

Это дешевле по организационному усилию, чем начинать сразу с самого тяжёлого платформенного варианта.

Где Feast нужен, а где это overkill

Feast — это feature store. Официальный репозиторий описывает offline store, online store и battle-tested feature server для production ML (feast-dev/feast). Но проблема в том, что feature store — это инструмент не для всех команд, а для зрелых платформенных команд.

Feast оправдан, если:

• у вас много моделей переиспользуют одни и те же признаки;
• есть онлайн- и офлайн-потребление признаков;
• вы реально живёте с риском training-serving skew.

Feast избыточен, если:

• у вас 1–3 модели и batch scoring;
• признаки спокойно живут в SQL / parquet / DVC;
• основная боль — не feature management, а вообще отсутствие нормального tracking.

Архитектура on-prem MLOps

flowchart LR
    A[GitLab CI] --> B[DVC: данные и артефакты]
    B --> C[Обучение / Kubeflow или Airflow]
    C --> D[MLflow Registry]
    D --> E[BentoML packaging]
    E --> F[KServe / Kubernetes]
    F --> G[Evidently / Alibi Detect]
    G --> H[Grafana / алерты / SLA]

Здесь важно разделение ответственности.

• GitLab и DVC отвечают за воспроизводимость.
• MLflow отвечает за знание, какая версия модели вообще существует и одобрена.
• BentoML / KServe отвечают за эксплуатацию inference.
• Evidently / Alibi Detect отвечают за то, что модель не деградировала молча.

Kubeflow или Airflow

Это не вопрос веры. Это вопрос центра тяжести платформы.

• Kubeflow Pipelines лучше, если у вас зрелый Kubernetes-first контур и ML действительно является важным platform workload (kubeflow/pipelines).
• Airflow лучше, если у вас уже есть сильный data engineering стек и ML — часть более широких ETL / data workflows (apache/airflow).

В промышленной компании Airflow часто выигрывает старт, потому что его уже знают. Kubeflow выигрывает масштаб, когда появляется отдельная ML platform team.

Почему on-prem вообще окупается

В модуле p.2 мы уже разбирали TCO. Здесь важно другое: on-prem MLOps окупается не только за счёт токенов или GPU-часов. Он окупается за счёт управляемости.

• не нужен внешний SaaS для registry и serving;
• нет вынужденного вывода чувствительных данных наружу;
• проще проходить ИБ и санкционный review;
• легче строить единый контур для ML и non-LLM моделей.

Это и есть тот случай, когда open-source стек поддерживает бизнес-логику из урока p.4/01, а не просто радует инженеров.

Минимальный внедренческий план

1. Поставьте GitLab + DVC + MLflow. Этого уже достаточно, чтобы перестать терять данные, артефакты и версии моделей.

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

3. Добавьте monitoring до первого инцидента. Evidently или Alibi Detect надо ставить не после деградации, а до неё.

4. KServe и Kubeflow добавляйте только когда есть минимум несколько production-моделей. Иначе вы купите сложность раньше пользы.

5. Если лицензия спорная, не тащите компонент по привычке. Seldon и часть mixed-license решений надо проверять заранее.

Границы применения

Если у вас один RAG-сервис и один CV-пайплайн, полноценная MLOps-платформа может быть избыточна. Но если у вас уже есть портфель моделей, разные цеха, разные owner’ы и требования к одобрению релизов, жить на bash-скриптах больше нельзя.

Именно в этот момент open-source on-prem MLOps перестаёт быть техническим хобби и становится инструментом промышленной эксплуатации.