Traitement par lots continu ou statique : comment fonctionne l’ordonnancement des LLM
Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
Le traitement par lots statique regroupe des requêtes pour une exécution d’inférence. Le traitement par lots continu actualise l’ensemble des requêtes actives entre les itérations de génération : les requêtes terminées sortent et les requêtes en attente admissibles entrent. Le serveur peut ainsi réutiliser la capacité sans attendre que toutes les requêtes initiales soient terminées.
Pour les ingénieurs chargés du serving, le gain dépend de la variabilité des longueurs de réponse, de la politique d’ordonnancement, de la capacité mémoire et des exigences de latence.
Comparer des longueurs de sortie inégales
Supposons que trois requêtes nécessitent 10, 40 et 100 tokens de sortie. Dans une boucle de génération simple à lot fixe qui ne remplace pas les requêtes terminées, la capacité occupée par les deux premières se libère avant la fin de la troisième. Le serveur attend malgré tout la réponse la plus longue du lot avant de commencer un nouveau lot complet.
Un ordonnanceur par itération peut retirer chaque requête terminée et en admettre une autre. Orca a présenté une architecture de serving de LLM utilisant cette approche d’ordonnancement. L’admission nécessite toujours des blocs libres de KV cache et un budget d’itération compatible. Le traitement par lots continu ne signifie pas que toutes les requêtes en file d’attente démarrent immédiatement.
Les nouveaux prompts nécessitent aussi un prefill. Un prefill découpé en segments peut partager les budgets d’itération avec les décodages en cours. Les règles d’admission et de priorité de l’ordonnanceur affectent donc à la fois le délai jusqu’au premier token et les intervalles entre les tokens suivants.
Comparer l’ordonnanceur et le runtime complet
L’expérience d’Anyscale de 2023 a rapporté environ 4x pour FasterTransformer, 8x pour ses configurations de traitement par lots continu et 23x pour vLLM par rapport à son implémentation de référence naïve. Elle utilisait OPT-13B, une A100-40GB, 1,000 requêtes, des entrées de 512 tokens et une distribution exponentielle des longueurs de sortie avec une moyenne de 128 tokens. Ces résultats concernent des implémentations complètes dans cette configuration, plutôt que l’effet isolé d’un seul changement d’ordonnancement.
Pour votre comparaison, consignez :
| Point à vérifier | Pourquoi il compte |
|---|---|
| Distributions des arrivées de requêtes et des longueurs de sortie | Déterminent la capacité inutilisée et la pression sur la file d’attente |
| Nombre maximal de séquences actives et budget de tokens | Limitent le travail de chaque itération |
| Allocation KV et préemption | Peuvent empêcher de nouvelles admissions |
| TTFT et latence de génération par requête | Révèlent le coût pour chaque requête |
| Taux de réussite et goodput | Indiquent si le travail supplémentaire respecte l’objectif de service |
Examinez séparément les requêtes courtes et longues. Un débit total plus élevé peut s’accompagner d’une latence accrue pour un groupe de requêtes. Choisissez les paramètres d’ordonnancement à partir des exigences de service mesurées.
Guide d’ingénierie : traitement par lots continu explique ensemble les mécanismes d’allocation et d’ordonnancement.