Le batching continu permet à un serveur vLLM d'admettre une nouvelle requête tandis que d'autres requêtes génèrent encore des tokens. Un lot fixe attend que tous ses membres aient terminé avant de pouvoir former le lot suivant ; le batching continu réévalue l'ensemble actif à chaque étape d'ordonnancement. Cette différence importe lorsque les prompts et les sorties ont des longueurs différentes. Les requêtes courtes peuvent rejoindre le travail du GPU sans attendre la réponse la plus longue d'un groupe précédent.
Pour une équipe d'inférence, la question utile n'est pas de savoir si le batching continu est activé dans une liste de fonctionnalités. Il s'agit de déterminer si votre combinaison réelle de requêtes augmente le nombre de réponses terminées par seconde sans faire dépasser le délai avant le premier token, le temps d'attente en file ou le taux d'erreur au-delà de l'objectif de votre service. Ce guide explique le mécanisme, les limites importantes et un benchmark que vous pouvez exécuter avant de choisir la capacité GPU.
Fonctionnement du batching continu de vLLM
Dans l'architecture V1 actuelle de vLLM, l'ordonnanceur remplit un budget de tokens à chaque étape à partir des requêtes en cours d'exécution et en attente. Une requête suit le nombre de tokens calculés ; l'ordonnanceur attribue du travail pour combler cet écart. La même boucle gère le préremplissage par morceaux, le cache de préfixes et le décodage spéculatif. C'est un modèle mental plus précis qu'un diagramme d'un lot statique unique qui s'exécute jusqu'à son terme. Consultez la vue d'ensemble de l'architecture vLLM pour la description de l'ordonnanceur.
Imaginez trois arrivées : une courte réponse de chat, un long prompt de document et un autre chat court. Avec un lot fixe, le second chat court pourrait attendre la limite de lot de la longue requête. Avec le batching continu, il peut être pris en compte lors d'une étape d'ordonnancement ultérieure tandis que les premières requêtes restent actives. L'admission reste contrainte par le budget de tokens, les limites de séquences et l'espace disponible du cache KV. Le batching continu ne garantit ni une absence de mise en file d'attente ni un résultat plus rapide pour chaque requête.
PagedAttention traite une autre partie du problème : le stockage et la gestion du cache KV d'attention en blocs. Il aide le moteur à utiliser la mémoire de manière plus flexible, tandis que l'ordonnanceur décide quelles requêtes reçoivent des ressources de calcul. Distinguer ces rôles vous aide à diagnostiquer si un faible débit est causé par l'ordonnancement, la pression sur le cache KV, les longs prompts ou un goulot d'étranglement en amont. La conception de PagedAttention de vLLM décrit le mécanisme de mémoire.
Les paramètres qui façonnent un lot
| Paramètre | Ce qu'il limite | Ce qu'il faut surveiller lorsque vous le modifiez |
|---|---|---|
max_num_batched_tokens |
Tokens traités dans une itération de l'ordonnanceur | Débit, délai avant le premier token, latence inter-tokens et progression des prompts longs |
max_num_seqs |
Séquences traitées dans une itération | Requêtes en cours d'exécution, marge de mémoire et latence de fin de distribution |
| Préremplissage par morceaux | Répartit un long préremplissage sur plusieurs étapes d'ordonnancement | Latence des prompts longs et interférence avec les requêtes de décodage |
| Limite de file d'attente ou d'admission | Requêtes autorisées à attendre ou à s'exécuter | Temps d'attente en file, taux de rejet et transmission ou non de la surcharge aux appelants |
| Capacité du cache KV | Contexte actif tenant sur le GPU | Préemption, recalcul et échecs par manque de mémoire |
Ces paramètres interagissent. Augmenter un budget de tokens peut améliorer le débit pour une charge de travail et dégrader la latence interactive pour une autre. Augmenter le nombre de séquences admises peut accroître la concurrence, mais aussi consommer davantage de cache KV. La version, l'architecture du modèle, les longueurs de contexte et le matériel influencent tous le résultat. Consultez la référence de configuration de l'ordonnanceur pour le comportement de votre version installée de vLLM, puis modifiez un paramètre à la fois.
Lorsque le cache KV ne peut pas accueillir de nouveau travail, vLLM peut préempter une requête en cours d'exécution puis recalculer ultérieurement sa progression. Un nombre de préemptions en hausse avertit que le simple ajout de nouvelles arrivées au lot n'est pas gratuit. La vue d'ensemble de l'architecture explique les règles d'ordonnancement et de préemption.
Un benchmark correspondant au trafic de production
Ne comparez pas les paramètres de batching continu avec un seul prompt court envoyé aussi vite que le client le peut. Constituez trois groupes de requêtes à partir de vos propres journaux ou d'une trace respectueuse de la confidentialité :
- Chats interactifs courts avec des prompts et des réponses brefs.
- Requêtes à contexte long avec de grands préremplissages et des longueurs de sortie modérées.
- Requêtes d'agent ou RAG avec des préfixes répétés, des longueurs de sortie variables, des annulations et des rafales.
Conservez la révision du modèle, le tokenizer, le type de GPU, la version de vLLM et la trace de requêtes fixes entre les exécutions. Faites varier le taux de requêtes proposé depuis une charge inférieure à celle attendue jusqu'au point où le temps d'attente en file ou les erreurs deviennent inacceptables. Le guide officiel vllm bench serve documente les contrôles du taux de requêtes et du jeu de données. Enregistrez la commande exacte, la configuration et la version de la trace afin que la comparaison puisse être répétée.
Pour chaque exécution, enregistrez les requêtes terminées par seconde, les tokens de sortie par seconde, le délai p50 et p95 avant le premier token, la latence inter-tokens p95, la latence de bout en bout p95, le temps d'attente en file, les échecs et le pic d'utilisation de la mémoire GPU. La référence des métriques de production de vLLM inclut des jauges pour les requêtes en cours d'exécution et en attente, ainsi que des histogrammes pour le temps d'attente en file, le délai avant le premier token et les préemptions. Un tableau de bord utile est :
| Exécution | Requêtes proposées/s | Requêtes terminées/s | Premier token p95 | File d'attente p95 | De bout en bout p95 | Taux d'erreur | Préemptions |
|---|---|---|---|---|---|---|---|
| Référence | mesuré | mesuré | mesuré | mesuré | mesuré | mesuré | mesuré |
| Modification du budget de tokens | mesuré | mesuré | mesuré | mesuré | mesuré | mesuré | mesuré |
| Modification de la limite de séquences | mesuré | mesuré | mesuré | mesuré | mesuré | mesuré | mesuré |
Remplissez ce tableau avec des mesures ; il n'existe pas de gain en pourcentage universel à copier depuis un autre modèle ou fournisseur. Choisissez la configuration qui atteint les objectifs de latence et de fiabilité au coût le plus faible par réponse acceptée, et non celle qui affiche isolément le débit de tokens le plus élevé.
Diagnostiquer un résultat décevant
Si le batching continu semble inefficace, recherchez la contrainte avant de modifier un autre paramètre.
Les requêtes en attente augmentent alors que la mémoire GPU reste largement disponible. Vérifiez les limites d'admission, un faible plafond de séquences, la tokenisation CPU et la concurrence côté client. Un ordonnanceur ne peut pas remplir un GPU avec des requêtes qui ne l'atteignent jamais.
Le délai jusqu'au premier token augmente pour les prompts longs. Séparez le trafic à forte charge de préremplissage du trafic à forte charge de décodage dans le benchmark. Examinez le préremplissage segmenté et les paramètres de budget de tokens, puis comparez la distribution des prompts longs plutôt que seulement la moyenne.
Le débit s'améliore, mais la latence p95 se dégrade. Le serveur accepte peut-être davantage de travail concurrent que ne le permet l'objectif de votre service interactif. Limitez l'admission, utilisez un délai d'expiration de file d'attente ou un pool de service distinct, puis testez de nouveau avec la même charge proposée.
Les préemptions ou les événements de mémoire insuffisante augmentent. Les contextes actifs peuvent ne pas tenir dans le cache KV du GPU. Réduisez les limites de concurrence ou de contexte, sélectionnez un GPU disposant de suffisamment de mémoire, ou revoyez les choix de modèle et de précision. Évitez de considérer une requête préemptée comme un événement d'ordonnancement gratuit.
L'utilisation du GPU est faible même lorsque des requêtes attendent. Inspectez le CPU, le réseau, le stockage, le chargement du modèle et le rythme du client avant d'attribuer le goulot d'étranglement au batching continu. Notre guide de déploiement de vLLM couvre le guide opérationnel de service plus général ; cet article se concentre sur le comportement de l'ordonnanceur et les mesures.
Comment le choix du GPU intervient dans la décision
Le batching continu peut améliorer votre utilisation d'un GPU, mais il ne peut pas faire tenir un modèle dans une mémoire dont il ne dispose pas. Estimez les poids, le cache KV selon la concurrence et la longueur de contexte attendues, la surcharge d'exécution et une marge de sécurité. Effectuez ensuite des benchmarks sur la configuration GPU que vous prévoyez de louer. Un GPU de 80 Go et un GPU doté de davantage de mémoire peuvent présenter un comportement d'admission et de préemption différent pour le même modèle et la même trace de requêtes.
Flatkey GPU Compute répertorie des options de location, notamment les H100 SXM, H200, B200, B300, A100 80GB et RTX 5090. La configuration, la région, la disponibilité et le prix doivent être confirmés pour la location sélectionnée. Apportez une trace de benchmark, la latence cible, la révision du modèle et l'estimation de mémoire lorsque vous comparez les options. Cela oriente la discussion sur la capacité vers le travail terminé plutôt que vers une spécification GPU mise en avant.
Liste de contrôle pratique pour la décision
Avant de valider une configuration de batching continu vLLM, répondez à ces questions :
- Le principal scénario de trafic respecte-t-il les objectifs de latence p95 du premier token et de bout en bout ?
- Que se passe-t-il lors d'un pic au-dessus du taux de requêtes normal : file d'attente bornée, rejet ou forte hausse de la latence ?
- Les préemptions et la pression sur le cache KV sont-elles stables à la longueur de contexte prévue ?
- Le résultat est-il reproductible avec la révision exacte du modèle et la configuration GPU que vous prévoyez d'utiliser ?
- Le coût par réponse acceptée est-il inférieur à celui de l'alternative après prise en compte des nouvelles tentatives et de la capacité inutilisée ?
Questions fréquemment posées
Le batching continu de vLLM signifie-t-il que chaque requête s'exécute immédiatement ?
Non. Une nouvelle arrivée peut être prise en compte lors d'une étape d'ordonnancement, mais elle peut tout de même attendre un budget de tokens, un emplacement de séquence ou une capacité de cache KV. Surveillez les jauges des requêtes en cours et en attente ainsi que les histogrammes de temps en file d'attente avant de promettre un objectif de latence interactive.
Le batching continu de vLLM est-il la même chose que le préremplissage segmenté ?
Non. Le batching continu décrit la manière dont les requêtes rejoignent et quittent le travail planifié au fil du temps. Le préremplissage segmenté divise le travail de préremplissage d'un prompt long afin qu'il puisse partager le budget de tokens entre les étapes. Ils fonctionnent ensemble dans l'ordonnanceur actuel, mais l'ajustement de l'un ne remplace pas la mesure de l'autre.
Dois-je maximiser la taille du batch ?
Pas automatiquement. Un batch plus grand peut améliorer le débit tout en augmentant le temps en file d'attente, le délai jusqu'au premier token ou la pression de préemption. Exécutez la même trace avec la même charge proposée et comparez l'ensemble de l'objectif de service, y compris les échecs et le coût par réponse acceptée.
Le batching continu de vLLM est une méthode d'ordonnancement, pas un résultat de benchmark. La meilleure configuration est celle dont vous pouvez expliquer le débit, la latence, le comportement mémoire et le mode de défaillance à l'aide de vos propres mesures.
