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 Anforderungen an den Datenlebenszyklus und die Latenz basiert.

Einzelheiten zur Implementierung finden Sie unter Speicher für die Agent Sandbox verwalten.

Überlegungen bei der 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 Ihrer Agenten an die Datenverwaltung.

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 pro Minute Tausende von Agenten erstellt oder inaktive Agenten pausiert werden, erfordern Speicher mit Anfüge- und Bereitstellungsvorgängen mit geringer Latenz bei erheblicher Skalierung (z. B. wird Filestore schneller bereitgestellt als Hyperdisk angefügt werden kann).
  • Dataset-Größe und Latenz beim Laden (Datenebene): Agenten, die beim Starten 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 Mehrsekundenbereich. Um eine Startlatenz im Subsekundenbereich zu erreichen, müssen Sie GKE Agent Sandbox-Warmpools verwenden. 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 Erkundung von Verzweigungen (schreibgeschützte Vorlage mit einem beschreibbaren Scratchpad) benötigen.
  • Resilienz: Wenn Ihre Agenten speziell regionale Resilienz 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 Eigentümerschaft (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 Eigentümerschaft 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 endgültig 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 Datenzugriffsmodi auf den 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 (RW) bereit, um Dateien gemeinsam in Echtzeit zu aktualisieren.
  • Arbeitsbereich für die Erkundung von Verzweigungen: Der Agent greift im schreibgeschützten Modus (RO) auf Basisvorlagendateien 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 Agent Sandboxes 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 Resilienz 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 Balanced Filestore Multishares für GKE (Enterprise)
Optimal für
  • Individuelle Arbeitsbereiche mit dem Zugriffsmodus ReadWriteOnce (RWO)
  • Arbeitslasten, die eine Speicheranfügelatenz von mehreren Sekunden tolerieren
  • Kosteneffizienz
  • Direkte Sandbox-Erstellung
  • Gemeinsame Arbeitsbereiche mit dem Zugriffsmodus ReadWriteMany (RWX)
  • Arbeitslasten, die eine Speicheranfügelatenz im Subsekundenbereich erfordern
  • Regionale Resilienz
Zugriffsmodi ReadWriteOnce (RWO)

Hinweis: Verwenden Sie Hyperdisk ML für den Modus ReadOnlyMany (ROX). 		ReadWriteMany (RWX)
Start der Agent Sandbox im Subsekundenbereich (Warmpools)
  • Flüchtiger Arbeitsbereich:Ein leeres Volume kann bei der Erstellung 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 Volume-Bindung (Beispiel auf GitHub).
  • Flüchtiger Arbeitsbereich:Ein leeres Volume kann bei der Erstellung 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 Volume-Bindung (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 des Hot Path Mehrere Sekunden für das Anfügen von Laufwerken Subsekunden 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 3.000 bis 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ößenbeschränkungen
  • 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 Beschränkungen für das Anfügen
  • 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 vertikal skalierbar Vertikal und horizontal skalierbar
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