¿Qué es el rendimiento provisionado para los modelos de Foundry? (clásico)

Visualización actual:Versión - Cambio a la versión del nuevo portal de Foundry

La oferta de rendimiento aprovisionado de Microsoft Foundry es un tipo de implementación de modelo que le permite especificar la cantidad de rendimiento que necesita en una implementación de modelos. A continuación, Foundry asigna la capacidad de procesamiento del modelo necesaria y garantiza que está listo para usted. Use el rendimiento aprovisionado que solicitó en una amplia cartera de modelos que se venden directamente mediante Azure. Estos modelos incluyen los modelos OpenAI de Azure y las familias de modelos emblemáticos recién introducidas, como Azure DeepSeek en los Foundry Models, con más familias de modelos incorporadas a lo largo del tiempo.

La capacidad de procesamiento aprovisionada proporciona:

Requisitos previos

• Una suscripción Azure. Cree uno gratis.
• Un proyecto Microsoft Foundry con un modelo implementado mediante un tipo de implementación con rendimiento aprovisionado.
• Cuota del rendimiento provisionado asignada a su suscripción en su región de destino.
• CLI de Azure (si tiene previsto crear implementaciones a través de la línea de comandos).

Cuándo usar el rendimiento aprovisionado

Considere la posibilidad de implementar el rendimiento aprovisionado cuando tenga requisitos de rendimiento y latencia bien definidos y predecibles, normalmente para aplicaciones de producción con patrones de tráfico conocidos. El rendimiento aprovisionado también es útil para aplicaciones en tiempo real o sensibles a la latencia.

Descripción de la asignación de PTU

Las unidades de rendimiento aprovisionadas (PTU) y los tipos de implementación son los bloques de creación del rendimiento aprovisionado. En las secciones siguientes se explica cómo funcionan.

Unidades de rendimiento aprovisionadas (PTU)

Las unidades de rendimiento aprovisionadas (PTU) son unidades genéricas de capacidad de procesamiento de modelos que se usan para dimensionar las implementaciones aprovisionadas y lograr el rendimiento requerido para el procesamiento de indicaciones y generar resultados. Las unidades de rendimiento aprovisionadas se conceden a una suscripción como cuota y se usan para definir los costos. Cada cuota es específica de una región y define el número máximo de PTU que se pueden asignar a las implementaciones de esa suscripción y región.

Administración de costos en reserva de PTU compartida

Utilice la capacidad de PTU para administrar sin problemas los costos de los modelos de fundición bajo una reserva de PTU compartida. Sin embargo, las unidades de PTU necesarias para el despliegue y el rendimiento se adaptan dinámicamente a los modelos elegidos. Para más información sobre los costos de PTU y los puntos de latencia del modelo, consulte Descripción de los costos asociados a PTU.

Las reservas de PTU existentes se actualizan automáticamente para capacitar a los clientes con una mayor eficiencia y ahorro de costos a medida que implementan modelos de Foundry. Por ejemplo, suponga que tiene una reserva de PTU existente con 500 PTU adquiridos. Use 300 unidades para modelos de Azure OpenAI y elija también utilizar PTU para implementar Azure DeepSeek, Azure Llama u otros modelos con funcionalidad PTU en Foundry Models.

• Si usa los 200 PTU restantes para DeepSeek-R1, los 200 PTU comparten automáticamente el descuento de reserva, y su uso total para la reserva es de 500 PTU.

• Si usa 300 PTU para DeepSeek-R1, 200 PTU comparte automáticamente el descuento por reserva mientras que 100 PTU superan la reserva y se cobran con la tarifa por hora de DeepSeek-R1.

Para obtener información sobre cómo ahorrar costos con reservas de PTU, consulte Ahorrar costos con las Reservas de rendimiento aprovisionado de Foundry de Microsoft.

Tipos de implementación

Al crear una implementación aprovisionada en Foundry, el tipo de implementación del cuadro de diálogo Crear implementación se puede establecer en el rendimiento aprovisionado global, el rendimiento aprovisionado de zona de datos o el tipo de implementación rendimiento aprovisionado regional en función de las necesidades de procesamiento de datos para la carga de trabajo determinada.

Al crear una implementación aprovisionada en Foundry a través de la CLI o la API, sku-name se puede establecer en GlobalProvisionedManaged, DataZoneProvisionedManaged o ProvisionedManaged, dependiendo de la necesidad de procesamiento de datos para la carga de trabajo dada.

Para adaptar el siguiente comando de CLI de Azure ejemplo a otro tipo de implementación, actualice el parámetro sku-name para que coincida con el tipo de implementación que desea implementar.

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

Administración de la capacidad y la disponibilidad

La capacidad para el rendimiento aprovisionado está sujeta a la disponibilidad regional y a la demanda en tiempo real. En las secciones siguientes se describe cómo funciona la capacidad y cómo encontrarlo.

Transparencia de la capacidad

Los modelos vendidos directamente por Azure son servicios muy buscados en los que la demanda del cliente podría superar la capacidad de GPU del servicio. Microsoft se esfuerza por proporcionar capacidad para todas las regiones y modelos a petición, pero la venta de una región siempre es una posibilidad. Esta restricción puede limitar la capacidad de algunos clientes de crear una implementación de su modelo, versión o número de PTU deseados en una región deseada, incluso si tienen cuota disponible en esa región.

Por lo general:

• La cuota no garantiza la capacidad. La cuota coloca un límite en el número máximo de PTUs que se pueden implementar en una suscripción y región.
• La capacidad se asigna en el momento de la implementación y se mantiene mientras exista la implementación. Si la capacidad del servicio no está disponible, se produce un error en la implementación.
• Use información en tiempo real sobre la cuota y la disponibilidad de la capacidad para elegir una región adecuada para su escenario.
• Reducir o eliminar una implementación libera capacidad de vuelta a la región. No hay ninguna garantía de que la capacidad esté disponible si la implementación se amplía o se vuelve a crear más adelante.

Guía de capacidad regional

Para encontrar la capacidad necesaria para sus implementaciones, use la API de capacidad o la experiencia de implementación de Foundry para proporcionar información en tiempo real sobre la disponibilidad de la capacidad.

En Foundry, la experiencia de implementación identifica cuándo una región carece de la capacidad necesaria para implementar el modelo. Esto examina el modelo, la versión y el número de PTU deseados. Si la capacidad no está disponible, la experiencia dirige a los usuarios a seleccionar una región alternativa.

Puede encontrar detalles sobre la experiencia de implementación en la guía de introducción de Foundry Provisioned.

Use la API de capacidades de modelo para identificar mediante programación la implementación de tamaño máximo de un modelo especificado. La API considera tanto tu cuota como la capacidad del servicio en la región.

Si una región aceptable no está disponible para admitir el modelo, la versión o PTU deseados, los clientes también pueden probar los pasos siguientes:

• Intente la implementación con un número menor de PTUs.
• Intente la implementación en otro momento. La disponibilidad de la capacidad cambia dinámicamente en función de la demanda del cliente y más capacidad podría estar disponible más adelante.
• Asegúrese de que la cuota está disponible en todas las regiones aceptables. La API de capacidades de modelo y la experiencia de Foundry tienen en cuenta la disponibilidad de cuota al devolver regiones alternativas para la creación de una implementación.

Supervisión del uso y el rendimiento

En las secciones siguientes se explica cómo supervisar el uso y controlar los límites de capacidad.

Supervisión de la capacidad

La métrica Provisioned-Managed Utilization V2 en Azure Monitor mide la utilización de un despliegue determinado en incrementos de 1 minuto. Todos los tipos de implementación aprovisionados están optimizados para asegurarse de que las llamadas aceptadas se procesan con un tiempo de procesamiento del modelo coherente (la latencia real de un extremo a otro depende de las características de una llamada).

Rendimiento de uso

Las implementaciones aprovisionadas proporcionan una cantidad asignada de capacidad de procesamiento de modelos para ejecutar un modelo determinado.

En todos los tipos de implementación aprovisionados, cuando se supera la capacidad, la API devuelve un error de estado HTTP 429. La respuesta rápida permite al usuario tomar decisiones sobre cómo administrar su tráfico. Los usuarios pueden redirigir las solicitudes a una implementación independiente, a una instancia de implementación estándar o usar una estrategia de reintento para administrar una solicitud determinada. El servicio continúa devolviendo el código de estado HTTP 429 hasta que el uso cae por debajo de 100%.

Manejo de respuestas HTTP 429

La respuesta 429 no es un error, sino que forma parte del diseño para indicar a los usuarios que una implementación determinada se utiliza por completo en un momento dado. Al proporcionar una respuesta de error rápida, tiene control sobre cómo controlar estas situaciones de una manera que mejor se adapte a los requisitos de la aplicación.

Los retry-after-ms encabezados y retry-after de la respuesta indican el tiempo de espera antes de que se acepte la siguiente llamada. La forma en que decide controlar esta respuesta depende de los requisitos de la aplicación. Estas son algunas consideraciones:

• Considere la posibilidad de redirigir el tráfico a otros modelos, implementaciones o experiencias. Esta opción es la solución de latencia más baja porque la acción se puede realizar en cuanto reciba la señal 429. Para obtener ideas sobre cómo implementar eficazmente este patrón, vea esta publicación de la comunidad.
• Si acepta latencias más largas por llamada, implemente la lógica de reintento en el lado del cliente. Esta opción proporciona la mayor cantidad de rendimiento por PTU. Las bibliotecas cliente de Foundry incluyen funcionalidades integradas para controlar reintentos.

Evaluación de solicitudes basadas en el uso

En todos los tipos de implementación aprovisionados, cada solicitud se evalúa individualmente según su tamaño de solicitud, el tamaño de generación esperado y el modelo para determinar su uso esperado. Este comportamiento contrasta con las implementaciones estándar, que tienen un comportamiento de limitación de velocidad personalizado en función de la carga de tráfico estimada. En el caso de las implementaciones estándar, este comportamiento de limitación de velocidad personalizada puede provocar errores HTTP 429 antes de que se superen los valores de cuota definidos si el tráfico no se distribuye uniformemente.

En el caso de las implementaciones aprovisionadas, se utiliza una variación del algoritmo de cubo con fugas para mantener el uso por debajo del 100% al tiempo que se permite cierta intermitencia en el tráfico. La lógica de alto nivel es la siguiente:

1. Cada cliente tiene una cantidad de capacidad establecida que puede usar en una implementación.

2. Cuando se realiza una solicitud:

   a. Cuando la utilización actual es superior al 100%, el servicio devuelve un código 429 con el encabezado retry-after-ms configurado para indicar el tiempo hasta que la utilización sea inferior al 100%.

   b. De lo contrario, el servicio calcula el cambio incremental en el uso necesario para atender la solicitud mediante la combinación de los tokens de solicitud, menos tokens almacenados en caché y el especificado max_tokens en la llamada. Un cliente puede recibir hasta 100% descuento en sus tokens de solicitud en función del tamaño de sus tokens almacenados en caché. Si no se especifica el max_tokens parámetro , el servicio calcula un valor. Esta estimación puede dar lugar a una simultaneidad menor de la esperada cuando el número de tokens generados reales es pequeño. Para obtener la simultaneidad más alta, asegúrese de que el max_tokens valor sea lo más cercano posible al tamaño de generación verdadero.

3. Cuando finaliza una solicitud, ahora conocemos el costo de proceso real de la llamada. Para garantizar una contabilidad precisa, corrigimos el uso mediante la siguiente lógica:

   a. Si el valor real > se estima, entonces la diferencia se añade a la utilización del despliegue.

   b. Si se calcula el valor real < , se resta la diferencia.

4. El uso general se disminuye a una velocidad continua en función del número de PTU implementado.

Límites de llamadas simultáneas

El número de llamadas simultáneas que puede lograr en una implementación depende de la forma de cada llamada (tamaño del aviso, max_tokens el parámetro y factores similares). El servicio sigue aceptando llamadas hasta que el uso alcance 100%. Para determinar el número aproximado de llamadas simultáneas, puede modelar las solicitudes máximas por minuto para una forma de llamada determinada en la calculadora de capacidad. Si el sistema genera menos del número de tokens de salida establecidos para el max_tokens parámetro , la implementación aprovisionada aceptará más solicitudes.

Capacidad de rendimiento aprovisionada para los modelos vendidos directamente por Azure

En esta sección se enumeran los Modelos Foundry que admiten la capacidad de rendimiento aprovisionado. Utiliza tu cuota de PTU y reserva de PTU en los modelos que se muestran en la tabla.

• La versión del modelo no se incluye en esta tabla. Compruebe la versión admitida para cada modelo al elegir la opción de implementación en el portal de Foundry.

• Las opciones de despliegue de rendimiento provisionado varían según la región.

• Los nuevos modelos vendidos directamente por Azure se incorporan primero a la opción de implementación de rendimiento aprovisionado global. La opción de Zona de datos aprovisionada estará disponible más adelante.

• Las PTU se administran de forma regional y por tipo de oferta. La cuota de PTU y las reservas deben estar en la región y el tipo (Global, Zona de datos, Regional) que desee usar.

• Las fluctuaciones del tráfico en las implementaciones aprovisionadas son gestionadas por una capacidad opcional llamada desbordamiento. Para más información sobre el desbordamiento, consulte Administración del tráfico con desbordamiento para implementaciones aprovisionadas.

Disponibilidad de regiones para la capacidad de rendimiento aprovisionado

Contenido relacionado

• Obtenga información sobre los pasos de incorporación para las implementaciones aprovisionadas.
• Guía de introducción de las unidades de rendimiento aprovisionadas (PTU)
• Descripción de los tipos de implementación
• Administración del tráfico con desbordamiento para implementaciones aprovisionadas
• Monitor modelos de OpenAI de Azure
• Gestionar la cuota para Azure OpenAI
• Ahorrar costos con las reservas de rendimiento aprovisionadas de Microsoft Foundry