Базовая эталонная архитектура чата OpenAI

Корпоративные приложения чата могут предоставлять сотрудникам возможность взаимодействия с беседами. Эта точка особенно истинна из-за непрерывного продвижения языковых моделей, таких как модели GPT OpenAI и модели Meta Llama. Эти приложения чата состоят из следующих:

• Пользовательский интерфейс чата.
• Репозитории данных, содержащие сведения о домене, относящиеся к запросам пользователя.
• Языковые модели, которые причиняют данные, относящиеся к домену, для получения соответствующего ответа.
• Оркестратор, который контролирует взаимодействие между компонентами.

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

Размещение пользовательского интерфейса чата следует базовым рекомендациям веб-приложений служб приложений по развертыванию безопасного, избыточного между зонами и высокодоступного веб-приложения в Службе приложений Azure. В этой архитектуре Служба приложений взаимодействует с решением Платформы Azure как услуга (PaaS) через интеграцию виртуальной сети с частными конечными точками. В архитектуре пользовательского интерфейса чата служба приложений взаимодействует с управляемой конечной точкой в Сети для потока через частную конечную точку. Общедоступный доступ к порталу Azure AI Foundry отключен.

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

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

Архитектура

Скачайте файл Visio для этой архитектуры.

Компоненты

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

• Azure OpenAI используется в обеих архитектурах. Azure OpenAI — это полностью управляемая служба, которая предоставляет доступ REST API к языковым моделям Azure OpenAI, включая GPT-4, GPT-3.5-Turbo и набор моделей внедрения. Базовая архитектура использует корпоративные функции, такие как виртуальные сети и частные каналы , которые базовая архитектура не реализует.

• Azure AI Foundry — это платформа, которую можно использовать для создания, тестирования и развертывания решений ИИ. Эта архитектура использует портал Azure AI Foundry для создания, тестирования и развертывания логики оркестрации потоков запроса для приложения чата. В этой архитектуре Azure AI Foundry предоставляет управляемые виртуальные сети для обеспечения безопасности сети. Дополнительные сведения см. в разделе "Сеть " в этой статье.

• Шлюз приложений Azure — это подсистема балансировки нагрузки уровня 7 (HTTP/S) и маршрутизатор веб-трафика. Он использует маршрутизацию на основе URL-адресов для распределения входящего трафика между зонами доступности и разгрузки шифрования для повышения производительности приложения.

• Брандмауэр веб-приложений Azure — это облачная служба, которая помогает защитить веб-приложения от распространенных эксплойтов, таких как внедрение SQL и межсайтовые скрипты. Брандмауэр веб-приложения обеспечивает видимость трафика в веб-приложение и из нее. Эта видимость помогает отслеживать и защищать приложение.

• Azure Key Vault — это служба, которая безопасно хранит секреты, ключи шифрования и сертификаты и управляет ими. Она централизованно обеспечивает управление конфиденциальной информацией.

• Виртуальная сеть Azure — это служба, которую можно использовать для создания изолированных и более безопасных частных виртуальных сетей в Azure. Для веб-приложения на Служба приложений требуется подсеть виртуальной сети для использования частных конечных точек для сетевого безопасного взаимодействия между ресурсами.

• Приватный канал Azure позволяет клиентам получать доступ к службам Azure PaaS непосредственно из частных виртуальных сетей без использования общедоступных IP-адресов.

• Azure DNS — это служба размещения для доменов DNS, которые предоставляют разрешение имен с помощью инфраструктуры Microsoft Azure. Частная зона DNS зонах предоставляют способ сопоставления полного доменного имени службы (FQDN) с IP-адресом частной конечной точки.

Альтернативные варианты

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

Рабочие области машинного обучения и интерфейсы портала

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

Компоненты уровня приложений

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

Размещение потока запроса

Развертывание потоков запросов не ограничивается вычислительными кластерами машинного обучения. Эта архитектура иллюстрирует эту точку с помощью альтернативного решения в Службе приложений. Потоки — это контейнерное приложение, которое можно развернуть в любой службе Azure, совместимой с контейнерами. К ним относятся такие службы, как AKS, приложения-контейнеры и служба приложений. Выберите службу контейнеров Azure на основе требований уровня оркестрации.

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

Хранилище данных заземления

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

Соображения

These considerations implement the pillars of the Azure Well-Architected Framework, which is a set of guiding tenets that you can use to improve the quality of a workload. For more information, see Well-Architected Framework.

Примените эту архитектуру и рекомендации по проектированию в рабочих нагрузках ИИ в Azure во время процесса разработки для конкретной рабочей нагрузки.

Надежность

Reliability helps ensure that your application can meet the commitments that you make to your customers. Дополнительные сведения см . в контрольном списке проверки конструктора для обеспечения надежности.

Базовая архитектура веб-приложения службы приложений посвящена зональной избыточности для ключевых региональных служб. Зоны доступности физически разделяются в пределах региона. Они обеспечивают избыточность в пределах региона для поддержки служб при развертывании двух или более экземпляров между ними. Когда время простоя происходит в одной зоне, другие зоны в регионе могут быть не затронуты. Архитектура также помогает гарантировать, что достаточно экземпляров и конфигураций служб Azure распределяются по зонам доступности. Дополнительные сведения см. в разделе "Базовые высокодоступные веб-приложения с высоким уровнем доступности".

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

Зональная избыточность для развертываний потоков

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

Альтернативные вычислительные кластеры машинного обучения включают AKS, Функции Azure, приложения контейнеров и службу приложений. Каждая из этих служб поддерживает зоны доступности. Чтобы обеспечить зональную избыточность для выполнения потока запроса без дополнительной сложности развертывания с несколькими регионами, можно развернуть потоки в одном из этих служб.

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

Следующий поток данных соответствует предыдущей схеме:

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

2. Эта точка показывает, что контейнерные исполняемые потоки отправляются в реестр контейнеров. На схеме не отображаются конвейеры, которые контейнеризируют потоки и передаются в реестр контейнеров. Вычисления, в которых выполняются эти конвейеры, должны иметь сетевую линию видимости к ресурсам, таким как Реестр контейнеров Azure и проект Azure AI Foundry.

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

4. Контейнер потока запроса должен подключаться ко всем зависимым службам для выполнения потока. В этой архитектуре контейнер потока запросов подключается к поиску ИИ и Azure OpenAI. Службы PaaS, предоставляемые только подсети управляемой частной конечной точки машинного обучения, теперь также нуждаются в воздействии в виртуальной сети, чтобы установить линию видимости от службы приложений.

Надежность в Azure OpenAI

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

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

Важно отслеживать требуемую пропускную способность с точки зрения маркеров в минуту (TPM) и запросов в минуту (RPM). Назначьте достаточно доверенного платформенного модуля из квоты, чтобы обеспечить соответствие требованиям к развертываниям и предотвратить регулирование вызовов развернутых моделей. Вы можете развернуть шлюз, например управление API Azure перед службой или службами Azure OpenAI, и настроить его для повторных попыток при возникновении временных ошибок и регулирования. Управление API также можно использовать в качестве средства автоматического останова , чтобы предотвратить перегрузку службы вызовами и превышение квоты. Дополнительные сведения см. в статье "Использование шлюза перед несколькими развертываниями Или экземплярами Azure OpenAI".

Надежность в поиске ИИ

Разверните поиск ИИ с ценовой категорией "Стандартный" или выше в регионе , поддерживающем зоны доступности, и разверните три или более реплики. Реплики автоматически распределяют равномерно между зонами доступности.

Используйте следующее руководство, чтобы определить соответствующее количество реплик и секций:

• Мониторинг поиска ИИ.

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

Надежность в Azure AI Foundry

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

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

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

• Развертывание не менее трех экземпляров для активного рабочего развертывания.

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

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

Если для развертывания ресурсов используется инфраструктура в качестве кода (IaC), включая управляемые сетевые конечные точки, возникает проблема надежности. Эта проблема выделена в предоставленной эталонной реализации. Если вы настроили трафик для маршрутизации в развертывания, созданные с помощью интерфейса командной строки или портала Azure AI Foundry, и выполняется последующее развертывание IaC, включающее управляемую конечную точку в сети, даже если она не обновляет управляемую конечную точку в сети каким-либо образом, трафик конечной точки возвращается к маршрутизации 0% трафика. Фактически этот сценарий означает, что развернутые потоки запросов недоступны, пока не измените трафик обратно в нужное место.

Проектирование нескольких регионов

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

• Глобальный вход и маршрутизация
• Стратегия управления DNS
• Стратегия репликации данных или изоляции
• Обозначение "активный-активный", "активный-пассивный" или "активный-холодный"
• Стратегия отработки отказа и восстановления размещения для достижения цели восстановления рабочей нагрузки и цели точки восстановления
• Рекомендации по обеспечению доступности регионов для разработчиков в ресурсе Центра Azure AI Foundry

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

• Базовые данные
• Размещение моделей
• Уровень оркестрации, который является потоком запроса в этой архитектуре
• Пользовательский интерфейс, доступный для клиента

Кроме того, необходимо поддерживать непрерывность бизнес-процессов в наблюдаемости, интерфейсах порталах и ответственном ИИ, таких как безопасность содержимого.

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

Security provides assurances against deliberate attacks and the misuse of your valuable data and systems. Дополнительные сведения см. в контрольном списке проверки конструктора для безопасности.

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

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

В этом разделе описываются рекомендации по настройке сети и безопасности для смены ключей и модели Azure OpenAI.

Управление удостоверениями и доступом

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

• Создайте отдельные управляемые удостоверения для следующих ресурсов Azure AI Foundry и Машинного обучения, где это применимо:

  • Центр Azure AI Foundry
  • Проекты Azure AI Foundry для разработки и управления потоками
  • Сетевые конечные точки в развернутом потоке, если поток развертывается в управляемой сетевой конечной точке

• Реализация элементов управления доступом к удостоверениям для пользовательского интерфейса чата с помощью идентификатора Microsoft Entra

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

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

Машинное обучение роли доступа на основе ролей

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

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

Управляемое удостоверение	Область	Назначения ролей
Управляемое удостоверение концентратора	Участник	Группа ресурсов
Управляемое удостоверение концентратора	Узел	Администратор ИИ Azure
Управляемое удостоверение концентратора	Реестр контейнеров	Участник
Управляемое удостоверение концентратора	Key Vault	Участник
Управляемое удостоверение концентратора	Key Vault	Администратор
Управляемое удостоверение концентратора	учетная запись хранения	Читатель
Управляемое удостоверение концентратора	учетная запись хранения	Участник учетных записей хранения
Управляемое удостоверение концентратора	учетная запись хранения	Участник данных хранилища BLOB-объектов
Управляемое удостоверение концентратора	учетная запись хранения	Привилегированный участник файловых данных хранилища
Управляемое удостоверение концентратора	учетная запись хранения	Участник данных таблицы хранилища
Управляемое удостоверение проекта	Project	Администратор ИИ Azure
Управляемое удостоверение проекта	Реестр контейнеров	Участник
Управляемое удостоверение проекта	Key Vault	Участник
Управляемое удостоверение проекта	Key Vault	Администратор
Управляемое удостоверение проекта	учетная запись хранения	Читатель
Управляемое удостоверение проекта	учетная запись хранения	Участник учетных записей хранения
Управляемое удостоверение проекта	учетная запись хранения	Участник данных хранилища BLOB-объектов
Управляемое удостоверение проекта	учетная запись хранения	Привилегированный участник файловых данных хранилища
Управляемое удостоверение проекта	учетная запись хранения	Участник данных таблицы хранилища
Управляемое удостоверение конечной точки в Сети	Project	секреты подключения к рабочей области Машинное обучение Azure
Управляемое удостоверение конечной точки в Сети	Project	Редактор метрик Azure ML
Управляемое удостоверение конечной точки в Сети	Реестр контейнеров	ACRPull
Управляемое удостоверение конечной точки в Сети	Azure OpenAI	Пользователь службы OpenAI в Cognitive Services
Управляемое удостоверение конечной точки в Сети	учетная запись хранения	Участник данных хранилища BLOB-объектов
Управляемое удостоверение конечной точки в Сети	учетная запись хранения	Читатель данных больших двоичных объектов хранилища
Служба приложений (при развертывании потока запроса в Служба приложений)	Azure OpenAI	Пользователь службы OpenAI в Cognitive Services
Пользователь портала (разработка потока запроса)	Azure OpenAI	Пользователь службы OpenAI в Cognitive Services
Пользователь портала (разработка потока запроса)	учетная запись хранения	Участник данных BLOB-объектов хранилища (используйте условный доступ)
Пользователь портала (разработка потока запроса)	учетная запись хранения	Привилегированный участник файловых данных хранилища

Важно понимать, что Центр Azure AI Foundry делится ресурсами Azure, такими как учетные записи хранения и реестр контейнеров в проектах. Если у вас есть пользователи, которым требуется доступ только к подмножествам проектов, рассмотрите возможность использования условий назначения ролей для служб Azure, которые поддерживают их, чтобы предоставить минимальный доступ к ресурсам. Например, большие двоичные объекты в хранилище поддерживают условия назначения ролей. Если пользователю требуется доступ к подмножество проектов, используйте условия доступа к ролям, чтобы ограничить разрешения на контейнеры BLOB-объектов, которые эти проекты используют вместо назначения разрешений на основе каждого контейнера. Каждый проект имеет уникальный GUID, который служит префиксом для имен контейнеров БОЛЬШИХ двоичных объектов, используемых в этом проекте. Этот GUID можно использовать в рамках условий назначения ролей.

Центру требуется Contributor доступ к группе ресурсов концентратора, чтобы она могли создавать и управлять ресурсами концентратора и проекта. Contributor access также предоставляет центру управления доступ к любому ресурсу, который находится в группе ресурсов. Создайте ресурсы Azure, которые не связаны напрямую с концентратором и его проектами в отдельной группе ресурсов. Рекомендуется создать не менее двух групп ресурсов для группы рабочей нагрузки, которая использует самоуправляемый центр Azure AI Foundry. Одна группа ресурсов содержит концентратор, его проекты и все его прямые зависимости, такие как Реестр контейнеров Azure и Key Vault. Другая группа ресурсов содержит все остальное в рабочей нагрузке.

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

Убедитесь, что для каждого отдельного проекта назначения ролей для зависимостей не предоставляют доступ к ресурсам, которые пользователь портала и управляемое управляемое удостоверение конечной точки в Сети не требуют. Например, Cognitive Services OpenAI User назначение ролей в Azure OpenAI предоставляет доступ ко всем развертываниям для этого ресурса. Нет способа ограничить авторов потоков или управляемых сетевых конечных удостоверений, имеющих назначение ролей определенным развертываниям моделей в Azure OpenAI. В этих сценариях рекомендуется развертывать такие службы, как Azure OpenAI и ПОИСК ИИ для каждого проекта, и не развертывать ресурсы в тех службах, к которым авторы потока или управляемые управляемые сетевые удостоверения конечных точек не должны иметь доступа. Например, развертывайте только модели в экземпляре Azure OpenAI, к которому требуется доступ к проекту. Только развертывайте индексы в экземпляре поиска ИИ, к которому должен иметь доступ проект.

Сеть

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

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

Сетевые потоки

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

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

Входящий трафик для Машинное обучение

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

Доступ к частной конечной точке также требуется для подключения к рабочей области Машинного обучения для разработки потоков.

На схеме показан автор потока запроса, который подключается через Бастион Azure к прямоугольнику перехода виртуальной машины. В этом поле перехода автор может подключиться к рабочей области Машинное обучение через частную конечную точку в той же сети, что и поле перехода. Автор также может подключаться к виртуальной сети через Azure ExpressRoute или VPN-шлюзы и пиринг виртуальной сети.

Поток из управляемой виртуальной сети Azure AI Foundry в службы Azure PaaS

Рекомендуется настроить центр Azure AI Foundry для изоляции управляемой виртуальной сети, для которой требуется утверждение всех исходящих подключений. Эта архитектура следует этой рекомендации. Существует два типа утвержденных правил исходящего трафика. Обязательные правила исходящего трафика предназначены для ресурсов, необходимых для решения, таких как реестр контейнеров и хранилище. Определяемые пользователем правила исходящего трафика предназначены для пользовательских ресурсов, которые использует рабочий процесс, например Azure OpenAI или поиск ИИ. Необходимо настроить определяемые пользователем правила исходящего трафика. Необходимые правила исходящего трафика настраиваются при создании управляемой виртуальной сети. Управляемая виртуальная сеть развертывается по запросу при первом использовании и сохраняется после этого.

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

Экземпляр брандмауэра Azure, управляемый корпорацией Майкрософт, реализует исходящий полный доменный домен и развертывается в управляемой сети Azure AI Foundry. Выберите ценовую категорию "Базовый", если необходимо управлять трафиком исходящего трафика только http (порт 80) или HTTPS (порт 443). Если для исходящего трафика требуются пользовательские протоколы или порты, выберите ценовую категорию "Стандартный". Эта архитектура использует ценовую категорию "Базовый", так как единственный исходящий трафик — это конечные точки HTTPS через порт 443.

Сегментация виртуальной сети и безопасность

Сеть в этой архитектуре имеет отдельные подсети для следующих целей:

• Шлюз приложений
• компоненты интеграции Служба приложений
• Частные конечные точки
• Бастион Azure
• Виртуальные машины с полем перехода
• Очки
• Обучение и оценка подсетей

  Примечание.

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

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

Подсеть	Входящий трафик	Исходящий трафик
snet-appGateway	Пособия для IP-адресов источника пользовательского интерфейса чата, таких как общедоступный Интернет и необходимые элементы для службы.	Доступ к частной конечной точке службы приложений и необходимым элементам службы.
snet-PrivateEndpoints	Разрешить только трафик из виртуальной сети.	Разрешить только трафик в виртуальную сеть.
snet-AppService	Разрешить только трафик из виртуальной сети.	Разрешить доступ к частным конечным точкам и Azure Monitor.
AzureBastionSubnet	Ознакомьтесь с доступом NSG и Бастионом Azure.	Ознакомьтесь с доступом NSG и Бастионом Azure.
snet-jumpbox	Разрешить входящий протокол удаленного рабочего стола и протокол Secure Shell из подсети узла Бастиона Azure.	Разрешить доступ к частным конечным точкам.
агенты snet-agent	Разрешить только трафик из виртуальной сети.	Разрешить только трафик в виртуальную сеть.
snet-training	Разрешить только трафик из виртуальной сети.	Разрешить только трафик в виртуальную сеть.
snet-scoring	Разрешить только трафик из виртуальной сети.	Разрешить только трафик в виртуальную сеть.

Весь остальной трафик явно отрицается.

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

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

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

• Используйте группы безопасности приложений для группировки групп безопасности сети. Группирование групп NSG упрощает создание правил для сложных сред.

Смена ключей

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

• Сохраните ключ в защищенном хранилище, например Key Vault, для доступа по запросу от авторизованных клиентов, таких как веб-приложение Azure, на котором размещен контейнер потока запроса.

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

Настройка модели OpenAI

Если вы точно настраиваете модели OpenAI в реализации, рассмотрите следующее руководство.

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

• Если вы храните обучающие данные в хранилище, например хранилище BLOB-объектов Azure, используйте управляемый клиентом ключ для шифрования данных, управляемое удостоверение для управления доступом к данным и частную конечную точку для подключения к данным.

Управление с помощью политики

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

• Отключите ключ или другой локальный доступ к проверке подлинности в службах, таких как службы ИИ Azure и Key Vault.

• Требуется определенная конфигурация правил доступа к сети или групп безопасности сети.

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

Назначения ролей Azure AI Foundry для Key Vault

Управляемое удостоверение Azure AI Foundry требует назначения ролей уровня управления (Contributor) и плоскости данных.Key Vault Administrator Эти назначения предоставляют этому удостоверению доступ на чтение и запись ко всем секретам, ключам и сертификатам, хранящимся в Azure Key Vault. Если рабочая нагрузка использует службы, отличные от Azure AI Foundry, для которых требуется доступ к секретам, ключам или сертификатам в Key Vault, ваша рабочая нагрузка или команда безопасности могут предпочесть, что управляемое удостоверение Azure AI Foundry Hub не имеет доступа к этим артефактам. В этом сценарии рассмотрите возможность развертывания экземпляра Key Vault специально для центра Azure AI Foundry и других экземпляров Key Vault в соответствии с другими частями рабочей нагрузки.

Оптимизация затрат

Cost Optimization focuses on ways to reduce unnecessary expenses and improve operational efficiencies. Дополнительные сведения см . в контрольном списке проверки конструктора для оптимизации затрат.

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

Службы вычислений

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

Azure OpenAI

Azure OpenAI — это служба на основе потребления, поэтому соответствие спроса с предложением является основным способом управления затратами. Для этого в Azure OpenAI необходимо использовать сочетание подходов:

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

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

  • Будьте самоуправляемы. Требовать от клиентов использовать ограничения, ограничивающие маркеры, предоставляемые вызовами API, например max_tokens и max_completions.

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

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

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

• Выберите подходящую модель ИИ. Выбранная модель влияет на общую стоимость Azure OpenAI. Все модели имеют сильные и слабые стороны и по отдельности ценятся. Используйте правильную модель для варианта использования, чтобы предотвратить перерасход на более дорогой модели, когда модель с меньшими затратами дает приемлемые результаты. Эта эталонная реализация чата использует GPT 3.5-turbo вместо GPT-4 для экономии затрат на развертывание модели при достижении достаточных результатов.

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

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

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

• Отслеживайте использование по мере использования. Если вы используете цены на оплату по мере использования, следите за использованием TPM и RPM. Используйте эти сведения для информирования архитектурных решений о проектировании, таких как модели для использования, и оптимизации размеров запросов.

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

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

Операционное превосходство

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

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

Как и в базовой архитектуре, эта архитектура использует автоматическую среду выполнения для минимизации рабочей нагрузки. Автоматическая среда выполнения — это бессерверный параметр вычислений в Машинное обучение, который упрощает управление вычислениями и делегирует большую часть конфигурации потока запроса в файл и requirements.txt конфигурацию запущенного flow.dag.yaml приложения. Этот выбор является низким обслуживанием, временным и управляемым приложением. В этой архитектуре используется среда выполнения вычислительного экземпляра или внешние вычисления, для управления жизненным циклом вычислений требуется команда рабочей нагрузки. Следует использовать среду выполнения вычислительного экземпляра, если требования к рабочей нагрузке превышают возможности конфигурации параметра автоматической среды выполнения.

Наблюдение

Как и в базовой архитектуре, диагностика настроены для всех служб. Все службы, кроме службы приложений, настроены для записи всех журналов. Служба приложений настроена для записи AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogsи AppServicePlatformLogs. В рабочей среде все журналы, вероятно, чрезмерны. Настройте потоки журналов в соответствии с вашими потребностями в работе. Для этой архитектуры проект Azure AI Foundry использует AmlComputeClusterEventAmlDataSetEventAmlEnvironmentEventжурналы , а также AmlModelsEvent журналы машинного обучения.

Оцените создание пользовательских оповещений, таких как те, которые находятся в базовых оповещениях Azure Monitor, для ресурсов в этой архитектуре. Например:

• Оповещения реестра контейнеров
• оповещения Машинное обучение и Azure OpenAI
• Оповещения веб-приложений

Не забудьте отслеживать использование маркеров в развертываниях модели Azure OpenAI. В этой архитектуре поток запросов отслеживает использование маркеров через интеграцию с Application Insights.

Операции языковой модели

Развертывание решений чата на основе Azure OpenAI, таких как эта архитектура, должно соответствовать инструкциям в GenAIOps с потоком запросов и Azure DevOps и GenAIOps с потоком запросов и GitHub. Кроме того, необходимо рассмотреть рекомендации по непрерывной интеграции и непрерывной доставке (CI/CD) и архитектуре, защищенной сетью. В следующем руководстве рассматривается реализация потоков и связанной с ними инфраструктуры на основе рекомендаций GenAIOps. Это руководство по развертыванию не включает интерфейсные элементы приложения, которые не отличаются от базовой архитектуры высокодоступных веб-приложений с высоким уровнем доступности.

Разработка

Поток запросов предоставляет интерфейс разработки на основе браузера на портале Azure AI Foundry или с помощью расширения Visual Studio Code. Оба этих параметра хранят код потока в виде файлов. При использовании портала файлы хранятся в учетной записи хранения. При работе в VS Code файлы хранятся в локальной файловой системе.

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

Для корпоративной разработки используйте расширение VS Code и пакет SDK потока запросов или CLI для разработки. Авторы потока запросов могут создавать и тестировать потоки из VS Code и интегрировать локальные сохраненные файлы с системой управления версиями и конвейерами. Интерфейс на основе браузера предназначен для изучения разработки, но вы можете работать над его интеграцией с системой управления версиями. Вы можете скачать папку потока с страницы потока на Files панели, распакуировать папку и отправить ее в систему управления версиями.

Оценка

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

• Точность классификации определяет, дает ли языковая модель правильный или неправильный показатель и агрегирует результаты для получения оценки точности.

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

• Fluency оценивает прогнозируемый ответ модели для его грамматической и лингвистической точности.

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

• Релевантность оценивает, насколько хорошо прогнозируемые ответы модели соответствуют заданным вопросам.

При реализации автоматизированных вычислений рассмотрите следующее руководство.

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

• Для некоторых из этих тестов требуются предварительно настроенные входные данные вопросов, контекста и правды.

• Включите достаточно пар вопросов и ответов, чтобы убедиться, что результаты тестов надежны. Рекомендуется включать по крайней мере 100-150 пар. Эти вопросы и ответы также называются золотым набором данных. Может потребоваться большее количество пар в зависимости от размера и домена набора данных.

• Избегайте использования языковых моделей для создания любых данных в золотом наборе данных.

Поток развертывания

Следующий поток данных соответствует предыдущей схеме:

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

2. После завершения локальной разработки и экспериментирования специалист по обработке и анализу данных открывает запрос на вытягивание (PR) из ветви признаков в главную ветвь. Pr активирует конвейер PR. Этот конвейер выполняет быстрые проверки качества, которые должны включать:

   • Выполнение потоков экспериментирования.
   • Выполнение настроенных модульных тестов.
   • Компиляция базы кода.
   • Анализ статического кода.

3. Конвейер может содержать шаг, который требует по крайней мере одного участника команды вручную утвердить PR перед слиянием. Утверждающий не может быть фиксацией, и они должны иметь опыт потока запроса и знание требований проекта. Если pr не утвержден, слияние блокируется. Если pr утвержден или отсутствует шаг утверждения, ветвь функций объединяется в основную ветвь.

4. Слияние с основной ветвью активирует процесс сборки и выпуска среды разработки.

   a. Конвейер CI активируется из слияния в главную ветвь. Конвейер CI выполняет все действия в конвейере PR и следующие действия.

   • Поток экспериментов
   • поток оценки.
   • Регистрация потока в реестре машинного обучения при обнаружении изменений

   b. Конвейер CI завершает работу, а затем активирует конвейер CD. Этот поток выполняет следующие действия:

   • Развертывает поток из реестра Машинное обучение в Машинное обучение конечную точку в сети
   • Выполняет тесты интеграции, предназначенные для конечной точки в Сети
   • Выполняет тесты дыма, предназначенные для конечной точки в Сети

5. Процесс утверждения встроен в процесс продвижения выпуска. После утверждения процесс CI/CD повторяется, нацелив тестовую среду. Шаги a. и b. одинаковы, за исключением того, что тесты принятия пользователем выполняются после тестов дыма в тестовой среде.

6. Процессы CI/CD выполняются для повышения выпуска в рабочую среду после проверки и утверждения тестовой среды.

7. После выпуска в динамической среде выполняются операционные задачи мониторинга метрик производительности и оценки развернутых языковых моделей. Эти задачи включают:

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

Руководства по развертыванию

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

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

• Используйте тестирование A/B для развертывания нового поведения. Тестирование A/B позволяет подмножество пользователей оценить последствия изменения.

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

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

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

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

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

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

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

Базовые компоненты

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

• Рабочая область машинного обучения.
• Учетная запись хранения для рабочей области машинного обучения.
• Реестр контейнеров.
• Поиск ИИ.
• Azure OpenAI.
• Application Insights.
• Бастион Azure.
• Виртуальная машина Azure для поля перехода.

Временные компоненты

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

• Модель в реестре моделей машинного обучения должна быть обновлена, если она изменяется в рамках конвейера CD.

• Образ контейнера должен быть обновлен в реестре контейнеров в рамках конвейера CD.

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

• Развертывания конечной точки Машинное обучение обновляются при развертывании или удалении потока.

• Хранилище ключей для пользовательского интерфейса клиента должно быть обновлено с ключом к конечной точке при создании новой конечной точки.

Управляемая виртуальная сеть по запросу

Управляемая виртуальная сеть автоматически подготавливается при первом создании вычислительного экземпляра. Если вы используете IaC для развертывания концентратора и не используете вычислительные ресурсы Azure AI Foundry в Bicep, управляемая виртуальная сеть не развертывается, и при подключении к порталу Azure AI Foundry возникает ошибка. После развертывания IaC необходимо вручную подготовить управляемую виртуальную сеть .

Организация ресурсов

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

Эффективность производительности

Performance Efficiency refers to your workload's ability to scale to meet user demands efficiently. Дополнительные сведения см . в контрольном списке проверки конструктора для повышения эффективности.

В этом разделе описывается эффективность производительности с точки зрения поиска ИИ, Azure OpenAI и Машинного обучения.

Эффективность производительности в поиске ИИ

Следуйте инструкциям по анализу производительности в поиске ИИ.

Эффективность производительности в Azure OpenAI

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

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

Эффективность производительности в машинном обучении

При развертывании в Машинное обучение сетевых конечных точек:

• Следуйте инструкциям по автомасштабированию сетевой конечной точки. Автомасштабирование обеспечивает тесное соответствие требованиям без чрезмерной подготовки, особенно в периоды низкой загрузки.

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

Развертывание этого сценария

Чтобы развернуть и запустить эту эталонную реализацию, выполните действия, описанные в реализации базовой эталонной базы OpenAI.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

• Рауф Алиуат | Инженер программного обеспечения II — Корпорация Майкрософт
• Фредди Айала | Архитектор облачных решений — Корпорация Майкрософт
• Роб Багби | Шаблоны и практики — Корпорация Майкрософт
• Prabal Deb | Старший инженер по программному обеспечению — Корпорация Майкрософт
• Ritesh Modi | Главный инженер по программному обеспечению — Корпорация Майкрософт
• Райан Пфальц | Старший архитектор решений — Корпорация Майкрософт

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

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

базовые показатели Azure OpenAI в целевой зоне Azure

Связанные ресурсы

• Перспектива Well-Architected Платформы для рабочих нагрузок ИИ в Azure
• Azure OpenAI
• Языковые модели Azure OpenAI
• поток запроса на портале Azure AI Foundry
• Изоляция управляемой виртуальной сети рабочей области
• Настройка частной конечной точки для рабочей области Машинное обучение
• Фильтрование содержимого