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 peut améliorer le débit et réduire le temps d'inactivité lorsque des requêtes attendent et que les budgets de mémoire et de calcul permettent de les admettre.

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, sous réserve de requêtes en attente, de mémoire disponible et du budget de jetons de l'ordonnanceur.

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 peut rester mieux rempli si des requêtes attendent et si les limites de mémoire et d'ordonnancement le permettent.

Le traitement par lots continu peut être associé au traitement par lots irrégulier (ragged batching) pour limiter le calcul sur des jetons de remplissage (padding tokens). L'ordonnancement continu ne supprime pas à lui seul tout remplissage : cela dépend aussi des noyaux et de l'environnement d'exécution. 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.

Les limites de performance varient selon la phase et la charge. Le préremplissage est souvent davantage limité par le calcul, tandis que le décodage peut être davantage limité par la bande passante mémoire, notamment avec de petits lots. Le serveur doit lire les poids du modèle et l'état du cache KV pendant la génération. La documentation d'optimisation de vLLM distingue ces profils pour expliquer l'ordonnancement du préremplissage et du décodage. Il faut mesurer le goulot d'étranglement de la configuration utilisée plutôt que supposer que toute l'inférence est limitée par les E/S mémoire.

La mémoire nécessaire comprend les poids du modèle, le cache KV des séquences actives et les autres allocations de l'environnement d'exécution. La taille du cache par jeton dépend de l'architecture et de sa précision. À titre d'exemple historique, l'article PagedAttention de 2023 décrit OPT-13B avec un cache FP16 : 2 vecteurs × 5 120 dimensions × 40 couches × 2 octets, soit 819 200 octets (800 Kio) par jeton. Ce calcul ne s'applique pas à tous les modèles de 13 milliards de paramètres. La mémoire GPU, l'allocation du cache KV et la taille du lot déterminent combien de requêtes simultanées un déploiement peut prendre en charge, et interagissent avec le choix du GPU pour l'inférence des LLM (en anglais).

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 regroupe les requêtes disponibles selon les limites configurées. Un délai de collecte facultatif permet d'attendre d'autres requêtes avant de lancer un lot ; ce délai peut améliorer le débit mais ajoute de l'attente. Dans Triton, le comportement par défaut n'ajoute pas de délai de collecte. Ce compromis doit être mesuré sur la charge réelle. Une fois le lot lancé, sa composition reste généralement fixe : ce mécanisme ne remplace pas à lui seul les séquences terminées au cours de la génération.

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, ce qui peut améliorer l'utilisation du GPU sous réserve de mémoire et de requêtes disponibles. Dans le traitement par lots continu, la composition du lot change dynamiquement à chaque itération de décodage, ce qui peut augmenter le débit et réduire le temps d'inactivité du 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 (en anglais) 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'ordonnancement qui permet de remplacer les séquences terminées entre les itérations. Il peut ainsi améliorer le débit sans attendre la fin de la séquence la plus longue. La gestion du cache KV, notamment avec PagedAttention, traite séparément l'allocation de mémoire.

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 (en anglais).

Avantages du traitement par lots continu

Le principal avantage recherché est une meilleure utilisation du GPU. Le traitement par lots continu peut améliorer cette utilisation 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. Si des requêtes attendent et peuvent être admises, moins d'emplacements restent inoccupés.

En renouvelant le lot actif, le traitement par lots continu peut augmenter le nombre de jetons servis par seconde avec le même matériel. Aucune plage d'utilisation GPU ne peut être présentée ici comme un résultat habituel sans benchmark identifié et comparable. Le travail sur Orca documente l'ordonnancement au niveau de l'itération dans un cadre expérimental précis ; ses résultats ne constituent pas une plage universelle d'utilisation GPU. Comparez les stratégies avec le même modèle, le même matériel, les mêmes versions et une distribution de requêtes représentative, en mesurant aussi la latence.

Le traitement par lots continu peut réduire le coût par requête si le débit utile augmente à coûts comparables et si les objectifs de latence restent respectés. Une hausse du pourcentage d'utilisation GPU ne suffit pas à démontrer ce gain. Comparez le coût des requêtes ou des jetons effectivement servis, à qualité et charge comparables, en tenant compte du temps matériel et des coûts d'exploitation.

Le traitement par lots continu peut aussi réduire certaines attentes dans la file. 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. Le gain dépend toutefois de la charge et de la politique d'admission ; un pic de trafic peut toujours allonger la file d'attente.

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 peut améliorer 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 (en anglais).

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 (en anglais) 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.

Sur une plateforme qui sert plusieurs modèles, le traitement par lots continu s'applique aux requêtes compatibles prises en charge par chaque moteur. Il ne signifie pas que des modèles de base différents sont automatiquement regroupés dans un même lot. La FAQ de vLLM (en anglais) décrit des instances de serveur distinctes et une couche de routage pour servir plusieurs modèles. Les plateformes multi-locataires doivent aussi définir des politiques de priorité, d'équité et d'isolation des ressources.

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 indique la médiane, tandis que le P90 et le P99 décrivent les valeurs élevées de la métrique mesurée. Ces percentiles ne mesurent pas à eux seuls le temps passé dans la file d'attente : distinguez le temps jusqu'au premier jeton, la latence entre jetons, la latence de bout en bout et le temps d'attente. 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. Selon la définition de NVIDIA pour nvidia-smi, l'utilisation GPU indique la part de la période d'échantillonnage pendant laquelle au moins un noyau s'exécute. Elle ne mesure directement ni le débit utile ni la part de la puissance de calcul maximale exploitée. Comparez-la au débit de jetons et aux objectifs de latence. Lorsque le décodage est limité par la bande passante mémoire, les lectures des poids et du cache KV ainsi que la pression mémoire aident à expliquer les limites de performance. Le benchmark Hivenet des RTX 4090, RTX 5090 et A100 80 Go porte sur Llama 3.1 8B Instruct en BF16 et deux profils de charge précis. Il ne désigne pas un GPU gagnant pour tous les modèles, contextes ou niveaux de concurrence.

Le coût par jeton de sortie est la métrique économique. Si le même GPU traite plus de jetons utiles par heure à coût horaire comparable et sans latence inacceptable, le coût par jeton peut diminuer. Le coût par requête dépend aussi de la longueur des entrées et des sorties. 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 comparer les stratégies, conservez le même modèle et sa révision, les mêmes GPU, versions logicielles, précision et distribution réaliste des requêtes. Changez une variable d'ordonnancement à la fois. Consignez la concurrence, les longueurs d'entrée et de sortie, les limites de mémoire, les percentiles de latence, les erreurs et les résultats bruts. L'outil de benchmark de vLLM permet de conserver des résultats et de mesurer plusieurs métriques de latence.

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 (en anglais).

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 (en anglais).

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 (en anglais).

Les optimisations de l'attention sont complémentaires. FlashAttention optimise le calcul de l'attention et ses accès mémoire. PagedAttention améliore surtout l'allocation et le partage du cache KV ; il ne réduit pas la quantité de KV requise par jeton pour une architecture et une précision données. 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 hausse du débit utile peut améliorer la rentabilité si elle respecte les objectifs de latence et de qualité. Le pourcentage d'utilisation GPU seul ne permet pas de conclure que le système produit plus de résultats utiles 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.

‍

‍