Платформа приложений для рабочих нагрузок ИИ в Azure

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

Эта область разработки охватывает несколько типов приложений, которые могут иметь отношение к рабочей нагрузке ИИ:

  • Разведочный анализ данных
  • Обучение и настройка моделей
  • Инференция

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

Рекомендации

Ниже приведена сводка рекомендаций, приведенных в этой статье.

Рекомендация Описание
Повторное использование инструментов. Начните с оценки уже используемых средств, чтобы понять, можно ли повторно использовать их для рабочей нагрузки ИИ. Если они поддерживают необходимые функциональные возможности и могут соответствовать вашим требованиям к надежности, безопасности, затратам и производительности, внедрение нового инструмента может не оправдать затрат и усилий.
Учитывайте требования соответствия касательно ваших данных и регионов, в которых планируется развертывание. Возможно, вам потребуется ограничить регионы развертывания или изолировать части вашей рабочей нагрузки друг от друга, чтобы соответствовать требованиям соответствия. Переход на этап разработки с этой информацией может помочь защитить вас от необходимости перепроектировать позже.
Свести к минимуму сборку. Рассмотрите использование решений Platform as a Service (PaaS) или Software as a Service (SaaS), чтобы минимизировать операционное бремя, возникающее при создании собственного решения, включая исправление ошибок и другое обслуживание. Минимизация эксплуатационной нагрузки, необходимой для новой технологии, упрощает её внедрение. Многие функции ИИ являются сложными, поэтому мы не рекомендуем создавать собственную платформу.
Общие сведения о квотах и ограничениях. При разработке решений PaaS или SaaS изучите все квоты или ограничения, которые применяются. Возможность горизонтального масштабирования для удовлетворения высоких требований к трафику может повлиять на квоты или ограничения, поэтому может потребоваться изменить структуру, чтобы свести к минимуму этот риск.
Развертывание в одном регионе. Попробуйте развернуть все связанные ресурсы в одном регионе, чтобы уменьшить задержку и упростить проектирование.
Практикуйте безопасное развертывание. Как правило, следует рассматривать API для рабочей нагрузки ИИ так же, как и любой другой API в вашей среде. Все API-интерфейсы должны размещаться за шлюзом, и весь код должен обрабатываться с теми же методами безопасного развертывания, что и каждый другой ресурс кода.
Создайте тесты производительности с помощью экспериментов. Каждая рабочая нагрузка ИИ отличается, и объем необходимых вычислений зависит от вашего варианта использования. Определите объем и типы вычислительных ресурсов, оптимальных для рабочей нагрузки, проведя тщательное тестирование производительности. Это руководство поможет вам выбрать платформу, но вы узнаете, какие SKU подходят для вашей рабочей нагрузки только после проведения бенчмарков.

Рекомендации по платформе EDA

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

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

Функциональные требования

При оценке платформы EDA рассмотрите следующие вопросы:

  • Поддерживает ли платформа временное использование?

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

  • Поддерживает ли платформа необязательность вычислений?

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

  • Поддерживает ли платформа MLflow?

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

    • Отслеживание экспериментов. MLflow позволяет отслеживать эксперименты, записывая параметры, метрики и артефакты. Эта возможность важна во время EDA, чтобы отслеживать различные этапы предварительной обработки данных и методы проектирования признаков и их влияние на производительность модели.
    • Воспроизводимость. Так как он записывает все сведения о экспериментах, MLflow помогает обеспечить воспроизведение результатов, что крайне важно для проверки результатов.
    • Управление версиями данных и моделей. MLflow помогает с версионированием наборов данных и моделей, что облегчает управление различными версиями преобразований данных и проверенными моделями.
    • Совместная работа. MLflow предоставляет централизованную платформу, в которой специалисты по обработке и анализу данных могут совместно использовать свои эксперименты и результаты, что упрощает совместную работу и обмен знаниями.

Нефункциональные требования

Рассмотрим следующие вопросы:

  • Как платформа помогает управлять затратами?

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

  • Какие требования безопасности должны соблюдаться для платформы?

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

    • Доступ и авторизация.
    • Шифрование при хранении и передаче.
    • Требования к защите региональных данных.
    • Надежные функции мониторинга и оповещения, включая ведение журнала и возможность аудита.
    • Частный сетевой доступ к централизованным репозиториям для образов контейнеров, данных и ресурсов кода.

Инструменты

Используйте вычислительный экземпляр Azure Machine Learning с общими папками уровня команды в качестве платформы EDA. Одним из исключений является то, что ваша команда или организация уже использует подходящую платформу размещения, например вычислительные кластеры с поддержкой GPU в Databricks, например. В этом случае может оказаться более подходящим оставаться на этой платформе.

Примечание.

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

Соображения по платформе для обучения и тонкой настройки модели

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

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

Функциональные требования

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

  • Поддерживает ли платформа временное использование?

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

  • Предоставляет ли платформа оркестрацию?

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

  • Могут ли существующие технологии в вашей среде быть частью решения?

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

Нефункциональные требования

Рассмотрим этот вопрос также:

  • Что такое терпимый компромисс между затратами и производительностью?

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

Инструменты

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

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

Примечание.

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

Рекомендации по размещению модели и платформе вывода

Функции размещения и инференции модели составляют служебный слой рабочей нагрузки ИИ. Эти функции выполняются с конечными точками, которые относятся к используемому программному обеспечению. Программные решения для обслуживания моделей, такие как NVIDIA Triton, TorchServe и TensorFlow Serving, по сути, являются Python SDK, которые предоставляют доступ к модели через API и добавляют функциональность, специфичную для данного решения. Вы можете выбрать свою платформу размещения на основе выбранного программного обеспечения или выбрать программное обеспечение на основе выбранной платформы размещения.

При использовании решений SaaS или PaaS с предварительно подготовленными моделями, такими как большие языковые модели, доступные в Azure OpenAI, у вас мало возможностей выбора программного обеспечения для обслуживания. Вместо этого служба, которую вы используете, предоставляет API. Это снижает гибкость процесса создания развертывания модели, что может обеспечить преимущества и недостатки. Например, это может упростить процесс разработки рабочей нагрузки. С другой стороны, это снижает гибкость в том, как приложение может вызывать и взаимодействовать с моделью.

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

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

Функциональные требования

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

  • Требуются ли пакетные или онлайн-инференсные вычисления?

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

  • Поддерживает ли платформа возможность трассировки?

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

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

  • Будет ли ваша платформа размещения централизованным ресурсом?

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

Нефункциональные требования

Рассмотрим следующие вопросы:

  • Каковы требования к надежности для платформы?

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

  • Какие сетевые элементы управления необходимы для платформы?

    Определите, требуется ли частная сеть или брандмауэр исходящего трафика для обеспечения защиты платформы.

  • Каковы требования к безопасности удостоверений и доступа для платформы?

    Определите элементы управления удостоверениями и доступом, необходимые для конечных точек. Рассмотрите необходимость собственного управления доступом на основе ролей (RBAC) или встроенной поддержки платформы удостоверений и доступа, например идентификатора Microsoft Entra.

  • Какие возможности мониторинга поддерживают платформу?

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

  • Каковы требования к производительности для платформы?

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

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

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

Инструменты

Пакетная обработка

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

  • Мы рекомендуем API пакетной службы Azure OpenAI для базовых моделей.

  • Для моделей, отличных от основы, рассмотрим следующие рекомендации:

    • Рассмотрите возможность использования пакетных конечных точек Azure Machine Learning для следующих сценариев:

      • Необходимо выполнить вывод в большом наборе данных, распределенном в нескольких файлах, и не требуется низкая задержка.

      • Необходимо выполнять длительные пакетные операции по большим наборам данных и использовать преимущества параллелизации.

      • Необходимо развернуть компоненты конвейера для пакетной обработки.

    • Если необходимо запустить задания Spark для распределенной обработки данных, рассмотрите возможность использования azure Synapse Analytics, Databricks или Машинное обучение бессерверных вычислений Spark.

    • Если ни один из этих сценариев не применяется, мы рекомендуем пакетные конечные точки машинного обучения.

Онлайн-инференция

  • Оцените платформу PaaS и бессерверные решения как первый шаг. Как правило, эти службы являются самыми простыми для внедрения и управления, так как они упрощают проектирование и минимизирует рабочее бремя. Например, Azure OpenAI — это хороший выбор для базовых моделей.

    • Рекомендуется использовать бессерверный API машинного обучения Azure для агрегирования доступа к конечным точкам, даже если вы используете Azure OpenAI или другое решение для размещения фундаментальных моделей.
  • Рассмотрите возможность использовать Машинное обучение с управляемыми вычислительными кластерами, если решения PaaS или бессерверные решения не подходят. Вычисления, управляемые машинным обучением, поддерживают разделение и зеркальное отображение трафика для A/B тестирования, отладки и надежного аудита. Так как вычислительные ресурсы управляются службой, операции Day-2 проще при самостоятельном размещении модели. Управляемые вычислительные ресурсы также предоставляют широкий выбор конфигураций вычислений и возможностей масштабирования.

  • Если вы решили самостоятельно разместить модель в кластере Служба Azure Kubernetes (AKS), подключенном к Машинное обучение или другой платформе на основе контейнеров, убедитесь, что пул узлов изолирован от других API или других рабочих нагрузок в кластере для достижения прогнозируемой производительности и оптимизации безопасности. Избегайте использования вычислительных ресурсов на основе GPU или GPU, оптимизированных для других функций рабочей нагрузки ИИ, чтобы сократить затраты. Вместо этого установите основную производительность с помощью тестирования и оптимально настройте вычислительные ресурсы, чтобы соответствовать требованиям к производительности без избыточного резервирования.

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

Рекомендации по платформе оркестрации

Оркестрация в контексте платформ приложений рабочей нагрузки искусственного интеллекта относится к средствам, таким как поток запросов на портале Машинного обучения и Microsoft Foundry. Эти средства предназначены для упрощения всего цикла разработки приложений ИИ, автоматизируя многие распространенные функции рабочего процесса.

Нефункциональные требования

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

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

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

  • оптимизация затрат. Средства оркестрации работают в режиме always-on, рассмотрите возможности для эластичных вычислений, чтобы свести к минимуму затраты на использование.

Инструменты

  • Предпочтите готовое решение, например, prompt flow. Определите, соответствуют ли его возможности требованиям оркестрации перед рассмотрением возможности пользовательского размещения с помощью таких инструментов, как LangChain или Semantic Kernel.

  • Конечные точки для решений, таких как prompt flow в машинном обучении с вычислительными экземплярами или в AKS с самостоятельным размещением.

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