Booster Llama 2 70B avec NVIDIA H100

La recherche de performances dans le moteur de réponse de Perplexity nous pousse à adopter les technologies les plus récentes proposées par NVIDIA et AWS. Dans ce blogue, nous sommes ravis de partager les résultats de nos dernières expériences : une comparaison de l'inférence de Llama 2 70B à travers divers paramètres matériels et logiciels.

Notre plateforme d'inférence de LLM, pplx-api, est construite sur une pile technologique de pointe alimentée par des bibliothèques libres. Depuis le lancement de la version bêta publique de pplx-api en octobre, nous avons relevé des défis de mise à l'échelle et appris à optimiser notre configuration pour atteindre une échelle massive. Cela nous a amenés à mener des expériences guidées par les questions suivantes :

Quel est le gain de performance brut en passant nos GPU de NVIDIA A100 à NVIDIA H100, tous les autres paramètres restant identiques ?

Quel est le gain d'efficacité de la quantification en virgule flottante 8 bits (fp8), pour laquelle la H100 offre un support natif ? Quel est le coût en termes de précision de cette quantification ?

Comment le parallélisme de tenseurs et la taille des lots affectent-ils la latence et le débit de jetons ?

Compte tenu de ce qui précède, quelle configuration offre l'équilibre le plus évolutif entre performance et efficacité des coûts ?

Nous avons mené l'expérience suivante sous forme d'une série de tests de performance locaux pour éviter la latence réseau.

Latence : Le temps total nécessaire au serveur d'inférence pour générer sa réponse complète.

Débit : Le nombre de jetons de sortie, par seconde et par GPU, que le serveur d'inférence peut générer pour l'ensemble des utilisateurs et des requêtes.

Les facteurs suivants influencent les indicateurs clés, c'est pourquoi nous les avons maintenus constants lors des différents essais de l'expérience.

Les performances augmentent avec la taille du LLM. Plus il y a de paramètres, plus il faut de calculs, ce qui ralentit l'inférence. Par exemple, Llama 2 13B est plus rapide que Llama 2 70B lorsque les autres paramètres sont égaux. Nous utilisons Llama 2 70B dans cette expérience parce que nous voulons optimiser le service des modèles open source les plus performants.

La quantité de jetons d'entrée et de sortie dans chaque paire requête/réponse d'échantillon peut influencer les mesures de performance. En règle générale, la génération de jetons de sortie domine le temps de réponse global. Lorsque les données d'échantillonnage n'induisent que des réponses « oui/non » de la part du LLM, la réponse est plus rapide que pour des échantillons qui demandent au LLM de rédiger des essais. Notre jeu de données est composé de requêtes synthétiques avec 1024 jetons d'entrée induisant 512 jetons de sortie. Cette distribution a été choisie pour correspondre à la distribution du trafic observée sur notre déploiement public de Llama 2 70B.

NVIDIA TensorRT-LLM (version v0.5.0) est une bibliothèque open source d'optimisation de l'inférence de LLM. Sortie fin 2023, elle synthétise les nombreuses optimisations d'inférence de NVIDIA et offre une couche de personnalisation flexible pour les paramètres clés de cette expérience : la taille des lots, la quantification et le parallélisme de tenseurs.

Nous avons fait des essais sur 4 axes de configuration : le parallélisme de tenseurs, l'architecture du GPU, la quantification et la taille maximale des lots. Ces axes sont interconnectés car ils représentent chacun un compromis par rapport à la ressource critique de goulet d'étranglement qu'est la mémoire du GPU.

L'architecture de GPU Hopper de neuvième génération (H100-HBM3-80GB / p5.48xlarge) intègre une gigantesque liste de fonctionnalités par rapport à son prédécesseur, Ampere (A100-SXM4-80GB / p4de.24xlarge), incluant des taux de calcul multipliés par 2 à 6 et une bande passante mémoire du GPU presque doublée. La bande passante de la mémoire du GPU est un indicateur critique pour l'inférence, car l'un des principaux goulets d'étranglement de la latence des multiplications de matrices de l'inférence provient du chargement de gigaoctets de données de modèle de la mémoire du GPU vers les registres de calcul. Sur la base de ces statistiques, nous avons émis l'hypothèse qu'une comparaison directe entre le NVIDIA H100 et le A100 montrerait une amélioration par 2 de la latence et du débit.

Une autre différence clé entre le NVIDIA H100 et le A100 est que le cœur tensoriel du H100 ajoute nativement la prise en charge des instructions en virgule flottante 8 bits (fp8), ce qui ouvre la voie à d'autres optimisations détaillées ci-dessous. C'est pourquoi nous utilisons spécifiquement fp8 et fp16 pour le H100.

Pour maintenir une mémoire par GPU constante dans cette expérience, nous avons utilisé des nœuds dotés d'une mémoire GPU de 8x80 Go pour nos NVIDIA A100 et H100. En plus de permettre des tailles de lots plus importantes, la mémoire du GPU est importante car les paramètres du modèle sont chargés dans la mémoire du GPU au démarrage du serveur pour un accès rapide. Par exemple, si chacun des 70 milliards de paramètres de notre modèle est un nombre en virgule flottante de 16 bits, la taille du modèle est d'environ 140 Go, ce qui ne tient pas sur un seul GPU. D'où la nécessité du parallélisme de tenseurs, que nous expliquons ci-dessous.

Le parallélisme de tenseurs fait référence au nombre de dispositifs GPU consommés pour exécuter le serveur d'inférence. Lorsque nous allouons un certain nombre de GPU, TensorRT-LLM met leurs ressources en commun pour nous aider à atteindre le budget mémoire minimum requis pour exécuter Llama 2 70B. Notre hypothèse est qu'un parallélisme de tenseurs plus faible entraînera une latence plus élevée (en raison du plus petit nombre de ressources consommées pour satisfaire chaque lot), mais un débit plus élevé par GPU (en raison d'une meilleure utilisation) par rapport à un parallélisme de tenseurs plus élevé.

La quantification est la réduction de la précision des poids et des activations utilisés par les réseaux de neurones. Nous utilisons cette technique pour diviser par deux la consommation de mémoire du GPU lorsque nous passons de fp16 à fp8. Il est ainsi possible d'exécuter le même modèle avec une utilisation globale de la mémoire du GPU réduite, ce qui permet un parallélisme de tenseurs plus faible et augmente le débit.

Les implémentations de la quantification peuvent potentiellement dégrader la précision. Par conséquent, nous avons évalué la précision pour différentes précisions en comparant leur statistique de perplexité, une mesure de la capacité du LLM à prédire chaque jeton suivant dans une phrase, sur le corpus WikiText. Pour la virgule flottante 8 bits et le poids 8 bits avec l'activation 8 bits et SmoothQuant (w8a8 SQ), il n'y a pas eu de changement significatif de la perplexité (< 1 %) par rapport à fp16 sur WikiText, nous avons donc eu confiance pour continuer. Cependant, w4a16 a présenté un changement substantiel de 7 % de la perplexité, potentiellement attribuable à une précision encore plus faible et aux conversions dynamiques nécessaires entre int4 et fp16.

Le parallélisme par lots est une stratégie classique pour optimiser les performances d'un système aux ressources contraintes. En traitant plusieurs requêtes lors de chaque passage direct dans le réseau de neurones, le traitement par lots est connu pour augmenter le débit au détriment d'une certaine latence. Le traitement par lots entraîne également une plus grande consommation de mémoire GPU, car la taille du cache KV qui gère le mécanisme d'attention augmente de manière linéaire avec la taille des lots.

Dans le cas de Llama 2 70B (qui possède 80 couches), avec fp16, une taille de lot de 32 et une taille de contexte de 4096, la taille du cache KV atteint un volume substantiel de 40 Go. Cela finit par empêcher Llama 2 70B fp16, dont les seuls poids occupent 140 Go, de tenir confortablement dans la mémoire GPU de 160 Go disponible avec un parallélisme de tenseurs de 2 (TP-2).

Nous avons examiné les combinaisons compatibles des 4 variables de l'expérience et présentons ci-dessous les tendances les plus instructives.

Figure 1 – La latence des requêtes avec une taille de lot variable à travers cinq configurations différentes, toutes dotées d'un parallélisme de tenseurs de 8, ce qui donne la meilleure latence avec 8 GPU disponibles. Dans chaque configuration, la latence double généralement lors du passage d'une taille de lot de 1 à 32, et double à nouveau de 32 à 128. Pour des tailles de lots suffisamment grandes, le H100 réduit approximativement de moitié la latence par rapport au A100. Le A100 utilise une précision mixte car l'architecture ne prend pas en charge nativement le format fp8. w8a8 avec SmoothQuant (SQ) est conçu pour ressembler au fp8.

L'amélioration de la latence liée à la quantification se situe aux alentours de 10 % lors de la comparaison entre H100 fp16 → fp8 et A100 fp16 → w8a8 avec SmoothQuant. Cependant, la précision mixte w4a16 est en fait plus performante pour les petites tailles de lots et moins performante pour les tailles de lots plus importantes par rapport à fp16. Cela peut être dû à plusieurs facteurs, notamment des noyaux de calcul moins optimisés, le temps de conversion entre int4 et fp16, et le fait que w4a16 utilise toujours des nombres en virgule flottante de 16 bits pour les activations, ce qui n'entraîne aucune économie sur les dimensions du cache KV. Étant donné que w4a16 a également démontré une précision inférieure, nous en concluons que nous devons nous en tenir à w8a8 SQ pour les A100 et à fp8 pour les H100.

Figure 2 – Le débit à travers les configurations TP-8 avec des architectures, des quantifications et des tailles de lots différentes. Pour chaque architecture et quantification, la taille de lot a été choisie comme étant la plus grande respectant une exigence de latence de 25600 ms (20 jetons par seconde pour 512 jetons), afin de comparer des configurations ayant une latence similaire. Selon cette exigence, le H100 avec BS-128 atteint 228 % du débit par rapport au A100 BS-64 utilisant la même quantification (fp16) et présente même une latence de réponse inférieure malgré la taille de lot doublée. La quantification avec fp8 porte ce facteur à 251 %.

Dans nos deux premières figures, nous ne présentons que les configurations TP-8. Le H100 atteint 54 % de la latence et 184 % du débit par rapport au A100 lorsque tous deux utilisent fp16 / BS-128 / TP-8, ce qui s'améliore à 49 % de la latence et 202 % du débit lors de l'utilisation de fp8 sur le H100. Cette amélioration des performances peut être attribuée à l'augmentation de la puissance de calcul et de la bande passante de la mémoire entre le H100 et le A100. Notamment, la différence est moins prononcée pour les tailles de lots plus faibles où l'utilisation peut être moindre.

Au fur et à mesure que nous construisons notre plateforme, nous voulons respecter certaines exigences de latence pour nos utilisateurs tout en maximisant le débit. Par conséquent, plutôt que de comparer le A100 et le H100 pour une même taille de lot, il est plus judicieux de comparer leur débit uniquement dans le cadre de configurations où ils satisfont à une exigence de latence. Nous avons fixé un seuil à 25600 ms de latence pour l'achèvement des 512 jetons de sortie et avons constaté que H100 / TP-8 / fp8 / BS-128 génère 251 % du débit par rapport à A100 / TP-8 / fp16 / BS-64, car il est capable de traiter le double de la taille de lot avec une latence inférieure. Étant donné que la quantification permet des économies de mémoire GPU, nous devons maintenant évaluer comment le parallélisme de tenseurs peut ajouter une nouvelle couche d'optimisation.

Figure 3 – La latence en fonction de différentes tailles de lots et du parallélisme de tenseurs pour H100 fp8. La latence double généralement lors du passage d'une taille de lot de 1 à 32, et double à nouveau de 32 à 128. TP-2 est systématiquement environ deux fois plus lent que TP-8 lorsque les tailles de lots sont égales. Doubler le parallélisme de tenseurs tout en doublant la taille des lots maintient une latence relativement stable, car le nombre de lots traités par GPU reste pair.

En matière de quantification et d'architecture, il y a des vainqueurs évidents : le H100 surclasse le A100 et la quantification à précision réduite améliore l'utilisation de la mémoire, la latence et le débit. Cependant, la taille des lots et le parallélisme de tenseurs présentent un compromis dans nos indicateurs clés. Une taille de lot plus importante optimise le débit au détriment d'une augmentation de la latence et de la consommation de mémoire. D'autre part, un parallélisme de tenseurs plus élevé augmente l'ensemble du réservoir de mémoire disponible et optimise la latence, mais se fait au détriment du débit en raison des coûts de synchronisation de la multiplication de matrices distribuée et du fait qu'il mobilise davantage de ressources GPU.

Figure 4 – Le débit en fonction de différentes tailles de lots et du parallélisme de tenseurs pour H100 fp8. Le débit le plus élevé est obtenu avec TP-2 BS-128, atteignant 460 % par rapport à la référence de A100/TP-8/fp16/BS-64. Cependant, TP-2 BS-128 est également le résultat le plus lent de la Figure 3.

La configuration maximisant le débit de notre expérience est H100 / fp8 / TP-2 / BS-128, à 767 jetons de sortie par seconde et par GPU. Il s'agit d'une amélioration de 460 % par rapport à A100 / fp16 / TP-8 / BS-64. Cependant, cela se fait au détriment d'une latence doublée — proche de 42000 ms pour 512 jetons de sortie —, ce qui peut la rendre impropre à une configuration de production. Les résultats de TP-4 BS-128 (626 tok/sec/gpu pour un temps de réponse de 26188 ms) et de TP-2 BS-32 (435 tok/sec/gpu pour un temps de réponse de 18821 ms) peuvent représenter de meilleurs compromis sur nos indicateurs clés.

Nos résultats démontrent que :

Nous atteignons 54 % de la latence et 184 % du débit en utilisant le H100 par rapport au A100 à configuration égale, ce qui s'améliore respectivement à 49 % et 202 % lorsque le H100 tire parti de sa prise en charge native du format fp8.

Lors de la maximisation du débit sous contrainte de latence, H100 / fp8 / TP-8 / BS-128 génère 251 % du débit par rapport à A100 / fp16 / TP-8 / BS-64, car il peut traiter le double du lot à une vitesse plus rapide.

En tirant parti du H100 avec TP-2 et fp8, nous pouvons atteindre 373 % du débit de A100 / fp16 / TP-8 / BS-128, avec une augmentation de la latence inférieure à 10 %.

La taille des lots et le parallélisme de tenseurs présentent un compromis entre le débit et la latence pour l'opérateur d'un système d'inférence de LLM.

Ces résultats nous donnent confiance quant à une transition complète vers les GPU H100 dans notre pile matérielle précédemment alimentée par des A100. Nous sommes ravis de pouvoir confirmer les gains de performance annoncés par NVIDIA et attendons avec impatience leurs prochaines avancées en matière de matériel accéléré.

Notre prochaine frontière d'optimisation consiste à examiner l'impact sur la précision et les performances de la sparsité structurée et de la précision int4, qui pourraient réduire considérablement l'empreinte mémoire GPU de Llama 2 70B et multiplier la latence par un facteur allant jusqu'à 2. Nous sommes ravis de poursuivre l'aventure d'une inférence ultrarapide et espérons permettre à nos utilisateurs de créer des applications puissantes sur notre plateforme.

À court terme, pplx-api lèvera les limites de taux et offrira davantage de modèles Perplexity personnalisés, y compris un LLM alimenté par Internet avec ancrage factuel.

Inscrivez-vous à Perplexity Pro sur perplexity.ai/pro. Obtenez l'accès à notre pplx-api de pointe et tirez parti de ces fonctionnalités avancées dans vos projets. Découvrez-en plus sur pplx-api sur notre blogue.

Envie de façonner l'avenir de l'IA ? Nous embauchons ! Rejoignez une équipe qui pilote une infrastructure de LLM génératifs à l'échelle massive. Explorez les opportunités sur Perplexity Careers.

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

Configuration expérimentale

Indicateurs clés :

Constantes :

Modèle d'IA

Jeu de données de jetons d'entrée/sortie

Version du logiciel

Variables

Architecture de GPU

Parallélisme de tenseurs

Quantification

Taille des lots

Résultats

Conclusion

Prochaines étapes

Auteurs :