Compartir a través de

¿Qué es el rendimiento aprovisionado?

Nota:

Para obtener más información sobre los cambios recientes en la oferta de rendimiento aprovisionado, consulte el artículo de actualización para obtener más información.

La oferta de rendimiento aprovisionado de Azure AI Foundry es un tipo de implementación de modelo que permite especificar la cantidad de rendimiento que necesita en una implementación de modelos. Después, Azure AI Foundry asigna la capacidad de procesamiento de modelos necesaria y garantiza que está listo para usted. Puede usar el rendimiento aprovisionado que solicitó en una amplia cartera de modelos que Azure vende directamente. Estos modelos incluyen modelos de Azure OpenAI y familias de modelos insignia recién introducidas, como Azure DeepSeek, Azure Grok, Azure Llama y mucho más dentro de azure AI Foundry Models.

El rendimiento aprovisionado proporciona:

  • Una elección de modelo más amplia en los modelos insignia más recientes
  • Flexibilidad para cambiar los modelos e implementaciones con una cuota de rendimiento aprovisionada determinada
  • Descuentos significativos y la capacidad de aumentar el uso de la reserva con una opción de reserva más flexible
  • Rendimiento predecible, proporcionando una latencia máxima estable y un rendimiento para cargas de trabajo uniformes.
  • Capacidad de procesamiento asignada: una implementación configura la cantidad de rendimiento. Una vez realizada la implementación, el rendimiento está disponible, independientemente de que se uso o no.
  • Ahorro de costos: cargas de trabajo de alto rendimiento pueden proporcionar ahorros de costos frente al consumo basado en tokens.

Sugerencia

Cuándo usar el rendimiento aprovisionado

Debe considerar la posibilidad de cambiar de las implementaciones estándar a las implementaciones de rendimiento aprovisionadas cuando tenga requisitos de rendimiento y latencia bien definidos y predecibles. Normalmente, esto ocurre cuando la aplicación está lista para producción o ya está implementada en producción y se entiende el tráfico esperado. Esto permite a los usuarios predecir con precisión la capacidad necesaria y evitar una facturación inesperada. Las implementaciones de capacidad aprovisionada también son útiles para aplicaciones que tienen requisitos sensibles al tiempo real o a la latencia.

Conceptos clave

En las secciones siguientes se describen los conceptos clave que debe tener en cuenta al usar la oferta de rendimiento aprovisionado.

Unidades de procesamiento aprovisionadas (PTU)

Las unidades de procesamiento aprovisionadas (PTU) son unidades genéricas de capacidad de procesamiento de modelos que se pueden usar para ajustar el tamaño de las implementaciones aprovisionadas con el fin de alcanzar el rendimiento necesario para procesar solicitudes y generar finalizaciones. 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.

Gestión de costos en reserva compartida de PTU

Puede usar la funcionalidad de PTU para administrar sin problemas los costos de los modelos Foundry en una reserva de PTU compartida. Las unidades PTU necesarias para la implementación y el rendimiento son adaptadas dinámicamente según 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, supongamos que tiene una reserva de PTU existente con 500 PTU comprados. Utilizas 300 unidades para los modelos de Azure OpenAI, y eliges usar también PTU para implementar Azure DeepSeek, Azure Llama o otros modelos con la capacidad PTU en los Modelos Foundry.

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

  • Si usa 300 unidades PTU para DeepSeek-R1, entonces 200 unidades PTU se benefician automáticamente del descuento de la reserva, mientras que las 100 unidades PTU restantes exceden la reserva y se facturan a la tarifa por hora de DeepSeek-R1.

Para aprender sobre cómo ahorrar costes con las reservas de PTU, consulta:Ahorre costes con las reservas de rendimiento aprovisionado Fundición de IA de Azure de Microsoft.

Tipos de implementación

Al crear una implementación aprovisionada en Azure AI 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 especificada.

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

Tipo de implementación Nombre de SKU en la CLI
Rendimiento aprovisionado global GlobalProvisionedManaged
Rendimiento aprovisionado de zona de datos DataZoneProvisionedManaged
Rendimiento aprovisionado regional ProvisionedManaged

Para adaptar el siguiente comando de ejemplo de la CLI de Azure a otro tipo de implementación, actualice el sku-name parámetro 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

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 ofrecer capacidad para todas las regiones y modelos más demandados, pero siempre existe la posibilidad de que se agote una región. 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 coloca un límite en el número máximo de PTU que se pueden implementar en una suscripción y región, y no garantiza la disponibilidad de la capacidad.
  • 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.
  • Los clientes usan información en tiempo real sobre la disponibilidad de la cuota o capacidad para elegir una región adecuada para su escenario con la capacidad del modelo necesaria.
  • La reducción o eliminación de una implementación devuelve capacidad a la región. No hay ninguna garantía de que la capacidad estará 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 Azure AI Foundry para proporcionar información en tiempo real sobre la disponibilidad de la capacidad.

En Azure AI 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 aprovisionada de Azure AI Foundry.

La API de capacidades de modelo se puede usar para identificar mediante programación la implementación de tamaño máximo de un modelo especificado. La API tiene en cuenta la capacidad de cuota y 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 PTU.
  • Intente la implementación en otro momento. La disponibilidad de capacidad cambia dinámicamente en función de la demanda de los clientes y es posible que más adelante haya más capacidad disponible.
  • Asegúrese de que la cuota está disponible en todas las regiones aceptables. La API de capacidades del modelo y la experiencia de Azure AI Foundry tienen en cuenta la disponibilidad de cuota para devolver regiones alternativas para crear una implementación.

¿Cómo puedo supervisar la capacidad?

La métrica de uso administrado aprovisionado V2 en Azure Monitor mide un uso de implementaciones 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).

Funcionamiento del rendimiento de uso

Las implementaciones aprovisionadas proporcionan una cantidad asignada de capacidad de procesamiento de modelo 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 sigue devolviendo el código de estado HTTP 429 hasta que la utilización se anula por debajo del 100 %.

¿Qué debo hacer cuando reciba una respuesta 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 está totalmente utilizada en un momento dado. Al proporcionar una respuesta de error rápida, tiene control sobre cómo manejar estas situaciones de una manera que mejor se adapte a los requisitos de la aplicación.

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

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

¿Cómo decide el servicio cuándo enviar una señal 429?

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 que se generan 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 usa una variación del algoritmo de cubo filtrado para mantener el uso por debajo del 100 % al tiempo que se permite cierta expansión en el tráfico. La lógica resumida 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 el uso actual está por encima del 100 %, el servicio devuelve un código 429 con el encabezado retry-after-ms establecido en el tiempo hasta que el uso esté por debajo del 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 indicación, menos los tokens almacenados en caché, y el max_tokens especificado en la llamada. Un cliente puede recibir hasta un descuento del 100 % 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 real de tokens generados es pequeño. Para obtener la simultaneidad más alta, asegúrese de que el valor de max_tokens 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, corregimos el uso mediante la lógica siguiente:

    a) Si el > real estimado, entonces la diferencia se agrega al uso de la implementación.

    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.

Nota:

Las llamadas se aceptan hasta que el uso alcanza el 100 %. Los picos por encima del 100% podrían estar permitidos durante periodos cortos, pero con el tiempo, su tráfico se limitará al 100 % de utilización.

Diagrama que muestra cómo se agregan las llamadas posteriores al uso.

¿Cuántas llamadas simultáneas puedo tener en mi implementación?

El número de llamadas simultáneas que puede lograr depende de la forma de cada llamada (tamaño del símbolo del sistema, max_tokens parámetro, etc.). El servicio sigue aceptando llamadas hasta que el uso alcance el 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 parámetro max_tokens, la implementación aprovisionada aceptará más solicitudes.

Capacidad de rendimiento provisionada para modelos vendidos directamente por Azure

En esta sección se enumeran los modelos Foundry que admiten la funcionalidad de rendimiento aprovisionada. Puede usar la cuota de PTU y la reserva de PTU en los modelos que se muestran en la tabla.

Los siguientes puntos son algunos aspectos importantes de 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 Azure AI Foundry.

  • La opción de implementación de rendimiento aprovisionado regional varía según la región.

  • Los nuevos modelos vendidos directamente por Azure se incorporan primero con la opción de implementación de rendimiento aprovisionado global. La opción de rendimiento aprovisionado de zona de datos llegará más tarde.

  • PTU se administra de forma regional y por tipo de oferta. La cuota de PTU y las reservas deben estar en la región y el formato (Global, zona de datos, Regional) que desee utilizar.

  • El desbordamiento es una capacidad opcional que gestiona las fluctuaciones de tráfico en las implementaciones aprovisionadas. Para más información sobre el desbordamiento, consulte Administración del tráfico con desbordamiento para implementaciones aprovisionadas.

Familia de modelos Nombre del modelo Aprovisionado global Zona de datos aprovisionada Aprovisionado regional Característica de desbordamiento
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 ✅

Disponibilidad de regiones para la funcionalidad de rendimiento aprovisionada

Disponibilidad del modelo de rendimiento aprovisionado global

Región gpt-5, 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
australiaeast ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Brasil Sur ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
este de Canadá ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
centralindia ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastasia ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus2 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
francecentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Alemania Oeste Central ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
italynorth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
japaneast ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
koreacentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
northcentralus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
northeurope ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
NoruegaEste ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
poloniacentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Sudáfrica Norte ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southcentralus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southeastasia ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Sur de la India ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
spaincentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Swedencentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Suiza Norte ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
suiza oeste ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uaenorth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uksouth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Europa Occidental ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus3 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

Nota:

La versión aprovisionada de gpt-4Version:turbo-2024-04-09 se limita actualmente solo al texto.

Contenido relacionado

  • Last updated on