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

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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

Совет

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

Вы можете развернуть локально с помощью 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

Or

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 в команды.

Устранение распространенных ошибок развертывания в Azure с помощью Azure Resource Manager

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

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

ERROR: 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 ресурс Kubernetes также может выйти из квоты.

Квота ЦП

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

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

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

Ошибка OutOfQuota возникает, если у вас недостаточно Машинное обучение Azure квоты вычислительного кластера. Квота определяет общее количество кластеров для каждой подписки, которые можно использовать одновременно для развертывания узлов ЦП или 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

ОШИБКА: BadArgument

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

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

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

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

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

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

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

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

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

Эта ошибка возникает при неправильном указании функции шаблона. Исправьте политику или удалите назначение политики для разблокировки. Сообщение об ошибке может содержать имя назначения политики и определение политики для отладки этой ошибки. См . структуру определения политики 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>

Также проверьте, присутствуют ли большие двоичные объекты в учетной записи хранения рабочей области. Например, если большой двоичный объект имеется 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 компонент, который направляет входящие запросы вывода в развернутые службы во время установки расширения k8s и автоматически масштабируется по мере необходимости. Этот компонент должен иметь по крайней мере одну здоровую реплику в кластере.

Эта ошибка возникает, если компонент недоступен при активации веб-конечной точки 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 версии 2 и azureml-inference-server-http. Дополнительные сведения см. в разделе "Устранение неполадок с HTTP-сервером".

ОШИБКА: ResourceNotFound

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

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

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

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

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

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

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

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

Дополнительные диагностические сведения см. в статье "Использование диагностика рабочей области".

ОШИБКА: WorkspaceManagedNetworkNotReady

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

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

ОШИБКА: OperationCanceled

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

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

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

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

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

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

ОШИБКА: SecretInjectionError

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

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

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

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

ОШИБКА: InternalServerError

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

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

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

Ошибки аварийного восстановления:

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

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

ОШИБКА: ACRSecretError

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

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

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

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

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

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

ОШИБКА: TokenRefreshFailed

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

ОШИБКА: GetAADTokenFailed

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

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

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

ОШИБКА: ACRAuthenticationChallengeFailed

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

ОШИБКА: ACRTokenExchangeFailed

Эта ошибка возникает, так как маркер идентификатора Microsoft Entra еще не авторизован, поэтому маркер реестра контейнеров Kubernetes кластера 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 файле вызвала исключение. Проверьте журналы развертывания, чтобы просмотреть сообщение об исключении подробно и исправить исключение.

ERROR: 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 проверить, запущены ли модули pod сервера ретрансляции.

Проблемы с потреблением модели

Распространенные ошибки потребления модели, вызванные состоянием операции конечной точки 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 используют управляемые сетевые конечные точки:

Код состояния Причина Description
200 OK Модель успешно выполнена в пределах границ задержки.
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 подготовленная инфраструктура завершается сбоем.

Распространенные коды ошибок для сетевых конечных точек 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 подготовленная инфраструктура завершается сбоем.

Предотвращение ошибок кода состояния 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 значение, чтобы увеличить максимальное количество реплик.

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

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

Создание подключенной конечной точки завершается сбоем с сообщением V1LegacyMode == true

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

Сведения об отключении v1_legacy_modeсм. в разделе "Изоляция сети" с помощью версии 2.

Внимание

Обратитесь к группе безопасности сети перед отключением v1_legacy_mode, так как они могли включить ее по причине.

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

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

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

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

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

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

Сбой при выполнении сетевого развертывания с ошибкой скачивания образа

Примечание.

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

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

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

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

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

    az network private-endpoint-connection approve -n <private-endpoint-name>

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

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

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

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

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

    Примечание.

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

  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 endpointname.westcentralus.inference.ml.azure.com

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

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

  2. Также проверьте, работает ли azureml-fe должным образом, выполнив следующую команду:

    kubectl exec -it deploy/azureml-fe -- /bin/bash
(Run in azureml-fe pod)

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, проверьте, работает ли разрешение из Azure DNS (168.63.129.16).

    dig @168.63.129.16 endpointname.westcentralus.inference.ml.azure.com

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

Не удается оценить сетевые развертывания

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

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

    Если развертывание выполнено успешно, значение state равно Succeeded.

  2. Если развертывание выполнено успешно, с помощью следующей команды проверьте, назначен ли развертыванию трафик. Замените <endpointname> именем конечной точки.

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

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

    Совет

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

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

    az ml online-deployment get-logs  -e <endpointname> -n <deploymentname>

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

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

В этом разделе приведены основные советы по устранению неполадок для http-сервера Машинное обучение Azure вывода.

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

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

  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 перечислены журнал изменений и все предыдущие версии.

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

Версия пакета Description Проблема Решение
0.4.x Пакет в обучающие образы от дат 20220601 или более ранних версий и azureml-defaults версий .1.34 1.43пакетов. Последняя стабильная версия — 0.4.13. Для версий сервера, предшествующих версии 0.4.11, могут возникнуть проблемы с зависимостью Flask, например "can't import name Markup from jinja2". При возможности обновите до версии 0.4.13 или 0.8.x, последнюю версию.
0.6.x Предварительно установлен в изображениях вывода, датированных 20220516 и более ранних версий. Последняя стабильная версия — 0.6.1. Неприменимо Неприменимо
0.7.x Поддерживает Flask 2. Последняя стабильная версия — 0.7.7. Неприменимо Неприменимо
0.8.x Изменен формат журнала. Поддержка Python 3.6 прекращена. Неприменимо Неприменимо

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

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

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

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

Совет

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

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, убедитесь, что версия сборки образа — июль 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 нотации. В предыдущем примере версия образа — 20220708 8 июля 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или markupsafeclickво время запуска сервера. В следующем примере показано сообщение об ошибке:

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 — это интерфейсный компонент, который обрабатывает автомасштабирование для всех развертываний моделей в кластере Kubernetes. Дополнительные сведения см. в статье "Автомасштабирование Kubernetes" для маршрутизации вывода.

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