Что такое выделенная пропускная способность для моделей Foundry?

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

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

Предпосылки

• Подписка Azure. Создайте его бесплатно.
• Проект Microsoft Foundry с моделью, развернутой с использованием типа развертывания с предусмотренной пропускной способностью.
• Установленная квота пропускной способности, выделенная для вашей подписки в целевом регионе.
• Azure CLI (если планируется создать развертывания с помощью командной строки).

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

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

Общие сведения о выделении PTU

Подготовленные единицы пропускной способности (PTU) и типы развертывания — это стандартные блоки подготовленной пропускной способности. В следующих разделах объясняется, как они работают.

Выделенные единицы пропускной способности (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 в зависимости от необходимости обработки данных для данной рабочей нагрузки.

Чтобы адаптировать следующую команду 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 %.

Обработка ответов HTTP 429

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

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

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

Оценка запросов на основе уровня использования ресурсов

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

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

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

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

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

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

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

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

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

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

Ограничения одновременных вызовов

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

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

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

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

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

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

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

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

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

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

• Узнайте о шагах ввода для предусмотренных развертываний
• Руководство по началу работы с подготовленными единицами пропускной способности (PTU)
• Общие сведения о типах развертывания
• Управление трафиком с помощью резервирования для специально выделенных развертываний
• Мониторинг моделей Azure OpenAI
• Управление квотой для Azure OpenAI
• Экономия затрат с помощью резервирования подготовленной пропускной способности Microsoft Foundry