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

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

Microsoft Foundry предоставляет API HTTP, которые позволяют приложениям выполнять внедрение или завершение с помощью языковых моделей. Интеллектуальные приложения вызывают эти API-интерфейсы HTTP непосредственно от клиентов или оркестраторов. Примерами клиентов являются код пользовательского интерфейса чата и пользовательские конвейеры обработки данных. Примеры оркестраторов включают Microsoft Agent Framework, Semantic Kernel, LangChain и Foundry Agent Service. Когда рабочая нагрузка подключается к одному или нескольким ресурсам Foundry или экземплярам модели Foundry, необходимо решить, подключаются ли эти потребители напрямую или через шлюз API обратного прокси-сервера.

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

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

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

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

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

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

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

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

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

• Ограничение: API Foundry ограничивают количество запросов, возвращая код ответа об ошибке HTTP 429 для запросов, которые превышают лимиты токенов в минуту (TPM) или запросов в минуту (RPM) в стандартной модели. Интерфейсы Foundry API также ограничивают объём запросов, превышающих предварительно определенную ёмкость, для модели выставления счетов с предварительным выделением ресурсов. Реализация клиента отвечает исключительно за обработку соответствующей логики обратного отключения и повтора.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Решение

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

• Потенциал для реализации федеративной проверки подлинности.

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

• Межуровневый и кросс-модельный мониторинг.

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

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

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

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

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

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

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

Надежность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используйте Azure API Management

Foundry имеет встроенную интеграцию с Azure API Management в качестве шлюза ИИ. Вы можете использовать управление API, интегрированное с Foundry, или использовать управление API в качестве автономного шлюза.

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

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

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

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

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

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

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

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

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

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

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

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

• Балансировка нагрузки или переключение при отказе между несколькими экземплярами бекэнда
• Пользовательская проверка подлинности и авторизация для клиентских приложений
• Реализуйте логирование и мониторинг моделей Azure OpenAI

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

• шлюз API в Azure API Management
• Зона приземления API Management в репозитории GitHub, охватывающая сценарии генеративного ИИ
• набор средств управления шлюзом API Management
• Симулятор API OpenAI
• целевая зона шлюза центра HUB