Speicher für KI-Arbeitslasten mit Agenten auswählen

In diesem Dokument erfahren Sie, wie Sie eine geeignete Speicheroption für Ihre KI-Agenten auswählen, die auf ihren spezifischen Datenlebenszyklus und Latenzanforderungen basiert.

Details zur Implementierung finden Sie unter Agent Sandbox-Speicher in GKE verwalten.

Überlegungen zur Auswahl einer Speicherlösung

Bei der Auswahl einer Speicherlösung für Ihre KI-Agenten sollten Sie die Anforderungen Ihrer Agentenplattform berücksichtigen, z. B. Leistung und Skalierung, sowie die Anforderungen an die Datenverwaltung Ihrer Agenten.

Plattformanforderungen

Bewerten Sie die folgenden betrieblichen und architektonischen Anforderungen Ihrer Plattform:

  • Plattformskalierung und Häufigkeit der Agentenfluktuation (Steuerungsebene): Anzahl der gleichzeitigen Agenten und Anzahl der Agenten, die pro Minute erstellt, pausiert, reaktiviert, und gelöscht werden. Plattformen, auf denen Tausende von Agenten pro Minute erstellt oder inaktive Agenten pausiert werden, erfordern Speicher mit Anfüge- und Bereitstellungsvorgängen mit niedriger Latenz in großem Maßstab (z. B. werden Filestore-Bereitstellungen schneller als Hyperdisk-Anfügungen ausgeführt).
  • Dataset-Größe und Latenz beim Laden (Datenebene): Agenten, die beim Start Datasets mit mehreren Gigabyte oder umfangreiche Bibliotheken (z. B. Node.js- oder Python- Pakete) laden, erfordern eine hohe Speicher-E/A-Leistung, um die Daten in Sekunden zu lesen (z. B. bietet Hyperdisk einen hohen Lesedurchsatz pro Laufwerk).
  • Latenz beim Kaltstart und bei der Reaktivierung von Agenten: die erwartete Latenz, z. B. im Subsekunden- oder Multisekundenbereich. Um eine Startlatenz im Subsekundenbereich zu erreichen, muss die Agent Sandbox in GKE-Warm Pools verwendet werden. Bei der direkten Sandbox-Erstellung kommt es in der Regel zu einer Verzögerung von mehreren Sekunden beim Pod-Start und beim dynamischen Anfügen von Laufwerken.
  • Speichergröße pro Agent: Je nach ausgewähltem Dienst müssen Sie die Bereitstellungslimits berücksichtigen, z. B. eine Mindestgröße von 4 GiB für Google Cloud Hyperdisk oder mindestens 10 GiB für eine einzelne Filestore-Freigabe.
  • Datenzugriffsmodi und Isolation: wie die Plattform Arbeitsbereichsisolation und gemeinsame Arbeitsbereiche unterstützen soll. Dadurch wird bestimmt, ob Ihre Agenten private isolierte Arbeitsbereiche (ReadWriteOnce), gemeinsame Arbeitsbereiche (ReadWriteMany) oder Arbeitsbereiche für die explorative Verzweigung (schreibgeschützte Vorlage mit einem beschreibbaren Scratchpad) benötigen.
  • Ausfallsicherheit: Wenn Ihre Agenten speziell regionale Ausfallsicherheit erfordern, Filestore Multishares für GKE (Enterprise) ist die richtige Wahl.
  • Speicherkosten: Die Preise für Speicherdienste variieren erheblich. Hyperdisk Balanced bietet im Vergleich zu Filestore Multishares eine kostengünstige Option.

Lebenszyklusmuster für Agentendaten

Wenn Sie entscheiden, wie Ihre Lösung mit nichtflüchtigen und flüchtigen Daten umgeht, berücksichtigen Sie die folgenden Lebenszyklusmuster für Agentendaten:

  • Zustandsorientierter Arbeitsbereich (kontinuierlicher Zustand): Der Arbeitsbereich behält einen kontinuierlichen Zustand über Sitzungen hinweg bei. Der Agent behält seine Daten bei, wenn er pausiert wird (die Agent Sandbox wird gelöscht), und stellt diese Daten aus dem zuletzt gespeicherten Zustand wieder her, wenn er reaktiviert wird (die Sandbox wird neu erstellt).
  • Wiederherstellung zu einem bestimmten Zeitpunkt und Übertragung der Inhaberschaft (Snapshot-Zustand): der Arbeitsbereich fungiert als Snapshot-Zustand, d. h., er verzweigt sich von einem eingefrorenen Zeitpunkt ab. Der Arbeitsbereich wird aus einem historischen Dataset oder dem freigegebenen Zustand eines anderen Nutzers initialisiert, um eine Übertragung der Inhaberschaft auszuführen. Nachfolgende Änderungen werden in einer separaten, privaten beschreibbaren Ebene gespeichert, sodass die Masterkopie unverändert bleibt. Dieses Muster ist nützlich für Szenarien wie das Klonen eines Datasets, um parallele Experimente durchzuführen, Fehler zu beheben oder unabhängig von freigegebenen Daten zu arbeiten.
  • Flüchtiger Arbeitsbereich (Scratch-Zustand): Der Arbeitsbereich bietet einen temporären Scratch-Zustand, in dem keine Daten gespeichert werden. Der Agent verwendet ein Speichervolume ausschließlich zum Speichern temporärer Dateien, während er aktiv ist. Wenn der Agent pausiert oder gelöscht wird (Löschen der Agent Sandbox), werden die temporären Daten dauerhaft verworfen.

Modi für den Datenzugriff von Agenten

Wählen Sie einen Speicherdienst aus, der die Anforderungen Ihrer Agenten unterstützt, wenn sie in einem der folgenden Modi für den Datenzugriff auf Speicher zugreifen müssen:

  • Privater isolierter Arbeitsbereich: Ein Agent wird mit einem privaten isolierten Speicherverzeichnis gestartet, auf das er allein Lese- und Schreibzugriff hat.
  • Gemeinsamer Arbeitsbereich: Mehrere koordinierende Agenten stellen dasselbe freigegebene Verzeichnis im Lese-/Schreibmodus bereit, um Dateien in Echtzeit gemeinsam zu aktualisieren.
  • Arbeitsbereich für die explorative Verzweigung: Der Agent greift im schreibgeschützten Modus auf Vorlagendateien zu, um die Vorlage nicht zu ändern. Neue Schreibvorgänge werden entweder an ein separates lokales emptyDir Scratchpad oder einen privaten nichtflüchtigen Pfad weitergeleitet oder die Vorlagendateien werden beim Start direkt in einen privaten beschreibbaren Arbeitsbereich kopiert.

Speicheroptionen für die Agent Sandbox in GKE vergleichen

Berücksichtigen Sie die folgenden Szenarien, um Ihre Speicheroptionen zu vergleichen:

  • Verwenden Sie Hyperdisk Balanced für kostengünstigen Speicher für Agenten, die eine Startlatenz von einigen Sekunden tolerieren und einen privaten isolierten Arbeitsbereich mit dem Zugriffsmodus ReadWriteOnce (RWO) verwenden.
  • Verwenden Sie Filestore Multishares für GKE (Enterprise) für Agenten, die einen gemeinsamen Arbeitsbereich oder regionale Ausfallsicherheit benötigen.

In der folgenden Tabelle werden Speicherdienste verglichen, damit Sie die Anforderungen an Leistung, Skalierung, Datenzugriff und Kosten Ihrer KI-Agenten erfüllen können.

Funktion Hyperdisk abgestimmt Filestore Multishares für GKE (Enterprise)
Optimal für
  • Individuelle Arbeitsbereiche mit dem Zugriffsmodus ReadWriteOnce (RWO)
  • Arbeitslasten, die eine Anfügelatenz von mehreren Sekunden tolerieren
  • Kosteneffizienz
  • Direkte Sandbox-Erstellung
  • Gemeinsame Arbeitsbereiche mit dem Zugriffsmodus ReadWriteMany (RWX)
  • Arbeitslasten, die eine Anfügelatenz von weniger als einer Sekunde erfordern
  • Regionale Ausfallsicherheit
Zugriffsmodi ReadWriteOnce (RWO)

Hinweis: Verwenden Sie Hyperdisk ML für den Modus ReadOnlyMany (ROX). 		ReadWriteMany (RWX)
Start der Agent Sandbox in GKE in weniger als einer Sekunde (Warm Pools)
  • Flüchtiger Arbeitsbereich:Beim Erstellen kann ein leeres Volume vorab angefügt und nach Ende der aktiven Sitzung gelöscht werden.
  • Zustandsorientierter Arbeitsbereich oder Wiederherstellung zu einem bestimmten Zeitpunkt: Erfordert benutzerdefinierte Skripts und ein DaemonSet für die dynamische Volumebindung (Beispiel auf GitHub).
  • Flüchtiger Arbeitsbereich:Beim Erstellen kann ein leeres Volume vorab angefügt und nach Ende der aktiven Sitzung gelöscht werden.
  • Zustandsorientierter Arbeitsbereich oder Wiederherstellung zu einem bestimmten Zeitpunkt: Erfordert benutzerdefinierte Skripts und ein DaemonSet für die dynamische Volumebindung (Beispiel auf GitHub).
Latenz bei der Speicherbereitstellung Mehrere Sekunden pro Volume
  • Sechs Minuten, um eine Instanz mit bis zu 80 Freigaben zu erstellen
  • Mehrere Instanzen können parallel erstellt werden
Latenz beim Anfügen und Bereitstellen von Hot-Path-Speicher Mehrere Sekunden für das Anfügen von Laufwerken Weniger als eine Sekunde für die NFS-Bereitstellung im Netzwerk
Maximaler Lesedurchsatz
  • 2.400 MiB/s pro Laufwerk
  • Der Durchsatz ist durch das physische Hardwarelimit des angefügten Geräts begrenzt.
  • 120 MiB/s pro 1 TiB bereitgestellter Kapazität
  • Der Durchsatz ist auf 1.200 MiB/s für eine Multishares-Instanz mit maximaler Kapazität von 10 TiB begrenzt.
IOPS Zwischen 3.000 und 160.000, je nach Volume-Größe und Konfiguration
  • Lese-IOPS:12.000 Lese-IOPS pro 1 TiB Instanzkapazität (maximal 120.000 Lese-IOPS)
  • Schreib-IOPS:4.000 Schreib-IOPS pro 1 TiB Instanzkapazität (maximal 40.000 Schreib-IOPS)
Größenlimits
  • Pro Laufwerk: mindestens 4 GiB, maximal 64 TiB (128 TiB auf C4)
  • Pro Knoten: maximal 247 TiB für weniger als 32 vCPUs oder 512 TiB für 32 oder mehr vCPUs
Skalierungslimits
  • Pro Knoten:keine Anfügelimits
  • Pro Multishares-Instanz:maximal 80 Freigaben und bis zu 20.000 Verbindungen (2.000 pro 1 TiB, Skalierung in Schritten von 500)
Richtung der Kapazitätsskalierung Nur vertikale Skalierung Vertikale und horizontale Skalierung
Unterstützung für CSI VolumeSnapshot Unterstützt Nicht unterstützt (Snapshots pro Freigabe werden nicht unterstützt)
Preis Preise für Persistent Disk und Google Cloud Hyperdisk Filestore-Preise

Nächste Schritte