Traitement par lots continu pour l'inférence LLM : Guide d'efficacité GPU

Le traitement par lots continu est une technique d'ordonnancement d'inférence qui maintient un GPU en activité en ajoutant de nouvelles requêtes à un lot actif dès que les séquences terminées le quittent. Au lieu d'attendre qu'un lot fixe se termine, un serveur d'inférence LLM met à jour le lot actuel à chaque étape de décodage, ce qui contribue à maximiser le débit, à réduire le temps d'inactivité du GPU et à améliorer l'économie de service pour les systèmes d'IA à volume élevé.

Qu'est-ce que le traitement par lots continu ?

Le traitement par lots continu est un ordonnancement dynamique des requêtes pour l'inférence d'IA, en particulier pour l'inférence de LLM où de nombreuses séquences d'entrée arrivent à des moments différents et génèrent des séquences de sortie de longueurs différentes. On l'appelle aussi ordonnancement au niveau de l'itération ou batching en cours de vol, car l'algorithme de batching met à jour le lot actif pendant la génération, et pas seulement avant que la génération ne commence.

L'idée principale est simple : lorsqu'une séquence génère un jeton de fin de séquence, atteint une limite de jetons, ou termine autrement la génération, cet emplacement ne reste pas vide tant que le reste du lot n'est pas terminé. Le serveur de modèle peut admettre l'une des requêtes entrantes de la file d'attente et continuer la prochaine passe avant avec un lot rafraîchi. En d'autres termes, le traitement par lots continu permet un ordonnancement dynamique des requêtes, permettant l'insertion de nouvelles invites dans la file d'attente de traitement dès que les invites précédentes ont terminé leur génération, ce qui maximise l'utilisation du GPU.

Ceci est différent du traitement par lots au niveau de la requête. Dans le traitement par lots statique, le lot reste constant jusqu'à ce que toutes les requêtes soient terminées. Dans le traitement par lots dynamique, le serveur peut attendre brièvement l'arrivée de plusieurs requêtes, mais une fois le lot démarré, la composition est généralement fixe. Le traitement par lots continu fonctionne au niveau du jeton plutôt qu'au niveau de la requête, ce qui permet une utilisation plus efficace des ressources GPU en traitant simultanément plusieurs jetons de différentes requêtes.

Un modèle mental utile est celui d'un tapis roulant. Si un lot existant commence avec sept séquences et que trois séquences terminées le quittent après plusieurs itérations, l'ordonnanceur peut introduire trois nouvelles requêtes plutôt que de forcer quatre séquences actives à continuer seules. C'est ainsi que le traitement par lots continu permet une meilleure utilisation du GPU : le lot reste dense tandis que les utilisateurs réels, les invites et les longueurs des séquences de jetons changent.

Cette technique combine le traitement par lots irrégulier (ragged batching) et l'ordonnancement dynamique pour améliorer le débit dans les systèmes de service LLM en éliminant le besoin de jetons de remplissage (padding tokens), qui peuvent gaspiller de la mémoire et des ressources de calcul. Il ne s'agit pas de réduire la taille du modèle, de modifier les paramètres du modèle ou d'améliorer la qualité de la prédiction des jetons. C'est un mécanisme d'ordonnancement pour servir efficacement plusieurs requêtes sur des architectures de calcul massivement parallèles.

Comment fonctionne l'inférence de LLM

Pour comprendre comment fonctionne le traitement par lots continu, il est utile de séparer l'inférence de LLM en deux étapes : la phase de préremplissage et la phase de décodage.

Dans la phase de préremplissage, le modèle traite l'entrée utilisateur ou l'invite d'entrée. La séquence d'entrée complète est passée à travers le transformeur afin que le système puisse construire l'état d'attention pour l'invite. Cette phase implique souvent un grand nombre d'opérations en virgule flottante car le modèle doit traiter de nombreux jetons d'invite simultanément. La phase de préremplissage consomme des ressources de calcul, en particulier pour les invites longues, et elle crée également le cache KV qui seront réutilisés pendant la génération.

La phase de décodage présente un schéma de calcul différent. Une fois l'invite traitée, le modèle génère la sortie du modèle un jeton à la fois. Il effectue la prédiction du jeton suivant, ajoute le jeton subséquent à la séquence de jetons, met à jour le cache kv et répète l'opération jusqu'à ce que la séquence émette un jeton de fin de séquence, atteigne une condition d'arrêt ou une longueur de sortie maximale. Ces jetons de décodage sont l'endroit où le traitement par lots continu devient particulièrement utile, car différentes requêtes atteignent la génération complète à différentes itérations.

Le cache kv est au cœur de ce processus. Il stocke les tenseurs clé et valeur des jetons précédents afin que le modèle n'ait pas besoin de recalculer le contexte complet pour chaque jeton subséquent. Sans le cache kv, chaque nouvelle prédiction de jeton nécessiterait de recalculer une grande partie de la séquence d'entrée et de sortie précédente, ce qui rendrait l'inférence beaucoup plus lente.

Le défi est la mémoire. L'inférence des LLM est limitée par les E/S mémoire (memory-IO bound), ce qui signifie qu'il faut plus de temps pour charger les données dans la mémoire du GPU que pour effectuer des calculs sur ces données, ce qui souligne l'importance d'optimiser l'utilisation de la mémoire. En d'autres termes, l'inférence des LLM est limitée par les E/S mémoire, ce qui signifie qu'il faut plus de temps pour charger les données dans les cœurs de calcul du GPU que pour que ces cœurs effectuent des calculs sur ces données. Pendant le décodage, la bande passante mémoire de la puce est souvent aussi importante que la puissance de calcul brute, car le système doit lire à plusieurs reprises les poids du modèle, les paramètres du modèle et l'état d'attention mis en cache.

La quantité de mémoire GPU consommée évolue avec la taille du modèle de base plus la longueur de la séquence de jetons, ce qui indique que l'optimisation de l'utilisation de la mémoire peut avoir un impact significatif sur le nombre de séquences traitées dans un lot. Plus précisément, la quantité de mémoire GPU consommée évolue avec la taille du modèle de base plus la longueur de la séquence de jetons, un modèle de 13 milliards de paramètres étant estimé à consommer près de 1 Mo d'état pour chaque jeton d'une séquence. C'est pourquoi la mémoire GPU, l'allocation du cache kv et la taille du lot ne sont pas des détails secondaires ; elles définissent le nombre de requêtes de décodage simultanées qu'un déploiement de modèle peut prendre en charge en toute sécurité, et elles interagissent directement avec le choix du GPU pour l'inférence des LLM.

Traitement par lots statique vs traitement par lots dynamique vs traitement par lots continu

Les stratégies de traitement par lots diffèrent principalement par ce qu'elles attendent, le moment où elles acceptent de nouvelles tâches et si la composition du lot peut changer après le début de la génération.

Le traitement par lots statique fonctionne bien lorsque les requêtes sont uniformes. Si chaque requête a la même longueur d'invite d'entrée, la même longueur de sortie et un coût de calcul prévisible, un lot fixe peut être efficace. Mais le service LLM se comporte rarement de manière aussi nette. Une requête individuelle peut n'avoir besoin que d'une réponse courte, tandis qu'une autre requête dans le même lot peut nécessiter une longue sortie de modèle.

Le traitement par lots dynamique est une amélioration car il évite d'attendre indéfiniment un nombre fixe de requêtes. Un serveur de modèles peut collecter les requêtes entrantes pendant quelques millisecondes, lancer un lot et réduire le temps d'attente pour la formation du lot. Mais le traitement par lots dynamique traite toujours la requête comme l'unité de base. Une fois que le lot actuel démarre, toutes les requêtes avancent souvent ensemble jusqu'à ce qu'elles soient terminées.

Le traitement par lots continu permet de traiter les requêtes au niveau du jeton plutôt qu'au niveau de la requête, ce qui permet d'ajouter de nouvelles requêtes à un lot dès qu'une séquence a fini de générer, maximisant ainsi l'utilisation du GPU. Dans le traitement par lots continu, la composition du lot change dynamiquement à chaque itération de décodage, ce qui permet un débit plus élevé et un temps d'inactivité réduit sur le GPU par rapport aux méthodes de traitement par lots statique et dynamique, et un solide guide pratique du traitement par lots continu pour l'inférence des LLM se concentrera généralement sur l'ajustement de ces compromis dans les déploiements réels.

Pourquoi le traitement par lots traditionnel échoue pour les LLM

Le traitement par lots traditionnel suppose que les tâches sont suffisamment similaires pour que leur regroupement améliore l'efficacité sans créer trop de gaspillage. Cette hypothèse échoue souvent pour l'inférence des LLM.

Le premier problème est la longueur variable de l'invite. Une entrée utilisateur peut être une question courte. Une autre peut contenir un long document, un fichier de code ou un historique de conversation. La phase de préremplissage pour ces deux requêtes a un schéma de calcul et une utilisation de la mémoire différents. L'invite longue crée plus d'état de cache kv, tandis que l'invite courte peut terminer le préremplissage rapidement et passer au décodage plus tôt.

Le deuxième problème est la longueur variable de la sortie. Certaines séquences de sortie se terminent après quelques jetons. D'autres continuent pendant des centaines ou des milliers de jetons. Si un lot statique contient de nombreuses séquences d'entrée et qu'une séquence génère beaucoup plus longtemps que les autres, les requêtes plus courtes peuvent avoir complètement terminé la génération tandis que la plus longue continue. Le GPU peut toujours être lié à la forme du lot même si le travail utile a diminué.

Le troisième problème est la génération jeton par jeton. Les LLM ne produisent généralement pas la réponse complète en une seule opération. Ils effectuent la prédiction de jeton, génèrent le dernier jeton pour cette étape, mettent à jour l'état et exécutent une autre passe avant pour le jeton suivant. Ces limites d'itération naturelles créent des opportunités pour un ordonnanceur de supprimer les séquences terminées et d'admettre de nouvelles requêtes. Le traitement par lots traditionnel manque cette opportunité car il traite la requête comme une unité fixe.

Le résultat est un temps d'inactivité du GPU, un gaspillage de remplissage et un débit effectif plus faible. Les systèmes statiques et dynamiques ont souvent besoin de jetons de remplissage pour aligner les longueurs de séquence à l'intérieur d'un lot. Les jetons de remplissage ne contribuent pas à une sortie de modèle significative, mais ils peuvent toujours consommer de la bande passante mémoire et des ressources de calcul. Le traitement par lots continu est une technique d'optimisation de la mémoire qui permet un débit plus élevé en laissant les séquences d'un lot se terminer indépendamment, évitant ainsi le temps d'inactivité du GPU en attendant que la séquence la plus longue se termine.

C'est pourquoi le traitement par lots continu n'est pas simplement un « traitement par lots plus rapide ». C'est une stratégie de traitement par lots conçue pour les charges de travail irrégulières générant des jetons où les longueurs de séquence, les requêtes de décodage et les temps d'achèvement varient d'un utilisateur à l'autre, et elle apparaît souvent comme une solution clé lors du diagnostic des raisons pour lesquelles un LLM est lent et de ce qu'il faut optimiser en premier.

Avantages du traitement par lots continu

Le principal avantage est une meilleure utilisation du GPU. Le traitement par lots continu améliore l'utilisation du GPU en permettant d'ajouter de nouvelles requêtes au flux de calcul dès que les requêtes précédentes sont terminées, plutôt que d'attendre que toutes les requêtes d'un lot soient achevées. Moins d'emplacements restent inoccupés, et le système passe moins de temps entre les lots.

Cela affecte directement le débit. En maintenant le lot actuel rempli sur différentes itérations, les frameworks de traitement par lots continu peuvent servir plus de jetons par seconde avec le même matériel. Dans des configurations de service LLM réelles comparables, les équipes signalent souvent que l'utilisation passe d'environ 30 à 50 % avec des stratégies de traitement par lots statiques ou dynamiques plus simples à environ 70 à 90 % avec le traitement par lots continu, bien que les résultats exacts dépendent du modèle, du GPU, de l'environnement d'exécution, du mélange de requêtes et de la politique de planification.

Le traitement par lots continu réduit également le coût par requête lorsqu'il est bien mis en œuvre. L'infrastructure GPU est coûteuse, et une grande partie du coût d'inférence provient du temps matériel, des poids du modèle résidant en mémoire, et du temps passé à charger les paramètres du modèle ou à déplacer des données via le sous-système de mémoire. Étant donné que l'inférence dépend souvent de la bande passante mémoire plutôt que du pur calcul, une utilisation plus élevée du GPU signifie que le même GPU peut prendre en charge plus de jetons de sortie utiles par heure.

Le comportement de la file d'attente s'améliore également. Les requêtes entrantes n'ont pas à attendre que l'intégralité du lot existant soit traitée. Dès que les séquences terminées sont traitées, le planificateur peut admettre de nouvelles requêtes, sous réserve de la capacité du GPU et des limites du cache KV. Cela rend le système de service plus fluide en cas de trafic en rafale.

Pour les chatbots, copilotes, agents et charges de travail API, ces gains sont économiquement importants. Une utilisation plus élevée du calcul, un meilleur traitement des files d'attente et un débit plus stable peuvent réduire le nombre de GPU nécessaires pour répondre à la même demande. Mais l'avantage n'est pas automatique. Un planificateur qui ne cherche qu'à maximiser le débit peut nuire au temps de premier jeton ou à la latence de queue, les systèmes de production doivent donc équilibrer le débit, la latence et l'équité.

Compromis et défis de mise en œuvre

Le traitement par lots continu améliore l'efficacité des ressources, mais il est plus difficile à mettre en œuvre que le simple traitement par lots statique. Le serveur de modèle doit suivre l'état des requêtes, le nombre de jetons, les blocs de cache KV, la progression de la phase de préremplissage, la progression de la phase de décodage, les conditions d'arrêt et l'état de fin de séquence pour chaque séquence active.

La complexité de la planification est le premier compromis. Le planificateur doit décider quelles requêtes entrantes entrent dans le lot actif, quand les préremplissages s'exécutent, combien de jetons de décodage tiennent dans chaque passe avant, et si une requête doit attendre parce que l'utilisation de la mémoire est trop élevée. Il s'agit d'un mécanisme de planification plus sophistiqué qu'une simple taille de lot fixe.

La pression mémoire est le deuxième compromis. Le traitement par lots continu peut augmenter la concurrence, mais plus de séquences actives signifient plus d'état de cache KV. Étant donné que la consommation de mémoire GPU évolue avec la taille du modèle et la longueur de la séquence de jetons, le serveur a besoin d'un contrôle d'admission strict. S'il admet trop de requêtes, il peut manquer de mémoire ou déclencher une gestion inefficace du cache.

La latence est une autre préoccupation. Le traitement par lots continu améliore souvent le débit du système, mais il ne garantit pas une meilleure latence pour chaque requête. Si l'algorithme de traitement par lots privilégie le débit maximal, les requêtes courtes peuvent attendre derrière de longs préremplissages, ou les requêtes de décodage peuvent être retardées par l'admission agressive de nouvelles invites. Les bons systèmes surveillent le temps de premier jeton, la latence P90, la latence P99 et l'équité plutôt que d'optimiser uniquement les jetons par seconde, qui sont des thèmes centraux dans la plupart des guides pratiques sur l'inférence LLM en production.

Il existe également un problème d'équité entre les tâches de préremplissage et de décodage. Le préremplissage est souvent plus limité par le calcul car il traite de nombreux jetons d'invite à la fois. Le décodage est souvent plus sensible à la bande passante mémoire car il lit à plusieurs reprises les poids du modèle et l'état du cache KV pour la prédiction du jeton suivant. Ces phases créent un modèle de calcul différent, le planificateur doit donc décider comment partager la capacité du GPU entre elles.

Enfin, le traitement par lots continu nécessite une priorisation. Les requêtes d'inférence en production peuvent ne pas toutes avoir le même niveau de service. Une requête API payante, un travail par lots interne, une session de chat interactive et une évaluation en arrière-plan peuvent nécessiter un traitement différent. Sans voies prioritaires ou contrôle d'admission, un trafic à volume élevé peut créer des retards injustes même si le débit moyen semble élevé, c'est pourquoi des systèmes robustes de limitation de débit et de quotas pour les API LLM sont si importants.

Batching continu et gestion du cache KV

Le batching continu dépend fortement de la gestion du cache KV. L'ordonnanceur ne peut ajouter de nouvelles requêtes que si la mémoire GPU disponible est suffisante pour le modèle de base, l'état de la séquence de jetons active et les futurs jetons de décodage.

PagedAttention est l'une des idées les plus importantes dans ce domaine. Au lieu d'allouer une grande région de mémoire contiguë pour chaque requête, le système divise le cache KV en blocs ou pages plus petits. Chaque séquence active détient des références aux blocs dont elle a besoin. Lorsqu'une séquence émet un jeton de fin de séquence ou atteint une génération complète, ses blocs peuvent être libérés et réutilisés par une nouvelle requête.

Cette approche basée sur les blocs améliore l'efficacité de la mémoire car elle réduit la fragmentation. Avec des longueurs de séquence variables, les grandes allocations fixes peuvent laisser des trous inutilisables en mémoire. Les blocs de cache KV facilitent l'intégration de nombreuses séquences d'entrée et de sortie de différentes longueurs dans la mémoire GPU disponible.

La relation entre la taille du lot et l'utilisation de la mémoire n'est donc pas linéaire de manière simple. Une taille de lot plus grande peut augmenter le débit, mais seulement si le cache KV, les poids du modèle et la surcharge d'exécution tiennent en mémoire. Les paramètres du modèle doivent rester résidents, et le système doit éviter de charger à plusieurs reprises les paramètres du modèle ou de charger de nouveaux paramètres du modèle pour chaque requête. Dans un serveur d'inférence bien conçu, les poids du modèle sont déjà chargés ; le goulot d'étranglement est généralement le cache actif et la bande passante mémoire nécessaire pour le décodage, c'est pourquoi les accélérateurs rapides et riches en mémoire tels que les NVIDIA RTX 5090 pour l'inférence LLM peuvent avoir un tel impact.

C'est aussi là que le remplissage est crucial. Le batching continu combine le traitement par lots irrégulier et l'ordonnancement dynamique afin que le serveur puisse éviter les jetons de remplissage inutiles lorsque cela est possible. Moins de remplissage signifie que plus de mémoire et de calcul sont consacrés à de vrais jetons plutôt qu'à un alignement artificiel. Certains runtimes utilisent encore le remplissage de forme pour améliorer l'efficacité du noyau ou réutiliser les graphes CUDA, mais l'objectif est de réduire le gaspillage tout en maintenant l'efficacité du pipeline GPU.

En pratique, les frameworks de batching continu exposent des contrôles liés à la mémoire tels que le nombre maximal de jetons par lot, la taille des blocs de cache, le nombre maximal de séquences actives et les limites de réservation de mémoire. Ces contrôles déterminent si le système atteint une utilisation GPU plus élevée en toute sécurité ou s'il se pousse simplement vers une instabilité de la mémoire.

Où le batching continu apporte une valeur maximale

Le batching continu apporte le plus de valeur dans les API LLM et les applications de chat avec des modèles de requêtes variables. Ces systèmes reçoivent de multiples requêtes d'utilisateurs qui posent des questions différentes, fournissent des longueurs de contexte différentes et attendent des longueurs de réponse différentes. Un utilisateur peut demander une réponse d'une phrase ; un autre peut demander une analyse détaillée ; un autre peut arrêter la génération prématurément. Le batching continu maintient le serveur de modèles productif pendant que ces différences se manifestent.

Il est particulièrement efficace dans les scénarios à volume de requêtes élevé. Lorsque le trafic est faible, il peut ne pas y avoir suffisamment de requêtes entrantes pour remplir les emplacements libérés. Mais lorsqu'un système a un flux constant de requêtes entrantes, les séquences terminées peuvent être remplacées rapidement, ce qui entraîne une utilisation GPU plus élevée et un meilleur débit.

Le service d'utilisateurs concurrents est un autre cas d'usage idéal. Les systèmes servant des centaines à des milliers d'utilisateurs ne peuvent pas se permettre de laisser un GPU inactif en attendant la requête la plus lente d'un lot fixe. Le batching continu permet au lot actif d'évoluer à mesure que les utilisateurs arrivent, génèrent et terminent.

Les charges de travail d'inférence par lots avec des longueurs de séquence mixtes en bénéficient également. Les tâches de résumé, d'évaluation, d'extraction et de traitement de documents hors ligne contiennent souvent des longueurs de séquence d'entrée inégales et des exigences de sortie inégales. Le batching continu peut combler les lacunes que le batching statique laisserait ouvertes, en particulier lorsque des tâches longues et courtes sont mélangées.

Il est également utile pour les moteurs d'inférence servant plusieurs tailles de modèles ou classes de charges de travail, à condition que le runtime prenne en charge l'ordonnancement et l'isolation de la mémoire requis. Les plateformes multi-locataires doivent être prudentes : le batching continu peut améliorer l'utilisation, mais les politiques de priorité et d'équité sont importantes lorsque différents clients, modèles ou objectifs de latence partagent l'infrastructure.

Comment évaluer les performances du batching continu

La première métrique est le nombre de jetons par seconde. Elle mesure le nombre de jetons de sortie que le système sert pour toutes les requêtes actives. C'est la métrique de débit la plus claire et elle aide à évaluer si le batching continu améliore réellement le travail utile sur le GPU.

La deuxième métrique est le temps jusqu'au premier jeton. Dans les applications LLM interactives, les utilisateurs se soucient de la rapidité avec laquelle le modèle commence à répondre. Le batching continu peut améliorer le temps jusqu'au premier jeton en admettant les requêtes plus fluidement, mais il peut aussi le nuire si l'ordonnanceur retarde les pré-remplissages de manière trop agressive. Mesurez-le directement plutôt que de faire des suppositions.

Les percentiles de latence sont tout aussi importants que les moyennes. Le P50 montre l'expérience typique, tandis que le P90 et le P99 révèlent la latence de queue. Un système peut afficher un débit moyen élevé et pourtant mal fonctionner pour les utilisateurs bloqués par de longues invites, une pression mémoire ou un ordonnancement inéquitable.

L'utilisation du GPU et l'utilisation de la bande passante mémoire doivent être surveillées conjointement. Une utilisation élevée du GPU n'est utile que si elle correspond à une génération réelle de jetons plutôt qu'à un remplissage gaspillé ou à une surcharge de l'ordonnanceur. Étant donné que l'inférence LLM est souvent limitée par la mémoire-E/S, la bande passante mémoire de la puce, les lectures du cache KV et la pression mémoire du GPU peuvent expliquer les limites de performance mieux que les seules métriques de calcul, et elles influencent fortement si les GPU grand public comme les Les RTX 4090 ou 5090 peuvent surpasser les cartes de centre de données de la catégorie A100 pour une charge de travail donnée.

Le coût par jeton de sortie est la métrique économique. Si le traitement par lots continu permet au même GPU de traiter plus de jetons par heure sans latence inacceptable, le coût par requête diminue. Cependant, le calcul doit inclure la complexité opérationnelle, la surcharge de mémoire et l'effort d'ingénierie nécessaire pour exécuter le traitement par lots continu en toute sécurité.

Les métriques d'efficacité des lots aident à diagnostiquer le gaspillage. Suivez le pourcentage d'emplacements actifs effectuant un travail utile, la quantité de jetons de remplissage, l'occupation du cache kv, la profondeur de la file d'attente et la fréquence à laquelle de nouvelles requêtes sont admises dans le lot existant. Pour un benchmarking précis, maintenez l'infrastructure stable : utilisez le même type de GPU, pilote, modèle, environnement d'exécution, précision, politique de lot et distribution réaliste des requêtes.

Traitement par lots continu vs autres optimisations de LLM

Le traitement par lots continu est souvent abordé en parallèle avec d'autres méthodes d'optimisation de LLM, mais il résout un problème différent.

Ce n'est pas la même chose que la quantification ou la compression. La quantification réduit la taille ou la précision des poids et des paramètres du modèle, comme le passage de FP16 à INT8 ou INT4. Cela peut réduire l'utilisation de la mémoire et améliorer la vitesse, mais cela ne décide pas comment les requêtes entrantes sont planifiées dans le lot actuel ; la quantification est un levier complémentaire abordé en détail dans des guides pratiques sur la quantification des LLM.

Ce n'est pas la même chose que le décodage spéculatif. Le décodage spéculatif tente d'accélérer la génération en utilisant un modèle brouillon plus petit ou une autre méthode de prédiction pour proposer des jetons, puis en les vérifiant avec le modèle principal. Le traitement par lots continu se concentre sur la manière dont plusieurs requêtes sont multiplexées à travers les itérations de décodage.

Ce n'est pas la même chose que le parallélisme tensoriel ou le parallélisme GPU. Le parallélisme répartit le travail sur plusieurs GPU ou unités de calcul afin que des modèles plus grands ou des lots plus importants puissent s'exécuter. Le traitement par lots continu peut fonctionner en parallèle avec les stratégies de parallélisme GPU, mais il doit tenir compte de la surcharge de communication et de la synchronisation entre les appareils, qui sont des préoccupations centrales dans les guides de déploiement de LLM multi-GPU.

Ce n'est pas non plus la même chose que le streaming de sortie. Le streaming envoie les jetons à l'utilisateur au fur et à mesure qu'ils sont générés. Le traitement par lots continu décide quelles séquences sont actives dans le lot à chaque étape. Un système peut diffuser en continu sans traitement par lots continu, et un système peut utiliser le traitement par lots continu tout en diffusant les résultats aux utilisateurs, souvent via le streaming basé sur SSE ou WebSocket pour les applications LLM.

Les optimisations de l'attention sont complémentaires. FlashAttention, l'attention paginée, les noyaux fusionnés et les améliorations de la disposition du cache kv réduisent le coût de l'attention et du mouvement de la mémoire. Le traitement par lots continu peut amplifier ces gains car il maintient un flux de travail de décodage plus utile à travers l'environnement d'exécution. Les piles d'inférence les plus performantes combinent généralement plusieurs techniques : des noyaux efficaces, une bonne allocation de mémoire, une gestion stable du cache kv et un ordonnanceur conçu pour les charges de travail irrégulières.

Quand le traitement par lots continu est le plus pertinent

Le traitement par lots continu est le plus pertinent dans les environnements de service de production à haut débit. Si un service gère de nombreuses requêtes d'inférence concurrentes, la capacité à remplacer les séquences terminées par de nouvelles requêtes peut améliorer considérablement le débit et réduire le nombre de GPU nécessaires.

C'est pertinent lorsque les longueurs de séquence varient. Les charges de travail qui mélangent des invites courtes, des invites longues, des réponses courtes, des essais longs, la génération de code, les sorties d'outils et les arrêts anticipés sont précisément là où le traitement par lots statique gaspille de la capacité. Le traitement par lots continu gère ces longueurs de séquence inégales en permettant à chaque séquence de se terminer indépendamment.

C'est important dans les scénarios d'inférence sensibles aux coûts. Lorsque le coût du GPU représente une part importante des dépenses d'exploitation, une meilleure utilisation du calcul et du GPU se traduit par une meilleure rentabilité. Le système obtient plus de résultats de modèle avec le même matériel.

C'est important dans les plateformes de service LLM multi-locataires. Différents utilisateurs, équipes ou applications peuvent partager le même backend d'inférence. Le traitement par lots continu peut aider à maintenir le matériel partagé occupé, mais seulement si l'ordonnanceur applique l'équité, la priorité et les limites de mémoire.

C'est important dans les applications en temps réel nécessitant des temps de réponse constants. Les chatbots, copilotes, agents et assistants nécessitent un équilibre délicat : maximiser le débit sans sacrifier le temps jusqu'au premier jeton ou la latence de queue. Le traitement par lots continu est l'une des techniques fondamentales qui rend cet équilibre possible, car il traite le service LLM comme un flux de sessions de génération de jetons irrégulières plutôt que comme une série de lots fixes et isolés.

‍

‍