Что такое конечные точки Машинного обучения Azure?

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

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

В этой статье раскрываются следующие темы:

  • Конечные точки
  • Развернутые приложения
  • Управляемые сетевые конечные точки
  • Сетевые конечные точки Kubernetes
  • Конечные точки пакетного вывода

Что такое конечные точки и развертывания?

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

Конечная точка — это конечная точка HTTPS, которую клиенты могут вызывать для получения результатов вывода (оценки) обученной модели. Консоль предоставляет следующие возможности:

  • Проверка подлинности на основе "ключа и маркера"
  • Завершение SSL-запросов
  • Стабильный URI оценки (endpoint-name.region.inference.ml.azure.com)

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

Одна конечная точка может содержать несколько развертываний. Конечные точки и развертывания — это независимые ресурсы ARM, которые отображаются на портале Azure.

Машинное обучение Azure использует концепцию конечных точек и развертываний в конечных точках различных типов: сетевых и пакетных.

Различные интерфейсы разработчика

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

  • Azure CLI
  • Azure Resource Manager/REST API
  • Веб-портал Студии машинного обучения Azure
  • Портал Azure (ИТ-администратор)
  • Поддержка конвейеров CI/CD MLOps с использованием интерфейса Azure CLI и интерфейсов REST/ARM

Что такое сетевые конечные точки

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

На следующей схеме показана сетевая конечная точка с двумя развертываниями: "синий" и "зеленый". В синем развертывании используются виртуальные машины с номером SKU ЦП и выполняется версия 1 модели. В зеленом развертывании используются виртуальные машины с номером SKU GPU и выполняется версия 2 модели. Конечная точка настроена на маршрутизацию 90% входящего трафика к синему развертыванию, а зеленое получает оставшиеся 10%.

Diagram showing an endpoint splitting traffic to two deployments.

Требования к сетевому развертыванию

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

  • Файлы модели (или указать зарегистрированную модель в рабочей области)
  • Скрипт оценки (код, необходимый для выполнения оценки или вывода)
  • Среда (образ Docker с зависимостями Conda или Dockerfile)
  • Вычислительный экземпляр и параметры масштабирования

Узнайте, как развертывать сетевые конечные точки с помощью интерфейса командной строки (CLI) и веб-портала студии.

Тестирование и развертывание локально для ускорения отладки

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

Собственное "сине-зеленое" развертывание

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

Распределение трафика можно использовать для безопасного развертывания по "сине-зеленой" стратегии путем балансировки запросов между разными экземплярами.

Совет

Запрос может обходить настроенную балансировку нагрузки трафика, включая заголовок HTTP azureml-model-deployment. Задайте в качестве значения заголовка имя развертывания, к которому должен маршрутизироваться запрос.

Screenshot showing slider interface to set traffic allocation between deployments.

Diagram showing an endpoint splitting traffic to two deployments.

Трафик к одному развертыванию можно также зеркально отобразить (копировать) в другом развертывании. Зеркальное отображение полезно, если требуется проверить, например, задержку ответа или состояния ошибки, не затрагивая динамические клиенты. К примеру, это может быть сине-зеленое развертывание, где 100 % трафика направляется в синее развертывание, а 10 % зеркально отображается в зеленом развертывании. При зеркальном отображении результаты трафика в зеленом развертывании не возвращаются клиентам, но метрики и журналы собираются. Функция зеркального отображения трафика предоставляется в предварительной версии.

Diagram showing an endpoint mirroring traffic to a deployment.

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

Интеграция с Application Insights

Все сетевые конечные точки интегрируются с Application Insights для мониторинга соглашений об уровне обслуживания и диагностики проблем.

Однако управляемые сетевые конечные точки также включают встроенную интеграцию с журналами и метриками Azure.

Безопасность

  • Проверка подлинности: ключ и маркеры Машинного обучения Azure
  • Управляемое удостоверение: назначенное пользователем и назначенное системой
  • SSL по умолчанию для вызова конечной точки

Автомасштабирование

Благодаря автомасштабированию автоматически запускается именно тот объем ресурсов, который нужен для обработки нагрузки в вашем приложении. Управляемые конечные точки поддерживают автоматическое масштабирование через интеграцию с функцией автомасштабирования Azure Monitor. Можно настроить масштабирование на основе метрик (например, загрузка ЦП >70%), масштабирование на основе расписания (например, правила масштабирования для пиковых рабочих часов) или их сочетание.

Screenshot showing that autoscale flexibly provides between min and max instances, depending on rules.

Отладка в Visual Studio Code

Visual Studio Code позволяет интерактивно отлаживать конечные точки.

Screenshot of endpoint debugging in VSCode.

Поддержка частных конечных точек (предварительная версия)

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

Важно!

Эта функция сейчас доступна в виде общедоступной предварительной версии. Эта предварительная версия предоставляется без соглашения об уровне обслуживания. Ее не следует использовать для производственных рабочих нагрузок. Некоторые функции могут не поддерживаться или их возможности могут быть ограничены. Дополнительные сведения см. в статье Дополнительные условия использования предварительных выпусков Microsoft Azure.

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

Дополнительные сведения см. в статье Защита сетевых конечных точек.

Сравнение управляемых сетевых конечных точек с сетевыми конечными точками Kubernetes

Существует два типа сетевых конечных точек: управляемые и Kubernetes.

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

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

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

Управляемые сетевые конечные точки Сетевые конечные точки Kubernetes
Рекомендуемые пользователи Пользователи, которым требуется развертывание управляемой модели и расширенный интерфейс MLOps Пользователи, которые предпочитают Kubernetes и могут сами реализовать требования к инфраструктуре
Управление инфраструктурой Управляемая подготовка вычислений, масштабирование, обновление образа ОС узла и усиление безопасности Ответственность пользователей
Тип вычислительного ресурса Управляемый (AmlCompute) Кластер Kubernetes (Kubernetes)
Готовые средства мониторинга Мониторинг Azure
(включает основные метрики, такие как задержка и пропускная способность).
Поддерживается
Готовые средства ведения журнала Журналы Azure и Log Analytics на уровне конечной точки Не поддерживается
Application Insights Поддерживается Поддерживается
Управляемое удостоверение Поддерживается Поддерживается
Виртуальная сеть Поддерживается (предварительная версия) Поддерживается
Просмотр затрат Уровень конечной точки и развертывания Уровень кластера
Зеркальный трафик Поддерживается Не поддерживается

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

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

  • Управляемая инфраструктура

    • Автоматическая подготовка вычислительного ресурса и размещение модели (нужно просто указать тип виртуальной машины и параметры масштабирования)
    • Автоматическое выполнение обновлений и исправлений для базового изображения ОС узла
    • Автоматическое восстановление узла при сбое системы
  • Мониторинг и журналы

    • Мониторинг доступности, производительности и Соглашения об уровне обслуживания модели за счет собственной интеграции с Azure Monitor.
    • Отладка развертываний с помощью журналов и интеграции платформенной функциональности с Azure Log Analytics.

    Screenshot showing Azure Monitor graph of endpoint latency.

  • Просмотр затрат

    Screenshot cost chart of an endpoint and deployment.

    Примечание

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

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

Пошаговые инструкции приведены в статье Развертывание сетевых конечных точек.

Что такое пакетные конечные точки?

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

Diagram showing that a single batch endpoint may route requests to multiple deployments, one of which is the default.

Требования к пакетному развертыванию

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

  • Файлы модели (или указать зарегистрированную модель в рабочей области).
  • Вычисления
  • Скрипт оценки — код, необходимый для выполнения оценки или вывода.
  • Среда (образ Docker с зависимостями Conda)

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

Узнайте, как развертывать и использовать пакетные конечные точки с Azure CLI и веб-портал студии

Управление стоимостью за счет автомасштабирования вычислений

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

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

Гибкие источники данных и хранилище

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

  • Облачные данные: путь к зарегистрированному хранилищу данных Машинного обучения Azure, ссылка на зарегистрированный ресурс данных Машинного обучения Azure версии 2 или общедоступный URI. Дополнительные сведения см. в статье о подключении к данным с помощью Студии машинного обучения Azure.
  • Локально хранимые данные: автоматически отправляются в зарегистрированное хранилище данных Машинного обучения Azure и передаются в пакетную конечную точку.

Примечание

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

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

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

Безопасность

  • Проверка подлинности: маркеры Azure Active Directory
  • SSL: включен по умолчанию для вызова конечной точки.
  • Поддержка виртуальной сети: пакетные конечные точки поддерживают защиту входящего трафика. Пакетная конечная точка с защитой входящего трафика будет принимать запросы оценки только от узлов в виртуальной сети, но не из общедоступного Интернета. Пакетная конечная точка, созданная в рабочей области с поддержкой приватного канала, будет иметь защиту входящего трафика. Сведения о создании рабочей области с поддержкой приватного канала см. в статье Создание защищенной рабочей области.

Дальнейшие шаги