Pruebas de carga para atender puntos de conexión

Este artículo le guía a través del proceso esencial de prueba de carga de los puntos de conexión de servicio del modelo de Mosaic AI para garantizar que pueden gestionar las cargas de trabajo de producción de manera eficaz. También proporciona ejemplos prácticos, analogías del mundo real e instrucciones paso a paso mediante el marco de pruebas de carga de Locust, para demostrar cómo medir las métricas claves de rendimiento, como las solicitudes por segundo y los límites de simultaneidad, permitiéndole ajustar correctamente el tamaño de sus puntos de conexión e implementar modelos para satisfacer sus necesidades empresariales.

Sugerencia

Las pruebas de carga son un componente esencial de la optimización de producción. Para obtener una guía completa sobre las estrategias de optimización, como la infraestructura, el modelo y las optimizaciones del lado del cliente, consulte Optimizar los endpoints de servicio de modelos para producción.

¿Qué es una prueba de carga?

Una prueba de carga es una prueba que simula el uso real de los endpoints de servicio del modelo de Mosaic AI para garantizar que cumplen con los requisitos de producción, como la latencia o las solicitudes por segundo. Una prueba de carga mide el rendimiento del punto de conexión en diferentes niveles de tráfico, lo que le ayuda a ajustar el tamaño correcto del punto de conexión para no provocar retrasos.

Imagina esto: Son las 8:00 a. m. en un día laborable, y una cafetería popular en el corazón de la ciudad acaba de abrir. El aroma del café fresco llena el aire. El barista está preparado, las máquinas están calientes, y la fila de clientes que necesitan cafeína ya se está formando.

Al principio, las cosas se ejecutan sin problemas. Un par de clientes se acercan, realizan sus pedidos, y el barista comienza a preparar sus bebidas. Algunas bebidas tardan 30 segundos, otras tardan un minuto, dependiendo de la complejidad. El barista maneja varios pedidos con eficacia práctica.

Pero pronto llegan más personas. Cinco clientes se convierten en diez, entonces veinte. Cada uno está haciendo un pedido, esperando su bebida, y tal vez chateando un poco en el mostrador. El barista ahora está bajo presión. Incluso con un segundo barista entrando, el sistema empieza a mostrar estrés, la fila crece, los pedidos se acumulan y los clientes comienzan a esperar más.

Ahora imagine que está intentando medir cuántas bebidas puede servir la cafetería por minuto antes de que los clientes empiecen a marcharse frustrados. Esas son pruebas de carga.

En esta analogía:

• Cada cliente es un cliente que envía una solicitud.
• Los baristas representan el servidor que procesa las inferencias del modelo una por una o en paralelo.
• El tiempo para tomar un pedido y servir la bebida es el tiempo de implementación del modelo .
• Los retrasos por hablar, pagar o encontrar el pedido son la sobrecarga de red.
• Más clientes que llegan a la vez es simultaneidad de clientes.
• Agregar más baristas o más máquinas es como aumentar la simultaneidad del servidor.

Como en cualquier buena cafetería, hay un límite para la cantidad que el personal puede manejar a la vez. Si no planeas con anticipación, por ejemplo, trayendo más baristas durante las horas punta, la gente se va descontenta. Lo mismo sucede con los sistemas que están bajo carga. Las pruebas de carga le ayudan a identificar dónde están los cuellos de botella, cuánto tráfico puede controlar el sistema y qué cambios necesita realizar para un servicio más suave.

Antes de ejecutar una prueba de carga en el punto de conexión, debe hacer lo siguiente:

• Comprenda los componentes y conceptos relacionados con las pruebas de carga.
• Decida y defina sus requisitos de producción.
• Busque una carga representativa para el marco de pruebas de carga que se usará al realizar pruebas comparativas del punto de conexión.

Conceptos y definiciones de pruebas de carga

En la tabla siguiente se definen los conceptos relacionados con las pruebas de carga:

Concepto	Descripción
Concurrencia de clientes (número de clientes)	Número total de clientes que envían simultáneamente solicitudes en paralelo a un punto de conexión. Estos son sus clientes en la cafetería en el ejemplo anterior. Producción: el número total de instancias de clientes que envían tráfico al punto de conexión de servicio del modelo. Prueba de carga: en Locust, este es el número de usuarios creados que generan tráfico al punto de conexión del servicio del modelo que se está probando.
Concurrencia del punto de conexión	Número de procesos de inferencia o instancias de modelo que pueden controlar las solicitudes entrantes. También se puede expresar como el número de solicitudes que el punto de conexión puede gestionar de manera simultánea. Es el número de baristas del ejemplo anterior. Mosaic AI Model Serving: los puntos de conexión de servicio del modelo se pueden configurar para tamaños de recursos de computación de escalado horizontal. Por ejemplo, el uso del tamaño Small de los puntos de conexión de CPU crea cuatro instancias del modelo en el punto de conexión.
Latencia	Tiempo (en milisegundos) para que se complete una solicitud de ida y vuelta completa. Medida del tiempo total después de que el cliente haya enviado una solicitud hasta que se haya recibido la respuesta, incluido el tiempo de ejecución del punto de conexión y la latencia de red.
Latencia PXX (P50,P90,P99)	La latencia (en milisegundos) para la que el percentil XX de las solicitudes ha finalizado comparativamente más rápido. Por ejemplo, un P90 de 30 ms significa que 90% de todas las solicitudes han finalizado en 30 ms o menos.
Solicitudes por segundo (RPS)	Número de solicitudes completadas por segundo. Completado significa que se devuelve una respuesta desde el punto de conexión al cliente.

Requisitos de latencia

En función de los requisitos empresariales y de clientes, defina el rendimiento ideal de su sistema. En un punto de conexión de servicio del modelo, la latencia incluye el tiempo de ida y vuelta que un cliente experimenta al enviar datos para la inferencia. Esto incluye la latencia de red, así como el tiempo de inferencia. Es importante asegurarse de que los requisitos sean realistas. Por ejemplo, si el modelo tarda 15 ms en realizar la inferencia cuando se carga en la memoria, debe permitir más tiempo para la latencia de la red cuando se sirve en un punto de conexión para servir modelos.

¿Cómo se relacionan RPS, latencia y simultaneidad?

Una empresa tiene algunos criterios definidos para el éxito de su sistema. En el caso de los sistemas de ML, los criterios empresariales suelen ser de alta calidad, baja latencia y alto rendimiento. La calidad de los resultados está relacionada específicamente con el propio modelo, mientras que la latencia y el rendimiento de un extremo a otro son rasgos del sistema de servicio. La latencia de un extremo a otro consta del tiempo de ejecución del modelo y la sobrecarga de red. El rendimiento (o solicitudes o consultas por segundo) está relacionado inversamente con la latencia y directamente relacionada con la simultaneidad.

• Cuanto mayor sea la simultaneidad, mayor será el rendimiento.
• Cuanto mayor sea la latencia, menor será el throughout.

Por lo general, hay una relación óptima de simultaneidad del lado cliente con la simultaneidad del lado servidor para cualquier aplicación determinada. Por ejemplo, "cuántas hamburguesas puede un chef de línea preparar simultáneamente". Dado que puede haber muchos pasos compartidos en el proceso de cocción, el chef de línea podría ser capaz de cocinar de forma más óptima cuatro hamburguesas al mismo tiempo en lugar de cocinar solo una a la vez. Hay un límite para esta paralelización, en algún momento el acto de realizar muchos actos paralelos agrega demasiada latencia, como si el chef necesita agregar queso a 1000 hamburguesas.

Uno de los objetivos centrales de una prueba de carga es determinar la relación óptima para la aplicación. La relación óptima maximiza RPS, cumple los requisitos de latencia y evita la puesta en cola. Esta relación se puede usar para ajustar con precisión el tamaño del punto de conexión para satisfacer las cargas más exigentes.

Si el punto de conexión no puede procesar las solicitudes lo suficientemente rápido, una línea comienza a formarse. Esto se denomina cola. La formación de una cola suele dar lugar a una latencia de un extremo a otro mucho más larga, ya que ahora hay tiempo adicional que cada solicitud pasa esperando antes de procesarse. Si las solicitudes siguen llegando más rápido que las solicitudes se pueden procesar, la cola aumenta, lo que aumenta aún más la latencia. Por este motivo, es importante comprender qué tipo de demanda máxima puede experimentar el punto de conexión y asegurarse de que tiene el tamaño correcto con una prueba de carga.

Ejemplos de escenarios de prueba de carga

En las pruebas de carga, así como en los sistemas reales, la relación entre la simultaneidad del cliente, la simultaneidad del servidor y la latencia es dinámica e interdependiente. Veamos esta relación con un ejemplo sencillo:

Escenario 1: Configuración sencilla

En esta configuración, un único cliente envía solicitudes secuencialmente: espera una respuesta antes de emitir la siguiente solicitud. Dado que el tiempo total por solicitud es la suma de la ejecución del modelo y la latencia de sobrecarga (40 ms + 10 ms), la latencia de un extremo a otro medido es de 50 ms.

• Número de clientes: 1
• Simultaneidad aprovisionada: 1
• Latencia de sobrecarga: 10 ms
• Tiempo de ejecución del modelo 40 ms

Como resultado, el cliente completa una solicitud cada 50 ms, lo que equivale a 20 solicitudes por segundo o consultas por segundo.

Escenario 2: Incremento de la simultaneidad provisionada

En este caso, tiene el doble de simultaneidad aprovisionada y un único cliente que realiza solicitudes secuencialmente. Esto significa que la latencia total sigue siendo de 50 ms (40 ms + 10 ms) y el sistema solo ve 20 solicitudes por segundo (QPS).

• Número de clientes: 1
• Simultaneidad aprovisionada: 1 -> 2
• Latencia de sobrecarga: 10 ms
• Tiempo de ejecución del modelo 40 ms

Escenario 3: Agregar otro cliente al sistema.

Ahora tiene dos clientes que realizan solicitudes a un punto de conexión con dos simultaneidades aprovisionadas. En este caso, la solicitud de cada cliente se puede procesar de forma independiente mediante el punto de conexión simultáneamente (suponiendo un equilibrio de carga perfecto). Por lo tanto, aunque la latencia total sigue siendo de 50 ms (40 ms + 10 ms), el sistema observa 40 solicitudes por segundos, ya que cada cliente envía 20 qps.

• Número de clientes: 1 -> 2
• Simultaneidad aprovisionada: 2
• Latencia de sobrecarga: 10 ms
• Tiempo de ejecución del modelo 40 ms

Aumentar la simultaneidad aprovisionada y el número de clientes que realizan solicitudes aumenta el QPS (consultas por segundo) total observado en el sistema, sin afectar negativamente a la latencia.

Escenario 4: Permite reducir la simultaneidad aprovisionada

En este último escenario, el número de clientes es mayor que la simultaneidad aprovisionada. Esta configuración introduce otra variable, la cola, en el sistema y su efecto en el QPS y la latencia.

• Número de clientes: 2
• Concurrencia aprovisionada: 2 -> 1
• Latencia de sobrecarga: 10 ms
• Tiempo de ejecución del modelo: 40 ms

Aquí tiene dos clientes que realizan solicitudes simultáneamente. Sin embargo, el punto de conexión solo puede procesar una única solicitud a la vez. Esto obliga a la segunda solicitud a esperar antes de que se haya procesado la primera solicitud. La espera, o más correctamente, la puesta en cola de la segunda solicitud puede afectar negativamente a la latencia del sistema. Suponiendo que el servidor permite la puesta en cola (habilitada de forma predeterminada en Databricks Model Serving), el segundo cliente ve una latencia de 90 ms: 10 ms (sobrecarga de red) + 40 ms (tiempo de espera de puesta en cola) + 40 ms (tiempo de ejecución del modelo). Esto es significativamente peor que los 50 ms vistos antes.