Memilih penyimpanan untuk workload agentik AI

Dokumen ini membantu Anda memilih opsi penyimpanan yang sesuai untuk agen AI berdasarkan kebutuhan siklus proses data dan persyaratan latensi tertentu.

Untuk mengetahui detail implementasinya, lihat Mengelola penyimpanan Agent Sandbox.

Pertimbangan untuk memilih solusi penyimpanan

Saat memilih solusi penyimpanan untuk agen AI, Anda harus mempertimbangkan persyaratan platform agen, seperti performa dan skala, serta persyaratan pengelolaan data agen.

Persyaratan platform

Evaluasi persyaratan operasional dan arsitektur platform berikut:

  • Skala platform dan frekuensi churn agen (bidang kontrol): jumlah agen serentak, dan jumlah agen yang dibuat, dijeda, diaktifkan kembali, dan dihapus per menit. Platform yang membuat ribuan agen per menit atau menjeda agen yang tidak aktif memerlukan penyimpanan dengan operasi pemasangan dan penghubungan latensi rendah pada skala yang signifikan (misalnya, Filestore dipasang lebih cepat daripada Hyperdisk dapat dihubungkan).
  • Ukuran set data dan latensi pemuatan (bidang data): agen yang memuat set data multi-gigabyte atau library yang berat (seperti paket Node.js atau Python ) selama startup memerlukan performa I/O penyimpanan yang tinggi untuk membaca data dalam hitungan detik (misalnya, Hyperdisk menawarkan throughput baca per disk yang tinggi).
  • Latensi cold-start dan aktivasi ulang agen: latensi yang diharapkan, seperti sub-detik atau multi-detik. Untuk mencapai latensi startup sub-detik, Anda harus menggunakan GKE Agent Sandbox Warm Pools. Penggunaan langsung pembuatan sandbox umumnya menimbulkan penundaan multi-detik untuk startup Pod dan lampiran disk dinamis.
  • Ukuran penyimpanan per agen: bergantung pada layanan yang dipilih, Anda harus mengakomodasi batas penyediaan, seperti ukuran minimum 4 GiB untuk Google Cloud Hyperdisk atau minimum 10 GiB untuk satu bagian Filestore.
  • Mode akses dan isolasi data: cara platform mendukung isolasi ruang kerja dan ruang kerja kolaboratif. Hal ini menentukan apakah agen Anda memerlukan ruang kerja terisolasi pribadi (ReadWriteOnce), ruang kerja kolaboratif (ReadWriteMany), atau ruang kerja percabangan eksplorasi (template Hanya Baca dengan notepad yang dapat ditulis).
  • Ketahanan: jika agen Anda secara khusus memerlukan ketahanan regional, Multishare Filestore untuk GKE (Enterprise) adalah pilihan yang tepat.
  • Biaya penyimpanan: layanan penyimpanan sangat bervariasi dalam harga, dengan Hyperdisk Balanced menawarkan opsi yang hemat biaya dibandingkan dengan Multishare Filestore.

Pola siklus proses data agen

Saat Anda memutuskan cara solusi menangani data persisten dan sementara, pertimbangkan pola siklus proses data agen berikut:

  • Ruang kerja stateful (status berkelanjutan): ruang kerja mempertahankan status berkelanjutan di seluruh sesi. Agen mempertahankan datanya saat dijeda (Agent Sandbox dihapus) dan memulihkan data tersebut dari status tersimpan terbaru saat diaktifkan kembali (Sandbox dibuat ulang).
  • Pemulihan dan transfer kepemilikan point-in-time (status snapshot): ruang kerja bertindak sebagai status snapshot, yang berarti ruang kerja bercabang dari titik waktu yang dibekukan. Ruang kerja diinisialisasi dari set data historis atau status bersama pengguna lain, untuk menjalankan transfer kepemilikan. Modifikasi berikutnya disimpan ke lapisan yang dapat ditulis pribadi yang terpisah, sehingga salinan utama tidak tersentuh. Pola ini berguna untuk skenario seperti meng-clone set data untuk menjalankan eksperimen paralel, melakukan proses debug, atau melakukan pekerjaan independen berdasarkan data yang dibagikan.
  • Ruang kerja sementara (status awal): ruang kerja menyediakan status awal sementara yang tidak menyimpan data. Agen menggunakan volume penyimpanan secara ketat untuk menyimpan file sementara saat aktif. Saat agen dijeda atau dihapus (penghapusan Agent Sandbox), data sementara akan dihapus secara permanen.

Mode akses data agen

Pilih layanan penyimpanan yang mendukung kebutuhan agen Anda jika agen tersebut perlu mengakses penyimpanan dalam salah satu mode akses data berikut:

  • Ruang kerja terisolasi pribadi: agen dimulai dengan direktori penyimpanan terisolasi pribadi yang memiliki akses baca dan tulis tunggal.
  • Ruang kerja kolaboratif: beberapa agen yang berkoordinasi memasang direktori bersama yang sama persis dalam mode Baca-Tulis (RW) untuk mengupdate file secara kolaboratif secara real time.
  • Ruang kerja percabangan eksplorasi: agen mengakses file template dasar dalam mode Hanya Baca (RO) untuk menghindari perubahan template, dan membuat penulisan baru dengan merutekannya ke notepad lokal emptyDir yang terpisah atau jalur persisten pribadi atau dengan menyalin file template langsung ke ruang kerja yang dapat ditulis pribadi saat startup.

Membandingkan opsi penyimpanan untuk Agent Sandbox

Pertimbangkan skenario berikut untuk membantu Anda membandingkan opsi penyimpanan:

  • Gunakan Hyperdisk Balanced untuk penyimpanan yang hemat biaya bagi agen yang mentolerir latensi startup beberapa detik dan menggunakan ruang kerja terisolasi pribadi dengan mode akses ReadWriteOnce (RWO).
  • Gunakan Multishare Filestore untuk GKE (Enterprise) bagi agen yang memerlukan ruang kerja kolaboratif atau ketahanan regional.

Tabel berikut membandingkan layanan penyimpanan untuk membantu Anda memenuhi persyaratan performa, skala, akses data, dan biaya agen AI.

Fitur Hyperdisk Balanced Multishare Filestore untuk GKE (Enterprise)
Paling cocok untuk
  • Ruang kerja individual dengan mode akses ReadWriteOnce (RWO)
  • Workload yang mentolerir latensi penghubungan penyimpanan multi-detik
  • Efisiensi biaya
  • Pembuatan Sandbox langsung
  • Ruang kerja kolaboratif dengan mode akses ReadWriteMany (RWX)
  • Workload yang memerlukan latensi penghubungan penyimpanan sub-detik
  • Ketahanan regional
Mode akses ReadWriteOnce (RWO)

Catatan: Gunakan Hyperdisk ML untuk mode ReadOnlyMany (ROX). 		ReadWriteMany (RWX)
Startup Agent Sandbox sub-detik (Warm Pools)
  • Ruang kerja sementara: volume kosong dapat dilampirkan sebelumnya saat pembuatan dan dihancurkan setelah sesi aktif berakhir.
  • Ruang kerja stateful atau pemulihan point-in-time: memerlukan skrip kustom dan DaemonSet untuk binding volume dinamis (contoh di GitHub).
  • Ruang kerja sementara: volume kosong dapat dilampirkan sebelumnya saat pembuatan dan dihancurkan setelah sesi aktif berakhir.
  • Ruang kerja stateful atau pemulihan point-in-time: memerlukan skrip kustom dan DaemonSet untuk binding volume dinamis (contoh di GitHub).
Latensi penyediaan penyimpanan Beberapa detik per volume
  • Enam menit untuk membuat instance dengan hingga 80 bagian
  • Beberapa instance dapat dibuat secara paralel
Latensi penghubungan dan pemasangan jalur aktif Beberapa detik untuk penghubungan disk Sub-detik untuk pemasangan NFS Jaringan
Throughput baca maksimum
  • 2.400 MiB/dtk per disk
  • Throughput dibatasi oleh batas hardware fisik perangkat terlampir
  • 120 MiB/dtk per 1 TiB kapasitas yang disediakan
  • Throughput dibatasi pada 1.200 MiB/dtk untuk instance multishare 10 TiB kapasitas maksimum
IOPS Dari 3.000 hingga 160.000, bergantung pada ukuran dan konfigurasi volume
  • IOPS Baca: 12.000 IOPS Baca per 1 TiB kapasitas instance (maksimum 120.000 IOPS Baca)
  • IOPS Tulis: 4.000 IOPS Tulis per 1 TiB kapasitas instance (maksimum 40.000 IOPS Tulis)
Batas ukuran
  • Per disk: minimum 4 GiB, maksimum 64 TiB (128 TiB di C4)
  • Per node: maksimum 247 TiB untuk kurang dari 32 vCPU, atau 512 TiB untuk 32 vCPU atau lebih
Batas skala
  • Per node: tidak ada batas lampiran
  • Per instance multishare: maksimum 80 bagian, dan hingga 20.000 koneksi (2.000 per 1 TiB, penskalaan dengan penambahan 500)
Arah penskalaan kapasitas Hanya meningkatkan skala Meningkatkan atau menurunkan skala
Dukungan CSI VolumeSnapshot Didukung Tidak didukung (snapshot per bagian tidak didukung)
Harga Harga Persistent Disk dan Google Cloud Hyperdisk Harga Filestore

Langkah berikutnya