Rendimiento y latencia

Artículo
09/20/2024

Este artículo le proporcionará información general sobre cómo funcionan la latencia y el rendimiento con Azure OpenAI y cómo optimizar su 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) El rendimiento del nivel de sistema y los (2) Tiempos de respuesta por llamada (también conocidos como latencia).

Rendimiento del 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 pueda lograr un rendimiento tan alto como la cuota. Obtenga más información sobre cómo administrar la cuota.

En una implementación aprovisionada, se asigna una cantidad establecida de capacidad de procesamiento de modelos al punto de conexión. La cantidad de rendimiento que puede lograr en el punto de conexión es un factor del tamaño de entrada, el tamaño 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. En los pasos siguientes se explica cómo evaluar el rendimiento que puede obtener una carga de trabajo determinada en una implementación aprovisionada:

Use la calculadora de capacidad para estimar el tamaño.
Prueba comparativa de la carga mediante una carga de trabajo de tráfico real. Mida las métricas procesadas de uso y tokens de Azure Monitor. Ejecute durante un período prolongado. El repositorio de Azure OpenAI Benchmarking contiene código para ejecutar el punto de referencia. Por último, el enfoque más preciso es ejecutar una prueba con sus propios datos y características de carga de trabajo.

Estos son algunos ejemplos del modelo GPT-4 0613:

Tamaño de la solicitud (tokens)	Tamaño de generación (tokens)	Llamadas por minuto	PTU requeridos
800	150	30	100
1000	50	300	700
5000	100	50	600

El número de PTU se escala aproximadamente de forma lineal con la tasa de llamadas (puede ser sublineal) 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.

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 la solicitud, (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 colaboradores del tiempo total. En la sección siguiente se detallan más detalles sobre la anatomía de una llamada de inferencia de un modelo de lenguaje grande.

Mejorar el 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 se use. Para una solicitud idéntica, espere que los diferentes modelos tengan latencias diferentes para las llamadas 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 de GPT-4o mini.

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

Al enviar una solicitud de finalización al punto de conexión de Azure OpenAI, 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 (parámetro max_tokens) 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.
Genere menos respuestas: los parámetros best_of y n pueden aumentar considerablemente la latencia porque generan varias salidas. Para obtener la respuesta más rápida, no especifique estos valores ni los establezca en 1.

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

Streaming

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 larga generación se cancelen debido a tiempos de espera agotados del lado cliente. Al volver a transmitir los datos, puede asegurarse de que se reciban datos incrementales.

Ejemplos de cuándo usar el streaming:

Bots de chat e interfaces conversacionales.

El streaming afecta a la latencia percibida. Si tiene habilitado el streaming, recibirá tokens en fragmentos tan pronto como estén disponibles. Desde la perspectiva del usuario final, suele parecer 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 idiomas y generación de contenido.

Hay muchos casos de uso en los que se lleva a cabo alguna tarea masiva en la que solo le interesa el resultado final, 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 de contenido 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 dañino.

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 de 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 podría valer la pena explorar la opción de deshabilitar los filtros de contenido para mejorar el rendimiento.

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 de la solicitud

Aunque el tamaño de la solicitud tiene una influencia menor en la latencia que el tamaño de generación, este afecta al tiempo general, especialmente cuando el tamaño aumenta.

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 dividiendo 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 al medir ambos para comprender mejor el rendimiento de la implementación. Esto se puede medir en Azure-Monitor mediante la métrica Tokens de inferencia procesados.

Puede obtener más información sobre la Supervisión de Azure OpenAI Service.

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 los filtros de contenido. La forma en que mida el tiempo variará en función de si usa streaming o no. Se recomienda un conjunto diferente de medidas para cada caso.