Le traitement par lots continu expliqué pour l'inférence LLM, expliqué

Le trafic réel est irrégulier : de nouvelles requêtes arrivent alors que d'autres sont en cours de génération. Avec un lot fixe, les requêtes terminées ne font pas place à de nouvelles requêtes avant la fin du lot. Le traitement par lots continu permet de modifier les requêtes actives entre les étapes de génération.

L'ordonnanceur peut admettre les requêtes en attente lorsque les ressources le permettent. Ce mécanisme est un ordonnancement au niveau de l'itération. Il ne consiste pas à recharger les poids du modèle à chaque jeton ou requête : dans un déploiement habituel où le modèle réside sur le GPU, ses poids restent chargés. Les gains dépendent du modèle, du matériel, du trafic et de la configuration ; aucun multiplicateur de débit universel ne peut être déduit sans benchmark comparable.

Préremplissage ou décodage

Le préremplissage traite les jetons de l’invite et construit leur cache clé-valeur. Le décodage utilise cet état pour générer les jetons suivants. L’invite constitue l’entrée du modèle, pas une séquence supplémentaire.

Le préremplissage traite de nombreux jetons en parallèle ; un moteur peut aussi découper une longue invite en segments. Le décodage avance ensuite étape par étape. Le préremplissage est souvent limité par le calcul et le décodage avec de petits lots par la bande passante mémoire. La documentation de vLLM décrit ces profils ; le goulot d’étranglement reste à mesurer sur la configuration utilisée.

Le traitement par lots continu relève de l’ordonnancement du moteur de service et ne nécessite pas de réentraîner le modèle. PagedAttention traite un autre problème : organiser le cache KV en blocs qui n’ont pas besoin d’être contigus. Les deux techniques peuvent être combinées, mais elles ne sont pas synonymes.

Évaluer Compute pour votre charge de travail

Vérifiez le matériel, les régions, les tarifs et les prérequis de déploiement actuels avant de choisir une instance.

Ouvrir la console Compute

Comment fonctionne le traitement par lots en continu

• Admettre des requêtes entre les itérations. L’ordonnanceur ajoute des requêtes en attente lorsque les budgets de jetons, de requêtes et de mémoire le permettent, sans attendre la fin de tout le lot.
• Gérer les blocs du cache KV. Chaque requête a besoin de l’état correspondant à sa séquence de jetons. La mémoire peut être réutilisée après la fin des requêtes. La réutilisation d’un préfixe commun est une optimisation distincte ; la documentation de vLLM sur le cache de préfixes décrit aussi des mécanismes d’isolation pour les environnements partagés.
• Grandissez et rétrécissez à la volée. Au fur et à mesure que les demandes se terminent ou sont annulées, la taille du lot actif change sans forcer le redémarrage. Cette approche dynamique optimise l'utilisation de la mémoire et la bande passante de la mémoire en allouant les ressources selon les besoins.
• Diffuser les résultats lorsque le streaming est activé. Une API peut envoyer les jetons générés pendant que l’ordonnanceur traite d’autres requêtes. Le streaming concerne leur livraison au client ; le traitement par lots continu concerne l’exécution du modèle.

Le regroupement peut augmenter le débit total, sans réduire la latence de chaque requête. Comparez le temps d’attente et la latence de livraison des jetons sous une même charge. Un gain à tous les percentiles ne doit pas être supposé.

Effets sur le TTFT et le TPS

• Moins d’attente liée aux lots fixes. Une requête peut rejoindre le travail actif lorsqu’une place se libère. Le délai jusqu’au premier jeton (TTFT) dépend aussi de la file d’attente et du préremplissage.
• Débit total potentiellement plus élevé. Remplacer les requêtes terminées peut augmenter les jetons en sortie par seconde (TPS) à l’échelle du serveur. Mesurez séparément la latence de chaque requête.
• Une surcharge reste possible. Le traitement par lots continu ne supprime pas une demande durablement supérieure à la capacité. Définissez des limites de file d’attente et des délais d’expiration, puis testez au-delà du pic prévu.

Limites et compromis

• Pression mémoire. Les poids, les espaces de travail du moteur et le cache KV partagent la mémoire GPU. De longs contextes et de nombreuses requêtes actives augmentent les besoins. Un manque de marge peut provoquer des préemptions, des recalculs ou des erreurs de mémoire insuffisante.
• Équité et vitesse. Un regroupement agressif peut retarder certaines requêtes, notamment celles qui ont de longues invites. Définissez des règles de priorité et d’équité, ainsi que des limites de contexte et de sortie adaptées.
• Variation de la latence entre jetons. Des requêtes de longueurs différentes peuvent modifier le rythme de livraison. Mesurez cette variation sous charge ; ne supposez pas qu’elle sera toujours faible ou compatible avec des contraintes de temps réel strictes.

Liste de contrôle de réglage

Cette section décrit les principales étapes à suivre pour créer une configuration de traitement par lots efficace pour vos modèles.

Commencez par les valeurs par défaut, puis modifiez une chose à la fois :

1. Plafonnez max_tokens. Choisissez une limite de sortie utile et testez son effet. Un plafond élevé autorise une longue génération, mais ne signifie pas que tout le cache maximal est nécessairement réservé à l’avance.
2. Définissez une longueur de contexte raisonnable. Utilisez RAG pour raccourcir les instructions lorsque vous le pouvez.
3. Choisissez des limites de lots. Prévoyez suffisamment d'emplacements de décodage parallèles pour occuper le GPU, mais évitez tout crash.
4. Dimensionnez le matériel à partir des mesures. Examinez la file d’attente, l’occupation du cache, les préemptions et la mémoire avant de changer de GPU ou de modèle. Un faible taux de réutilisation des préfixes peut simplement indiquer que les invites ont peu de texte en commun.
5. Activez le streaming lorsqu’il est utile. Il peut rendre la progression visible plus tôt, mais ne réduit pas à lui seul le calcul du modèle ni la longueur de la file d’attente.
6. Utilisez de courtes instructions système. Moins de jetons en entrée signifie moins de jetons à mettre en cache.

Tests à exécuter

Pour une validation complète, il est recommandé d'exécuter ces tests sur plusieurs itérations, en utilisant différentes itérations et plusieurs itérations pour couvrir une gamme de scénarios. Par exemple, vous pouvez faire varier la longueur des invites ou les niveaux de simultanéité à chaque exécution pour observer le comportement du système.

• Montée en charge. Augmentez la concurrence étape par étape et observez le TTFT et le TPS.
• Invites de longueurs variées. Combinez des invites courtes et longues pour observer le comportement de l’ordonnanceur.
• Annulations en rafale. Lancez plusieurs annulations pour vérifier la libération des ressources et la réutilisation du cache.
• Limites de jetons. Vérifiez que les plafonds sont respectés et que les erreurs sont compréhensibles.
• Redémarrage et reprise. Redémarrez le serveur ou rechargez un modèle si le moteur le permet, puis vérifiez la reprise. Un redémarrage ne prouve pas la prise en charge d’un rechargement à chaud.

Une instrumentation rentable

Suivez-les au minimum :

• TTFT et latence entre jetons aux percentiles p50/p95, plus TPS total en sortie sous charge
• Taille du lot actif et longueur de la file d'attente
• Mémoire GPU, occupation du cache KV et préemptions ; taux de réutilisation du cache de préfixes si cette fonction est activée
• Codes d'erreur : OOM, timeouts, 5xx
• Nombre de jetons d’entrée et de sortie par requête ; évitez de conserver les invites et réponses brutes sans besoin justifié

Récapitulation

Le traitement par lots continu peut aider à utiliser les GPU lorsque le trafic est irrégulier. Commencez par des limites prudentes, mesurez le TTFT et le TPS, puis ajustez les limites de lots à partir des résultats.

Préparer un déploiement autogéré
Le guide de déploiement de vLLM sur Compute (en anglais) fournit une référence, sans confirmer la disponibilité actuelle de son image ou de sa configuration. Vérifiez la documentation Compute actuelle et le matériel disponible, puis configurez l’authentification et TLS pour votre point de terminaison.

FAQ

Qu'est-ce que le préremplissage et le décodage ?

Le préremplissage traite les jetons de l’invite et construit l’état d’attention en cache, éventuellement par segments. Le décodage utilise ensuite cet état pour générer des jetons.

Quelle doit être la taille d'un lot ?

Suffisamment grand pour occuper le GPU pendant le décodage sans provoquer de saturation du cache. Testez avec vos vraies instructions et plafonnez le nombre maximum de jetons.

Pourquoi le TTFT s'aggrave-t-il à charge élevée ?

Sous forte charge, la file d’attente et le préremplissage peuvent dominer. Examinez la longueur des invites, la concurrence, les préemptions et les paramètres d’ordonnancement ; le taux de réussite du cache ne suffit pas à diagnostiquer la cause.

Le traitement par lots continu fonctionne-t-il avec le streaming ?

Oui, si le serveur et le client prennent en charge le streaming. Les jetons peuvent être transmis pendant que l’ordonnanceur traite d’autres requêtes. Vérifiez les réglages plutôt que de supposer que le streaming est activé par défaut.

Faut-il plusieurs GPU pour en bénéficier ?

Non. Le traitement par lots continu peut être utile sur un seul GPU lorsque plusieurs requêtes sont actives. Plusieurs GPU peuvent répondre à un besoin de capacité ou de débit, mais leur intérêt doit être mesuré.

Combien de mots font 1 000 jetons ?

Le rapport dépend de la langue, du texte et du tokenizer. Pour dimensionner une requête, comptez les jetons avec le tokenizer du modèle utilisé plutôt que d’appliquer un nombre fixe de mots par jeton.

Que signifie un jeton dans l'IA ?

Un jeton est une unité de texte utilisée dans le traitement du langage naturel, souvent un mot ou un sous-mot que le modèle traite lors de l'inférence ou de la formation.

Qu'est-ce que le TTFT ?

TTFT signifie « time to first token », ou délai jusqu’au premier jeton. Du point de vue du client, il va de l’envoi de la requête à la réception du premier jeton de sortie. Une mesure côté serveur utilise une autre frontière.

Comment mesurer le TTFT ?

Pour une requête en streaming, mesurez le temps entre son envoi et la première réponse non vide contenant un jeton. Documentez la frontière de mesure et conservez-la pour tous les tests. Les définitions de métriques de NVIDIA distinguent le TTFT, la latence de bout en bout et la latence entre jetons.

Qu'est-ce que la métrique TPOT ?

TPOT signifie time per output token, ou temps par jeton de sortie. C’est une mesure de latence, souvent en millisecondes par jeton. Un calcul courant exclut le premier jeton : (latence totale − TTFT) / (nombre de jetons en sortie − 1), pour une réponse de plus d’un jeton. Vérifiez la définition de l’outil utilisé.

Que signifie TPS pour un LLM ?

TPS signifie jetons par seconde. Précisez s’il s’agit d’une seule réponse ou du débit total de plusieurs requêtes concurrentes ; ces mesures peuvent évoluer différemment lorsque la charge augmente.

Qu'est-ce qu'un cache KV ?

Le cache KV fait référence au cache clé-valeur qui stocke les tenseurs de clé et de valeur intermédiaires calculés pendant le mécanisme d'attention afin d'accélérer la génération ultérieure de jetons.

Qu'est-ce que le cache GPU KV ?

Le cache GPU KV est le stockage de paires clé-valeur dans la mémoire GPU utilisées lors de l'inférence de modèles pour optimiser les calculs d'attention et réduire les calculs redondants.

Qu'est-ce que le cache KV dans LLM ?

Dans les grands modèles de langage, le cache KV contient les vecteurs de clé et de valeur mis en cache des jetons précédents afin de calculer efficacement l'attention portée aux nouveaux jetons sans recalculer les états antérieurs.

Qu'est-ce que le cache de stockage clé-valeur ?

Un stockage clé-valeur associe des valeurs à des clés pour les retrouver. Le cache KV d’un LLM conserve des tenseurs d’attention liés aux positions des jetons. L’abréviation commune ne désigne pas le même mécanisme.

Comment fonctionne le traitement par lots dynamique ?

Le traitement par lots dynamique regroupe des requêtes compatibles avant leur exécution, avec un délai de collecte facultatif. Le batcher dynamique de Triton vise les modèles sans état. Le traitement par lots continu des LLM peut, lui, modifier les requêtes actives entre les itérations de génération.

Quelle est la différence entre le traitement par lots statique et le traitement par lots dynamique ?

Un lot statique conserve sa composition pour une exécution. Un lot dynamique est formé à partir des requêtes en attente selon des limites configurées et, éventuellement, un délai de collecte. Le traitement par lots continu ajoute la possibilité de modifier les requêtes actives entre les itérations. Un lot statique n’exige pas intrinsèquement d’attendre d’être complètement rempli.

‍