GKE Agent Substrate

Agent Substrate führt agentische Arbeitslasten in großem Maßstab auf Kubernetes-Clustern aus. Damit wird eine häufige Ressourcenineffizienz behoben: Interaktive Agenten (z. B. persönliche Assistenten und Coding-Agenten) 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 pausierte 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 auf einem Computer 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 Ruhezustand 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 Skalierungseinschränkungen, indem der Agent-Status von den zugrunde liegenden Pods entkoppelt wird: Es speichert Millionen von angehaltenen Agent-Snapshots im Speicher und stellt sie bei Bedarf in einem gemeinsamen Pool von warmen Workern wieder her.

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 die folgenden 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 werden sitzungsübergreifend beibehalten. 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.
  • Computing-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 Arbeitsspeicherressourcen verwenden, zahlen Sie nur für Rechenressourcen, wenn Agents Aufgaben aktiv verarbeiten.

Anwendungsfälle

Agent Substrate ist so konzipiert, dass Agenten in jeder Größenordnung ausgeführt werden können, von zehn bis zu Millionen von gleichzeitigen Agenten. Hier sind drei Beispielarbeitslasten:

  • Produktivitäts-KI-Agenten: Langfristige Hintergrundassistenten, die den Kontext über Wochen hinweg beibehalten. Da diese Assistenten die meiste Zeit auf Trigger warten, werden durch das Anhalten der Arbeitslasten bei Nichtgebrauch die Rechenkosten gesenkt.
  • 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 (definiert Container-Images, Umgebungsvariablen und Rechenressourcen), die zum Instanziieren von Actors 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 sperren und die freigegebenen Rechenressourcen wiederverwenden. Mit dieser Architektur kann das System Millionen von KI-Agenten auf einer begrenzten Anzahl von Maschinen ausführen.

Ein typischer Agentenlebenszyklus umfasst die folgenden Schritte:

  1. Routing: In 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 spezifischen 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 aktiven Worker weiter und der Actor verarbeitet die Aufgabe.
  4. Anhalten: Wenn der Actor seine Arbeit beendet hat und inaktiv wird, erstellt das System einen neuen Snapshot des Arbeitsspeichers und der Dateien des Actors, speichert den Snapshot im Speicher und gibt den leeren Worker wieder an den Pool zurück.

Arbeitslastisolation 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 auf 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 sind für GKE Beta-APIs (podcertificaterequests und clustertrustbundles) erforderlich. Wenn Sie diese APIs in einem vorhandenen Cluster mit Version 1.36 aktivieren, müssen Sie auch die vorhandenen Knoten ersetzen, damit die Pod-Zertifikatprojektion auf ihnen aktiviert wird. Ab Version 1.37 müssen vorhandene Knoten nicht ersetzt werden.
  • Workload Identity Federation for GKE: Für GKE-Cluster muss Workload Identity Federation for GKE aktiviert sein. Agent Substrate verwendet Workload Identity Federation for GKE, um sich bei Google Cloud APIs wie Cloud Storage zu authentifizieren, um Agent-Snapshots zu speichern.
  • 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 Kundenservicemitarbeiter die Arbeit unterbricht. 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 ist als Vorabversion verfügbar.
    • Collector-Connectors werden nicht unterstützt. Für das Telemetrie-Benchmarking ist daher ein externer Proxy-Zähler erforderlich.
    • Bei Collector-Bereitstellungen fällt ein Overhead für den Speicher-Cache an, der in großen Clustern linear mit der Anzahl der Pods 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 für die Installation nicht ausreicht. Sie müssen Agent Substrate von einer lokalen Workstation oder einer VM mit ausreichend Speicherplatz installieren.

Nächste Schritte