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

Узнайте, как устранять неполадки и разрешать (или обходить) ошибки, которые могут возникнуть при развертывании модели в Экземплярах контейнеров Azure (ACI) и Службе Azure Kubernetes (AKS), с помощью Машинного обучения Azure.

Примечание.

При развертывании модели в Службе Azure Kubernetes (AKS) рекомендуется включить Azure Monitor для этого кластера. Это поможет определить общую работоспособность кластера и использование ресурсов. Могут также быть полезными следующие ресурсы.

Если вы пытаетесь развернуть модель в неработоспособном или перегруженном кластере, возникнут проблемы. Если вам нужна помощь в устранении неполадок кластера AKS, обратитесь в службу поддержки AKS.

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

Действия для развертывания Docker моделей машинного обучения

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

  1. Dockerfile, указанный в объекте Environments в файле InferenceConfig, отправляется в облако вместе с содержимым исходного каталога.
  2. Если ранее созданный образ недоступен в реестре контейнеров, новый образ Docker создается в облаке и сохраняется в реестре контейнеров по умолчанию для вашей рабочей области.
  3. Образ Docker из реестра контейнеров загружается в целевой объект вычислений.
  4. Хранилище BLOB-объектов вашей рабочей области по умолчанию подключено к целевому объекту вычислений, предоставляя доступ к зарегистрированным моделям.
  5. Веб-сервер инициализируется путем запуска функции init() начального сценария.
  6. Когда развернутая модель получает запрос, функция run() обрабатывает этот запрос.

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

Понимание этих общих шагов помогает разобраться, где возникают ошибки.

Получение журналов развертывания

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

ОБЛАСТЬ ПРИМЕНЕНИЯ: Расширение ML для Azure CLI версии 1

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

az ml service get-logs --verbose --workspace-name <my workspace name> --name <service name>

Отладка в локальной среде

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

HTTP-сервер вывода Машинного обучения Azure

Локальный сервер вывода позволяет быстро выполнить отладку начального сценария (score.py). Если базовый скрипт оценки имеет ошибку, сервер не может инициализировать или обслуживать модель. Вместо этого он создает исключение и расположение, в котором произошли проблемы. Подробнее об HTTP-сервере вывода Машинного обучения Azure

  1. Установите пакет azureml-inference-server-http из веб-канала PyPI.

    python -m pip install azureml-inference-server-http
    
  2. Запустите сервер и укажите score.py в качестве начального сценария:

    azmlinfsrv --entry_script score.py
    
  3. Отправьте запрос оценки на сервер с помощью команды curl.

    curl -p 127.0.0.1:5001/score
    

Примечание.

Изучите часто задаваемые вопросы о HTTP-сервере вывода машинного обучения Azure.

Контейнер невозможно запланировать

При развертывании службы в целевом объекте вычислений Служба Azure Kubernetes Машинное обучение Azure пытается запланировать службу с запрошенным объемом ресурсов. Если через 5 минут в кластере не появятся узлы с соответствующим количеством доступных ресурсов, развертывание завершится сбоем. Сообщение об ошибке: Couldn't Schedule because the kubernetes cluster didn't have available resources after trying for 00:05:00. Вы можете устранить эту ошибку, добавив больше узлов, изменив SKU своих узлов или изменив требования к ресурсам службы.

В сообщении об ошибке обычно указывается ресурс, количество которого необходимо увеличить. Например, если отображается сообщение об ошибке 0/3 nodes are available: 3 Insufficient nvidia.com/gpu, это означает, что для службы требуются GPU, а в кластере имеется три узла, у которых нет доступных GPU. Эту проблему можно решить, добавив больше узлов при использовании SKU-номера GPU. В противном случае переключитесь на SKU с поддержкой GPU или измените среду, избавившись от необходимости использовать GPU.

Сбой запуска службы

После успешной сборки образа система пытается запустить контейнер с использованием конфигурации развертывания. В ходе процесса запуска контейнера системой вызывается функция init() в скрипте оценки. При наличии неперехваченных исключений в функции init() в сообщении об ошибке может появиться ошибка CrashLoopBackOff.

Используйте сведения из статьи Проверка журнала Docker.

Запуск контейнера azureml-fe-aci завершается сбоем.

При развертывании службы в целевом объекте для вычисления экземпляра контейнера Azure Машинное обучение Azure пытается создать интерфейсный контейнер с именем azureml-fe-aci для запроса вывода. В случае azureml-fe-aci сбоя можно просмотреть журналы, выполнив az container logs --name MyContainerGroup --resource-group MyResourceGroup --subscription MySubscription --container-name azureml-fe-aci . Вы можете следовать сообщению об ошибке в журналах, чтобы внести исправление.

Наиболее распространенный сбой azureml-fe-aci заключается в том, что предоставленный SSL-сертификат или ключ является недопустимым.

Ошибка выполнения функции: get_model_path()

Часто в рамках функции init() в скрипте оценки вызывается функция Model.get_model_path(), чтобы найти файл модели или папку с файлами модели в контейнере. Если файл или папку модели найти не удается, происходит сбой функции. Самый простой способ устранить эту ошибку — это выполнить приведенный ниже код Python в оболочке контейнера.

ОБЛАСТЬ ПРИМЕНЕНИЯ:Пакет SDK для Python для ML Azure версии 1

from azureml.core.model import Model
import logging
logging.basicConfig(level=logging.DEBUG)
print(Model.get_model_path(model_name='my-best-model'))

Этот пример выводит локальный путь (относительно /var/azureml-app) в контейнер, где скрипт оценки ожидает найти файл модели или папку с файлами. Затем можно проверить, действительно ли файл или папка находится там, где нужно.

При установке уровня ведения журнала DEBUG (для отладки) в нем может регистрироваться дополнительная информация, которая может быть полезна для определения причины сбоя.

Ошибка выполнения функции: run(input_data)

Если служба успешно развернута, но аварийно завершает работу при публикации данных в конечную точку оценки, можно добавить оператор для перехвата ошибок в функцию run(input_data), чтобы она возвращала подробное сообщение об ошибке. Например:

def run(input_data):
    try:
        data = json.loads(input_data)['data']
        data = np.array(data)
        result = model.predict(data)
        return json.dumps({"result": result.tolist()})
    except Exception as e:
        result = str(e)
        # return error message back to the client
        return json.dumps({"error": result})

Примечание. Возврат сообщений об ошибках из вызова run(input_data) следует выполнять только в целях отладки. Из соображений безопасности сообщения об ошибках не следует возвращать таким способом в рабочей среде.

Код состояния HTTP 502

Код состояния 502 указывает, что в службе создано исключение или в методе run() файла score.py произошла ошибка. Используйте сведения из этой статьи для отладки файла.

Код состояния HTTP 503

Развертывания Службы контейнеров Azure поддерживают автомасштабирование, что позволяет добавлять реплики для поддержки дополнительной загрузки. Автомасштабирование предназначено для обработки постепенных изменений загрузки. В случае высоких скачков в запросах в секунду клиенты могут получить код состояния HTTP 503. Хотя автомасштабирование реагирует быстро, для создания дополнительных контейнеров AKS требуется значительное количество времени.

Решения для увеличения или уменьшения масштаба основываются на использовании текущих реплик контейнеров. Количество занятых (обрабатывающих запросы) реплик, деленное на общее число текущих реплик, и является показателем текущего использования. Если это число превышает autoscale_target_utilization, то создаются дополнительные реплики. Если оно меньше, то реплики сокращаются. Решения по добавлению реплик принимаются быстро (около 1 секунды). Решения по удалению реплик более консервативны и принимаются около 1 минуты. По умолчанию для целевого использования автоматического масштабирования установлено значение 70 %, а это означает, что служба может обрабатывать пики запросов в секунду (RPS) до 30 %.

Предотвратить появление кода состояния 503 можно двумя способами:

Совет

Эти два подхода можно использовать по отдельности или в сочетании.

  • Измените уровень использования, при котором автоматическое масштабирование создает новые реплики. Вы можете настроить целевое использование, задав для autoscale_target_utilization более низкое значение.

    Важно!

    Это изменение не ускорит создание реплик. Просто они будут создаваться с более низким порогом использования. Вместо того, чтобы ждать, пока служба использует реплики на 70 %, измените значения на 30 %. Таким образом реплики будут создаваться при использовании 30 %.

    Если веб-служба уже использует все текущие реплики, а код состояния 503 не исчезает, увеличьте значение autoscale_max_replicas, чтобы повысить максимальное количество реплик.

  • Измените минимальное количество реплик. Увеличение минимального количества реплик обеспечивает больший пул для обработки входящих пиков.

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

    from math import ceil
    # target requests per second
    targetRps = 20
    # time to process the request (in seconds)
    reqTime = 10
    # Maximum requests per container
    maxReqPerContainer = 1
    # target_utilization. 70% in this example
    targetUtilization = .7
    
    concurrentRequests = targetRps * reqTime / targetUtilization
    
    # Number of container replicas
    replicas = ceil(concurrentRequests / maxReqPerContainer)
    

    Примечание.

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

Дополнительные сведения о настройке autoscale_target_utilization, autoscale_max_replicas и autoscale_min_replicas см. на этой странице.

Код состояния HTTP 504

Код состояния 504 указывает, что время ожидания запроса истекло. Время ожидания по умолчанию составляет 1 минуту.

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

Другие сообщения об ошибках

Выполните приведенные ниже действия для следующих ошибок.

Ошибка Разрешение
Ошибка конфликта 409 Когда операция уже выполняется, любая новая операция в той же веб-службе отвечает с ошибкой конфликта 409. Например, если выполняется операция создания или обновления веб-службы, а при активации новой операции удаления возникает ошибка.
Сбой создания образа при развертывании веб-службы. Добавьте "pynacl==1.2.1" в качестве зависимости PIP в файл Conda для конфигурации образа.
['DaskOnBatch:context_managers.DaskOnBatch', 'setup.py']' died with <Signals.SIGKILL: 9> Измените номер SKU для виртуальных машин, используемых в развертывании, на другой с большим объемом памяти.
Сбой FPGA Вы не можете развертывать модели на FPGAs, пока не будет запрошено и утверждено для квоты FPGA. Чтобы запросить доступ, заполните форму запроса квоты: https://aka.ms/aml-real-time-ai

Расширенная отладка

Возможно, потребуется интерактивная отладка кода Python, содержащегося в развертывании модели. Например, если скрипт записи завершается сбоем, и причина не может быть определена с дополнительным ведением журнала. Используя Visual Studio Code и debugpy, вы можете подключить отладчик к коду, выполняющемуся внутри контейнера Docker.

Дополнительные сведения см. в руководстве по интерактивной отладке в VS Code.

Форум пользователей по развертыванию модели

Следующие шаги

Дополнительные сведения о развертывании см. в статьях, представленных ниже.