Déploiement de modèles hautement performants

À mesure que les modèles d’apprentissage automatique (ML) s’améliorent avec le temps, leurs besoins en ressources changent également. Pour de meilleures performances, il est important que lors du déploiement de modèles ML via AI Center, les compétences soient correctement dimensionnées par rapport au trafic qu’elles doivent gérer. Dans la plupart des cas, l’infrastructure est dimensionnée par rapport au nombre de pages par unité de temps (minute ou heure). Un document peut comporter une ou plusieurs pages.

Introduction aux performances du modèle ML

Pour déployer une infrastructure via AI Center, il y a quelques aspects importants à garder à l’esprit pour des performances optimales.

GPU

Un seul type d’infrastructure GPU est disponible. Ceci est mis en évidence par la case à cocher pour activer le GPU. Chaque compétence s’exécute sur une seule machine virtuelle (MV) ou un seul nœud disposant d’un GPU. Dans ce cas, le processeur et la mémoire ne sont pas pertinents, car la compétence peut utiliser toutes les ressources de processeur et de mémoire disponibles sur ces nœuds. Outre le débit, le GPU est beaucoup plus rapide. Pour cette raison, si la latence est critique, il est recommandé d’utiliser le GPU.

Processeur

Le processeur et la mémoire peuvent être fractionnés, ce qui signifie que plusieurs compétences ML peuvent s’exécuter sur le même nœud. Pour éviter toute perturbation d’une compétence voisine, chaque compétence ML est limitée à la quantité de mémoire et de processeur qu’elle peut consommer, selon le niveau sélectionné. Un processeur plus élevé entraîne un traitement plus rapide (pour une page), tandis qu’une mémoire plus élevée entraîne un plus grand nombre de documents pouvant être traités.

Nombre de répliques

Le nombre de répliques détermine le nombre de conteneurs utilisés pour répondre aux requêtes du modèle ML. Un nombre plus élevé entraîne une plus grande quantité de documents pouvant être traités en parallèle, sous réserve des limites de ce niveau particulier. Le nombre de répliques est directement lié au type d’infrastructure (nombre de processeurs par réplique, ou si vous utilisez un GPU), au sens où les répliques et la taille de l’infrastructure peuvent affecter directement le débit (pages/minute).

Remarque :

Multiple replicas multiply the throughput.

Nombre de robots

Le nombre de robots a un impact sur le débit. Pour obtenir un débit efficace, le nombre de robots doit être dimensionné de manière à ne pas surcharger les compétences ML. Cela dépend de l’automatisation elle-même et doit être testé. En règle générale, vous pouvez utiliser un à trois robots comme point de départ pour chaque réplique que possède la compétence ML. Selon le temps de processus global (hors extracteur ML), le nombre de robots (ou le nombre de répliques) peut être supérieur ou inférieur.

Problèmes potentiels liés au dimensionnement de l’infrastructure

Si l’infrastructure n’est pas dimensionnée correctement, les modèles peuvent être soumis à une charge très élevée. Dans certains cas, cela peut entraîner un retour de demandes, un long délai de traitement, voire des échecs lors du traitement des documents.

Mémoire insuffisante

Insufficient memory most commonly encountered on the lower CPU tiers (0.5 CPU or 1 CPU). If you need to process a very large payload (one or several large documents), it can lead to an out of memory exception. This is related to the document size in terms of pages and text density (how much text there is per page). Since the requirements are very specific to each use case, it is not possible to provide exact numbers. You can check the guidelines in the Sizing the infrastructure correctly section for more detailed information. If you encounter an insufficient memory situation, the general recommendation is to go to the next tier.

Calcul insuffisant

Un calcul insuffisant fait référence à la fois au processeur et au GPU, bien qu’il soit plus couramment rencontré sur le processeur. Lorsque la compétence ML reçoit trop de pages par rapport à son débit disponible, les requêtes peuvent expirer (codes de statut 520 et 499), être renvoyées, ou même provoquer le plantage du modèle (codes de statut 503 et 500). Si vous rencontrez une situation de calcul insuffisante, nous vous recommandons de passer au niveau suivant, voire au niveau GPU.

Dimensionner correctement l’infrastructure

Directives générales

Cette section fournit des directives générales sur les performances des modèles selon chaque taille de compétence.

Important :

The calculations provided in this section are intended to be used only as general guidelines and should not be interpreted as exact specifications. Performance outcomes can vary and are influenced by different factors such as the size of the document, number of pages, and the specific model being utilized.

Remarque :

Each model generation (2022.10, 2023.4, or 2023.10) behaves differently in relation to resources required and throughput. As models become better in terms of accuracy, this can also impact the performance and demand more resources.

Table 1. 2022.10 Extractor

Niveau	Nombre maximum de pages/document	Débit prévu (pages/heure)	AI Units/heure
0,5 processeur/2 Go de mémoire	25	300-600	1
1 processeur/4 Go de mémoire	50	400-800	2
2 processeurs/8 Go de mémoire	100	600-1000	4
4 processeurs/16 Go de mémoire	100	800-1200	8
6 processeurs/24 Go de mémoire	100	900-1300	12
GPU	200-250	1350-1600	20

Table 2. 2023.4 Extractor

Niveau	Nombre maximum de pages/document	Débit prévu (pages/heure)	AI Units/heure
0,5 processeur/2 Go de mémoire	25	40-100	1
1 processeur/4 Go de mémoire	50	70-140	2
2 processeurs/8 Go de mémoire	75	120-220	4
4 processeurs/16 Go de mémoire	100	200-300	8
6 processeurs/24 Go de mémoire	100	250-400	12
GPU	200-250	1400-2200	20

Table 3. 2023.7 and later versions of extractors

Niveau	Nombre maximum de pages/document	Débit prévu (pages/heure)	AI Units/heure
0,5 processeur/2 Go de mémoire	25	60-200	1
1 processeur/4 Go de mémoire	50	120-240	2
2 processeurs/8 Go de mémoire	75	200-280	4
4 processeurs/16 Go de mémoire	100	250-400	8
6 processeurs/24 Go de mémoire	100	350-500	12
GPU	200-250	1000-2000	20

Le débit attendu est exprimé pour chaque réplique, en page/heure, et un débit minimum et maximum attendu, en fonction du document lui-même. La compétence ML doit être dimensionnée pour le débit le plus élevé attendu (pic), et non pour le débit moyen sur une journée, une semaine ou un mois.

Remarque :

When sizing the infrastructure, make sure to start from the largest document the skill needs to handle and the expected throughput.

Exemples

Exemple 1

La compétence ML doit traiter les éléments suivants à l’aide d’un extracteur 2023.10 :

• Documents contenant un maximum de cinq pages.
• Un pic maximum de 300 pages par heure.

Étant donné que le débit est inférieur et que la taille du document est petite, un GPU n’est pas nécessaire dans cet exemple. Deux à quatre répliques du niveau 0,5 CPU ou 1 CPU sont suffisantes.

Exemple 2

La compétence ML doit traiter les éléments suivants à l’aide d’un extracteur 2023.4 :

• Documents contenant 80 pages maximum.
• Un pic maximum de 900 pages par heure.

Pour cet exemple, trois répliques du niveau 4 du processeur ou un seul niveau du GPU sont suffisants.

Remarque :

A single replica does not have high availability, so it is always recommended to use at least two replicas for critical production workflows.

Exemple 3

La compétence ML doit traiter les éléments suivants à l’aide d’un extracteur 2023.10 :

• Documents contenant 50 pages maximum.
• Un pic maximum de 3 000 pages par heure.

Il y a deux façons de répondre à cette exigence :

• Utiliser 3 répliques de GPU.
• Utilisez 12 à 15 répliques du niveau 4 ou 6 processeurs.

Les deux options ont une haute disponibilité car il y a plus de deux répliques pour la compétence ML.

Dimensionner l’infrastructure pour une réplique

You can check the tables from the General guidelines section for the expected throughput from a single extraction replica, depending on the model version and the tier.

Remarque :

To achieve maximum throughput potential, you must keep the extraction replica under constant load.

Afin de s’assurer que la réplique soit continuellement opérationnelle, les critères suivants doivent être remplis :

• Idéalement, il doit y avoir un temps d’inactivité minimum entre le moment où la réplique envoie la réponse à une requête et le moment où la réplique reçoit les données de la requête suivante.
• La réplique ne doit pas être surchargée. Les requêtes sont traitées les unes après les autres (de façon sérielle). Cela signifie qu’il y aura toujours une requête active en cours de traitement et une file d’attente de requêtes en attente. Si cette file d’attente contient trop d’éléments, la réplique rejettera les nouvelles demandes entrantes et affichera un code de statut 429 (too many requests) HTTP.

Le point clé à retenir lorsque vous dimensionnez l’infrastructure pour une seule réplique consiste à s’assurer que la charge de travail soit équilibrée. Si la charge de travail est trop légère, la réplique restera inactive ; si elle est trop importante, des tâches commenceront à être rejetées.

Déterminer le nombre de répliques nécessaires

Pour déterminer le nombre de répliques requises, vous devez effectuer les opérations suivantes :

• Identifiez la période pertinente où les répliques sont les plus actives. Par exemple, vous devez identifier l’heure d’activité la plus importante, et non un pic d’une minute ni une plage de 12 heures. Après avoir identifié cette période, évaluez la demande (nombre de pages ou de requêtes) pendant cette période.
• Divide the estimate by the throughput per replica, described in the Size the infrastructure for one replica section.
• Par mesure de sécurité, ajoutez un peu de capacité en plus.

Veuillez noter que l’utilisation de la période où l’activité est la plus importante peut conduire à des ressources supérieures au besoin lorsque la demande est nettement plus faible. Pour résoudre ce problème, vous pouvez augmenter ou réduire manuellement la taille d’un déploiement en fonction de la demande. Cela peut être utile s’il existe un intervalle d’une heure où l’activité est très importante nécessitant 10 répliques, suivi de 23 heures d’activité plus faible pour lesquelles seules 2 répliques sont nécessaires. Cela peut conduire à un laps de temps important où les ressources du système sont supérieures aux besoins.

Mesurer la demande et l’approvisionnement : pages ou requêtes

Le nombre de pages et la densité de ces pages constituent des facteurs clés. En effet, le nombre de pages est plus pertinent que le nombre de requêtes. Cependant, sur le plan pratique, les requêtes sont plus faciles à compter.

Astuce :

You can use historical data to make this conversion easier. For a particular skill with a recorded history, you can check the metering telemetry to identify the distribution of page counts for requests made to that skill. For example, if a skill received mostly documents with two or three pages in the last month, you can assume the future trend will continue with an average of 2.5 pages per document.

Déterminer si un déploiement dispose de ressources suffisantes

Lorsque vous souhaitez déterminer si un déploiement dispose de ressources suffisantes, l’utilisation du processeur n’est pas pertinente, dans la mesure où chaque réplique va maximiser l’utilisation du processeur et du processeur graphique lors du traitement d’une requête, indépendamment de la file des requêtes en attente.

Le temps écoulé d’un bout à l’autre du processus est le facteur le plus important : c’est la somme entre le temps d’attente et le temps de traitement réel.

Par exemple, si vous avez choisi un plan avec un débit d’environ 900 pages/heure ou d’environ 4 secondes/page, et que vous envoyez des documents de 5 pages, cela devrait prendre environ 30 secondes par document.

Vous pouvez ensuite calculer un temps d’attente d’environ 10 secondes. Cela signifie qu’il y aura un temps d’attente (ce qui signifie que la requête n’est pas instantanément prise en compte par la réplique, car celle-ci est occupée à traiter les requêtes préexistantes). Cela a également indiqué que ce temps d’attente était d’environ 10 secondes.

Si la différence entre la durée de bout en bout réelle (la durée mesurée) et la durée de bout en bout attendue (estimée en fonction du niveau de votre plan) est supérieure à zéro, cela signifie que la réplique fonctionne en continu. Par ailleurs, si le temps d’attente augmente à mesure que la demande augmente, il est clair que le déploiement est soumis à une pression importante. Enfin, tous les codes de statut 429 (nombre de requêtes trop important) sont un signe de ressources insuffisantes par rapport aux besoins.

Déterminer si les paramètres d'un déploiement sont supérieurs aux besoins

Les sections précédentes peuvent aider à déterminer si le déploiement est efficacement alimenté, mais nous vous recommandons de suivre les étapes suivantes pour une analyse détaillée de votre déploiement :

• Identifiez la période où l’activité est la plus importante. Pour les besoins de notre exemple, imaginons que la durée soit d’une heure ou 3600 secondes.
• Prenons le nombre actuel de répliques : imaginons qu’il soit de 10. Cela donne 36 000 « secondes-répliques » (concept similaire à « heure-personne »).
• Calculez la durée totale des demandes (somme des heures de bout en bout). Supposons que cette somme soit 10 000 secondes.

Dans cet exemple, étant donné que 10 000 est inférieur à 36 000, cela signifie que votre infrastructure actuelle est supérieure à vos besoins. Vous pouvez essayer de réduire le déploiement à huit répliques et surveiller les performances : si tout fonctionne correctement, vous pouvez réduire à six répliques. Réévaluez les performances à chaque ajustement.