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 spesifik mereka.

Untuk mengetahui detail implementasi, lihat Mengelola Agent Sandbox di penyimpanan GKE.

Pertimbangan untuk memilih solusi penyimpanan

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

Persyaratan platform

Evaluasi persyaratan operasional dan arsitektur berikut dari platform Anda:

  • 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 penyambungan berlatensi rendah dalam skala yang signifikan (misalnya, pemasangan Filestore lebih cepat daripada penyambungan Hyperdisk).
  • Ukuran set data dan latensi pemuatan (data plane): agen yang memuat set data multi-gigabyte atau library 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 reaktivasi agen: latensi yang diharapkan, seperti sub-detik atau multi-detik. Mencapai latensi startup di bawah satu detik memerlukan penggunaan Agent Sandbox di GKE Warm Pools. Menggunakan pembuatan sandbox langsung umumnya menimbulkan penundaan beberapa detik untuk startup Pod dan pemasangan 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 pembagian Filestore.
  • Mode akses dan isolasi data: cara platform harus mendukung isolasi ruang kerja dan ruang kerja kolaboratif. Hal ini menentukan apakah agen Anda akan memerlukan ruang kerja terisolasi pribadi (ReadWriteOnce), ruang kerja kolaboratif (ReadWriteMany), atau ruang kerja percabangan eksplorasi (template Hanya Baca dengan scratchpad 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 memiliki harga yang sangat bervariasi, dengan Hyperdisk Balanced menawarkan opsi yang hemat biaya dibandingkan dengan Filestore Multishare.

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 (Sandbox Agen dihapus) dan memulihkan data tersebut dari status tersimpan terbaru saat diaktifkan kembali (Sandbox dibuat ulang).
  • Pemulihan point-in-time dan transfer kepemilikan (status snapshot): ruang kerja bertindak sebagai status snapshot, yang berarti ruang kerja ini 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 terpisah yang dapat ditulis dan bersifat pribadi, sehingga salinan master tidak tersentuh. Pola ini berguna untuk skenario seperti meng-clone set data untuk menjalankan eksperimen paralel, proses debug, atau melakukan pekerjaan independen berdasarkan data yang dibagikan.
  • Ruang kerja sementara (status scratch): ruang kerja menyediakan status scratch sementara tempat tidak ada data yang dipertahankan. Agen menggunakan volume penyimpanan hanya untuk menyimpan file sementara saat aktif. Saat agen dijeda atau dihapus (penghapusan Sandbox Agen), data sementara akan dihapus secara permanen.

Mode akses data agen

Pilih layanan penyimpanan yang mendukung kebutuhan agen Anda jika mereka 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 koordinasi memasang direktori bersama yang sama persis dalam mode Baca-Tulis (RW) untuk memperbarui file secara real time secara kolaboratif.
  • 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 scratchpad emptyDir lokal terpisah atau jalur persisten pribadi atau dengan menyalin file template langsung ke ruang kerja pribadi yang dapat ditulis saat startup.

Membandingkan opsi penyimpanan untuk Sandbox Agen di GKE

Pertimbangkan skenario berikut untuk membantu Anda membandingkan opsi penyimpanan:

  • Gunakan Hyperdisk Balanced untuk penyimpanan hemat biaya bagi agen yang menoleransi 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 Anda.

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

Catatan: Gunakan Hyperdisk ML untuk mode ReadOnlyMany (ROX). 		ReadWriteMany (RWX)
Startup Sub-second Agent Sandbox di GKE (Warm Pools)
  • Ruang kerja sementara: volume kosong dapat dipasang sebelumnya saat pembuatan dan dihancurkan setelah sesi aktif berakhir.
  • Workspace stateful atau pemulihan point-in-time: memerlukan skrip kustom dan DaemonSet untuk pengikatan volume dinamis (contoh di GitHub).
  • Ruang kerja sementara: volume kosong dapat dipasang sebelumnya saat pembuatan dan dihancurkan setelah sesi aktif berakhir.
  • Workspace stateful atau pemulihan point-in-time: memerlukan skrip kustom dan DaemonSet untuk pengikatan volume dinamis (contoh di GitHub).
Latensi penyediaan penyimpanan Beberapa detik per volume
  • Enam menit untuk membuat instance dengan hingga 80 kali berbagi
  • Beberapa instance dapat dibuat secara paralel
Latensi pemasangan dan pengaitan jalur panas Beberapa detik untuk pemasangan disk Kurang dari satu detik untuk pemasangan Network NFS
Throughput baca maksimum
  • 2.400 MiB/dtk per disk
  • Throughput dibatasi oleh batas hardware fisik perangkat yang terpasang
  • 120 MiB/dtk per 1 TiB kapasitas yang disediakan
  • Throughput dibatasi pada 1.200 MiB/dtk untuk instance multishare 10 TiB berkapasitas 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 dalam inkremen 500)
Arah penskalaan kapasitas Hanya meningkatkan skala Meningkatkan atau menurunkan skala
Dukungan VolumeSnapshot CSI Didukung Tidak didukung (snapshot per-share tidak didukung)
Harga Harga Persistent Disk dan Google Cloud Hyperdisk Harga Filestore

Langkah berikutnya