Résumé Technique : Une Couche d'Exécution Pilotée par des Politiques pour le Service de LLMs Agents

1. Énoncé du Problème

Les systèmes multi-agents de modèles de langage à grande échelle (LLM) sont devenus la charge de travail de production dominante, pourtant la pile de service existante est architecturalement inadaptée à leurs exigences. Les systèmes actuels fonctionnent sur une structure à deux niveaux :

1. Cadre d'Agent (Haut) : Des systèmes comme AutoGen, LangGraph ou MetaGPT qui gèrent les identités des agents, les schémas de rôle et la logique de dispatch. Ils émettent des appels API LLM mais restent aveugles aux événements au niveau du moteur (par exemple, la génération de tokens, l'état du cache KV).
2. Moteur de Service (Bas) : Des moteurs comme vLLM ou SGLang qui gèrent le préremplissage, le regroupement (batching) et la génération de tokens. Ils observent chaque événement mais ne possèdent aucune connaissance des identités des agents ou de la structure sémantique du flux de travail multi-agent.

Cette « couture » crée un fossé critique pour les politiques transversales. De nombreuses stratégies d'optimisation — telles que l'éviction du cache KV, la mise en forme des lots (batch shaping), l'exécution spéculative, l'équité et l'application des règles de sécurité — nécessitent un accès simultané aux métadonnées d'identité des agents (provenant du cadre) et aux événements au niveau du moteur (provenant du moteur de service). Actuellement, ces politiques sont implémentées sous forme de « correctifs ponctuels » soit dans le cadre, soit dans le moteur. Cette approche est fragile, non modulaire et échoue à exploiter le contexte complet requis pour une prise de décision optimale.

2. Méthodologie : La Couche d'Exécution de l'Agent

Les auteurs proposent une intervention architecturale : insérer un troisième niveau, la Couche d'Exécution de l'Agent, entre le cadre et le moteur de service. Cette couche agit comme un substrat qui possède les métadonnées transversales des agents et expose une interface stable, agnostique des politiques.

Les Quatre Primitives

La couche définit quatre primitives génériques par lesquelles n'importe quelle politique consciente des agents peut se brancher. Ces primitives forment une boucle de rétroaction observer → évaluer → prédire → agir, unifiée par l'identité de l'agent comme coordonnée partagée :

1. observe(event) : Le runtime reçoit des événements pertinents pour la politique de ses voisins (par exemple, accès aux blocs, arrivées de requêtes, retours d'outils). Il met à jour un état interne étiqueté par l'identité de l'agent.
2. score(item) : Le runtime renvoie une priorité par élément utilisée par un voisin pour classer les décisions (par exemple, quel bloc KV évicter, quelle requête admettre).
3. predict(horizon) : Le runtime renvoie une prévision probabiliste de l'activité future de l'agent (par exemple, le prochain rôle d'agent, le prochain appel d'outil).
4. act(side_effect) : Le runtime émet des effets secondaires hors du chemin critique vers un voisin (par exemple, préchauffer un cache, précharger des poids, couvrir un appel spéculatif). C'est la seule primitive qui modifie l'état du voisin.

Étude de Cas : CacheSage

Pour valider cette abstraction, les auteurs instancient la couche pour le cache KV, la politique ayant l'impact immédiat le plus important sur les coûts de service. Ils introduisent CacheSage, qui résout le problème des caches de préfixe réactifs qui abandonnent les « ancres d'agent » (prompts système et définitions d'outils) avant l'arrivée de la prochaine session.

CacheSage implémente les quatre primitives via trois composants :

• Apprenant de Transition (observe) : Maintient une fenêtre glissante de comptes de transitions d'agents par paires ($n(a', a)$) pour calculer en ligne une matrice de transition de Markov du premier ordre. Il identifie l'« ancre d'agent » (système + outils) via hachage de contenu.
• Évaluateur de Probabilité de Survie (score) : Approxime la probabilité qu'un agent se déclenche dans les $K$ prochaines étapes. Au lieu de calculs exacts coûteux, il utilise un graphe orienté acyclique (DAG) avec seuil et une recherche en largeur (BFS) pour calculer un proxy de « nombre de sauts ». Ce score est combiné à l'horloge de récence existante du moteur pour déterminer la priorité d'éviction.
• Préchargement Inter-Session (predict + act) : Entre les étapes de l'ordonnanceur, le runtime prédit le prochain agent ($a^*$) et émet une requête de « préchauffage ». Cette requête ne contient que le prompt système et un message utilisateur minimal pour remplir le cache KV de l'ancre de l'agent prédit sans injecter de contenu spécifique complet à la session.

3. Contributions Clés

1. La Couche d'Exécution de l'Agent : Un troisième niveau proposé pour la pile de service qui expose une interface à quatre primitives (observe, score, predict, act). Les auteurs cartographient neuf politiques distinctes conscientes des agents (y compris le cache KV, la mémorisation des résultats d'outils, la mise en forme des lots et l'équité) sur cette interface, arguant qu'elles partagent toutes le même besoin architectural d'événements étiquetés par l'identité de l'agent.
2. CacheSage : Une implémentation concrète de la couche pour le cache KV. Il apprend en ligne des matrices de transition d'agents par charge de travail et les utilise pour une éviction basée sur la survie et un préchargement inter-étapes. Il fonctionne avec un état borné ($\le$ 20 Ko par charge de travail) et inclut un retour gracieux vers LRU standard si aucune structure n'est apprise.
3. Validation Empirique : Résultats préliminaires sur cinq charges de travail multi-agents réelles (MMLU, MT-Bench, GAIA, GSM8K, HumanEval) démontrant l'efficacité de l'approche.

4. Résultats

Des expériences ont été menées sur des GPU NVIDIA H100 utilisant Llama-3.1-8B-Instruct, comparant CacheSage à vLLM et Continuum.

• Taux de Succès du Cache : CacheSage a obtenu une augmentation de +13 à +37 points de pourcentage (pp) des taux de succès du cache par rapport à vLLM sur les cinq charges de travail. Cela est attribué au maintien des ancres d'agent à travers les limites de session que les caches réactifs évictent généralement.
• Latence : Le temps moyen jusqu'au premier token (TTFT) et la latence de bout en bout par tour ont été réduits de 12 % à 29 %.
• Débit : Le débit du système a augmenté de 6 % à 14 %.
• Surcharge : La surcharge du chemin critique est négligeable. La fonction observe s'exécute en $\sim1 \mu s$ par accès au bloc, et l'évaluateur s'exécute en quelques microsecondes. L'état du coordinateur reste inférieur à 25 Ko.

Il est à noter que le système de base Continuum, qui utilise des épingles TTL, a en réalité réduit les taux de succès de 9 à 23 pp sur trois charges de travail de tâches réelles, mettant en évidence les compromis des politiques statiques par rapport à la nature adaptative de la couche d'exécution.

5. Signification et Revendications

L'article affirme que la « couture » entre le cadre d'agent et le moteur de service est mieux résolue par un changement architectural plutôt que par des correctifs ponctuels incrémentaux.

• Modularité : L'interface à quatre primitives permet à des politiques distinctes de partager le même flux d'observation et de composer avec les mêmes primitives sans nécessiter de nouvelles interventions chirurgicales dans le moteur pour chaque politique.
• Généralité : La couche est agnostique du cadre (supportant AutoGen, LangGraph, etc.) et portable vers les moteurs, ne nécessitant que des points d'accroche spécifiques plutôt que des modifications internes profondes.
• Validation du Fossé : En démontrant des gains de performance significatifs sur le cache KV, les auteurs soutiennent que le fossé architectural est réel et qu'une couche d'exécution d'agent est un composant nécessaire pour un service efficace de LLMs agents.

Les auteurs restent modestes quant à la portée de leur travail actuel, notant que si CacheSage valide l'abstraction, les huit autres politiques cartographiées sur la couche (par exemple, mémorisation des résultats d'outils, exécution spéculative d'agents, équité) restent des défis ouverts pour les travaux futurs. La contribution principale est l'interface et l'argument architectural, et non l'achèvement de chaque implémentation de politique.