¿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.
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-35-turbo. Puede generar una solicitud de soporte técnico para desplazar la cuota entre tipos de implantación, modelos o regiones, pero no podemos garantizar el cambio.
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 de la aplicación de la utilización
Las implementaciones aprovisionadas proporcionan una cantidad asignada de capacidad de procesamiento de modelo para ejecutar un modelo determinado. La métrica Provisioned-Managed Utilization de Azure Monitor mide un uso determinado de implementaciones 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). Cuando la carga de trabajo supera su capacidad asignada, el servicio devuelve un código de estado HTTP 429 hasta que el uso cae 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 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.
- 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?
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:
Cada cliente tiene una cantidad de capacidad establecida que puede usar en una implementación.
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-msestablecido 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_tokensespecificado en la llamada. Si no se especifica el parámetromax_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 demax_tokenssea lo más cercano posible al tamaño de generación verdadero.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.
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 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.