Реализация расширенного мониторинга для Azure OpenAI в модели Foundry через шлюз

Службы ИИ Azure

Служба Azure OpenAI

Управление API Azure

Microsoft Entra ID

Azure Monitor

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

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

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

• Мониторинг в режиме, близком к реальному времени.

Замечание

Дополнительные сведения о непосредственном мониторинге Azure OpenAI см. в статье Мониторинг Azure OpenAI.

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

Схема, на которой показаны два клиента с метками A и B, напрямую взаимодействующие с развертываниями моделей в двух экземплярах Azure OpenAI. Клиент А напрямую обращается к развертыванию gpt-35-turbo и развертыванию gpt-4-o в одном экземпляре Azure OpenAI. Клиент B получает доступ к развертыванию gpt-4o в первом экземпляре Azure OpenAI и обращается к развертыванию gpt-4 во втором экземпляре Azure OpenAI. Клиент B также показывает пунктирную линию, которая подключается к экземпляру gpt-4o во втором развертывании Azure OpenAI. Оба экземпляра Azure OpenAI передают метрики и журналы Azure OpenAI в Azure Monitor.

Отслеживание использования модели

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

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

• Бюджет и прогноз на будущее использование.

• Привязка стоимости и использования модального режима к производительности модели.

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

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

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

Введение шлюза для отслеживания использования модели

Схема с двумя клиентами, помеченными как A и B, напрямую взаимодействуют с шлюзом. Шлюз имеет две стрелки, указывающие на частные конечные точки. Первая частная конечная точка имеет две твердые стрелки, указывающие на развертывание gpt-35-turbo и развертывание gpt-4o в развертывании Azure OpenAI. Вторая частная конечная точка имеет сплошную стрелку, указывающую на развертывание gpt-4, и пунктирную линию, указывающую на развертывание gpt-4o во втором экземпляре Azure OpenAI. Оба экземпляра Azure OpenAI передают метрики и журналы Azure OpenAI в Azure Monitor. У шлюза есть стрелка, указывающая на Azure Monitor, которая показывает передачу метрик использования, включая IP-адрес клиента, модель и данные маркеров.

Внедрите шлюз в эту топологию для захвата полного IP-адреса клиента, идентификатора Microsoft Entra (или альтернативного удостоверения) клиента или пользовательского идентификатора бизнес-единицы, клиента или приложения в одном месте. Затем эти данные можно использовать для реализации решения по возврату платежей для бюджетирования и прогнозирования, а также для выполнения анализа затрат и выгод моделей.

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

Пример запроса для мониторинга использования

ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend modelkey = substring(parse_json(BackendResponseBody)['model'], 0, indexof(parse_json(BackendResponseBody)['model'], '-', 0, -1, 2))
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend completiontokens = parse_json(parse_json(BackendResponseBody)['usage'])['completion_tokens']
| extend totaltokens = parse_json(parse_json(BackendResponseBody)['usage'])['total_tokens']
| extend ip = CallerIpAddress
| summarize
    sum(todecimal(prompttokens)),
    sum(todecimal(completiontokens)),
    sum(todecimal(totaltokens)),
    avg(todecimal(totaltokens))
    by ip, model

Выходные данные:

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

Пример запроса для мониторинга использования запросов

ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend prompttext = substring(parse_json(parse_json(BackendResponseBody)['choices'])[0], 0, 100)

Выходные данные:

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

Входные и выходные данные модели аудита

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

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

• Обнаружение угроз: Анализируйте входные данные для выявления и устранения потенциальных рисков безопасности.

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

• Производительность модели: Объедините их с выходными данными модели для оценки производительности по таким показателям, как обоснованность и релевантность. Эти сведения можно использовать для устранения проблем с производительностью модели или подсказок.

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

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

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

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

• Производительность модели: Объедините с входными данными модели для оценки производительности по таким показателям, как обоснованность и релевантность. Эти сведения можно использовать для устранения проблем с производительностью модели или подсказок.

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

• Ограничения ведения журнала модели: Некоторые службы, такие как Azure OpenAI, не регистрируют входные и выходные данные модели.

• Тайник: Более сложные архитектуры могут обслуживать ответы из кэша. В таких сценариях модель не вызывается и не регистрирует входные или выходные данные.

• Разговоры с состоянием: Состояние диалога с несколькими взаимодействиями может храниться за пределами модели. Модель не знает, какие взаимодействия должны быть сопоставлены как беседа.

• Многомодельная архитектура: Уровень оркестрации может динамически вызывать несколько моделей для создания окончательного ответа.

Введение шлюза для аудита входных и выходных данных модели

Схема с двумя клиентами, помеченными как A и B, напрямую взаимодействуют с шлюзом. Шлюз имеет две стрелки, указывающие на частные конечные точки. Первая частная конечная точка имеет две твердые стрелки, указывающие на развертывание gpt-35-turbo и развертывание gpt-4o в развертывании Azure OpenAI. Вторая частная конечная точка имеет сплошную стрелку, указывающую на развертывание gpt-4, и пунктирную линию, указывающую на развертывание gpt-4o во втором экземпляре Azure OpenAI. Оба экземпляра Azure OpenAI отображаются, передавая метрики и журналы Azure OpenAI в Azure Monitor. Шлюз имеет стрелку, указывающую на Azure Monitor, которая показывает, как он передает входные и выходные данные.

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

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

Мониторинг входных и выходных данных на шлюзе позволяет применять правила аудита равномерно во всех моделях.

Мониторинг практически в режиме реального времени

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

Схема с двумя клиентами, помеченными как A и B, напрямую взаимодействуют с шлюзом. Шлюз имеет две стрелки, указывающие на частные конечные точки. Первая частная конечная точка имеет две твердые стрелки, указывающие на развертывание gpt-35-turbo и развертывание gpt-4o в развертывании Azure OpenAI. Вторая частная конечная точка имеет сплошную стрелку, указывающую на развертывание gpt-4, и пунктирную линию, указывающую на развертывание gpt-4o во втором экземпляре Azure OpenAI. Оба экземпляра Azure OpenAI отображаются, передавая метрики и журналы Azure OpenAI в Azure Monitor. Шлюз имеет стрелку, указывающую на Azure Monitor, которая показывает, как он передает входные и выходные данные. У шлюза есть еще одна стрелка, указывающая на шину сообщений. Шина сообщений имеет стрелки, указывающие на хранилище BLOB-объектов и потоковый процессор.

Рекомендации по внедрению шлюза для мониторинга

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

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

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

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

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

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

Дальнейшие действия

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

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

• проектирование хорошо спроектированной рабочей нагрузки ИИ
• Шлюз API в Управлении API

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

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

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

• Мониторинг в режиме, близком к реальному времени.

Замечание

Дополнительные сведения о непосредственном мониторинге Azure OpenAI см. в статье Мониторинг Azure OpenAI.

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

Схема, на которой показаны два клиента с метками A и B, напрямую взаимодействующие с развертываниями моделей в двух экземплярах Azure OpenAI. Клиент А напрямую обращается к развертыванию gpt-35-turbo и развертыванию gpt-4-o в одном экземпляре Azure OpenAI. Клиент B получает доступ к развертыванию gpt-4o в первом экземпляре Azure OpenAI и обращается к развертыванию gpt-4 во втором экземпляре Azure OpenAI. Клиент B также показывает пунктирную линию, которая подключается к экземпляру gpt-4o во втором развертывании Azure OpenAI. Оба экземпляра Azure OpenAI передают метрики и журналы Azure OpenAI в Azure Monitor.

Отслеживание использования модели

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

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

• Бюджет и прогноз на будущее использование.

• Привязка стоимости и использования модального режима к производительности модели.

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

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

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

Введение шлюза для отслеживания использования модели

Схема с двумя клиентами, помеченными как A и B, напрямую взаимодействуют с шлюзом. Шлюз имеет две стрелки, указывающие на частные конечные точки. Первая частная конечная точка имеет две твердые стрелки, указывающие на развертывание gpt-35-turbo и развертывание gpt-4o в развертывании Azure OpenAI. Вторая частная конечная точка имеет сплошную стрелку, указывающую на развертывание gpt-4, и пунктирную линию, указывающую на развертывание gpt-4o во втором экземпляре Azure OpenAI. Оба экземпляра Azure OpenAI передают метрики и журналы Azure OpenAI в Azure Monitor. У шлюза есть стрелка, указывающая на Azure Monitor, которая показывает передачу метрик использования, включая IP-адрес клиента, модель и данные маркеров.

Внедрите шлюз в эту топологию для захвата полного IP-адреса клиента, идентификатора Microsoft Entra (или альтернативного удостоверения) клиента или пользовательского идентификатора бизнес-единицы, клиента или приложения в одном месте. Затем эти данные можно использовать для реализации решения по возврату платежей для бюджетирования и прогнозирования, а также для выполнения анализа затрат и выгод моделей.

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

Пример запроса для мониторинга использования

ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend modelkey = substring(parse_json(BackendResponseBody)['model'], 0, indexof(parse_json(BackendResponseBody)['model'], '-', 0, -1, 2))
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend completiontokens = parse_json(parse_json(BackendResponseBody)['usage'])['completion_tokens']
| extend totaltokens = parse_json(parse_json(BackendResponseBody)['usage'])['total_tokens']
| extend ip = CallerIpAddress
| summarize
    sum(todecimal(prompttokens)),
    sum(todecimal(completiontokens)),
    sum(todecimal(totaltokens)),
    avg(todecimal(totaltokens))
    by ip, model

Выходные данные:

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

Пример запроса для мониторинга использования запросов

ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend prompttext = substring(parse_json(parse_json(BackendResponseBody)['choices'])[0], 0, 100)

Выходные данные:

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

Входные и выходные данные модели аудита

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

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

• Обнаружение угроз: Анализируйте входные данные для выявления и устранения потенциальных рисков безопасности.

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

• Производительность модели: Объедините их с выходными данными модели для оценки производительности по таким показателям, как обоснованность и релевантность. Эти сведения можно использовать для устранения проблем с производительностью модели или подсказок.

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

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

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

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

• Производительность модели: Объедините с входными данными модели для оценки производительности по таким показателям, как обоснованность и релевантность. Эти сведения можно использовать для устранения проблем с производительностью модели или подсказок.

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

• Ограничения ведения журнала модели: Некоторые службы, такие как Azure OpenAI, не регистрируют входные и выходные данные модели.

• Тайник: Более сложные архитектуры могут обслуживать ответы из кэша. В таких сценариях модель не вызывается и не регистрирует входные или выходные данные.

• Разговоры с состоянием: Состояние диалога с несколькими взаимодействиями может храниться за пределами модели. Модель не знает, какие взаимодействия должны быть сопоставлены как беседа.

• Многомодельная архитектура: Уровень оркестрации может динамически вызывать несколько моделей для создания окончательного ответа.

Введение шлюза для аудита входных и выходных данных модели

Схема с двумя клиентами, помеченными как A и B, напрямую взаимодействуют с шлюзом. Шлюз имеет две стрелки, указывающие на частные конечные точки. Первая частная конечная точка имеет две твердые стрелки, указывающие на развертывание gpt-35-turbo и развертывание gpt-4o в развертывании Azure OpenAI. Вторая частная конечная точка имеет сплошную стрелку, указывающую на развертывание gpt-4, и пунктирную линию, указывающую на развертывание gpt-4o во втором экземпляре Azure OpenAI. Оба экземпляра Azure OpenAI отображаются, передавая метрики и журналы Azure OpenAI в Azure Monitor. Шлюз имеет стрелку, указывающую на Azure Monitor, которая показывает, как он передает входные и выходные данные.

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

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

Мониторинг входных и выходных данных на шлюзе позволяет применять правила аудита равномерно во всех моделях.

Мониторинг практически в режиме реального времени

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

Схема с двумя клиентами, помеченными как A и B, напрямую взаимодействуют с шлюзом. Шлюз имеет две стрелки, указывающие на частные конечные точки. Первая частная конечная точка имеет две твердые стрелки, указывающие на развертывание gpt-35-turbo и развертывание gpt-4o в развертывании Azure OpenAI. Вторая частная конечная точка имеет сплошную стрелку, указывающую на развертывание gpt-4, и пунктирную линию, указывающую на развертывание gpt-4o во втором экземпляре Azure OpenAI. Оба экземпляра Azure OpenAI отображаются, передавая метрики и журналы Azure OpenAI в Azure Monitor. Шлюз имеет стрелку, указывающую на Azure Monitor, которая показывает, как он передает входные и выходные данные. У шлюза есть еще одна стрелка, указывающая на шину сообщений. Шина сообщений имеет стрелки, указывающие на хранилище BLOB-объектов и потоковый процессор.

Рекомендации по внедрению шлюза для мониторинга

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

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

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

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

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

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

Дальнейшие действия

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

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

• проектирование хорошо спроектированной рабочей нагрузки ИИ
• Шлюз API в Управлении API