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

Устранение неполадок при развертывании и оценке веб-конечной точки

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

В этой статье описывается, как устранять и решать распространенные проблемы онлайн-развертывания и оценивания в Azure Machine Learning.

Структура документа отражает способ устранения неполадок:

  1. Используйте локальное развертывание для локального тестирования и отладки моделей перед их развертыванием в облаке.
  2. Используйте журналы контейнеров для отладки проблем.
  3. Изучите распространенные ошибки развертывания, которые могут возникнуть, и способы их устранения.

В разделе "Коды состояния HTTP" объясняется, как ошибки вызова и прогнозирования сопоставляют с кодами состояния HTTP при оценке конечных точек с помощью запросов REST.

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

Трассировка запросов

Существует два поддерживаемых заголовка трассировки:

  • x-request-id зарезервирован для отслеживания работы сервера. Машинное обучение Azure переопределяет этот заголовок, чтобы удостовериться в его допустимости как GUID. При создании заявки в службу поддержки по поводу сбоя, приложите идентификатор сбойного запроса, чтобы ускорить расследование. Кроме того, укажите имя региона и имя конечной точки.

  • x-ms-client-request-id доступен для случаев отслеживания клиентов. Этот заголовок принимает только буквенно-цифровые символы, дефисы и символы подчеркивания и усечен до не более 40 символов.

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

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

Совет

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

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

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

az ml online-deployment create --endpoint-name <endpoint-name> -n <deployment-name> -f <spec_file.yaml> --local

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

  1. Docker либо создает новый образ контейнера, либо извлекает существующий образ из локального кэша Docker. Docker использует существующий образ, если он соответствует части среды файла спецификации.
  2. Docker запускает новый контейнер с подключенными локальными артефактами, такими как файлы модели и кода.

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

Совет

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

Получите журналы контейнера

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

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

  • Журнал консоли сервера выводов содержит результаты функций печати и ведения журнала из скрипта оценки score.py.
  • Журналы инициализатора хранилища содержат информацию о том, были ли успешно загружены в контейнер данные кода и модели. Контейнер запускается до запуска контейнера сервера вывода.

Для сетевых конечных точек Kubernetes администраторы могут напрямую получить доступ к кластеру, в котором развертывается модель, и проверять журналы в Kubernetes. Рассмотрим пример.

kubectl -n <compute-namespace> logs <container-name>

Примечание.

Если вы используете ведение журнала Python, обязательно используйте правильный уровень ведения журнала, например INFO, для публикации сообщений в журналах.

Просмотр выходных данных журнала из контейнеров

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

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

Или

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> --lines 100

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

Добавьте --resource-group и --workspace-name в команды, если вы ещё не задали эти параметры через az configure. Чтобы просмотреть сведения о настройке этих параметров или если в настоящее время заданы значения, выполните следующую команду:

az ml online-deployment get-logs -h

Чтобы просмотреть дополнительные сведения, добавьте --help или --debug в команды.

Распространенные ошибки развертывания

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

Если вы создаете или обновляете онлайн-развертывание Kubernetes, см. также Распространенные ошибки, присущие развертываниям Kubernetes.

ОШИБКА: ImageBuildFailure

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

Точное расположение может быть возвращено как часть ошибки, например "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

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

сбой авторизации реестра контейнеров Azure

Сообщение об ошибке упоминает "container registry authorization failure", когда вы не можете получить доступ к реестру контейнеров с текущими учетными данными. Десинхронизация ключей ресурсов рабочей области может вызвать эту ошибку, и требуется некоторое время для автоматической синхронизации. Однако вы можете вручную вызвать синхронизацию ключей с az ml workspace sync-keys, что может устранить сбой авторизации.

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

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

Если в сообщении об ошибке упоминается "failed to communicate with the workspace's container registry", вы используете виртуальную сеть, и реестр контейнеров рабочей области является частным и настроен с использованием частной конечной точки, необходимо разрешить реестру контейнеров создавать образы в виртуальной сети.

Время ожидания на сборку образа истекло

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

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

Сбой сборки универсального образа

Дополнительные сведения о сбое см. в журнале сборки. Если в журнале сборки не найдено очевидных ошибок и последняя строка — Installing pip dependencies: ...working..., возможно, ошибка вызвана какой-либо зависимостью. Закрепление зависимостей версий в файле conda может устранить эту проблему.

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

ОШИБКА: OutOfQuota

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

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

Квота ЦП

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

Можно проверить наличие неиспользуемых развертываний, которые можно удалить, или отправить запрос на увеличение квоты.

Квота кластера

Ошибка OutOfQuota возникает, если ваша квота на вычислительный кластер Azure Machine Learning недостаточна. Квота определяет общее количество кластеров для каждой подписки, которые можно использовать одновременно для развертывания узлов ЦП или GPU в облаке Azure.

Дисковая квота

Ошибка OutOfQuota возникает, когда размер модели превышает доступное место на диске, а модель не может быть загружена. Попробуйте использовать SKU с большим дисковым пространством, или уменьшите размер образа и модели.

Квота на память

Ошибка OutOfQuota возникает, когда объем памяти модели превышает доступную память. Попробуйте SKU с большим объёмом памяти.

Квота назначения ролей

При создании управляемой онлайн-точки, для управляемого удостоверения требуется назначение ролей для доступа к ресурсам рабочей области. Если вы достигли лимита назначения ролей, попробуйте удалить неиспользуемые назначения ролей в этой подписке. Вы можете проверить все назначения ролей, выбрав Управление доступом для вашей подписки Azure в портале Azure.

Квота конечной точки

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

Квота Kubernetes

Ошибка OutOfQuota возникает, когда запрошенный ЦП или память не могут быть предоставлены из-за незапланированных узлов для этого развертывания. Например, узлы могут быть оцеплены или недоступны.

Сообщение об ошибке обычно указывает на нехватку ресурсов в кластере, например OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods.... Это сообщение означает, что в кластере слишком много podов и недостаточно ресурсов для развертывания новой модели в соответствии с вашим запросом.

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

  • ИТ-операторы, которые поддерживают кластер Kubernetes, могут попытаться добавить дополнительные узлы или очистить неиспользуемые pod в кластере, чтобы освободить ресурсы.

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

    • Если вы напрямую определяете запрос ресурсов в конфигурации развертывания с помощью раздела ресурсов, попробуйте уменьшить запрос ресурса.
    • Если вы используете instance_type для определения ресурса для развертывания модели, обратитесь к ИТ-оператору, чтобы настроить конфигурацию ресурса типа экземпляра. Дополнительные сведения см. в разделе "Создание типов экземпляров и управление ими".

Емкость виртуальной машины на уровне региона

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

Другая квота

Чтобы запустить файл score.py , предоставляемый в рамках развертывания, Azure создает контейнер, включающий все ресурсы, необходимые score.py . Машинное обучение Azure затем запускает скрипт оценки в этом контейнере. Если контейнер не удается запустить, оценка не может быть проведена. Контейнер может запрашивать больше ресурсов, чем instance_type может обеспечить. Рассмотрите возможность обновления instance_type развертывания в сети.

Чтобы получить точные причины ошибки, выполните следующее действие.

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

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

ОШИБКА: Неверный аргумент

Эта ошибка может возникать при использовании управляемых сетевых конечных точек или веб-конечных точек Kubernetes по следующим причинам:

Вы также можете получить эту ошибку при использовании только сетевых конечных точек Kubernetes по следующим причинам:

Подписка не существует

Указанная подписка Azure должна быть существующей и активной. Эта ошибка возникает, когда Azure не может найти введенный идентификатор подписки. Ошибка может возникнуть из-за опечатки в идентификаторе подписки. Убедитесь, что идентификатор подписки был правильно введён и в настоящее время активен.

Ошибка авторизации

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

Если вы создаете связанную конечную точку с удостоверением, назначенным пользователем, управляемое удостоверение пользователя должно иметь разрешение Чтение данных BLOB-объектов хранилища в хранилище рабочей области и разрешение AcrPull в реестре контейнеров рабочей области. Убедитесь, что пользовательское удостоверение имеет правильные права доступа.

Если MDC включен, управляемое удостоверение пользователя должно иметь разрешение участника данных BLOB для учетной записи хранения рабочей области. Более подробную информацию можно найти в разделе Ошибка авторизации объектов BLOB хранилища при включенной MDC.

Если вы создаете связанную конечную точку с системно назначенным удостоверением, разрешение на контроль доступа на основе ролей Azure (RBAC) автоматически предоставляется, и никаких дополнительных разрешений не требуется. Дополнительные сведения см. в разделе об ошибке авторизации реестра контейнеров.

Недопустимая спецификация функции шаблона

Эта ошибка возникает при неправильном указании функции шаблона. Исправьте политику или удалите назначение политики для разблокировки. Сообщение об ошибке может содержать имя назначения политики и определение политики для отладки этой ошибки. Смотрите структуру определения политики Azure, чтобы избежать ошибок в шаблонах.

Не удается скачать образ контейнера пользователя

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

Убедитесь, что образ контейнера доступен в реестре контейнеров в рабочей области. Например, если это изображение testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest, можно использовать следующую команду для проверки репозитория:

az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table`

Не удается скачать модель пользователя

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

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

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

az ml model show --name <model-name> --version <version>

Также проверьте, присутствуют ли объекты BLOB в учетной записи хранения рабочей области. Например, если блоб https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl, можно использовать следующую команду, чтобы проверить, существует ли блоб:

az storage blob exists --account-name <storage-account-name> --container-name <container-name> --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>

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

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> –-container storage-initializer`

Формат модели MLflow с частной сетью не поддерживается

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

Запросы ресурсов превышают ограничения

Запросы ресурсов должны быть меньше или равны ограничениям. Если ограничения не заданы, Машинное обучение Azure задает значения по умолчанию при присоединении вычислений к рабочей области. Ограничения можно проверить на портале Azure или с помощью команды az ml compute show.

Azureml-fe не готов

Фронтенд azureml-fe компонент, который направляет входящие запросы на вывод к развернутым службам, устанавливается во время установки к8s-расширения и автоматически масштабируется по мере необходимости. Этот компонент должен иметь по крайней мере одну здоровую реплику в кластере.

Эта ошибка возникает, если компонент недоступен при отправке запроса на онлайн-конечную точку Kubernetes или запроса на создание или обновление развертывания. Проверьте состояние и журналы pod'а, чтобы устранить эту проблему. Вы также можете попытаться обновить расширение k8s, установленное в кластере.

ОШИБКА: ResourceNotReady

Чтобы запустить файл score.py , предоставляемый в рамках развертывания, Azure создает контейнер, включающий все ресурсы, необходимые score.py , и запускает скрипт оценки в этом контейнере. Ошибка в этом сценарии заключается в том, что этот контейнер выходит из строя при выполнении, поэтому невозможно провести оценку. Эта ошибка может возникать в одном из следующих условий:

  • В score.py возникает ошибка. Используйте get-logs для диагностики распространенных проблем, таких как:

    • Пакет, который score.py пытается импортировать, но который отсутствует в среде conda.
    • ошибка синтаксиса;
    • сбой в методе init().

    Если get-logs не создаёт никаких логов, это обычно означает, что контейнер не удалось запустить. Чтобы выполнить отладку этой проблемы, попробуйте выполнить локальное развертывание.

  • Должным образом не настроены пробы готовности или активности.

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

  • В конфигурации окружения контейнера возникает ошибка, например, отсутствующие зависимости.

    Если вы получите ошибку TypeError: register() takes 3 positional arguments but 4 were given, проверьте зависимость между flask v2 и azureml-inference-server-http. Дополнительные сведения см. в разделе "Устранение неполадок с HTTP-сервером".

ОШИБКА: ResourceNotFound

Эта ошибка может возникнуть при использовании управляемой сетевой конечной точки или веб-конечной точки Kubernetes по следующим причинам:

Resource Manager не может найти ресурс

Эта ошибка возникает, когда Azure Resource Manager не удается найти необходимый ресурс. Например, эту ошибку можно получить, если учетная запись хранения не удается найти по указанному пути. Дважды проверьте путь или спецификации имен для точности и орфографии. Дополнительные сведения см. в разделе Устранение ошибки "Ресурс не найден".

Ошибка авторизации реестра контейнеров

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

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

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

Если это смягчение пройдет успешно, образ не требует сборки, и окончательный адрес изображения — указанный адрес изображения. Во время развертывания системное удостоверение конечной точки в Сети извлекает образ из частного реестра.

Для получения дополнительной диагностической информации см. раздел «Использование диагностики рабочей области».

ОШИБКА: WorkspaceManagedNetworkNotReady

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

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

ОШИБКА: Операция отменена

Эта ошибка может возникнуть при использовании управляемой сетевой конечной точки или веб-конечной точки Kubernetes по следующим причинам:

Операция отменена другой операцией с более высоким приоритетом

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

Операция отменена, поскольку ожидается подтверждение блокировки

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

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

ОШИБКА: SecretInjectionError

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

  • Удостоверение конечной точки не имеет разрешения Azure RBAC на чтение секретов из подключений к рабочей области или хранилищ ключей, даже если определение развертывания указало секреты в виде ссылок на переменные среды. Назначение ролей может занять время, чтобы изменения вступили в силу.

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

Дополнительные сведения см. в разделе "Внедрение секретов" в сетевых конечных точках (предварительная версия) и Получение доступа к секретам при онлайн-развертывании с помощью внедрения секретов (предварительная версия).

ОШИБКА: Внутренняя ошибка сервера

Эта ошибка означает, что со службой Машинного обучения Azure что-то не в порядке и её необходимо исправить. Отправьте запрос в службу поддержки клиентов со всеми сведениями, необходимыми для решения проблемы.

Распространенные ошибки, относящиеся к развертываниям Kubernetes

Ошибки идентификации и проверки подлинности:

Ошибки Crashloopbackoff

Ошибки скрипта оценки:

Другие ошибки:

ОШИБКА: ACRSecretError

При создании или обновлении веб-развертываний Kubernetes эта ошибка может возникнуть по одной из следующих причин:

  • Назначение ролей не завершено. Подождите несколько секунд и повторите попытку.

  • Кластер Kubernetes с поддержкой Azure Arc или расширение AKS Машинное обучение Azure не установлены или настроены должным образом. Проверьте конфигурацию и состояние Kubernetes с поддержкой Azure Arc или расширения Azure Machine Learning.

  • Кластер Kubernetes имеет неправильную конфигурацию сети. Проверьте прокси-сервер, политику сети или сертификат.

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

  • Версия вашего расширения Azure для машинного обучения — v1.1.25 или ниже. Убедитесь, что версия расширения больше версии 1.1.25.

ОШИБКА: TokenRefreshFailed

Ошибка возникает из-за того, что удостоверение кластера Kubernetes задано неправильно, и из-за этого расширение не может получить учетные данные главного субъекта из Azure. Переустановите расширение Машинное обучение Azure и повторите попытку.

ОШИБКА: GetAADTokenFailed

Эта ошибка возникает из-за того, что запрос кластера Kubernetes на получение токена Microsoft Entra ID завершился неудачей или истекло время ожидания. Проверьте сетевое подключение и повторите попытку.

  • Следуйте инструкциям по использованию вычислительных ресурсов Kubernetes, чтобы проверить исходящий прокси-сервер и убедиться, что кластер может подключиться к рабочей области. URL-адрес конечной точки рабочей области можно найти в пользовательском определении ресурсов (CRD) для сетевой конечной точки в кластере.

  • Проверьте, разрешен ли общий доступ к рабочему пространству. Независимо от того, является ли кластер AKS общедоступным или частным, если частная рабочая область отключает доступ к общедоступной сети, кластер Kubernetes может взаимодействовать с этой рабочей областью только через приватный канал. Дополнительные сведения см. в разделе "Что такое безопасная среда вывода AKS".

ОШИБКА: ACRAuthenticationChallengeFailed (ошибка аутентификации ACR)

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

ОШИБКА: Сбой при обмене токенов ACR

Эта ошибка возникает, так как токен Microsoft Entra ID еще не авторизован, поэтому не удается обмен токенами с реестром контейнеров кластера Kubernetes. Назначение роли занимает некоторое время, поэтому подождите минуту, а затем повторите попытку.

Этот сбой также может возникнуть из-за слишком большого количества одновременных запросов к службе реестра контейнеров. Эта ошибка должна быть временной, и вы можете повторить попытку позже.

ОШИБКА: KubernetesUnaccessible

При развертывании модели Kubernetes может возникнуть следующая ошибка:

{"code":"BadRequest","statusCode":400,"message":"The request is invalid.","details":[{"code":"KubernetesUnaccessible","message":"Kubernetes error: AuthenticationException. Reason: InvalidCertificate"}],...}

Чтобы устранить эту ошибку, можно повернуть сертификат AKS для кластера. Новый сертификат следует обновить через 5 часов, чтобы вы могли ждать 5 часов и повторно развернуть его. Для получения дополнительных сведений см. Обновление сертификатов в службе Azure Kubernetes (AKS).

ОШИБКА: ImagePullLoopBackOff

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

ОШИБКА: DeploymentCrashLoopBackOff

Эта ошибка вызывается при создании или обновлении онлайновых развертываний Kubernetes, так как контейнер пользователя крашнулся при инициализации. Существует две возможные причины этой ошибки:

  • Скрипт пользователя score.py имеет синтаксическую ошибку или ошибку импорта, которая вызывает исключения при инициализации.
  • Модулю развертывания требуется больше памяти, чем допустимое ограничение.

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

ОШИБКА: KubernetesCrashLoopBackOff

Эта ошибка может возникнуть при создании или обновлении конечных точек Kubernetes online или развертываний по одной из следующих причин:

  • Один или несколько podов застряли в состоянии CrashLoopBackoff. Проверьте наличие журнала развертывания и наличие сообщений об ошибках в журнале.
  • При инициализации вашего кода оценки в score.py произошла ошибка, и контейнер вышел из строя. Следуйте инструкциям в разделе ERROR: ResourceNotReady.
  • Для процесса оценки требуется больше памяти, чем ограничение конфигурации развертывания. Вы можете попытаться обновить развертывание путём увеличения ограничения памяти.

ОШИБКА: NamespaceNotFound

Эта ошибка может возникнуть при создании или обновлении конечных точек Kubernetes в Сети, так как пространство имен, используемое вычислением Kubernetes, недоступно в кластере. Проверьте вычислительные ресурсы Kubernetes в портале вашей рабочей области и проверьте пространство имен в вашем кластере Kubernetes. Если пространство имен недоступно, отсоедините устаревший вычислительный модуль и подсоедините его снова, указав пространство имен, которое уже существует в кластере.

ОШИБКА: UserScriptInitFailed

Эта ошибка может возникнуть при создании или обновлении развертываний Kubernetes в онлайн-среде, так как init функция в отправленном score.py файле вызвала исключение. Проверьте журналы развертывания, чтобы просмотреть сообщение об исключении подробно и исправить исключение.

ОШИБКА: UserScriptImportError

Эта ошибка может возникнуть при создании или обновлении онлайн-развертываний Kubernetes, так как файл score.py, который вы загрузили, импортирует недоступные пакеты. Проверьте журналы развертывания, чтобы просмотреть сообщение об исключении подробно и исправить исключение.

ОШИБКА: UserScriptFunctionNotFound

Эта ошибка может возникнуть при создании или обновлении развертываний Kubernetes в Сети, так как загруженный файл score.py не имеет функции с именем init() или run(). Проверьте код и добавьте функцию.

ОШИБКА: EndpointNotFound

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

ОШИБКА: EndpointAlreadyExists

Эта ошибка может возникнуть при создании веб-конечной точки Kubernetes, так как конечная точка уже существует в кластере. Имя конечной точки должно быть уникальным для каждой рабочей области и для каждого кластера, поэтому создайте конечную точку с другим именем.

Ошибка: ScoringFeUnhealthy

Эта ошибка может возникнуть при создании или обновлении конечной точки Kubernetes online или развертывания, так как системная служба Azureml-fe , которая выполняется в кластере, не найдена или неработоспособна. Чтобы устранить эту проблему, переустановите или обновите расширение Машинное обучение Azure в кластере.

ОШИБКА: ValidateScoringFailed

Эта ошибка может возникнуть при создании или обновлении развертываний Kubernetes в Сети, так как проверка URL-адреса запроса оценки завершилась сбоем при обработке модели. Проверьте URL-адрес конечной точки и повторите развертывание.

ОШИБКА: Неверная спецификация развертывания (InvalidDeploymentSpec)

Эта ошибка может возникнуть при создании или обновлении онлайн-развертываний Kubernetes, так как спецификация развертывания некорректна. Проверьте сообщение об ошибке, чтобы убедиться, что instance count является действительным. Если вы включили автоматическое масштабирование, убедитесь, что minimum instance count и maximum instance count являются допустимыми.

ОШИБКА: PodUnschedulable

Эта ошибка может возникнуть при создании или обновлении конечных точек Kubernetes online или развертываний по одной из следующих причин:

  • Система не может назначить pod на узлы, потому что в вашем кластере недостаточно ресурсов.
  • Узел не соответствует селектору сходства узлов.

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

  1. Проверьте node selector определение используемого вами instance_type, а также node label конфигурацию ваших узлов кластера.
  2. instance_type Проверьте размер SKU узла для кластера AKS или ресурса узла для кластера Kubernetes, поддерживающего Azure Arc.
  3. Если в кластере недостаточно ресурсов, уменьшите требования к ресурсам типа экземпляра или используйте другой тип экземпляра с меньшими требованиями к ресурсам.
  4. Если кластер не имеет дополнительных ресурсов для удовлетворения требований к развертыванию, удалите некоторые развертывания для освобождения ресурсов.

ОШИБКА: PodOutOfMemory

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

ОШИБКА: InferencingClientCallFailed

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

Чтобы устранить ошибки путем повторного подключения, необходимо повторно подключиться с той же конфигурацией, что и у отсоединенной вычислительной среды, например, с тем же именем и пространством имен, чтобы избежать других ошибок. Если он по-прежнему не работает, попросите администратора, имеющего доступ к кластеру, использовать kubectl get po -n azureml для проверки, запущены ли поды сервера ретрансляции.

Проблемы с эксплуатацией модели

Распространенные ошибки потребления модели, вызванные состоянием операции конечной точки invoke , включают проблемы ограничения пропускной способности, политику CORS и различные коды состояния HTTP.

Проблемы с ограничением пропускной способности

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

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

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

  • ms-azureml-bandwidth-request-delay-ms — время задержки в миллисекундах, необходимое для передачи потока запроса.
  • ms-azureml-bandwidth-response-delay-ms— время задержки в миллисекундах, необходимое для передачи потока ответа.

Заблокирована политикой CORS

Конечные точки версии 2 в сети изначально не поддерживают общий доступ к ресурсам между источниками (CORS). Если веб-приложение пытается вызвать конечную точку без правильной обработки предварительных запросов CORS, вы можете получить следующее сообщение об ошибке:

Access to fetch at 'https://{your-endpoint-name}.{your-region}.inference.ml.azure.com/score' from origin http://{your-url} has been blocked by CORS policy: Response to preflight request doesn't pass access control check. No 'Access-control-allow-origin' header is present on the request resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with the CORS disabled.

Для обработки предварительных запросов CORS можно использовать Функции Azure, Шлюз приложений Azure или другую службу в качестве промежуточного слоя.

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

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

Распространенные коды ошибок для управляемых сетевых конечных точек

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

Код состояния Причина Описание
200 ХОРОШО Модель успешно выполнена в рамках допустимой задержки.
401 Не авторизовано У вас нет разрешения на выполнение запрошенного действия, например, оценивания, или срок действия токена истек или токен в неправильном формате. Дополнительные сведения см. в разделе "Проверка подлинности для управляемых сетевых конечных точек" и "Аутентификация клиентов" для сетевых конечных точек.
404 Не найдено Конечная точка не имеет допустимого развертывания с положительным весом.
408 Время ожидания запроса Выполнение модели заняло больше времени, чем задано параметром request_timeout_ms в разделе request_settings конфигурации развертывания модели.
424 Ошибка модели Если контейнер модели возвращает ответ, отличный от 200, Azure возвращает код 424. Проверьте измерение Model Status Code в метрике Requests Per Minute в Обозревателе метрик Azure Monitor для конечной точки. Или проверьте заголовки ответа ms-azureml-model-error-statuscode и ms-azureml-model-error-reason, чтобы получить дополнительную информацию. Если 424 поставляется с ошибкой пробы активности или готовности, рассмотрите возможность настройки ProbeSettings , чтобы обеспечить больше времени для проверки активности контейнера или готовности.
429 Слишком много ожидающих выполнения запросов В настоящее время модель получает больше запросов, чем она может обрабатывать. Для обеспечения плавной работы Машинное обучение Azure позволяет одновременно обрабатывать максимальное 2 * max_concurrent_requests_per_instance * instance_count requests количество операций в любое время. Запросы, превышающие это максимальное, отклоняются.

Конфигурацию развертывания модели можно просмотреть в разделах request_settings и scale_settings, чтобы проверить и настроить эти параметры. Кроме того, убедитесь, что переменная WORKER_COUNT среды передается правильно, как описано в RequestSettings.

Если эта ошибка возникает при использовании автомасштабирования, модель получает запросы быстрее, чем система может увеличить масштаб. Рассмотрите возможность повторного отправки запросов с экспоненциальной задержкой, чтобы дать системе время для адаптации. Кроме того, можно увеличить количество экземпляров с помощью кода для вычисления количества экземпляров. Объедините эти шаги с настройкой автомасштабирования, чтобы убедиться, что модель готова к обработке притока запросов.
429 Ограничение скорости Количество запросов в секунду достигло ограничений управляемых онлайн конечных точек.
500 Внутренняя ошибка сервера. Инфраструктура, подготовленная на платформе Azure Machine Learning, дает сбой.

Распространенные коды ошибок для сетевых конечных точек Kubernetes

В следующей таблице содержатся распространенные коды ошибок, когда запросы REST используют сетевые конечные точки Kubernetes:

Код состояния Ошибка Описание
409 ошибка конфликта Когда операция уже выполняется, любая новая операция на том же самом сетевом конечном узле выдаёт ошибку конфликта 409. Например, если выполняется операция создания или обновления сетевой конечной точки, при запуске новой операции удаления возникает ошибка.
502 Исключение или сбой в методе run()файла score.py Если в score.py возникает ошибка, например, отсутствует импортированный пакет в среде conda, имеется синтаксическая ошибка или сбой в методе init(), обратитесь к ERROR: ResourceNotReady для отладки файла.
503 Большие пики запросов в секунду Автомасштабировщик предназначен для обработки постепенных изменений нагрузки. Если вы получаете большие пики запросов в секунду, клиенты могут получить код состояния HTTP 503. Хотя автомасштабирование реагирует быстро, для создания дополнительных контейнеров AKS требуется значительное количество времени. Узнайте , как предотвратить ошибки кода состояния 503.
504 Истекло время ожидания запроса Код состояния 504 указывает, что время ожидания запроса истекло. Значение времени ожидания по умолчанию — 5 секунд. Вы можете увеличить время ожидания или попытаться ускорить конечную точку, изменив score.py , чтобы удалить ненужные вызовы. Если эти действия не исправляют проблему, код может находиться в неответственном состоянии или бесконечном цикле. Следуйте ошибке: ResourceNotReady, чтобы отладить файл score.py.
500 Внутренняя ошибка сервера. Инфраструктура, подготовленная на платформе Azure Machine Learning, дает сбой.

Предотвращение ошибок кода состояния 503

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

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

  • Измените целевой объект использования, при котором автомасштабирование создает новые реплики, задав autoscale_target_utilization значение ниже. Это изменение не приводит к тому, что реплики будут создаваться быстрее, но при более низком пороге использования. Например, изменение значения на 30 % приводит к созданию реплик, когда 30 % используется вместо ожидания, пока служба не будет использована на 70 %.

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

Как определить число экземпляров

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

from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7

concurrent_requests = target_rps * request_process_time / target_utilization

# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)

Примечание.

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

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

Проблемы с сетевой изоляцией

В этом разделе содержатся сведения о распространенных проблемах сетевой изоляции.

Создание конечной точки в Сети завершается сбоем с сообщением о устаревшем режиме версии 1

Управляемые сетевые конечные точки — это функция платформы API Машинного обучения Azure версии 2. Если рабочая область машинного обучения Azure настроена для устаревшего режима версии 1, управляемые сетевые конечные точки не работают. В частности, если для параметра рабочей области задано значение v1_legacy_mode, включен устаревший режим версии 1 и не поддерживается API версии 2.

Чтобы узнать, как отключить устаревший режим версии 1, ознакомьтесь с изменением сетевой изоляции с помощью новой платформы API в Azure Resource Manager.

Внимание

Обратитесь к команде сетевой безопасности перед настройкой v1_legacy_mode на false, так как устаревший режим версии 1 может быть включен не просто так.

Сбой при создании онлайн-конечной точки с проверкой подлинности, основанной на ключах

Используйте следующую команду, чтобы получить список сетевых правил хранилища ключей Azure для рабочей области. Замените <key-vault-name> именем своего хранилища ключей.

az keyvault network-rule list -n <key-vault-name>

Ответ для этой команды аналогичен следующему коду JSON:

{
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [],
    "virtualNetworkRules": []
}

Если значение bypass не равно AzureServices, используйте инструкции в разделе "Настройка параметров сети Azure Key Vault", чтобы задать для него значение AzureServices.

Отказ онлайн-развертываний с ошибкой загрузки образа

Примечание.

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

  1. Проверьте, имеет ли egress-public-network-access флаг значение disabled для развертывания. Если этот флаг включен, а видимость реестра контейнеров является частной, ожидается этот сбой.

  2. Используйте следующую команду, чтобы проверить состояние подключения к частной конечной точке. Замените <registry-name> именем Реестра контейнеров Azure для рабочей области:

    az acr private-endpoint-connection list -r <registry-name> --query "[?privateLinkServiceConnectionState.description=='Egress for Microsoft.MachineLearningServices/workspaces/onlineEndpoints'].{ID:id, status:privateLinkServiceConnectionState.status}"

    В коде ответа убедитесь, что status для поля задано значение Approved. Если значение не совпадает с Approved, используйте следующую команду, чтобы одобрить соединение. Замените <private-endpoint-connection-ID> идентификатором, возвращаемого предыдущей командой.

    az network private-endpoint-connection approve --id <private-endpoint-connection-ID> --description "Approved"

Не удается решить конечную точку оценки

  1. Убедитесь, что клиент, отправивший запрос оценки, представляет виртуальную сеть, которая имеет доступ к рабочей области Машинного обучения Azure.

  2. nslookup Используйте команду в имени узла конечной точки, чтобы получить сведения об IP-адресе:

    nslookup <endpoint-name>.<endpoint-region>.inference.ml.azure.com

    Например, команда может выглядеть примерно так:

    nslookup endpointname.westcentralus.inference.ml.azure.com

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

    Примечание.

    • Для конечной точки Kubernetes в Сети имя узла конечной точки должно быть CName (доменное имя), указанное в кластере Kubernetes.
    • Если конечная точка использует HTTP, IP-адрес содержится в URI конечной точки, который можно получить из пользовательского интерфейса студии.
    • Чтобы узнать дополнительные способы получения IP-адреса конечной точки, см. Обновите свой DNS с помощью полного доменного имени.

  3. nslookup Если команда не распознает имя узла, выполните шаги в одном из следующих разделов.

Управляемые сетевые конечные точки

  1. Используйте следующую команду, чтобы проверить, существует ли запись A в зоне частных доменных имен (DNS) для виртуальной сети.

    az network private-dns record-set list -z privatelink.api.azureml.ms -o tsv --query [].name

    Результаты должны содержать запись, аналогичную *.<GUID>.inference.<region>.

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

  3. Если рабочая область с частной конечной точкой использует пользовательский DNS-сервер, выполните следующую команду, чтобы убедиться, что разрешение с пользовательского DNS-сервера работает правильно:

    dig <endpoint-name>.<endpoint-region>.inference.ml.azure.com

Сетевые конечные точки Kubernetes

  1. Проверьте конфигурацию DNS в кластере Kubernetes.

  2. Проверьте, azureml-feработает ли маршрутизатор вывода машинного обучения Azure, как ожидалось. Чтобы выполнить эту проверку, выполните следующие действия.

    1. Выполните следующую команду в поде azureml-fe:

      kubectl exec -it deploy/azureml-fe -- /bin/bash

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

      curl -vi -k https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

      Для HTTP используйте следующую команду:

      curl https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

  3. Если команда curl HTTPS завершается ошибкой или истекает время ожидания, но команда HTTP работает, проверьте, является ли сертификат допустимым.

  4. Если предыдущий процесс не удалось определить запись A, используйте следующую команду, чтобы проверить, работает ли разрешение с виртуального общедоступного IP-адреса Azure DNS, 168.63.129.16:

    dig @168.63.129.16 <endpoint-name>.<endpoint-region>.inference.ml.azure.com

  5. Если предыдущая команда выполняется успешно, устраните неполадки условного пересылателя для Azure Private Link на пользовательском DNS.

Невозможно присвоить оценку онлайн-развертываниям

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

    az ml online-deployment show -e <endpoint-name> -n <deployment-name> --query '{name:name,state:provisioning_state}'

    Значение Succeeded поля state указывает на успешное развертывание.

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

    az ml online-endpoint show -n <endpoint-name>  --query traffic

    Ответ этой команды должен содержать процент трафика, назначенного каждому развертыванию.

    Совет

    Этот шаг не нужен, если в своем запросе вы используете заголовок azureml-model-deployment, чтобы нацелиться на это развертывание.

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

    az ml online-deployment get-logs  -e <endpoint-name> -n <deployment-name>

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

Проблемы с сервером выводов

В этом разделе приведены основные советы по устранению неполадок для HTTP-сервера вывода Azure Machine Learning.

Проверка установленных пакетов

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

  1. Сбор сведений об установленных пакетах и версиях среды Python.

  2. В файле среды проверьте версию указанного azureml-inference-server-http пакета Python. В журналах запуска HTTP-сервера машинного обучения Azure проверьте версию сервера прогнозирования, которая отображается. Убедитесь, что совпадают две версии.

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

  3. Если вы указываете Flask или его зависимости в вашей среде, удалите эти элементы.

    • Зависимые пакеты включают flask, , jinja2, itsdangerouswerkzeug, markupsafeи click.
    • Пакет flask указан как зависимость в пакете сервера вывода. Лучший подход — разрешить серверу вывода установить flask пакет.
    • Когда сервер вывода настроен на поддержку новых версий Flask, сервер вывода автоматически получает обновления пакета по мере их доступности.

Проверка версии сервера вывода

Пакет azureml-inference-server-http сервера публикуется в PyPI. На странице PyPI перечислены журнал изменений и все версии пакета.

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

Версия пакета Описание Проблема Решение
0.4.x Включенные в обучающие образы, датированные 20220601 или ранее, и версии пакетов от 0.1.34 до 1.43. Последняя стабильная версия — 0.4.13. Для версий сервера, предшествующих версии 0.4.11, могут возникнуть проблемы с зависимостью Flask, например can't import name Markup from jinja2. При возможности обновите до версии 0.4.13 или 1.4.x, последнюю версию.
0.6.x Предварительно установлен в изображениях инференции, датированных 20220516 и более ранние. Последняя стабильная версия — 0.6.1. Неприменимо Неприменимо
0.7.x Поддерживает Flask 2. Последняя стабильная версия — 0.7.7. Неприменимо Неприменимо
0.8.x Использует обновленный формат журнала. Заканчивает поддержку Python 3.6. Неприменимо Неприменимо
1.0.x Заканчивает поддержку Python 3.7. Неприменимо Неприменимо
1.1.x Переход на pydantic 2.0. Неприменимо Неприменимо
1.2.x Добавляет поддержку Python 3.11. Обновляется gunicorn до версии 22.0.0. Обновляет werkzeug до версии 3.0.3 и более поздних версий. Неприменимо Неприменимо
1.3.x Добавляет поддержку Python 3.12. certifi Обновляется до версии 2024.7.4. flask-cors Обновляется до версии 5.0.0. Обновляет пакеты gunicorn и pydantic. Неприменимо Неприменимо
1.4.x waitress Обновляется до версии 3.0.1. Заканчивает поддержку Python 3.8. Удаляет слой совместимости, который предотвращает сбой кода объекта запроса при обновлении до Flask 2.0. Если вы зависите от уровня совместимости, код объекта запроса может не работать. Перенос вашего скрипта подсчета на Flask 2.

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

Ниже перечислены наиболее важные зависимые пакеты для azureml-inference-server-http пакета сервера:

  • flask
  • opencensus-ext-azure
  • inference-schema

Если указать azureml-defaults пакет в среде Python, azureml-inference-server-http пакет является зависимым пакетом. Зависимость устанавливается автоматически.

Совет

Если вы используете SDK машинного обучения Azure для Python версии 1 и не указываете пакет azureml-defaults в своей среде Python, SDK может автоматически его добавить. Однако версия пакета заблокирована относительно версии SDK. Например, если версия пакета SDK 1.38.0, в требования pip среды добавляется запись azureml-defaults==1.38.0.

TypeError во время запуска сервера вывода

Во время запуска инференс-сервера вы можете столкнуться со следующим TypeError:

TypeError: register() takes 3 positional arguments but 4 were given

  File "/var/azureml-server/aml_blueprint.py", line 251, in register

    super(AMLBlueprint, self).register(app, options, first_registration)

TypeError: register() takes 3 positional arguments but 4 were given

Эта ошибка возникает при установке Flask 2 в среде Python, но версия azureml-inference-server-http пакета не поддерживает Flask 2. Поддержка Flask 2 доступна в пакете azureml-inference-server-http 0.7.0 и более поздних версиях, а azureml-defaults также в пакете 1.44 и более поздних версиях.

  • Если вы не используете пакет Flask 2 в образе Docker для службы машинного обучения Azure, используйте последнюю версию пакета azureml-inference-server-http или пакета azureml-defaults.

  • Если вы используете пакет Flask 2 в Docker-образе для машинного обучения Azure, убедитесь, что версия сборки July 2022 или более поздняя.

    Версию образа можно найти в логах контейнера. Например, обратите внимание на следующие записи журнала:

    2022-08-22T17:05:02,147738763+00:00 | gunicorn/run | AzureML Container Runtime Information
2022-08-22T17:05:02,161963207+00:00 | gunicorn/run | ###############################################
2022-08-22T17:05:02,168970479+00:00 | gunicorn/run | 
2022-08-22T17:05:02,174364834+00:00 | gunicorn/run | 
2022-08-22T17:05:02,187280665+00:00 | gunicorn/run | AzureML image information: openmpi4.1.0-ubuntu20.04, Materialization Build:20220708.v2
2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
2022-08-22T17:05:02,190557998+00:00 | gunicorn/run |

    Дата сборки изображения отображается после Materialization Build нотации. В предыдущем примере версия образа — 202207088 июля 2022 г. Изображение в этом примере совместимо с Flask 2.

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

    Если вы используете сервер вывода с веб-конечной точкой, вы также можете найти журналы в Студии машинного обучения Azure. На странице конечной точки выберите вкладку "Журналы".

При развертывании с использованием SDK версии 1 и если вы не указываете явно образ в конфигурации развертывания, сервер инференции применяет пакет openmpi4.1.0-ubuntu20.04 с версией, которая соответствует вашему локальному набору инструментов SDK. Однако установленная версия может не быть последней доступной версией образа.

Для SDK версии 1.43 сервер выводов по умолчанию устанавливает openmpi4.1.0-ubuntu20.04:20220616 версию пакета, но она несовместима с SDK 1.43. Убедитесь, что для развертывания используется последняя версия пакета SDK.

Если вы не можете обновить изображение, можно временно избежать проблемы, закрепив записи azureml-defaults==1.43 или azureml-inference-server-http~=0.4.13 в файле среды. Эти записи направляют сервер прогнозирования, чтобы установить более старую версию flask 1.0.x.

ImportError или ModuleNotFoundError во время запуска сервера предсказаний

Во время запуска сервера вывода может возникнуть ImportError или ModuleNotFoundError на определенных модулях, например opencensus, jinja2, markupsafe или click. В следующем примере показано сообщение об ошибке:

ImportError: cannot import name 'Markup' from 'jinja2'

Ошибки импорта и модуля возникают при использовании версии 0.4.10 или более ранних версий сервера вывода, которые не закрепляют зависимость Flask к совместимой версии. Чтобы предотвратить проблему, установите более позднюю версию сервера вывода.

Другие распространенные проблемы.

Другие распространенные проблемы с сетевыми конечными точками связаны с установкой и автомасштабированием conda.

Проблемы с установкой Conda

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

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

  1. Проверьте журналы установки conda. Если контейнер завершился сбоем или его запуск занял слишком много времени, вероятно, обновление среды conda не удалось правильно выполнить.
  2. Установите файл conda mlflow локально с помощью команды conda env create -n userenv -f <CONDA_ENV_FILENAME>.
  3. Если в локальной среде возникают ошибки, попробуйте восстановить среду conda и создать работоспособную перед повторным развертыванием.
  4. Если контейнер дает сбой, даже если разрешение происходит локально, размер SKU, используемый для развертывания, может быть недостаточным.
    • Установка пакета Conda происходит в процессе выполнения, поэтому если размер SKU слишком мал, чтобы разместить все пакеты в conda.yml, контейнер может завершиться сбоем.
    • Виртуальная машина Standard_F4s_v2 — это хороший начальный размер SKU, но могут потребоваться более крупные виртуальные машины в зависимости от зависимостей, которые указывает файл conda.
    • Для сетевых конечных точек Kubernetes кластер Kubernetes должен иметь не менее четырех ядер виртуального ЦП и 8 ГБ памяти.

Проблемы с автомасштабированием

Если у вас возникли проблемы с автомасштабированием, см. "Устранение неполадок в автомасштабировании Azure Monitor".

Для сетевых конечных точек Kubernetes маршрутизатор выводов Azure Machine Learning — это фронтенд-компонент, который управляет автомасштабированием для всех развертываний моделей в кластере Kubernetes. Для получения дополнительной информации см. Маршрутизация выводов в Kubernetes с автомасштабированием.

Связанный контент