Comment le traitement par lots continu affecte-t-il l’équité sur un serveur d’IA domestique ?
Le batching continu améliore l’utilisation des ressources en remplissant à nouveau les lots actifs, mais l’équité dépend de la manière dont les utilisateurs obtiennent l’admission, du temps de traitement des tokens et de la mémoire au fil du temps.
Un serveur IA domestique peut gérer plusieurs conversations sans attendre que chaque séquence se termine en même temps. Les requêtes terminées quittent le système, de nouvelles requêtes y entrent et les utilisateurs actifs se partagent des itérations d’inférence répétées. Cela augmente le débit, mais les requêtes ne sont pas équivalentes : un utilisateur peut envoyer une commande courte, un autre un long document et un autre encore un agent qui génère des centaines de tokens. Un ordonnanceur équitable doit déterminer quelle unité de travail compte, comment les nouvelles requêtes sont admises et comment les priorités interagissent avec des longueurs de sortie imprévisibles.
Le batching continu fait passer l’unité d’ordonnancement d’un lot fixe aux itérations
Le batching statique conserve un même groupe jusqu’à ce qu’il soit entièrement terminé, ce qui gaspille de la capacité lorsque les requêtes courtes finissent plus tôt. Le batching continu peut remplir à nouveau les emplacements disponibles entre les itérations de génération.
Orca a introduit la planification au niveau des itérations, afin que les requêtes puissent entrer et sortir à mesure que leur état de séquence évolue.
Cela améliore l’utilisation des ressources, mais signifie également que les utilisateurs se disputent régulièrement une place dans l’itération suivante, au lieu de recevoir un emplacement de requête indivisible.
L’ordre d’admission détermine qui commence à accumuler du temps de service
Une requête en dehors du lot actif ne bénéficie d’aucune progression du modèle. L’ordonnanceur peut admettre les requêtes selon leur heure d’arrivée, leur longueur estimée, leur priorité, le nombre de blocs KV disponibles ou un compteur d’équité.
vLLM associe une admission continue à une gestion paginée du cache KV, afin que la mémoire puisse être allouée à mesure que les séquences grandissent.
Le principe du premier arrivé, premier servi est simple, mais une file composée de longues requêtes peut retarder les commandes domestiques courtes arrivées ensuite, même si celles-ci pourraient se terminer rapidement.
Compter les requêtes de manière égale peut produire un service inégal de l’accélérateur
Une réponse de cinq tokens et une réponse de cinq cents tokens correspondent toutes deux à une requête, mais elles occupent un nombre d’itérations de décodage très différent. La longueur des prompts entraîne également des volumes différents de traitement de préremplissage.
Virtual Token Counter définit une équité fondée sur les tokens, car le simple nombre de requêtes ne représente pas le service consommé par des charges de travail LLM hétérogènes.
Une politique domestique doit déterminer si l’équité signifie un volume de tokens identique, un temps d’attente identique, une possibilité d’achèvement équivalente ou une priorité accordée aux tâches sensibles à la latence.
Aucune métrique unique ne convient à toutes les charges de travail. Une commande vocale et un résumé en arrière-plan ne devraient pas nécessairement recevoir exactement le même traitement.
Une longueur de sortie inconnue rend le service futur difficile à prévoir
L’ordonnanceur connaît la taille du prompt lors de l’admission, mais ne sait généralement pas exactement combien de tokens de sortie le modèle va générer. Une requête peut rester active bien plus longtemps que prévu.
Les recherches sur l’équité mettent en évidence les longueurs de requêtes imprévisibles comme un défi particulier du service des LLM.
Facturer le service au fur et à mesure du traitement réel des tokens évite de dépendre entièrement d’une estimation de longueur peu fiable, mais cela peut tout de même permettre à une longue requête d’occuper la mémoire pendant de nombreuses itérations.
Les préremplissages volumineux peuvent perturber les utilisateurs qui reçoivent déjà des tokens
Un nouveau prompt contenant un document peut arriver alors que plusieurs utilisateurs sont en cours de décodage. Son préremplissage, très exigeant en calcul, peut allonger l’itération que les conversations actives doivent attendre.
Sarathi-Serve utilise une planification sans blocage pour fractionner les préremplissages volumineux et réduire leur effet sur la latence de décodage en cours.
Un ordonnanceur qui ne comptabilise que les tokens de décodage peut tout de même être injuste si un utilisateur introduit régulièrement de grands préremplissages qui retardent la sortie en flux de tous les autres.
Une comptabilisation équitable devrait donc inclure le traitement des entrées ainsi que les tokens générés.
La pression sur la mémoire peut créer des problèmes d’équité avant la saturation des ressources de calcul
Chaque conversation active a besoin d’un cache KV, et les contextes plus longs consomment davantage de blocs. Un utilisateur disposant d’un seul contexte volumineux peut réduire le nombre d’autres requêtes pouvant tenir dans le lot actif.
L’analyse multi-utilisateur de ZimaSpace relie la concurrence domestique à la mémoire partagée des modèles et aux décisions de l’ordonnanceur.
Préempter ou permuter une requête peut rétablir la capacité disponible, mais l’utilisateur interrompu peut ensuite subir un recalcul, un rechargement du cache ou un délai d’achèvement plus long.
L’admission en mémoire et l’ordonnancement du calcul doivent donc suivre la même politique d’équité, au lieu de fonctionner comme des limites indépendantes.
Les priorités ont besoin d’un vieillissement, de quotas et de mesures visibles par les utilisateurs
Le contrôle vocal, les outils d’accessibilité et les conversations interactives courtes peuvent mériter une priorité supérieure à celle des embeddings ou des résumés nocturnes. Toutefois, un ordonnancement fondé uniquement sur les priorités peut affamer les tâches à faible priorité.
Llumnix utilise une planification dynamique pour adapter le placement des requêtes et les décisions d’allocation des ressources à mesure que les conditions de service évoluent.
Ajoutez un vieillissement des requêtes, des quotas par utilisateur, des limites maximales de contexte ou de sortie, ainsi qu’une part réservée à l’arrière-plan, afin que les tâches prioritaires réagissent rapidement sans bloquer indéfiniment toutes les autres.
Mesurez le temps d’attente dans la file, le délai avant le premier token, le délai entre les tokens, le temps d’achèvement, le nombre de tokens servis et les préemptions par utilisateur ou par catégorie de charge de travail. Le batching continu n’est équitable que lorsque la répartition observée correspond à la politique domestique, et pas simplement lorsque le nombre total de tokens par seconde est élevé.
Produits recommandés
Centre Tech & IA
Plus à lire
Quelles fonctionnalités permettent de créer une frontière de confiance pour l’IA domestique autour des fichiers sensibles ?
Une frontière de confiance pour l’IA à domicile combine le chiffrement des données au repos, des autorisations selon le principe du moindre privilège, un...
Pourquoi les résultats de recherche privés privilégient-ils les fichiers fréquemment modifiés ?
Les fichiers fréquemment modifiés bénéficient d’un meilleur classement lorsque chaque mise à jour ajoute des signaux de fraîcheur, des segments, des versions ou des...
Qu’est-ce qui pousse les modèles de détection de présence pour maison intelligente à confondre les invités avec les résidents ?
Les invités peuvent être pris pour des résidents lorsque le système observe des habitudes d’activité du foyer, mais ne dispose d’aucun signal d’identité stable...
