¿Qué es el rendimiento aprovisionado?

Nota:

La oferta aprovisionada de Azure OpenAI recibió actualizaciones significativas el 12 de agosto de 2024, incluida la alineación del modelo de compra con los estándares de Azure y la migración a una cuota independiente del modelo. Se recomienda encarecidamente que los clientes incorporados antes de esta fecha lean la actualización de agosto de Azure OpenAI aprovisionada para obtener más información sobre estos cambios.

La capacidad de rendimiento aprovisionado permite especificar la cantidad de rendimiento que se necesita en una implementación. A continuación, el servicio asigna la capacidad de procesamiento del modelo necesaria y garantiza que está listo para el usuario. El rendimiento se define en términos de unidades de procesamiento aprovisionadas (PTU), que es una forma normalizada de representar una cantidad de rendimiento para una implementación. Cada par de modelo y versión requiere diferentes cantidades de PTU para su implementación y aporta diferentes cantidades de rendimiento por PTU.

¿Qué proporcionan los tipos de implementación aprovisionados?

• Rendimiento predecible: una latencia máxima y un rendimiento estables para generar cargas de trabajo uniformes.
• Capacidad de procesamiento reservada: 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.

Una implementación de Azure OpenAI es una unidad de administración para un modelo específico de OpenAI. Las implementaciones proporcionan a los clientes acceso a un modelo para realizar inferencias e integra más características como la moderación de contenidos (consulte la documentación de la moderación de contenido). Las implementaciones aprovisionadas globales están disponibles en los mismos recursos de Azure OpenAI que todos los demás tipos de implementación, pero permiten aprovechar la infraestructura global de Azure para enrutar dinámicamente el tráfico al centro de datos con la mejor disponibilidad para cada solicitud. Del mismo modo, las implementaciones aprovisionadas de zona de datos también están disponibles en los mismos recursos que todos los demás tipos de implementación, pero permiten aprovechar la infraestructura global de Azure para enrutar dinámicamente el tráfico al centro de datos dentro de la zona de datos especificada por Microsoft con la mejor disponibilidad para cada solicitud.

¿Qué obtiene?

Tema	aprovisionado
¿Qué es?	Proporciona un rendimiento garantizado en incrementos menores que la oferta aprovisionada existente. Las implementaciones tienen una latencia máxima coherente para una versión de modelo dada
¿Para quién es?	Clientes que desean un rendimiento garantizado con una varianza de latencia mínima.
Cuota	Unidad de procesamiento gestionada aprovisionada, unidad de procesamiento gestionada aprovisionada global o unidad de procesamiento gestionada aprovisionada de zona de datos asignada por región. La cuota se puede usar en cualquier modelo de Azure OpenAI disponible.
Latencia	Latencia máxima restringida del modelo. La latencia general es un factor de forma de llamada.
Uso	Medida de uso administrado aprovisionada V2 proporcionada en Azure Monitor.
Estimación de tamaño	Calculadora proporcionada en el script de pruebas y pruebas comparativas de Azure AI Foundry.
Almacenamiento en caché de mensajes	Para los modelos compatibles, descontamos hasta el 100 % de los tokens de entrada almacenados en caché.

Cuánto rendimiento por PTU se obtiene con cada modelo

La cantidad de rendimiento (tokens por minuto o TPM) que obtiene una implementación por PTU es una función de los tokens de entrada y salida en el minuto. La generación de tokens de salida requiere más procesamiento que la de los tokens de entrada, por lo que cuantos más tokens de salida se generen, menor será su TPM global. El servicio equilibra dinámicamente los costes de entrada y salida, por lo que los usuarios no tienen que establecer límites específicos de entrada y salida. Este enfoque significa que su implementación es resistente a las fluctuaciones en la forma de la carga de trabajo.

Para ayudar a simplificar el esfuerzo de ajuste de tamaño, en la tabla siguiente se describe el TPM por PTU para los modelos de gpt-4o y gpt-4o-mini que representan el TPM máximo, suponiendo que todo el tráfico sea de entrada o salida. Para comprender cómo afectan las diferentes proporciones de tokens de entrada y salida al número máximo de TPM por PTU, consulte la calculadora de capacidad de Azure OpenAI. En la tabla también se muestran los valores de destino de latencia del Acuerdo de Nivel de Servicio (SLA) por modelo. Para obtener más información sobre el Acuerdo de Nivel de Servicio para Azure OpenAI Service, consulte la página Acuerdos de Nivel de Servicio (SLA) para Online Services

Tema	gpt-4o, 2024-05-13 y gpt-4o, 2024-08-06	gpt-4o-mini, 2024-07-18
Implementación mínima aprovisionada de la zona global y de datos	15	15
Incremento de escala aprovisionado en la zona de datos y global	5	5
Implementación mínima aprovisionada regional	50	25
Incremento de escala aprovisionada regional	50	25
TPM de entrada máxima por PTU	2,500	37 000
TPM de salida máxima por PTU	833	12 333
Valor de destino de latencia	25 tokens por segundo	33 tokens por segundo

Para obtener una lista completa, consulte la AOAI en la calculadora de Azure AI Foundry.

Nota:

Las implementaciones aprovisionadas globales solo se admiten para los modelos gpt-4o, 2024-08-06 y gpt-4o-mini, 2024-07-18 en este momento. Las implementaciones aprovisionadas de zona de datos solo se admiten para los modelos gpt-4o, 2024-08-06, gpt-4o, 2024-05-13 y gpt-4o-mini, 2024-07-18 en este momento. Para más información sobre la disponibilidad de los modelos, consulte la documentación de modelos.

Conceptos clave

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 tipo de implementación administrado aprovisionado global, administrado aprovisionado de DataZone o administrado 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 OpenAI a través de la CLI o la API, sku-name se puede establecer en GlobalProvisionedManaged, DataZoneProvisionedManaged o ProvisionedManaged en función de la necesidad de procesamiento de datos para la carga de trabajo especificada. Para adaptar el comando de ejemplo de la CLI de Azure siguiente a otro tipo de implementación, basta con actualizar 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-4 \
--model-version 0613  \
--model-format OpenAI \
--sku-capacity 100 \
--sku-name ProvisionedManaged

Cuota

Unidades de procesamiento aprovisionadas

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 procesamiento aprovisionadas se conceden a una suscripción como cuota. Cada cuota es específica de una región y define el número máximo de PTU que pueden asignarse a las implementaciones en esa suscripción y región.

Cuota independiente del modelo

A diferencia de la cuota tokens por minuto (TPM) usada por otras ofertas de Azure OpenAI, las PTU son independientes del modelo. Es posible que las PTU se usen para implementar cualquier modelo o versión admitidos en la región.

En el caso de las implementaciones aprovisionadas, la nueva cuota se muestra en Azure AI Foundry como un elemento de cuota denominado unidad de procesamiento administrada aprovisionada. En el caso de las implementaciones aprovisionadas globales, la nueva cuota se muestra en Azure AI Foundry como un elemento de cuota denominado unidad de procesamiento administrada aprovisionada global. En el caso de las implementaciones aprovisionadas de zona de datos, la nueva cuota se muestra en Azure AI Foundry como un elemento de cuota denominado Unidad de procesamiento administrado aprovisionado de zona de datos. En el panel Cuota de Foundry, al expandir el elemento de cuota se muestran las implementaciones que contribuyen al uso de cada cuota.

Obtención de cuota de PTU

La cuota de PTU está disponible de forma predeterminada en muchas regiones. Si se necesita más cuota, los clientes pueden solicitarla a través del vínculo Solicitar cuota. Este vínculo se puede encontrar a la derecha de las pestañas de cuota de tipo de implementación aprovisionadas designadas en Azure AI Foundry El formulario permite al cliente solicitar un aumento en la cuota de PTU especificada para una región determinada. El cliente recibe un correo electrónico en la dirección incluida una vez aprobada la solicitud, normalmente en un plazo de dos días laborables.

Mínimos de PTU por modelo

La implementación de PTU mínima, los incrementos y la capacidad de procesamiento que se asocian a cada unidad varían en función del tipo de modelo y de la versión.

Transparencia de la capacidad

Azure OpenAI es un servicio muy solicitado en el 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 pone un límite al número máximo de PTU que pueden desplegarse en una suscripción y región, y no garantiza la disponibilidad de 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 producirá un error en la implementación
• Los clientes usan información en tiempo real sobre la disponibilidad de cuota o capacidad para elegir una región adecuada para su escenario con la capacidad de modelo necesaria
• La reducción o eliminación de una implementación devuelve capacidad a la región. No hay garantía de que la capacidad esté disponible en caso de que la implementación se amplíe o se vuelva 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. Para ello se tiene en cuenta 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 una región alternativa.

Puede encontrar detalles sobre la nueva experiencia de implementación en la guía de introducción de Azure OpenAI aprovisionado.

La nueva API de capacidades de modelo puede usarse 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 apoyar el modelo deseado, la versión o las PTU, los clientes también pueden probar los siguientes pasos:

• 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.

Determinar el número de PTU necesarios para una carga de trabajo

Las PTU representan una cantidad de capacidad de procesamiento de modelos. Al igual que ocurre con el equipo o las bases de datos, las diferentes cargas de trabajo o solicitudes al modelo consumirán diferentes cantidades de capacidad de procesamiento subyacente. La conversión de características de forma de llamada (tamaño de la solicitud, tamaño de la generación y tasa de la llamada) en PTU es compleja y no lineal. Para simplificar este proceso, puede usar la calculadora de capacidad de Azure OpenAI para ajustar el tamaño de las formas de carga de trabajo específicas.

Algunas consideraciones generales:

• Las generaciones requieren más capacidad que las solicitudes
• Para los modelos GPT-4o y posteriores, el TPM por PTU se establece para los tokens de entrada y salida por separado. En el caso de los modelos más antiguos, las llamadas más grandes son progresivamente más caras de proceso. Por ejemplo, 100 llamadas con un tamaño de solicitud de 1000 tokens requiere menos capacidad que 100,000 llamada con 100 000 tokens en la solicitud. Este escalonamiento significa que la distribución de estas formas de llamada es importante en el rendimiento global. Los patrones de tráfico con una distribución amplia que incluye algunas llamadas grandes pueden experimentar un menor rendimiento por PTU que una distribución más estrecha con los mismos tamaños de token de solicitud y finalización promedios.

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 devolverá un error de estado HTTP 429. Esta rápida respuesta 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 estándar de pago por uso 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 %.

¿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).

¿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 se utiliza por completo 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 OpenAI incluyen capacidades 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. Esto contrasta con las implementaciones de pago por uso, que tienen un comportamiento de limitación de velocidad personalizada en función de la carga de tráfico estimada. En el caso de las implementaciones de pago por uso, esto puede dar lugar a que se generen 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 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 tokens de solicitud y el max_tokens especificado en la llamada. Para las solicitudes que incluyen al menos 1024 tokens almacenados en caché, los tokens almacenados en caché se restan del valor del token solicitado. 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 parámetro max_tokens, el servicio estima 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 reduce a una velocidad continua en función del número de PTU implementadas.

Nota:

Las llamadas se aceptan hasta que el uso alcanza el 100 %. Las ráfagas por encima del 100 % pueden permitirse en periodos cortos, pero con el tiempo, el tráfico se limita al 100 % de 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 mensaje, max_token parámetro, etc.). El servicio sigue aceptando llamadas hasta que la utilización alcanza 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 muestreo como max_token, aceptará más solicitudes.

¿Qué modelos y regiones están disponibles para el rendimiento aprovisionado?

Región	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	✅	-	✅	✅	✅	-	✅	-	✅	-
estado	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
eastus2	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
francecentral	✅	✅	✅	✅	✅	✅	-	✅	-	✅
germanywestcentral	✅	-	-	✅	✅	✅	✅	✅	✅	-
japaneast	✅	✅	✅	-	✅	✅	✅	-	-	✅
koreacentral	✅	✅	✅	✅	-	-	✅	✅	✅	-
northcentralus	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
norwayeast	✅	-	✅	✅	-	✅	-	✅	-	-
polandcentral	✅	-	-	✅	✅	✅	✅	✅	✅	✅
southafricanorth	✅	-	-	✅	✅	-	✅	✅	✅	-
southcentralus	✅	-	-	✅	✅	✅	✅	✅	✅	✅
southindia	✅	✅	✅	✅	✅	✅	-	✅	✅	✅
suecia central	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
norte de suiza	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
switzerlandwest	-	-	-	-	-	-	-	-	-	✅
uaenorth	✅	-	-	-	✅	-	-	-	✅	✅
uksouth	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
westus	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
westus3	✅	✅	-	✅	✅	✅	✅	✅	✅	✅

Nota:

La versión aprovisionada de la gpt-4 Versión: turbo-2024-04-09 está limitada actualmente a solo texto.

Pasos siguientes

• Más información sobre los pasos de incorporación para las implementaciones aprovisionadas
• Guía de introducción a las unidades de rendimiento aprovisionadas (PTU)