Зависимости модели журналов

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

Зависимости модели пакета Python журнала

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

Например, MLflow поддерживает scikit-learn в модуле mlflow.sklearn, а команда mlflow.sklearn.log_model регистрирует версию sklearn. То же самое относится к автологу с помощью этих библиотек машинного обучения. Дополнительные примеры см. в репозитории GitHub MLflow.

Для библиотек машинного обучения, которые можно установить с pip install PACKAGE_NAME==VERSIONпомощью , но не имеют встроенных вариантов модели MLflow, можно регистрировать эти пакеты с помощью метода mlflow.pyfunc.log_model . Обязательно регистрировать требования с точной версией библиотеки, например f"nltk=={nltk.__version__}" вместо простой nltk.

mlflow.pyfunc.log_model поддерживает ведение журнала для:

• Общедоступные и пользовательские библиотеки, упакованные как файлы яйцо Python или колесика Python.
• Общедоступные пакеты на pyPI и частных размещенных пакетах на собственном сервере PyPI.

При использовании mlflow.pyfunc.log_model MLflow пытается автоматически определить зависимости. MLflow выводит зависимости с помощью mlflow.models.infer_pip_requirements и записывает их в requirements.txt файл в виде артефакта модели.

В более ранних версиях MLflow иногда не определяет все требования Python автоматически, особенно если библиотека не является встроенной версией модели. В этих случаях можно указать дополнительные зависимости с параметром extra_pip_requirements в команде log_model . См. пример использования параметра extra_pip_requirements.

Внимание

Вы также можете перезаписать весь набор требований с conda_env параметрами и pip_requirements параметрами, но это обычно не рекомендуется, так как это переопределяет зависимости, которые MLflow выбирает автоматически. См. пример использования pip_requirements параметра для перезаписи требований.

Ведение журнала настраиваемых моделей

В сценариях, где требуется более настраиваемое ведение журнала моделей, можно выполнить следующие действия.

• Создание пользовательской модели Python. Это позволяет подклассу mlflow.pyfunc.PythonModel настраивать инициализацию и прогнозирование. Этот подход хорошо подходит для настройки моделей, доступных только для Python.
  • Простой пример см. в примере модели добавления N.
  • Более сложный пример см. в примере пользовательской модели XGBoost.
• Напишите пользовательский вкус. В этом сценарии можно настроить ведение журнала больше универсального pyfunc вкуса, но это требует больше работы для реализации.

Пользовательский код Python

Возможно, у вас могут быть зависимости кода Python, которые не могут быть установлены с помощью %pip install команды, например одного или нескольких .py файлов.

При ведении журнала модели можно сообщить MLflow, что модель может найти эти зависимости по указанному пути с помощью code_path параметра в mlflow.pyfunc.log_model. MLflow хранит все файлы или каталоги, переданные в code_path качестве артефактов, а также модель в каталоге кода. При загрузке модели MLflow добавляет эти файлы или каталоги в путь Python. Этот маршрут также работает с пользовательскими файлами колес Python, которые можно включить в модель, используя code_pathтакие же файлы, как .py файлы.

mlflow.pyfunc.log_model( artifact_path=artifact_path,
                         code_path=[filename.py],
                         data_path=data_path,
                         conda_env=conda_env,
                       )

Журнал зависимостей модели пакетов, отличных от Python

MLflow не автоматически выбирает зависимости, отличные от Python, например пакеты Java, пакеты R и собственные пакеты (например, пакеты Linux). Для этих пакетов необходимо записать дополнительные данные.

• Список зависимостей: Databricks рекомендует ведения журнала артефакта с помощью модели, указывающей эти зависимости, отличные от Python. Это может быть простой .txt файл или .json файл. mlflow.pyfunc.log_model позволяет указать этот дополнительный артефакт с помощью аргумента artifacts .
• Пользовательские пакеты: как и для пользовательских зависимостей Python выше, необходимо убедиться, что пакеты доступны в среде развертывания. Для пакетов в центральном расположении, например Maven Central или собственном репозитории, убедитесь, что расположение доступно во время оценки или обслуживания. Для частных пакетов, не размещенных в другом месте, можно записывать пакеты вместе с моделью как артефакты.

Развертывание моделей с помощью зависимостей

При развертывании модели из сервера отслеживания MLflow или реестра моделей необходимо убедиться, что среда развертывания имеет правильные зависимости. Самый простой путь может зависеть от режима развертывания: пакетной или потоковой передачи или онлайн-службы, а также от типов зависимостей.

Для всех режимов развертывания Databricks рекомендует выполнять вывод по одной и той же версии среды выполнения, которую вы использовали во время обучения, так как среда выполнения Databricks, в которой вы создали модель, уже установлены различные библиотеки. MLflow в Databricks автоматически сохраняет версию среды выполнения в MLmodel файле метаданных в databricks_runtime поле, например databricks_runtime: 10.2.x-cpu-ml-scala2.12.

Онлайн-обслуживание: модель Databricks, обслуживающая

Databricks предлагает обслуживание моделей, где модели машинного обучения MLflow предоставляются как масштабируемые конечные точки REST API.

Для зависимостей Python в requirements.txt файле Databricks и MLflow обрабатывают все общедоступные зависимости PyPI. Аналогичным образом, если вы указали .py файлы или файлы колес Python при ведении журнала модели с помощью аргумента code_path , MLflow загружает эти зависимости автоматически.

В следующих сценариях обслуживания моделей см. следующее:

• Использование пользовательских библиотек Python с помощью службы моделей
• Пакет настраиваемых артефактов и файлов для обслуживания моделей

Для зависимостей Python в requirements.txt файле Databricks и MLflow обрабатывают все общедоступные зависимости PyPI. Аналогичным образом, если вы указали .py файлы или файлы колес Python при ведении журнала модели с помощью аргумента code_path , MLflow загружает эти зависимости автоматически.

Онлайн-обслуживание: сторонние системы или контейнеры Docker

Если в вашем сценарии требуется обслуживать сторонние решения или собственное решение на основе Docker, можно экспортировать модель в виде контейнера Docker.

Databricks рекомендует следующее для стороннего обслуживания, которое автоматически обрабатывает зависимости Python. Однако для зависимостей, отличных от Python, контейнер необходимо изменить, чтобы включить их.

• Интеграция Docker MLflow для решения для обслуживания на основе Docker: модели MLflow build-docker

• интеграция MLflow Машинное обучение Azure:

  • Развертывание в экземпляре контейнеров Azure (ACI)
  • Развертывание в Служба Azure Kubernetes (AKS)

Пакетные и потоковые задания

Пакетная и потоковая оценка должны выполняться в качестве заданий Databricks. Задание записной книжки часто достаточно, и самый простой способ подготовки кода — использовать реестр моделей Databricks для создания записной книжки оценки.

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

1. Запустите кластер оценки с той же версией Databricks Runtime, используемой во время обучения. databricks_runtime Считывайте поле из MLmodel файла метаданных и запустите кластер с этой версией среды выполнения.

   • Это можно сделать вручную в конфигурации кластера или автоматически с помощью пользовательской логики. Для автоматизации формат версии среды выполнения, который вы читаете из файла метаданных в API заданий и API кластеров.

2. Затем установите все зависимости, отличные от Python. Чтобы убедиться, что зависимости, отличные от Python, доступны для вашей среды развертывания, можно:

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

3. Задание оценки устанавливает зависимости Python в среде выполнения задания. В Databricks реестр моделей позволяет создать записную книжку для вывода, которая делает это для вас.

   • При использовании реестра моделей Databricks для создания записной книжки оценки записная книжка содержит код для установки зависимостей Python в файле модели requirements.txt . Для задания записной книжки для пакетной или потоковой оценки этот код инициализирует среду записной книжки, чтобы зависимости модели были установлены и готовы для модели.

4. MLflow обрабатывает любой пользовательский код Python, включенный code_path в log_modelпараметр. Этот код добавляется в путь Python при вызове метода модели predict() . Это также можно сделать вручную.

   • Вызов mlflow.pyfunc.spark_udf с аргументом env_manager=['virtualenv'/'conda'] .
   • Извлечение требований с помощью mlflow.pyfunc.get_model_dependencies и их установка с помощью %pip install.

   Примечание.

   Если вы указали .py файлы или файлы колес Python при ведении журнала модели с помощью аргумента code_path , MLflow загружает эти зависимости автоматически.