Tests de charge pour les Serving Endpoint
Cet article vous guide à travers le processus essentiel de test de charge de vos endpoints de Model Serving pour vous assurer qu'ils peuvent gérer efficacement les charges de travail de production. Il fournit également des exemples pratiques, des analogies du monde réel et des instructions étape par étape à l'aide du framework de test de charge Locust, pour démontrer comment mesurer les métriques de performance clés comme les requêtes par seconde et les limites de concurrence, afin que vous puissiez dimensionner correctement vos Endpoint et déployer en toute confiance des modèles pour vos besoins commerciaux.
Les tests de charge sont un composant essentiel de l'optimisation de la production. Pour un guide complet des stratégies d'optimisation, y compris les optimisations d'infrastructure, de modèle et côté client, consultez Optimiser les Endpoint Model Serving pour la production.
Qu'est-ce qu'un test de charge ?
Un test de charge est un test qui simule l'utilisation réelle des endpoints Model Serving en s'assurant qu'ils répondent à vos exigences de production, comme la latence ou le nombre de requêtes par seconde. Un test de charge mesure les performances de votre Endpoint sous différents niveaux de trafic, vous aidant à dimensionner correctement votre Endpoint afin de ne pas causer de retards.
Imaginez la scène : il est 8 h 00 en semaine et un café populaire au cœur de la ville vient tout juste d'ouvrir. L’arôme du café frais emplit l’air. Le barista est préparé, les machines sont mises en route, et la file de clients en manque de caféine se forme déjà.
Au début, les choses se déroulent sans heurts. Quelques clients s'approchent, passent leurs commandes et le barista commence à préparer leurs boissons. Certaines boissons prennent 30 secondes, d'autres une minute – selon la complexité. Le barista gère plusieurs commandes avec une efficacité éprouvée.
Mais bientôt, plus de personnes arrivent. Cinq clients se transforment en dix, puis en vingt. Chacun passe une commande, attend sa boisson et discute peut-être un peu au comptoir. Le barista est maintenant sous pression. Même avec un deuxième barista qui intervient, le système start à se tendre, la file s’allonge, les commandes s’accumulent et les clients commencent à attendre plus longtemps.
Imaginez maintenant que vous essayez de mesurer combien de boissons le café peut servir par minute avant que les clients ne start à partir frustrés. Ce sont les tests de charge .
Dans cette analogie :
- Chaque client est un client qui envoie une demande.
- Les barista(s) 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 de **mise en œuvre du modèle**.
- Les retards de discussion, de paiement ou de recherche de la commande correspondent à votre **charge réseau**.
- L’arrivée simultanée de nombreux clients correspond à la simultanéité des clients .
- Ajouter plus de baristas ou plus de machines revient à augmenter votre concurrence de serveur .
Comme dans tout bon café, la quantité de travail que le personnel peut gérer en même temps est limitée. Si vous ne planifiez pas à l'avance — par exemple, en recrutant plus de baristas pendant les heures de pointe —, les gens s'en vont mécontents. Il en va de même pour vos systèmes sous charge. Les tests de charge vous aident à identifier les goulets d'étranglement, la quantité de trafic que votre système peut gérer et les modifications que vous devez apporter pour un service plus fluide.
Avant d’exécuter un test de charge sur votre endpoint, vous devez :
- Comprendre les composants et concepts liés aux tests de charge.
- Décidez et définissez vos exigences de production.
- Trouvez une charge utile représentative pour le framework de test de charge à utiliser lors de l'évaluation de votre endpoint.
Concepts et définitions des tests de charge
Le tableau suivant définit les concepts liés aux tests de charge :
Concept | Description |
|---|---|
Simultanéité des clients (nombre de clients) | Le nombre total de clients qui envoient simultanément des requêtes en parallèle à un endpoint. Ce sont vos clients du café dans l'exemple ci-dessus. Production : Le nombre total d'instances de clients envoyant du trafic vers l'endpoint de service de modèle. Test de charge : dans Locust, il s'agit du nombre d'utilisateurs créés qui envoient du trafic vers l'endpoint de déploiement de modèles testé en charge. |
Simultanéité des Endpoint | Le nombre de processus d'inférence ou d'instances de modèle pouvant traiter les requêtes entrantes. Peut également être exprimé comme le nombre de requêtes pouvant être gérées simultanément par votre Endpoint. C'est le nombre de baristas dans l'exemple ci-dessus. Model Serving : les Endpoint de Model Serving peuvent être configurés pour des tailles de montée en charge de compute. Par exemple, l'utilisation de la taille |
Latence | Le temps (en millisecondes) nécessaire à l'achèvement d'une requête aller-retour complète. Mesure du temps total écoulé entre l'envoi d'une requête par le client et la réception de la réponse, incluant le temps d'exécution de l'Endpoint et la latence réseau. |
Latence PXX (P50, P90, P99) | La latence (en millisecondes) pour laquelle XX centile des requêtes s'est terminé plus rapidement que. Par exemple, un P90 de 30 ms signifie que 90 % de toutes les requêtes se sont terminées en 30 ms ou moins. |
Requêtes par seconde (RPS) | Le nombre de requêtes terminées par seconde. Terminé signifie qu'une réponse est renvoyée de l'Endpoint au client. |
Exigences de latence
En fonction de vos exigences commerciales et de celles de vos clients, définissez la performance idéale de votre système. Sur un Endpoint de service de modèle, la latence inclut le temps d'aller-retour qu'un client subit lors de l'envoi de données pour inférence. Cela inclut la latence du 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 prévoir un délai supplémentaire pour la latence réseau lorsqu'il est servi sur un endpoint de diffusion de modèle.
Comment le RPS, la latence et la simultanéité sont-ils liés ?
Une entreprise a des critères définis pour le succès de son système. Pour les systèmes ML, les critères commerciaux sont généralement des résultats de haute qualité, une faible latence et un haut throughput. 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 throughput 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 du surcoût réseau. Le Throughput (ou les requêtes par seconde) est inversement lié à la latence et directement lié à la concurrence.
- Plus la concurrence est élevée, plus le throughput est important.
- Plus la latence est élevée, plus le débit est bas.
Généralement, il existe un rapport optimal de concurrence côté client par rapport à la concurrence côté serveur pour toute application donnée. À titre d'exemple, « combien de burgers un chef de ligne peut-il préparer simultanément ? » Puisqu'il peut y avoir de nombreuses étapes partagées dans le processus de cuisson, le chef de ligne pourrait être en mesure de cuire de manière plus optimale quatre hamburgers en même temps plutôt que d'en cuire un seul à la fois. Il existe une limite à cette parallélisation ; à un certain point, l'exécution de nombreux actes parallèles ajoute trop de latence, comme si le chef devait ajouter du fromage à 1000 hamburgers.
L'un des objectifs centraux d'un test de charge est de déterminer le ratio optimal pour votre application. Le ratio optimal maximise les RPS, répond à vos exigences en matière de latence et évite la mise en file d'attente. Ce rapport peut être utilisé pour dimensionner avec précision votre Endpoint afin de répondre à vos charges les plus exigeantes.
Si l'Endpoint ne peut pas traiter les requêtes assez rapidement, une file d'attente commence à se former. C'est ce qu'on appelle 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 chaque requête passe désormais plus de temps à attendre d'être traitée. Si les requêtes continuent d'arriver plus vite qu'elles ne peuvent être traitées, la file d'attente s'allonge, ce qui augmente encore la latence. Pour cette raison, il est important de comprendre le type de demande maximale que votre Endpoint peut connaître et de vous assurer qu'il est correctement dimensionné avec un test de charge.
Exemples de scénarios de test de charge
Dans les tests de charge, ainsi que dans les systèmes réels, la relation entre la simultanéité client, la simultanéité serveur et la latence est dynamique et interdépendante. Voyons cette relation avec un exemple simple :
Scénario 1 : Configuration simple.
Dans cette configuration, un client unique envoie les requêtes séquentiellement — il attend une réponse avant d'émettre la requête suivante. Puisque 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
- Simultanéité provisionnée : 1
- Latence supplémentaire : 10 ms
- Temps d'exécution du modèle 40 ms
En conséquence, le client effectue une requête toutes les 50 ms, ce qui équivaut à 20 requêtes par seconde ou query par seconde.
Scénario 2 : augmenter la simultanéité provisionnée
Dans ce cas, vous avez le double de la simultanéité provisionnée et un seul client effectue des requêtes séquentiellement. Cela signifie que la latence totale est toujours de 50 ms (40 ms + 10 ms), et le système ne voit que 20 requêtes par seconde (QPS).
- Nombre de clients : 1
- Simultanéité provisionnée : 1 -> 2
- Latence supplémentaire : 10 ms
- Temps d'exécution du modèle 40 ms
Scénario 3 : Ajouter un autre client au système.
Vous avez maintenant deux clients qui effectuent des requêtes vers un endpoint avec deux simultanéités provisionnées. Dans ce cas, chaque requête client peut être traitée indépendamment par l'endpoint simultanément (en supposant un équilibrage de charge parfait). Ainsi, tandis que la latence totale est toujours de 50 ms (40 ms + 10 ms), le système observe 40 requêtes par seconde, puisque chaque client envoie 20 qps.
- Nombre de clients : de 1 à 2
- Simultanéité provisionnée : 2
- Latence supplémentaire : 10 ms
- Temps d'exécution du modèle 40 ms
L'augmentation de la concurrence provisionnée et du nombre de clients effectuant des requêtes augmente le QPS total observé dans votre système, sans pénalité sur la latence.
Scénario 4 : Réduisons 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, la mise en file d'attente, dans le système et son effet sur le QPS et la latence.
- Nombre de clients : 2
- Simultanéité provisionnée : 2 -> 1
- Latence supplémentaire : 10 ms
- Temps d'exécution du modèle : 40 ms
Ici, vous avez deux clients effectuant des requêtes simultanément. L'Endpoint, cependant, ne peut traiter qu'une seule requête à la fois. Cela force la deuxième requête à attendre que la première requête 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 default dans Databricks Model Serving), le deuxième client constate une latence de 90 ms : 10 ms (charge réseau) + 40 ms (temps d'attente en file d'attente) + 40 ms (temps d'exécution du modèle). Ceci est nettement pire que les 50 ms observées précédemment.