Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Praktik terbaik penyimpanan untuk workload AI/ML di VM TPU

Untuk memaksimalkan performa dan efisiensi biaya workload AI/ML Anda di VM TPU, pilih dan konfigurasi solusi penyimpanan yang tepat untuk workload Anda. Dengan menghilangkan hambatan I/O, Anda dapat mengurangi 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, pembuatan titik pemeriksaan, penayangan, dan penyiapan cache di VM TPU. Sebelum menerapkan praktik ini, tinjau Opsi penyimpanan untuk data TPU yang tersedia. 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	Gunakan bucket regional Cloud Storage dengan Cache Cepat dan penyesuaian sisi klien (seperti pembacaan baca-dahulu) untuk biaya terendah. Gunakan Bucket Cepat Cloud Storage untuk performa dan skala terbaik. Gunakan Managed Lustre jika Anda menstandardisasi 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 profil `gcsfusecsi-training`. Untuk Managed Lustre, pertimbangkan untuk menggunakan tingkat Dinamis guna mengurangi biaya dan mengoptimalkan performa secara otomatis.
Checkpointing dan bobot reinforcement learning	Gunakan Managed Lustre untuk performa tinggi tanpa penyesuaian ekstensif untuk persyaratan latensi rendah (kurang dari 1 md), seperti checkpoint sinkron dan propagasi bobot berkecepatan tinggi untuk reinforcement learning. Gunakan Bucket Cepat Cloud Storage untuk throughput tertinggi untuk checkpointing asinkron dan bertingkat serta memparalelkan operasi checkpoint ke penyimpanan. Rapid Bucket menyediakan throughput tinggi yang diperlukan untuk workload ini.	Untuk Rapid Bucket, gunakan profil `gcsfusecsi-checkpointing`.
Penyimpanan dan download model	Gunakan Hyperdisk ML untuk penyimpanan dalam cache model kecil dan hingga 2.500 instance. Gunakan solusi penyimpanan yang sama dengan yang Anda gunakan untuk set data pelatihan (Managed Lustre, Rapid Bucket, atau bucket regional) jika Anda ingin menyeragamkan satu solusi penyimpanan.	Untuk mendownload model, gunakan GKE Run:ai Model Streamer atau Cloud Storage FUSE dengan direktori pemasangan terpisah menggunakan profil `gcsfusecsi-serving`.
Offload cache nilai kunci (KV)	Selalu gunakan memori CPU host (RAM) sebagai tingkat utama untuk mengosongkan VRAM tanpa menambahkan latensi yang signifikan. Jika memori CPU tidak mencukupi, gunakan Managed Lustre sebagai tingkat kedua paralel dengan latensi rendah dalam hierarki cache untuk memenuhi kebutuhan latensi sangat rendah (kurang dari 1 md) pada 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 modifikasi jalur dan folder objek, bukan membaca atau menulis konten file itu sendiri.

Di bucket tanpa namespace hierarkis yang diaktifkan, folder tidak ada sebagai resource yang 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 diselesaikan dengan cepat.
QPS awal yang lebih tinggi: Namespace hierarkis mendukung hingga delapan kali kueri per detik (QPS) awal yang lebih tinggi untuk operasi baca dan tulis dibandingkan dengan bucket tanpa namespace hierarkis yang diaktifkan. Hal ini mencegah hambatan ketika banyak TPU mengakses penyimpanan secara bersamaan.
Operasi tingkat folder yang efisien: Menemukan dan mencantumkan file dalam direktori tertentu menjadi jauh lebih cepat, sehingga mengurangi waktu respons selama pelatihan dan pemuatan data.

Bucket zonal, yang ditawarkan melalui Bucket Cepat, 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 dengan menggunakan skrip startup atau dengan membuat image kustom. Menyesuaikan disk boot berguna untuk skenario berikut:

Memuat software dan library sebelumnya: Instal framework ML, dependensi, atau software kustom tertentu untuk mengurangi waktu mulai VM dan memastikan lingkungan yang konsisten.
Menggunakan distribusi OS non-standar: Menggunakan distribusi atau versi OS yang tidak termasuk 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 mengambil 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:

Minimalkan modifikasi disk booting: Jika memungkinkan, instal aplikasi dan simpan data di volume Persistent Disk atau Hyperdisk, bukan memodifikasi disk booting secara besar-besaran.
Gunakan UUID untuk pemasangan: Saat menambahkan entri ke file /etc/fstab, selalu gunakan UUID untuk mengidentifikasi disk dan partisi (UUID=...), bukan nama perangkat seperti /dev/sdb1. Nama perangkat yang dibuat secara otomatis tidak dijamin stabil di seluruh proses mulai ulang.

Ikuti rekomendasi berikut untuk mengurangi risiko kegagalan booting saat melakukan perubahan sistem:

Penanganan error: Terapkan pemeriksaan error yang andal dan mode kegagalan yang cermat dalam skrip Anda. Mencatat 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. Kesalahan sintaksis atau entri yang salah dapat menyebabkan 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 memerlukan waktu lebih lama untuk dilampirkan 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 image tersebut tepercaya dan kompatibel dengan image OS dasar. Pahami dependensi paket yang Anda instal dan potensi dampaknya pada library sistem.
Ruang penyimpanan disk: Pantau penggunaan disk boot. Logging yang ekstensif atau penginstalan software yang besar dapat mengisi boot disk, sehingga mencegah VM dimulai.
Logging: Konfigurasi aplikasi dan skrip Anda untuk mencatat log secara verbose ke serial console, karena ini adalah alat utama untuk mendiagnosis masalah booting pada VM TPU.

Merencanakan kapasitas penyimpanan Anda

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

Perkiraan penyimpanan

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

Jenis workload	Penyimpanan set data	Penyimpanan checkpoint
Pelatihan awal 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

Estimasi bandwidth checkpoint

Anda dapat memperkirakan bandwidth pembuatan titik pemeriksaan minimum yang diperlukan untuk beban kerja pelatihan menggunakan formula berikut. Untuk pembacaan data, beberapa proses pelatihan, atau pelatihan dan inferensi, tingkatkan perkiraan persyaratan bandwidth Anda secara proporsional.

Ukuran titik pemeriksaan: 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.
Interval checkpoint: Seberapa sering Anda menyimpan checkpoint (misalnya, setiap 15 menit).
Bandwidth yang diperlukan: Ukuran checkpoint ÷ interval checkpoint.

Contoh berikut menunjukkan cara memperkirakan bandwidth pembuatan titik pemeriksaan minimum untuk Qwen3-72B:

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

Resep referensi

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

Inferensi TPU7x:
- Resep Cloud Storage
- Resep Managed Lustre
Pelatihan TPU7x:

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 dibatasi.

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