Informazioni su GKE Agent Substrate

Agent Substrate esegue carichi di lavoro agentici su larga scala sui cluster Kubernetes. Affronta un'inefficienza comune delle risorse: gli agenti interattivi (come gli assistenti personali e gli agenti di codifica) spesso trascorrono la maggior parte del tempo ad attendere l'input dell'utente o trigger esterni. Il mantenimento continuo dell'esecuzione di questi agenti inattivi utilizza CPU e memoria che altrimenti potrebbero essere allocate a carichi di lavoro attivi.

Agent Substrate risolve questo problema sospendendo gli agenti inattivi e scattando un'istantanea della memoria attiva (RAM) e dei file locali dell'agente. Quando l'agente sospeso deve agire di nuovo, il sistema ripristina il suo stato in una sandbox disponibile in meno di un secondo.

Agent Substrate si basa sulle funzionalità di Agent Sandbox e lo migliora aggirando i colli di bottiglia del control plane Kubernetes standard. Di conseguenza, esegue molti più agenti simultanei per macchina e riduce drasticamente i tempi di avvio degli agenti.

I deployment Kubernetes standard (inclusa la sandbox dell'agente) associano ogni workload dell'agente a un pod dedicato. Sebbene Kubernetes sia altamente scalabile, è limitato dalla velocità effettiva di pianificazione e dalla latenza di avvio dei pod. Inoltre, Kubernetes non supporta l'ibernazione dei pod e mantenere milioni di agenti inattivi in un cluster esaurirebbe i limiti dei pod e la memoria del control plane. Per evitare di pagare per la capacità di calcolo inattiva, devi arrestare i pod e gestire lo stato dell'agente in un archivio esterno. Agent Substrate risolve questi vincoli di scalabilità separando lo stato dell'agente dai pod sottostanti: memorizza milioni di snapshot di agenti sospesi nello spazio di archiviazione e li ripristina su richiesta in un pool condiviso di worker attivi.

Agent Substrate è un sistema open source che esegui il deployment direttamente sui tuoi cluster GKE Standard. Sebbene il progetto principale sia sviluppato nel repository open source Agent Substrate, Google fornisce strumenti e script di deployment ottimizzati per GKE nel repository substrate-gke per i clienti Google Cloud idonei.

Vantaggi di Agent Substrate

Puoi utilizzare Agent Substrate per raggiungere i seguenti obiettivi:

  • Esegui codice non attendibile in modo sicuro: Agent Substrate applica l'isolamento del kernel e della rete in modo da poter eseguire codice generato dall'AI senza rischiare la tua infrastruttura più ampia.
  • Crea agenti stateful a esecuzione prolungata: la memoria di lavoro e i file di un agente vengono conservati tra le sessioni. L'agente riprende esattamente dal punto in cui si è interrotto.
  • Rispondere alle richieste in tempo reale: quando una nuova richiesta attiva un agente sospeso, il sistema ripristina lo stato dell'agente in una frazione di secondo.
  • Ridurre i costi di calcolo: puoi eseguire più agenti su meno macchine condividendo un pool di sandbox worker tra tutti gli agenti. Poiché gli agenti inattivi vengono sospesi e non utilizzano CPU e memoria, paghi per il calcolo solo quando gli agenti elaborano attivamente le attività.

Casi d'uso

Agent Substrate è progettato per eseguire agenti su qualsiasi scala, da decine a milioni di agenti simultanei. Ecco tre esempi di carichi di lavoro:

  • Agenti di produttività: assistenti in background a lungo termine che mantengono il contesto per settimane. Poiché questi assistenti trascorrono la maggior parte del tempo in attesa di trigger, la sospensione dei workload quando non sono in uso riduce i costi di calcolo.
  • Sandbox effimere: ambienti isolati on demand per l'esecuzione di codice non attendibile generato da LLM, l'esecuzione di chiamate di strumenti o l'analisi dei dati. Poiché i sandbox vengono ripristinati in meno di un secondo, il sistema può fornire ambienti temporanei per attività di breve durata e rilasciare risorse al termine dell'esecuzione.
  • Agenti di programmazione: assistenti AI che conversano in tempo reale con gli sviluppatori per scrivere, compilare e testare il codice. L'agente esegue comandi del terminale e modifica i file all'interno di una sandbox. Quando l'agente è inattivo, il sistema lo sospende finché lo sviluppatore non invia un altro prompt.

Come funziona Agent Substrate

Agent Substrate è basato su Kubernetes, ma non è necessario comprenderne il funzionamento per utilizzarlo. I concetti principali di Agent Substrate sono i seguenti:

  • Attore: una singola istanza in esecuzione di un agente.
  • ActorTemplate: un progetto di configurazione (che definisce immagini container, variabili di ambiente e risorse di calcolo) utilizzato per creare istanze di attori.
  • Worker: una sandbox sicura in cui viene eseguito un attore attivo.
  • WorkerPool: un gruppo di worker inattivi e preavviati che vengono mantenuti pronti a ricevere un attore.

Poiché un attore non è legato a un lavoratore specifico, il sistema può sospendere gli agenti inattivi e riutilizzare la potenza di calcolo liberata. Questa architettura consente al sistema di eseguire milioni di agenti su un numero limitato di macchine.

Un ciclo di vita tipico di un agente segue questi passaggi:

  1. Instradamento: ogni richiesta API in entrata dalla tua applicazione specifica l'attore di destinazione. Ad esempio, quando un utente digita un nuovo prompt in un'interfaccia di chat, la tua applicazione invia una richiesta indirizzata all'attore specifico che gestisce la sessione dell'utente.
  2. Ripristino: se la richiesta riguarda un attore sospeso, il sistema richiede un worker caldo dal WorkerPool e ripristina lo snapshot dell'attore su quel worker.
  3. Esecuzione: il sistema indirizza la richiesta a questo worker appena attivato e l'attore elabora l'attività.
  4. Sospensione: quando l'attore termina il suo lavoro e diventa inattivo, il sistema acquisisce un nuovo snapshot della memoria e dei file dell'attore, lo salva nello spazio di archiviazione e rilascia il worker vuoto nel pool.

Isolamento del carico di lavoro e GKE Sandbox

Agent Substrate utilizza gVisor o Cloud Hypervisor per eseguire ogni workload in un sandbox che isola il codice dell'applicazione dal kernel host. L'installazione di Agent Substrate include un runtime gVisor per i worker, in modo da non dover configurare GKE Sandbox sui nodi GKE sottostanti.

Limitazioni e requisiti

Agent Substrate presenta le seguenti limitazioni e requisiti:

  • Versione del cluster e API beta: Agent Substrate è supportato sui cluster GKE Standard che eseguono la versione 1.36 (con i flag beta abilitati) o la versione 1.37 o successive. Le versioni precedenti alla 1.36 non sono supportate. Inoltre, GKE richiede l'abilitazione delle API beta (podcertificaterequests e clustertrustbundles) al momento della creazione del cluster. L'abilitazione di queste API su un cluster esistente non è supportata e non va a buon fine.
  • Workload Identity Federation for GKE: i cluster GKE devono avere Workload Identity Federation for GKE abilitata. Agent Substrate utilizza Workload Identity Federation for GKE per l'autenticazione alle APIGoogle Cloud , come Cloud Storage per il salvataggio degli snapshot dell'agente.
  • Famiglie di VM:
    • Architetture CPU miste: Agent Substrate non supporta le serie di macchine per uso generico che vengono eseguite su architetture CPU miste (come i tipi di macchine E2) a causa di un problema noto con gVisor.
    • Tipi di VM uniformi per modello di attore: la combinazione di tipi di VM all'interno di un singolo ActorTemplate (la blueprint di configurazione utilizzata per creare gli attori) non è supportata. Ad esempio, se il cluster ha due pool di nodi che utilizzano VM C4 e N2, un ActorTemplate deve includere un selettore di nodi che specifica un singolo tipo di VM (ad esempio C4) per impedire che gli attori per quel modello vengano suddivisi in diversi tipi di macchine.
  • Supporto GPU: il passthrough del dispositivo GPU nei container Actor non è supportato. La specifica di nvidia.com/gpu inserisce i pod solo sui nodi abilitati alla GPU, ma non passa il dispositivo GPU nel contenitore Actor. Inoltre, gVisor non può creare snapshot dei contesti CUDA attivi.
  • Networking:
    • Norme di uscita: le regole EgressPolicy (controlli di rete per nome host e indirizzo IP) non sono supportate, incluse le seguenti funzionalità:
      • Regole di negazione predefinite
      • Regole basate sul nome host
      • Inserimento delle credenziali
    • Connessioni aperte: le connessioni di rete aperte (ad esempio sessioni di database o connessioni ai server MCP) non vengono mantenute quando un agente viene sospeso. Il codice dell'agente deve gestire la riconnessione ai servizi esterni quando l'agente riprende l'attività.
  • Osservabilità e OpenTelemetry gestito: OpenTelemetry gestito per GKE presenta le seguenti limitazioni:
    • OpenTelemetry gestito per GKE è in anteprima.
    • I connettori del raccoglitore non sono supportati, il che richiede l'utilizzo di un misuratore proxy esterno per il benchmarking della telemetria.
    • I deployment del collettore comportano un overhead della cache di memoria che viene scalato linearmente con il numero di pod nei cluster di grandi dimensioni.
    • TLS non è supportato in Managed OpenTelemetry per GKE.
  • Storage: il sistema richiede Cloud Storage per salvare gli snapshot degli agenti.
  • Ambiente di installazione: non puoi installare Agent Substrate in Cloud Shell. Cloud Shell ha un limite di spazio di archiviazione su disco permanente di 5 GB, che non fornisce spazio su disco sufficiente per l'installazione. Devi installare Agent Substrate da una workstation locale o da una macchina virtuale (VM) con spazio su disco sufficiente.

Passaggi successivi