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

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

Замечание

Этот документ относится к порталу Microsoft Foundry (классическая модель).

🔄 Перейдите в новую документацию по Microsoft Foundry, если вы используете новый портал.

Замечание

Этот документ относится к порталу Microsoft Foundry (new).

Подсказка

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

Предложение Microsoft Foundry по подготовленной пропускной способности является типом развертывания модели, который позволяет указать, какую пропускную способность вы требуете при развертывании. Затем платформа выделяет необходимую емкость для обработки модели и гарантирует, что она готова для вашего использования. Вы можете использовать запрошенную подготовленную пропускную способность в разнообразном портфеле моделей, которые продаются непосредственно компанией Azure. Эти модели включают в себя модели Azure OpenAI и новые флагманские семейства моделей, такие как Azure DeepSeek, Azure Grok, Azure Llama и многое другое в модели Foundry.

Подготовленная пропускная способность обеспечивает:

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

Подсказка

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

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

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

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

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

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

Управление затратами при совместном резервировании PTU

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

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

  • Если вы используете оставшуюся 200 PTU для DeepSeek-R1, 200 PTU предоставляет скидку на резервирование автоматически, а общее использование резервирования составляет 500 PTU.

  • Если вы используете 300 PTU для DeepSeek-R1, то 200 PTU предоставляет скидку на резервирование автоматически, а 100 PTU превышает резервирование и взимается плата за почасовую ставку DeepSeek-R1.

Дополнительные сведения о экономии затрат на резервирование PTU см. в статье "Экономия затрат с помощью резервирования подготовленной пропускной способности Microsoft Foundry".

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

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

При создании подготовленного развертывания в Foundry с помощью интерфейса командной строки или API sku-name можно задать значение GlobalProvisionedManaged, DataZoneProvisionedManaged или ProvisionedManaged в зависимости от необходимости обработки данных для данной рабочей нагрузки.

Тип развертывания sku-name в CLI
Глобальная подготовленная пропускная способность GlobalProvisionedManaged
Выделенная пропускная способность зоны данных DataZoneProvisionedManaged
Региональная подготовленная пропускная способность ПредоставленоУправляемый

Чтобы адаптировать следующую команду Azure CLI к другому типу развертывания, обновите sku-name параметр, чтобы он соответствовал типу развертывания, который требуется развернуть.

az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group  <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4o \
--model-version 2024-08-06  \
--model-format OpenAI \
--sku-capacity 15 \
--sku-name GlobalProvisionedManaged

Прозрачность возможностей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. Когда запрос делается:

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

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

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

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

    б. Если фактическое < больше (или) меньше оценки, то разница вычитается.

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

Замечание

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

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

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

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

Подготовленная пропускная способность для моделей, проданных непосредственно в Azure

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

Ниже приведены некоторые важные выводы из таблицы:

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

  • Вариант развертывания подготовленной пропускной способности региона зависит от региона.

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

  • PTU управляется по регионам и по типу предложения. Квота PTU и любые резервирования должны находиться в области и формате (Глобальный, Зона данных, Регион), которые вы хотите использовать.

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

Семейство моделей Имя модели Глобально обеспеченный Подготовленная зона данных Региональные подготовленные Функция разлива
Azure OpenAI Gpt 5 ✅ ✅ ✅
GPT 4.1 ✅ ✅ ✅ ✅
Gpt 4.1 mini ✅ ✅ ✅ ✅
Gpt 4.1 nano ✅ ✅ ✅ ✅
GPT-4.0 ✅ ✅ ✅ ✅
Gpt 4o mini ✅ ✅ ✅ ✅
Gpt 3.5 Turbo ✅ ✅ ✅ ✅
o1 ✅ ✅ ✅ ✅
O3 mini ✅ ✅ ✅ ✅
O4 mini ✅ ✅ ✅ ✅
Azure DeepSeek DeepSeek-R1 ✅
DeepSeek-V3-0324 ✅
DeepSeek-R1-0528 ✅

Доступность региона для подготовленной пропускной способности

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

Регион gpt-5, 2025-08-07 gpt-5-mini, 2025-08-07 o3, 2025-04-16 o4-mini, 2025-04-16 gpt-4.1, 2025-04-14 gpt-4.1-nano, 2025-04-14 gpt-4.1-mini, 2025-04-14 o3-mini, 2025-01-31 o1, 2024-12-17 gpt-4o, 2024-05-13 gpt-4o, 2024-08-06 gpt-4o, 2024-11-20 gpt-4o-mini, 2024-07-18
австралиявосток ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Бразильский Юг ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Центральная Канада ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Канада Восток ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Центральус ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Истус ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus2 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
francecentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Германия-запад-центр ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
северная италия ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
japaneast ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
koreacentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
northcentralus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Норвегия Восток ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Польша Центральная ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Южная Африка-север ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
СаутЦентралус ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Юго-Восточная Азия ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Южная Индия ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
spaincentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
SwedenCentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Швейцария север ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
швейцариязапад ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
уаенорт ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
UKSOUTH ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Западная Европа ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Вестус ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus3 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

Замечание

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

Связанный контент

  • Last updated on