Общие сведения о пользовательских моделях

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

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

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

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

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

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

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

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

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

Автологирование Этот метод автоматически включается при использовании 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())
```

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

Рекомендуется добавить пример подписи и входных данных в 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, используя методы, предоставляемые платформой. MLflow делает это автоматически для моделей, зарегистрированных с помощью вкусов PyTorch или Преобразователей.

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

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

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

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

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

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

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

Для пользовательских pyfunc моделей можно явно добавить зависимости. Подробные сведения о требованиях к ведению журнала и рекомендациях см. в документации по моделям MLflow и справочнике по API Python MLflow.

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

Параметр 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"],)

Сведения о проверке и обновлении зависимостей перед развертыванием см. в разделе "Предварительная проверка развертывания" для службы моделей.

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

Примечание.

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

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

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

Время развертывания. Развертывание новой зарегистрированной версии модели включает упаковку модели и ее среды модели и подготовку самой конечной точки модели. Этот процесс может занять около 10 минут, но может занять больше времени в зависимости от сложности модели, размера и зависимостей.
Обновления без простоя: Azure Databricks выполняет обновление конечных точек без простоя, сохраняя существующую конфигурацию конечной точки до тех пор, пока новый не будет готов. Это снижает риск прерывания работы конечных точек, которые используются. В ходе этого процесса обновления плата взимается как для старых, так и для новых конфигураций конечных точек до завершения перехода.
Тайм-аут запроса: если вычисление модели занимает больше 297 секунд, запросы будут истекать.

Внимание

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

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

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

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

Предупреждение

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

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

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

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

Уведомление о лицензировании Anaconda для устаревших моделей

Примечание.

Этот раздел относится только к моделям, зарегистрированным с помощью MLflow версии 1.17 или более ранних версий (Databricks Runtime 8.3 ML или более ранних версий). Если вы используете более новую версию, можно пропустить этот раздел.

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

Внимание

Anaconda Inc. обновил условия обслуживания для каналов anaconda.org. В соответствии с новыми условиями предоставления услуг вам может потребоваться коммерческая лицензия, если вы полагаетесь на пакетирование и распространение Anaconda. Подробнее см. в разделе FAQ по коммерческой версии 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_envlog_model().

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

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

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-12-19

Поделиться через

Общие сведения о пользовательских моделях

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

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

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

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

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

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

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

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

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

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

Уведомление о лицензировании Anaconda для устаревших моделей

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

Обратная связь

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