Cortex : Mise en commun des ressources et ordonnancement conscients du flux de travail pour la fourniture d'agents

Informations de base

• ID de l'article : 2510.14126
• Titre : Cortex: Workflow-Aware Resource Pooling and Scheduling for Agentic Serving
• Auteurs : Nikos Pagonas (Columbia University), Yeounoh Chung (Google), Kostis Kaffes (Columbia University), Arvind Krishnamurthy (Google & University of Washington)
• Classification : cs.DC (Informatique distribuée, parallèle et en grappe)
• Date de publication : 15 octobre 2025 (prépublication arXiv)
• Lien de l'article : https://arxiv.org/abs/2510.14126

Résumé

Cet article présente Cortex, un prototype de plateforme de service consciente du flux de travail conçu pour les charges de travail d'agents. Le principe fondamental de Cortex est l'isolation des étapes : fournir des pools de ressources dédiés pour chaque étape distincte du flux de travail d'un agent. Cette stratégie simple mais puissante atténue les interférences inter-étapes dans le calcul et la mémoire, permettant une meilleure utilisation du cache KV, un débit plus élevé et des performances plus prévisibles. En personnalisant l'allocation des ressources et l'ordonnancement au sein de chaque étape distincte du flux de travail d'un agent, Cortex jette les bases de paradigmes de service plus avancés et natifs des agents, notamment la gestion des ressources plastiques, l'exécution spéculative des branches de flux de travail et les caches multicouches partagés pour l'« état d'agent ».

Contexte de recherche et motivation

Définition du problème

Les flux de travail d'agents combinent l'inférence de modèles de langage volumineux (LLM) avec l'utilisation itérative d'outils : le modèle observe les résultats intermédiaires, réfléchit, appelle un autre outil et répète jusqu'à ce que la tâche soit résolue ou que le budget soit épuisé. Ce mode en boucle fermée devient de plus en plus important dans les applications de niveau production, comme les agents de conversion du langage naturel en SQL (NL2SQL).

Limitations des approches existantes

Les plateformes actuelles de service LLM présentent les problèmes suivants :

1. Insensibilité au flux de travail : Les cadres populaires de service LLM (comme vLLM) traitent chaque étape comme un appel LLM indépendant, utilisant l'ordonnancement premier arrivé, premier servi (FCFS)
2. Manque de conscience structurelle : Les plateformes de service d'agents existantes (comme Autellix) utilisent des stratégies de priorité complexes mais ne comprennent pas la structure interne du flux de travail
3. Opportunités de cache gaspillées : Cinq tentatives d'amélioration du même modèle produisent cinq constructions de requête identiques et cinq exécutions de cache chaud SQL identiques
4. Ordonnancement aveugle : L'ordonnancement des appels LLM sans connaissance du flux de travail restant, ignorant les coûts en aval

Motivation de la recherche

Les auteurs observent qu'un seul pool d'« usage général » LLM partagé ne convient pas aux flux de travail d'agents contenant des étapes hétérogènes. Chaque étape (génération SQL, exécution, correction d'erreurs) possède des profils de latence différents, des exigences de mémoire différentes et des opportunités de cache différentes.

Contributions principales

1. Proposition de l'architecture Cortex : Première plateforme de service consciente du flux de travail basée sur l'isolation des étapes, fournissant des pools de moteurs dédiés pour chaque étape du flux de travail
2. Réalisation d'optimisations significatives du cache KV : Réduction significative de l'utilisation de la mémoire du cache KV par l'isolation des étapes, amélioration de l'utilisation de la mémoire GPU
3. Élimination des interférences inter-étapes : Restauration de modèles de latence stables et locaux aux étapes, amélioration de la prévisibilité des performances
4. Conception d'un cadre de service natif des agents : Fondation pour les flux de travail plastiques, l'exécution spéculative et la gestion de l'état d'agent

Explication détaillée de la méthode

Définition des tâches

En prenant le flux de travail NL2SQL comme exemple, l'entrée est une requête en langage naturel (par exemple, « Quel était le chiffre d'affaires du trimestre dernier en Europe ? »), et la sortie est le résultat d'une requête SQL exécutée avec succès. Le flux de travail comprend :

1. Récupération du schéma cible
2. Génération autorégressive de requêtes candidates
3. Exécution de la requête
4. Validation de l'ensemble de résultats
5. Si la requête échoue, correction et nouvelle tentative

Conception de l'architecture centrale

Principe d'isolation des étapes

Cortex fournit des pools de moteurs dédiés pour chaque étape du flux de travail. Un pool de moteurs est un ensemble de travailleurs homogènes (par exemple, des GPU pour le décodage LLM ou des exécuteurs CPU pour SQL), géré par un ordonnanceur local à l'étape avec sa propre file d'attente, cache et stratégie de mise à l'échelle.

Composants du système

1. Orchestrateur (Orchestrator) :
   • Conscient du flux de travail, suit la position de chaque requête dans le graphe
   • Prédit le prochain ensemble d'opérateurs éligibles
   • Attache des clés de priorité basées sur le relâchement SLO, la sélectivité des étapes et le temps de service attendu
2. Couche d'allocation des moteurs (Engine Allocation Layer) :
   • Achemine les sous-appels vers des instances de pool qui maximisent la localité
   • Équilibre la charge entre les répliques
   • Réordonne les requêtes en fonction de la priorité
   • Exécute le contrôle d'admission lorsqu'une étape devient un goulot d'étranglement
3. Mécanisme d'emprunt de ressources : Lorsque la charge et la pression mémoire sont suffisamment faibles, l'orchestrateur peut permettre opportunément aux étapes compatibles d'emprunter des moteurs inactifs pour réduire la fragmentation et améliorer l'utilisation.

Points d'innovation technique

Optimisation du cache KV

Par l'isolation des étapes, chaque moteur ne maintient que le contexte spécifique à son étape, tandis que les moteurs partagés doivent maintenir le cache chaud du contexte de deux étapes sur chaque réplique, doublant effectivement l'utilisation de la mémoire du cache KV. La mémoire GPU récupérée augmente la taille de lot effective, se traduisant directement par un débit plus élevé et une latence de queue plus serrée.

Prévisibilité des performances

L'isolation des étapes élimine les interférences inter-étapes qui nuisent à la prévisibilité. Lorsque des appels hétérogènes partagent un moteur, les lots couplent leurs temps d'exécution, retardant l'émission de jetons et rendant la latence des appels LLM dépendante de leurs partenaires de lot.

Mise à l'échelle indépendante

Permet la mise à l'échelle et la configuration indépendantes : un moniteur rapide met à l'échelle uniquement les pools menaçant le SLO, permettant une configuration légère des étapes d'exécution unique, tout en allouant plus de poids aux pools du chemin critique.

Configuration expérimentale

Scénarios d'expérience

L'article utilise le flux de travail NL2SQL comme scénario d'expérience principal, contenant deux étapes LLM :

• Générateur SQL
• Correcteur d'erreurs SQL
• Exécuteur SQL (étape non-LLM)

Métriques d'évaluation

• Utilisation de la mémoire du cache KV
• Empreinte mémoire totale
• Débit du système
• Latence de queue

Repères de comparaison

• Solution de pool de moteurs partagés : toutes les étapes partagent le même ensemble de moteurs LLM
• Solution d'isolation des étapes Cortex : chaque étape utilise un pool de moteurs dédié

Résultats expérimentaux

Résultats principaux

Effet d'optimisation du cache KV

Les résultats expérimentaux montrent que lors de l'exécution des étapes LLM du flux de travail NL2SQL dans Cortex, l'occupation totale du KV diminue considérablement. Lorsque chaque étape s'exécute dans son propre pool Cortex, l'empreinte KV totale est nettement plus faible : chaque moteur ne maintient que le contexte spécifique à son étape.

Amélioration des performances

1. Efficacité mémoire : Par l'isolation des étapes, évite la duplication du cache KV, libérant une mémoire GPU précieuse
2. Augmentation du débit : La mémoire GPU récupérée se traduit directement par une taille de lot effective plus élevée
3. Amélioration de la latence : Latence de queue plus serrée et performances plus prévisibles

Vérification des avantages du système

L'expérience valide les trois avantages principaux de Cortex :

1. Utilisation améliorée du cache KV : Réduction significative de l'occupation mémoire
2. Élimination des interférences inter-étapes : Restauration de modèles de latence stables et locaux aux étapes
3. Capacité de mise à l'échelle indépendante : Support de la gestion des ressources à granularité fine

Travaux connexes

Cadres de service LLM

• vLLM : Service de modèle de langage volumineux efficace, utilisant PagedAttention pour la gestion de la mémoire
• SGLang : Exécution efficace de programmes de modèles de langage structurés

Plateformes de service d'agents

• Autellix : Moteur de service efficace pour les agents LLM, utilisant des stratégies de priorité complexes
• HEXGEN-TEXT2SQL : Ordonnancement des requêtes de flux de travail NL2SQL basé sur le relâchement du délai restant et le temps d'exécution estimé

Différences techniques

Les plateformes existantes manquent de conscience de la structure interne du flux de travail, que Cortex comble par l'isolation des étapes.

Conclusion et discussion

Conclusions principales

Cortex améliore considérablement les performances de service des charges de travail d'agents grâce à une stratégie simple mais efficace d'isolation des étapes. Cette approche non seulement améliore l'efficacité de l'utilisation des ressources, mais jette également les bases de paradigmes de service plus avancés et natifs des agents.

Directions futures

Flux de travail plastiques et ressources

1. Adaptabilité du calcul : Remplacer les modèles lourds par des variantes légères lorsque la latence approche la limite SLO
2. Élasticité des ressources : Utiliser des moteurs plus puissants pour rattraper les retardataires dans les modèles de fan-out

Exécution spéculative

• Spéculer sur les branches les plus probables du flux de travail
• Préchauffer les moteurs pertinents ou pré-exécuter l'étape suivante
• Générer et évaluer en parallèle plusieurs requêtes candidates

Gestion de l'état d'agent

• Multicouche « état d'agent » avec les données intermédiaires comme citoyens de première classe
• Couche partagée au niveau du flux de travail en tant que structure publication/abonnement
• Transformer les appels d'outils et LLM répétés en accès à coût zéro

Limitations

1. Phase de prototype : Actuellement encore une preuve de concept, nécessitant une implémentation et une évaluation plus complètes
2. Restrictions de scénario : Principalement basé sur NL2SQL comme exemple, nécessite une validation sur plus de flux de travail d'agents
3. Gestion de la complexité : Comment concevoir des interfaces permettant aux flux de travail de déclarer leur plasticité reste un défi ouvert

Évaluation approfondie

Avantages

1. Innovation forte : Première architecture de service d'agents consciente du flux de travail
2. Identification précise des problèmes : Identification précise des problèmes clés des plateformes de service LLM existantes
3. Solution simple et efficace : La stratégie d'isolation des étapes est simple mais très efficace
4. Forte prospective : Fournit une trajectoire de développement claire pour les services d'agents natifs futurs

Insuffisances

1. Validation expérimentale limitée : Principalement basée sur un scénario NL2SQL, manque d'expériences diversifiées à grande échelle
2. Résultats quantifiés insuffisants : Les graphiques montrent les tendances mais manquent de chiffres spécifiques d'amélioration des performances
3. Détails d'implémentation insuffisants : Description moins détaillée de l'implémentation spécifique des algorithmes d'ordonnancement et des stratégies d'allocation des ressources
4. Expériences de comparaison insuffisantes : Principalement comparé à la simple approche de pool partagé, manque de comparaison avec d'autres méthodes avancées

Impact

1. Valeur académique : Fournit une nouvelle direction de recherche pour le domaine du service d'agents
2. Valeur pratique : Résout des problèmes importants dans les environnements de production réels
3. Caractère inspirant : Fournit des idées précieuses pour les recherches connexes ultérieures

Scénarios applicables

1. Flux de travail d'agents multi-étapes : Particulièrement adapté aux applications d'agents avec une division d'étapes claire
2. Environnements sensibles aux ressources : Effets significatifs dans les environnements où les ressources comme la mémoire GPU sont limitées
3. Scénarios à exigences de haute performance : Environnements de production avec des exigences strictes de latence et de débit

Références

L'article cite les références clés suivantes :

1. vLLM : Mécanisme de gestion de la mémoire PagedAttention
2. SGLang : Exécution de programmes de modèles de langage structurés
3. Autellix : Moteur de service d'agents LLM
4. HEXGEN-TEXT2SQL : Ordonnancement de flux de travail d'agents
5. Littérature connexe NL2SQL et services cloud

Évaluation globale : Ceci est un article innovant et prospectif qui soulève des problèmes importants dans le domaine du service d'agents et propose des solutions efficaces. Bien qu'actuellement au stade du prototype, il indique clairement la direction du développement du domaine et possède une valeur académique et pratique importante.