LLM et Batching : Optimisation Cruciale des GPU en IA

Introduction

Dans le domaine de l'intelligence artificielle, les GPU sont des composants essentiels pour le traitement des modèles, mais leur potentiel est souvent sous-utilisé. En effet, ces unités de traitement graphique passent une grande partie de leur temps en attente entre deux demandes. Cette inefficacité est particulièrement visible avec les grands modèles de langage (LLM), où la variabilité des demandes peut être extrême : certaines se terminent en quelques tokens, tandis que d'autres en nécessitent des milliers. Cette disparité pose un défi majeur pour la gestion du trafic, qui doit jongler avec des charges de travail très inégales.

Pour pallier ce problème, le batching s'impose comme une solution efficace. Plutôt que de traiter chaque demande individuellement, le batching permet de regrouper plusieurs requêtes et de les exécuter en une seule fois. Cela permet de transformer les cycles d'inactivité des GPU en un débit utile, optimisant ainsi l'utilisation des ressources pour lesquelles vous payez déjà. Cependant, la clé de l'efficacité réside dans la manière dont ces groupes sont constitués, car un schéma de batching inadapté peut rapidement échouer face à des demandes de longueurs imprévisibles.

Comment fonctionne le batching statique

Le batching statique est la forme la plus directe de regroupement des demandes. Il repose sur l'attente d'un nombre fixe de requêtes avant de les traiter ensemble. Par exemple, si la taille de lot est fixée à huit, la septième demande devra attendre l'arrivée d'une huitième pour que le traitement commence.

Ce mécanisme est simple : les demandes s'accumulent dans une file d'attente, et lorsque le nombre atteint la taille prédéfinie, le serveur exécute un passage unique sur toutes les requêtes, partageant ainsi un poids de modèle à travers le groupe. Le principal avantage réside dans le fait que charger les poids du modèle depuis la mémoire GPU est une opération coûteuse. La faire une seule fois pour plusieurs demandes, plutôt que pour chacune individuellement, représente un gain d'efficacité considérable. C'est pourquoi le batching statique est idéal pour des tâches programmées, où la latence n'est pas un facteur critique.

Cependant, ce modèle présente des limitations significatives pour le trafic en temps réel. Premièrement, la première demande doit attendre que le lot soit complet, ce qui signifie que la latence dépend de la vitesse d'arrivée des autres requêtes. De plus, une fois le lot en cours, toutes les demandes doivent attendre la plus lente pour se terminer, ce qui peut retarder l'ensemble du processus. Enfin, il n'existe aucun moyen de limiter le temps d'attente avant le début d'un lot, rendant le batching statique inadapté aux applications nécessitant une faible latence.

Comment fonctionne le batching dynamique

Le batching dynamique reprend le principe du regroupement des demandes pour partager un poids de modèle, mais il élimine l'exigence d'un groupe complet avant de commencer le traitement. Au lieu de cela, le serveur définit deux limites : une taille de lot maximale et une fenêtre de délai. L'exécution du lot est déclenchée dès que l'une de ces limites est atteinte.

Concrètement, cela signifie que dès qu'une première demande arrive, un chronomètre démarre. Si suffisamment de requêtes arrivent pour remplir le lot avant l'expiration du chronomètre, elles sont traitées immédiatement. Sinon, le serveur exécute ce qui a été accumulé jusqu'à présent, même si le lot est partiel.

Une configuration de batching dynamique optimisée sur un benchmark d'inférence Triton a considérablement amélioré le débit tout en introduisant une augmentation modérée de la latence de queue. C'est un compromis typique du batching dynamique : une utilisation accrue du matériel et un débit plus élevé se traduisent par des temps de réponse légèrement augmentés.

Le batching dynamique offre donc un débit accru, et la fenêtre de délai détermine la latence que vous êtes prêt à accepter. Un délai plus court protège la latence au prix de lots plus petits et moins efficaces, tandis qu'un délai plus long augmente les chances d'obtenir un lot complet mais allonge le temps d'attente des premières demandes.

La taille maximale du lot limite toujours la quantité de travail pouvant partager un poids de modèle, indépendamment du paramètre de délai. Cependant, cette méthode ne résout pas le problème des demandes longues qui bloquent l'ensemble du lot. Pour les modèles nécessitant un nombre variable de tokens, cela signifie que les requêtes courtes attendent souvent derrière les longues sans possibilité de contournement.

Comment fonctionne le batching continu

Le batching continu introduit une approche radicalement différente en remplaçant la demande comme unité de planification par l'étape de décodage individuelle. Plutôt que d'attendre la fin de chaque séquence dans un lot avant de commencer le suivant, le serveur suit chaque séquence indépendamment, un token à la fois.

Lors du service, à chaque itération de décodage, le serveur produit le prochain token pour chaque séquence active simultanément. Dès qu'une séquence émet un token de fin, elle est retirée du lot, et une nouvelle demande est insérée à sa place lors de l'itération suivante.

Dans ce modèle, il n'y a pas de lot fixe à compléter. Au lieu de cela, un ensemble roulant de séquences actives change presque à chaque étape, ce qui signifie qu'un GPU exécutant un batching continu est rarement en attente.

Une séquence qui se termine tôt libère immédiatement son emplacement, au lieu de retarder le reste du lot. Une nouvelle demande n'a besoin d'attendre qu'une seule itération pour être insérée dans un emplacement libre, et non jusqu'à la fin d'un cycle complet de lot.

Le passage de pré-remplissage initial d'une nouvelle demande est lourd en calcul et peut retarder l'étape de décodage pour chaque autre séquence active lors de cette itération. Le pré-remplissage par morceaux divise ces longues invites en segments plus petits, traités sur plusieurs étapes.

Le batching continu est également connu sous le nom de batching in-flight dans TensorRT-LLM. De nombreux cadres d'inférence pour les LLM, tels que vLLM et TGI, privilégient le batching continu pour sa capacité à offrir un débit élevé sous des charges de travail concurrentes. En revanche, le batching dynamique au niveau des demandes peut offrir un temps plus rapide pour le premier token sous des charges légères.

Résumé

Les différentes techniques de batching abordent le même problème avec des niveaux de granularité variés. Le batching statique partage un poids de modèle à travers un groupe, mais impose une attente pour la demande la plus lente. Le batching dynamique réduit cette attente en ajoutant un délai, mais ne peut pas accélérer un lot une fois qu'il a commencé. Le batching continu élimine complètement le lot fixe, planifiant au niveau des étapes de décodage individuelles, ce qui en fait le choix standard pour les grands modèles de langage à grande échelle.

Voici un récapitulatif des stratégies de batching :

• Batching statique : adapté aux tâches hors ligne sans exigence de latence, mais avec un temps d'inactivité élevé entre les lots.
• Batching dynamique : offre un compromis entre débit et latence, idéal pour les sorties de longueur fixe.
• Batching continu : optimise le service des LLM autoregressifs en production, avec un faible temps d'inactivité et un débit élevé.

Pour ceux qui souhaitent approfondir le sujet, plusieurs ressources sont disponibles, notamment des manuels d'inférence LLM et des guides sur le batching continu et dynamique.