Rendimiento y latencia

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

Esto examina la capacidad general de la implementación: el número de solicitudes por minuto y el total de tokens que se pueden 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 para las llamadas a la implementación y no aplica directamente el rendimiento. Debido a las variaciones de latencia por llamada, es posible que no se pueda alcanzar un rendimiento tan alto como el de la cuota.

En una implementación aprovisionada, se asigna una cantidad establecida de capacidad de procesamiento del modelo al endpoint. La cantidad de rendimiento que puede alcanzar en el extremo depende de la forma de la carga de trabajo, incluida la cantidad de tokens de entrada, la cantidad de salida, la tasa de llamadas y la tasa de coincidencia 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. Es importante tener en cuenta el rendimiento de nivel de sistema para una combinación de modelo, versión y carga de trabajo determinada, ya que el rendimiento variará 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 de uso históricos y visualizarlos con las capacidades de monitoreo nativas ofrecidas dentro de Azure OpenAI. Se necesitan dos métricas para calcular el rendimiento del nivel del sistema para cargas de trabajo de Azure OpenAI: (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 utilizando 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 la siguiente captura de pantalla se muestra un ejemplo de la métrica Tokens de entrada procesados visualizada en Azure Monitor, que está disponible directamente a través del portal de Azure.

Captura de pantalla del gráfico de Azure Monitor que muestra la métrica Tokens de indicaciones procesados, dividida por modelo y versión.

Estimación de TPM a partir de datos de solicitud

Un segundo enfoque para el rendimiento estimado a nivel de sistema implica recopilar información de uso de tokens 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 la respuesta de la API para una solicitud determinada de Azure OpenAI de finalización de chats 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, los tokens de solicitud y los tokens de finalización de los datos de respuesta de la API se pueden multiplicar por las RPM estimadas para identificar el TPM de entrada y salida de la carga de trabajo especificada.

Uso de estimaciones de rendimiento de nivel de sistema

Una vez que se ha estimado el rendimiento de nivel del sistema para una carga de trabajo determinada, estas estimaciones se pueden usar para ajustar el tamaño de las implementaciones estándar y aprovisionadas. En el caso de las implementaciones estándar, los valores de TPM de entrada y salida se pueden combinar para calcular el TPM total que se asignará a una implementación determinada. En el caso de las implementaciones aprovisionadas, los datos de uso del token de solicitud o los valores de TPM de entrada y salida se pueden usar para calcular el número de PTUs necesarios para admitir una carga de trabajo determinada con la experiencia de calculadora de capacidad de implementación.

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

Tamaño de entrada (tokens)	Tamaño de generación (tokens)	Solicitudes por minuto	TPM de entrada	TPM de salida	Mantenimiento Productivo Total (TPM)	Se requieren PTU
800	150	30	24,000	4,500	28,500	15
5,000	50	1,000	5,000,000	50,000	5,050,000	140
1,000	300	500	500,000	150,000	650,000	30

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 de chat, la latencia depende en gran medida del tipo de modelo, el número de tokens en el prompt y el número de tokens generados. En general, cada token de comando añade poco tiempo comparado con cada token incremental generado.

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 símbolo del sistema, (3) el número de tokens generados y (4) la carga general en la implementación y el sistema. Uno y tres suelen ser los principales contribuyentes al tiempo total. En la sección siguiente se detallan más detalles sobre la anatomía de una llamada de inferencia de modelo de lenguaje grande.

Mejora del rendimiento

Hay varios factores que puede controlar para 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 texto de entrada se convierte en tokens que luego se envían 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 parámetro max_tokens en cada llamada lo más pequeño 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 genera varias salidas por solicitud. Para obtener la respuesta más rápida, no lo establezca en n (o en 1).

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

Nota

max_tokens solo cambia la longitud de una respuesta y, en algunos casos, puede truncarlo. El parámetro no cambia la calidad de la respuesta.

Transmisión en tiempo real

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 con 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 generación prolongada se cancelen debido a los tiempos de espera del lado del 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. Con el streaming habilitado, recibirá los tokens por fragmentos en cuanto estén disponibles. Para los usuarios finales, este enfoque suele parecerse a que el modelo responde más rápido aunque el tiempo general para completar la solicitud siga 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 haya terminado toda la respuesta.

Filtrado de contenido

Azure OpenAI incluye un sistema de filtrado content que funciona junto con los modelos principales. Este sistema funciona ejecutando 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 esperar a que finalicen las 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 de la solicitud tiene una menor influencia en la latencia que el tamaño de la generación de datos, afecta al tiempo total, especialmente cuando el tamaño es grande.

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 Solicitudes de Azure OpenAI y separando por ModelDeploymentName.
Tokens totales procesados 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 usando la métrica Processed Inference tokens.

Puede obtener más información sobre Monitoring Azure OpenAI.

Medición de la latencia por llamada

El tiempo que tarda cada llamada depende del tiempo necesario para leer el modelo, generar la salida y aplicar filtros de contenido. La forma en que mida el tiempo variará si usa streaming o no. Se recomienda un conjunto diferente de medidas para cada caso.