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


Что такое подготовленная пропускная способность?

Примечание.

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

Возможность подготовленной пропускной способности позволяет указать объем пропускной способности, которую требуется в развертывании. Затем служба выделяет необходимую емкость обработки модели и гарантирует, что она готова к работе. Пропускная способность определяется с точки зрения подготовленных единиц пропускной способности (PTU), который является нормализованным способом представления пропускной способности для развертывания. Каждая пара версий модели требует разных объемов PTU для развертывания и предоставления разных объемов пропускной способности на PTU.

Что предоставляют подготовленные и глобальные типы развертывания?

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

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

Что получится?

Раздел Подготовлено
Что это такое? Обеспечивает гарантированную пропускную способность с меньшим шагом, чем существующее подготовленное предложение. Развертывания имеют согласованную максимальную задержку для заданной версии модели.
Кто может использовать это средство? Клиенты, которые хотят гарантированной пропускной способности с минимальной задержкой.
Квота Подготовленная единица управляемой пропускной способности или глобальная подготовленная единица пропускной способности, назначенная для каждого региона. Квоту можно использовать в любой доступной модели Azure OpenAI.
Задержка Максимальная задержка ограничена моделью. Общая задержка — это фактор фигуры вызова.
Загруженность Подготовленная управляемая мера использования версии 2, предоставляемая в Azure Monitor.
Оценка размера Предоставленный калькулятор в скрипте студии и тестирования.
Кэширование запросов Для поддерживаемых моделей мы скидываем до 100 % кэшированных маркеров ввода.

Сколько пропускной способности на PTU вы получаете для каждой модели

Объем пропускной способности (маркеры в минуту или TPM) для каждого PTU — это функция маркеров ввода и вывода в минуту. Для создания выходных маркеров требуется больше обработки, чем входные маркеры, поэтому больше выходных маркеров создало более низкий общий TPM. Служба динамически балансирует затраты на входные и выходные данные, поэтому пользователям не нужно устанавливать определенные ограничения входных и выходных данных. Такой подход означает, что развертывание устойчиво к колебаниям в форме рабочей нагрузки.

Чтобы упростить усилия по размеру, в следующей таблице описывается TPM для каждого PTU gpt-4o и gpt-4o-mini моделей, представляющих максимальное количество трафика— входные или выходные данные. В таблице также показаны значения целевой цели задержки на уровне обслуживания (SLA) для каждой модели. Дополнительные сведения о соглашении об уровне обслуживания для службы Azure OpenAI см. на странице [Соглашения об уровне обслуживания( соглашения об уровне обслуживания) для веб-служб]. (https://www.microsoft.com/licensing/docs/view/Service-Level-Agreements-SLA-for-Online-Services?lang=1)

gpt-4o, 2024-05-13 & gpt-4o, 2024-08-06 gpt-4o-mini, 2024-07-18
Развертываемые добавочные значения 50 25
Максимальное число входных TPM на PTU 2500 37 000
Максимальное число выходных TPM на PTU 833 12,333
Целевое значение задержки 25 токенов в секунду* 33 токена в секунду*

Полный список см. в калькуляторе AOAI Studio.

Основные понятия

Типы развертывания

При создании подготовленного развертывания в Azure OpenAI Studio тип развертывания в диалоговом окне "Создание развертывания" выполняется управляемая подготовка. При создании глобально подготовленного управляемого развертывания в Azure Open Studio тип развертывания в диалоговом окне "Создание развертывания" является глобальным управляемым.

При создании подготовленного развертывания в Azure OpenAI с помощью интерфейса командной строки или API необходимо задать значение sku-name ProvisionedManaged. При создании глобально подготовленного развертывания в Azure OpenAI с помощью ИНТЕРФЕЙСА командной строки или API необходимо задать значение sku-name GlobalProvisionedManaged. Указывает sku-capacity количество ПТП, назначенных развертыванию.

az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group  <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4 \
--model-version 0613  \
--model-format OpenAI \
--sku-capacity 100 \
--sku-name ProvisionedManaged 

Квота

Подготовленные единицы пропускной способности

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

Независимая квота модели

В отличие от квоты токенов в минуту (TPM), используемой другими предложениями Azure OpenAI, PTUS являются независимыми от модели. PTUs можно использовать для развертывания любой поддерживаемой модели или версии в регионе.

Схема независимой квоты модели с одним пулом ПТУ, доступным для нескольких моделей Azure OpenAI.

Для подготовленных развертываний новая квота отображается в Azure OpenAI Studio в качестве элемента квоты с именем подготовленной управляемой пропускной способности. Для глобальных подготовленных управляемых развертываний новая квота отображается в Azure OpenAI Studio в качестве элемента квоты с именем Global Provisioned Managed Пропускная способность. В области квот Студии разверните элемент квоты, в которых показаны развертывания, которые способствуют использованию каждой квоты.

Снимок экрана: пользовательский интерфейс квоты для подготовленного Azure OpenAI.

Получение квоты PTU

Квота PTU доступна по умолчанию во многих регионах. Если требуется дополнительная квота, клиенты могут запрашивать квоту по ссылке "Квота запроса". Эту ссылку можно найти справа от вкладки "Подготовленная управляемая пропускная способность" или "Глобальная подготовленная управляемая единица пропускной способности" в Azure OpenAI Studio. Форма позволяет клиенту запрашивать увеличение указанной квоты PTU для заданного региона. Клиент получает сообщение электронной почты по указанному адресу после утверждения запроса, как правило, в течение двух рабочих дней.

Минимальные значения PTU для каждой модели

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

Прозрачность емкости

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

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

Руководство по региональной емкости

Чтобы найти емкость, необходимую для их развертываний, используйте API емкости или интерфейс развертывания Studio для предоставления сведений о доступности емкости в режиме реального времени.

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

Дополнительные сведения о новом интерфейсе развертывания см. в руководстве по началу работы с Azure OpenAI.

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

Если приемлемый регион недоступен для поддержки требуемой модели, версии и /или PTUS, клиенты также могут выполнить следующие действия:

  • Попробуйте выполнить развертывание с меньшим количеством ПТП.
  • Попробуйте выполнить развертывание в другое время. Доступность емкости динамически изменяется в зависимости от спроса клиента и больше емкости может стать доступной позже.
  • Убедитесь, что квота доступна во всех допустимых регионах. Интерфейс API емкостей модели и Студии рассматривают доступность квот при возврате альтернативных регионов для создания развертывания.

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

PTUs представляет объем емкости обработки модели. Как и в случае с компьютером или базами данных, различные рабочие нагрузки или запросы к модели будут использовать разные объемы базовой емкости обработки. Преобразование из характеристик фигуры вызова (размер запроса, размер создания и частота вызовов) в PTUs является сложным и нелинейным. Чтобы упростить этот процесс, можно использовать калькулятор емкости Azure OpenAI для размера определенных фигур рабочей нагрузки.

Несколько общих рекомендаций.

  • Поколения требуют больше емкости, чем запросы
  • Для моделей GPT-4o и более поздних версий TPM для каждого PTU устанавливается для маркеров ввода и вывода отдельно. Для более старых моделей более крупные вызовы постепенно дороже вычислений. Например, 100 вызовов с размером запроса на 1000 маркеров требуют меньше емкости, чем один вызов с 100 000 маркерами в запросе. Это означает, что распределение этих фигур вызова важно в общей пропускной способности. Шаблоны трафика с широким распределением, включающее некоторые крупные вызовы, могут столкнуться с более низкой пропускной способностью на PTU, чем более узким распределением с одинаковыми средними размерами запросов и маркеров завершения.

Как работает производительность использования

Подготовленные и глобальные подготовленные развертывания предоставляют выделенный объем емкости обработки модели для выполнения данной модели.

При превышении емкости API возвращает ошибку состояния HTTP 429 в управляемых и глобальных развертываниях. Этот быстрый ответ позволяет пользователю принимать решения о том, как управлять трафиком. Пользователи могут перенаправить запросы к отдельному развертыванию, в стандартный экземпляр с оплатой по мере использования или использовать стратегию повторных попыток для управления заданным запросом. Служба продолжает возвращать код состояния HTTP 429 до тех пор, пока использование не падает ниже 100 %.

Как отслеживать емкость?

Метрика подготовленного управляемого использования версии 2 в Azure Monitor измеряет заданное использование развертываний на 1 минуту. Подготовленные управляемые и глобальные развертывания, управляемые глобальной подготовкой, оптимизированы, чтобы обеспечить обработку принятых вызовов с помощью конзиса режим палатки l (фактическая задержка зависит от характеристик вызова).

Что делать, когда я получаю ответ 429?

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

retry-after Заголовки retry-after-ms в ответе сообщают вам время ожидания до принятия следующего вызова. Способ обработки этого ответа зависит от требований приложения. Ниже приведены некоторые рекомендации.

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

Как служба решает, когда отправлять 429?

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

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

  1. Каждый клиент имеет набор емкости, которую они могут использовать в развертывании

  2. При выполнении запроса:

    a. Если текущее использование превышает 100 %, служба возвращает код 429 с retry-after-ms заголовком, заданным для времени, пока использование не превышает 100 %

    b. В противном случае служба оценивает добавочное изменение использования, необходимое для обслуживания запроса путем объединения маркеров запроса и указанного max_tokens в вызове. Для запросов, включающих не менее 1024 кэшированных маркеров, кэшированные маркеры вычитаются из значения токена запроса. Клиент может получить до 100% скидки на маркеры запроса в зависимости от размера кэшированных маркеров. max_tokens Если параметр не указан, служба оценивает значение. Эта оценка может привести к снижению параллелизма, чем ожидалось, если количество фактически созданных маркеров невелико. Для максимальной параллелизма убедитесь, что max_tokens значение максимально близко к размеру истинного поколения.

  3. Когда запрос завершится, теперь мы знаем фактическую стоимость вычислений для вызова. Чтобы обеспечить точный учет, мы исправим использование с помощью следующей логики:

    a. Если фактический > расчет, то разница добавляется в использование развертывания.

    b. Если фактическая < оценка, то разница вычитается.

  4. Общее использование уменьшается на непрерывной скорости на основе числа развернутых PTUS.

Примечание.

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

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

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

Количество одновременных вызовов зависит от фигуры каждого вызова (размер запроса, max_token параметр и т. д.). Служба продолжает принимать вызовы до тех пор, пока использование не достигнет 100 %. Чтобы определить приблизительное количество одновременных вызовов, можно моделировать максимальные запросы в минуту для определенной фигуры вызова в калькуляторе емкости. Если система создает меньше количества маркеров выборки, таких как max_token, оно будет принимать больше запросов.

Какие модели и регионы доступны для подготовленной пропускной способности?

Регион gpt-4o, 2024-05-13 gpt-4o, 2024-08-06 gpt-4o-mini, 2024-07-18 gpt-4, 0613 gpt-4, 1106-Preview gpt-4, 0125-Preview gpt-4, turbo-2024-04-09 gpt-4-32k, 0613 gpt-35-turbo, 1106 gpt-35-turbo, 0125
australiaeast
brazilsouth - - -
canadacentral - - - - - - -
canadaeast - - - -
eastus
eastus2
francecentral - -
germanywestcentral - - -
japaneast - - -
koreacentral - - -
northcentralus
norwayeast - - - - -
польшацентральная - -
southafricanorth - - - -
southcentralus - -
southindia - -
swedencentral
switzerlandnorth
switzerlandwest - - - - - - - - -
uaenorth - - - - - -
uksouth
westus
westus3 -

Примечание.

Подготовленная версия версии gpt-4 : turbo-2024-04-09 в настоящее время ограничена только текстом.

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