Continuous Batching
iaDéfinition
Le Continuous Batching (aussi appelé Dynamic Batching ou Iteration-level Scheduling) est une technique d'optimisation pour les serveurs d'inférence LLM qui améliore drastiquement l'utilisation GPU et le débit en traitant les requêtes au niveau des itérations de génération plutôt qu'au niveau des requêtes complètes. Cette technique est implémentée dans vLLM, TGI et la plupart des serveurs LLM production modernes. Dans un serveur LLM naïf utilisant le Static Batching, les requêtes d'un même batch sont traitées ensemble de bout en bout : le serveur attend que toutes les séquences du batch aient terminé leur génération avant d'en démarrer de nouvelles. Si une séquence génère 10 tokens et une autre 500 tokens, le GPU est sous-utilisé pendant les 490 étapes où la courte séquence est terminée mais la longue continue. Le Continuous Batching résout ce problème d'alignement en autorisant les séquences terminées à être immédiatement remplacées par de nouvelles requêtes en attente dans la file. À chaque étape de décodage, le scheduler peut retirer les séquences finies (EOS token atteint ou longueur max) et insérer de nouvelles séquences. Résultat : le GPU reste constamment occupé à sa capacité maximale, peu importe la distribution des longueurs de génération. L'implémentation du Continuous Batching est complexe car elle nécessite de gérer des séquences de longueurs variables dans un même batch (padding ou packing), de mettre à jour dynamiquement le KV-Cache (d'où l'importance de PagedAttention), et de coordonner le scheduling entre le préfill (traitement du prompt) et le decode (génération token par token). En pratique, le Continuous Batching permet d'augmenter le throughput (tokens générés par seconde) de 5-23× selon le mix de longueurs de requêtes, tout en réduisant la latence médiane P50 pour les requêtes courtes qui ne sont plus bloquées par des requêtes longues.
Static vs Continuous Batching
Scénario : 4 requêtes avec des longueurs de génération de 10, 50, 200, 500 tokens.
- Static batching : attend 500 itérations pour toutes les requêtes. Utilisation GPU effective ≈ 19%
- Continuous batching : les requêtes terminent progressivement, remplacées par nouvelles. Utilisation GPU ≈ 85%+
Interaction avec Prefill et Decode
Les serveurs LLM modernes distinguent deux phases :
- Prefill : traitement parallèle du prompt (GPU-compute bound) — très rapide
- Decode : génération séquentielle token par token (GPU-memory bound) — lent
Sarathi-Serve (2024) introduit le "chunked prefill" : diviser les longs prefills en chunks pour les intercaler avec les decodes, réduisant la latence time-to-first-token (TTFT) pour les requêtes en attente.
Métriques en production
# Monitoring vLLM (Prometheus)
# vllm:num_requests_running - requêtes en cours de décodage
# vllm:num_requests_waiting - requêtes en file d'attente
# vllm:gpu_cache_usage_perc - % KV-Cache utilisé
# vllm:e2e_request_latency_seconds - latence end-to-end
# Si gpu_cache_usage_perc → 100% : augmenter GPU ou réduire max_model_len
Articles liés
Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.
Services
- Audit Infrastructure
- Audit Kubernetes
- Audit Microsoft 365
- Audit Sécurité Réseau
- Analyse de Risques
- Audit Active Directory
- Audit Application Web
- Audit Cloud (AWS/Azure/GCP)
- Audit Messagerie
- Audit API (OWASP Top 10)
- Audit DevSecOps & CI/CD
- Audit Code Source (SAST)
- Audit Postes de Travail
- Audit Sauvegarde & Résilience
- Audit OT/SCADA (IEC 62443)
- Développement IA
- Formations
Ressources
Projets & Outils
© 2026 Ayi NEDJIMI Consultants. Tous droits réservés. 2.1.7
Un projet cybersécurité ?
Expert dispo · Réponse 24h