Inférence LLM : ce que change le continuous batching

En inférence LLM, le continuous batching permet à un GPU partagé d'accueillir de nouvelles requêtes entre deux étapes de génération. Les tâches courtes ne laissent donc plus de capacité inutilisée en attendant que les plus longues se terminent. L'article fondateur sur Orca, publié par Yu et ses collègues à OSDI en 2022, décrit ce changement d'ordonnancement. Cette approche peut augmenter le nombre total de tokens produits par seconde lorsque les requêtes se chevauchent. Mais un serveur plus occupé ne répond pas forcément plus vite à chaque utilisateur.

Pour un serveur de modèle partagé, le bon objectif est de accomplir davantage de travail tout en respectant vos limites de temps de réponse. Un graphique de débit sans objectif de latence ne dit pas combien de clients le serveur peut servir dans de bonnes conditions.

Les fonctionnalités et les réglages des serveurs présentés ci-dessous ont été vérifiés dans la documentation officielle en ligne le 25 octobre 2026. L'exemple d'ordonnancement sert à illustrer le mécanisme ; ce n'est pas un benchmark matériel.

Inférence LLM : comment fonctionne le continuous batching ?

Le batching continu modifie le groupe de requêtes actives pendant la génération. Une requête terminée sort du lot ; une requête en attente peut y entrer si l'ordonnanceur dispose des ressources nécessaires. On parle aussi d'in-flight batching ou d'iteration-level batching.

Un grand modèle de langage, ou LLM, commence par traiter votre prompt pendant la phase de prefill, puis génère la suite pendant la phase de decode. En décodage autorégressif classique, chaque requête active produit son prochain token, un fragment de texte, au cours d'une étape de génération. L'ordonnanceur choisit les requêtes qui participeront à l'étape suivante. Le guide de l'inférence LLM détaille ces phases.

Imaginez une grande table partagée. Avec un service par groupes fixes, les convives suivants ne s'installent qu'une fois le groupe précédent parti. Avec un service continu, une place libérée accueille un nouveau convive alors que d'autres mangent encore. La table est commune, mais chacun garde son propre repas.

L'analogie a ses limites : l'ordonnanceur du GPU doit aussi faire de la place au traitement des prompts et à l'allocation de mémoire. Une chaise libre ne signifie donc pas que n'importe quelle requête en attente peut entrer immédiatement.

Ce qu'Orca a apporté à l'ordonnancement

Avec Orca, l'ordonnancement se décide à chaque itération, et non plus à l'échelle d'une requête entière. Dans leur article présenté à OSDI en 2022, Gyeong-In Yu et ses collègues décrivent un moteur d'exécution appelé pour une seule itération du modèle, avant de réexaminer la composition du lot.

Une technique complémentaire, le selective batching, regroupe certaines opérations du modèle tout en tenant compte des historiques différents dont a besoin l'attention, l'opération qui relie un token au contexte qui le précède. Ensemble, ces techniques permettent au système de service d'entrelacer des requêtes de longueurs différentes. L'article traite également la taille du lot et la mémoire clé-valeur disponible comme des contraintes d'ordonnancement. Lire l'article sur Orca.

Le changement concerne le système qui sert le modèle. Il n'impose pas d'entraîner celui-ci à répondre à plusieurs personnes dans une même conversation.

Batching statique, dynamique et continu : quelles différences ?

La question décisive est de savoir à quel moment une nouvelle requête peut rejoindre le travail en cours. Accepter des connexions HTTP simultanées ne prouve pas que l'exécution du modèle utilise du batching continu.

La documentation de NVIDIA sur le batching dans Triton décrit le batching dynamique classique, notamment les réglages de taille des lots et de délai d'attente en file. Ces réglages répondent à une autre question d'ordonnancement que le remplacement de requêtes pendant la génération d'un LLM.

Batching dynamique dans vLLM : quand le lot peut-il changer ?

vLLM, un moteur de service de LLM, documente le batching continu. L'appellation « batching dynamique » est moins précise. Hugging Face emploie aussi dynamic scheduling ou dynamic batching pour désigner le remplacement des prompts terminés pendant la génération dans son explication du continuous batching. Vérifiez si le moteur admet de nouvelles tâches entre deux étapes de génération, sans vous fier au seul nom de la fonctionnalité.

Le streaming est encore autre chose. Un serveur peut transmettre les tokens au client au fil de leur génération tout en conservant un lot de composition fixe. L'intérêt du mécanisme présenté ici est que les nouvelles requêtes peuvent utiliser la capacité libérée par celles qui se terminent.

Un exemple d'ordonnancement

Une tâche courte peut libérer de la capacité utile pendant qu'une tâche plus longue continue. Prenons un serveur fictif doté de deux places pour le décodage. Il reste 2 étapes à la requête A, 4 à B, et C attend avec 2 étapes de travail à effectuer. Pour cet exemple, nous ignorons le prefill, le coût de l'ordonnancement et les variations de durée des étapes.

Avec un lot fixe, A et B démarrent ensemble. A se termine, mais C attend la fin de B avant que le groupe suivant ne démarre. Avec le batching continu, C peut prendre la place de A dès que celle-ci se termine et avancer en parallèle de B.

Cet exemple montre une admission plus précoce, pas une accélération mesurée. Un chatbot d'assistance qui mélange réponses courtes et longs résumés offre la même possibilité d'ordonnancement ; le gain réel dépend des requêtes, du matériel et de la configuration du serveur.

Pourquoi le débit augmente, et comment le cache KV le limite

Le batching tire davantage de travail utile d'un même transfert des poids du modèle. Les poids sont les paramètres numériques appris qui servent à calculer une réponse. Plusieurs requêtes adressées au même modèle peuvent partager le travail de transfert de ces poids à travers la mémoire du GPU, ce qui améliore l'utilisation de la puissance de calcul disponible. L'ordonnancement continu aide à maintenir ce lot utile à mesure que les requêtes se terminent. NVIDIA explique le lien entre batching, transferts mémoire et utilisation du GPU.

Un GPU peut rester occupé même avec un lot inefficace. Ce qui compte, c'est la quantité de travail utile produite pour les requêtes, pas l'allure bien remplie d'un graphique d'utilisation.

Mais chaque requête active a aussi besoin de mémoire de travail. Son cache KV, pour key-value cache ou cache clé-valeur, conserve l'état d'attention des tokens déjà traités. Davantage de requêtes simultanées et des historiques plus longs accentuent la pression sur cette mémoire. L'explication du cache KV distingue cet état de la mise en cache de prompts réutilisables.

PagedAttention utilise mieux la mémoire disponible

Le batching continu décide de ce qui s'exécute ; PagedAttention modifie la façon de stocker l'état d'attention. Dans leur article de 2023 sur vLLM, Woosuk Kwon et ses collègues décrivent le découpage de l'état KV en blocs de taille fixe, qui n'ont pas besoin d'occuper des emplacements contigus en mémoire physique. Une table de correspondance des blocs préserve l'ordre logique de la séquence.

Cette organisation réduit la mémoire perdue à cause de la fragmentation et des duplications inutiles. En utilisant mieux l'espace, on peut y faire tenir les données de travail de davantage de requêtes. L'ordonnanceur dispose alors de plus de travail utile parmi lequel choisir. L'article présente explicitement cette approche de gestion mémoire comme complémentaire de l'ordonnancement d'Orca.

La limite reste la capacité physique. Une meilleure utilisation de l'espace ne permet pas d'y faire tenir un nombre illimité de longues conversations. Dans vLLM, un manque d'espace KV peut entraîner une préemption : une requête est mise en pause, puis son état est recalculé ultérieurement, ce qui peut allonger son délai d'exécution complet. La documentation d'optimisation explique ce comportement.

Quel effet sur la latence ?

Le batching continu peut réduire l'attente en file, tandis que des lots plus grands ou plus chargés peuvent dégrader l'expérience une fois la requête admise. Suivez séparément les différentes étapes :

• Délai avant le premier token, ou TTFT : le temps d'attente de l'utilisateur avant que la réponse commence à s'afficher.
• Latence entre tokens : les intervalles entre les tokens une fois le streaming commencé.
• Latence de bout en bout : la durée totale de la requête.

Une nouvelle requête peut éviter d'attendre la fin complète d'un lot fixe. En revanche, le traitement d'un nouveau prompt volumineux peut entrer en concurrence avec les requêtes déjà en cours de décodage. Le chunked prefill découpe le traitement du prompt en fragments plus petits, que l'ordonnanceur peut entrelacer avec la génération en cours.

vLLM documente par exemple un compromis lié au budget de tokens par itération : des valeurs plus faibles peuvent préserver la latence entre tokens, tandis que des valeurs plus élevées peuvent traiter davantage de prefill et améliorer le TTFT. Ce budget doit donc dépendre de la charge de travail ; ce n'est pas un réglage à pousser au maximum sans discernement. Voir les conseils de réglage de vLLM.

Batching continu des LLM : que se passe-t-il à faible ou forte charge ?

À faible charge, il y a parfois peu de requêtes à regrouper ; en surcharge prolongée, une file d'attente subsiste. Un développeur qui envoie ses requêtes une par une ne doit pas attendre le même bénéfice qu'un service destiné aux clients où les requêtes se chevauchent. À l'autre extrême, accepter plus de travail que le GPU ne peut en absorber finit par allonger les temps d'attente.

Pour une application interactive, surveillez le p95, le 95e percentile, en plus de la médiane. Une bonne moyenne peut masquer des lenteurs pour une minorité de sessions. Définissez le TTFT et les intervalles de streaming acceptables en fonction de l'expérience produit, puis mesurez la capacité qui respecte ces limites.

Quels serveurs LLM proposent le batching continu, et avec quelles limites ?

Les quatre serveurs ci-dessous documentent le batching continu ou l'in-flight batching. Cette fonctionnalité commune ne rend pas leurs ordonnanceurs, leurs budgets mémoire ou leurs modèles pris en charge interchangeables.

vLLM : batching continu et gestion du cache KV

vLLM associe l'ordonnancement continu des requêtes à une gestion paginée du cache KV. Sa documentation mentionne explicitement les deux. Pour l'exploitation, les réglages utiles sont le nombre maximal de séquences et le nombre de tokens planifiés par itération, pas simplement un nombre souhaité de connexions simultanées à l'API.

La limite vient de la pression mémoire : augmenter le nombre de requêtes simultanées peut provoquer des préemptions et des recalculs au lieu d'accroître la capacité exploitable. Ajustez les réglages en fonction de votre trafic et de votre objectif de latence, en conservant le même modèle et le même matériel pour comparer les configurations.

SGLang

SGLang prend en charge le batching continu et expose des réglages explicites d'admission des requêtes. Sa documentation des arguments du serveur définit --max-running-requests, --chunked-prefill-size ainsi que le budget des poids du modèle et de la réserve KV contrôlé par --mem-fraction-static.

Ces réglages répondent à des questions différentes : combien de requêtes peuvent s'exécuter, quelle quantité de traitement de prompt entre dans un fragment et comment la mémoire est répartie. Relever la limite de requêtes ne supprime pas les autres contraintes. Pour choisir le moteur, consultez le comparatif vLLM et SGLang, puis évaluez le modèle précis et le mélange de requêtes que vous comptez servir.

NVIDIA TensorRT-LLM

NVIDIA TensorRT-LLM présente explicitement l'in-flight batching comme l'équivalent du batching continu et de l'iteration-level batching. Sa documentation décrit le traitement conjoint de séquences en phase de contexte et en phase de génération, avec des tenseurs d'entrée regroupés dans l'implémentation documentée.

La limite de requêtes et le budget de tokens constituent des contraintes distinctes. La documentation de son ordonnanceur PyTorch distingue également la réservation des ressources, dont la capacité KV, du choix des requêtes admissibles qui vont s'exécuter. Un ordonnanceur in-flight ne peut pas admettre une tâche qui échoue à ces contrôles de capacité.

Hugging Face Text Generation Inference

Hugging Face Text Generation Inference prend en charge le batching continu, mais son statut de maintenance change la donne pour un nouveau déploiement. Sa documentation indique que le projet accepte désormais des corrections mineures, des améliorations de documentation et une maintenance légère. Elle recommande pour la suite d'autres moteurs, dont vLLM et SGLang.

Une installation TGI existante ne perd pas le batching à cause de ce statut. Pour une nouvelle stack d'inférence, je commencerais l'évaluation par les alternatives dont le développement reste actif. Pour un déploiement établi qui atteint ses objectifs, planifiez la migration en fonction d'un besoin concret de support ou de fonctionnalités.

Quelles promesses faut-il relativiser ?

Le batching continu n'offre pas un facteur d'accélération transposable partout. Les articles sur Orca et PagedAttention évaluent des systèmes et des charges de travail précis. Leurs résultats n'isolent pas un gain universel que l'on pourrait appliquer à n'importe quel modèle, GPU ou endpoint de fournisseur.

Il ne supprime pas non plus l'attente. Une requête en file a toujours besoin que son prompt soit traité, que de la mémoire lui soit allouée et que l'ordonnanceur lui donne son tour. Les longs prompts, la forte demande simultanée et la pression sur le cache restent des limites.

Enfin, un débit total de tokens plus élevé ne prouve pas qu'un produit de chat s'est amélioré. Si les utilisateurs attendent davantage le premier token ou subissent des pauses gênantes pendant le streaming, ce débit supplémentaire peut se situer hors des conditions de fonctionnement acceptables pour le produit.

Que changer concrètement dès lundi ?

Les développeurs ont intérêt à évaluer un serveur partagé quand les requêtes se chevauchent ; les équipes d'exploitation doivent régler le système dans les limites de latence ; celles qui évaluent un fournisseur doivent demander des mesures sous contention. Un outil individuel utilisé ponctuellement peut attendre. Un service dont les clients patientent en file et dont les réponses ont des longueurs variées a une raison concrète d'agir. Le comparatif Ollama et vLLM aborde le passage d'un usage local à un serveur partagé.

1. 1

   Définir l'expérience attendue avant d'augmenter les requêtes simultanées

   Consignez les limites acceptables de délai avant le premier token, d'intervalles pendant le streaming et de durée totale pour le workflow réel. Un outil de résumé en arrière-plan et un assistant d'aide en direct n'ont pas les mêmes critères d'acceptation.

2. 2

   Rejouer un mélange de requêtes représentatif

   Gardez des conditions comparables pour le modèle, le matériel, la longueur des prompts, les limites de sortie et l'état du cache. Incluez des réponses courtes, des prompts longs et des générations longues. Conservez des rythmes d'arrivée réalistes : un test calme avec un seul utilisateur ne doit pas tenir lieu de test d'un service chargé.

3. 3

   Mesurer ensemble le débit, la file d'attente et la latence

   Mesurez le débit total de tokens de sortie par seconde, les requêtes terminées, les requêtes en attente, les échecs, le TTFT et les intervalles entre tokens. vLLM expose les métriques correspondantes, notamment vllm:num_requests_waiting, vllm:time_to_first_token_seconds et vllm:inter_token_latency_seconds, dans sa documentation des métriques de production.

4. 4

   Retenir la charge maximale qui respecte encore les objectifs

   Modifiez un seul réglage d'ordonnancement ou de mémoire à la fois. Cessez d'augmenter le nombre de requêtes simultanées dès que les limites de latence ne sont plus respectées ou que la pression mémoire provoque des recalculs répétés. Demandez au fournisseur la même vue du débit et de la latence au niveau de concurrence prévu, ainsi que le caractère partagé ou réservé de la capacité.

Le résultat attendu est une limite de fonctionnement mesurée : la charge que votre endpoint peut soutenir tout en préservant l'expérience utilisateur visée. C'est ce qui permet de passer d'une fonctionnalité de batching à une décision de déploiement.

Pour comprendre concrètement l'infrastructure d'IA et les changements à apporter à votre stack, abonnez-vous à la newsletter.