Praktik terbaik penyimpanan untuk workload AI/ML di VM TPU

Untuk memaksimalkan performa dan efisiensi biaya workload AI/ML di VM TPU, pilih dan konfigurasi solusi penyimpanan yang tepat untuk workload Anda. Dengan menghilangkan bottleneck I/O, Anda dapat mengurangi jumlah waktu saat akselerator TPU tidak ada aktivitas, sehingga mengurangi waktu dan biaya pelatihan.

Dokumen ini memberikan rekomendasi penyimpanan khusus workload dan praktik terbaik pengoptimalan untuk pelatihan, checkpointing, penyajian, dan caching di VM TPU. Sebelum menerapkan praktik ini, tinjau Opsi penyimpanan yang tersedia untuk data TPU. Dokumen ini mengasumsikan bahwa Anda sudah memahami VM TPU dan memiliki pengalaman dasar dalam menyediakan resource Cloud Storage.

Panduan khusus workload

Tabel berikut memberikan rekomendasi penyimpanan, yang tercantum dalam urutan preferensi, untuk berbagai workload:

Workload Rekomendasi Pengoptimalan dan alat (jika berlaku)
Set data pelatihan, termasuk persiapan data
  1. Gunakan bucket regional Cloud Storage dengan Rapid Cache dan penyesuaian sisi klien (seperti pembacaan read-ahead) untuk biaya terendah.
  2. Gunakan Rapid Bucket Cloud Storage untuk performa dan skala terbaik.
  3. Gunakan Managed Lustre jika Anda melakukan standarisasi pada Lustre (penyimpanan sistem file) karena konkurensi metadata yang tinggi atau file kecil (kurang dari 1 MB).
  • Untuk bucket Cloud Storage regional, aktifkan namespace hierarkis.
  • Untuk bucket Cloud Storage regional atau Rapid Bucket, gunakan Cloud Storage FUSE dan gRPC. Untuk GKE, gunakan gcsfusecsi-training profil.
  • Untuk Managed Lustre, pertimbangkan untuk menggunakan tingkat Dinamis guna mengurangi biaya dan mengoptimalkan performa secara otomatis.
Checkpointing dan bobot reinforcement learning
  1. Gunakan Managed Lustre untuk performa tinggi tanpa penyesuaian ekstensif untuk persyaratan latensi rendah (kurang dari 1 md), seperti checkpoint sinkron dan propagasi bobot kecepatan tinggi untuk reinforcement learning.
  2. Gunakan Rapid Bucket Cloud Storage untuk throughput tertinggi untuk checkpointing asinkron dan bertingkat serta operasi checkpoint paralel ke penyimpanan. Rapid Bucket menyediakan throughput tinggi yang diperlukan untuk workload ini.
Untuk Rapid Bucket, gunakan profil gcsfusecsi-checkpointing.
Penyimpanan dan download model
  1. Gunakan Hyperdisk ML untuk caching model kecil dan hingga 2.500 instance.
  2. Gunakan solusi penyimpanan yang sama dengan yang Anda gunakan untuk set data pelatihan (Managed Lustre, Rapid Bucket, atau bucket regional) jika Anda ingin melakukan standarisasi pada satu solusi penyimpanan.
Untuk mendownload model, gunakan GKE Run:ai Model Streamer atau Cloud Storage FUSE dengan direktori pemasangan terpisah menggunakan gcsfusecsi-serving profil.
Pengalihan cache nilai kunci (KV)
  1. Selalu gunakan memori CPU host (RAM) sebagai tingkat utama untuk mengosongkan VRAM tanpa menambahkan latensi yang signifikan.
  2. Jika memori CPU tidak mencukupi, gunakan Managed Lustre sebagai tingkat kedua paralel, latensi rendah dalam hierarki cache untuk memenuhi kebutuhan latensi ultra-rendah (kurang dari 1 md) pengalihan cache KV dengan throughput tinggi (hingga 10 TB/dtk).

Pengoptimalan Cloud Storage

Bagian berikut menjelaskan praktik terbaik untuk mengoptimalkan performa saat menggunakan Cloud Storage dengan VM TPU.

Mengaktifkan namespace hierarkis untuk pengoptimalan metadata

Untuk meningkatkan performa metadata, aktifkan namespace hierarkis saat Anda membuat bucket regional untuk workload AI/ML. Performa metadata mengacu pada seberapa cepat Cloud Storage dapat memproses operasi yang melibatkan pencarian, pencantuman, atau pengubahan jalur dan folder objek, bukan membaca atau menulis konten file itu sendiri.

Di bucket tanpa namespace hierarkis yang diaktifkan, folder tidak ada sebagai resource sebenarnya, tetapi merupakan folder simulasi yang diwakili oleh awalan nama objek yang dibatasi oleh garis miring (/). Hal ini membuat operasi seperti mencantumkan konten direktori atau mengganti nama direktori menjadi lambat karena sistem harus memindai semua objek dengan awalan tersebut. Namespace hierarkis menyediakan struktur sistem file yang sebenarnya, yang penting untuk workload AI/ML karena beberapa alasan:

  • Penggantian nama direktori atomik: Framework ML menggunakan penggantian nama direktori untuk menyelesaikan checkpoint. Namespace hierarkis mendukung penggantian nama atomik, sehingga checkpoint dapat diselesaikan dengan cepat.
  • QPS awal yang lebih tinggi: Namespace hierarkis mendukung kueri per detik (QPS) awal yang hingga delapan kali lebih tinggi untuk pembacaan dan penulisan dibandingkan dengan bucket tanpa namespace hierarkis yang diaktifkan. Hal ini mencegah bottleneck saat banyak TPU mengakses penyimpanan secara bersamaan.
  • Operasi tingkat folder yang efisien: Menemukan dan mencantumkan file dalam direktori tertentu jauh lebih cepat, sehingga mengurangi waktu respons selama pelatihan dan pemuatan data.

Bucket zona, yang ditawarkan melalui Rapid Bucket, menggunakan namespace hierarkis secara default. Untuk mengetahui informasi selengkapnya, lihat Ringkasan namespace hierarkis.

Menggunakan Cloud Storage FUSE dengan profil yang sesuai

Cloud Storage FUSE adalah adaptor FUSE yang memungkinkan Anda memasang bucket sebagai sistem file lokal. Saat menggunakan Google Kubernetes Engine, sebaiknya gunakan driver CSI Cloud Storage FUSE dan profil Cloud Storage FUSE untuk mengotomatiskan penyesuaian performa.

Untuk mengetahui informasi selengkapnya tentang praktik terbaik penggunaan Cloud Storage FUSE, lihat Praktik terbaik penyesuaian performa.

Menyesuaikan boot disk VM TPU

Anda dapat menyesuaikan lingkungan OS tamu di VM TPU menggunakan skrip startup atau dengan membuat image kustom. Menyesuaikan boot disk berguna untuk skenario berikut:

  • Memuat software dan library secara otomatis: Instal framework ML, dependensi, atau software kustom tertentu untuk mengurangi waktu startup VM dan memastikan lingkungan yang konsisten.
  • Menggunakan distribusi OS non-standar: Gunakan distribusi atau versi OS yang tidak disertakan dalam daftar yang dikelola Google.
  • Menerapkan konfigurasi keamanan dan pemantauan: Terapkan setelan keamanan kustom, instal agen pemantauan, atau tetapkan variabel lingkungan.

Namun, pemulihan boot disk untuk VM TPU terbatas. Anda tidak dapat melepaskan atau membuat snapshot boot disk untuk perbaikan offline, jadi berhati-hatilah saat membuat perubahan yang memengaruhi proses booting. Dengan mengikuti praktik terbaik ini, Anda dapat mengurangi risiko kegagalan booting saat menyesuaikan lingkungan VM TPU.

Perhatikan prinsip-prinsip utama berikut saat menyesuaikan boot disk:

  • Meminimalkan modifikasi boot disk: Jika memungkinkan, instal aplikasi dan simpan data di volume Persistent Disk atau Hyperdisk , bukan memodifikasi boot disk secara besar-besaran.

  • Menggunakan UUID untuk pemasangan: Saat menambahkan entri ke file /etc/fstab, selalu gunakan UUID untuk mengidentifikasi disk dan partisi (UUID=...) dan bukan nama perangkat seperti /dev/sdb1. Nama perangkat yang dibuat secara otomatis tidak dijamin stabil di seluruh reboot.

Ikuti rekomendasi ini untuk mengurangi risiko kegagalan booting saat membuat perubahan sistem:

  • Penanganan error: Terapkan pemeriksaan error yang andal dan mode kegagalan yang lancar dalam skrip Anda. Catat pesan mendetail ke konsol serial dan Cloud Logging untuk membantu proses debug.

  • Dependensi penting: Berhati-hatilah saat mengubah file yang penting untuk booting, seperti file /etc/fstab, konfigurasi jaringan, atau setelan bootloader. Error sintaksis atau entri yang salah dapat membuat VM tidak dapat di-boot.

  • Disk sekunder: Jika skrip Anda bergantung pada disk sekunder, pastikan skrip tersebut menangani kasus saat disk mungkin tidak ada atau membutuhkan waktu lebih lama untuk dipasang dari yang diharapkan. Hindari membuat proses booting sangat bergantung pada pemasangan disk sekunder kecuali jika benar-benar diperlukan.

    Berikut adalah contoh entri /etc/fstab yang direkomendasikan dan tidak direkomendasikan untuk memasang disk sekunder:

    • Direkomendasikan: UUID=a1b2c3d4-e5f6-7890-1234-567890abcdef /mnt/mydata ext4 defaults,nofail 0 2
    • Tidak direkomendasikan: /dev/sdb1 /mnt/mydata ext4 defaults 0 2

    Menggunakan opsi nofail dapat mencegah sistem berhenti jika disk tidak ditemukan, tetapi pastikan aplikasi Anda dapat menangani direktori pemasangan yang tidak tersedia.

  • Pengelolaan paket: Berhati-hatilah saat menambahkan repositori pihak ketiga. Pastikan repositori tersebut tepercaya dan kompatibel dengan image OS dasar. Pahami dependensi paket yang Anda instal dan potensi dampaknya pada library sistem.

  • Ruang disk: Pantau penggunaan boot disk. Logging ekstensif atau penginstalan software besar dapat mengisi boot disk, sehingga mencegah VM dimulai.

  • Logging: Konfigurasi aplikasi dan skrip Anda untuk mencatat secara detail ke konsol serial, karena ini adalah alat utama untuk mendiagnosis masalah booting di VM TPU.

Merencanakan kapasitas penyimpanan

Penting untuk merencanakan jumlah kapasitas penyimpanan yang akan dibutuhkan workload Anda untuk memanfaatkan akselerator sepenuhnya. Hal ini mencakup kapasitas penyimpanan dan bandwidth checkpoint.

Memperkirakan penyimpanan

Anda dapat menggunakan perkiraan berikut sebagai titik awal untuk persyaratan penyimpanan:

Jenis workload Penyimpanan set data Penyimpanan checkpoint
Pra-pelatihan LLM 2 TB per TPU 200 GB per TPU
Pelatihan multimodal 12 TB per TPU 1 TB per TPU
Inferensi 1 TB per TPU 1 GB per TPU

Memperkirakan bandwidth checkpoint

Anda dapat memperkirakan bandwidth checkpoint minimum yang diperlukan untuk workload pelatihan menggunakan rumus berikut. Untuk pembacaan data, beberapa proses pelatihan, atau pelatihan dan inferensi, tingkatkan persyaratan bandwidth yang diperkirakan secara proporsional.

  1. Ukuran checkpoint: Jumlah parameter × byte per parameter (sekitar 12-16 byte per parameter untuk FP16 + status pengoptimal). Tambahkan buffer (sekitar 3×) untuk status pengoptimal dan presisi yang berbeda.
  2. Interval checkpoint: Seberapa sering Anda menyimpan checkpoint (misalnya, setiap 15 menit).
  3. Bandwidth yang diperlukan: Ukuran checkpoint ÷ interval checkpoint.

Contoh berikut menunjukkan cara memperkirakan bandwidth checkpoint minimum untuk Qwen3-72B:

  1. Ukuran checkpoint: 72B parameter × 12 byte ≈ 864 GB per checkpoint. Dengan buffer, 3 × 864 GB ≈ 2,5 TB.
  2. Interval checkpoint: 2 menit = 120 detik.
  3. Bandwidth yang diperlukan: 2,5 TB ÷ 120 detik ≈ 20 GBps.

Resep referensi

Untuk contoh konfigurasi penyimpanan untuk hardware dan workload tertentu, lihat resep berikut:

Kuota dan batas bandwidth

Bandwidth untuk penawaran Cloud Storage dan Compute Engine dibatasi oleh kuota default. Jika Anda melampaui kuota, permintaan input dan output Anda mungkin akan dibatasi.

Untuk mengetahui informasi tentang kuota Cloud Storage dan cara meminta peningkatan, lihat Kuota & batas dalam dokumentasi Cloud Storage. Untuk mengetahui informasi tentang kuota Compute Engine untuk Hyperdisk dan Persistent Disk, lihat Kuota disk.

Langkah berikutnya