À propos du substrat de l'agent GKE

Agent Substrate exécute des charges de travail agentiques à grande échelle sur des clusters Kubernetes. Il s'attaque à une inefficacité courante des ressources : les agents interactifs (tels que les assistants personnels et les agents de codage) passent souvent la majeure partie de leur temps à attendre l'entrée d'un utilisateur ou des déclencheurs externes. Le maintien de l'exécution continue de ces agents inactifs utilise du processeur et de la mémoire qui pourraient autrement être alloués à des charges de travail actives.

Agent Substrate résout ce problème en suspendant les agents inactifs et en prenant un instantané de la mémoire vive (RAM) et des fichiers locaux de l'agent. Lorsque l'agent suspendu doit à nouveau agir, le système restaure l'état de l'agent dans un bac à sable disponible en moins d'une seconde.

Agent Substrate s'appuie sur les fonctionnalités d'Agent Sandbox et les améliore en contournant les goulots d'étranglement du plan de contrôle Kubernetes standard. Par conséquent, il exécute beaucoup plus d'agents simultanés par machine et réduit considérablement les temps de démarrage des agents.

Les déploiements Kubernetes standards (y compris le bac à sable de l'agent) associent chaque charge de travail d'agent à un pod dédié. Bien que Kubernetes soit très évolutif, il est limité par le débit de planification et la latence de démarrage des pods. De plus, Kubernetes n'est pas compatible avec la mise en veille des pods. Si vous conservez des millions d'agents inactifs dans un cluster, vous épuiserez les limites de pods et la mémoire du plan de contrôle. Pour éviter de payer pour la puissance de calcul inactive, vous devez éteindre les pods et gérer l'état de l'agent dans un stockage externe. Le sous-système Agent résout ces contraintes de scaling en dissociant l'état de l'agent des pods sous-jacents : il stocke des millions d'instantanés d'agents suspendus dans le stockage et les restaure à la demande dans un pool partagé de Workers actifs.

Agent Substrate est un système Open Source que vous déployez directement sur vos propres clusters GKE Standard. Bien que le projet principal soit développé dans le dépôt Agent Substrate Open Source, Google fournit des outils et des scripts de déploiement optimisés pour GKE dans le dépôt substrate-gke pour les clients éligibles Google Cloud .

Avantages d'Agent Substrate

Vous pouvez utiliser Agent Substrate pour atteindre les objectifs suivants :

  • Exécutez du code non approuvé en toute sécurité : Agent Substrate applique l'isolation du noyau et du réseau pour que vous puissiez exécuter du code généré par l'IA sans risquer d'endommager votre infrastructure.
  • Créez des agents avec état de longue durée : la mémoire de travail et les fichiers d'un agent sont conservés d'une session à l'autre. L'agent reprend exactement là où il s'était arrêté.
  • Répondre aux requêtes en temps réel : lorsqu'une nouvelle requête déclenche un agent suspendu, le système restaure l'état de l'agent en une fraction de seconde.
  • Réduisez les coûts de calcul : vous pouvez exécuter plus d'agents sur moins de machines en partageant un pool de bacs à sable Worker entre tous vos agents. Étant donné que les agents inactifs sont suspendus et n'utilisent pas de processeur ni de mémoire, vous ne payez les ressources de calcul que lorsque les agents traitent activement des tâches.

Cas d'utilisation

Agent Substrate est conçu pour exécuter des agents à n'importe quelle échelle, de quelques dizaines à des millions d'agents simultanés. Voici trois exemples de charges de travail :

  • Agents de productivité : assistants en arrière-plan de longue durée qui conservent le contexte pendant plusieurs semaines. Comme ces assistants passent la majorité de leur temps à attendre des déclencheurs, la suspension des charges de travail lorsqu'elles ne sont pas utilisées réduit les coûts de calcul.
  • Bac à sable éphémère : environnements isolés à la demande pour exécuter du code non fiable généré par LLM, exécuter des appels d'outils ou analyser des données. Comme les bacs à sable sont restaurés en moins d'une seconde, le système peut fournir des environnements jetables pour les tâches de courte durée et libérer des ressources une fois l'exécution terminée.
  • Agents de codage : assistants IA qui discutent en temps réel avec les développeurs pour écrire, compiler et tester du code. L'agent exécute des commandes de terminal et modifie des fichiers dans un bac à sable. Lorsque l'agent est inactif, le système le suspend jusqu'à ce que le développeur envoie une autre requête.

Fonctionnement d'Agent Substrate

Agent Substrate est basé sur Kubernetes, mais vous n'avez pas besoin de comprendre Kubernetes pour l'utiliser. Voici les concepts fondamentaux d'Agent Substrate :

  • Acteur : instance d'exécution unique d'un agent.
  • ActorTemplate : plan de configuration (définissant les images de conteneur, les variables d'environnement et les ressources de calcul) utilisé pour instancier les acteurs.
  • Worker : bac à sable sécurisé dans lequel un acteur actif s'exécute.
  • WorkerPool : groupe de nœuds de calcul inactifs et pré-démarrés, prêts à recevoir un acteur.

Comme un acteur n'est pas lié à un Worker spécifique, le système peut suspendre les agents inactifs et réutiliser les ressources de calcul libérées. Cette architecture permet au système d'exécuter des millions d'agents sur un nombre limité de machines.

Le cycle de vie d'un agent typique se déroule comme suit :

  1. Routage : chaque requête API entrante de votre application spécifie son acteur cible. Par exemple, lorsqu'un utilisateur saisit une nouvelle requête dans une interface de chat, votre application envoie une requête adressée à l'acteur spécifique qui gère la session de l'utilisateur.
  2. Reprise : si la requête concerne un acteur suspendu, le système récupère un Worker "warm" du WorkerPool et restaure le snapshot de l'acteur sur ce Worker.
  3. Exécution : le système achemine la requête vers ce Worker nouvellement actif, et l'Actor traite la tâche.
  4. Suspension : lorsque l'acteur termine son travail et devient inactif, le système prend un nouvel instantané de la mémoire et des fichiers de l'acteur, l'enregistre dans le stockage et libère le nœud de calcul vide dans le pool.

Isolation des charges de travail et GKE Sandbox

Agent Substrate utilise gVisor ou Cloud Hypervisor pour exécuter chaque charge de travail dans un bac à sable qui isole le code de l'application du noyau hôte. L'installation d'Agent Substrate inclut un environnement d'exécution gVisor pour les nœuds de calcul. Vous n'avez donc pas besoin de configurer GKE Sandbox sur les nœuds GKE sous-jacents.

Limites et exigences

Le sous-ensemble d'agent présente les limites et exigences suivantes :

  • Version du cluster et API bêta : Agent Substrate est compatible avec les clusters GKE Standard exécutant la version 1.36 (avec les indicateurs bêta activés) ou la version 1.37 ou ultérieure. Les versions antérieures à 1.36 ne sont pas compatibles. De plus, GKE nécessite que les API bêta (podcertificaterequests et clustertrustbundles) soient activées lors de la création du cluster. Il n'est pas possible d'activer ces API sur un cluster existant.
  • Workload Identity Federation for GKE : la fédération d'identité de charge de travail pour GKE doit être activée sur les clusters GKE. Agent Substrate utilise Workload Identity Federation for GKE afin de s'authentifier auprès des APIGoogle Cloud , telles que Cloud Storage pour enregistrer les instantanés d'agent.
  • Familles de VM :
    • Architectures de processeur mixtes : Agent Substrate n'est pas compatible avec les séries de machines à usage général qui s'exécutent sur des architectures de processeur mixtes (comme les types de machines E2) en raison d'un problème connu avec gVisor.
    • Types de VM uniformes par modèle d'acteur : il n'est pas possible de combiner des types de VM dans un même ActorTemplate (le plan de configuration utilisé pour créer des acteurs). Par exemple, si votre cluster comporte deux pools de nœuds utilisant des VM C4 et N2, un ActorTemplate doit inclure un sélecteur de nœuds qui spécifie un seul type de VM (tel que C4) pour empêcher les acteurs de ce modèle d'être répartis sur différents types de machines.
  • Compatibilité avec les GPU : le transfert direct de périphériques GPU dans les conteneurs Actor n'est pas compatible. Si vous spécifiez uniquement nvidia.com/gpu, les pods sont placés sur des nœuds compatibles avec les GPU, mais le périphérique GPU n'est pas transmis au conteneur Actor. De plus, gVisor ne peut pas créer d'instantanés des contextes CUDA actifs.
  • Mise en réseau :
    • Règles de sortie : les règles EgressPolicy (contrôles réseau par nom d'hôte et adresse IP) ne sont pas compatibles, y compris les fonctionnalités suivantes :
      • Règles de refus par défaut
      • Règles basées sur le nom d'hôte
      • Injection d'identifiants
    • Connexions ouvertes : les connexions réseau ouvertes (telles que les sessions de base de données ou les connexions aux serveurs MCP) ne sont pas conservées lorsqu'un agent est suspendu. Votre code d'agent doit gérer la reconnexion aux services externes lorsque l'agent reprend son activité.
  • Observabilité et OpenTelemetry géré : OpenTelemetry géré pour GKE présente les limites suivantes :
    • Managed OpenTelemetry pour GKE est disponible en version bêta.
    • Les connecteurs de collecteur ne sont pas compatibles, ce qui nécessite l'utilisation d'un compteur proxy externe pour le benchmarking de la télémétrie.
    • Les déploiements de collecteurs entraînent des frais généraux de cache de la mémoire qui évoluent de manière linéaire avec le nombre de pods dans les grands clusters.
    • TLS n'est pas compatible avec Managed OpenTelemetry pour GKE.
  • Stockage : le système nécessite Cloud Storage pour enregistrer les instantanés de vos agents.
  • Environnement d'installation : vous ne pouvez pas installer Agent Substrate dans Cloud Shell. Cloud Shell dispose d'une limite de stockage sur disque persistant de 5 Go, ce qui ne fournit pas suffisamment d'espace disque pour l'installation. Vous devez installer Agent Substrate à partir d'une station de travail locale ou d'une machine virtuelle (VM) disposant de suffisamment d'espace disque.

Étapes suivantes