Производительность и задержка

Статья
2025-04-01

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

Общие сведения о пропускной способности и задержке

Существует два ключевых понятия, о которых следует думать при изменении размера приложения: (1) Пропускная способность уровня системы, измеряемая в маркерах в минуту (TPM) и (2) время отклика на вызов (также называется задержкой).

Пропускная способность уровня системы

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

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

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

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

Оценка пропускной способности на уровне системы

Оценка транзакций в минуту с помощью метрик Azure Monitor

Одним из подходов к оценке пропускной способности на уровне системы для данной рабочей нагрузки является использование данных об использовании исторических маркеров. Для рабочих нагрузок Azure OpenAI все исторические данные об использовании можно получить и визуализировать с помощью собственных возможностей мониторинга, предлагаемых в Azure OpenAI. Для оценки пропускной способности системы для рабочих нагрузок Azure OpenAI требуются две метрики: (1) Обработанные токены запроса и (2) Сгенерированные токены завершения.

При объединении метрики обработанных маркеров запроса (входной TPM) и созданных маркеров завершения (выходной TPM) позволяют получить оценку пропускной способности на системном уровне, основанную на фактическом трафике рабочей нагрузки. Этот подход не учитывает преимущества кэширования запросов, поэтому оценка пропускной способности системы будет консервативной. Эти метрики можно анализировать с помощью минимального, среднего и максимального агрегирования в течение 1-минутных окон за несколько недель. Рекомендуется проанализировать эти данные в течение многонедельного горизонта времени, чтобы убедиться, что для оценки достаточно точек данных. На следующем снимке экрана показан пример метрики обработанных токенов запроса, визуализированной в Azure Monitor и доступной непосредственно через портал Azure.

Снимок экрана графика Azure Monitor, показывающего метрику обработанных токенов запроса, разделенной по модели и версии.

Оценивание TPM на основе данных запроса

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

{
  "body": {
    "id": "chatcmpl-7R1nGnsXO8n4oi9UPz2f3UHdgAYMn",
    "created": 1686676106,
    "choices": [...],
    "usage": {
      "completion_tokens": 557,
      "prompt_tokens": 33,
      "total_tokens": 590
    }
  }
}

Предполагая, что все запросы для данной рабочей нагрузки являются однородными, маркеры запроса и маркеры завершения из данных ответа API могут быть умножены на предполагаемое число запросов в минуту (RPM) для определения входных и выходных токенов в минуту (TPM) для данной рабочей нагрузки.

Использование оценки пропускной способности на уровне системы

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

Ниже приведены несколько примеров для мини-модели GPT-4o:

Размер запроса (токены)	Размер поколения (токен)	Число запросов в минуту	Входной TPM	Выходной TPM	Общий доверенный платформенный модуль	Требуемые PTUs
800	150	30	24,000	4 500	28,500	15
5,000	50	1,000	5 000 000	50,000	5,050,000	140
1,000	300	500	500,000	150 000	650,000	30

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

Задержка: время ответа на вызов

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

Оценка ожидаемой задержки для каждого вызова может быть сложной задачей с этими моделями. Задержка запроса на завершение может отличаться в зависимости от четырех основных факторов: (1) модель, (2) количество маркеров в запросе, (3) количество маркеров, созданных, и (4) общая нагрузка на развертывание и систему. Один и три часто являются основными факторами, влияющими на общее время. Следующий раздел содержит дополнительные сведения об анатомии вызова крупной языковой модели вывода.

Повышение производительности

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

выбор модели;

Задержка зависит от используемой модели. Для идентичного запроса можно ожидать, что у разных моделей будет разная задержка при завершении чата. Если для вашего варианта использования требуется наименьшая задержка моделей с самым быстрым временем отклика, мы рекомендуем последнюю модель GPT-4o mini.

Размер поколения и максимальное количество токенов

При отправке запроса на завершение в конечную точку Azure OpenAI входной текст преобразуется в маркеры, которые затем отправляются в развернутую модель. Модель получает входные маркеры, а затем начинает создавать ответ. Это итеративный последовательный процесс, один токен за раз. Другой способ представить себе это — как цикл for с n tokens = n iterations. Для большинства моделей создание ответа является самым медленным шагом процесса.

Во время запроса запрошенный размер генерации (параметр max_tokens) используется в качестве начальной оценки размера генерации. Время вычислений для создания полного размера зарезервировано моделью по мере обработки запроса. После завершения генерации оставшаяся квота освобождается. Способы уменьшения количества токенов:

Для каждого вызова задайте параметр max_tokens как можно меньшим.
Включите последовательности остановки, чтобы предотвратить создание дополнительного содержимого.
Создание меньшего количества ответов: параметры best_of и n могут значительно увеличить задержку, так как они создают несколько выходных данных. Для самого быстрого ответа не указывайте эти значения или не устанавливайте их значение 1.

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

Стриминг

Установка stream: true в запросе приводит к тому, что служба возвращает токены, как только они становятся доступны, вместо ожидания генерации полной последовательности токенов. Это не изменяет время получения всех маркеров, но сокращает время первого ответа. Такой подход обеспечивает лучший пользовательский интерфейс, так как конечные пользователи могут читать ответ по мере его создания.

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

Примеры использования потоковой передачи:

Боты чата и диалоговые интерфейсы.

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

Примеры, когда потоковая передача менее важна:

Анализ тональности, перевод языка, создание контента.

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

Фильтрация содержимого

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

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

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

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

Разделение рабочих нагрузок

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

Размер подсказки

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

Пакетная обработка

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

Как измерить пропускную способность

Рекомендуется измерять общую пропускную способность развертывания с помощью двух мер:

Вызовы в минуту: количество вызовов вывода API, которые вы делаете в минуту. Это можно измерить в Azure Monitor с помощью метрики запросов Azure OpenAI и сплитинга по имени ModelDeploymentName.
Общее количество токенов в минуту: общее количество токенов, обрабатываемых в минуту вашим развертыванием. Сюда входят подсказки и созданные токены. Это часто делится на измерение обоих аспектов для более глубокого понимания производительности развертывания. Это можно измерить в Azure Monitor с помощью метрики токенов обработанных выводов.

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

Как измерять задержку для каждого вызова

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