Развертывание моделей искусственного интеллекта в облаке Azure

Развертывание моделей искусственного интеллекта в облаке Azure

Основываясь на опыте работы над проектами AI (искусственный интеллект) и машинного обучения (машинное обучение) с платформой AML (машинное обучение Azure) с 2018 года, в этой статье мы поделимся точкой зрения (положительные стороны ) по внедрению ваших моделей искусственного интеллекта в производство в облаке Azure с помощью MLOps. Это типичная ситуация, когда первоначальное экспериментирование (метод проб и ошибок) и связанное с ним технико-экономическое обоснование для создания определенной модели сначала проводятся в блокноте (-ах) AML / Jupyter. После того, как некоторые многообещающие результаты были получены, проанализированы и подтверждены с помощью технико-экономического обоснования командой инженеров машинного обучения на местном уровне, группы разработки приложений и DevOps Engineering могут сотрудничать для производственной реализации рабочей нагрузки в масштабе в облаке (и / или край по мере необходимости). При автоматизации CI / CD для конкретной рабочей нагрузки AI / ML существует ряд общих проблем (которые также частично выделены здесь), которые необходимо решить следующим образом:

• Сама автоматизация CI (Continuous Integration) / CD (Continuous Delivery)
• Стратегия / процесс среды (разработка и продвижение моделей и т. Д.) И автоматизация инфраструктуры
• Интеграция данных (переключение с файлов на базы данных / хранилища данных и т. Д.)
• Безопасность (аутентификация, авторизация и т. Д.)
• Производительность (моделирует распределенное обучение, вывод в реальном времени или пакетный вывод и т. Д.)
• Непрерывное совершенствование (переобучение моделей, (пере) маркировка данных, цикл обратной связи и т. Д.)
• Тестируемость
• Наблюдаемость и мониторинг
• и больше …

Платформа

AML (Машинное обучение Azure) - это комплексная платформа машинного обучения Azure с поддержкой MLOps для создания и развертывания моделей в облаке Azure. Дополнительные сведения о машинном обучении Azure (ML как услуга) можно найти здесь, а более подробную информацию об эталонных архитектурах и передовых методах Microsoft AI / ML - здесь. Таксономия платформы машинного обучения Azure показана на следующей диаграмме, как описано здесь:

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

• Учетная запись хранения Azure
• Реестр контейнеров Azure
• Аналитика приложений Azure
• Хранилище ключей Azure

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

• AML Python SDK (описано здесь)
• AML CLI (описывается здесь), который является расширением Azure CLI.
• AML REST API (описано здесь)

AML Python SDK отлично подходит для разработки и автоматизации, AML CLI более удобен для автоматизации Dev (Sec) Ops / MLOps, а AML REST API - это интерфейс более низкого уровня, который обычно не используется в проектах в пользу первых двух подходов. Более подробную информацию о подходах, ориентированных на CLI и Python, можно найти здесь.

Примечательно: с точки зрения безопасности 4 вышеупомянутых ресурса Azure будут связаны с рабочей областью машинного обучения Azure и будут иметь отдельные ключи безопасности. Связанное хранилище ключей Azure - это центральное место, где хранятся ключи безопасности для рабочей области машинного обучения Azure, и в случае, если вам нужно повернуть (изменить) ключи безопасности для учетной записи хранения Azure, реестра контейнеров Azure и Azure Application Insights, существует процедура для этого с использованием AML CLI az ml workspace sync-keys, как описано здесь.

Процесс

Для автоматизации CI / CD для конкретной рабочей нагрузки AI / ML (на основе одной или нескольких моделей или ансамбля (ов) моделей) можно использовать различные конвейеры Dev (Sec) Ops / MLOps, как описано здесь:

Azure DevOps обеспечивает центральную точку для организации всего процесса MLOps на основе нескольких конвейеров. Вот как могут выглядеть разные конвейеры MLOps для проекта в Azure DevOps:

Архитектура

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

На схеме выше разные конвейеры Azure DevOps взаимодействуют с различными элементами платформы машинного обучения Azure:

• Data-Pipeline ‹-› Хранилища данных, наборы данных
• Environment-Pipeline ‹-› Окружающая среда
• Code-Pipeline (CI) ‹-› AML Python SDK (код)
• Training-Pipeline ‹-› Эксперименты, трубопроводы, модели
• Deployment-Pipeline (ACI) ‹-› Конечные точки
• Deployment-Pipeline (AKS), Canary-Deployment-Pipeline (AKS) ‹-› Конечные точки

Примечательно: различные технологии, используемые на схеме, включают, помимо прочего, службы хранилища и вычислений Azure, в частности, Машинное обучение Azure (AML), Azure DevOps, хранилище BLOB-объектов Azure, фабрику данных Azure, контейнер Azure. Реестр, экземпляры контейнеров Azure (ACI), служба Azure Kubernetes (AKS) и т. Д.

Эта архитектура основана на канонической архитектуре MLOps (MLOps в Azure), описанной здесь, и ее дочерней архитектуре, MLOpsPython (MLOps с Azure ML), описанной здесь.

Простой исходный шаблонный конвейер CI / CD YAML для MLOps можно найти внутри самого Azure DevOps, как показано ниже:

YAML для этого базового конвейера универсального шаблона CI / CD выглядит следующим образом:

Примечательно: команда AML CLI az ml folder attach обеспечивает контекстную осведомленность для последующих команд AML CLI в конвейере Azure DevOps. Таким образом, если AML CLI az ml folder attach не задействован, ожидается, что вы явно укажете параметры --workspace-name и --resource-group в соответствующей команде AML CLI, например, az ml model deploy по мере необходимости.

Вывод

Что касается логического вывода, мы рассмотрим пример простой модели Scikit-Learn (для неконтролируемого обучения, кластеризацию с использованием алгоритма kmeans) и ее развертывание в экземплярах контейнеров Azure (ACI) и Azure Kubernetes Services (AKS) с помощью платформы машинного обучения Azure.

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

Точно так же на следующем рисунке показано развертывание в службе Azure Kubernetes (AKS) и то, как полученное развертывание выглядит на портале Azure.

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

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

Файл модели TensorFlow model.pb, файл меток labels.txt, сценарий Python score.py оценки, приложение Python API app.py и Docker Dockerfile с использованием сервера Python flask

Говоря о безопасности конечных точек в реальном времени, при развертывании модели в веб-сервисе традиционным способом параметры аутентификации будут зависеть от цели развертывания. А именно, аутентификацию на основе ключей можно включить при развертывании в ACI, таким образом ваша развернутая конечная точка с точки зрения аутентификации будет напоминать Azure Cognitive Services, к которым можно получить доступ с помощью apiKeys. Для маршрута AKS вы можете использовать аутентификацию на основе токенов или на основе ключей. Также обратите внимание, что новый способ обработки развертываний конечных точек в реальном времени через конечные точки AML станет основным, когда функциональность конечных точек и развертываний AML выйдет из общедоступной предварительной версии. Дополнительную информацию о конечных точках и развертываниях AML можно найти здесь.

Обучение

Что касается обучения, мы рассмотрим пример модели преобразователя HuggingFace NLP с учителем (BERT или DistilBERT) и ее обучение на основе вычислений на базе ЦП и графического процессора, предоставляемых платформой машинного обучения Azure. Более подробную информацию о моделях трансформаторов HuggingFace можно найти здесь и здесь.

Обращает на себя внимание: прежде чем перейти к обучению, мы сделаем небольшое отступление, чтобы выделить способ упаковки моделей трансформатора HuggingFace и то, как это можно использовать во время развертывания (-ий). В частности, как показано ниже, trainer.save_model() создает файлы config.json, pytorch_model.bin и training_args.bin; и tokenizer.save_pretrained() создает остальные 3 файла конфигурации json и файл vocab.txt. Более подробную информацию о назначении этих файлов можно найти здесь. Также для удобства будущих оценок вы можете включить label2id и id2label преобразования прямо в config.json как часть вашего обучающего кода.

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

Постоянное улучшение модели - обычное ожидание в проекте, это означает, что при изменении кода модели нам потребуется переупаковывать этапы конвейера и соответствующим образом переобучать модель. С точки зрения автоматизации это означает, что если конвейер обучения AML опубликован и доступен в конечной точке конвейера обучения AML через URL-адрес, это позволяет переобучать модель по запросу при изменении данных (например, поступают новые помеченные или немаркированные данные) и / или код изменения. С точки зрения обслуживания было бы удобно поддерживать версии конвейера, сохраняя фиксированный URL-адрес конечной точки, вместо того, чтобы повторно публиковать многочисленные конвейеры / конечные точки на разных URL-адресах. Машинное обучение Azure поддерживает версионные конечные точки конвейера обучения AML, как описано здесь и здесь. Ниже мы приводим иллюстрацию того, как превратить опубликованный конвейер в конечную точку конвейера с контролем версий с помощью AML Python SDK в Машинном обучении Azure (обратите внимание, как происходит подчинение между шагами 2 и 3 и как меняются значки):

В соответствии с его определением Swagger (например, для региона EastUS здесь) конечная точка конвейера обучения AML может быть вызвана с помощью идентификатора (динамическое значение, которое генерируется после развертывания конечной точки конвейера обучения AML) или имени (статическое значение, которое обычно известно аванс). Для обеспечения повторяемости в DevOps может быть удобно называть конечную точку конвейера обучения AML по имени, а не по идентификатору, это может упростить работу любых вышестоящих приложений или служб, которым потребуется вызывать конечную точку конвейера обучения AML по запросу:

Обратите внимание: при вызове конечной точки конвейера обучения AML по имени, имя является параметром запроса, который должен быть указан в URL-адресе. Также pipelineVersion может быть предоставлен в качестве параметра запроса. В случае, если pipelineVersion не указан явно, будет принята развернутая по умолчанию pipelineVersion. Другие статические части URL-адреса будут предоставлены как параметры пути, такие как subscriptionId, resourceGroupName и workspaceName.

Для сложных моделей на основе глубокой нейронной сети (DNN) обычно требуется распределенное обучение на основе графического процессора на вычислительном кластере (ах). Эталонная архитектура для распределенного обучения глубоких нейронных сетей в Azure с использованием машинного обучения Azure описана здесь. Более подробную информацию о распределенном обучении GPU можно найти здесь, здесь и здесь. В этом руководстве также освещаются некоторые аспекты структуры (например, Tensorflow или PyTorch) и модели (например, HuggingFace) распределенного обучения. Например, существует более общее руководство по Open Message Passing Interface (MPI), а также более конкретное руководство по моделям преобразователя HuggingFace Варианты распределенного обучения PyTorch, а также подчеркивается, как платформа машинного обучения Azure поддерживает эти параметры и какие переменные среды предоставляет платформа. . В частности, для моделей трансформеров HuggingFace доступны 2 основных варианта распределенного обучения:

• На узел (средство запуска для каждого узла с использованием PyTorch torch.distributed.launchlibrary)
• За процесс (за процесс-пусковую установку)

Платформа машинного обучения Azure упрощает настройку, предоставляя ряд переменных среды, таких как MASTER_ADDR, MASTER_PORT, WORLD_SIZE, NODE_RANK, RANK, LOCAL_RANK в контексте образов контейнеров, на которых выполняется распределенный обучающий код. Как описано здесь и здесь, при использовании параметра Per Process для распределенного обучения моделей преобразователя HuggingFace вы должны явно указать параметр local_rank (который определяет ранг процесса во время распределенного обучения) в объекте класса transformers.TrainingArguments на основе переменной RANKenvironmental . Ниже мы проиллюстрируем, как включить распределенное обучение для модели преобразователя HuggingFace на узел или на процесс с помощью AML Python SDK:

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

• Конвейеры обучения AML в AML Python SDK
• Обучающие конвейеры AML в YAML, как описано здесь

По сути, когда мы используем AML Python SDK для определения кода конвейера обучения AML, у нас будет файл Python (например, pipeline.py), который описывает шаги конвейера, и каждый шаг может быть реализован как отдельный Файл Python (например, train.py) и подключен к конвейеру как PythonScriptStep. Когда мы используем YAML для определения конфигурации конвейера обучения AML, у нас будет файл YAML (например, pipeline.yaml), который описывает шаги конвейера, и каждый шаг по-прежнему может быть реализован как отдельный файл Python и все еще упоминается как PythonScriptStep.

Обратите внимание: при переключении с записной книжки на конвейер обучения по сценарию аутентификация может выполняться с помощью класса AzureCliAuthentication, как показано ниже.

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

Обратите внимание: при запуске конвейера каждый шаг конвейера (и связанный с ним код Python для PythonScriptStep’s) будет упакован и выполнен в отдельном контейнере. Это позволяет выполнять различные шаги для разных целей вычислений, что удобно, когда, например, обучающий код с большей потребностью в ресурсах использует преимущества вычислений на основе графического процессора, в то время как код с меньшим потреблением ресурсов выполняется на основе вычислений на базе процессора.

Одно предостережение, связанное с конвейерами обучения AML в YAML, заключается в том, что существуют только определенные типы шагов, которые в настоящее время поддерживаются в YAML, как описано здесь. Например, для распределенного обучения моделей преобразователей HuggingFace на каждом узле с использованием AML Python SDK для вызова библиотеки PyTorch torch.distributed.launch можно использовать _41 _ (здесь), однако для конвейеров обучения AML в YAML CommandStep в настоящее время не поддерживается. Вот почему для распределенного обучения моделей преобразователей HuggingFace в YAML мы можем использовать опцию Per Process и поддерживаемый PythonScriptStep. Ниже мы вкратце проиллюстрируем, как распределенное обучение по узлам и процессам выглядит изнутри:

Другой нюанс связан с тем, что при предоставлении nodeCount и processCount в распределенной конфигурации (YAML) в YAML-определение конвейера обучения AML похоже, что параметр processCount не принимается во внимание. Дополнительные сведения о том, как этапы конвейера упаковываются и отправляются на выполнение, можно найти в студии машинного обучения Azure, перейдя на связанную страницу эксперимента ›вкладка« Подробности »› См. Раздел всех свойств ›кнопка Raw JSON. Этот JSON содержит раздел runDefinition, в котором представлены настройки конфигурации. Один из способов решить эту проблему - использовать многоузловые вычисления с одним графическим процессором на узел, таким образом вы можете установить PythonScriptStep для распределенного обучения модели преобразователя HuggingFace на процесс, идентичной настройке на каждый узел. Одним из недостатков будет то, что настройка Per Process (~ Per Node), скажем, с 8 узлами с одним графическим процессором на каждом узле займет больше времени для разогрева по сравнению, скажем, с 2 узлами с 4 графическими процессорами на каждом узле ( общее количество графических процессоров будет одинаковым в обоих случаях), в то время как с точки зрения стоимости эти две настройки могут быть одинаковыми.

Примечательно: при настройке распределенного обучения для модели преобразователя HuggingFace с использованием подхода Open MPI (здесь) ("framework": "Python", "communicator": "Mpi") мы получили следующую ошибку: Ошибка инициализации torch.distributed с использованием env: // рандеву: переменная среды RANK ожидается, но не установлена ​​ даже после предоставления local_rankargument в объекте класса ftransformers.TrainingArguments.

В заключение рассмотрим распределенное обучение и конвейеры обучения AML в YAML. В AML CLI (v2) появятся некоторые захватывающие новые улучшения, связанные с заданиями AML в формате YAML, как описано здесь и здесь.

В зависимости от требований проекта может быть удобно инициировать процесс переобучения модели (ей) «изнутри» AML (например, из самого AML или через DevOps от имени личности, имеющей доступ к AML, например, с назначенным Участником или Роли владельца) или извне AML (например, из функции Azure или другого приложения или службы, размещенной в Azure).

Говоря о вызове «изнутри», следующий фрагмент кода показывает, как выполнить конвейер обучения AML из конвейера Azure DevOps (который может выполняться периодически по расписанию):

В этом коде, используя подход AML CLI (v1), мы сначала получаем список опубликованных конвейеров по имени и предполагаем, что вверху этого отфильтрованного списка находится последняя (по умолчанию) опубликованная конечная точка, которую мы хотим вызвать.

Говоря о вызове извне, официальная документация по Машинному обучению Azure предоставляет примеры того, как вызывать конечную точку конвейера обучения AML извне, используя аутентификацию на основе токенов с SPN (Service Principal) для разных языков: NodeJS, Python ", "Ява". Мы адаптировали фрагмент кода «Java, чтобы получить следующий фрагмент кода для консольного приложения C # .NET Core (с использованием минималистичного подхода REST только с HttpClient), вызывающего конвейер обучения AML извне от имени SPN:

У этого SPN должно быть не менее 2 разрешений, предоставленных AML в соответствии с принципом наименьших привилегий:

• Microsoft.MachineLearningServices / рабочие области / эксперименты / запускает / отправить / действие
• Microsoft.MachineLearningServices / рабочие области / конечные точки / конвейеры / чтение

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

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

Разница между использованием назначаемой пользователем управляемой идентификации и использованием управляемой идентификации будет заключаться в предоставлении или не предоставлении client_id в GetAmlAccessToken функции. Кроме того, переменные среды IDENTITY_ENDPOINT и IDENTITY_HEADER предоставляются платформой внутри среды выполнения функций Azure, как описано здесь. Таким образом, практически мы также можем увидеть разницу между токенами доступа, выпущенными с SPN, и с MSI, как показано ниже:

appidacrclaim указывает тип выполненной аутентификации клиента. Для конфиденциального клиента значение равно 1, когда общий секрет (пароль) используется как секрет клиента, и 2, когда сертификат используется как секрет клиента. Значение 0 указывает на общедоступного клиента, который не предоставляет секрет клиента и, следовательно, не аутентифицируется в STS.

Обратите внимание: в приведенных выше фрагментах кода вы могли заметить, что пустые полезные данные отправляются вместе с запросом POST при вызове конечной точки конвейера обучения AML. Это связано с тем, что в противном случае вы можете получить ошибку «Ссылка на объект не установлена ​​для экземпляра объекта», как показано ниже:

По своей природе обучение сложных моделей - длительная задача, которая может занять несколько часов или дней. Когда процесс обучения запускается в конвейере Azure DevOps через AML CLI (например, с помощью команды az ml run submit-pipeline), сам конвейер будет успешно завершен после выполнения команды, фактически, фактический процесс обучения может затем отслеживаться в Azure. Машинное обучение в связанном экспериментальном прогоне. На практике, когда код обучения модели изменяется и отправляется новый PR (запрос на вытягивание), важно убедиться, что процесс обучения завершается успешно. Таким образом, для конечной согласованности между Azure DevOps и машинным обучением Azure может быть полезно обновить состояние запроса на вытягивание Azure DevOps на основе результата выполнения эксперимента по машинному обучению Azure Выполнение обучения модели (успешно или неудачно). Этого можно достичь, реализовав механизм обратного вызова из конвейера обучения машинного обучения Azure обратно в Azure DevOps через Azure DevOps REST API. Фактически, новый PythonScriptStep может быть добавлен в самый конец обучающего конвейера машинного обучения Azure (после этапов обучения модели и оценки), который обновит статус запроса на вытягивание Azure DevOps после завершения процесса обучения в Машинном обучении Azure. Варианты аутентификации Azure DevOps описаны здесь. Например, для целей неинтерактивной аутентификации в Azure DevOps вы можете выбрать аутентификацию на основе PAT (персональный токен доступа), как описано здесь. Затем, следуя этому руководству и следующему общему шаблону VERB https://{instance}[/{collection}][/{team-project}]/_apis[/{area}]/{resource}?api-version={version}, мы можем реализовать фактический обратный вызов HTTP для обновления статуса запроса на вытягивание Azure DevOps в соответствии со спецификацией это, также предоставив токен личного доступа для Azure DevOps (его строковое представление Base64 должно быть точное) через заголовок HTTP. В Python вы можете воспользоваться преимуществами вашей любимой библиотеки HTTP-запросов, например, requests или http.client.

Структура конвейера обучения

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

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

Помимо шаблона MLOpsPython, вы также можете найти много кода и примеров GitHub для построения конвейеров обучения AML, например, подробное руководство здесь или простую демонстрацию здесь и т. Д. Однако мы придерживаемся шаблона MLOpsPython / sample from here, чтобы проиллюстрировать, как строится типичный многоступенчатый конвейер обучения AML с использованием AML Python SDK. В частности, на следующем рисунке показано, как параметры передаются из Azure DevOps в конвейер обучения AML, а также как параметры затем передаются между шагами внутри конвейера обучения AML, и все это с помощью стандартной библиотеки Python argparselibrary.

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

Когда конвейер выполняется, вы также можете проверить журналы выполнения на предмет шагов. На рисунке ниже показано, как PipelineDataobject использовался для передачи данных между этапами конвейера обучения AML (этап обучения и этап регистрации).

Также тот же конвейер (pipeline.py) может быть представлен в форме YAML (pipeline.yaml), как показано ниже:

При использовании YAML-представления конвейера обучения AML нам все еще нужны средства для указания порядка выполнения шагов (в отличие от использования run_aftercall для принудительного порядка конвейеров, определенных с помощью AML Python SDK). Порядок будет подразумеваться из-за зависимостей между входами и выходами между шагами, и это именно та модификация, которую мы внесли, чтобы правильно соединить шаги, используя 3 PipelineDataobject (A, B и C), как показано ниже:

Примечательно: когда запускается конвейер обучения AML, это делается в контексте запуска эксперимента (вы можете найти описательную схему этого процесса здесь). Машинное обучение Azure предоставляет объект Run (как описано здесь), доступный в вашем коде конвейера обучения AML. Поскольку типичный конвейер обучения AML состоит из нескольких шагов, каждый из которых выполняется в собственном контейнере Docker (возможно, даже на разных вычислительных кластерах), контекст выполнения шага доступен через runobject, а общий контекст выполнения родительского конвейера доступен черезrun.parentobject. Это может пригодиться в случае, если нам нужно передать некоторую информацию между этапами конвейера, например, пометив весь цикл конвейера тегами с определенного этапа (этапов), а затем прочитав эти теги на следующем этапе (этапах) вместо формальной передачи параметры между шагами через код.

Данные обучения

Машинное обучение Azure предоставляет концепцию хранилища данных, которая позволяет подключаться к различным типам служб хранения в Azure, как описано здесь. Некоторые из этих типов хранилищ данных (например, хранилище BLOB-объектов Azure, общие файловые ресурсы Azure) предоставляют статические данные, в то время как другие (например, База данных SQL Azure) предоставляют динамические данные (например, на основе запроса). Практически это означает, что если у вас есть этап подготовки данных в вашем обучающем конвейере, который зависит от набора файлов в хранилище BLOB-объектов Azure (в связанном наборе данных), вам необходимо обязательно обновить (повторно загрузить) эти файлы на случай, если данные изменились. С другой стороны, если на этапе подготовки данных используется живое соединение с базой данных, данные будут актуальными в соответствии с запросом для связанного набора данных. В некоторых случаях имеет смысл переместить данные из одного типа хранилища в другой (например, из базы данных в хранилище больших двоичных объектов), и для этих целей aDataTransferStep может использоваться как часть вашего обучающего конвейера.

Среды и стратегия развертывания

Процесс создания моделей AI / ML и их внедрения в производство включает в себя множество сдержек и противовесов с участием множества заинтересованных сторон и множества сред, созданных для поддержки необходимых процедур. Справочник по процессу и руководство по средам можно найти здесь в эталонной архитектуре Python MLOps, как показано ниже.

На этой диаграмме выделен ряд сред, таких как Dev / Test, Staging / QA и Production. Платформа машинного обучения Azure обеспечивает интегрированную автоматизацию развертывания (стратегия развертывания AML), которая позволяет развертывать ваши модели в экземплярах контейнеров Azure (ACI) и Azure Kubernetes Services (AKS) с помощью удобного пакета SDK для AML Python и / или интерфейса командной строки AML. Однако вы можете использовать свою собственную стратегию развертывания вне AML, в этом случае вы можете упаковать свои модели в образы контейнеров Docker, поместить их в выделенный реестр контейнеров Azure (ACR), а затем развернуть их в выделенной службе Azure Kubernetes. (AKS) или, возможно, как приложение-функция Azure или веб-приложение Azure в зависимости от требований. Эта стратегия гибридного развертывания (стратегия развертывания AML + ваша собственная стратегия развертывания) проиллюстрирована ниже.

Дополнительные инструкции по этой теме можно найти здесь, здесь и здесь. И в этом разделе мы предоставим дополнительную иллюстрацию того, как вы можете упаковать свою модель из AML в образ контейнера Docker с помощью команды CLI az ml model packageAML и как выглядит результат.

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

Теперь, если вам нужно переместить образы контейнеров между ACR (например, непроизводственной и производственной), это можно сделать с помощью команды az acr import CLI, как описано здесь.

Как правило, модели развертываются в экземплярах контейнеров Azure (ACI) в среде разработки / тестирования и / или в среде промежуточного тестирования / контроля качества с меньшим объемом инфраструктуры, а затем службы Azure Kubernetes (AKS) используются для масштабных производственных развертываний. Общий жизненный цикл продвижения модели обычно включает в себя маркировку моделей соответствующими тегами (чтобы различать незавершенные модели и модели, которые являются кандидатами для производства), а также ручные пусковые механизмы для обеспечения необходимой строгости перед тем, как модель попадет в производство. На практике обработка метаданных производственной модели и управление версиями в виде декларативной конфигурации, зарегистрированной в репо (в выделенной ветке на основе запроса на вытягивание), помогает обеспечить подотчетность и помогает в случае, если вам нужно отменить ошибочное развертывание до последней стабильной версии. государство.

Инфраструктура и MLOps

С точки зрения чистой инфраструктуры существует несколько вариантов, которые можно использовать для развертывания необходимой инфраструктуры для самого ресурса AML и AML. Например, ARM-шаблоны или Бицепс, или Terraform. Дополнительные сведения о том, какие объекты AML можно развернуть с помощью Terraform (помимо обычных ресурсов Azure, таких как хранилище Azure и т. Д.), Можно найти здесь:

• Рабочая область машинного обучения Azure (azurerm_machine_learning_workspace)
• Вычислительный кластер машинного обучения Azure (azurerm_machine_learning_compute_cluster)
• Экземпляр компьютера для машинного обучения Azure (azurerm_machine_learning_compute_instance)
• Кластер вывода машинного обучения Azure (azurerm_machine_learning_inference_cluster)

DevOps и MLOps

Как описано в этой статье, Azure DevOps очень хорошо оборудован для организации всех необходимых процессов MLOps во взаимодействии с платформой машинного обучения Azure. Фактически, для такой оркестрации доступны и другие варианты, например, GitHub Actions. Как описано здесь, GitHub Actions предоставляют набор действий, интегрированный с Машинным обучением Azure, для развертывания моделей машинного обучения в Azure. Список соответствующих действий машинного обучения Azure приведен ниже:

• Aml-workspace - подключается или создает новое рабочее пространство.
• Aml-compute - подключается или создает новую цель вычислений в Машинном обучении Azure.
• Aml-run - отправляет ScriptRun, оценщик или конвейер в Машинное обучение Azure.
• Aml-registermodel - регистрирует модель в Машинном обучении Azure.
• Aml-deploy - развертывает модель и создает конечную точку для модели.

Инструменты и производительность разработчика

По нашему опыту, использование Visual Studio Code для разработки и тестирования Python увеличивает продуктивность вашего разработчика. Visual Studio Code поставляется с множеством полезных функций и плагинов. Чтобы упомянуть только один здесь, мы подчеркиваем, как средства форматирования кода и линтеры кода Python позволяют вам в первую очередь (в первый раз) написать свой очиститель кода, поэтому вам не нужно решать эти проблемы отдельно и тратить дополнительное время на код. cleanup, когда вы собираетесь отправить запрос на перенос в основную ветку. Visual Studio Code удобно предлагает варианты для программ форматирования Python, таких как black, autopep8 или yapf, и линтеров Python, таких как flake8.

Заявление об ограничении ответственности

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