Compartir vía


¿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 aprovisionada y aprovisionada global?

  • 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 globales están disponibles en los mismos recursos de Azure OpenAI que los tipos de implementación no globales, 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.

¿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 administrada aprovisionada o unidad de procesamiento administrada aprovisionada global 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 punto de referencia y de Studio
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 dimensionamiento, la tabla siguiente resume el TPM por PTU para los modelos gpt-4o y gpt-4o-mini

gpt-4o, 2024-05-13 y gpt-4o, 2024-08-06 gpt-4o-mini, 2024-07-18
Incrementos implementables 50 25
TPM de entrada por PTU 2,500 37 000
TPM de salida por PTU 833 12 333

** Para obtener una lista completa, consulte la calculadora de AOAI Studio

Conceptos clave

Tipos de implementación

Al crear una implementación aprovisionada en Azure OpenAI Studio, el tipo de implementación en el cuadro de diálogo Crear implementación es Administrada aprovisionada. Al crear una implementación administrada aprovisionada global en Azure Open Studio, el tipo de implementación en el cuadro de diálogo Crear implementación es Administrada aprovisionada global.

Al crear una implementación aprovisionada en Azure OpenAI a través de la CLI o la API, debe establecer el sku-name para que sea ProvisionedManaged. Al crear una implementación aprovisionada global en Azure OpenAI a través de la CLI o la API, debe establecer el sku-name en GlobalProvisionedManaged. 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

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.

Diagrama de la cuota independiente del modelo con un grupo de PTU disponibles para varios modelos de Azure OpenAI.

En el caso de las implementaciones aprovisionadas, la nueva cuota se muestra en Azure OpenAI Studio como un elemento de cuota denominado Unidad de procesamiento administrada aprovisionada. En el caso de las implementaciones administradas aprovisionadas globales, la nueva cuota se muestra en Azure OpenAI Studio como un elemento de cuota denominado Unidad de procesamiento administrada aprovisionada global. En el panel Cuota de Studio, al expandir el elemento de cuota se mostrarán las implementaciones que contribuyen al uso de cada cuota.

Recorte de pantalla de la interfaz de usuario de cuotas para Azure OpenAI aprovisionado.

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 Unidad de procesamiento administrada aprovisionada o Unidad de procesamiento administrada aprovisionada global en Azure OpenAI Studio. 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 para crear una implementación del modelo, la versión o el número de PTU que deseen en una región determinada, aunque dispongan de cuota 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 Studio para obtener información en tiempo real sobre la disponibilidad de capacidad.

En Azure OpenAI Studio, 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 seleccionar 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 Studio tienen en cuenta la disponibilidad de cuota en la devolución de 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 y aprovisionadas globales proporcionan una cantidad asignada de capacidad de procesamiento de modelo para ejecutar un modelo determinado.

En las implementaciones administradas aprovisionadas y administradas aprovisionadas globales, 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. Las implementaciones administradas aprovisionadas y administradas aprovisionadas globales 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 las ofertas administrada aprovisionada y administrada aprovisionada global, 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 aprovisionada administrada y aprovisionada administrada global, 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. 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 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 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 - - - - - - - - -
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