Batching
Le batching en inférence de modèle est la pratique de regrouper plusieurs demandes d'entrée et de les traiter ensemble dans un seul passage avant à travers le modèle, améliorant l'utilisation du GPU et le débit. Le batching continu étend cela en insérant et supprimant des séquences en cours de génération plutôt que d'attendre que l'ensemble du batch se termine.
Le batching agrège plusieurs demandes d'inférence — chacune une séquence de tokens — en un seul tenseur fourni au modèle simultanément. Les opérations de multiplication matricielle GPU traitent un batch de n séquences presque aussi vite qu'une seule séquence quand la capacité mémoire le permet, car le coût fixe du chargement des poids du modèle à partir de la mémoire est amorti sur tous les membres du batch. Sans batching, chaque demande engage ce surcoût indépendamment, laissant les GPU sous-utilisés.
En batching statique (ou synchrone), un groupe fixe de demandes est assemblé avant le début de la génération ; toutes les séquences doivent être complétées avant que le batch soit libéré, donc les demandes qui se terminent rapidement restent inactives en attente des lentes. Ce blocage head-of-line produit généralement une utilisation GPU de 20–40 % sous des charges de longueurs mixtes. Le batching continu, introduit dans l'article de recherche Orca (2022) et adopté par vLLM (2023), planifie au niveau de l'itération : les séquences complétées sont évincées et les nouvelles demandes insérées à chaque étape de décodage, gardant le GPU complètement chargé indépendamment de la variance de longueur de séquence. Cela augmente l'utilisation à 70–90 %+ en pratique.
Le batching est le mécanisme principal par lequel les systèmes de service amortissent le surcoût GPU sur les utilisateurs simultanés. C'est aussi le levier principal disponible aux opérateurs qui veulent augmenter le débit sans ajouter de matériel. Le coût est une latence accrue pour les demandes individuelles, car une demande doit parfois attendre en queue jusqu'à ce qu'un slot de batch s'ouvre — un compromis qui peut être réglé en ajustant la taille maximale du batch et la politique de planification.
Depuis 2026, le batching continu est la stratégie par défaut dans les runtimes LLM open-source majeurs — vLLM, LMDeploy, SGLang et MLC-LLM — et est utilisé en interne par tous les grands fournisseurs d'inférence commerciale. Les domaines de recherche actifs incluent le chunked prefill (intercaler le traitement des invites avec le décodage pour réduire les pics de latence), le batching spéculatif et les architectures désagrégées qui séparent les charges de prefill et de décodage sur différents pools de matériel pour un contrôle de ressource plus fin.