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

ОБЛАСТЬ ПРИМЕНЕНИЯ:Расширение машинного обучения Azure CLI версии 2 (current)Python SDK azure-ai-ml версии 2 (current)

В этой статье вы узнаете, как развернуть модель в онлайн-конечной точке для использования в режиме реального времени. Сначала вы развернете модель на локальном компьютере для отладки ошибок. Затем вы развернете и протестируете модель в Azure. Вы также узнаете, как просматривать журналы развертывания и отслеживать соглашение об уровне обслуживания (SLA). К концу этой статьи у вас будет масштабируемая конечная точка HTTPS/REST, которую можно использовать для вывода в режиме реального времени.

Сетевые конечные точки — это конечные точки, используемые для вывода в режиме реального времени. Существует два типа сетевых конечных точек: управляемые и Kubernetes. Дополнительные сведения о конечных точках и различиях между управляемыми сетевыми конечными точками и сетевыми конечными точками Kubernetes см. в статье "Что такое Машинное обучение Azure конечных точек?".

Управляемые сетевые конечные точки помогают развертывать модели ML в комплексном режиме. Управляемые сетевые конечные точки работают с мощными машинами ЦП и GPU в Azure масштабируемым и полностью управляемым образом. Управляемые сетевые конечные точки отвечают за обслуживание, масштабирование, безопасность и мониторинг моделей, избавляя вас от накладных расходов на настройку и управление базовой инфраструктурой.

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

Необходимые компоненты

ОБЛАСТЬ ПРИМЕНЕНИЯ:расширение Машинного обучения для Azure CLI версии 2 (текущая версия)

Перед выполнением действий, описанных в этой статье, убедитесь, что выполнены следующие необходимые условия:

  • Управление доступом на основе ролей Azure (Azure RBAC) используется для предоставления доступа к операциям в Машинном обучении Azure. Чтобы выполнить действия, описанные в этой статье, учетной записи пользователя должна быть назначена роль владельца или участника для рабочей области Машинного обучения Azure либо пользовательская роль с разрешением Microsoft.MachineLearningServices/workspaces/onlineEndpoints/*. Если вы используете студию для создания и управления сетевыми конечными точками и развертываниями, вам потребуется дополнительное разрешение "Microsoft.Resources/deployments/write" от владельца группы ресурсов. Дополнительные сведения см. в статье Управление доступом к рабочей области Машинного обучения Azure.

  • (Необязательно) Для локального развертывания необходимо установить подсистему Docker на локальном компьютере. Настоятельно рекомендуем использовать этот вариант, чтобы упростить отладку.

Выделение квот виртуальной машины для развертывания

Для управляемых сетевых конечных точек Машинное обучение Azure резервирует 20 % вычислительных ресурсов для выполнения обновлений на некоторых номерах SKU виртуальных машин. Если вы запрашиваете заданное количество экземпляров в развертывании, необходимо иметь квоту, чтобы ceil(1.2 * number of instances requested for deployment) * number of cores for the VM SKU избежать возникновения ошибки. Например, если вы запрашиваете 10 экземпляров виртуальной машины Standard_DS3_v2 (которая поставляется с 4 ядрами) в развертывании, у вас должна быть квота на 48 ядер () (12 instances * 4 coresдоступных). Чтобы просмотреть увеличение квоты на использование и запрос, ознакомьтесь с разделом "Просмотр использования и квот" в портал Azure.

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

Машинное обучение Azure предоставляет общий пул квот, из которого все пользователи могут получить доступ к квоте для выполнения тестирования в течение ограниченного времени. При использовании студии для развертывания моделей Llama-2, Phi, Nemotron, Mistral, Dolly и DeciLM из каталога моделей в управляемую конечную точку в сети Машинное обучение Azure позволяет получить доступ к этой общей квоте в течение короткого времени.

Дополнительные сведения об использовании общей квоты для развертывания конечных точек в Сети см. в статье "Развертывание базовых моделей с помощью студии".

Подготовка системы

Настройка переменных среды

Если вы еще не задали параметры по умолчанию для Azure CLI, сохраните их. Чтобы не указывать параметры для подписки, рабочей области и группы ресурсов несколько раз, используйте следующий код:

az account set --subscription <subscription ID>
az configure --defaults workspace=<Azure Machine Learning workspace name> group=<resource group>

Клонирование репозитория примеров

Чтобы следовать этой статье, сначала клонируйте репозиторий примеров (azureml-examples). Затем запустите следующий код, чтобы перейти в каталог репозитория cli/ :

git clone --depth 1 https://github.com/Azure/azureml-examples
cd azureml-examples
cd cli

Совет

При использовании параметра --depth 1 клонируется только последняя фиксация, что сокращает время выполнения операции.

Команды, приведенные в этом руководстве, находятся в файлах deploy-local-endpoint.sh и deploy-managed-online-endpoint.shcli каталоге, а файлы конфигурации YAML находятся в подкаталоге endpoints/online/managed/sample/ .

Примечание.

Файлы конфигурации YAML для конечных точек Kubernetes в сети находятся в подкаталоге endpoints/online/kubernetes/ .

Определение конечной точки

Чтобы определить конечную точку, необходимо указать следующее:

  • Имя конечной точки: имя конечной точки. Оно должно быть уникальным в рамках региона Azure. Дополнительные сведения о правилах именования см. в разделе "Ограничения конечной точки".
  • Режим проверки подлинности: метод проверки подлинности для конечной точки. Выберите проверку подлинности на основе ключей и Машинное обучение Azure проверку подлинности на основе маркеров. Срок действия ключа не истекает, но срок действия маркера истекает. Дополнительные сведения о проверке подлинности см. в статье Проверка подлинности подключенной конечной точки.
  • При необходимости можно добавить описание и теги в конечную точку.

Задание имени конечной точки

Чтобы задать имя конечной точки, выполните следующую команду (замените YOUR_ENDPOINT_NAME уникальным именем).

Для Linux выполните следующую команду:

export ENDPOINT_NAME="<YOUR_ENDPOINT_NAME>"

Настройка конечной точки

В следующем фрагменте кода показан файл endpoints/online/managed/sample/endpoint.yml:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineEndpoint.schema.json
name: my-endpoint
auth_mode: key

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

Ключ. Description
$schema (Необязательно) Схема YAML. Чтобы просмотреть все доступные параметры в ФАЙЛЕ YAML, можно просмотреть схему в предыдущем фрагменте кода в браузере.
name Имя конечной точки.
auth_mode Используйте key для аутентификации на основе ключей. Используйте aml_token для проверки подлинности в службе "Машинное обучение Azure" на основе маркеров. Чтобы получить последний маркер, используйте az ml online-endpoint get-credentials команду.

Определение развертывания

Развертывание представляет собой набор ресурсов, необходимых для размещения модели, которая выполняет процесс вывода. Для развертывания модели необходимо следующее:

  • Файлы модели (или имя и версия модели, уже зарегистрированной в рабочей области). В нашем примере есть модель scikit-learn, выполняющая регрессию.
  • Скрипт оценки, то есть код, который выполняет модель в заданном входном запросе. Скрипт оценки получает данные, отправленные в развернутую веб-службу, и передает его модели. Затем скрипт выполняет модель и возвращает ответ клиенту. Скрипт оценки зависит от модели и должен понимать данные, которые модель ожидает в качестве входных данных и возвращает в качестве выходных данных. В этом примере у нас есть файл score.py .
  • Среда, в которой работает модель. Среда может быть образом Docker с зависимостями Conda или Dockerfile.
  • Параметры для типа экземпляра и возможностей масштабирования.

В следующей таблице описаны ключевые атрибуты развертывания:

Атрибут Описание
Имя. Имя развертывания.
Имя конечной точки Имя конечной точки для создания развертывания.
Модель Модель, которая будет использоваться для развертывания. Это значение может быть ссылкой на существующую модель с управлением версиями в рабочей области или спецификацией встроенной модели.
Путь к коду Путь к каталогу в локальной среде разработки, содержащей весь исходный код Python для оценки модели. Вы можете использовать вложенные каталоги и пакеты.
Scoring script (Скрипт оценки) Относительный путь к файлу оценки в каталоге исходного кода. Этот код Python должен содержать функции init() и run(). Функция init() будет вызвана после создания или обновления модели (например, можно использовать ее для кэширования модели в памяти). Функция run() вызывается при каждом вызове конечной точки для фактического выполнения оценки и прогнозирования.
Среда Среда для размещения модели и кода. Это значение может быть ссылкой на существующую среду с управлением версиями в рабочей области или спецификацией встроенной среды.
Тип экземпляра Размер виртуальной машины, используемый для развертывания. Список поддерживаемых размеров см. в списке SKU управляемых сетевых конечных точек.
Число экземпляров Число экземпляров, которые будут использоваться для развертывания. Это значение должно быть основано на предполагаемой рабочей нагрузке. Для обеспечения высокой доступности рекомендуется задать значение по крайней мере 3. Мы резервируем дополнительные 20 % для выполнения обновлений. Дополнительные сведения см. в статье о выделении квот виртуальной машины для развертываний.

Примечание.

  • Образ модели и контейнера (как определено в среде) можно ссылаться снова в любое время при развертывании, когда экземпляры развертывания проходят через исправления безопасности и /или другие операции восстановления. Если вы использовали зарегистрированную модель или образ контейнера в Реестр контейнеров Azure для развертывания и удалили модель или образ контейнера, развертывания, использующие эти ресурсы, могут завершиться ошибкой при повторном создании образа. Если вы удалили модель или образ контейнера, убедитесь, что зависимые развертывания создаются повторно или обновляются с помощью альтернативной модели или образа контейнера.
  • Реестр контейнеров, который ссылается на среду, может быть частным, только если удостоверение конечной точки имеет разрешение на доступ к нему через проверку подлинности Microsoft Entra и Azure RBAC. По той же причине частные реестры Docker, отличные от Реестр контейнеров Azure, не поддерживаются.

Настройка развертывания

В следующем фрагменте кода показаны конечные точки,online/managed/sample/blue-deployment.yml-файл со всеми необходимыми входными данными для настройки развертывания:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json
name: blue
endpoint_name: my-endpoint
model:
  path: ../../model-1/model/
code_configuration:
  code: ../../model-1/onlinescoring/
  scoring_script: score.py
environment: 
  conda_file: ../../model-1/environment/conda.yaml
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest
instance_type: Standard_DS3_v2
instance_count: 1

Примечание.

В файле blue-deployment.yml мы указали следующие атрибуты развертывания:

  • model— В этом примере мы указываем встроенные свойства модели с помощью .path Файлы модели автоматически передаются и зарегистрируются с помощью автоматического формирования имени.
  • environment — В этом примере у нас есть встроенные определения, которые включают в себя path. Мы будем использовать environment.docker.image в качестве образа. Зависимости conda_file будут установлены поверх образа.

Во время развертывания локальные файлы, такие как источник Python для модели оценки, отправляются из среды разработки.

Дополнительные сведения о схеме YAML см. в справочнике по подключенной конечной точке YAML.

Примечание.

Чтобы использовать Kubernetes вместо управляемых конечных точек в качестве целевого объекта:

  1. Создайте и присоедините кластер Kubernetes в качестве целевого объекта вычислений к рабочей области Машинного обучения Azure с помощью студии машинного обучения Azure.
  2. Используйте эту конечную точку YAML для выбора целевого объекта Kubernetes вместо кода YAML управляемой конечной точки. Вам потребуется отредактировать код YAML и изменить значение target на имя зарегистрированного целевого объекта вычислений. Вы можете использовать этот файл deployment.yaml с дополнительными свойствами, применимыми к развертыванию Kubernetes.

Все команды, используемые в этой статье (кроме необязательной интеграции мониторинга SLA и Azure Log Analytics), можно использовать либо с управляемыми конечными точками, либо с конечными точками Kubernetes.

Отдельная регистрация модели и среды

В этом примере мы указываем path (откуда загружать файлы) встроенным. CLI автоматически отправляет файлы и регистрирует модель и среду. Для рабочей среды рекомендуется отдельно зарегистрировать модель и среду, а также указать зарегистрированное имя и версию в YAML. Используйте формат model: azureml:my-model:1 или environment: azureml:my-env:1.

Для регистрации вы можете извлечь определения YAML model и environment в отдельные файлы YAML и использовать команды az ml model create и az ml environment create. Чтобы узнать больше об этих командах, выполните команду az ml model create -h и az ml environment create -h.

Дополнительные сведения о регистрации модели в качестве ресурса см. в разделе "Регистрация модели в качестве ресурса" в Машинное обучение с помощью интерфейса командной строки. Дополнительные сведения о создании среды см. в статье "Управление средами Машинное обучение Azure с помощью ИНТЕРФЕЙСА командной строки и пакета SDK (версия 2)".

Использование различных типов экземпляров ЦП и GPU

Предыдущее определение в файле blue-deployment.yml использует экземпляр типа Standard_DS3_v2 общего назначения и образ mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latestDocker, отличный от GPU. Для вычислений GPU выберите SKU типа вычислений GPU и образ Docker GPU.

Поддерживаемые типы экземпляров общего назначения и GPU перечислены в статье о номерах SKU поддерживаемых виртуальных машин для управляемых сетевых конечных точек. Список базовых образов ЦП и GPU для Машинного обучения Azure см. на странице базовых образов Машинного обучения Azure.

Примечание.

Сведения об использовании Kubernetes вместо управляемых конечных точек в качестве целевого объекта вычислений см. в статье "Общие сведения о целевом объекте вычислений Kubernetes".

Определение пути модели относительно AZUREML_MODEL_DIR

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

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

A screenshot showing a folder structure containing multiple models.

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

Чтобы использовать одну модель на локальном компьютере в развертывании, укажите pathmodel ее в yamL развертывания. Ниже приведен пример развертывания YAML с путем /Downloads/multi-models-sample/models/model_1/v1/sample_m1.pkl:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: 
  path: /Downloads/multi-models-sample/models/model_1/v1/sample_m1.pkl 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1 

После создания развертывания переменная AZUREML_MODEL_DIR среды будет указывать на расположение хранилища в Azure, где хранится модель. Например, /var/azureml-app/azureml-models/81b3c48bbf62360c7edbbe9b280b9025/1 будет содержать модель sample_m1.pkl.

В скрипте оценки () можно загрузить модель (score.pyв этом примере sample_m1.pkl) в функцию init() :

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR")), "sample_m1.pkl") 
    model = joblib.load(model_path) 

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

Хотя Azure CLI, пакет SDK для Python и другие клиентские средства позволяют указать только одну модель для каждого развертывания в определении развертывания, вы по-прежнему можете использовать несколько моделей в развертывании, зарегистрируя папку модели, содержащую все модели в виде файлов или подкаталогов.

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

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: 
  path: /Downloads/multi-models-sample/models/ 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1 

После создания развертывания переменная AZUREML_MODEL_DIR среды будет указывать на расположение хранилища в Azure, где хранятся модели. Например, /var/azureml-app/azureml-models/81b3c48bbf62360c7edbbe9b280b9025/1 будет содержать модели и структуру файлов.

В этом примере содержимое AZUREML_MODEL_DIR папки будет выглядеть следующим образом:

A screenshot of the folder structure of the storage location for multiple models.

В скрипте оценки (score.py) можно загрузить модели в функцию init() . Следующий код загружает sample_m1.pkl модель:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR")), "models","model_1","v1", "sample_m1.pkl ") 
    model = joblib.load(model_path) 

Пример развертывания нескольких моделей в одном развертывании см. в статье Развертывание нескольких моделей в одном развертывании (пример CLI) и развертывание нескольких моделей в одном развертывании (пример пакета SDK).

Совет

Если у вас более 1500 файлов для регистрации, рассмотрите возможность сжатия файлов или подкаталогов как .tar.gz при регистрации моделей. Чтобы использовать модели, можно распаковать файлы или вложенные каталоги в функции из init() скрипта оценки. Кроме того, при регистрации моделей задайте для свойства Trueзначение <>azureml.unpack/>, чтобы автоматически распаковывать файлы или вложенные каталоги. В любом случае распаковка происходит один раз на этапе инициализации.

Использование моделей, зарегистрированных в рабочей области Машинное обучение Azure в развертывании

Чтобы использовать одну или несколько моделей, зарегистрированных в рабочей области Машинное обучение Azure, в развертывании укажите имя зарегистрированных моделей в YAML развертывания. Например, следующая конфигурация YAML развертывания указывает зарегистрированный model имя как azureml:local-multimodel:3:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: azureml:local-multimodel:3 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1 

В этом примере рассмотрим, что local-multimodel:3 содержит следующие артефакты модели, которые можно просмотреть на вкладке "Модели" в Студия машинного обучения Azure:

A screenshot of the folder structure showing the model artifacts of the registered model.

После создания развертывания переменная AZUREML_MODEL_DIR среды будет указывать на расположение хранилища в Azure, где хранятся модели. Например, /var/azureml-app/azureml-models/local-multimodel/3 будет содержать модели и структуру файлов. AZUREML_MODEL_DIR указывает на папку, содержащую корень артефактов модели. В этом примере содержимое AZUREML_MODEL_DIR папки будет выглядеть следующим образом:

A screenshot of the folder structure showing multiple models.

В скрипте оценки (score.py) можно загрузить модели в функцию init() . Например, загрузите diabetes.sav модель:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR"), "models", "diabetes", "1", "diabetes.sav") 
    model = joblib.load(model_path) 

Общие сведения о скрипте оценки

Совет

Для сетевых конечных точек используется тот же формат скрипта оценки, что и в более ранних версиях CLI и в пакете SDK для Python.

Как отмечалось ранее, скрипт оценки, указанный init() вcode_configuration.scoring_script, должен иметь функцию и run() функцию.

В этом примере используется файл score.py: score.py

import os
import logging
import json
import numpy
import joblib


def init():
    """
    This function is called when the container is initialized/started, typically after create/update of the deployment.
    You can write the logic here to perform init operations like caching the model in memory
    """
    global model
    # AZUREML_MODEL_DIR is an environment variable created during deployment.
    # It is the path to the model folder (./azureml-models/$MODEL_NAME/$VERSION)
    # Please provide your model's folder name if there is one
    model_path = os.path.join(
        os.getenv("AZUREML_MODEL_DIR"), "model/sklearn_regression_model.pkl"
    )
    # deserialize the model file back into a sklearn model
    model = joblib.load(model_path)
    logging.info("Init complete")


def run(raw_data):
    """
    This function is called for every invocation of the endpoint to perform the actual scoring/prediction.
    In the example we extract the data from the json input and call the scikit-learn model's predict()
    method and return the result back
    """
    logging.info("model 1: request received")
    data = json.loads(raw_data)["data"]
    data = numpy.array(data)
    result = model.predict(data)
    logging.info("Request processed")
    return result.tolist()

Функция init() вызывается при инициализации или запуске контейнера. Инициализация обычно происходит вскоре после создания или обновления развертывания. Функция init — это место для записи логики для глобальных операций инициализации, таких как кэширование модели в памяти (как и в этом примере).

Функция run() вызывается для каждого вызова конечной точки, и она выполняет фактическую оценку и прогнозирование. В этом примере мы извлеким данные из входных данных JSON, вызовем метод модели predict() scikit-learn, а затем возвращаем результат.

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

Мы настоятельно рекомендуем протестировать конечную точку локально, проверив и отладив код и конфигурацию перед развертыванием в Azure. Пакет SDK Azure CLI и Python поддерживают локальные конечные точки и развертывания, а шаблон Студия машинного обучения Azure и ARM не поддерживаются.

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

Совет

Вы можете использовать пакет Python http-сервера Машинное обучение Azure для отладки скрипта оценки локально без подсистемы Docker. Отладка с помощью сервера вывода помогает выполнить отладку скрипта оценки перед развертыванием на локальных конечных точках, чтобы можно было выполнять отладку без влияния на конфигурации контейнеров развертывания.

Примечание.

Локальные конечные точки имеют следующие ограничения:

  • Они не поддерживают правила трафика, параметры проверки подлинности или пробы.
  • Они поддерживают только одно развертывание на конечную точку.
  • Они поддерживают файлы локальной модели и среду только с локальным файлом conda. Если вы хотите протестировать зарегистрированные модели, сначала скачайте их с помощью интерфейса командной строки или пакета SDK, а затем используйте path в определении развертывания для ссылки на родительскую папку. Если вы хотите протестировать зарегистрированные среды, проверка контекст среды в Студия машинного обучения Azure и подготовить локальный файл conda для использования. Пример в этой статье демонстрирует использование локальной модели и среды с локальным файлом conda, который поддерживает локальное развертывание.

Дополнительные сведения об отладке сетевых конечных точек локально перед развертыванием в Azure см. в статье "Отладка сетевых конечных точек локально в Visual Studio Code".

Локальное развертывание модели

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

az ml online-endpoint create --local -n $ENDPOINT_NAME -f endpoints/online/managed/sample/endpoint.yml

Теперь создайте развертывание с именем blue в конечной точке.

az ml online-deployment create --local -n blue --endpoint $ENDPOINT_NAME -f endpoints/online/managed/sample/blue-deployment.yml

Флаг --local инструктирует CLI развернуть конечную точку в среде Docker.

Совет

Используйте Visual Studio Code для локального тестирования и отладки конечных точек. Дополнительные сведения см. в разделе Локальная отладка сетевых конечных точек в Visual Studio Code.

Проверка успешности локального развертывания

Проверьте статус, чтобы узнать, удалось ли развернуть модель без ошибок:

az ml online-endpoint show -n $ENDPOINT_NAME --local

Результат должен выглядеть аналогично следующему JSON. Значение параметра provisioning_state — Succeeded.

{
  "auth_mode": "key",
  "location": "local",
  "name": "docs-endpoint",
  "properties": {},
  "provisioning_state": "Succeeded",
  "scoring_uri": "http://localhost:49158/score",
  "tags": {},
  "traffic": {}
}

В следующей таблице приведены возможные значения для provisioning_state:

State Description
Создание Ресурс создается.
Обновление Ресурс обновляется.
Удаление Ресурс удаляется.
Успешно Операция создания или обновления выполнена успешно.
Неудачно Не удалось выполнить операцию создания, обновления или удаления.

Вызов локальной конечной точки для оценки данных с помощью модели

Вызовите конечную точку для оценки модели с помощью команды invoke, передав ей параметры запроса, хранящиеся в JSON-файле:

az ml online-endpoint invoke --local --name $ENDPOINT_NAME --request-file endpoints/online/model-1/sample-request.json

Если вы хотите использовать клиент REST (например, curl), вам потребуется URI оценки. Чтобы получить URI оценки, используйте команду az ml online-endpoint show --local -n $ENDPOINT_NAME. Найдите атрибут scoring_uri в возвращенных данных. Примерные команды на основе cURL доступны далее в этом документе.

Проверка журналов на наличие выходных данных операции вызова

В примере файла score.py метод run() выводит некоторые выходные данные в консоли.

Эти выходные get-logs данные можно просмотреть с помощью команды:

az ml online-deployment get-logs --local -n blue --endpoint $ENDPOINT_NAME

Развертывание сетевой конечной точки в Azure

Теперь следует развернуть сетевую конечную точку в Azure.

Развернуть в Azure

Чтобы создать конечную точку в облаке, выполните следующий код:

az ml online-endpoint create --name $ENDPOINT_NAME -f endpoints/online/managed/sample/endpoint.yml

Чтобы создать развертывание с именем blue в конечной точке, выполните следующий код:

az ml online-deployment create --name blue --endpoint $ENDPOINT_NAME -f endpoints/online/managed/sample/blue-deployment.yml --all-traffic

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

Совет

  • Если вы не хотите блокировать консоль CLI, добавьте к команде флаг --no-wait. Однако так вы не сможете отслеживать состояние развертывания в интерактивном режиме.

Внимание

Флаг --all-traffic в приведенном выше az ml online-deployment create разделе выделяет 100 % трафика конечной точки только что созданному синему развертыванию. Хотя это полезно для целей разработки и тестирования, для рабочей среды может потребоваться открыть трафик в новое развертывание с помощью явной команды. Например, az ml online-endpoint update -n $ENDPOINT_NAME --traffic "blue=100".

Совет

Проверка состояния конечной точки

Команда show содержит сведения provisioning_state о конечной точке и развертывании:

az ml online-endpoint show -n $ENDPOINT_NAME

Вы можете вывести список всех конечных точек рабочей области в табличном формате с помощью команды list:

az ml online-endpoint list --output table

Проверка состояния развертывания в сети

Проверьте журналы, чтобы узнать, была ли модель развернута без ошибок.

Чтобы просмотреть выходные данные журнала из контейнера, используйте следующую команду CLI:

az ml online-deployment get-logs --name blue --endpoint $ENDPOINT_NAME

По умолчанию журналы извлекаются из контейнера сервера вывода. Чтобы просмотреть журналы из контейнера инициализатора хранилища, добавьте --container storage-initializer флаг. Дополнительные сведения о журналах развертывания см. в разделе "Получение журналов контейнеров".

Вызов конечной точки для оценки данных с помощью модели

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

az ml online-endpoint invoke --name $ENDPOINT_NAME --request-file endpoints/online/model-1/sample-request.json

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

Совет

Вы можете контролировать, какие субъекты безопасности Microsoft Entra могут получить ключ проверки подлинности, назначив их пользовательской роли, которая позволяет Microsoft.MachineLearningServices/workspaces/onlineEndpoints/token/action и Microsoft.MachineLearningServices/workspaces/onlineEndpoints/listkeys/action. Дополнительные сведения см. в статье Управление доступом к рабочей области Машинного обучения Azure.

ENDPOINT_KEY=$(az ml online-endpoint get-credentials -n $ENDPOINT_NAME -o tsv --query primaryKey)

Затем используйте cURL для оценки данных.

SCORING_URI=$(az ml online-endpoint show -n $ENDPOINT_NAME -o tsv --query scoring_uri)

curl --request POST "$SCORING_URI" --header "Authorization: Bearer $ENDPOINT_KEY" --header 'Content-Type: application/json' --data @endpoints/online/model-1/sample-request.json

Обратите внимание, что мы используем команды show и get-credentials для получения учетных данных для проверки подлинности. Мы используем флаг --query, чтобы отфильтровать только необходимые атрибуты. Дополнительные сведения о флаге --query см. в статье о выходных данных команды Query в Azure CLI.

Чтобы просмотреть журналы вызовов, снова введите команду get-logs.

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

(Необязательно) Обновление развертывания

Если вы хотите обновить код, модель, среду или параметры масштабирования, обновите файл YAML и введите команду az ml online-endpoint update.

Примечание.

При обновлении количества экземпляров (для масштабирования развертывания) вместе с другими параметрами модели (например, кодом, моделью или средой) в одной update команде сначала будет выполнена операция масштабирования, а затем будут применены другие обновления. Рекомендуется выполнять эти операции отдельно в рабочей среде.

Чтобы понять, как работает команда update:

  1. Откройте файл online/model-1/onlinescoring/score.py.

  2. Измените последнюю строку функции init(): после logging.info("Init complete") добавьте logging.info("Updated successfully").

  3. Сохраните файл.

  4. Выполните следующую команду:

    az ml online-deployment update -n blue --endpoint $ENDPOINT_NAME -f endpoints/online/managed/sample/blue-deployment.yml
    

    Примечание.

    Обновление с помощью YAML является декларативным. Это означает, что изменения в YAML отражаются в базовых ресурсах Azure Resource Manager (конечных точках и развертываниях). В декларативном подходе используется GitOps: все изменения конечных точек и развертываний (даже instance_count) проходят через YAML.

    Совет

    • Вы можете использовать универсальные параметры обновления, такие как --set параметр, с помощью команды CLI update для переопределения атрибутов в YAML или для задания определенных атрибутов, не передавая их в YAML-файл. Использовать --set для отдельных атрибутов особенно удобно в сценариях разработки и тестирования. Например, с помощью флага --set instance_count=2 можно увеличить значение instance_count первого развертывания. Однако поскольку YAML не обновляется, этот метод не упрощает процесс GitOps.
    • Указание ФАЙЛА YAML не является обязательным. Например, если вы хотите протестировать различные параметры параллелизма для данного развертывания, можно попробовать что-то подобное az ml online-deployment update -n blue -e my-endpoint --set request_settings.max_concurrent_requests_per_instance=4 environment_variables.WORKER_COUNT=4. Это позволит сохранить всю существующую конфигурацию, но обновить только указанные параметры.
  5. Так как вы изменили init() функцию, которая выполняется при создании или обновлении конечной точки, сообщение Updated successfully будет находиться в журналах. Чтобы получить журналы, выполните следующую команду:

    az ml online-deployment get-logs --name blue --endpoint $ENDPOINT_NAME
    

Команда update также работает с локальными конечными точками. Используйте такую же команду az ml online-deployment update с флагом --local.

Примечание.

Предыдущее обновление развертывания является примером последовательного обновления.

  • Для управляемой сетевой конечной точки развертывание обновляется до новой конфигурации с 20% узлами за раз. То есть, если развертывание имеет 10 узлов, 2 узла за раз будут обновлены.
  • Для конечной точки Kubernetes в Сети система будет итеративно создавать экземпляр развертывания с новой конфигурацией и удалять старый.
  • Для использования в рабочей среде следует учитывать сине-зеленое развертывание, которое предлагает более безопасную альтернативу обновлению веб-службы.

(Дополнительно) Настройка автомасштабирования

Благодаря автомасштабированию автоматически запускается именно тот объем ресурсов, который нужен для обработки нагрузки в вашем приложении. Управляемые сетевые конечные точки поддерживают автоматическое масштабирование через интеграцию с функцией автомасштабирования Azure Monitor. Сведения о настройке автомасштабирования см. в разделе Автомасштабирование сетевых конечных точек.

(Необязательно) Мониторинг соглашения об уровне обслуживания с помощью Azure Monitor

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

(Необязательно) Интеграция с Log Analytics

Команда get-logs для ИНТЕРФЕЙСА командной строки или get_logs метода пакета SDK предоставляет только последние несколько сотен строк журналов из автоматически выбранного экземпляра. Однако Log Analytics позволяет надежно хранить и анализировать журналы. Дополнительные сведения об использовании ведения журнала см. в разделе "Мониторинг сетевых конечных точек".

Удаление конечной точки и развертывания

Если вы не планируете использовать развертывание, удалите его с помощью следующего кода (он удаляет конечную точку и все базовые развертывания):

az ml online-endpoint delete --name $ENDPOINT_NAME --yes --no-wait