Изменить

Поделиться через

Доступ к Azure OpenAI и другим языковым моделям через шлюз

Службы ИИ Azure
Служба Azure OpenAI
Cлужба управления Azure API

Служба Azure OpenAI предоставляет API-интерфейсы HTTP, которые позволяют приложениям выполнять внедрения или завершения с помощью языковых моделей OpenAI. Интеллектуальные приложения вызывают эти API-интерфейсы HTTP непосредственно от клиентов или оркестраторов. Примерами клиентов являются код пользовательского интерфейса чата и пользовательские конвейеры обработки данных. Примерами оркестраторов являются LangChain, семантический ядро и поток запроса Машинное обучение Azure. При подключении рабочей нагрузки к одному или нескольким экземплярам Azure OpenAI необходимо решить, подключаются ли эти потребители напрямую или через шлюз API обратного прокси-сервера.

Используйте это руководство, чтобы узнать о ключевых проблемах в пяти основных аспектах платформы Azure Well-Architected Framework , с которыми вы столкнулись, если проект рабочей нагрузки включает прямой доступ от потребителей к API плоскости данных Azure OpenAI. Затем узнайте, как внедрить шлюз в архитектуру, чтобы устранить эти проблемы прямого доступа, а также ввести новые проблемы. В этой статье описывается архитектурный шаблон, но не способ реализации шлюза.

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

Ключевые проблемы

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

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

Проблемы надежности

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

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

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

  • Балансировка нагрузки или регулирование. Api-интерфейсы Azure OpenAI сокращают запросы, возвращая код ответа на ошибку HTTP 429 для запросов, превышающих маркер за минуту (TPM) или Requests-Per-Minute (RPM) в модели оплаты по мере использования. API-интерфейсы Azure OpenAI также регулирования запросов, превышающих подготовленную емкость единиц пропускной способности (PTU) для предварительно подготовленной модели выставления счетов. Обработка соответствующей логики обратного отключения и повторных попыток остается исключительно для клиентских реализаций.

Проблемы безопасности

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

  • Управление удостоверениями — область проверки подлинности. API плоскости данных, предоставляемые Azure OpenAI, можно защитить одним из двух способов: ключ API или управление доступом на основе ролей Azure (RBAC). В обоих случаях проверка подлинности выполняется на уровне экземпляра Azure OpenAI, а не на уровне отдельного развертывания, что приводит к сложности для обеспечения минимального привилегированного доступа и сегментации удостоверений для определенных моделей развертывания.

  • Управление удостоверениями — поставщики удостоверений: клиенты, которые не могут использовать удостоверения, расположенные в клиенте Microsoft Entra, который поддерживает экземпляр Azure OpenAI, должен предоставить общий доступ к одному ключу API полного доступа. Ключи API имеют ограничения полезности безопасности и проблематичны, если задействовано несколько клиентов и все используют одно и то же удостоверение.

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

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

Проблемы оптимизации затрат

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

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

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

Проблемы с операционным превосходством

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

  • Контроль квоты: клиенты получают 429 кодов ответов непосредственно из Azure OpenAI при регулировании API HTTP. Операторы рабочей нагрузки отвечают за обеспечение доступности достаточной квоты для законного использования, и что неправильное поведение клиентов не потребляет лишний объем. Если рабочая нагрузка состоит из нескольких развертываний моделей, понимание использования квот и доступности квот может быть сложно визуализировать.

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

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

Проблемы с эффективностью производительности

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

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

  • Оптимизация производительности — соответствие клиентов: для совместного использования емкости клиентам необходимо хорошо вести себя. Примером этого является то, что клиенты гарантируют, что max_tokens и best_of заданы утвержденные значения. Без шлюза клиенты должны доверять клиентам в интересах сохранения емкости экземпляра Azure OpenAI.

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

Решение

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

Рис. 1. Концептуальная архитектура доступа к Azure OpenAI через шлюз

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

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

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

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

Надежность

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

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

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

Внимание

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

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

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

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

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

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

  • Шлюз может расширить область авторизации клиента и проверки подлинности за пределами идентификатора Microsoft Entra и проверки подлинности ключа API, а также потенциально для нескольких поставщиков удостоверений (IdP).

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

Внимание

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

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

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

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

Чтобы помочь управлять затратами при разработке и тестировании шлюза, рекомендуется использовать имитированную конечную точку для Azure OpenAI. Например, используйте решение в репозитории GitHub симулятора API Azure OpenAI.

Эффективность работы

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

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

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

  • Необходимо создать или расширить подход APIOps, чтобы охватывать API, предоставляемые в шлюзе.

Уровень производительности

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

  • Служба шлюза может привести к узким местам пропускной способности. Убедитесь, что шлюз имеет достаточную производительность для обработки полной параллельной нагрузки и может легко масштабироваться в соответствии с ожиданиями роста. Убедитесь, что эластичность в решении позволяет шлюзу уменьшить объем предложения или уменьшить масштаб, если спрос низкий, например с использованием рабочего дня.

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

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

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

Внимание

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

Варианты реализации

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

Использование Управления API Azure

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

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

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

Использование Azure Управление API для реализации шлюза обычно является предпочтительным подходом к созданию и работе шлюза Azure OpenAI. Это предпочтительнее, так как служба является платформой как услуга (PaaS) с расширенными встроенными возможностями, высоким уровнем доступности и сетевыми параметрами. Он также имеет надежные подходы APIOps для управления API завершения.

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

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

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

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

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

Пример архитектуры

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

Рис. 2. Пример архитектуры доступа к Azure OpenAI через шлюз на основе Управление API Azure

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

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

Узнайте, как реализовать ведение журнала и мониторинг моделей Azure OpenAI.