Évaluer les performances de l'inférence des grands modèles de langage sur Red Hat OpenShift AI

Le paysage de l'intelligence artificielle (IA) générative a connu une évolution rapide au cours de l'année passée. Face à la puissance croissante des grands modèles de langage génératifs, les entreprises cherchent de plus en plus à exploiter leurs capacités pour répondre à leurs besoins métier. L'exécution de ces grands modèles de langage nécessite une puissance de calcul élevée. Il est donc essentiel de les déployer sur une plateforme fiable et performante pour exploiter de manière rentable le matériel sous-jacent, notamment les GPU.

Cet article présente la méthode et les résultats des tests des performances des modèles Llama-2 déployés sur la pile de distribution des modèles fournie avec Red Hat OpenShift AI.Plateforme MLOps flexible et évolutive, la solution OpenShift AI inclut des outils de création, de déploiement et de gestion d'applications basées sur l'IA. Conçue autour de technologies Open Source, cette solution offre aux équipes des fonctionnalités fiables et cohérentes pour faire des essais, déployer des modèles et distribuer des applications innovantes.

Pile de distribution des modèles

La pile logicielle de distribution des modèles repose sur KServe, OpenShift Serverless et OpenShift Service Mesh. Pour exécuter les modèles Llama-2, nous avons également utilisé Caikit et text-generation-inference-service (TGIS), bien qu'OpenShift AI prenne aussi en charge OpenVINO et offre la possibilité d'utiliser d'autres environnements d'exécution personnalisés de façon modulaire. L'opérateur GPU NVIDIA gère et expose les GPU de sorte que le conteneur Text Generation Inference Server (TGIS) puisse les utiliser.

Figure 1 : interactions entre les composants et le workflow de l'utilisateur dans la pile KServe/Caikit/TGIS

KServe offre des fonctionnalités avancées de distribution pour l'inférence des modèles d'IA en tirant parti d'OpenShift Serverless et d'OpenShift Service Mesh. Ces composants isolent la complexité liée à la mise en réseau, la configuration du service, la mise à l'échelle automatique et le contrôle d'intégrité pour la distribution des modèles en production.

Le kit d'outils Caikit permet de gérer les modèles à l'aide d'un ensemble d'API adaptées aux équipes de développement. Caikit fournit des interfaces gRPC (Remote Procedure Call) et HTTP standard servant à interroger divers modèles de fondation. Il transfère les demandes au TGIS, le service d'inférence.

TGIS est l'un des premiers forks du kit d'outils de distribution de text-generation-inference Hugging Face. Il fournit plusieurs fonctions importantes pour optimiser les performances de distribution des grands modèles de langage, notamment le traitement par lots continu, la création dynamique de lots, le parallélisme des tenseurs (sharding de modèles) et la prise en charge de la compilation PyTorch 2.

L'opérateur GPU NVIDIA automatise la gestion de divers composants logiciels nécessaires pour provisionner et utiliser des GPU NVIDIA dans OpenShift, dont le conteneur de pilotes, le plug-in de périphériques et l'exportateur d'indicateurs de mesure DCGM (Data Center GPU Manager). Ce dernier permet d'analyser les indicateurs de mesure des GPU, notamment l'utilisation de la mémoire et du multiprocesseur de diffusion, à l'aide de l'instance Prometheus de surveillance d'OpenShift.

Méthode de test des performances pour les grands modèles de langage

Pour évaluer les performances d'un grand modèle de langage, il faut s'intéresser aux mesures classiques de la latence et du débit. Cependant, la latence de bout en bout des requêtes adressées à un grand modèle de langage peut varier considérablement en fonction de plusieurs facteurs. L'aspect le plus important est la longueur en sortie, car les grands modèles de langage génèrent du texte au rythme d'un token à la fois. Il faut donc mesurer la latence par token, ou en « durée par token en sortie ».

Les tokens sont des unités de texte qui représentent une chaîne de caractères d'un mot ou d'un sous-mot. Lorsqu'un grand modèle de langage traite du texte, celui-ci est d'abord converti en tokens. Le schéma exact utilisé pour mettre en correspondance le texte et les tokens varie d'un modèle à l'autre. Les tokens se voient attribuer des représentations numériques et sont organisés en vecteurs qui alimentent le modèle et ses sorties.

Le délai de « préremplissage » est un autre facteur qui influe sur la latence totale des requêtes. Il s'agit du temps nécessaire pour traiter les tokens du prompt d'entrée avant que le modèle ne génère le premier nouveau token. Enfin, le temps de mise en file d'attente contribue aussi de manière significative à la latence totale des requêtes. Dans les cas où le service d'inférence ne peut pas traiter les requêtes assez rapidement pour répondre à la charge entrante en raison de contraintes matérielles, telles que la mémoire du GPU, certaines d'entre elles sont placées dans une file d'attente avant d'être traitées. En raison de ces facteurs, il est courant d'utiliser le « délai du premier token » comme indicateur de mesure pour évaluer les performances des grands modèles de langage. Ce délai est particulièrement utile dans des cas d'utilisation tels que les chatbots, pour lesquels les tokens sont diffusés et affichés à mesure qu'ils sont générés.

Tout comme la latence, le débit varie considérablement s'il est mesuré en requêtes par seconde en fonction du nombre de tokens générés dans les requêtes. Il faut donc mesurer le débit global en fonction du nombre total de tokens générés par seconde pour tous les utilisateurs qui interrogent le modèle.

Tests de charge avec llm-load-test

Nous avons créé l'outil Open Source llm-load-test pour effectuer des tests de charge des modèles exécutés sur la pile de distribution des modèles OpenShift AI. Il est écrit en Python et repose sur l'outil de test de charge gRPC ghz. Nous avons copié ghz pour lui ajouter la possibilité d'enregistrer la réponse et l'identifiant de thread de calcul pour chaque requête dans la sortie de test.

Au-delà des fonctions proposées dans ghz, llm-load-test permet d'exécuter plusieurs processus ghz en parallèle avec l'ensemble de données d'entrée dans un ordre aléatoire dans chaque instance. Ainsi, il est possible de simuler une situation où de nombreux utilisateurs différents interrogeraient simultanément le modèle avec différents prompts. llm-load-test peut également télécharger les résultats directement dans un bucket S3 après un essai, en balisant les objets de sortie avec les métadonnées correspondantes pour l'exécution.

Ensemble de données en entrée

Il est possible de configurer les prompts d'entrée dans llm-load-test pour le test de charge à l'aide d'un fichier JSON. Nous avons choisi un ensemble de 32 entrées issues de l'ensemble de données OpenOrca avec des longueurs d'entrée/sortie variables pour les essais réalisés dans le but d'obtenir les résultats partagés dans cet article de blog. L'entrée la plus longue dans nos données de test comptait 1 688 tokens et la sortie la plus longue comptait 377 tokens. La figure 2 montre la distribution des longueurs d'entrée et de sortie dans l'ensemble de données de test.

Figure 2 : longueur des tokens de l'ensemble de données de test

Il est important d'utiliser différentes tailles d'entrée et de sortie pour tester les capacités de traitement par lots continu et dynamique du TGIS dans un scénario réaliste. Les modèles récents commencent à prendre en charge de très grandes longueurs de contexte supérieures à 4 000 tokens, ce qui est particulièrement important pour des cas d'utilisation tels que la génération augmentée de récupération (RAG). C'est pourquoi nous avons l'intention d'augmenter la taille de notre ensemble de données de test de charge afin d'inclure de plus grandes longueurs d'entrée à l'avenir.

Résultats des performances des modèles Llama-2 avec OpenShift AI sur AWS

Les mesures de performances suivantes ont été recueillies avec un cluster OpenShift IPI (Installer-Provisioned Infrastructure) autogéré et déployé sur AWS. Nous avons installé l'opérateur OpenShift AI et créé les objets ServingRuntime et InferenceService pour permettre la distribution du modèle avec Kserve, Caikit et TGIS.

Le tableau 1 ci-dessous résume les résultats des tests de quatre combinaisons de modèles et de types d'instances AWS :

Tableau 1 : résumé des configurations de test

Dans chaque configuration, nous avons exécuté plusieurs tests de charge de quatre minutes en utilisant llm-load-test avec différents nombres de threads simultanés (le paramètre de simultanéité dans les figures ci-dessous). Lors de chaque test, chaque thread simultané envoie en continu une requête à la fois dès qu'il reçoit la réponse de la requête précédente.

À titre d'illustration, la figure 3 ci-dessous représente la latence totale de chaque requête pendant la durée du test. La couleur de chaque point représente la longueur du token, permettant de voir à quel point sa longueur est étroitement corrélée avec la sortie globale des requêtes.

Figure 3 : latence totale de toutes les requêtes pendant la durée d'un test de charge

Nous avons analysé les journaux du TGIS pour obtenir la latence totale de chaque requête et le débit calculé en divisant le total des tokens générés pendant le test de charge par la durée du test (240 secondes).

La figure 4 montre la latence et le débit mesurés lors du test de charge du modèle Llama-2-7b sur l'instance g5.2xlarge avec différents paramètres de simultanéité de test de charge. Dans ce cas, nous constatons que le débit augmente à mesure que nous augmentons la simultanéité du test de charge jusqu'à 20 threads environ. En raison des contraintes de mémoire GPU de l'instance g5.2xlarge, le TGIS ne peut pas intégrer plus d'une vingtaine de requêtes (selon la longueur d'entrée/de sortie des requêtes) dans un lot à la fois.

Figure 4 : résumé de la latence et du débit du modèle Llama-2-7b sur l'instance g5.2xlarge

Le graphique de la figure 5 montre la latence et le débit mesurés lors du test de charge du modèle Llama-2-13b sur l'instance g5.12xlarge. Dans ce cas, nous constatons que la latence minimale par token est inférieure à celle du modèle 7b sur l'instance g5.2xlarge, et que le débit augmente jusqu'à au moins 30 requêtes simultanées, bien que le modèle soit plus grand et que l'instance utilise le même type de GPU. Ce résultat est dû aux avantages significatifs de performances liés à l'utilisation du parallélisme des tenseurs pour distribuer le modèle sur les quatre GPU.

Figure 5 : résumé de la latence et du débit du modèle Llama-2-13b sur l'instance g5.12xlarge

La figure 6 montre la latence et le débit mesurés lors du test de charge du modèle Llama-2-70b sur l'instance g5.48xlarge. Dans ce cas, la latence par token est plus élevée à tous les niveaux que dans les configurations précédentes. Les modèles tels que Llama-2-70b présentent d'importantes exigences matérielles. Les GPU 8xA10G ont une capacité de 192 Go de VRAM combinée, la majeure partie étant nécessaire pour charger les paramètres 70 b avec une précision de 16 bits en mémoire (70 b*16 bits = 140 Go environ). En fonction des exigences de performances, il faut opter pour davantage de ressources de calcul, avec une instance p4d.24xlarge par exemple.

Figure 6 : résumé de la latence et du débit du modèle Llama-2-70b sur l'instance g5.48xlarge

La figure 7 montre la latence et le débit mesurés lors du test de charge du modèle Llama-2-70b sur l'instance p4d.24xlarge. Sur cette instance, nous pouvons maintenir une latence bien plus faible pour un nombre identique d'utilisateurs par rapport à l'instance g5.48xlarge. Même lorsque la valeur de simultanéité s'élève à 30, le débit continue à s'adapter à mesure que la simultanéité du test de charge augmente.

Figure 7 : résumé de la latence et du débit du modèle Llama-2-70b sur l'instance p4d.24xlarge

Calcul des coûts

Nous pouvons estimer le coût de la génération d'un million de tokens en utilisant le débit mesuré et les coûts du type d'instance. Le tableau ci-dessous résume ces estimations sur la base du débit mesuré pour les résultats recueillis avec une simultanéité de la charge de 10.

Tableau 2 : résumé des résultats pour chaque configuration avec coût calculé par million de tokens

Prochains travaux

Ces résultats sont un aperçu des tests effectués par l'équipe Red Hat chargée des performances et de la mise à l'échelle des plateformes d'IA (PSAP). Outre les tests de performances pour d'autres aspects d'OpenShift AI, nous poursuivons activement nos analyses des performances et de l'évolutivité de la pile de distribution des modèles. Nous espérons pouvoir prochainement partager davantage de résultats liés notamment aux tests d'autres modèles et à la mise à l'échelle automatique de répliques de modèles en fonction du trafic.

Nous continuerons de développer llm-load-test pour y ajouter plusieurs fonctions, comme :

• la capacité de mesurer le délai du premier token et le délai par token en sortie pour les demandes de diffusion en continu ;
• des interfaces enfichables/modulables pour interroger les modèles d'API différentes, y compris les interfaces HTTP et gRPC ;
• une phase de lancement et la possibilité de vérifier que le modèle est chargé et répond sans erreur ;
• des modèles de charge plus complexes, tels qu'un taux d'arrivée Poisson aléatoire.

Conclusion

Les tests des performances des modèles Llama-2 sur OpenShift AI permettent d'avoir un aperçu de la latence, du débit et du coût associés à l'exécution de grands modèles de langage dans différentes configurations. Par exemple, pour le modèle 7b, l'instance g5.2xlarge était la plus abordable, mais l'utilisation de l'instance g5.12xlarge peut s'avérer bénéfique dans certains cas en raison des améliorations significatives de la latence et du débit grâce au parallélisme des tenseurs. L'exécution de plus grands modèles devrait offrir une sortie de meilleure qualité, mais nécessite davantage de mémoire GPU, ce qui augmente les coûts.

OpenShift AI offre une solution de distribution de modèles performante et adaptable pour les entreprises confrontées aux difficultés du déploiement de grands modèles de langage génératifs. Notre plateforme s'adapte à diverses exigences en matière de qualité des modèles, de latence, de débit ou de coût. Pour découvrir comment tirer parti de ces avantages selon votre cas d'utilisation spécifique, essayez de déployer le modèle de votre choix sur OpenShift AI.