Обновление до версии 2
интерфейсы REST API версии 2 Машинное обучение Azure, расширение Azure CLI и пакет SDK Для Python представляют согласованность и набор новых функций для ускорения жизненного цикла машинного обучения. В этой статье представлен обзор обновления до версии 2 с рекомендациями, которые помогут вам выбрать версию 1, версию 2 или оба варианта.
Необходимые компоненты
- Общее знакомство с Машинное обучение Azure и пакетом SDK для Python версии 1.
- Понимание того, что такое версия 2
Стоит ли мне использовать версию 2?
Если вы запускаете новый проект машинного обучения или рабочий процесс, следует использовать версию 2. Если вы хотите использовать новые функции, предлагаемые в версии 2, следует использовать версию 2. Доступны следующие функции:
- Управляемое вывод
- Повторно используемые компоненты в конвейерах
- Улучшено планирование конвейеров
- Панель мониторинга ответственного применения ИИ
- Реестр ресурсов
Новый проект версии 2 может повторно использовать существующие ресурсы версии 1, такие как рабочие области и вычислительные ресурсы, а также существующие ресурсы, такие как модели и среды, созданные с помощью версии 1.
Некоторые пробелы функций в версии 2 включают:
- Поддержка Spark в заданиях — это сейчас в предварительной версии 2.
- публикацию заданий (конвейеры в версии 1) в качестве конечных точек; Однако можно запланировать конвейеры без публикации.
- поддержку хранилищ данных SQL / баз данных;
- Возможность использования классических предварительно созданных компонентов в конструкторе с версией 2.
Затем вы должны убедиться, что возможности, которые вам понадобятся в версии 2, соответствуют требованиям вашей организации, например являются общедоступными.
Внимание
Новые функции в Машинное обучение Azure будут запущены только в версии 2.
Какой API версии 2 мне нужно использовать?
В интерфейсах версии 2 доступны интерфейсы REST API, CLI и python SDK. Интерфейс, который вам следует использовать, зависит от вашего сценария и предпочтений.
API | Примечания. |
---|---|
REST | Наименьшее количество зависимостей и издержек. Используется для создания приложений на Машинное обучение Azure в качестве платформы, непосредственно на языках программирования без предоставленного пакета SDK или для каждого личного предпочтения. |
CLI | Рекомендуется для автоматизации с помощью CI/CD или в соответствии с личными предпочтениями. Позволяет быстро выполнять итерацию с файлами YAML и простым разделением между Машинное обучение Azure и кодом модели машинного обучения. |
Пакет SDK для Python | Рекомендуется для сложных сценариев (например, при программном создании больших заданий конвейера) или в соответствии с личными предпочтениями. Позволяет быстро выполнять итерации с файлами YAML или разрабатывать исключительно на Python. |
Сопоставление пакета SDK Python версии 1 с версией 2
Ознакомьтесь с каждой из следующих статей по сопоставлению кода для пакета SDK версии 1 и версии 2.
Ресурсы и ресурсы | Статья |
---|---|
Рабочая область | Управление рабочей областью в пакете SDK версии 1 и пакете SDK версии 2 |
Хранилище данных | Управление хранилищем данных в пакете SDK версии 1 и пакете SDK версии 2 |
Data | Ресурсы данных в пакете SDK версии 1 и версии 2 |
Службы вычислений | Управление вычислениями в пакете SDK версии 1 и пакете SDK версии 2 |
Обучение | Выполнить сценарий |
Обучение | Локальные запуски |
Обучение | Настройка гиперпараметров |
Обучение | Параллельное выполнение |
Обучение | Конвейеры |
Обучение | AutoML |
Модели | Управление моделями в пакете SDK версии 1 и пакете SDK версии 2 |
Развертывание | Обновление конечных точек развертывания до пакета SDK версии 2 |
Ресурсы и ресурсы в версии 1 и версии 2
В этом разделе представлен обзор конкретных ресурсов и ресурсов в Машинное обучение Azure. Дополнительные сведения об их использовании в версии 2 см. в статье о концепции каждой сущности.
Рабочая область
Рабочие области не нужно обновлять с помощью версии 2. Вы можете применять одну и ту же рабочую область независимо от того, используете ли вы версию 1 или 2.
При создании рабочих областей с помощью автоматизации рекомендуется обновить код для создания рабочей области до версии 2. Обычно ресурсы Azure управляются с помощью Azure Resource Manager (и Bicep) или аналогичных средств для подготовки ресурсов. Или вы можете использовать CLI (версии 2) и файлы YAML.
Сравнение кода пакета SDK версии 1 и версии 2 см. в разделе "Управление рабочей областью" в пакете SDK версии 1 и пакете SDK версии 2.
Внимание
Если ваша рабочая область использует частную конечную точку, в ней автоматически будет установлен флаг v1_legacy_mode
, предотвращающий использование API версии 2. Дополнительные сведения см. в статье о настройке сетевой изоляции с помощью версии 2.
Подключение (подключение к рабочей области в версии 1)
Подключения к рабочей области версии 1 сохраняются в рабочей области и полностью доступны в версии 2.
Сравнение кода пакета SDK версии 1 и версии 2 см. в разделе "Управление рабочей областью" в пакете SDK версии 1 и пакете SDK версии 2.
Хранилище данных
Типы хранилищ данных хранилища объектов, созданные с помощью версии 1, полностью доступны при использовании в версии 2. Хранилища данных базы данных не поддерживаются; рекомендуемым способом миграции является экспорт в хранилище объектов (обычно это большой двоичный объект Azure).
Сравнение кода пакета SDK версии 1 и версии 2 см. в разделе "Управление хранилищем данных" в пакете SDK версии 1 и пакете SDK версии 2.
Данные (наборы данных в версии 1)
Наборы данных переименовываются в активы данных. Обеспечивается обратная совместимость , что означает, что в версии 2 можно использовать наборы данных версии 1. При использовании набора данных версии 1 в задании версии 2 вы заметите, что они автоматически сопоставляются с типами версии 2 следующим образом:
- V1 FileDataset = папка V2 (
uri_folder
) - V1 TabularDataset = таблица V2 (
mltable
)
Следует отметить, что совместимость пересылки не предоставляется, что означает, что нельзя использовать ресурсы данных версии 2 в версии 1.
В этой статье рассказывается о обработке данных в версии 2. Чтение и запись данных в задании
Сравнение кода пакета SDK версии 1 и версии 2 см. в разделе "Ресурсы данных" в пакете SDK версии 1 и версии 2.
Службы вычислений
Вычисления типа AmlCompute
и ComputeInstance
полностью доступны для использования в версии 2.
Сравнение кода пакета SDK версии 1 и версии 2 см. в разделе "Управление вычислениями" в пакете SDK версии 1 и пакете SDK версии 2.
Задания (эксперименты, запуски, конвейеры в версии 1)
В версии 2 операции типа "эксперименты", "запуски" и "конвейеры" объединяются в задания. Каждое задание имеет тип. Большинство заданий — это задания command
, которые выполняют команду, например python main.py
. То, что выполняется в задании, не зависит от языка программирования, поэтому вы можете запускать скрипты bash
, вызывать интерпретаторы python
, выполнять набор команд curl
или что-либо еще. Другим распространенным типом задания является pipeline
определение дочерних заданий, которые могут иметь связи "ввод/вывод", формируя направленный ациклический граф (DAG).
Сравнение кода ПАКЕТА SDK версии 1 и версии 2 см. в статье
- Выполнить сценарий
- Локальные запуски
- Настройка гиперпараметров
- Параллельное выполнение
- Конвейеры
- AutoML
Автор
С помощью конструктора можно создавать конвейеры с помощью собственных пользовательских компонентов версии 2 и новых предварительно созданных компонентов из реестра. В этом случае в конвейере можно использовать ресурсы данных версии 1 или версии 2.
Конструктор можно продолжать использовать для создания конвейеров с помощью классических предварительно созданных компонентов и типов наборов данных версии 1 (табличный, файл). Нельзя использовать существующие предварительно созданные компоненты конструктора с ресурсом данных версии 2.
Невозможно создать конвейер с помощью существующих классических предварительно созданных компонентов конструктора и пользовательских компонентов версии 2.
Модель
Модели, созданные на основе версии 1, можно использовать в версии 2.
Сравнение кода пакета SDK версии 1 и версии 2 см. в разделе "Управление моделями" в пакете SDK версии 1 и пакете SDK версии 2
Конечная точка и развертывание (конечная точка и веб-служба в версии 1)
С помощью пакета SDK или CLI версии 1 можно развертывать модели в ACI или AKS в виде веб-служб. Существующие развертывания моделей версии 1 и веб-службы будут продолжать работать так же, как они есть, но использование пакета SDK/CLI версии 1 для развертывания моделей в ACI или AKS в качестве веб-служб теперь считается устаревшим. Для новых развертываний моделей рекомендуется обновить до версии 2. В версии 2 мы предлагаем управляемые конечные точки или конечные точки Kubernetes. В следующей таблице собраны наши рекомендации.
Тип конечной точки в версии 2 | Исходная версия | Примечания. |
---|---|---|
Local | ACI | Быстрая локальная проверка развертывания модели; не для рабочей среды. |
Управляемая сетевая конечная точка | ACI, AKS | Инфраструктура развертывания управляемых моделей корпоративного уровня с реагированием практически в реальном времени и массовым масштабированием для рабочей среды. |
Управляемая конечная точка пакета | ParallelRunStep в конвейере для пакетной оценки | Инфраструктура развертывания управляемых моделей корпоративного уровня с массовой параллельной пакетной обработкой для рабочей среды. |
Служба Azure Kubernetes (AKS) | ACI, AKS | Управляйте собственным кластером (кластерами) AKS для развертывания модели, обеспечивая гибкость и полный контроль за счет накладных расходов на ИТ. |
Kubernetes с поддержкой Azure Arc | Н/П | Управляйте собственным кластером (кластерами) Kubernetes в других облаках или в локальной среде, обеспечивая гибкость и полный контроль за счет накладных расходов на ИТ. |
Сравнение кода пакета SDK версии 1 и версии 2 см. в статье об обновлении конечных точек развертывания до пакета SDK версии 2. Инструкции по миграции из существующих веб-служб ACI в управляемые сетевые конечные точки см . в нашей статье по обновлению и блоге.
Среда
Окружения, созданные на основе версии 1, можно использовать в версии 2. В версии 2 окружения имеют новые возможности, такие как создание из локального контекста Docker.
управление секретами;
Управление секретами Key Vault значительно отличается в версии 2 по сравнению с версией 1. Методы пакета SDK версии 1 set_secret версии 1 и get_secret недоступны в версии 2. Вместо этого следует использовать прямой доступ с помощью клиентских библиотек Key Vault. При доступе к секретам из скрипта обучения можно использовать управляемое удостоверение вычислительных ресурсов или удостоверение.
Дополнительные сведения о Key Vault см. в разделе "Использование секретов учетных данных проверки подлинности" в заданиях обучения Машинное обучение Azure.
Сценарии на протяжении всего жизненного цикла машинного обучения
Существует несколько сценариев, распространенных в жизненном цикле машинного обучения с помощью Машинное обучение Azure. Мы рассмотрим несколько общих рекомендаций по обновлению до версии 2.
Настройка Azure
Azure рекомендует использовать для создания ресурсов шаблоны Azure Resource Manager (часто через Bicep, поскольку это упрощает работу). То же самое является хорошим подходом для создания Машинное обучение Azure ресурсов, а также.
Если ваша команда использует только Машинное обучение Azure, вы можете рассмотреть возможность подготовки рабочей области и других ресурсов с помощью файлов YAML и CLI.
Создание прототипов моделей
Мы рекомендуем использовать для создания прототипов моделей версию 2. Вы можете использовать интерфейс командной строки для интерактивного использования Машинное обучение Azure, а код обучения модели — Python или любой другой язык программирования. Кроме того, вы можете использовать полный стек с python исключительно с помощью пакета SDK Машинное обучение Azure или смешанного подхода с Машинное обучение Azure пакета SDK для Python и ФАЙЛОВ YAML.
Обучение модели в рабочей среде
Мы рекомендуем использовать для обучения модели в рабочей среде версию 2. Задания консолидируют терминологию и обеспечивают набор согласованности, позволяющий легче переходить от одного типа к другому (например, от command
к sweep
) и удобный для GitOps процесс сериализации заданий в файлы YAML.
В версии 2 вам понадобится отделить код машинного обучения от кода уровня управления. Такое разделение позволяет упростить итерацию, а также упростить переход между локальными и облачными средами. Мы также рекомендуем использовать MLflow для отслеживания и ведения журнала моделей. Дополнительные сведения см. в статье о концепции MLflow.
Развертывание модели в рабочей среде
Мы рекомендуем использовать для развертывания модели в рабочей среде версию 2. Управляемые конечные точки сокращают издержки на ИТ и служат эффективным решением для развертывания и оценки моделей как в режиме онлайн (практически в реальном времени), так и для сценариев пакетной обработки (с массовым параллелизмом).
Развертывания Kubernetes можно выполнять в версии 2 при использовании AKS или Azure Arc, что позволяет реализовать облачные и локальные развертывания Azure, управляемые вашей организацией.
Операции машинного обучения (MLOps)
Рабочий процесс MLOps обычно включает в себя непрерывную поставку и непрерывную интеграцию через внешнее средство. Как правило, в CI/CD используется интерфейс командной строки, хотя вы можете также вызвать Python или напрямую использовать REST.
Акселератор решений для MLOps с версией 2 разрабатывается на https://github.com/Azure/mlops-v2. Его можно использовать в качестве эталонного решения или внедрить для настройки и автоматизации жизненного цикла машинного обучения.
Заметка о GitOps с версией 2
Ключевой парадигмой в версии 2 является сериализация сущностей машинного обучения в виде YAML-файлов для управления версиями git
, что позволяет применять более эффективные подходы GitOps, чем это было возможно в версии 1. Например, вы можете применить политику, согласно которой только субъект-служба, используемый в конвейерах CI/CD, может создавать/обновлять/удалять некоторые или все сущности, гарантируя, что изменения будут проходить через управляемый процесс, такой как запросы на вытягивание с необходимыми рецензентами. Поскольку файлы в системе управления версиями имеют формат YAML, их легко различать и отслеживать изменения с течением времени. Вы и ваша команда могут рассмотреть возможность перехода к этой парадигме при обновлении до версии 2.
Вы можете получить YAML-представление любой сущности с помощью CLI через az ml <entity> show --output yaml
. Обратите внимание, что эти выходные данные будут иметь системные свойства, которые могут быть проигнорированы или удалены.
Следует ли обновить существующий код версии 1 до версии 2
Вы можете повторно использовать существующие ресурсы версии 1 в рабочих процессах версии 2. Например, модель, созданная в версии 1, можно использовать для выполнения управляемого вывода в версии 2.
При необходимости, если вы хотите обновить определенные части существующего кода версии 1 до версии 2, обратитесь к ссылкам сравнения, указанным в этом документе.
Можно ли использовать версии 1 и 2 в комбинации?
Версия 1 и v2 могут совместно существовать в рабочей области. Вы можете повторно использовать существующие ресурсы в рабочих процессах версии 2. Например, модель, созданная в версии 1, можно использовать для выполнения управляемого вывода в версии 2. Такие ресурсы, как рабочая область, вычислительные ресурсы и хранилище данных, работают в версиях 1 и 2, но есть и исключения. Пользователь может вызвать пакет SDK для Python версии 1, чтобы изменить описание рабочей области, а затем снова изменить его с помощью расширения CLI версии 2. Задания (эксперименты, запуски и конвейеры в версии 1) можно отправлять в ту же рабочую область из пакета SDK для Python версии 1 или 2. Рабочая область может иметь конечные точки развертывания модели версий 1 и 2.
Совместное использование кода версии 1 и версии 2
Не рекомендуется использовать пакеты SDK версии 1 и версии 2 в одном коде. Технически можно использовать версии 1 и 2 в одном коде, так как они используют разные пространства имен Azure. Однако существует множество классов с одинаковым именем в этих пространствах имен (например, рабочая область, модель), что может привести к путанице и сделать код удобочитаемостью и отладкой сложной.
Внимание
Если ваша рабочая область использует частную конечную точку, в ней автоматически будет установлен флаг v1_legacy_mode
, предотвращающий использование API версии 2. Дополнительные сведения см. в статье о настройке сетевой изоляции с помощью версии 2.