Continuous Batching

Le traitement par lots continu, également appelé planification au niveau de l’itération ou traitement par lots en vol, est une technique de planification utilisée pour servir des modèles génératifs : le serveur reconstruit le lot à chaque étape de décodage. Une séquence terminée quitte immédiatement le lot et renvoie son résultat, et une requête en attente prend sa place à l’étape suivante. Gyeong-In Yu et ses collègues de l’Université nationale de Séoul et de FriendliAI ont présenté cette approche dans Orca à OSDI 2022, en rapportant un débit 36,9 fois supérieur à celui de NVIDIA FasterTransformer sur GPT-3 175B, pour une latence identique. Le terme « traitement par lots continu » s’est répandu en 2023, lorsque vLLM et Hugging Face Text Generation Inference l’ont adopté ; il s’agit désormais du planificateur par défaut des moteurs de service utilisés pour les grands modèles de langage (LLMs).

Pourquoi le traitement par lots au niveau des requêtes gaspille le GPU#

La génération de texte produit un jeton par passe avant, et le nombre de passes nécessaires varie fortement d’une requête à l’autre : une réponse par oui ou non se termine après quelques jetons, tandis qu’un fichier de code peut en contenir des milliers. Avec le traitement statique par lots, un groupe de requêtes reste ensemble jusqu’à la fin de la plus longue. Les emplacements dont les séquences se sont terminées tôt restent inactifs, et les nouvelles requêtes attendent que tout le groupe soit terminé, ce qui augmente la latence d’inférence de chaque requête courte placée derrière une longue.

Le traitement dynamique par lots, le mécanisme au niveau des requêtes utilisé par des serveurs comme NVIDIA Triton, regroupe les requêtes arrivées dans un court intervalle et les exécute ensemble jusqu’à leur terme. Cette approche convient aux modèles dont le coût par entrée est fixe, comme un classifieur d’images ou un détecteur d’objets, car chaque entrée est traitée en une seule passe avant. Le mode predict d’Ultralytics YOLO crée des lots de requêtes d’entrées YOLO26 à partir de la source : un fichier .streams contenant des URL de caméras forme un lot avec l’image la plus récente de chaque flux ; ainsi, 8 flux s’exécutent avec une taille de lot de 8, et l’argument batch regroupe les images d’une vidéo, d’un répertoire ou d’une liste d’images .txt en une seule passe avant.

Fonctionnement de la planification au niveau de l’itération#

Le planificateur exécute une étape de décodage pour chaque séquence active, puis vérifie si chacune a atteint un jeton de fin de séquence ou sa limite de longueur. Les séquences terminées sont renvoyées et leur mémoire est libérée ; les requêtes en attente sont admises si elles tiennent dans le cache KV. Orca traite (préremplit) l’invite d’une nouvelle requête à la même étape que le décodage des autres séquences, et les moteurs actuels font de même avec le préremplissage par blocs.

Le mélange de séquences de longueurs différentes nécessitait une autre idée, qu’Orca a appelée traitement sélectif par lots. Les opérations qui traitent chaque jeton indépendamment, comme les grandes multiplications matricielles de chaque couche Transformer, s’exécutent simultanément sur tous les jetons de toutes les séquences. Le mécanisme d’attention s’exécute par séquence, car chacune a sa propre longueur de contexte.

Cette simulation planifie les huit mêmes requêtes sur un GPU qui décode quatre séquences à la fois :

import heapq

output_lengths = [5, 50, 8, 12, 40, 3, 30, 7]  # tokens each queued request will generate
slots = 4  # sequences the GPU decodes together at each step

# Static batching: each group of 4 runs until its longest request finishes
static_steps = sum(max(output_lengths[i : i + slots]) for i in range(0, len(output_lengths), slots))

# Continuous batching: the next request takes the first slot that frees up
slot_free_at = [0] * slots
for length in output_lengths:
    start = heapq.heappop(slot_free_at)
    heapq.heappush(slot_free_at, start + length)
continuous_steps = max(slot_free_at)

for name, steps in [("static", static_steps), ("continuous", continuous_steps)]:
    print(f"{name}: {steps} decode steps, slots busy {sum(output_lengths) / (steps * slots):.0%}")

Le traitement statique par lots nécessite 90 étapes de décodage et les emplacements sont occupés 43 % du temps. Le traitement par lots continu termine en 50 étapes, soit la longueur de la requête la plus longue, et les emplacements sont occupés 78 % du temps.

Limites et techniques complémentaires#

Un lot en cours d’exécution plus grand augmente le débit total, mais chaque étape prend plus de temps, ce qui allonge le temps par jeton généré. Les moteurs limitent donc le nombre de séquences simultanées et le nombre de jetons traités par étape, des paramètres que vLLM expose sous les noms max_num_seqs et max_num_batched_tokens ; ils associent le traitement par lots continu à quelques techniques connexes :

• PagedAttention : alloue le cache KV en petits blocs, de sorte qu’une séquence terminée libère aussitôt sa mémoire et qu’une nouvelle séquence ne réserve que la mémoire dont elle a besoin.
• Préremplissage par blocs : divise les longues invites en segments afin que le préremplissage d’une nouvelle requête ne bloque pas le décodage de toutes les autres.
• Décodage spéculatif : apporte le gain le plus important avec de petits lots, car les grands lots continus utilisent déjà la majeure partie de la puissance de calcul du GPU.