Fiche concept

Batching continu — Comment vLLM atteint 10x de débit

À jour au 2026-07-24T14:00:00Z

Édité par Cédric-Olivier Mâry, éditeur et directeur de la publication — 27 ans d'écosystème SAP. Comment ces pages sont produites, et où intervient l'automatisation.

Qu'est-ce que Batching continu — Comment vLLM atteint 10x de débit ?

Le batching statique gaspille 60-90 % du compute GPU car une seule requête longue dans un batch force le GPU à continuer de faire tourner des emplacements paddés pour des requêtes déjà terminées — le batching continu libère chaque emplacement dès que sa requête se termine.

Le batching continu — aussi appelé batching au niveau de l'itération ou « in-flight batching » — est la technique d'ordonnancement qui permet à un moteur d'inférence LLM de commencer à traiter une nouvelle requête dès qu'une requête plus ancienne se termine, plutôt que d'attendre que tout un lot se termine ensemble. C'est la première raison pour laquelle des moteurs comme vLLM et TensorRT-LLM atteignent un débit environ dix à vingt-quatre fois supérieur à celui d'une boucle de génération de texte naïve tournant sur le même matériel GPU, et cela vaut la peine d'être compris même pour un non-ingénieur évaluant un déploiement d'IA SAP, car cela pilote directement le coût par token et la latence de réponse qu'un consultant devra expliquer à un client.

Pourquoi le batching naïf échoue, et comment fonctionne l'alternative

Pourquoi c'est important

Le planificateur raisonne en itérations, pas en requêtes : il recompose le batch à chaque passe avant, admettant une nouvelle requête en attente dès qu'un emplacement se libère.
Combiné à PagedAttention, le batching continu maintient l'utilisation GPU à 60-90 % sur des requêtes de longueurs très variables, contre le gaspillage massif du batching statique.
Le débit s'améliore de 5-10× à budget matériel constant, avec une latence de queue P99 encore meilleure puisque les requêtes courtes n'attendent plus derrière les longues.

Points clés

Planification au niveau itération — nouvelles requêtes admises dans le batch dès que les anciennes finissent.
Le batching statique naïf gaspille 60-90 % du compute GPU sur charges réelles à longueur de sortie variable.
Combiné à PagedAttention (C246), le batching continu maintient le GPU à 60-90 % d'utilisation effective.
Amélioration de débit 10-24× vs baseline HuggingFace generate() ; 5-10× vs batching statique, à budget matériel constant.
La latence de queue P99 s'améliore car les requêtes courtes ne font pas la file derrière les longues.
La complexité d'implémentation explique pourquoi la plupart des équipes adoptent vLLM ou TensorRT-LLM.
Complémentaire au décodage spéculatif : batching continu = débit (fort trafic) ; décodage spéculatif = latence (mono-utilisateur).
Benchmark pratique : HuggingFace generate() 20-50 tokens/s vs vLLM 800-2 000 tokens/s sur le même H100 à 32 requêtes concurrentes.
Passage à vLLM pour traitement nocturne de documents SAP : réduction des heures GPU jusqu'à 10× — de 3,10 $/h à 0,31 $/h pour le même job.
Joule conversationnel mono-utilisateur bénéficie peu du batching continu — décodage spéculatif ou tier de modèle plus rapide sont les bons leviers.

Termes employés sur cette page

Continuous batching: Ordonnancement de l'inférence LLM au niveau de l'itération, de sorte que les nouvelles requêtes sont admises dans le lot dès qu'une requête plus ancienne se termine, plutôt que d'attendre l'achèvement de tout le lot.
Static batching: L'approche naïve où un lot de requêtes est figé au moment de l'admission et où toutes progressent ensemble à travers les passes avant jusqu'à ce que la plus longue se termine.
Iteration-level scheduling: Synonyme de batching continu ; souligne que les décisions d'ordonnancement se produisent à chaque itération de passe avant, et non aux frontières de requêtes.
Head-of-line blocking: Le problème de latence du batching statique où les requêtes courtes doivent attendre la fin de la requête la plus longue de leur lot ; éliminé par le batching continu.
Decision owner: La personne responsable qui accepte l'arbitrage et finance l'action suivante.
Semantic contract: La définition partagée des termes métier, métriques, entités et règles d'accès utilisée par les outils et les équipes.
Control plane: La couche qui applique la politique, les accès, la traçabilité (lineage), la supervision et l'escalade à travers le modèle opérationnel.
Evidence grade: Un label qui distingue le fait vérifié, le signal directionnel, l'hypothèse modélisée et l'observation de terrain.

Sources

Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code · les chiffres à citer.

Ouvrir dans l'application →