GKE Agent Substrate

Agent Substrate führt agentenbasierte Arbeitslasten in großem Umfang auf Kubernetes-Clustern aus. Das Problem ist eine häufige Ressourcenverschwendung: Interaktive Agents (z. B. persönliche Assistenten und Coding-Agents) verbringen oft die meiste Zeit damit, auf Nutzereingaben oder externe Trigger zu warten. Wenn diese inaktiven Agents kontinuierlich ausgeführt werden, werden CPU und Arbeitsspeicher verwendet, die ansonsten aktiven Arbeitslasten zugewiesen werden könnten.

Agent Substrate löst dieses Problem, indem inaktive Agents angehalten und ein Snapshot des aktiven Arbeitsspeichers (RAM) und der lokalen Dateien des Agents erstellt wird. Wenn der angehaltene Agent wieder aktiv werden muss, stellt das System den Status des Agents in weniger als einer Sekunde in einer verfügbaren Sandbox wieder her.

Agent Substrate basiert auf den Funktionen der Agent-Sandbox und umgeht die Engpässe der standardmäßigen Kubernetes-Steuerungsebene. Dadurch können deutlich mehr Agents gleichzeitig pro Maschine ausgeführt werden und die Startzeiten von Agents werden drastisch verkürzt.

Bei Standard-Kubernetes-Bereitstellungen (einschließlich Agent Sandbox) wird jede Agent-Arbeitslast einem dedizierten Pod zugeordnet. Kubernetes ist zwar hochgradig skalierbar, wird aber durch den Planungsdurchsatz und die Startlatenz von Pods eingeschränkt. Außerdem unterstützt Kubernetes das Ruhen von Pods nicht. Millionen von inaktiven Agents in einem Cluster würden die Pod-Limits und den Arbeitsspeicher der Steuerungsebene erschöpfen. Um Gebühren für inaktive Rechenleistung zu vermeiden, müssen Sie die Pods herunterfahren und den Agent-Status in einem externen Speicher verwalten. Agent Substrate löst diese Skalierungsbeschränkungen, indem der Agent-Status von den zugrunde liegenden Pods entkoppelt wird: Millionen von angehaltenen Agent-Snapshots werden im Speicher abgelegt und bei Bedarf in einem gemeinsamen Pool von warmen Workern wiederhergestellt.

Agent Substrate ist ein Open-Source-System, das Sie direkt in Ihren eigenen GKE-Standardclustern bereitstellen. Das Kernprojekt wird zwar im Open-Source-Agent Substrate-Repository entwickelt, Google stellt aber für berechtigte Google Cloud Kunden GKE-optimierte Bereitstellungstools und ‑scripts im Substrate-GKE-Repository bereit.

Vorteile von Agent Substrate

Mit Agent Substrate können Sie folgende Ziele erreichen:

  • Nicht vertrauenswürdigen Code sicher ausführen: Agent Substrate erzwingt die Kernel- und Netzwerkisolation, sodass Sie KI-generierten Code ausführen können, ohne Ihre gesamte Infrastruktur zu gefährden.
  • Langfristig ausgelegte, zustandsorientierte Agenten erstellen: Der Arbeitsspeicher und die Dateien eines Agenten bleiben sitzungsübergreifend erhalten. Der Agent setzt genau an der Stelle fort, an der er pausiert wurde.
  • In Echtzeit auf Anfragen reagieren: Wenn eine neue Anfrage einen gesperrten Agenten auslöst, wird der Status des Agenten in einem Bruchteil einer Sekunde wiederhergestellt.
  • Compute-Kosten senken: Sie können mehr Agents auf weniger Maschinen ausführen, indem Sie einen Pool von Worker-Sandboxes für alle Ihre Agents freigeben. Da inaktive Agents angehalten werden und keine CPU und keinen Arbeitsspeicher verwenden, zahlen Sie für die Rechenleistung nur, wenn Agents Aufgaben aktiv verarbeiten.

Anwendungsfälle

Agent Substrate ist so konzipiert, dass es Agenten in jeder Größenordnung ausführen kann, von zehn bis zu Millionen von gleichzeitigen Agenten. Hier sind drei Beispielarbeitslasten:

  • Produktivitäts-Agents: Langfristige Hintergrundassistenten, die den Kontext über Wochen hinweg beibehalten. Da diese Assistenten die meiste Zeit auf Trigger warten, werden die Computing-Kosten gesenkt, wenn die Arbeitslasten bei Nichtgebrauch angehalten werden.
  • Kurzlebige Sandboxes: On-Demand-Umgebungen, die isoliert sind und in denen nicht vertrauenswürdiger, von LLMs generierter Code ausgeführt, Tool-Aufrufe ausgeführt oder Daten analysiert werden können. Da Sandboxes in weniger als einer Sekunde wiederhergestellt werden, kann das System Einwegumgebungen für kurzlebige Aufgaben bereitstellen und Ressourcen freigeben, wenn die Ausführung abgeschlossen ist.
  • Coding Agents: KI-Assistenten, die in Echtzeit mit Entwicklern kommunizieren, um Code zu schreiben, zu erstellen und zu testen. Der KI-Agent führt Terminalbefehle aus und ändert Dateien in einer Sandbox. Wenn der Agent inaktiv ist, wird er vom System angehalten, bis der Entwickler einen weiteren Prompt sendet.

Funktionsweise von Agent Substrate

Agent Substrate basiert auf Kubernetes, aber Sie müssen Kubernetes nicht verstehen, um es zu verwenden. Die wichtigsten Konzepte von Agent Substrate sind:

  • Akteur: Eine einzelne laufende Instanz eines Agents.
  • ActorTemplate: Eine Konfigurationsvorlage (mit Definitionen für Container-Images, Umgebungsvariablen und Rechenressourcen), die zum Instanziieren von Akteuren verwendet wird.
  • Worker: Eine sichere Sandbox, in der ein aktiver Actor ausgeführt wird.
  • WorkerPool: Eine Gruppe von vorab gestarteten, inaktiven Workern, die bereitgehalten werden, um einen Actor zu empfangen.

Da ein Actor nicht an einen bestimmten Worker gebunden ist, kann das System inaktive Agents anhalten und die freigegebenen Rechenressourcen wiederverwenden. Diese Architektur ermöglicht es dem System, Millionen von Agenten auf einer begrenzten Anzahl von Maschinen auszuführen.

Ein typischer Agent-Lebenszyklus umfasst die folgenden Schritte:

  1. Routing: Bei jeder eingehenden API-Anfrage von Ihrer Anwendung wird der Ziel-Actor angegeben. Wenn ein Nutzer beispielsweise einen neuen Prompt in eine Chatoberfläche eingibt, sendet Ihre Anwendung eine Anfrage an den Actor, der die Sitzung des Nutzers verwaltet.
  2. Fortsetzen: Wenn die Anfrage für einen gesperrten Actor erfolgt, fordert das System einen warmen Worker aus dem WorkerPool an und stellt den Snapshot des Actors auf diesem Worker wieder her.
  3. Ausführung: Das System leitet die Anfrage an diesen neu aktivierten Worker weiter und der Actor verarbeitet die Aufgabe.
  4. Aussetzen: Wenn der Actor seine Arbeit beendet und inaktiv wird, erstellt das System einen neuen Snapshot des Arbeitsspeichers und der Dateien des Actors, speichert den Snapshot und gibt den leeren Worker wieder an den Pool zurück.

Isolation von Arbeitslasten und GKE Sandbox

Agent Substrate verwendet gVisor oder Cloud Hypervisor, um jede Arbeitslast in einer Sandbox auszuführen, die den Anwendungscode vom Hostkernel isoliert. Die Agent Substrate-Installation umfasst eine gVisor-Laufzeit für Worker, sodass Sie GKE Sandbox nicht auf den zugrunde liegenden GKE-Knoten konfigurieren müssen.

Beschränkungen und Anforderungen

Für Agent Substrate gelten die folgenden Einschränkungen und Anforderungen:

  • Clusterversion und Beta-APIs: Agent Substrate wird in GKE-Standardclustern mit Version 1.36 (mit aktivierten Beta-Flags) oder Version 1.37 oder höher unterstützt. Versionen vor 1.36 werden nicht unterstützt. Außerdem müssen für GKE Beta APIs (podcertificaterequests und clustertrustbundles) bei der Clustererstellung aktiviert sein. Das Aktivieren dieser APIs in einem vorhandenen Cluster wird nicht unterstützt und schlägt fehl.
  • Workload Identity Federation for GKE: Für GKE-Cluster muss Workload Identity Federation for GKE aktiviert sein. Agent Substrate verwendet die Workload Identity-Föderation für GKE zur Authentifizierung beiGoogle Cloud -APIs, z. B. Cloud Storage zum Speichern von Agent-Snapshots.
  • VM-Familien:
    • Gemischte CPU-Architekturen: Agent Substrate unterstützt keine Maschinenreihen für allgemeine Zwecke, die auf gemischten CPU-Architekturen ausgeführt werden (z. B. E2-Maschinentypen), da ein bekanntes Problem mit gVisor besteht.
    • Einheitliche VM-Typen pro Actor-Vorlage: Das Mischen von VM-Typen innerhalb einer einzelnen ActorTemplate (der Konfigurationsvorlage, die zum Erstellen von Actors verwendet wird) wird nicht unterstützt. Wenn Ihr Cluster beispielsweise zwei Knotenpools mit C4- und N2-VMs hat, muss ein ActorTemplate einen Knotenselektor enthalten, der einen einzelnen VM-Typ (z. B. C4) angibt, damit die Akteure für diese Vorlage nicht auf verschiedene Maschinentypen aufgeteilt werden.
  • GPU-Unterstützung: Das Durchreichen von GPU-Geräten in Actor-Container wird nicht unterstützt. Wenn Sie nur nvidia.com/gpu angeben, werden Pods auf GPU-fähigen Knoten platziert, das GPU-Gerät wird aber nicht an den Actor-Container übergeben. Außerdem kann gVisor keine Snapshots von aktiven CUDA-Kontexten erstellen.
  • Netzwerk:
    • Richtlinien für ausgehenden Traffic: EgressPolicy-Regeln (Netzwerksteuerung nach Hostname und IP-Adresse) werden nicht unterstützt, einschließlich der folgenden Funktionen:
      • Standard-Ablehnungsregeln
      • Hostnamebasierte Regeln
      • Einschleusen von Anmeldedaten
    • Offene Verbindungen: Offene Netzwerkverbindungen (z. B. Datenbanksitzungen oder Verbindungen zu MCP-Servern) werden nicht beibehalten, wenn ein Agent angehalten wird. Ihr Agentencode muss die erneute Verbindung zu externen Diensten verarbeiten, wenn der Agent fortgesetzt wird.
  • Observability und verwaltetes OpenTelemetry: Verwaltetes OpenTelemetry für GKE hat die folgenden Einschränkungen:
    • Verwaltetes OpenTelemetry für GKE befindet sich in der Vorschau.
    • Collector-Connectors werden nicht unterstützt. Für das Telemetrie-Benchmarking ist daher ein externes Proxy-Messgerät erforderlich.
    • Bei Collector-Bereitstellungen fällt ein Overhead für den Speicher-Cache an, der linear mit der Anzahl der Pods in großen Clustern skaliert wird.
    • TLS wird in Managed OpenTelemetry für GKE nicht unterstützt.
  • Speicher: Das System erfordert Cloud Storage, um die Snapshots Ihrer Agents zu speichern.
  • Installationsumgebung: Sie können Agent Substrate nicht in Cloud Shell installieren. Cloud Shell hat ein Limit von 5 GB für nichtflüchtigen Speicher, was nicht genügend Speicherplatz für die Installation bietet. Sie müssen Agent Substrate von einer lokalen Workstation oder einer VM mit ausreichend Speicherplatz installieren.

Nächste Schritte