Avec un nombre croissant de grands modèles de langage (LLM) proposés, le choix du modèle qui répond le mieux à vos besoins est crucial pour le succès de votre stratégie d’IA générative. Un mauvais choix peut consommer beaucoup de temps et de ressources et peut même conduire à la conclusion prématurée que l’IA ne peut pas, en fait, améliorer l’efficacité et la productivité de votre organisation.
Bien qu’il existe plusieurs façons de déterminer les capacités d’un LLM, telles que l’analyse comparative, comme détaillé dans notre guide précédent, l’une des méthodes les plus applicables à une utilisation dans le monde réel consiste à mesurer l’inférence d’un modèle. c’est-à-dire à quelle vitesse il génère des réponses.
Dans cette optique, ce guide explore la surveillance des performances de l’inférence LLM, notamment le fonctionnement de l’inférence, les mesures utilisées pour mesurer la vitesse d’un LLM et les performances de certains des modèles les plus populaires du marché.
Qu’est-ce que la surveillance des performances d’inférence LLM et pourquoi est-elle importante ?
L’inférence LLM est le processus de saisie d’une invite et de génération d’une réponse à partir d’un LLM. Cela implique qu’un modèle de langage tire des conclusions ou fasse des prédictions pour générer un résultat approprié basé sur les modèles et les relations auxquels il a été exposé pendant la formation.
Par la suite, la surveillance des performances d’inférence LLM est le processus de mesure de la vitesse et des temps de réponse d’un modèle. Mesurer l’inférence LLM est essentiel car il vous permet d’évaluer l’efficacité, la fiabilité et la cohérence d’un LLM – qui sont tous des aspects cruciaux pour déterminer sa capacité à fonctionner dans des scénarios du monde réel et à fournir la valeur souhaitée dans un délai acceptable. À l’inverse, l’insuffisance des moyens pour évaluer correctement les LLM laisse les organisations et les individus dans des angles morts et dans l’incapacité de distinguer correctement un modèle d’un autre. Cela entraînera probablement une perte de temps et de ressources à long terme, car un modèle de langage s’avère inadapté au cas d’utilisation prévu.
Comment fonctionne l’inférence LLM
Pour mieux comprendre les métriques utilisées pour mesurer la latence d’un modèle, examinons d’abord brièvement comment un LLM effectue l’inférence, qui implique deux étapes : une phase de pré-remplissage et une phase de décodage.
Premièrement, lors de la phase de pré-remplissage, le LLM doit traiter le texte de l’invite de saisie d’un utilisateur en le convertissant en une série d’invites, ou de jetons d’entrée. Un jeton est une unité de texte qui représente un mot ou une partie de mot. Pour la langue anglaise, un jeton comporte 0,75 mot, soit quatre caractères. Le mécanisme exact qu’un LLM utilise pour diviser le texte en jetons, c’est-à-dire son tokeniseur, varie selon les modèles. Une fois généré, chaque jeton est transformé en une intégration vectorielle, une représentation numérique que le modèle peut comprendre et à partir de laquelle faire des inférences. Ces intégrations sont ensuite traitées par le LLM afin de générer une sortie appropriée pour l’utilisateur.
À partir de là, pendant la phase de décodage, le LLM génère une série d’intégrations vectorielles qui représentent sa réponse à l’invite de saisie donnée. Ceux-ci sont ensuite convertis en jetons d’achèvement ou de sortie, qui sont générés un par un jusqu’à ce qu’ils atteignent un critère d’arrêt, tel que le nombre limite de jetons ou l’un d’une liste de mots vides. À ce moment-là, il générera un jeton de fin spécial pour signaler la fin de la génération du jeton. Comme les LLM génèrent un jeton par propagation directe, c’est-à-dire par passe ou itération, le nombre de propagations dont un modèle a besoin pour compléter une réponse est le même que le nombre de jetons d’achèvement.
Quelles sont les mesures de performances d’inférence LLM les plus importantes ?
Pour évaluer les capacités d’inférence d’un grand modèle de langage, les métriques qui nous intéressent le plus sont la latence et le débit .
Latence
La latence est une mesure du temps nécessaire à un LLM pour générer une réponse à l’invite d’un utilisateur. Il fournit un moyen d’évaluer la vitesse d’un modèle de langage et est principalement responsable de la formation de l’impression de l’utilisateur sur la rapidité ou l’efficacité d’une application d’IA générative. Par conséquent, une faible latence est importante pour les cas d’utilisation impliquant des interactions en temps réel, tels que les chatbots et les copilotes d’IA, mais moins pour les processus hors ligne. Il existe plusieurs façons de mesurer la latence d’un modèle, notamment :
- Temps jusqu’au premier jeton (TTFT) :
- Temps par jeton de sortie (TPOT)
- Temps de génération total
TTFT est le temps nécessaire à l’utilisateur pour commencer à recevoir une réponse d’un modèle après avoir saisi son invite. Il est déterminé par le temps nécessaire pour traiter la saisie de l’utilisateur et générer le premier jeton d’achèvement. Les facteurs qui influencent le TFTT comprennent :
- Vitesse du réseau : bande passante générale d’un système et, de la même manière, degré de congestion du réseau au moment de l’inférence.
- Longueur de la séquence d’entrée : plus l’invite est longue, plus le modèle nécessite de traitement avant de pouvoir générer le premier jeton.
- Taille du modèle : classiquement, plus le modèle est grand, c’est-à-dire plus il possède de paramètres, plus il effectue de calculs pour générer une réponse, ce qui prolonge le TFTT.
TPOT , alternativement, est le temps moyen nécessaire pour générer un jeton d’achèvement pour chaque utilisateur interrogeant le modèle à un moment donné. Cela peut aussi parfois être appelé latence inter-jetons (ITL).
Le temps de génération total fait référence à la latence de bout en bout d’un LLM : à partir du moment où une invite est initialement saisie par l’utilisateur jusqu’au moment où il reçoit la sortie complète du modèle ; souvent, lorsque les gens font référence à la latence, ils font en réalité référence à la durée totale d’une génération. Il peut être calculé comme suit :
- Temps de génération total = TTFT + (TPOT x nombre de tokens générés)
La durée totale de génération d’un LLM varie en fonction d’un certain nombre de facteurs clés :
- Longueur de sortie : c’est le facteur le plus important car les modèles génèrent une sortie jeton à la fois. C’est aussi pourquoi le TPOT du LLM doit également être mesuré.
- Temps de pré-remplissage : le temps nécessaire au modèle pour terminer l’étape de pré-remplissage, c’est-à-dire combien de temps il faut au modèle pour traiter tous les jetons d’entrée à partir de l’invite saisie par l’utilisateur et pouvoir générer le premier jeton d’achèvement.
- Temps d’attente : il peut arriver qu’un LLM ne puisse pas répondre aux demandes des utilisateurs en raison de ses contraintes matérielles, à savoir un manque de mémoire GPU. Cela signifie que certaines demandes d’entrée seront placées dans une file d’attente avant d’être traitées. C’est la raison pour laquelle TTFT est une métrique si couramment enregistrée, car elle donne un aperçu de la capacité du serveur du modèle à gérer un nombre variable de demandes d’utilisateurs et, par la suite, de ses performances dans un environnement réel.
Un autre élément à prendre en compte lors de la mesure de la latence est le concept de démarrage à froid. Lorsqu’un LLM est invoqué après avoir été précédemment inactif, c’est-à-dire mis à l’échelle à zéro, il provoque un démarrage « à froid » car le serveur du modèle doit créer une instance pour traiter la requête. Cela a un effet considérable sur les mesures de latence, en particulier sur le TFTT et le temps de génération total. Il est donc crucial de noter si les résultats publiés de la surveillance des inférences pour un modèle précisent s’ils incluent ou non un temps de démarrage à froid.
Débit
Le débit d’un LLM fournit une mesure du nombre de requêtes qu’il peut traiter ou de la quantité de résultats qu’il peut produire dans un laps de temps donné. Le débit est généralement mesuré de deux manières : requêtes par seconde ou jetons par seconde.
- Requêtes par seconde : cette métrique dépend du temps de génération total du modèle et du nombre de requêtes effectuées en même temps, c’est-à-dire de la manière dont le modèle gère la concurrence. Cependant, la durée totale de génération varie en fonction de la durée des entrées et des sorties du modèle.
- Jetons par seconde : étant donné que les requêtes par seconde sont influencées par le temps total de génération, qui lui-même dépend de la durée de la sortie du modèle et, dans une moindre mesure, de son entrée, les jetons par seconde sont une métrique plus couramment utilisée pour mesurer le débit. Tout comme TFTT, la métrique de jetons par seconde fait partie intégrante de la vitesse perçue d’un LLM.
De plus, les jetons par seconde peuvent faire référence à :
- Nombre total de jetons par seconde : jetons d’entrée et de sortie
- Jetons de sortie par seconde : uniquement les jetons d’achèvement générés
En règle générale, le nombre total de jetons par seconde est considéré comme la mesure la plus définitive du débit du modèle, tandis que les jetons de sortie par seconde sont applicables à la mesure des performances des LLM destinés à être utilisés dans des applications en temps réel.
Requête par lots
L’une des méthodes les plus efficaces et de plus en plus utilisées pour augmenter le débit d’un LLM est le traitement par lots. Au lieu de charger les paramètres du modèle pour chaque invite utilisateur, le traitement par lots implique de collecter autant d’entrées que possible à traiter en même temps – les paramètres doivent donc être chargés moins fréquemment. Cependant, même si cela permet d’utiliser le GPU de la manière la plus efficace et d’améliorer le débit, cela se fait au détriment de la latence : les utilisateurs qui ont effectué les requêtes initiales constituant un lot devront attendre qu’elles soient traitées pour recevoir une réponse. De plus, plus la taille du lot est grande, plus la baisse de latence est importante, bien qu’il existe des limites à la taille maximale d’un lot avant de provoquer un débordement de mémoire.
Les types de techniques de traitement par lots comprennent :
- Traitement par lots statique : également appelé traitement par lots naïf, il s’agit de la méthode de traitement par lots par défaut avec laquelle plusieurs invites sont rassemblées et les réponses ne sont générées que lorsque toutes les demandes du lot sont terminées.
- Traitement par lots continu : également appelé traitement par lots en vol ; au lieu d’attendre que toutes les invites d’un lot soient complétées, cette forme de traitement par lots regroupe les requêtes au niveau de l’itération. Par conséquent, une fois qu’une requête est terminée, une nouvelle peut la remplacer, ce qui la rend plus efficace en termes de calcul.
Quels sont les défis de la surveillance des performances d’inférence LLM ?
Même s’il est avantageux d’avoir un aperçu de la latence et des débits d’un modèle, l’obtention de ces données n’est pas toujours simple. Certains des défis associés à la mesure de l’inférence LLM comprennent :
- Manque de cohérence des tests : il peut y avoir des différences dans la manière dont les tests d’inférence sont effectués, comme le type de GPU (et la quantité utilisée), le nombre et la nature des invites, si le LLM est déduit localement ou via une API, etc. peuvent tous affecter les métriques d’inférence d’un modèle et rendre difficile les comparaisons à l’identique, car les tests ont été effectués dans des conditions différentes.
- Différentes longueurs de jetons par modèle : les tests de performances d’inférence présentent généralement des résultats en termes de métriques basées sur les jetons, par exemple, les jetons par seconde, mais les longueurs des jetons varient selon le LLM. Cela signifie que les métriques ne sont pas toujours comparables entre les types de modèles.
- Manque de données : tout simplement, les mesures d’inférence peuvent ne pas être disponibles pour des modèles particuliers car elles n’ont pas été publiées par leurs fournisseurs – et personne ne les a encore suffisamment testées.
Comment les LLM populaires fonctionnent-ils sur ces mesures ?
Maintenant que nous avons expliqué comment les LLM effectuent l’inférence et comment elle est mesurée, tournons notre attention vers la manière dont certains des modèles les plus populaires obtiennent des résultats sur diverses mesures d’inférence.
Pour commencer, examinons les tests effectués par le centre de recherche sur l’IA Artifical Analysis , qui publie des tests de performance et de référence en cours pour une collection de LLM largement utilisés. Bien que le site publie une grande variété de métriques d’inférence, nous nous concentrons sur trois :
- Débit (jetons par seconde)
- Latence (temps de réponse total (TRT)) : dans ce cas, le nombre de secondes nécessaires pour sortir 100 tokens
- Latence ( temps jusqu’au premier morceau (TTFC)) : le site choisit d’utiliser TFCC plutôt que TFTT, car certains hôtes d’API envoient des morceaux de jetons plutôt qu’individuellement.
Une autre remarque importante est que pour les métriques TRT et TFCR, à l’exception de Gemini Pro, Claude 2.0 et Mistral Medium, les chiffres ci-dessous sont la moyenne moyenne sur plusieurs hôtes d’API. Dans le cas des trois modèles OpenAI GPT, il s’agit de la moyenne de deux hôtes API, OpenAI et Azure. En revanche, pour Mixtral 8x7B et Llama 2 Chat, la moyenne provient respectivement de huit et neuf fournisseurs d’hébergement d’API.
| Modèle | Débit (jetons par seconde) | Latence (TRT) (secondes) | Latence (TFCR) (secondes) |
| Mixtral 8x7B | 95 | 2,66 | 0,6 |
| GPT-3.5 Turbo | 92 | 1,85 | 0,65 |
| Pour les Gémeaux | 86 | 3.6 | 2.6 |
| Lama 2 Chat (70B) | 82 | 3.16 | 0,88 |
| Claude 2.0 | 27 | 4.8 | 0,9 |
| GPT-4 | 22 | 7h35 | 1.9 |
| GPT-4 Turbo | 20 | 7.05 | 1.05 |
| Mistral moyen | 19 | 6.2 | 0,3 |
En plus du résumé fourni ci-dessus, le site propose d’autres mesures d’inférence, notamment la latence et le débit dans le temps, ainsi que les coûts d’inférence.
Le site GTP For Work propose un tracker de latence qui surveille en permanence les performances des API pour plusieurs modèles d’OpenAI et Azure OpenAI (GPT-4 et GPT-3.5 et Anthropic (Claude 1.0 et 2.0). Ils publient la latence moyenne de chaque modèle. sur une période de 48 heures, sur la base :
- Générer un maximum de 512 jetons
- Une température de 0,7
- intervalles de 10 minutes
- Données provenant de trois emplacements
Enfin, examinons les résultats d’une étude plus approfondie menée par l’organisation d’opérations d’apprentissage automatique Predera . Désormais, bien que cette étude ne concentre que les types de modèles, Mistral Instruct et Llama 2 (bien que les modèles 7B et 70B soient testés plus loin dans l’expérience), elle fournit un plus large éventail de métriques d’inférence, telles que :
- Débit (jetons par seconde)
- Débit (requêtes par seconde)
- Latence moyenne (secondes)
- Latence moyenne par jeton (secondes)
- Latence moyenne par jeton de sortie (secondes)
- Temps total (secondes)
De plus, l’expérience voit l’inférence effectuée grâce à l’utilisation parallèle d’un nombre variable de GPU, qui dans ce cas est le GPU NVIDIA L4 Tensor Core. Cela offre une indication de l’évolutivité de chaque LLM. Enfin, ces résultats sont basés sur l’alimentation de chaque modèle avec 1 000 invites.
1 GPU L4
| Modèle | Débit (jetons par seconde) | Débit (requêtes par seconde) | Latence moyenne (secondes) | Latence moyenne par jeton (secondes) | Latence moyenne par jeton de sortie (secondes) | Temps total (secondes) |
|---|---|---|---|---|---|---|
| Lama2-7B | 558.54 | 1.17 | 449,88 | 1,71 | 10.87 | 897.23 |
| Mistral-7B-instruire | 915.48 | 1,89 | 277.19 | 0,97 | 7.12 | 552.44 |
2 GPU L4
| Modèle | Débit (jetons par seconde) | Débit (requêtes par seconde) | Latence moyenne (secondes) | Latence moyenne par jeton (secondes) | Latence moyenne par jeton de sortie (secondes) | Temps total (secondes) |
|---|---|---|---|---|---|---|
| Lama2-7B | 1265.17 | 2,65 | 179,85 | 0,63 | 3,81 | 397,65 |
| Mistral-7B-instruire | 1625.08 | 3.35 | 153.09 | 0,50 | 2,65 | 339.51 |
4 GPU L4
| Modèle | Débit (jetons par seconde) | Débit (requêtes par seconde) | Latence moyenne (secondes) | Latence moyenne par jeton (secondes) | Latence moyenne par jeton de sortie (secondes) | Temps total (secondes) |
|---|---|---|---|---|---|---|
| Lama2-7B | 1489,99 | 3.12 | 147.36 | 0,48 | 2,57 | 324,71 |
| Mistral-7B-instruire | 1742.70 | 3,59 | 136,49 | 0,44 | 2,68 | 285.03 |
8 GPU L4
| Modèle | Débit (jetons par seconde) | Débit (requêtes par seconde) | Latence moyenne (secondes) | Latence moyenne par jeton (secondes) | Latence moyenne par jeton de sortie (secondes) | Temps total (secondes) |
|---|---|---|---|---|---|---|
| Lama2-7B | 1401.18 | 2,93 | 153.09 | 0,50 | 2,65 | 339.51 |
| Mistral-7B-instruire | 1570.70 | 3.24 | 149,67 | 0,48 | 2,90 | 316.74 |
| Lama2-70B | – | 1h00 | 475,59 | 1,62 | 9.21 | 996,86 |
La première chose que vous remarquerez dans les résultats ci-dessus est que, comme on peut raisonnablement s’y attendre, les métriques d’inférence de chaque modèle s’améliorent globalement à mesure que davantage de GPU sont utilisés. Cependant, cela jusqu’à ce qu’ils atteignent 8 GPU – auquel cas les performances de chaque modèle sont pires par rapport à 4 GPU. Cela montre que les modèles ne sont évolutifs que jusqu’à un certain point – et diviser l’inférence entre des GPU supplémentaires n’offre que peu d’avantages tout en nécessitant plus de temps pour répartir la charge de travail.
Vous remarquerez également que le Llama2-70B n’est présent dans l’expérience que lorsqu’il y a 8 GPU. Cela est dû au fait qu’un modèle nécessite suffisamment d’espace pour stocker le nombre de paramètres déclarés d’un modèle multiplié par la taille du type de données dans lequel ses paramètres sont stockés. Dans le cas du Llama-2-70B, qui stocke les paramètres sous forme de nombres à virgule flottante de 16 bits, cela équivaut à 70 x 2 (octets) = 140B. Comme un GPU L4 mesure 24 Go, le nombre minimum d’unités pouvant accueillir le modèle 70B est de 6 – bien que, conformément au thème consistant à doubler la quantité de GPU utilisés à chaque fois, il a été exécuté sur 8 unités.
Conclusion
La surveillance des performances d’inférence fournit une bonne indication de la vitesse d’un LLM et constitue une méthode efficace pour comparer les modèles les uns par rapport aux autres. Cependant, lorsque vous cherchez à sélectionner le modèle le plus approprié pour les objectifs à long terme de votre organisation, il est prudent d’utiliser les mesures d’inférence comme facteur déterminant et non comme seul déterminant de votre choix de LLM.
Comme détaillé dans ce guide, les chiffres de latence et de débit publiés pour différents modèles peuvent être influencés par plusieurs facteurs, tels que le type et le nombre de GPU utilisés et la nature de l’invite utilisée lors des tests. De plus, même le type de métriques enregistrées peut différer, ce qui rend difficile la compréhension la plus complète des capacités d’un modèle.
De plus, comme mentionné au début de ce guide, il existe des tests d’analyse comparative, tels que HumanEval, qui teste les capacités de codage d’un modèle, et MMLU, qui évalue la compréhension du langage naturel d’un modèle, qui donnent un aperçu de la manière dont un LLM effectue des tâches spécifiques. . Rechercher les performances d’un modèle de langage lors de divers tests d’analyse comparative en plus de sa vitesse d’inférence est une stratégie robuste pour identifier le meilleur LLM pour vos besoins particuliers.
