Chiosa
FR
Systems & Infrastructure

Un planificateur utilise le calendrier des outils pour placer les sessions d’IA en attente

TAO: Tool-Aware Joint Scheduling for LLM-Based Agentic Serving · arXiv:2610.37230

4 min
Mis à jour
The TAO evaluate-then-decide framework in CGDC. External tools on distributed CPUs provide historical tool-call durations, while the serving engines on clustered GPUs provide cache observations.…
The TAO evaluate-then-decide framework in CGDC. External tools on distributed CPUs provide historical tool-call durations, while the serving engines on clustered GPUs provide cache observations. Then, the session evaluation component constructs triplets (decayed KV-cache…Figure 2 · TAO: Tool-Aware Joint Scheduling for LLM-Based Agentic Serving · Shuhuai Li et al. · CC BY 4.0

En termes simples

Les agents d’IA alternent entre les demandes adressées à un modèle de langage et l’attente de résultats fournis par des outils externes, comme un compilateur. Pendant qu’un agent attend, le GPU peut servir une autre session.

L’article présente TAO, un planificateur qui tient compte du moment où les outils pourraient répondre, des données de conversation réutilisables et de la taille des sessions pour choisir quelles sessions en attente utilisent quels GPU.

Dans 12 configurations rapportées de modèles, de charges de travail et de niveaux de concurrence, la réduction maximale de la durée moyenne des tâches avec TAO était de 26.8% par rapport au meilleur planificateur évalué pour cette mesure.

Cette durée comprend l’exécution des outils, et le gain maximal n’a pas été observé dans toutes les configurations.

La recherche

Quand un agent d’IA attend un outil externe, la capacité GPU qu’il utilisait peut être disponible pour une autre session. Mais le planificateur doit aussi tenir compte du moment où la session en attente reprendra.

Comment choisir entre les sessions qui se disputent les mêmes nœuds GPU, tout en préservant les données de cache utiles et en servant celles qui devraient bientôt avoir besoin du modèle ?

TAO combine le calendrier de retour des outils, la réutilisation du cache et la taille des sessions pour choisir et placer les sessions d’agents en attente, dans les limites de capacité des GPU.

TAO compare son planificateur aux solutions évaluées dans 12 configurations de modèles, de charges de travail et de niveaux de concurrence. Les plus fortes réductions rapportées atteignent 26.8% pour la latence moyenne des tâches et 36.3% pour le délai moyen avant le premier token ; le débit de décodage augmente jusqu’à 29.5%.

La latence des tâches comprend l’exécution des outils, et chaque maximum est calculé par rapport au meilleur système de référence évalué pour la mesure et la configuration concernées.

Ces résultats étayent l’idée que TAO peut améliorer les performances de service dans les conditions testées, mais les gains ne sont pas uniformes. À 128 workers avec Qwen3-32B et SWE-verified, sa latence moyenne des tâches était 2.5% plus élevée que celle de ThunderAgent.

Les gains rapportés correspondent aux meilleures améliorations observées parmi 12 combinaisons de modèles, de charges de travail et de niveaux de concurrence ; ils ne valent pas pour chaque configuration. La borne calculée par l’article pour les plans appliqués après une capture d’état concerne la valeur de la planification dans les conditions indiquées.

Elle ne borne ni la latence des tâches ni l’écart avec un planificateur en ligne globalement optimal.

Ce que montrent les preuves

  • La question de la planification

    TAO est un cadre de planification conjoint qui tient compte des outils pour servir des agents utilisant des modèles de langage. Les sessions d’agents alternent entre des requêtes adressées à un modèle sur des GPU regroupés en grappes et des appels à des outils externes exécutés sur des CPU répartis.

    Quand un outil fonctionne, sa session n’a pas besoin d’inférence sur GPU ; le planificateur peut donc attribuer cette capacité à une autre session. La question est de savoir comment estimer le retour probable de la session en attente tout en choisissant entre plusieurs sessions qui se disputent les mêmes nœuds.

  • Pourquoi choisir les sessions ensemble

    Les planificateurs existants peuvent négliger le moment où les outils renverront leur résultat et prendre des décisions d’admission et de placement à partir d’heuristiques appliquées session par session. Or les sessions se partagent la capacité des nœuds : en choisir une peut empêcher une combinaison plus utile d’autres sessions.

    TAO attribue une valeur à chaque paire admissible session-nœud, en fonction du crédit du cache, de la probabilité d’un retour d’outil à court terme et du nombre de tokens, dans cet ordre de priorité. Il choisit ensuite les affectations conjointement, dans les limites de capacité des nœuds.

  • Ce que montrent les résultats principaux

    L’article compare TAO aux planificateurs évalués dans 12 configurations de modèles, de charges de travail et de niveaux de concurrence. Il rapporte des améliorations relatives maximales de 26.8% pour la latence moyenne de bout en bout des tâches, de 36.3% pour le délai moyen avant le premier token et de 29.5% pour le débit de décodage.

    La latence des tâches comprend l’inférence du modèle et l’exécution des outils ; le débit correspond au nombre de tokens de sortie par seconde. Chaque maximum est calculé par rapport au meilleur système de référence évalué pour cette mesure et cette configuration, qui peut varier.

  • Une configuration avec une latence plus élevée

    Les maxima ne correspondent pas à des gains dans toutes les configurations. Dans une comparaison rapportée, avec Qwen3-32B sur SWE-verified à 128 workers, la latence moyenne des tâches avec TAO était 2.5% plus élevée qu’avec ThunderAgent.

    Cette exception précise la portée des résultats mis en avant : l’article rapporte les meilleurs gains relatifs parmi plusieurs configurations, et non une réduction garantie de la latence dans chacune d’elles.

  • Ce qu’apporte le test des composants

    Une comparaison distincte des composants a utilisé DeepSeek-V4 Flash sur SWE-Lite à 32 workers, répartis sur deux nœuds. TAO complet a produit 1,417.97 tokens de sortie par seconde ; les variantes qui supprimaient la valeur du cache ou le signal de disponibilité, modifiaient l’ordre de mise en pause ou remplaçaient la reprise conjointe ont obtenu un débit inférieur.

    Dans cette configuration, la comparaison étaye l’idée que l’évaluation des sessions et les décisions de reprise contribuent au résultat. Comme elle porte sur une seule configuration, elle ne permet pas de généraliser ces effets des composants.

Détails

Article suivantKVStream exploite le stockage disponible pour accélérer le service des modèles à long contexte