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

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

Узнайте, как использовать пакетные конечные точки для пакетной оценки. Пакетные конечные точки упрощают процесс размещения моделей для пакетной оценки, что позволяет сосредоточиться на настройке машинного обучения, а не инфраструктуры. Дополнительные сведения см. в статье Что такое конечные точки Машинного обучения Azure?

Из этой статьи вы узнаете, как выполнять перечисленные ниже задачи.

  • Создание пакетной конечной точки и пакетного развертывания по умолчанию
  • Запуск задания пакетной оценки с помощью интерфейса командной строки Azure
  • Мониторинг хода выполнения пакетной оценки и проверка ее результатов
  • Развертывание новой модели MLflow с автоматически созданным кодом и средой в существующей конечной точке без влияния на существующую последовательность
  • Тестирование нового развертывания и задание его в качестве развертывания по умолчанию
  • Удаление неиспользуемой конечной точки и развертывания

Предварительные требования

az account set -s "<subscription ID>"
az configure --defaults group="<resource group>" workspace="<workspace name>" location="<location>"

Клонируйте репозиторий примеров

Выполните следующие команды, чтобы клонировать Репозиторий примеров AzureML и перейдите к каталогу cli. В этой статье используются активы в /cli/endpoints/batch, а в качестве сквозного рабочего примера — /cli/batch-score.sh.

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

Установка имени конечной точки. Замените YOUR_ENDPOINT_NAME уникальным именем в пределах региона Azure.

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

export ENDPOINT_NAME="<YOUR_ENDPOINT_NAME>"

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

set ENDPOINT_NAME="<YOUR_ENDPOINT_NAME>"

Примечание

Имена пакетных конечных точек должны быть уникальными в пределах региона Azure. Например, в westus2 можно указать только одну пакетную конечную точку с именем mybatchendpoint.

Создание вычислений

Запуск пакетных конечных точек выполняется только на ресурсах облачных вычислений, но не локально. Ресурс облачных вычислений — это многократно используемый кластер виртуальных компьютеров. Выполните следующий код, чтобы создать вычислительный кластер машинного обучения Azure. Далее в примерах в этой статье используется созданное здесь вычисление с именем batch-cluster . Внесите необходимые изменения и сделайте ссылку на вычисление с помощью azureml:<your-compute-name> .

az ml compute create -n batch-cluster --type amlcompute --min-instances 0 --max-instances 5

Примечание

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

Общие сведения о пакетных конечных точках и развертываниях

Пакетная конечная точка — это конечная точка HTTPS, которую клиенты могут вызывать для запуска задания оценки пакетной службы. Задание оценки пакетной службы — это задание, которое оценивает несколько входных данных (дополнительные сведения см. в разделе Что такое конечные точки пакетной службы). Развертывание пакетной службы — это набор вычислительных ресурсов, в которых размещается модель, фактически выполняющая оценку пакетной службы. У одной пакетной конечной точки может быть несколько развертываний пакетной службы.

Совет

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

В следующем файле YAML определена пакетная конечная точка, которую можно включить в команду CLI для создания пакетной конечной точки. В репозитории этот файл находится в папке /cli/endpoints/batch/batch-endpoint.yml .

$schema: https://azuremlschemas.azureedge.net/latest/batchEndpoint.schema.json
name: mybatchedp
description: my sample batch endpoint
auth_mode: aad_token

Далее в таблице описаны ключевые свойства конечной точки YAML. Полная схема YAML для пакетной конечной точки приведена в разделе Схема YAML для пакетной конечной точки CLI (версия 2).

Ключ Описание
$schema [Необязательно]: схема YAML. Вы можете просмотреть схему из примера выше в браузере, чтобы увидеть все доступные параметры в файле YAML пакетной конечной точки.
name Имя учетной записи пакетной конечной точки. Должно быть уникальным на уровне региона Azure.
auth_mode Способ проверки подлинности для пакетной конечной точки. В настоящее время поддерживается только проверка подлинности на основе токенов Azure Active Directory (aad_token).
defaults.deployment_name Имя развертывания, которое будет использоваться в качестве развертывания по умолчанию для конечной точки.

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

  • Файлы модели, или зарегистрированная модель в вашем рабочем пространстве, на которую указана ссылка с помощью azureml:<model-name>:<model-version>.
  • Код для оценки модели.
  • Среда, в которой работает модель. Это может быть образ Docker с зависимостями Conda, или среда, уже зарегистрированная в рабочем пространстве, на которую указана ссылка с помощью azureml:<environment-name>:<environment-version>.
  • Предварительно созданное вычисление, на которое указана ссылка с помощью azureml:<compute-name>, и параметры ресурсов.

Дополнительные сведения о том, как указывать ссылку на объект Azure ML, см. в разделе Ссылки на объект Azure ML.

Пример репозитория содержит все необходимые файлы. Следующий файл YAML определяет развертывание пакетной службы со всеми необходимыми входными и дополнительными параметрами. Этот файл можно включить в команду интерфейса командной строки, чтобы создать развертывание пакетной службы. В репозитории этот файл находится в папке /cli/endpoints/batch/nonmlflow-deployment.yml.

$schema: https://azuremlschemas.azureedge.net/latest/batchDeployment.schema.json
name: nonmlflowdp
endpoint_name: mybatchedp
model: 
  path: ./mnist/model/
code_configuration:
  code: ./mnist/code/
  scoring_script: digit_identification.py
environment:
  conda_file: ./mnist/environment/conda.yml
  image: mcr.microsoft.com/azureml/openmpi3.1.2-ubuntu18.04:latest
compute: azureml:batch-cluster
resources:
  instance_count: 1
max_concurrency_per_instance: 2
mini_batch_size: 10
output_action: append_row
output_file_name: predictions.csv
retry_settings:
  max_retries: 3
  timeout: 30
error_threshold: -1
logging_level: info

Полная схема YAML для развертывания пакетной службы приведена в разделе Схема YAML для развертывания пакетной службы CLI (версия 2).

Ключ Описание
$schema [Необязательно]: схема YAML. Вы можете просмотреть схему из примера выше в браузере, чтобы увидеть все доступные параметры в файле YAML для развертывания пакетной службы.
name Имя развертывания.
endpoint_name Имя конечной точки для создания развертывания.
model Модель, используемая для пакетной оценки. В примере определяется встроенная модель с использованием path . Файлы модели будут автоматически переданы и зарегистрированы с помощью автоматического формирования имени и версии. Для получения дополнительных параметров следуйте схеме модели . В сценариях для рабочей среды рекомендуется создавать модель отдельно и ссылаться на нее здесь. Чтобы сослаться на существующую модель, используйте синтаксис azureml:<model-name>:<model-version>.
code_configuration.code.path Локальный каталог, содержащий весь исходный код Python для оценки модели.
code_configuration.scoring_script Файл Python в указанном выше каталоге. В этом файле должны быть функции init() и run(). Используйте функцию init() для любой дорогостоящей или распространенной подготовки (например, загрузите модель в память). init() будет вызываться только один раз в начале процесса. Метод run(mini_batch) позволяет оценить каждую запись; значение mini_batch представляет собой список путей к файлам. Функция run() должна возвращать объект DataFrame Pandas или массив. Каждый возвращаемый элемент обозначает один успешный запуск входного элемента в mini_batch. Дополнительные сведения о создании скрипта оценки см. на странице Основные сведения о скрипте оценки.
environment Среда для оценки модели. В примере определяется встроенная среда с использованием conda_file и image. Зависимости conda_file будут установлены поверх image. Среда будет автоматически зарегистрирована с автоматически сформированными именем и версией. Для получения дополнительных параметров следуйте схеме среды. В сценариях для рабочей среды рекомендуется создавать среду отдельно и ссылаться на нее здесь. Чтобы сослаться на существующую среду, используйте синтаксис azureml:<environment-name>:<environment-version>.
compute Вычисление для выполнения оценки пакетной службы. В примере используется объект batch-cluster, созданный в начале, и ссылка на него с помощью синтаксиса azureml:<compute-name>.
resources.instance_count Количество экземпляров, используемых для каждого задания оценки пакетной службы.
max_concurrency_per_instance [Необязательно]: Максимальное количество параллельных запусков scoring_script на экземпляр.
mini_batch_size [Необязательно]: число файлов, которые scoring_script может обрабатывать в одном вызове run().
output_action [Необязательно]: Как выходные данные должны быть упорядочены в выходном файле. append_row объединит все run() возвращенные выходные результаты в один файл с именем output_file_name. summary_only не будет объединять выходные результаты, а только вычислит error_threshold.
output_file_name [Необязательно]: Имя выходного файла оценки пакетной службы для append_rowoutput_action.
retry_settings.max_retries [Необязательно]: Максимальное количество попыток при сбое scoring_scriptrun().
retry_settings.timeout [Необязательно]: Время ожидания в секундах для scoring_scriptrun() для оценки мини-пакета.
error_threshold [Необязательно]: Количество сбоев оценки входных файлов, которое следует игнорировать. Если общее количество ошибок для всего объема входных данных превысит это значение, задание по оценке пакетной службы будет прервано. В примере используется -1, что означает, что любое количество ошибок разрешено без завершения задания пакетной оценки.
logging_level [Необязательно]: уровень детализации журнала. Значения уровня детализации в порядке увеличения: WARNING, INFO и DEBUG.

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

Как упоминалось ранее, code_configuration.scoring_script должен содержать две функции:

  • init(): Используйте эту функцию для любых затратных или повторяющихся операций подготовки. Например, в ней можно загружать модель в глобальный объект. Эта функция будет вызываться один раз в начале процесса.
  • run(mini_batch): Эта функция будет вызываться для каждого mini_batch и выполнять фактическую оценку.
    • mini_batch: значение mini_batch представляет собой список путей к файлам.
    • response: метод run() должен возвращать объект DataFrame Pandas или массив. Каждый возвращаемый выходной элемент обозначает один успешный запуск входного элемента во входном mini_batch. Убедитесь, что в ваш ответ run() включено достаточно данных, чтобы сопоставить входные данные с выходными данными. Результирующий кадр данных или массив заполняется в соответствии с этим скриптом оценки. Вам необходимо решить, сколько сведений вы хотите вывести, чтобы сопоставить выходные значения с входным значением. Например, массив может представлять список кортежей, содержащих как выходные, так и входные данные модели. Требований к кратности результатов нет. Все элементы в результирующем DataFrame или массиве записываются в выходной файл как есть (с учетом того, что output_action не является summary_only).

В этом примере используется /cli/endpoints/batch/mnist/code/digit_identification.py. Модель загружается в init() из AZUREML_MODEL_DIR, что представляет собой путь к папке модели, созданной во время развертывания. run(mini_batch) выполняет итерацию каждого файла в mini_batch, выполняет фактическую оценку модели и затем возвращает выходные результаты.

Развертывание с пакетными конечными точками и выполнение оценки пакетной службы

Теперь выполним развертывание модели с пакетными конечными точками и оценку пакетной службы.

Создание пакетной конечной точки

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

az ml batch-endpoint create --name $ENDPOINT_NAME

Вы также можете создать пакетную конечную точку с помощью файла YAML. Добавьте параметр --file в приведенной выше команде и укажите путь к файлу YAML.

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

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

az ml batch-deployment create --name nonmlflowdp --endpoint-name $ENDPOINT_NAME --file endpoints/batch/nonmlflow-deployment.yml --set-default

Совет

Параметр --set-default задает вновь созданное развертывание в качестве развертывания конечной точки по умолчанию. Это удобный способ создания нового развертывания конечной точки по умолчанию, особенно для первого создания развертывания. Для рабочих сценариев рекомендуется создать новое развертывание без настройки по умолчанию, проверить его и обновить развертывание по умолчанию позже. Дополнительные сведения см. в разделе Развертывание новой модели.

Проверка пакетной конечной точки и сведений о развертывании

Используйте show для проверки пакетной конечной точки и сведений о развертывании.

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

az ml batch-deployment show --name nonmlflowdp --endpoint-name $ENDPOINT_NAME

Чтобы проверить пакетную конечную точку, выполните следующий код. Поскольку вновь созданное развертывание устанавливается в качестве развертывания по умолчанию, вы должны увидеть nonmlflowdp в defaults.deployment_name в ответе.

az ml batch-endpoint show --name $ENDPOINT_NAME

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

При вызове пакетной конечной точки запускается задание оценки пакетной службы. Задание name будет возвращено из ответа на вызов и может использоваться для отслеживания хода выполнения оценки пакетной службы. Задание оценки пакетной службы выполняется в течение определенного периода времени. Все входные данные разбиваются на несколько mini_batch, и они обрабатываются параллельно в кластере вычислений. Один scoring_scriptrun() принимает один mini_batch и обрабатывает его в ходе процесса в экземпляре. Выходные данные задания оценки пакетной службы будут храниться в облачном хранилище, либо в хранилище BLOB-объектов рабочего пространства по умолчанию, либо в указанном вами хранилище.

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

Для конечной точки invoke можно использовать CLI или REST. Сведения о REST см. в статье Использование пакетных конечных точек с REST

Указать входные данные в CLI invoke можно несколькими способами.

  • Вариант 1-1. Данные в облаке

    Используйте --input и --input-type, чтобы указать файл или папку в зарегистрированном хранилище данных Машинного обучения Azure или общедоступный путь. Когда вы указываете один файл, используйте --input-type uri_file, а когда вы указываете папку, — --input-type uri_folder.

    Если файл или папка находится в зарегистрированном хранилище данных Azure ML, синтаксис для URI — это azureml://datastores/<datastore-name>/paths/<path-on-datastore>/ для папки и azureml://datastores/<datastore-name>/paths/<path-on-datastore>/<file-name> для определенного файла. Если файл или папка представляют общедоступный путь, синтаксис для URI — это https://<public-path>/ для папки и https://<public-path>/<file-name> для определенного файла.

    Дополнительные сведения о данных URI см. в разделе Справочный URI для данных машинного обучения Azure.

    В примере используются общедоступные данные в папке из https://pipelinedata.blob.core.windows.net/sampledata/mnist, которая содержит тысячи символов, написанных вручную. Имя задания оценки пакетной службы будет возвращено из ответа на вызов. Выполните следующий код, чтобы вызвать пакетную конечную точку с помощью этих данных. --query name добавляется только для возврата имени задания из ответа на вызов и будет использоваться позже для мониторинга хода выполнения задания оценки пакетной службы и проверки результатов оценки пакетной службы. Удалите --query name -o tsv, если хотите просмотреть полный ответ на вызов. Дополнительные сведения о параметре --query см. в разделе Вывод команды запроса Azure CLI.

    JOB_NAME=$(az ml batch-endpoint invoke --name $ENDPOINT_NAME --input https://pipelinedata.blob.core.windows.net/sampledata/mnist --input-type uri_folder --query name -o tsv)
    
  • Вариант 1-2. Зарегистрированные данные

    Используйте --input для передачи зарегистрированного ресурса данных Машинного обучения Azure версии 2 (с типом uri_file или url_folder). Для этого варианта не нужно указывать --input-type. Для этого варианта используется синтаксис azureml:<dataset-name>:<dataset-version>.

    az ml batch-endpoint invoke --name $ENDPOINT_NAME --input azureml:<dataset-name>:<dataset-version>
    
  • Вариант 2. Данные, хранимые локально

    Используйте --input для передачи файлов данных, хранимых локально. Для этого варианта не нужно указывать --input-type. Файлы данных будут автоматически отправлены в виде папки в хранилище данных Azure ML и переданы в задание пакетной оценки.

    az ml batch-endpoint invoke --name $ENDPOINT_NAME --input <local-path>
    

Примечание

  • Если вы используете существующий FileDataset версии 1 для пакетной конечной точки, мы рекомендуем перенести его в ресурсы данных версии 2 и обращаться к нему напрямую при вызове пакетных конечных точек. Сейчас поддерживаются только ресурсы данных типа uri_folder или uri_file. Пакетные конечные точки, созданные с помощью общедоступных выпусков CLI версии 2 (2.4.0 и выше ) или REST API (2022-05-01 и выше), не будут поддерживать набор данных версии 1.
  • Вы также можете извлечь URI или путь к хранилищу данных, извлеченному из FileDataset версии 1, с помощью команды az ml dataset show с параметром --query и использовать эту информацию для вызова.
  • Хотя конечные точки пакетной службы, созданные с помощью более ранних версий API, будут по-прежнему поддерживать FileDataset версии 1, мы добавим дополнительную поддержку ресурсов данных версии 2 с последними версиями API для удобства использования и гибкости. Дополнительные сведения о ресурсах данных версии 2 см. в статье Работа с данными с использованием пакета SDK версии 2 (предварительная версия). Дополнительные сведения о новых возможностях версии 2 см. в статье Что собой представляет версия 2?.

Настройка расположения выходных данных и параметров перезаписи

Результаты оценки пакетной службы по умолчанию записываются в хранилище BLOB-объектов рабочей области по умолчанию в папку под именем задания (уникальный идентификатор, сформированный системой). Вы можете настроить место хранения выходных данных оценки пакетной службы при вызове пакетной конечной точки. Используйте --output-path для настройки любой папки в зарегистрированном хранилище данных Машинного обучения Azure. Синтаксис для --output-path такой же, как --input при указании папки, т. е. azureml://datastores/<datastore-name>/paths/<path-on-datastore>/. Префикс folder: больше не требуется. Используйте --set output_file_name=<your-file-name> для настройки нового имени выходного файла, если вы предпочитаете использовать один выходной файл, содержащий все результаты оценки (указанные output_action=append_row в вашем развертывании YAML).

Важно!

Используйте новое (уникальное) расположение выходных данных. Если такой выходной файл существует, задание пакетной оценки завершится ошибкой.

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

  • Используйте --instance-count для перезаписи instance_count. Например, для больших объемов входных данных может потребоваться больше экземпляров для ускорения обработки до завершения оценки пакетной службы.
  • Используйте --mini-batch-size для перезаписи mini_batch_size. Число мини-пакетов определяется общим количеством входных файлов и размером мини-пакетов (mini_batch_size). Меньший параметр mini_batch_size создает больше мини-пакетов. Мини-пакеты можно запускать параллельно, но при этом могут возникнуть дополнительные затраты на планирование и вызов.
  • С помощью --set можно перезаписать другие параметры, включая max_retries, timeout и error_threshold. Эти параметры могут повлиять на конечное время оценки пакетной службы для разных рабочих нагрузок.

Чтобы указать расположение выходных данных и параметры перезаписи при вызове, выполните следующий код. В примере выходные данные сохраняются в папке с тем же именем, что и конечная точка в хранилище BLOB-объектов по умолчанию в рабочей области, а также используется случайное имя файла, чтобы обеспечить уникальность расположения выходных данных. Код должен работать в Unix. Замените собственной уникальной папкой и именем файла.

export OUTPUT_FILE_NAME=predictions_`echo $RANDOM`.csv
JOB_NAME=$(az ml batch-endpoint invoke --name $ENDPOINT_NAME --input https://pipelinedata.blob.core.windows.net/sampledata/mnist --input-type uri_folder --output-path azureml://datastores/workspaceblobstore/paths/$ENDPOINT_NAME --set output_file_name=$OUTPUT_FILE_NAME --mini-batch-size 20 --instance-count 5 --query name -o tsv)

Мониторинг хода выполнения задания оценки пакетной службы

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

Для просмотра задания можно использовать CLI job show. Выполните следующий код, чтобы проверить состояние задания из предыдущего вызова конечной точки. Чтобы узнать больше об этих командах, выполните команду az ml job -h.

STATUS=$(az ml job show -n $JOB_NAME --query status -o tsv)
echo $STATUS
if [[ $STATUS == "Completed" ]]
then
  echo "Job completed"
elif [[ $STATUS ==  "Failed" ]]
then
  echo "Job failed"
  exit 1
else 
  echo "Job status not failed or completed"
  exit 2
fi

Проверка результатов пакетной оценки

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

  1. Выполните следующий код, чтобы открыть задание оценки пакетной службы в студии машинного обучения Azure. Ссылка на студию содержится в ответе invoke в виде значения interactionEndpoints.Studio.endpoint.

    az ml job show -n $JOB_NAME --web
    
  2. На графике задания выберите шаг batchscoring.

  3. Перейдите на вкладку Выходные данные + журналы и выберите Показать выходные данные.

  4. Из выходных данных выберите значок, чтобы открыть Обозреватель службы хранилища.

Снимок экрана студии: просмотр расположения выходных данных

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

Снимок экрана: выходные данные оценки

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

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

Создание нового развертывания пакетной службы, содержащего модель MLflow

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

az ml batch-deployment create --name mlflowdp --endpoint-name $ENDPOINT_NAME --file endpoints/batch/mlflow-deployment.yml

Обратите внимание, что --set-default не используется. В случае повторной пакетной конечной точки show вы не увидите изменения defaults.deployment_name.

В примере используется модель (/cli/endpoints/batch/autolog_nyc_taxi), обученная и отслеживаемая с помощью MLflow. scoring_script и environment могут создаваться автоматически с помощью метаданных модели; нет необходимости указывать в файле YAML. Дополнительные сведения о MLflow см. в статье Обучение и отслеживание моделей машинного обучения с помощью MLflow и Машинного обучения Azure.

Ниже приведен файл YAML, используемый в примере для развертывания модели MLflow, которая содержит только минимальное количество обязательных свойств. Исходный файл в репозитории — /cli/endpoints/batch/mlflow-deployment.yml.

$schema: https://azuremlschemas.azureedge.net/latest/batchDeployment.schema.json
name: mlflowdp
endpoint_name: mybatchedp
model: 
  path: ./autolog_nyc_taxi
compute: azureml:batch-cluster

Примечание

scoring_script и environment автоматическое создание поддерживает только версию модели функции Python и подписи модели на основе столбцов.

Тестирование развертывания пакета, не используемое по умолчанию

Чтобы проверить новое развертывание, не используемое по умолчанию, выполните следующий код. В примере используется другая модель, которая принимает общедоступный CSV-файл из https://pipelinedata.blob.core.windows.net/sampledata/nytaxi/taxi-tip-data.csv.

JOB_NAME=$(az ml batch-endpoint invoke --name $ENDPOINT_NAME --deployment-name mlflowdp --input https://pipelinedata.blob.core.windows.net/sampledata/nytaxi/taxi-tip-data.csv --input-type uri_file --query name -o tsv)

echo "Show job detail"
az ml job show -n $JOB_NAME --web

echo "Stream job logs to console"
az ml job stream -n $JOB_NAME

STATUS=$(az ml job show -n $JOB_NAME --query status -o tsv)
echo $STATUS
if [[ $STATUS == "Completed" ]]
then
  echo "Job completed"
elif [[ $STATUS ==  "Failed" ]]
then
  echo "Job failed"
  exit 1
else 
  echo "Job status not failed or completed"
  exit 2
fi

Уведомление --deployment-name используется для указания нового имени развертывания. Этот параметр позволяет вам invoke развертывание, не используемое по умолчанию, и не будет обновлять развертывание по умолчанию для пакетной конечной точки.

Обновление развертывания пакетной службы по умолчанию

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

az ml batch-endpoint update --name $ENDPOINT_NAME --set defaults.deployment_name=mlflowdp

Теперь, в случае повторной пакетной конечной точки show вы должны увидеть, что defaults.deployment_name становится mlflowdp. Пакетную конечную точку можно invoke напрямую без параметра --deployment-name.

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

Если вы хотите обновить развертывание (например, обновить код, модель, среду или параметры), обновите файл YAML и введите команду az ml batch-deployment update. Обновление можно также выполнить без файла YAML с помощью --set. Подробнее см. в разделе az ml batch-deployment update -h.

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

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

az ml batch-deployment delete --name nonmlflowdp --endpoint-name $ENDPOINT_NAME --yes

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

az ml batch-endpoint delete --name $ENDPOINT_NAME --yes

Дальнейшие действия