Устранение неполадок при развертывании и оценке подключенных конечных точек

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

Совет

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

Установка Conda

Как правило, проблемы с развертыванием MLflow связаны с проблемами при установке пользовательской среды, указанной conda.yaml в файле.

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

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

  2. Установите файл conda mlflow локально с помощью команды conda env create -n userenv -f <CONDA_ENV_FILENAME>.

  3. Если в локальной среде возникают ошибки, попробуйте разрешить среду conda и создать рабочую перед повторным развертыванием.

  4. Если контейнер завершает работу даже при локальном разрешении, размер SKU, используемый для развертывания, может быть слишком мал.

    1. Установка пакета Conda происходит во время выполнения, поэтому если размер номера SKU слишком мал для размещения всех пакетов, подробных в conda.yaml файле среды, контейнер может завершиться сбоем.
    2. Standard_F4s_v2 виртуальная машина является хорошим начальным размером SKU, но в зависимости от того, какие зависимости указаны в файле conda, могут потребоваться большие.
    3. Для конечной точки Kubernetes в сети кластер Kubernetes должен иметь не менее 4 виртуальных ЦП и 8 ГБ памяти.

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

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

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

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

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

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

Добавьте --resource-group и --workspace-name в эти команды, если эти параметры еще не заданы.az configure

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

az ml online-deployment get-logs -h

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

Примечание.

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

Также можно получить журналы из контейнера инициализатора хранилища с помощью параметра –-container storage-initializer.

Для просмотра дополнительных сведений добавьте команды --help и (или) --debug.

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

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

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

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

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

    Примечание.

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

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

Устранение распространенных ошибок развертывания в 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]'".

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

Мы также рекомендуем просмотреть параметры пробы по умолчанию, если у вас есть время ожидания ImageBuild.

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

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

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

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

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

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

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

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

ОШИБКА: OutOfQuota

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

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

Квота ЦП

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

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

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

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

Возможное устранение рисков заключается в том, чтобы проверка при наличии неиспользуемых развертываний, которые можно удалить. Также можно отправить запрос на увеличение квоты. Обязательно выберите Machine Learning Service: Cluster Quota тип квоты для этого запроса на увеличение квоты.

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

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

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

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

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

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

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

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

Квота Kubernetes

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

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

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

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

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

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

Другая квота

Для запуска скрипта score.py в рамках развертывания Azure создает контейнер, который содержит все необходимые скрипту score.py ресурсы, и выполняет в этом контейнере скрипт оценки.

Если контейнер не удалось запустить, это означает, что оценка не может произойти. Возможно, контейнер запрашивает больше ресурсов, чем может поддерживать 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 пытается извлечь образ контейнера пользователя из рабочей области Реестр контейнеров Azure (ACR). Он пытается подключить модель пользователя и артефакты кода к контейнеру пользователя из учетной записи хранения рабочей области.

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

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

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

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

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

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

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

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

Убедитесь, что образ контейнера доступен в ACR рабочей области.

Например, для образа 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 foobar --container-name 210212154504-1517266419 --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>`
    
  • Если BLOB-объект присутствует, эту команду можно использовать для получения журналов из инициализатора хранилища:

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

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

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

Дополнительные сведения см. в статье Устранение ошибок "Ресурс не найден".

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

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

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

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

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

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

ОШИБКА: OperationCanceled

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

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

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

Повторная попытка операции может привести к ее выполнению без отмены.

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

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

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

ОШИБКА: SecretInjectionError

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

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

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

ОШИБКА: InternalServerError

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

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

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

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

Ошибки, касающиеся скрипта оценки:

Прочее:

ОШИБКА: ACRSecretError

Ниже приведен список причин, по которым может возникнуть эта ошибка при создании и обновлении развертываний Kubernetes в сети:

  • Назначение роли не завершено. В этом случае подождите несколько секунд и повторите попытку позже.
  • Расширение Azure ARC (для кластера Azure Arc Kubernetes) или расширение Машинное обучение Azure (для AKS) не установлено или настроено должным образом. Попробуйте проверка конфигурацию и состояние расширения Azure ARC или Машинное обучение Azure.
  • Кластер Kubernetes имеет неправильную конфигурацию сети, проверка прокси-сервер, сетевую политику или сертификат.
    • Если вы используете частный кластер AKS, необходимо настроить частные конечные точки для ACR, учетной записи хранения, рабочей области в виртуальной сети AKS.
  • Убедитесь, что версия расширения Машинное обучение Azure больше версии 1.1.25.

ОШИБКА: TokenRefreshFailed

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

ОШИБКА: GetAADTokenFailed

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

  • Чтобы проверка исходящий прокси-сервер, можно выполнить настройку требуемого сетевого трафика, убедитесь, что кластер может подключиться к рабочей области.
  • URL-адрес конечной точки рабочей области можно найти в crD веб-конечной точки в кластере.

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

  • Вы можете проверка, если доступ к рабочей области разрешает общедоступный доступ, независимо от того, является ли кластер AKS общедоступным или частным, он не может получить доступ к частной рабочей области.
  • Дополнительные сведения см. в разделе "Безопасная Служба Azure Kubernetes выводов"

ОШИБКА: ACRAuthenticationChallengeFailed

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

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

ОШИБКА: ACRTokenExchangeFailed

Эта ошибка возникает из-за сбоя маркера ACR кластера Kubernetes, так как маркер Azure AD еще не авторизован. Так как назначение роли занимает некоторое время, поэтому вы можете ждать момент, а затем повторите попытку.

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

ОШИБКА: KubernetesUnaccessible

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

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

Чтобы устранить эту ошибку, можно:

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

ОШИБКА: ImagePullLoopBackOff

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

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

ОШИБКА: DeploymentCrashLoopBackOff

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

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

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

ОШИБКА: KubernetesCrashLoopBackOff

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

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

ОШИБКА: NamespaceNotFound

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

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

ОШИБКА: UserScriptInitFailed

Причина, по которой возникает эта ошибка при создании и обновлении развертываний Kubernetes в Сети, заключается в том, что функция инициализации в отправленном score.py файле вызвала исключение.

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

ERROR: UserScriptImportError

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

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

ОШИБКА: UserScriptFunctionNotFound

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

ОШИБКА: EndpointNotFound

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

ОШИБКА: EndpointAlreadyExists

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

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

ОШИБКА: ScoringFeUnhealthy

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

Чтобы устранить эту проблему, можно переустановить или обновить расширение Машинное обучение Azure в кластере.

ОШИБКА: ValidateScoringFailed

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

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

ОШИБКА: InvalidDeploymentSpec

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

В этом случае можно проверка сообщение об ошибке.

  • Убедитесь, что он действителен instance count .
  • Если вы включили автоматическое масштабирование, убедитесь, что minimum instance count они maximum instance count допустимы.

ОШИБКА: PodUnschedulable

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

  • Не удается запланировать выполнение pod на узлы из-за нехватки ресурсов в кластере.
  • Сопоставление узлов и селектора не соответствует узлу.

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

  • node selector Проверьте определение используемых instance type узлов кластера и node label конфигурацию.
  • Проверьте instance type и размер SKU узла для кластера AKS или ресурса узла для кластера Arc-Kubernetes.
    • Если кластер находится под ресурсом, можно уменьшить требование к ресурсу типа экземпляра или использовать другой тип экземпляра с меньшим ресурсом.
  • Если в кластере больше нет ресурсов для удовлетворения требований развертывания, удалите некоторые развертывания для освобождения ресурсов.

ОШИБКА: PodOutOfMemory

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

ОШИБКА: InferencingClientCallFailed

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

В этом случае можно отсоединить и повторно подключить вычислительные ресурсы.

Примечание.

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

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

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

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

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

Распространенные ошибки потребления моделей

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

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

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

  • Используйте метрику "Сетевые байты", чтобы понять текущее использование пропускной способности. Дополнительные сведения см. в статье Отслеживание управляемых сетевых конечных точек.
  • При принудительном применении ограничения пропускной способности возвращается два трейлера ответа:
    • ms-azureml-bandwidth-request-delay-ms: время задержки в миллисекундах, затраченное на передачу потока запроса.
    • ms-azureml-bandwidth-response-delay-ms: время задержки в миллисекундах, затраченное на передачу потока ответа.

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

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

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

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

Код состояния Описание причины Почему может возвращаться этот код
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 поставляется с ошибкой пробы активности или готовности, рассмотрите возможность настройки параметров пробы , чтобы разрешить более длительное время для проверки активности или готовности контейнера.
429 Слишком много ожидающих выполнения запросов В настоящее время модель получает больше запросов, чем она может обрабатывать. Машинное обучение Azure реализовала систему, которая позволяет параллельно обрабатывать максимальное 2 * max_concurrent_requests_per_instance * instance_count requests количество операций в любой момент, чтобы гарантировать беспроблемную работу. Другие запросы, превышающие это максимальное значение, отклоняются. Конфигурацию развертывания модели можно просмотреть в разделах request_settings и scale_settings, чтобы проверить и настроить эти параметры. Кроме того, как описано в определении YAML для запроса Параметры, важно убедиться, что переменная WORKER_COUNT среды передается правильно.

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

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

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

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

Как предотвратить ошибки с кодом состояния 503

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

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

Совет

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

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

    Внимание

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

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

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

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

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

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

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

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)

Заблокирована политикой 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.

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

Распространенные проблемы с сетевой изоляцией

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

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

Внимание

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

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

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

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

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

Отклик на эту команду будет похож на приведенный ниже документ JSON:

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

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

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

Примечание.

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

  1. Убедитесь, что флаг 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. Чтобы получить сведения об IP-адресе, используйте команду nslookup в имени узла конечной точки:

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

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

    Примечание.

    Для конечной точки Kubernetes в Сети имя узла конечной точки должно быть CName (доменное имя), указанное в кластере Kubernetes. Если это конечная точка HTTP, IP-адрес будет содержаться в URI конечной точки, которую можно получить непосредственно в пользовательском интерфейсе Studio. Дополнительные способы получения 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 online

    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"
      

    Если сбой HTTPs curl (например, время ожидания), но http работает, проверка, что сертификат действителен.

    Если это не удается разрешить запись A, проверьте, работает ли разрешение из Azure DNS(168.63.129.16).

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

    Если это успешно, можно устранить неполадки условного пересылки для приватного канала на пользовательском 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> 
    

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

Устранение неполадок сервера вывода

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

Основные этапы

Ниже приведены основные действия по устранению неполадок.

  1. Сбор сведений о версии для среды Python.
  2. Убедитесь, что версия пакета python azureml-inference-server-http, указанная в файле среды, соответствует версии HTTP-сервера для вывода AzureML, отображаемой в журнале запуска. Иногда сопоставитель зависимостей pip приводит к непредвиденным версиям установленных пакетов.
  3. Если вы указываете Flask (и его зависимости) в вашей среде, удалите их. Зависимости включают Flask, , Jinja2, itsdangerous, Werkzeugи MarkupSafeclick. Flask отображается в качестве зависимости в пакете сервера, и лучше всего позволить серверу установить его. Таким образом, когда сервер поддерживает новые версии Flask, вы автоматически получите их.

Версия сервера

Пакет azureml-inference-server-http сервера публикуется в PyPI. Наш журнал изменений и все предыдущие версии можно найти на странице PyPI. Обновите до последней версии, если вы используете более раннюю версию.

  • 0.4.x: версия, связанная с обучающими изображениями ≤ 20220601 и в azureml-defaults>=1.34,<=1.43. 0.4.13 является последней стабильной версией. Если вы используете сервер до версии 0.4.11, могут возникнуть проблемы с зависимостью Flask, например не удается импортировать имя Markup из 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
  • схема вывода

Если вы указали 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 среды.

Часто задаваемые вопросы

1. При запуске сервера возникла следующая ошибка:


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.

  • Если вы не используете этот пакет в образе Docker AzureML, используйте последнюю версию azureml-inference-server-http или azureml-defaults.

  • Если вы используете этот пакет с образом Docker AzureML, убедитесь, что вы используете образ, созданный в июле 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, Materializaton Build:20220708.v2
    2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
    2022-08-22T17:05:02,190557998+00:00 | gunicorn/run | 
    

    Дата сборки образа отображается после фразы "Сборка материализации". В приведенном выше примере это 20220708 или 8 июля 2022 г. Этот образ совместим с Flask 2. Если в журнале контейнеров не отображаются эти сведения, значит образ устарел и должен быть обновлен. Если вы используете образ CUDA и не можете найти более новый образ, проверка, если образ не рекомендуется использовать в AzureML-Containers. Если это так, вы сможете найти замены.

  • Если вы используете сервер с веб-конечной точкой, вы также можете найти журналы в разделе "Журналы развертывания" на странице веб-конечной точки в Студия машинного обучения Azure. Если вы развертываете пакет SDK версии 1 и не указываете образ в конфигурации развертывания явным образом, по умолчанию используется версия openmpi4.1.0-ubuntu20.04, которая соответствует локальному набору инструментов пакета SDK и может не быть последней версией образа. Например, пакет SDK 1.43 по умолчанию будет использовать openmpi4.1.0-ubuntu20.04:20220616, что несовместимо. Убедитесь, что для развертывания используется последняя версия пакета SDK.

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

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

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

Более старые версии (<= 0.4.10) сервера не закрепляли зависимость Flask к совместимым версиям. Эта проблема исправлена в последней версии сервера.

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