Test de charge pour les points de terminaison de service

Cet article vous guide tout au long du processus essentiel de test de charge de vos points de terminaison pour le déploiement de modèles d’IA Mosaic afin de vous assurer qu'ils soient capables de gérer efficacement les charges de travail en production. Il fournit également des exemples pratiques, des analogies réelles et des instructions pas à pas à l’aide de l’infrastructure de test de charge locust, pour montrer comment mesurer les métriques de performances clés telles que les demandes par seconde et les limites d’accès concurrentiel, afin de pouvoir dimensionner vos points de terminaison correctement et en toute confiance déployer des modèles pour vos besoins métier.

Qu’est-ce qu’un test de charge ?

Un test de charge est un test qui simule l’utilisation réelle du modèle Mosaic AI pour desservir les points de terminaison, garantissant qu'ils répondent à vos besoins de production, comme la latence ou les requêtes par seconde. Un test de charge mesure les performances de votre point de terminaison sous différents niveaux de trafic, ce qui vous permet de dimensionner correctement votre point de terminaison afin de ne pas provoquer de retards.

Il est 8h00 en semaine, et un café populaire au cœur de la ville vient d'ouvrir. L’arôme du café frais remplit l’air. Le barista est prêt, les machines chauffées, et la file de clients en manque de caféine se forme déjà.

Au début, les choses s’exécutent sans problème. Un couple de clients s'approchent, passent leurs commandes, et le barista commence à préparer des boissons. Certaines boissons prennent 30 secondes, d’autres prennent une minute , en fonction de la complexité. Le barista jongle avec plusieurs commandes avec une efficacité d’expert.

Mais bientôt, plus de gens arrivent. Cinq clients se transforment en dix, puis vingt. Chacun passe une commande, attend son verre et peut-être bavarder un peu au comptoir. Le barista est maintenant sous pression. Même avec un deuxième barista intervenant, le système commence à être sous pression — la file s'allonge, les commandes s’empilent, et les clients commencent à attendre plus longtemps.

Imaginez maintenant que vous essayez de mesurer le nombre de boissons que le café peut servir par minute avant que les clients commencent à partir frustrés. C’est le test de charge.

Dans cette analogie :

• Chaque client est un client qui envoie une demande.
• Les baristas représentent votre serveur qui traite les inférences de modèle une par une ou en parallèle.
• Le temps nécessaire pour prendre une commande et servir la boisson est le temps d’implémentation du modèle .
• Les retards de conversation, de paiement ou de recherche de la commande sont votre surcharge réseau.
• L'arrivée simultanée de plusieurs clients est la concurrence des clients.
• L’ajout de baristas ou de machines supplémentaires ressemble à augmenter la concurrence de votre serveur.

Comme dans n’importe quel bon café, il y a une limite à combien le personnel peut gérer à la fois. Si vous ne planifiez pas à l'avance, par exemple en prévoyant plus de baristas pendant les heures de pointe, les gens partent mécontents. Il en va de même pour vos systèmes sous charge. Le test de charge vous aide à identifier l’emplacement des goulots d’étranglement, la quantité de trafic que votre système peut gérer et les modifications dont vous avez besoin pour faciliter le service.

Avant d’exécuter un test de charge sur votre point de terminaison, vous devez :

• Comprendre les composants et concepts liés aux tests de charge.
• Déterminez et définissez vos besoins en production.
• Recherchez une charge utile représentative pour le cadre de test de charge à utiliser lors du benchmarking de votre point de terminaison.

Concepts et définitions de test de charge

Le tableau suivant définit les concepts liés aux tests de charge :

Exigences en matière de latence

En fonction de vos besoins métier et clients, définissez les performances idéales de votre système. Sur un point de terminaison de mise en service de modèles, la latence inclut le temps d’aller-retour qu’un client subit lors de l’envoi des données pour une inférence. Cela inclut la latence réseau ainsi que le temps d’inférence. Il est important de s’assurer que vos exigences sont réalistes. Par exemple, si votre modèle prend 15 ms pour effectuer une inférence lorsqu’il est chargé en mémoire, vous devez autoriser un temps supplémentaire pour la latence réseau lorsqu’il est servi sur un point de terminaison de service de modèle.

Comment les relations RPS, latence et concurrence sont-elles liées ?

Une entreprise a des critères définis pour la réussite de son système. Pour les systèmes ML, les critères métier sont généralement des résultats de haute qualité, une faible latence et un débit élevé. La qualité des résultats est spécifiquement liée au modèle lui-même, tandis que la latence de bout en bout et le débit sont des caractéristiques du système de service. La latence de bout en bout se compose du temps d’exécution du modèle et de la surcharge réseau. Le débit (ou les requêtes ou demandes par seconde) est inversement lié à la latence et directement lié à la simultanéité.

• Plus la concurrence est élevée, plus le débit est élevé.
• Plus la latence est élevée, plus le débit est faible.

En règle générale, il existe un ratio optimal de concurrence côté client à la concurrence côté serveur pour toute application donnée. Par exemple, « combien de hamburgers peut préparer simultanément un chef de ligne ». Étant donné qu’il peut y avoir beaucoup d’étapes partagées dans le processus de cuisson, le chef de ligne peut être en mesure de cuire plus de façon optimale quatre hamburgers en même temps plutôt que de cuire un seul à la fois. Il existe une limite à cette parallélisation, à un moment donné, l’acte d’exécution de nombreux actes parallèles ajoute trop de latence, comme si le chef doit ajouter du fromage à 1000 hamburgers.

L’un des objectifs centraux d’un test de charge consiste à déterminer le ratio optimal pour votre application. Le ratio optimal optimise rpS, répond à vos exigences de latence et évite la mise en file d’attente. Ce ratio peut être utilisé pour dimensionner avec précision votre point de terminaison pour répondre à vos charges les plus exigeantes.

Si le point de terminaison ne parvient pas à traiter les demandes suffisamment rapidement, une ligne commence à se former. Il s’agit d’une file d’attente. La formation d’une file d’attente entraîne généralement une latence de bout en bout beaucoup plus longue, car il y a maintenant un temps supplémentaire pendant lequel chaque requête passe en attente avant d’être traitée. Si les requêtes continuent d’arriver plus rapidement que les requêtes peuvent être traitées, la file d’attente augmente, ce qui augmente encore la latence. Pour cette raison, il est important de comprendre le type de demande maximale que votre point de terminaison peut rencontrer et de s’assurer qu’il est correctement dimensionné avec un test de charge.

Exemples de scénario de test de charge

Dans les tests de charge, ainsi que les systèmes réels, la relation entre la concurrence cliente, la concurrence du serveur et la latence sont dynamiques et interdépendantes. Voyons cette relation avec un exemple simple :

Scénario 1 : Configuration simple

Dans cette configuration, un seul client envoie des requêtes de manière séquentielle : il attend une réponse avant d’émettre la requête suivante. Étant donné que le temps total par requête est la somme de l’exécution du modèle et de la latence de surcharge (40 ms + 10 ms), la latence de bout en bout mesurée est de 50 ms.

• Nombre de clients : 1
• Concurrence provisionnée : 1
• Latence de surcharge : 10 ms
• Durée d’exécution du modèle 40 ms

Par conséquent, le client termine une demande toutes les 50 ms, ce qui équivaut à 20 requêtes ou demandes par seconde.

Scénario 2 : Augmenter la concurrence provisionnée

Dans ce cas, vous avez double l’accès concurrentiel provisionné et un seul client qui effectue des requêtes de manière séquentielle. Cela signifie que la latence totale est toujours de 50 ms (40 ms + 10 ms) et que le système ne voit que 20 requêtes par seconde (QPS).

• Nombre de clients : 1
• Concurrence provisionnée : 1 -> 2
• Latence de surcharge : 10 ms
• Durée d’exécution du modèle 40 ms

Scénario 3 : Ajouter un autre client au système.

Vous disposez maintenant de deux clients qui effectuent des requêtes à un point de terminaison avec deux accès concurrentiels provisionnés. Dans ce cas, la requête de chaque client peut être traitée indépendamment par le point de terminaison simultanément (en supposant un équilibrage de charge parfait). Ainsi, alors que la latence totale est toujours de 50 ms (40 ms + 10 ms), le système observe 40 requêtes par seconde, car chaque client envoie 20 qps.

• Nombre de clients : 1 à> 2
• Concurrence provisionnée : 2
• Latence de surcharge : 10 ms
• Durée d’exécution du modèle 40 ms

L’augmentation de l’accès concurrentiel provisionné et du nombre de clients effectuant des requêtes augmente le nombre total de RPS observées dans votre système, sans pénalité sur la latence.

Scénario 4 : Permet de réduire la concurrence provisionnée

Dans ce dernier scénario, le nombre de clients est supérieur à la simultanéité provisionnée. Cette configuration introduit une autre variable, mise en file d’attente, dans le système et son effet sur QPS et la latence.

• Nombre de clients : 2
• Concurrence provisionnée : 2 -> 1
• Latence de surcharge : 10 ms
• Durée d’exécution du modèle : 40 ms

Ici, vous avez deux clients qui effectuent des demandes simultanément. Toutefois, le point de terminaison ne peut traiter qu’une seule requête à la fois. Cela force la deuxième requête à attendre avant que la première demande ait été traitée. L’attente, ou plus correctement, la mise en file d’attente de la deuxième requête peut affecter négativement la latence du système. En supposant que le serveur autorise la mise en file d’attente (activée par défaut dans Databricks Model Serving), le deuxième client voit une latence de 90 ms : 10 ms (surcharge réseau) + 40 ms (temps d’attente de mise en file d’attente) + 40 ms (temps d’exécution du modèle). Cela est nettement pire que les 50 ms vus avant.