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

De quoi il s'agit

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 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.

Speculative decoding

Une optimisation de latence complémentaire où un petit modèle brouillon propose plusieurs tokens à l'avance et le grand modèle les vérifie en une seule passe avant ; réduit la latence par token pour une requête unique, alors que le batching continu élève le débit agrégé sur les requêtes concurrentes — les moteurs de production appliquent typiquement les deux.

Max batch size (max_num_seqs)

Le paramètre de configuration du planificateur plafonnant le nombre de séquences que le moteur peut traiter simultanément par itération ; trop bas, il gaspille la capacité GPU disponible ; trop haut par rapport à la mémoire du KV-cache, il risque l'éviction de pages et des pics de latence.

Sources

1. Yu et al. — Orca: A Distributed Serving System for Transformer-Based Generative Models (OSDI 2022, the iteration-batching paper)
2. Kwon et al. — Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023)
3. NVIDIA TensorRT-LLM in-flight batching documentation
4. Anyscale — How continuous batching enables 23x throughput in LLM inference
5. Databricks — LLM inference performance engineering best practices
6. NVIDIA Docs — TensorRT-LLM
7. vLLM Docs — Scheduler configuration reference
8. vLLM Documentation — project home
9. NVIDIA Technical Blog — TensorRT-LLM accelerates encoder-decoder models with in-flight batching
10. NVIDIA Triton Inference Server — TensorRT-LLM backend documentation
11. arXiv — SGLang: Efficient Execution of Structured Language Model Programs (2312.07104)
12. LMSYS Org — Fast and Expressive LLM Inference with RadixAttention and SGLang