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

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

Что такое пользовательские модели?

Служба моделей может развертывать любую модель Python в качестве api производственного класса. Databricks относится к таким моделям, как пользовательские модели. Эти модели машинного обучения можно обучить с помощью стандартных библиотек машинного обучения, таких как scikit-learn, XGBoost, PyTorch и преобразователи HuggingFace и могут включать любой код Python.

Чтобы развернуть пользовательскую модель, выполните инструкции

1. Регистрируйте модель или код в формате MLflow с помощью встроенных вкусов MLflow или pyfunc.
2. После регистрации модели зарегистрируйте ее в каталоге Unity (рекомендуется) или в реестре рабочих областей.
3. Здесь можно создать конечную точку обслуживания модели для развертывания и запроса модели.
   1. См. статью "Создание пользовательских конечных точек обслуживания моделей"
   2. См. сведения о конечных точках обслуживания запросов для пользовательских моделей.

Полное руководство по обслуживанию пользовательских моделей в Databricks см . в руководстве по обслуживанию моделей.

Databricks также поддерживает обслуживание созданных моделей ИИ для создания приложений искусственного интеллекта, см. в api-интерфейсах модели Foundation и внешних моделях для поддерживаемых моделей и предложений вычислений.

Внимание

Если вы используете Anaconda, ознакомьтесь с уведомлением об условиях обслуживания для получения дополнительных сведений.

Модели машинного обучения журнала

Существуют различные методы для регистрации модели машинного обучения для обслуживания моделей. В следующем списке приведены поддерживаемые методы и примеры.

• Автоматическое ведение журнала этого метода автоматически включено при использовании Databricks Runtime для машинного обучения.

  import mlflow
  from sklearn.ensemble import RandomForestRegressor
  from sklearn.datasets import load_iris
  
  iris = load_iris()
  model = RandomForestRegressor()
  model.fit(iris.data, iris.target)
  

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

  import mlflow
  from sklearn.ensemble import RandomForestClassifier
  from sklearn.datasets import load_iris
  
  iris = load_iris()
  model = RandomForestClassifier()
  model.fit(iris.data, iris.target)
  
  with mlflow.start_run():
      mlflow.sklearn.log_model(model, "random_forest_classifier")
  

• Настраиваемое ведение журнала с pyfuncпомощью . Этот метод можно использовать для развертывания произвольных моделей кода Python или развертывания дополнительного кода вместе с моделью.

    import mlflow
    import mlflow.pyfunc
  
    class Model(mlflow.pyfunc.PythonModel):
        def predict(self, context, model_input):
            return model_input * 2
  
    with mlflow.start_run():
        mlflow.pyfunc.log_model("custom_model", python_model=Model())
  

• Скачайте из HuggingFace. Вы можете скачать модель непосредственно из Hugging Face и журнал этой модели для обслуживания. Примеры см . в примерах записных книжек.

Примеры подписи и входных данных

Рекомендуется добавить пример подписи и входных данных в MLflow. Подписи необходимы для моделей ведения журнала в каталоге Unity.

Ниже приведен пример подписи:

from mlflow.models.signature import infer_signature

signature = infer_signature(training_data, model.predict(training_data))
mlflow.sklearn.log_model(model, "model", signature=signature)

Ниже приведен пример ввода:

input_example = {"feature1": 0.5, "feature2": 3}
mlflow.sklearn.log_model(model, "model", input_example=input_example)

Тип вычисления

Примечание.

Служба модели GPU доступна в общедоступной предварительной версии.

Мозаичная служба модели ИИ предоставляет различные варианты ЦП и GPU для развертывания модели. При развертывании с GPU необходимо убедиться, что код настроен так, чтобы прогнозы выполнялись на GPU, используя методы, предоставляемые платформой. MLflow делает это автоматически для моделей, зарегистрированных с помощью вкусов PyTorch или Преобразователей.

Тип рабочей нагрузки	Экземпляр GPU	Память
CPU		4 ГБ на параллелизм
GPU_SMALL	1xT4	16 ГБ
GPU_LARGE	1xA100	80ГБ
GPU_LARGE_2	2xA100	160ГБ

Контейнер развертывания и зависимости

Во время развертывания контейнер рабочего класса создается и развертывается в качестве конечной точки. Этот контейнер включает библиотеки, автоматически захваченные или указанные в модели MLflow.

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

Зависимости пакетов и кода

В развертывание можно добавить пользовательские или частные библиотеки. См. раздел "Использование пользовательских библиотек Python с обслуживанием моделей".

Для моделей собственных вкусов MLflow необходимые зависимости пакетов автоматически фиксируются.

Для пользовательских pyfunc моделей можно явно добавить зависимости.

Можно добавить зависимости пакета с помощью:

• Параметр pip_requirements :

  mlflow.sklearn.log_model(model, "sklearn-model", pip_requirements = ["scikit-learn", "numpy"])
  

• Параметр conda_env :

  
  conda_env = {
      'channels': ['defaults'],
      'dependencies': [
          'python=3.7.0',
          'scikit-learn=0.21.3'
      ],
      'name': 'mlflow-env'
  }
  
  mlflow.sklearn.log_model(model, "sklearn-model", conda_env = conda_env)
  

• Чтобы включить дополнительные требования за рамки автоматического отслеживания, используйте extra_pip_requirements.

  mlflow.sklearn.log_model(model, "sklearn-model", extra_pip_requirements = ["sklearn_req"])
  

Если у вас есть зависимости кода, их можно указать с помощью code_path.

  mlflow.sklearn.log_model(model, "sklearn-model", code_path=["path/to/helper_functions.py"],)

Проверка зависимостей

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

Существует два API предварительной проверки развертывания API MLflow Python и MLflow CLI.

Вы можете указать следующее, используя любой из этих API.

• Модель model_uri , развернутая для обслуживания моделей.
• Одно из следующих элементов:
  • Ожидаемый input_data формат вызова mlflow.pyfunc.PyFuncModel.predict() модели.
  • Определяет input_path файл, содержащий входные данные, которые будут загружены и использованы для вызова predict.
• Формат content_type или json форматcsv.
• Необязательный для output_path записи прогнозов в файл. Если этот параметр опущен, прогнозы печатаются в stdout.
• Диспетчер среды, env_managerкоторый используется для создания среды для обслуживания:
  • Значение по умолчанию — virtualenv. Рекомендуется обслуживать проверку.
  • local доступен, но потенциально может возникать ошибка для обслуживания проверки. Обычно используется только для быстрой отладки.
• Следует ли установить текущую версию MLflow, которая находится в вашей среде с виртуальной средой.install_mlflow Этот параметр по умолчанию используется False.
• Следует ли обновлять и тестировать различные версии зависимостей пакетов для устранения неполадок или отладки. Это можно указать в виде списка переопределения строковых зависимостей или добавлений с помощью аргумента переопределения. pip_requirements_override

Например:

import mlflow

run_id = "..."
model_uri = f"runs:/{run_id}/model"

mlflow.models.predict(
  model_uri=model_uri,
  input_data={"col1": 34.2, "col2": 11.2, "col3": "green"},
  content_type="json",
  env_manager="virtualenv",
  install_mlflow=False,
  pip_requirements_override=["pillow==10.3.0", "scipy==1.13.0"],
)

Обновления зависимостей

Если возникли проблемы с зависимостями, указанными в зарегистрированной модели, можно обновить требования с помощью интерфейса командной строки MLflow или mlflow.models.model.update_model_requirements() в API Python MLflow без необходимости регистрировать другую модель.

В следующем примере показано, как обновить pip_requirements.txt зарегистрированную модель на месте.

Можно обновить существующие определения с указанными версиями пакетов или добавить несуществующие требования к файлу pip_requirements.txt . Этот файл находится в артефакте модели MLflow в указанном model_uri расположении.

from mlflow.models.model import update_model_requirements

update_model_requirements(
  model_uri=model_uri,
  operation="add",
  requirement_list=["pillow==10.2.0", "scipy==1.12.0"],
)

Ожидания и ограничения

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

Ожидания создания и обновления конечных точек

Примечание.

Сведения в этом разделе не применяются к конечным точкам, которые служат базовым моделям или внешним моделям.

Развертывание новой зарегистрированной версии модели включает упаковку модели и ее среды модели и подготовку самой конечной точки модели. Этот процесс может занять около 10 минут.

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

Если вычисление модели занимает более 120 секунд, запросы будут истекает. Если вы считаете, что вычисление модели займет больше 120 секунд, обратитесь к группе учетных записей Azure Databricks.

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

Ожидания масштабирования конечных точек

Примечание.

Сведения в этом разделе не применяются к конечным точкам, которые служат базовым моделям или внешним моделям.

Обслуживание конечных точек автоматически масштабируется на основе трафика и емкости подготовленных единиц параллелизма.

• Подготовленное параллелизм: максимальное количество параллельных запросов, которые может обрабатывать система. Оцените требуемую параллельность с помощью формулы: подготовленная параллелизм = запросы в секунду (QPS) * время выполнения модели (s).
• Поведение масштабирования: конечные точки масштабируемые практически сразу с увеличением трафика и увеличением масштаба каждые пять минут, чтобы соответствовать сниженному трафику.
• Масштабирование до нуля: конечные точки могут уменьшаться до нуля после 30 минут бездействия. Первый запрос после масштабирования до нуля вызывает "холодный запуск", что приводит к более высокой задержке. Для приложений, зависящих от задержки, рассмотрите стратегии эффективного управления этой функцией.

Ограничения рабочей нагрузки GPU

Ниже приведены ограничения для обслуживания конечных точек с рабочими нагрузками GPU:

• Создание образа контейнера для обслуживания GPU занимает больше времени, чем создание образа для обслуживания ЦП из-за размера модели и повышенных требований к установке моделей, обслуживающихся на GPU.
• При развертывании очень больших моделей процесс развертывания может провести время ожидания, если развертывание сборки контейнера и модели превышает 60-минутную длительность. Если это произойдет, инициируя повторную попытку процесса, необходимо успешно развернуть модель.
• Автомасштабирование для обслуживания GPU занимает больше времени, чем для обслуживания ЦП.
• Емкость GPU не гарантируется при масштабировании до нуля. Конечные точки GPU могут ожидать дополнительную задержку для первого запроса после масштабирования до нуля.
• Эта функциональность недоступна в northcentralus.

Обновление лицензирования Anaconda

Следующее уведомление предназначено для клиентов, использующих для проверки Anaconda.

Внимание

Корпорация Anaconda Inc. обновила свои условия предоставления услуг для каналов anaconda.org. В соответствии с новыми условиями предоставления услуг для использования пакетов и распространения Anaconda может потребоваться коммерческая лицензия. Дополнительные сведения см. в часто задаваемых вопросах о коммерческом выпуске Anaconda. Использование любых каналов Anaconda регулируется условиями предоставления услуг Anaconda.

Модели MLflow, зарегистрированные до выхода версии 1.18 (Databricks Runtime 8.3 ML или более ранней версии), по умолчанию регистрировались с каналом conda defaults (https://repo.anaconda.com/pkgs/) в качестве зависимости. Из-за этого изменения условий предоставления услуг компания Databricks прекратила использовать канал defaults для моделей, зарегистрированных с помощью MLflow 1.18 и более поздних версий. По умолчанию теперь регистрируется канал conda-forge, который указывает на управляемый сообществом сайт https://conda-forge.org/.

Если вы зарегистрировали модель до выхода MLflow версии 1.18 и не исключили канал defaults из среды conda для модели, эта модель может иметь зависимость от канала defaults, которая, возможно, не предполагалась. Чтобы узнать, имеет ли модель эту зависимость, можно проверить значение channel в файле conda.yaml, который упакован с зарегистрированной моделью. Например, conda.yaml модели с зависимостью от канала defaults может выглядеть так:

channels:
- defaults
dependencies:
- python=3.8.8
- pip
- pip:
    - mlflow
    - scikit-learn==0.23.2
    - cloudpickle==1.6.0
      name: mlflow-env

Так как Databricks не может определить, разрешено ли вам использовать репозиторий Anaconda для взаимодействия с моделями, Databricks не требует от пользователей вносить какие-либо изменения. Если вы используете репозиторий Anaconda.com с помощью Databricks в соответствии с условиями Anaconda, вам не нужно предпринимать никаких действий.

Если вы хотите изменить канал, используемый в среде модели, можно повторно зарегистрировать модель в реестре моделей с новым conda.yaml. Это можно сделать, указав канал в параметре conda_env log_model().

Дополнительные сведения об API log_model() см. в документации по MLflow для варианта модели, с которым вы работаете, например log_model для scikit-learn.

Дополнительные сведения о файлах conda.yaml см. в документации по MLflow.

Дополнительные ресурсы

• Создание конечных точек обслуживания пользовательских моделей
• Запрос конечных точек обслуживания для пользовательских моделей
• Использование пользовательских библиотек Python с помощью службы моделей
• Пакеты настраиваемых артефактов для обслуживания моделей
• Развертывание кода Python с помощью службы моделей
• Обслуживание нескольких моделей в конечной точке обслуживания моделей
• Настройка оптимизации маршрутов для конечных точек обслуживания
• Настройка доступа к ресурсам из конечных точек обслуживания модели