TAO accélère les agents IA : premier jeton jusqu'à 36% plus rapide, tâches jusqu'à 27%

Quand un agent IA corrige un bug dans un dépôt de code, il ne fait pas que réfléchir. Le modèle émet une commande ; un compilateur, des tests ou un moteur de recherche l'exécutent sur des processeurs distincts ; le résultat retourne au modèle, et ainsi de suite des dizaines de fois. Les chercheurs de l'université Jiao Tong de Shanghai appellent cette architecture CGDC : un cluster GPU pour l'inférence, plus des CPU dispersés sur le réseau pour les outils.

Ils proposent l'ordonnanceur TAO, qui décide quels agents faire passer sur GPU et sur quel nœud précisément, en tenant compte du moment où la réponse de l'outil reviendra pour chaque agent. Par rapport au meilleur concurrent sur chaque métrique, TAO réduit la latence d'exécution des tâches jusqu'à 26,8% et le temps moyen avant le premier jeton après la reprise d'une session (TTFT) jusqu'à 36,3%, tout en augmentant la vitesse de génération (jetons par seconde) jusqu'à 29,5%.

Pourquoi le GPU et le cache souffrent pendant que l'agent attend un outil

Tant que l'outil travaille, l'agent n'a pas besoin du GPU. On peut suspendre la session et libérer la place pour d'autres. Mais cette pause a un coût. Le modèle conserve en mémoire un KV-cache : la représentation déjà calculée de l'historique de la conversation. Si la session reprend vite sur le même nœud, le préfixe est réutilisé et il n'est pas nécessaire de retraiter tout le contexte. Si elle tarde, le cache est évincé et le recalcul consomme de la capacité.

Les auteurs l'ont montré sur des traces de DeepSeek-V4 Flash issues de deux nœuds H100 : la part de cache conservée chute nettement avec l'âge de l'observation, la courbe couvrant un intervalle allant jusqu'à 1 800 secondes.

Selon les auteurs, les systèmes existants commettent deux erreurs :

• Ils n'utilisent la durée d'exécution de l'outil que comme signal indirect pour la conservation du cache ou le décompte des jetons, et non comme indicateur à part entière de la disponibilité d'une session.
• Ils évaluent chaque session séparément, avec des heuristiques. Or les sessions se disputent la même capacité, et le choix glouton de l'une peut écarter une combinaison d'autres sessions plus avantageuse.

Trois valeurs dans un ordre strict et un problème de sacs à dos

Pour chaque paire « session en attente — nœud », TAO calcule un triplet de valeurs comparées dans l'ordre, comme des mots dans un dictionnaire :

• Crédit de cache. Nombre de jetons de cette session qui se trouvent, d'après les observations, sur ce nœud. Les anciennes observations s'érodent de façon exponentielle, avec une demi-vie fixée. Si l'on n'a aucune donnée sur le nœud, le crédit est nul.
• Disponibilité au retour. Indicateur binaire : l'outil reviendra-t-il dans la prochaine fenêtre de planification ? La prédiction s'appuie sur les indices fournis par les outils eux-mêmes (Claude Code dispose d'un Monitor, OpenCode d'un message de timeout de Bash), sur les commandes sleep analysées et sur l'historique des durées. En l'absence de toute information, la valeur par défaut est de cinq secondes. Les prévisions dépassées reçoivent des chances d'essai temporaires, afin qu'une session ne reste pas « prête » indéfiniment.
• Nombre de jetons. En cas d'égalité sur les deux premières valeurs, la préférence va aux contextes longs.

L'ordre est figé, tandis que les valeurs évoluent avec le temps. Il n'y a donc pas besoin de pondérations manuelles dans une somme.

Un algorithme exact de programmation dynamique prend ensuite le relais. Le problème ressemble aux classiques « sacs à dos multiples » : chaque nœud dispose d'une capacité résiduelle, chaque session a un coût d'admission, et il faut obtenir la valeur totale maximale. La solution est exacte pour un instantané figé de l'état, même si l'arrondi de la capacité peut exclure des plans qui étaient admissibles avant arrondi. L'ordonnanceur tourne dans un processus asynchrone distinct et vérifie le plan par rapport à l'état en direct avant de l'appliquer. D'après les auteurs, la préparation et le calcul prennent moins de 0,12% du temps d'exécution dans le test à quatre répliques.

Ce que montrent les mesures sur H100

Trois modèles ont été testés : DeepSeek-V4 Flash sur deux nœuds H100, Qwen3-32B sur quatre et GLM-4.7 sur un. Les charges de travail sont les suivantes : SWE-bench Lite (correction de bugs réels) via mini-SWE-agent, Terminal-Bench 2.0 avec Claude Code pour des tâches de terminal complexes, et SWE-verified pour Qwen sous forte concurrence. Chaque nœud héberge une réplique du modèle.

La comparaison porte sur quatre approches : l'ordonnanceur de vLLM avec distribution circulaire (round-robin), le même avec prise en compte du cache, Dynamo de NVIDIA (qui tient compte du KV) et ThunderAgent (selon le nombre de jetons et un empaquetage « par ordre décroissant »).

Sur SWE-bench Lite, par rapport au meilleur concurrent dans chaque colonne :

• la latence des tâches est inférieure de 2,4 à 26,8% ;
• le TTFT est inférieur de 7,4 à 36,3% ;
• la vitesse de génération est supérieure de 5,1 à 29,5%.

Sur Terminal-Bench, TAO est en tête pour la latence et le TTFT aux trois niveaux de concurrence. Sur Qwen3-32B, il affiche le TTFT le plus bas pour les trois nombres de sessions parallèles. Les maximums sont pris sur 12 configurations « modèle — charge — concurrence » : pour chaque combinaison prise isolément, le gain est donc plus modeste.

Ce que les ingénieurs peuvent en retenir

La principale conclusion pour ceux qui gèrent eux-mêmes l'inférence de leurs agents : il faut traiter la durée d'exécution des outils comme une donnée d'ordonnancement. Si vous mesurez déjà la durée des appels, une partie de cette information peut devenir une priorité d'accès au GPU et un critère de placement.

Les auteurs affirment que l'approche se transpose aux architectures multi-agents, aux agents cycliques et aux charges de chat classiques. Il s'agit de leur affirmation, et le document ne permet pas de savoir si des mesures distinctes la confirment. Tous les chiffres proviennent de H100 et de combinaisons précises de modèles ; sur un autre matériel et avec un autre profil d'outils, le résultat peut différer.