Всем привет! Меня зовут Алина. Ранее я вам рассказывала про то, как можно спроектировать Feature Platform. Сегодня речь пойдёт об очень важном компоненте ML-платформы — о развёртывании ML-моделей, а также о связанных с ним компонентах.

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

Как выглядит процесс развёртывания

Для человека из другой IT-команды развёртывание модели выглядит как-то так: делаем модель и оборачиваем в сервис.

Но на самом деле процесс состоит из большого количества шагов:

• Разработка инференса модели

• Разработка API и сервиса

• Разработка промышленной витрины фич

• Интеграция с Feature Store

• Настройка журналирования и мониторинга

• Тестирование

• Конфигурирование раскатки и сборка образа

Для руководителя ML-направления развёртывание — это не техническая задача, а скорее управленческий вызов. И суть его можно выразить тремя словами: часто, много, надёжно. Каждый новый релиз должен стать рутинной операцией.

Два основных подхода к эксплуатации моделей

Модель как сервис (в реальном времени)

Модель упаковывают в микросервис и предоставляют синхронный HTTP API для получения предсказания, а приложение интегрируют с модельным микросервисом backend-to-backend. 

Например, у нас есть сервис предсказания цены по объектам недвижимости. Предсказание доступно по API и с ним интегрированы несколько наших приложений, таких как сервис объявлений и сервис «Моя недвижимость». Каждое приложение отображает цену в том виде, в котором это будет удобно пользователю сервиса.

Модель как конвейер (пакетная обработка)

Создают конвейер, где в первую очередь в пакетном режиме обрабатывают данные, затем подают их в модель, которая рассчитывает предсказание. Полученные результаты сохраняют в базу данных. Как правило, расчёт происходит один раз в сутки. Заранее рассчитанные предсказания используются микросервисом для их выдачи приложению, взаимодействующему с пользователем.

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

Развёртывание моделей

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

Сложная часть — системная интеграция в рабочую инфраструктуру: 

1. Артефакты и реестр моделей

2. Мониторинг

3. Интеграция с Feature Store

Процесс развёртывания моделей состоит из двух этапов: сборки и раскатки.

Сборка Docker-образа:

• Скачивают базовый Docker-образ, выбирают минимальный образ с нужной версией Python

• Устанавливают нужные пакеты

• Загружают модель и артефакты

• Собирают финальный Docker-образ с моделью

• Публикуют в Docker Registry

Раскатка в кластер Kubernetes:

• Скачивают финальный Docker-образ, который нужно выкатить

• Поднимают поды и запускают веб-сервер

Артефакты и реестр моделей

Реестр моделей — это специализированный сервис, в котором хранятся версии обученных моделей и необходимые артефакты. Сервис предоставляет API для интеграции с CI/CD, то есть можно скачать модель и её артефакты. В конфигурационном YAML-файле для развёртывания прописывают ID и версии моделей и артефактов, которые должны попасть в промышленное окружение.

Отказоустойчивость в развёртывании

В промышленной среде ML-модели тоже должны работать 24/7. Отказоустойчивость достигается благодаря тому, что модель находится внутри образа и при запуске пода не зависит от внешнего хранилища, которое может стать точкой отказа. Также можно воспользоваться кешированием образа на ноде в кластере Kubernetes. Кроме того, доступен быстрый откат на предыдущую версию, поскольку у вас уже есть сборка с нужной версией модели. Сборка получается полностью воспроизводима.

Мониторинг

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

Мониторинг включает в себя: 

• Операционные метрики:

  • Частота запросов и время отклика

  • Пропускная способность и использование ресурсов

  • Доступность сервиса и частота ошибок

  • Качество данных и моделей

  • Контроль дрифта данных и аномалий

  • Мониторинг фич

  • Кастомные метрики для каждой модели

• Полная наблюдаемость (Observability):

  • Журналирование запросов и предсказаний

  • Журналирование всех используемых фич

  • Метаданные для трассировки предсказаний

• Обратная связь от потребителей:

  • Как приложения используют предсказания

  • Поведение пользователей относительно предсказания

  • Бизнес-метрики, связанные с работой модели

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

Обратная связь в ML-системах

Обратная связь — это не просто технические метрики, а полноценный анализ взаимодействия реальных пользователей с предсказаниями модели, закрывающий цикл «предсказание → действие → результат»: факт взаимодействия, поведенческие паттерны, бизнес-трансформации. Без такого мониторинга мы рискуем оптимизировать не те метрики. 

Взаимодействие с Feature Store

При развёртывании ML-моделей Feature Store становится ключевым компонентом, обеспечивающим:

• Централизованное хранение актуальных фичей

• Гарантированную согласованность данных между обучением и инференсом

• Чёткие контракты на данные между командой DS и инженерами

Open Source-решения с функцией развёртывания моделей: обзор возможностей

Среди доступных Open Source-платформ для управления жизненным циклом моделей особенно выделяются три решения, каждое из которых предлагает разный набор возможностей. Но только у одного их них в бесплатном доступе есть мониторинг моделей. 

ClearML:

• Отслеживание экспериментов

• Управление проектами через единый интерфейс

• Развёртывание в Kubernetes

MLflow:

• Отслеживание экспериментов

• Управление проектами через единый интерфейс

• Гибкие варианты развёртывания (облачные провайдеры, Kubernetes, локальные серверы)

MLRun:

• Отслеживание экспериментов

• Управление проектами

• Развёртывание в Kubernetes

• Мониторинг работающих моделей

• Интеграция с Feature Store

Архитектура мониторинга в MLRun

На схеме ниже показано, как собираются данные для системы мониторинга. В качестве источников данных для анализа выступают микросервисы: журналы собираются через брокер очередей и конвейеры, результаты напрямую записываются в базу данных. Присутствует централизованное хранение данных, а также поддерживается структурированный формат для анализа. Обработку журналов и генерацию метрик осуществляет сервис метрик, который вычисляет ключевые показатели для анализа дрифтов и выявления аномалий. Журналы и метрики могут использоваться для построения фич и поступают в Feature Store, а данные для мониторинга — в дашборды для визуализации (Grafana и Prometheus).

Схема взаимодействия с Feature Store в платформе MLRun

В платформе MLRun работа с фичами организована через специальный Feature Service на основе KV-хранилища (Key-Value). Это решение обеспечивает:

1. Гибкое управление данными:

   • Автоматическую трансформацию сырых данных в готовые фичи

   • Версионирование и контроль качества признаков

2. Единый доступ к данным для моделей:

   • Единый API для онлайн-сценариев

   • Оптимизированные запросы

Нюансы развёртывания в MLRun

Платформа использует подход с загрузкой модели во время запуска сервиса, что позволяет динамически обновлять модели без пересборки образов и создаёт дополнительную точку отказа (зависимость от сети и хранилища).

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

Улучшение архитектуры

Текущая реализация журналирования результатов ML-моделей в нашей компании выглядит относительно стандартно для микросервисной архитектуры. Сейчас у нас децентрализованное хранение журналов, то есть каждый микросервис с моделью пишет в свою PostgreSQL-базу, которая предварительно партицируется для управления объёмами данных. Процесс подсчёта метрик полуавтоматический и без визуализации в Grafana. Такая реализация имеет право на жизнь.

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

Преимущества такого подхода видятся в следующем:

• Упрощение поддержки (единый формат вместо разрозненных JSON)

• Масштабируемость (Kafka вместо прямых записей в PG)

• Автоматизация (шаблонизация метрик вместо ручных скриптов)

• Гибкость (данные доступны для разных целей)

Заключение 

Современные ML-системы — это не только алгоритмы, но и продуманная инфраструктура от версионирования артефактов до интеграции с Feature Store и системы мониторинга. Современные инструменты (MLflow, MLRun) значительно упрощают этот процесс, но рекомендую погружаться в детали работы.