Использование шлюза перед несколькими развертываниями или экземплярами Azure OpenAI

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

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

• Несколько развертываний модели в одном экземпляре Azure OpenAI
• Несколько экземпляров Azure OpenAI в одном регионе и одной подписке
• Несколько экземпляров Azure OpenAI в одном регионе в нескольких подписках
• Несколько экземпляров Azure OpenAI в нескольких регионах

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

Несколько развертываний модели в одном экземпляре Azure OpenAI

Сведения о топологии для нескольких развертываний моделей

• Развертывания модели Azure OpenAI: несколько
• Экземпляры Azure OpenAI: один
• Подписки: один
• Регионы: один

Варианты использования топологии для нескольких развертываний моделей

Топология, которая включает один экземпляр Azure OpenAI, но содержит несколько одновременно развернутых моделей, поддерживает следующие варианты использования:

• Предоставление различных возможностей модели, таких как gpt-35-turbo, gpt-4и пользовательские точно настроенные модели.

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

• Предоставление различных квот, назначенных (30 000 токенов в минуту (TPM), 60 000 TPM) для поддержки регулирования потребления в нескольких клиентах.

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

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

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

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

Использование шлюза в этой топологии позволяет отслеживать использование на основе клиента. Если клиенты не используют отдельные субъекты-службы Microsoft Entra, журналы доступа для Azure OpenAI не смогут различать несколько клиентов. Наличие шлюза перед развертыванием дает рабочей нагрузке возможность отслеживать использование каждого клиента в различных доступных развертываниях моделей для поддержки моделей оплаты или демонстрации моделей.

Советы по топологии нескольких развертываний моделей

• Хотя шлюз находится в состоянии полностью изменить используемую модель, например gpt-35-turbo gpt-4, это изменение, скорее всего, будет считаться критическим изменением клиента. Не позволяйте новым функциональным возможностям шлюза отвлекать от выполнения всегда безопасных методов развертывания для этой рабочей нагрузки.

• Эта топология, как правило, достаточно простая для реализации с помощью политики azure Управление API вместо пользовательского решения кода.

• Чтобы поддерживать использование собственных пакетов SDK с опубликованными спецификациями API OpenAI Azure, сохраняйте совместимость API с API Azure OpenAI. Эта ситуация является более крупной проблемой, когда ваша команда не создает весь код клиентов рабочей нагрузки. При принятии решения о разработке HTTP-API для шлюза рассмотрите преимущества обеспечения совместимости API HTTP Azure OpenAI.

• Хотя эта топология технически поддерживает сквозные учетные данные клиента (маркеры доступа или ключ API) для экземпляра Azure OpenAI, настоятельно рекомендуется реализовать завершение и восстановление учетных данных. Таким образом клиент авторизован на шлюзе, а затем шлюз авторизован через Azure RBAC в экземпляр Azure OpenAI.

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

• Разверните шлюз в том же регионе, что и экземпляр Azure OpenAI.

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

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

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

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

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

Несколько экземпляров Azure OpenAI в одном регионе и одной подписке

Сведения о топологии для нескольких экземпляров в одном регионе и одной подписке

• Развертывания модели Azure OpenAI: одна или несколько
• Экземпляры Azure OpenAI: несколько
• Подписки: один
• Регионы: один

Варианты использования топологии для нескольких экземпляров в одном регионе и одной подписке

Топология, включающая несколько экземпляров Azure OpenAI в одном регионе и одну подписку, поддерживает следующие варианты использования:

• Включает границы сегментации безопасности, такие как ключ или RBAC для каждого клиента

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

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

• Включает стратегию отработки отказа для доступности квоты Azure OpenAI, например связывание экземпляра на основе PTU и экземпляра на основе потребления для разлива

Введение шлюза для нескольких экземпляров в одном регионе и подписке

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

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

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

Один из вариантов, когда команда рабочей нагрузки подготавливает Azure OpenAI, определяет, основана ли модель выставления счетов и пропускной способности на основе PTU или на основе потребления. Стратегия оптимизации затрат, чтобы избежать отходов через неиспользуемую PTU, заключается в том, чтобы немного при подготовке экземпляра PTU, а также развернуть экземпляр на основе потребления вместе с ним. Цель этой топологии заключается в том, чтобы клиенты сначала потребляли все доступные PTU, а затем "всплеск" к развертыванию на основе потребления для избыточных ресурсов. Эта форма плановая отработка отказа преимущества от той же причины, что и в открывающем абзаце этого раздела: сохранение этой сложности из клиентского кода.

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

Советы по нескольким экземплярам в одном регионе и топологии подписки

• Убедитесь, что шлюз использует Retry-After сведения, доступные в ответе HTTP из Azure OpenAI, при поддержке сценариев отработки отказа на шлюзе. Используйте эти достоверные сведения для управления реализацией разбиения каналов. Не нажимайте на конечную точку, которая возвращает значение 429 Too Many Requests. Вместо этого разорвать канал для этого экземпляра модели.

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

• При циклического перебора или отработки отказа в другую конечную точку, включая разлив PTU в потребление, всегда убедитесь, что эти конечные точки используют ту же модель в той же версии. Например, не отработка отказа между ними не выполняется в gpt-4 gpt-35-turbo версию X или с версии X + 1 или балансировку нагрузки. Это изменение версии может привести к непредвиденному поведению клиентов.

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

• Разверните шлюз в том же регионе, что и экземпляр Azure OpenAI.

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

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

• Чтобы упростить логику в коде маршрутизации шлюза, используйте то же имя развертывания модели, чтобы свести к минимуму разницу между маршрутами HTTP. Например, имя gpt4-v1 модели можно использовать во всех экземплярах балансировки нагрузки или разлива, будь то на основе потребления или на основе PTU.

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

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

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

Несколько экземпляров Azure OpenAI в одном регионе в нескольких подписках

Сведения о топологии для нескольких экземпляров Azure OpenAI в одном регионе в нескольких подписках

• Развертывания модели Azure OpenAI: одна или несколько
• Экземпляры Azure OpenAI: несколько
• Подписки: несколько
• Регионы: один

Варианты использования топологии для нескольких экземпляров Azure OpenAI в одном регионе в нескольких подписках

Топология, которая включает несколько экземпляров Azure OpenAI в одном регионе в нескольких подписках, поддерживает следующие варианты использования:

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

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

Введение шлюза для нескольких экземпляров в одном регионе и нескольких подписках

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

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

Советы по нескольким экземплярам в одном регионе и топологии нескольких подписок

• В идеале подписки должны поддерживать согласованность в Azure RBAC и Политика Azure с одинаковым клиентом Microsoft Entra.

• Разверните шлюз в том же регионе, что и экземпляр Azure OpenAI.

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

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

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

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

Несколько экземпляров Azure OpenAI в нескольких регионах

Сведения о топологии для нескольких экземпляров Azure OpenAI в нескольких регионах

• Развертывания модели Azure OpenAI: несколько
• Экземпляры Azure OpenAI: несколько
• Подписки: одна или несколько
• Регионы: несколько

Варианты использования топологии для нескольких экземпляров Azure OpenAI в нескольких регионах

Топология, которая включает несколько экземпляров Azure OpenAI, распределенных по двум или нескольким регионам Azure, поддерживает следующие варианты использования:

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

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

• Включает структуру расположения данных и соответствия требованиям.

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

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

Введение шлюза для нескольких экземпляров в нескольких регионах

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

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

Использование Azure Управление API (развертывание в одном регионе)

В этой топологии azure Управление API используется специально для технологии шлюза. Здесь Управление API развертывается в одном регионе. В этом экземпляре шлюза выполняется балансировка нагрузки "активный— активный" между регионами. Политики в шлюзе ссылаются на все экземпляры Azure OpenAI. Шлюз требует сетевой линии видимости для каждой серверной части между регионами через пиринг между регионами или частные конечные точки виртуальной сети. Вызовы из этого шлюза в экземпляр Azure OpenAI в другом регионе вызывают большую задержку сети и расходы на исходящий трафик.

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

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

Активный пассивный вариант

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

Использование Azure Управление API (развертывание в нескольких регионах)

Чтобы повысить надежность предыдущей архитектуры azure Управление API, Управление API поддерживает развертывание экземпляра в нескольких регионах Azure. Этот вариант развертывания предоставляет один уровень управления через один экземпляр Управление API, но предоставляет реплицированные шлюзы в выбранных регионах. В этой топологии вы развертываете компоненты шлюза в каждом регионе, в котором содержатся экземпляры Azure OpenAI, обеспечивающие архитектуру шлюза active-active.

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

Управление API предлагает полную полную маршрутизацию доменных имен (FQDN) на основе минимальной задержки. Используйте эту встроенную функциональность на основе производительности для развертываний шлюза active-active. Эта встроенная функция помогает устранять производительность и обрабатывать сбой регионального шлюза. Встроенный глобальный маршрутизатор также поддерживает аварийное восстановление, так как регионы можно имитировать путем отключения отдельных шлюзов. Убедитесь, что клиенты уважают время жизни (TTL) в полное доменное имя и имеют соответствующую логику повторных попыток для обработки недавней отработки отказа DNS.

Если вам нужно ввести брандмауэр веб-приложения в эту архитектуру, вы по-прежнему можете использовать встроенное полное доменное имя в качестве внутреннего источника для глобального маршрутизатора, реализующего брандмауэр веб-приложения. Глобальный маршрутизатор делегировать отработку отказа Управление API. Кроме того, можно использовать полное доменное имя регионального шлюза в качестве членов внутреннего пула. В этой последней архитектуре используйте встроенную /status-0123456789abcdef конечную точку для каждого регионального шлюза или другой пользовательской конечной точки API работоспособности для поддержки региональной отработки отказа. Если не уверены, начните с подхода внутреннего полного доменного имени источника.

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

Если регион испытывает сбой шлюза Управление API или помечен как неработоспособный, остальные доступные регионы должны поглощать 100% трафика из этих других регионов. Это означает, что необходимо перенаправить экземпляры Azure OpenAI на основе PTU для обработки нового всплеска трафика или использовать активный пассивный подход для отработки отказа. Используйте калькулятор емкости Azure OpenAI для планирования емкости.

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

Активный-активный шлюз, а также вариант Azure OpenAI с активным пассивным

В предыдущем разделе рассматривается доступность шлюза путем предоставления топологии шлюза "активный— активный". Эта топология объединяет шлюз active-active с экономичной топологией Azure OpenAI с экономичной пассивной топологией Azure OpenAI. Добавление активной пассивной логики в шлюз для отработки отказа в развертывание Azure OpenAI на основе потребления из развертывания на основе PTU может значительно повысить надежность рабочей нагрузки. Эта модель по-прежнему позволяет клиентам использовать встроенное решение для маршрутизации на основе производительности Управление API полное доменное имя.

Использование настраиваемого закодированного шлюза

Если правила маршрутизации для каждого шлюза слишком сложны для вашей команды, чтобы считаться разумными как политики Управление API, необходимо развернуть собственное решение и управлять ими. Эта архитектура должна быть развертыванием шлюза с несколькими регионами с одной единицей масштабирования с высоким уровнем доступности для каждого региона. Эти развертывания необходимо настроить с помощью Azure Front Door (Anycast) или Диспетчер трафика Azure (DNS), как правило, с помощью маршрутизации на основе задержки и соответствующих проверок доступности шлюза.

Используйте Azure Front Door, если требуется брандмауэр веб-приложения и общедоступный доступ к Интернету. Используйте Диспетчер трафика, если вам не нужен брандмауэр веб-приложения, а TTL DNS достаточно. При входе в экземпляры шлюза с помощью Azure Front Door (или любого обратного прокси-сервера) убедитесь, что шлюз не может быть обходить. Сделайте экземпляры шлюза доступными только через частную конечную точку при использовании Azure Front Door и добавьте проверку заголовка X_AZURE_FDID HTTP в реализации шлюза.

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

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

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

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

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

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

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

Общие рекомендации

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

Взаимодействие с отслеживанием состояния

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

Проверки работоспособности шлюза

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

Если шлюз построен вокруг циклического перебора или строго выполняет отработку отказа службы, вы хотите принять экземпляр Azure OpenAI (или модель) из состояния доступности. Azure OpenAI не предоставляет конечную точку проверки работоспособности, чтобы заранее знать, доступна ли она для обработки запросов. Вы можете отправлять искусственные переходы, но это потребляет емкость модели. Если у вас нет другого надежного источника сигнала для экземпляра Azure OpenAI и доступности модели, скорее всего, шлюз должен предположить, что экземпляр Azure OpenAI находится в состоянии, а затем обрабатывает 429500503 коды состояния HTTP в качестве сигнала для канала для будущих запросов в этом экземпляре или модели в течение некоторого времени. Для регулирования всегда следует учитывать данные в заголовке, найденные в Retry-After ответах API OpenAI Azure для 429 кодов ответов в логике нарушения канала. Если вы используете Azure Управление API, оцените использование встроенной функции разбиения цепи.

Клиенты или ваша группа операций рабочей нагрузки могут потребовать проверки работоспособности шлюза для собственных целей маршрутизации или интроспекции. Если вы используете Управление API, то значение по умолчанию /status-0123456789abcdef может быть недостаточно подробным, так как оно в основном обращается к экземпляру шлюза Управление API, а не к серверным концам. Попробуйте добавить выделенный API проверки работоспособности, который может возвращать значимые данные клиентам или системам наблюдаемости в доступности шлюза или определенных маршрутов в шлюзе.

Методики безопасного развертывания

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

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

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

Достаточно реализации

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

Независимость данных

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

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

Авторизация Azure OpenAI

Шлюз должен пройти проверку подлинности со всеми экземплярами Azure OpenAI, с которыми он взаимодействует. Если шлюз не предназначен для сквозной проверки подлинности, шлюз должен использовать управляемое удостоверение для своих учетных данных. Поэтому каждому экземпляру Azure OpenAI необходимо настроить RBAC с минимальными привилегиями для управляемых удостоверений шлюзов. Для архитектур active-active и отработки отказа убедитесь, что удостоверение шлюза имеет эквивалентные разрешения для всех участвующих экземпляров Azure OpenAI.

Политика Azure

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

Избыточность шлюза

Хотя и не зависит от нескольких внутренних серверов, реализация шлюза каждого региона всегда должна создаваться с избыточностью и быть высокодоступной в единице масштабирования. Выберите регионы с зонами доступности и убедитесь, что шлюз распространяется по ним. Разверните несколько экземпляров шлюза, чтобы одна точка сбоя была ограничена полным региональным сбоем, а не ошибкой одного вычислительного экземпляра в шлюзе. Для Управление API разверните два или более единиц в двух или более зонах. Для реализации пользовательского кода разверните по крайней мере три экземпляра с лучшим распределением усилий между зонами доступности.

Реализации шлюза

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

Внедрение	Пример
Управление API Azure	Интеллектуальная балансировка нагрузки для Azure OpenAI с помощью Azure Управление API. Этот репозиторий GitHub содержит пример кода политики и инструкции по развертыванию в подписке. Масштабирование Azure OpenAI с помощью Azure Управление API. Этот репозиторий GitHub содержит пример кода политики и инструкции для PTU и разлива потребления. Набор средств шлюза GenAI содержит примеры политик Управление API вместе с настройкой нагрузочного тестирования для тестирования поведения политик.
Пользовательский код	Интеллектуальная балансировка нагрузки для Azure OpenAI с помощью приложений контейнеров Azure Этот репозиторий GitHub содержит пример кода C# и инструкции по сборке контейнера и развертыванию в подписке.

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

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

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

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

• Служба Azure OpenAI
• Шлюз API в службе "Управление API Azure"