Compartir vía


¿Qué es el rendimiento aprovisionado?

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é proporciona el tipo de implementación aprovisionado?

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

Nota:

La cuota de unidades de procesamiento aprovisionadas (PTU) es diferentes de la cuota estándar en Azure OpenAI y no está disponibles de forma predeterminada. Para más información sobre esta oferta, póngase en contacto con el equipo de su cuenta Microsoft.

¿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 Unidades de procesamiento administradas aprovisionadas para un modelo determinado
Latencia Latencia máxima restringida del modelo. La latencia general es un factor de forma de llamada.
Uso Medida del uso administrado y aprovisionado que se proporciona en Azure Monitor
Estimación de tamaño Calculadora proporcionada en el script de punto de referencia y de Studio

¿Cómo obtengo acceso a Aprovisionado?

Debe hablar con el equipo de ventas o de cuenta de Microsoft para adquirir el rendimiento aprovisionado. Si no tiene equipo de ventas o de cuenta, desafortunadamente en este momento no puede comprar el rendimiento aprovisionado.

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

Región gpt-4, 0613 gpt-4, 1106-Preview gpt-4, 0125-Preview gpt-4, turbo-2024-04-09 gpt-4o, 2024-05-13 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 - - - - - - -
uksouth -
westus
westus3

Nota:

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

Conceptos clave

Unidades de procesamiento aprovisionadas

Las unidades de procesamiento aprovisionadas (PTU) son unidades de capacidad de procesamiento de modelos que puede reservar e implementar para procesar mensajes y generar finalizaciones. 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.

Tipos de implementación

Al implementar un modelo en Azure OpenAI, debe establecer el sku-name que se va a aprovisionar y administrar. sku-capacity especifica el número de PTU asignadas a la implementación.

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

La cuota de rendimiento aprovisionada representa una cantidad específica del rendimiento total que puede implementar. La cuota de Azure OpenAI Service se administra en el nivel de suscripción. Todos los recursos de Azure OpenAI dentro de la suscripción comparten esta cuota.

La cuota se especifica en unidades de procesamiento aprovisionadas y es específica de un triplete (tipo de implementación, modelo, región). La cuota no es intercambiable. Esto significa que no se puede usar la cuota de GPT-4 para implementar GPT-3.5-Turbo.

Aunque hacemos todo lo posible para garantizar que la cuota se pueda implementar, esta no representa una garantía de que la capacidad subyacente esté disponible. El servicio asigna una capacidad durante la operación de implementación y, si la capacidad no está disponible, se produce un error de capacidad insuficiente para la 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
  • Las llamadas más grandes son progresivamente más caras de calcular. Por ejemplo, 100 llamadas con un tamaño de solicitud de 1000 tokens requerirá menos capacidad que 1 llamada con 100 000 tokens en la solicitud. Esto también significa que la distribución de estas formas de llamada es importante en el rendimiento general. Los patrones de tráfico con una distribución amplia que incluye algunas llamadas muy 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 las implementaciones administradas aprovisionadas, cuando se supera la capacidad, la API devolverá inmediatamente un error de estado HTTP 429. Esto 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 aprovechar una estrategia de reintento para administrar una solicitud determinada. El servicio seguirá devolviendo el código de estado HTTP 429 hasta que el uso caiga 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. Las implementaciones administradas aprovisionadas se optimizan para asegurarse de que las llamadas aceptadas se procesen 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 la oferta administrada aprovisionada, 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 HTTP 429 antes de que se superen los valores de cuota definidos si el tráfico no se distribuye uniformemente.

En el caso de aprovisionado administrado, usamos una variación del algoritmo de cubo filtrado para mantener el uso por debajo del 100 % al tiempo que se permite cierta ráfaga 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. Si no se especifica el parámetro max_tokens, el servicio calculará 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 se calcula el valor > real, 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.

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 mensaje, max_token parámetro, etc.). El servicio seguirá 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 muestreo como max_token, aceptará más solicitudes.

Pasos siguientes