Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Continuous Batching

ia

Dé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

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis