Развертывание конечной точки в Сети для вывода в режиме реального времени

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

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

Подключенные конечные точки

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

• У вас есть требования к низкой задержке.
• Модель может ответить на запрос относительно коротким временем.
• Входные данные модели соответствуют полезным данным HTTP запроса.
• Необходимо увеличить число запросов.

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

• Имя конечной точки. Это имя должно быть уникальным в регионе Azure. Другие требования к именованию см. в Машинное обучение Azure сетевых конечных точек и пакетных конечных точек.
• Режим проверки подлинности. Вы можете выбрать режим проверки подлинности на основе ключей, Машинное обучение Azure режим проверки подлинности на основе маркеров или проверку подлинности на основе маркера Microsoft Entra для конечной точки. Дополнительные сведения о проверке подлинности см. в статье "Проверка подлинности клиентов для сетевых конечных точек".

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

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

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

Управляемые сетевые конечные точки и Экземпляры контейнеров Azure или Служба Azure Kubernetes (AKS) версии 1

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

Атрибуты	Управляемые сетевые конечные точки (версия 2)	Экземпляры контейнеров или AKS (v1)
Безопасность сети и изоляция	Простой входящий и исходящий элемент управления с быстрым переключением	Виртуальная сеть не поддерживается или требует сложной настройки вручную
Управляемая служба	• Полностью управляемая подготовка вычислительных ресурсов и масштабирование • Конфигурация сети для предотвращения кражи данных • Обновление ОС узла, управляемое развертывание обновлений на месте	• Масштабирование ограничено • Пользователь должен управлять конфигурацией сети или обновлением
Концепция конечной точки и развертывания	Различие между конечной точкой и развертыванием позволяет выполнять сложные сценарии, такие как безопасный развертывание моделей	Нет концепции конечной точки
Диагностика и мониторинг	• Отладка локальной конечной точки возможна с помощью Docker и Visual Studio Code • Расширенные метрики и анализ журналов с помощью диаграммы или запроса для сравнения между развертываниями • Разбивка затрат на уровень развертывания	Нет простой локальной отладки
Масштабируемость	Эластичное и автоматическое масштабирование (не привязанное к размеру кластера по умолчанию)	• Экземпляры контейнеров не масштабируется • AKS версии 1 поддерживает только масштабирование в кластере и требует настройки масштабируемости
Готовность к работе в масштабах предприятия	Приватный канал, управляемые клиентом ключи, идентификатор Microsoft Entra, управление квотами, интеграция выставления счетов, соглашение об уровне обслуживания (SLA)	Не поддерживается
Расширенные возможности машинного обучения	• Сбор данных модели • Мониторинг модели • Модель чемпиона-претендента, безопасное развертывание, зеркальное отображение трафика • Расширяемость ответственного искусственного интеллекта	Не поддерживается

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

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

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

• Автоматическое управление инфраструктурой

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

• Мониторинг и журналы

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

  

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

  

  Примечание.

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

  Если вы используете виртуальную сеть Машинное обучение Azure для защиты исходящего трафика из управляемой сетевой конечной точки, плата взимается за частный канал Azure и полное доменное имя (FQDN), используемые управляемыми виртуальными сетями. Дополнительные сведения см. в разделе "Цены на управляемую виртуальную сеть".

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

	Управляемые сетевые конечные точки	Сетевые конечные точки Kubernetes (AKS версии 2)
Рекомендуемые пользователи	Пользователи, которым требуется развертывание управляемой модели и расширенный интерфейс MLOps	Пользователи, которые предпочитают Kubernetes и могут сами реализовать требования к инфраструктуре
Подготовка узлов	Подготовка управляемых вычислений, обновление, удаление	Ответственность пользователей
Обслуживание узлов	Обновления образа операционной системы управляемого узла и защита системы безопасности	Ответственность пользователей
Размер кластера (масштабирование)	Управляемые вручную и автомасштабирование , поддерживающие дополнительную подготовку узлов	Ручное и автомасштабирование, поддерживающая масштабирование количества реплик в фиксированных границах кластера
Тип вычислений	Управление службой	Управляемый клиентом кластер Kubernetes
Управляемое удостоверение	Поддерживается	Поддерживается
Виртуальная сеть	Поддерживается с помощью изоляция управляемой сети	Ответственность пользователей
Встроенный мониторинг и ведение журнала	Azure Monitor и Log Analytics, включая ключевые метрики и таблицы журналов для конечных точек и развертываний	Ответственность пользователей
Ведение журнала с помощью Application Insights (устаревшая версия)	Поддерживается	Поддерживается
Представление затрат	Подробные сведения о уровне конечной точки и развертывания	Уровень кластера
Затраты, применяемые к	Виртуальные машины ( виртуальные машины), назначенные развертыванию	Виртуальные машины, назначенные кластеру
Зеркальный трафик	Поддерживается	Не поддерживается
Развертывание без кода	Поддерживает модели MLflow и Triton	Поддерживает модели MLflow и Triton

Сетевые развертывания

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

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

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

• Файлы модели или имя и версия модели, уже зарегистрированной в рабочей области.

• Код скрипта оценки, который выполняет модель в заданном входном запросе.

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

• Среда для запуска модели. Среда может быть образом Docker с зависимостями Conda или Dockerfile.

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

Сведения о развертывании сетевых конечных точек с помощью Azure CLI, пакета SDK для Python, Студия машинного обучения Azure или шаблона ARM см. в статье "Развертывание модели машинного обучения с помощью веб-конечной точки".

Ключевые атрибуты развертывания

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

Атрибут	Описание
Имя.	Имя развертывания.
Имя конечной точки	Имя конечной точки для создания развертывания.
Модель	Модель, которая будет использоваться для развертывания. Это значение может быть ссылкой на существующую модель с управлением версиями в рабочей области или спецификацией встроенной модели. Дополнительные сведения о том, как отслеживать и указывать путь к модели, см. в разделе "Указание модели для развертывания для использования в сети".
Путь к коду	Путь к каталогу в локальной среде разработки, содержащей весь исходный код Python для оценки модели. Вы можете использовать вложенные каталоги и пакеты.
Scoring script (Скрипт оценки)	Относительный путь к файлу оценки в каталоге исходного кода. Этот код Python должен содержать функции init() и run(). Функция init() вызывается после создания или обновления модели, например для кэширования модели в памяти. Функция run() вызывается при каждом вызове конечной точки для фактического выполнения оценки и прогнозирования.
Среда	Среда для размещения модели и кода. Это значение может быть ссылкой на существующую среду с управлением версиями в рабочей области или спецификацией встроенной среды.
Тип экземпляра	Размер виртуальной машины, используемый для развертывания. Список поддерживаемых размеров см. в списке SKU управляемых сетевых конечных точек.
Число экземпляров	Число экземпляров, которые будут использоваться для развертывания. Это значение должно быть основано на предполагаемой рабочей нагрузке. Для обеспечения высокой доступности задайте значение по крайней мере 3. Система резервирует дополнительные 20 % для выполнения обновлений. Дополнительные сведения см. в статье о выделении квот виртуальной машины для развертываний.

Заметки о развертывании в Сети

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

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

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

Выделение квот виртуальной машины для развертывания

Для управляемых сетевых конечных точек Машинное обучение Azure резервирует 20 % вычислительных ресурсов для выполнения обновлений на некоторых номерах SKU виртуальных машин. Если вы запрашиваете определенное количество экземпляров для этих SKU виртуальных машин в развертывании, необходимо иметь квоту, чтобы ceil(1.2 * number of instances requested for deployment) * number of cores for the VM SKU избежать возникновения ошибки. Например, если вы запрашиваете 10 экземпляров виртуальной машины Standard_DS3_v2 (которая поставляется с четырьмя ядрами) в развертывании, у вас должна быть квота на 48 ядер () (12 instances * 4 coresдоступно). Эта дополнительная квота зарезервирована для операций, инициируемых системой, таких как обновления ОС и восстановление виртуальной машины, и она не будет стоить, если такие операции не выполняются.

Существуют определенные номера SKU виртуальных машин, исключенные из дополнительного резервирования квот. Чтобы просмотреть полный список, ознакомьтесь со списком SKU управляемых конечных точек в Интернете. Чтобы просмотреть увеличение квоты на использование и запрос, ознакомьтесь с разделом "Просмотр использования и квот" в портал Azure. Чтобы просмотреть затраты на запуск управляемой сетевой конечной точки, см. статью " Просмотр затрат на управляемую конечную точку в Сети".

Общий пул квот

Машинное обучение Azure предоставляет общий пул квот, из которого пользователи в различных регионах могут получить доступ к квоте для выполнения тестирования в течение ограниченного времени в зависимости от доступности. При использовании студии для развертывания моделей Llama-2, Phi, Nemotron, Mistral, Dolly и DeciLM моделей из каталога моделей в управляемую конечную точку в сети Машинное обучение Azure позволяет получить доступ к общему пулу квот в течение короткого времени, чтобы вы могли выполнять тестирование. Дополнительные сведения о общем пуле квот см. в разделе Машинное обучение Azure общей квоты.

Чтобы развернуть модели Llama-2, Phi, Nemotron, Mistral, Dolly и Deci-DeciLM из каталога моделей с помощью общей квоты, необходимо иметь подписку Соглашение Enterprise. Дополнительные сведения об использовании общей квоты для развертывания конечных точек в Сети см. в статье "Развертывание базовых моделей с помощью студии".

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

Развертывание для кодировщиков и некодировщиков

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

• Развертывание без кода обеспечивает вывод стандартных платформ, таких как scikit-learn, TensorFlow, PyTorch и Open Neural Network Exchange (ONNX) через MLflow и Triton.
• Развертывание с низким кодом позволяет предоставлять минимальный код вместе с моделью машинного обучения для развертывания.
• Развертывание BYOC позволяет использовать практически любые контейнеры для запуска конечной точки в Сети. Для управления конвейерами MLOps можно использовать все функции платформы Машинное обучение Azure, такие как автомасштабирование, GitOps, отладка и безопасный развертывание.

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

	Нет кода	Низкий код	BYOC
Сводка	Использует вывод из коробки для популярных платформ, таких как scikit-learn, TensorFlow, PyTorch и ONNX, через MLflow и Triton. Дополнительные сведения см. в статье "Развертывание моделей MLflow в сетевых конечных точках".	Использует защищенные, общедоступные курированные образы для популярных платформ с обновлениями каждые две недели для решения уязвимостей. Вы предоставляете скрипт оценки и (или) зависимости Python. Дополнительные сведения см. в разделе Машинное обучение Azure Курированные среды.	Вы предоставляете полный стек с помощью Машинное обучение Azure поддержки пользовательских образов. Дополнительные сведения см. в статье "Использование пользовательского контейнера для развертывания модели в сети".
Настраиваемый базовый образ	Нет. Курированные среды предоставляют базовый образ для простого развертывания.	Вы можете использовать курируемый образ или настроенный образ.	Доведите доступное расположение образа контейнера, например docker.io, реестр контейнеров или Реестр артефактов Microsoft, или Dockerfile, который можно создать или отправить с помощью реестра контейнеров для контейнера.
Пользовательские зависимости	Нет. Курированные среды предоставляют зависимости для простого развертывания.	Добавьте среду Машинное обучение Azure, в которой выполняется модель, образ Docker с зависимостями Conda или dockerfile.	Пользовательские зависимости включены в образ контейнера.
Настраиваемый код	Нет. Скрипт оценки создается автоматически для простого развертывания.	Доведите скрипт оценки.	Скрипт оценки включен в образ контейнера.

Примечание.

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

Отладка конечной точки в Сети

По возможности выполните тестирование конечной точки локально, чтобы проверить и отладить код и конфигурацию перед развертыванием в Azure. Пакет SDK Azure CLI и Python поддерживают локальные конечные точки и развертывания, а шаблоны СТУДИЯ МАШИННОГО ОБУЧЕНИЯ AZURE и ARM не поддерживают локальные конечные точки или развертывания.

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

• Локальная отладка с помощью HTTP-сервера вывода Машинное обучение Azure
• Локальная отладка с помощью локальной конечной точки
• Локальная отладка с помощью локальной конечной точки и Visual Studio Code
• Отладка с помощью журналов контейнеров

Локальная отладка с помощью HTTP-сервера вывода Машинное обучение Azure

Скрипт оценки можно отлаживать локально с помощью http-сервера вывода Машинное обучение Azure. HTTP-сервер — это пакет Python, который предоставляет функцию оценки как конечную точку HTTP и упаковывает код сервера Flask и зависимости в один пакет.

Машинное обучение Azure включает HTTP-сервер в предварительно созданные образы Docker для вывода, используемого для развертывания модели. С помощью пакета можно развернуть модель локально для рабочей среды, а также легко проверить скрипт оценки записи в локальной среде разработки. Если с скриптом оценки возникла проблема, сервер возвращает ошибку и расположение, в котором произошла ошибка. Вы также можете использовать Visual Studio Code для отладки с помощью http-сервера вывода Машинное обучение Azure.

Совет

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

Дополнительные сведения об отладке с помощью HTTP-сервера см. в скрипте оценки отладки с помощью http-сервера вывода Машинное обучение Azure.

Локальная отладка с помощью локальной конечной точки

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

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

Совет

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

Локальная отладка обычно включает в себя следующие действия:

• Сначала убедитесь, что локальное развертывание выполнено успешно.
• Затем вызовите локальную конечную точку для вывода.
• Наконец, просмотрите выходные журналы для invoke операции.

Локальные конечные точки имеют следующие ограничения:

• Нет поддержки правил трафика, проверки подлинности или параметров пробы.

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

• Поддержка файлов локальной модели и среды только с локальным файлом conda.

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

  • Чтобы протестировать зарегистрированные среды, проверьте контекст среды в Студия машинного обучения Azure и подготовьте локальный файл conda для использования.

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

Локальная отладка с помощью локальной конечной точки и Visual Studio Code (предварительная версия)

Внимание

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

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

Как и при локальной отладке, необходимо установить и запустить подсистему Docker, а затем развернуть модель в локальной среде Docker. После локального развертывания Машинное обучение Azure локальные конечные точки используют контейнеры разработки Docker и Visual Studio Code (контейнеры разработки) для сборки и настройки локальной среды отладки.

С помощью контейнеров разработки можно использовать такие функции Visual Studio Code, как интерактивная отладка из контейнера Docker. Дополнительные сведения об интерактивной отладке конечных точек в Visual Studio Code см. в статье "Отладка сетевых конечных точек локально в Visual Studio Code".

Отладка с помощью журналов контейнеров

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

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

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

Маршрутизация трафика и зеркальное отображение в сети развертываний

Одна конечная точка в Сети может иметь несколько развертываний. Так как конечная точка получает входящие запросы на трафик, она может направлять проценты трафика в каждое развертывание, как и в собственной стратегии развертывания сине-зеленого цвета. Конечная точка также может зеркально или копировать трафик из одного развертывания в другое, называемый зеркальным отображением трафика или тени.

Маршрутизация трафика для развертывания синим и зеленым цветом

Сине-зеленое развертывание — это стратегия развертывания, которая позволяет развернуть новое зеленое развертывание для небольшого подмножества пользователей или запросов, прежде чем развертывать его полностью. Конечная точка может реализовать балансировку нагрузки, чтобы выделить определенные проценты трафика для каждого развертывания, при этом общее выделение во всех развертываниях составляет до 100 %.

Совет

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

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

Предыдущие маршруты распределения трафика 10% трафика к зеленому развертыванию и 90% трафика в синее развертывание, как показано на следующем рисунке.

Зеркальное отображение трафика в сетевых развертываниях

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

Например, можно реализовать сине-зеленое развертывание, в котором 100% трафика направляется на синий и 10% зеркально отражается в зеленом развертывании. Результаты зеркального трафика в зеленом развертывании не возвращаются клиентам, но метрики и журналы записываются.

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

Дополнительные возможности веб-конечной точки

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

Проверка подлинности и шифрование

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

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

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

Дополнительные сведения см. в разделе "Автомасштабирование сетевых конечных точек" в Машинное обучение Azure.

Управляемая сетевая изоляция

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

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

Мониторинг конечных точек и развертываний в Сети

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

Внедрение секретов в сетевых развертываниях (предварительная версия)

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

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

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

• Развертывание и оценка модели машинного обучения с помощью сетевой конечной точки
• Конечные точки пакетной службы
• Защита управляемых конечных точек в Сети с помощью сетевой изоляции
• Развертывание моделей с помощью REST
• Мониторинг подключенных конечных точек
• Просмотр затрат на управляемую подключенную конечную точку Машинного обучения Azure
• Управление квотами и ограничениями для ресурсов с помощью Машинное обучение Azure