Rendimiento y latencia (clásico)

Visualización actual:Versión - Cambio a la versión del nuevo portal de Foundry

En este artículo se proporciona información general sobre cómo funciona la latencia y el rendimiento con Azure OpenAI y cómo optimizar el entorno para mejorar el rendimiento.

Descripción del rendimiento frente a la latencia

Hay dos conceptos clave que se deben tener en cuenta al cambiar el tamaño de una aplicación: (1) Rendimiento del nivel del sistema medido en tokens por minuto (TPM) y (2) tiempos de respuesta por llamada (también conocidos como latencia).

Rendimiento de nivel de sistema

Esta métrica muestra la capacidad general de la implementación: cuántas solicitudes por minuto y el total de tokens que puede procesar.

Para una implementación estándar, la cuota asignada a la implementación determina parcialmente la cantidad de rendimiento que puede lograr. Sin embargo, la cuota solo determina la lógica de admisión de las llamadas a la implementación y no aplica directamente el rendimiento. Debido a las variaciones de latencia por llamada, es posible que no pueda lograr un rendimiento tan alto como la cuota.

En una implementación aprovisionada, se asigna al punto de conexión una cantidad fija de capacidad de procesamiento de modelos. El rendimiento que puede alcanzar en el extremo depende de las características de la carga de trabajo, incluido el número de tokens de entrada, el número de tokens de salida, la frecuencia de llamadas y la tasa de aciertos de caché. El número de llamadas simultáneas y el número total de tokens procesados puede variar en función de estos valores.

Para todos los tipos de implementación, comprender el rendimiento del nivel del sistema es un componente clave de la optimización del rendimiento. Considere el rendimiento de nivel de sistema para una combinación de modelo, versión y carga de trabajo determinada, ya que el rendimiento varía en estos factores.

Estimación del rendimiento del nivel de sistema

Estimación de TPM con métricas de Azure Monitor

Un enfoque para calcular el rendimiento del nivel del sistema para una carga de trabajo determinada es usar datos históricos de uso de tokens. Para las cargas de trabajo de Azure OpenAI, se puede acceder a todos los datos históricos de uso y visualizarlos con las capacidades nativas de monitorización que ofrece Azure OpenAI. Se necesitan dos métricas para calcular el rendimiento del nivel del sistema para cargas de trabajo de OpenAI Azure: (1) Tokens de solicitud procesados y (2) Tokens de finalización generados.

Cuando se combinan, las métricas Tokens de solicitud procesados (TPM de entrada) y Tokens de finalización generados (TPM de salida) proporcionan una vista estimada del rendimiento del nivel del sistema en función del tráfico real de la carga de trabajo. Este enfoque no tiene en cuenta las ventajas del almacenamiento en caché de mensajes, por lo que será una estimación conservadora del rendimiento del sistema. Estas métricas se pueden analizar mediante la agregación mínima, media y máxima en ventanas de 1 minuto a lo largo de un horizonte temporal de varias semanas. Se recomienda analizar estos datos en un horizonte de varias semanas para asegurarse de que hay suficientes puntos de datos para evaluar. En el recorte de pantalla siguiente se muestra un ejemplo de la métrica Tokens de solicitud procesados visualizado en Azure Monitor, que está disponible directamente a través de Azure Portal.

Estimación de TPM a partir de datos de solicitud

Un segundo enfoque para estimar el rendimiento a nivel del sistema consiste en recopilar información sobre el uso de tokens a partir de los datos de solicitud de API. Este método proporciona un enfoque más granular para comprender la forma de la carga de trabajo por solicitud. La combinación de información de uso de tokens por solicitud con el volumen de solicitudes, medida en solicitudes por minuto (RPM), proporciona una estimación del rendimiento del nivel del sistema. Es importante tener en cuenta que las suposiciones realizadas para la coherencia de la información de uso de tokens entre las solicitudes y el volumen de solicitudes afectarán a la estimación del rendimiento del sistema. Los datos de salida de uso de tokens se pueden encontrar en los detalles de respuesta de la API de una determinada solicitud de finalización de chat de Azure OpenAI en Microsoft Foundry Models.

{
  "body": {
    "id": "chatcmpl-7R1nGnsXO8n4oi9UPz2f3UHdgAYMn",
    "created": 1686676106,
    "choices": [],
    "usage": {
      "completion_tokens": 557,
      "prompt_tokens": 33,
      "total_tokens": 590
    }
  }
}

Suponiendo que todas las solicitudes de una carga de trabajo determinada sean uniformes, multiplique los tokens de solicitud y los tokens de finalización de los datos de respuesta de la API por medio de rpm estimados para identificar el TPM de entrada y salida de la carga de trabajo especificada.

Uso de estimaciones de rendimiento de nivel de sistema

Después de calcular el rendimiento de nivel de sistema de una carga de trabajo determinada, use estas estimaciones para ajustar el tamaño de las implementaciones estándar y aprovisionadas. En el caso de las implementaciones estándar, combine los valores de TPM de entrada y salida para calcular el TPM total que se asignará a una implementación determinada. Para las implementaciones aprovisionadas, use los datos de uso del token de solicitud o los valores de TPM de entrada y salida para calcular el número de PTU necesarios para admitir una carga de trabajo determinada mediante la experiencia de calculadora de capacidad de implementación.

Estos son algunos ejemplos del modelo mini GPT-4o:

El número de PTUs se escala aproximadamente linealmente con la tasa de llamadas cuando la distribución de la carga de trabajo permanece constante.

Latencia: los tiempos de respuesta por llamada

La definición de alto nivel de latencia en este contexto es la cantidad de tiempo que se tarda en obtener una respuesta del modelo. Para las solicitudes de finalización y finalización de chat, la latencia depende en gran medida del tipo de modelo, el número de tokens en la solicitud y el número de tokens generados. En general, cada token de solicitud agrega poco tiempo en comparación con cada token incremental generado.

La relación TTLT = TTFT + (TBT × Tokens Generated) le permite separar la latencia controlada por tokens esperada de regresiones reales. Consulte Comprender la latencia de Azure OpenAI para obtener el desglose completo.

Estimar la latencia esperada por llamada puede ser difícil con estos modelos. La latencia de una solicitud de finalización puede variar en función de cuatro factores principales: (1) el modelo, (2) el número de tokens en el prompt, (3) el número de tokens generados y (4) la carga general de la implementación y del sistema. Los factores uno y tres suelen contribuir más al tiempo total. La siguiente sección profundiza en la anatomía de una llamada de inferencia de un modelo de lenguaje de gran tamaño.

Comprensión de la latencia de Azure OpenAI

Azure OpenAI la latencia de las solicitudes sigue una fórmula predecible. Saber esta fórmula le ayuda a indicar los tiempos de respuesta esperados controlados por tokens a partir de regresiones de rendimiento reales.

Fórmula de latencia

El tiempo total para generar una respuesta es:

TTLT = TTFT + (TBT × tokens generados)

Dónde:

• TTFT (Time to First Token) es el tiempo desde el envío del mensaje hasta que el primer token se devuelve, en milisegundos.
• TBT (tiempo entre tokens) es el tiempo medio entre tokens generados consecutivos, en milisegundos.
• Los tokens generados son el recuento total de tokens de salida para la respuesta.
• TTLT (Tiempo hasta el último token) es el tiempo total de respuesta de un extremo a otro.

Dado que TTLT se escala con el número de tokens generados, un aumento en TTLT suele explicarse por completo por un aumento de los tokens de salida, no por un problema de rendimiento del sistema. Compruebe siempre los recuentos de tokens antes de concluir que hay una regresión de latencia.

Métricas de latencia clave

Use estas métricas de Azure Monitor para investigar la latencia, independientemente de si transmite respuestas:

Siempre empareja una métrica de latencia con una métrica de recuento de tokens. Un TTLT de 5 segundos que genera 2000 tokens es muy diferente de un TTLT de 5 segundos que genera 50 tokens. La latencia sin contexto de token no es accionable.

Para obtener el catálogo de métricas completo, incluidas las dimensiones y la guía de agregación, consulte la referencia de datos de supervisión de Azure OpenAI.

Evaluación de la latencia en 10 minutos

Utilice la ruta que coincida con la carga de trabajo para evaluar si la latencia de implementación se comporta como se espera. Ambas rutas usan métricas de latencia clave de Azure Monitor de la tabla Key latency metrics.

Cargas de trabajo que no son de streaming

1. En el portal de Azure, abra el recurso Azure OpenAI y seleccione Monitoring>Metrics.

2. Agregue Time to Last Byte (AzureOpenAITTLTInMS) y separe mediante ModelDeploymentName para aislar el comportamiento por implementación.

3. Añada un segundo gráfico para Tokens de finalización generados (GeneratedTokens) en el mismo intervalo de tiempo.

4. Compare los dos gráficos:

   • Si TTLT y los tokens generados aumentan juntos, el cambio de latencia se explica por volumen de tokens. Este patrón es el comportamiento esperado, no una regresión.
   • Si TTLT aumenta sin un aumento del recuento de tokens, compruebe si hay presión de capacidad. En implementaciones administradas por PTU, gráfico Uso administrado por aprovisionamiento V2 (AzureOpenAIProvisionedManagedUtilizationV2). En las implementaciones de pago por uso, verifique las solicitudes de Azure OpenAI (AzureOpenAIRequests) para detectar la limitación 429 y el volumen de solicitudes simultáneas.

Cargas de trabajo de transmisión

1. En el portal de Azure, abra el recurso Azure OpenAI y seleccione Monitoring>Metrics.

2. Agregue tiempo a la respuesta (AzureOpenAITimeToResponse) y divida por ModelDeploymentName para la latencia del primer token.

3. Agregue Tiempo entre Tokens (AzureOpenAINormalizedTBTInMS) para el rendimiento de generación por token.

4. Añada tokens de solicitudes procesados (ProcessedPromptTokens). Las solicitudes más grandes aumentan el TTFT.

5. Compare los gráficos:

   • Si el tiempo de respuesta aumenta mientras el tamaño del prompt se mantiene estable, compruebe la utilización del despliegue y el volumen de solicitudes simultáneas.
   • Si se eleva el tiempo entre tokens, es probable que la implementación esté bajo carga.

Si los valores observados tienen un aspecto inesperado, vuelva a conectarlos a la fórmula de latencia para comprobar la integridad antes de abrir un caso de soporte técnico.

Mejora del rendimiento

Varios factores pueden mejorar la latencia por llamada de la aplicación.

Selección de modelos

La latencia varía en función del modelo que use. Para una solicitud idéntica, espere que los diferentes modelos tengan latencias diferentes para la llamada de finalizaciones de chat. Si el caso de uso requiere los modelos de latencia más baja con los tiempos de respuesta más rápidos, se recomienda el último modelo mini GPT-4o.

Tamaño de generación y tokens máximos

Al enviar una solicitud de finalización al punto de conexión de OpenAI de Azure, el servicio convierte el texto de entrada en tokens y los envía al modelo implementado. El modelo recibe los tokens de entrada y, a continuación, comienza a generar una respuesta. Es un proceso secuencial iterativo, un token a la vez. Otra manera de pensarlo es como un bucle for con n tokens = n iterations. Para la mayoría de los modelos, generar la respuesta es el paso más lento del proceso.

En el momento de la solicitud, el tamaño de generación solicitado (max_tokens parámetro) se usa como una estimación inicial del tamaño de generación. El modelo reserva el tiempo de proceso para generar el tamaño completo a medida que se procesa la solicitud. Una vez completada la generación, se libera la cuota restante. Formas de reducir el número de tokens:

• Establezca el max_tokens parámetro en cada llamada lo más bajo posible.
• Incluya secuencias de detención para evitar la generación de contenido adicional.
• Generar menos respuestas: el uso del parámetro n puede aumentar la latencia porque produce varias salidas por cada solicitud. Para obtener la respuesta más rápida, no establezca n (o establézcalo en 1).

En resumen, reducir el número de tokens generados por solicitud reduce la latencia de cada solicitud.

Transmisión en directo

Si se establece stream: true en una solicitud, el servicio devuelve tokens tan pronto como estén disponibles, en lugar de esperar a que se genere la secuencia completa de tokens. No cambia el tiempo para obtener todos los tokens, pero reduce el tiempo de la primera respuesta. Este enfoque proporciona una mejor experiencia de usuario, ya que los usuarios finales pueden leer la respuesta a medida que se genera.

El streaming también es útil para llamadas grandes que tardan mucho tiempo en procesarse. Muchos clientes y capas intermedias tienen tiempos de espera en llamadas individuales. Es posible que las llamadas de larga generación se cancelen debido a tiempos de espera del lado de cliente. Al volver a transmitir los datos, puede asegurarse de que se reciben datos incrementales.

Ejemplos de cuándo usar streaming:

Bots de chat e interfaces conversacionales.

El streaming afecta a la latencia percibida. Al habilitar el streaming, recibirá tokens en fragmentos tan pronto como estén disponibles. En el caso de los usuarios finales, este enfoque suele parecerse a que el modelo responde más rápido, aunque el tiempo general para completar la solicitud sigue siendo el mismo.

Ejemplos de cuándo el streaming es menos importante:

Análisis de sentimiento, traducción de idioma, generación de contenido.

Hay muchos casos de uso en los que se realiza alguna tarea masiva en la que solo le interesa el resultado finalizado, no la respuesta en tiempo real. Si el streaming está deshabilitado, no recibirá ningún token hasta que el modelo finalice toda la respuesta.

Filtrado de contenido

Azure OpenAI incluye un sistema de filtrado content que funciona junto con los modelos principales. Este sistema ejecuta tanto la solicitud como la finalización a través de un conjunto de modelos de clasificación destinados a detectar y evitar la salida de contenido perjudicial.

El sistema de filtrado de contenido detecta y toma medidas en categorías específicas de contenido potencialmente perjudicial tanto en solicitudes de entrada como en finalizaciones de salida.

La adición del filtrado de contenido incluye un aumento de la seguridad, pero también la latencia. Hay muchas aplicaciones en las que este equilibrio en el rendimiento es necesario; sin embargo, hay algunos casos de uso de riesgo más bajos en los que deshabilitar los filtros de contenido para mejorar el rendimiento podría merecer la pena explorar.

Obtenga más información sobre cómo solicitar modificaciones en las directivas de filtrado de contenido predeterminadas.

Separación de cargas de trabajo

La combinación de diferentes cargas de trabajo en el mismo punto de conexión puede afectar negativamente a la latencia. Esto se debe a que (1) se agrupan por lotes durante la inferencia y las llamadas cortas pueden estar esperando finalizaciones más largas y (2) mezclar las llamadas puede reducir la tasa de aciertos de caché, ya que ambas compiten por el mismo espacio. Siempre que sea posible, se recomienda tener implementaciones independientes para cada carga de trabajo.

Tamaño del mensaje

Aunque el tamaño del prompt influye menos en la latencia que el tamaño de la generación, sí afecta al tiempo total, especialmente cuando aumenta mucho.

Procesamiento por lotes

Si va a enviar varias solicitudes al mismo punto de conexión, puede procesar por lotes las solicitudes en una sola llamada. Esto reduce el número de solicitudes que necesita realizar y, en función del escenario, podría mejorar el tiempo de respuesta general. Se recomienda probar este método para ver si ayuda.

Medición del rendimiento

Se recomienda medir el rendimiento general en una implementación con dos medidas:

• Llamadas por minuto: el número de llamadas de inferencia de API que realiza por minuto. Esto se puede medir en Azure Monitor mediante la métrica de solicitudes de Azure OpenAI y desglosando por ModelDeploymentName
• Total de tokens por minuto: el número total de tokens que la implementación procesa por minuto. Esto incluye tokens de solicitud y & generados. A menudo, esto se divide aún más en medir ambos para comprender mejor el rendimiento de la implementación. Esto se puede medir en Azure Monitor mediante la métrica de tokens de inferencia procesados.

Para obtener la lista completa de métricas, dimensiones y registros de recursos de supervisión, consulte la referencia de datos de supervisión de Azure OpenAI.

Resumen

• Latencia del modelo: si la latencia del modelo es importante para usted, se recomienda probar el modelo mini GPT-4o.
• Reducir el máximo de tokens: OpenAI ha encontrado que incluso en los casos en que el número total de tokens generados es similar, la solicitud que tiene un valor más alto establecido para el parámetro de tokens máximos tendrá más latencia.
• Menor número de tokens totales generados: cuantos menos tokens generen más rápido será la respuesta general. Recuerde que esto es como tener un bucle for con n tokens = n iterations. Reducir el número de tokens generados y el tiempo de respuesta general mejorará en consecuencia.
• Streaming: la habilitación del streaming puede ser útil para administrar las expectativas del usuario en determinadas situaciones, ya que permite al usuario ver la respuesta del modelo a medida que se genera en lugar de tener que esperar hasta que el último token esté listo.
• El filtrado de contenido mejora la seguridad, pero también afecta a la latencia. Evalúe si alguna de las cargas de trabajo se beneficiaría de las directivas de filtrado de contenido modificadas.