Tentang penyediaan GPU dan TPU dengan mode penyediaan flex-start

Halaman ini menjelaskan mode penyediaan mulai fleksibel di Google Kubernetes Engine (GKE). Mulai fleksibel, yang didukung oleh Dynamic Workload Scheduler, memberikan teknik yang fleksibel dan hemat biaya untuk mendapatkan GPU dan TPU saat Anda perlu menjalankan workload AI/ML.

Dengan mulai fleksibel, Anda dapat menyediakan GPU dan TPU secara dinamis sesuai kebutuhan, hingga tujuh hari, tidak terikat pada waktu mulai tertentu, dan tanpa pengelolaan reservasi jangka panjang. Oleh karena itu, flex-start berfungsi dengan baik untuk workload berukuran kecil hingga sedang dengan persyaratan permintaan yang berfluktuasi atau durasi pendek. Misalnya, pra-pelatihan model kecil, penyesuaian model, atau model inferensi yang dapat diskalakan.

Informasi di halaman ini dapat membantu Anda melakukan hal berikut:

  • Pahami cara kerja mulai fleksibel di GKE.
  • Tentukan apakah mulai fleksibel cocok untuk workload Anda.
  • Tentukan konfigurasi mulai fleksibel yang tepat untuk workload Anda.
  • Mengelola gangguan saat menggunakan flex-start.
  • Pahami batasan flex-start di GKE.

Halaman ini ditujukan untuk Admin dan operator platform dan Engineer machine learning (ML) yang ingin mengoptimalkan infrastruktur akselerator untuk workload mereka.

Kapan harus menggunakan flex-start

Sebaiknya gunakan flex-start jika workload Anda memenuhi semua kondisi berikut:

  • Workload Anda memerlukan resource GPU.
  • Workload Anda memerlukan resource TPU yang berjalan di node pool slice TPU host tunggal.
  • Anda memiliki kapasitas GPU atau TPU yang dicadangkan terbatas atau tidak ada dan Anda memerlukan akses yang lebih andal ke akselerator ini.
  • Workload Anda fleksibel terhadap waktu dan kasus penggunaan Anda dapat menunggu untuk mendapatkan semua kapasitas yang diminta, misalnya, saat GKE mengalokasikan resource GPU di luar jam tersibuk.

Harga mulai fleksibel

Mulai fleksibel direkomendasikan jika workload Anda memerlukan penyediaan dinamis sumber daya sesuai kebutuhan, hingga tujuh hari dengan reservasi jangka pendek, tanpa pengelolaan kuota yang rumit, dan akses yang hemat biaya. Mulai fleksibel didukung oleh Dynamic Workload Scheduler dan ditagih menggunakan harga Dynamic Workload Scheduler:

  • Diskon (hingga 53%) untuk vCPU, GPU, dan TPU.
  • Anda membayar sesuai penggunaan.

Persyaratan

Untuk menggunakan mulai fleksibel di GKE, cluster Anda harus memenuhi persyaratan berikut:

  • Untuk menjalankan GPU, gunakan GKE versi 1.32.2-gke.1652000 atau yang lebih baru.

  • Untuk menjalankan TPU, gunakan GKE versi 1.33.0-gke.1712000 atau yang lebih baru. Mulai fleksibel mendukung versi dan zona berikut:

    • TPU Trillium (v6e) di asia-northeast1-b dan us-east5-a.
    • TPU v5e di us-west4-a.
    • TPU v5p di us-east5-a.

    TPU v3 dan v4 tidak didukung.

Cara kerja mode penyediaan mulai fleksibel

Dengan mulai fleksibel, Anda menentukan kapasitas GPU atau TPU yang diperlukan dalam workload. Selain itu, dengan cluster Standar, Anda mengonfigurasi mulai fleksibel pada node pool tertentu. GKE secara otomatis menyediakan VM dengan menyelesaikan proses berikut saat kapasitas tersedia:

  1. Workload meminta kapasitas yang tidak langsung tersedia. Permintaan ini dapat dilakukan langsung oleh spesifikasi beban kerja atau melalui alat penjadwalan seperti class komputasi kustom atau Kueue.
  2. GKE mengidentifikasi bahwa node Anda telah mengaktifkan flex-start dan workload dapat menunggu selama waktu yang tidak ditentukan.
  3. Autoscaler cluster menerima permintaan Anda dan menghitung jumlah node yang diperlukan, dengan memperlakukannya sebagai satu unit.
  4. Autoscaler cluster menyediakan node yang diperlukan saat tersedia. Node ini berjalan maksimal selama tujuh hari, atau selama durasi yang lebih singkat jika Anda menentukan nilai dalam parameter maxRunDurationSeconds. Parameter ini tersedia dengan GKE versi 1.28.5-gke.1355000 atau yang lebih baru. Jika Anda tidak menentukan nilai untuk parameter maxRunDurationSeconds, defaultnya adalah tujuh hari.
  5. Setelah waktu berjalan yang Anda tentukan dalam parameter maxRunDurationSeconds berakhir, node dan Pod akan dihentikan.
  6. Jika Pod selesai lebih cepat dan node tidak lagi digunakan, autoscaler cluster akan menghapusnya sesuai dengan profil penskalaan otomatis.

GKE menghitung durasi untuk setiap permintaan mulai fleksibel di tingkat node. Waktu yang tersedia untuk menjalankan Pod mungkin sedikit lebih kecil karena penundaan selama startup. Percobaan ulang Pod berbagi durasi ini, yang berarti lebih sedikit waktu yang tersedia untuk Pod setelah percobaan ulang. GKE menghitung durasi untuk setiap permintaan flex-start secara terpisah.

Konfigurasi mulai fleksibel

GKE mendukung konfigurasi mulai fleksibel berikut:

  • Mulai fleksibel, saat GKE mengalokasikan resource node demi node. Konfigurasi ini hanya mengharuskan Anda menetapkan tanda --flex-start selama pembuatan node.

  • Mulai fleksibel dengan penyediaan yang diantrekan, dengan GKE mengalokasikan semua resource yang diminta secara bersamaan. Untuk menggunakan konfigurasi ini, Anda harus menambahkan flag --flex-start dan enable-queued-provisioning saat membuat node pool. GKE mengikuti proses dalam Cara kerja mode penyediaan mulai fleksibel dalam dokumen ini, tetapi juga menerapkan kondisi berikut:

    • Scheduler menunggu hingga semua resource yang diminta tersedia dalam satu zona.
    • Semua Pod beban kerja dapat berjalan bersama di node yang baru disediakan.
    • Node yang disediakan tidak digunakan kembali di antara eksekusi beban kerja.

Tabel berikut membandingkan konfigurasi flex-start:

Flex-start Mulai fleksibel dengan penyediaan dalam antrean
Ketersediaan Pratinjau

Tersedia Secara Umum (GA)

Catatan: Mulai fleksibel mendukung tanda flex-start dan enable-queued-provisioning dalam Pratinjau.
Akselerator yang didukung
Ukuran beban kerja yang direkomendasikan Kecil hingga sedang, yang berarti workload dapat berjalan di satu node. Misalnya, konfigurasi ini berfungsi baik jika Anda menjalankan tugas pelatihan kecil, inferensi offline, atau tugas batch. Sedang hingga besar, yang berarti beban kerja dapat berjalan di beberapa node. Beban kerja Anda memerlukan beberapa resource dan tidak dapat mulai berjalan hingga semua node disediakan dan siap secara bersamaan. Misalnya, konfigurasi ini berfungsi dengan baik jika Anda menjalankan workload pelatihan machine learning terdistribusi.
Jenis penyediaan GKE menyediakan satu node dalam satu waktu saat resource tersedia. GKE mengalokasikan semua resource yang diminta secara bersamaan.
Kompleksitas penyiapan Tidak terlalu rumit. Konfigurasi ini mirip dengan VM sesuai permintaan dan Spot VM. Lebih kompleks. Sebaiknya gunakan alat pengelolaan kuota, seperti Kueue.
Dukungan class komputasi kustom Ya Tidak
Daur ulang node Ya Tidak
Harga SKU Flex Start SKU Flex Start
Kuota
Strategi upgrade node Upgrade berjangka pendek Upgrade berjangka pendek
Flag gcloud container node pool create --flex-start
  • --flex-start
  • --enable-queued-provisioning
Mulai GPU: TPU: Menjalankan workload berskala besar dengan mulai fleksibel dengan penyediaan dalam antrean

Mengoptimalkan konfigurasi flex-start

Untuk membuat infrastruktur AI/ML yang andal dan dioptimalkan biayanya, Anda dapat menggabungkan konfigurasi mulai fleksibel dengan fitur GKE yang tersedia. Sebaiknya gunakan Class Komputasi untuk menentukan daftar konfigurasi node yang diprioritaskan berdasarkan persyaratan workload Anda. GKE akan memilih konfigurasi yang paling sesuai berdasarkan ketersediaan dan prioritas yang Anda tetapkan.

Mengelola gangguan dalam workload yang menggunakan Dynamic Workload Scheduler

Workload yang memerlukan ketersediaan semua node, atau sebagian besar node, dalam node pool rentan terhadap pengusiran. Selain itu, node yang disediakan dengan menggunakan permintaan Dynamic Workload Scheduler tidak mendukung perbaikan otomatis. Perbaikan otomatis menghapus semua workload dari node, sehingga mencegahnya berjalan.

Semua node yang menggunakan mulai fleksibel, penyediaan dalam antrean, atau keduanya, menggunakan upgrade berdurasi singkat saat control plane cluster menjalankan versi minimum untuk mulai fleksibel, 1.32.2-gke.1652000 atau yang lebih baru.

Upgrade singkat mengupdate node pool Standard atau grup node dalam cluster Autopilot tanpa mengganggu node yang sedang berjalan. Node baru dibuat dengan konfigurasi baru, yang secara bertahap menggantikan node yang ada dengan konfigurasi lama dari waktu ke waktu. Versi GKE sebelumnya, yang tidak mendukung upgrade mulai fleksibel atau upgrade singkat, memerlukan praktik terbaik yang berbeda.

Praktik terbaik untuk meminimalkan gangguan workload untuk node yang menggunakan upgrade singkat

Node mulai fleksibel dan node yang menggunakan penyediaan dalam antrean dikonfigurasi secara otomatis untuk menggunakan upgrade berdurasi singkat saat cluster menjalankan versi 1.32.2-gke.1652000 atau yang lebih baru.

Untuk meminimalkan gangguan pada workload yang berjalan di node yang menggunakan upgrade singkat, lakukan tugas berikut:

Untuk node pada cluster yang menjalankan versi sebelum 1.32.2-gke.1652000, dan dengan demikian tidak menggunakan upgrade singkat, lihat panduan khusus untuk node tersebut.

Praktik terbaik untuk meminimalkan gangguan workload untuk node penyediaan dalam antrean tanpa upgrade singkat

Node yang menggunakan penyediaan dalam antrean di cluster yang menjalankan versi GKE yang lebih lama dari 1.32.2-gke.1652000 tidak menggunakan upgrade singkat. Cluster yang diupgrade ke 1.32.2-gke.1652000 atau yang lebih baru dengan node penyediaan dalam antrean yang ada akan otomatis diupdate untuk menggunakan upgrade singkat.

Untuk node yang menjalankan versi sebelumnya ini, lihat panduan berikut:

Pertimbangan saat cluster Anda dimigrasikan ke upgrade berdurasi singkat

GKE mengupdate node yang ada menggunakan penyediaan dalam antrean untuk menggunakan upgrade singkat saat cluster diupgrade ke versi 1.32.2-gke.1652000 atau yang lebih baru. GKE tidak mengupdate setelan lain, seperti mengaktifkan upgrade otomatis node jika Anda menonaktifkannya untuk node pool tertentu.

Sebaiknya terapkan praktik terbaik berikut sekarang karena kumpulan node Anda menggunakan upgrade singkat:

  • Jika Anda menonaktifkan upgrade otomatis node menggunakan flag --no-enable-autoupgrade, migrasi ini tidak akan mengaktifkan kembali upgrade otomatis node untuk node pool. Sebaiknya Anda mengaktifkan upgrade otomatis node, karena upgrade singkat tidak mengganggu node yang ada dan workload yang berjalan di node tersebut. Untuk mengetahui informasi selengkapnya, lihat Upgrade berdurasi singkat.
  • Sebaiknya, jika cluster Anda belum terdaftar di saluran rilis, daftarkan cluster Anda agar Anda dapat menggunakan cakupan pengecualian pemeliharaan yang lebih terperinci.

Daur ulang node di flex-start

Untuk membantu memastikan transisi node yang lancar dan mencegah periode nonaktif untuk tugas yang sedang berjalan, mulai fleksibel mendukung daur ulang node. Saat node mencapai akhir durasinya, GKE akan otomatis mengganti node tersebut dengan node baru untuk mempertahankan workload yang sedang berjalan.

Untuk menggunakan daur ulang node, Anda harus membuat profil class komputasi kustom dan menyertakan kolom nodeRecycling dalam spesifikasi flexStart dengan parameter leadTimeSeconds.

Parameter leadTimeSeconds memungkinkan Anda menyeimbangkan ketersediaan resource dan efisiensi biaya. Parameter ini menentukan seberapa awal (dalam detik) sebelum node mencapai akhir durasi tujuh harinya, proses penyediaan node baru harus dimulai untuk menggantikannya. Waktu tunggu yang lebih lama akan meningkatkan kemungkinan node baru siap sebelum node lama dihapus, tetapi dapat menimbulkan biaya tambahan.

Proses daur ulang node terdiri dari langkah-langkah berikut:

  1. Fase daur ulang: GKE memvalidasi bahwa node yang disediakan dengan flex-start memiliki kolom nodeRecycling dengan parameter leadTimeSeconds yang ditetapkan. Jika ya, GKE akan memulai fase daur ulang node saat tanggal saat ini lebih besar dari atau sama dengan selisih antara nilai dari kolom berikut:

    • creationTimestamp plus maxRunDurationSeconds
    • leadTimeSeconds

    Flag creationTimeStamp mencakup waktu saat node dibuat. Kolom maxRunDurationSeconds dapat ditentukan dalam kelas komputasi kustom, dan secara default adalah tujuh hari.

  2. Pembuatan node: proses pembuatan untuk node baru dimulai, berlanjut melalui fase antrean dan penyediaan. Durasi fase antrean dapat bervariasi secara dinamis, bergantung pada zona dan kapasitas akselerator tertentu.

  3. Tandai node yang akan mencapai akhir durasi tujuh harinya: setelah node baru berjalan, node lama akan ditandai sebagai tidak dapat dijadwalkan. Tindakan ini mencegah Pod baru dijadwalkan di node tersebut. Pod yang ada di node tersebut akan terus berjalan.

  4. Penghapusan penyediaan node: node yang mencapai akhir durasi tujuh harinya akan dihapus penyediaannya setelah jangka waktu yang sesuai, yang membantu memastikan bahwa beban kerja yang berjalan telah dimigrasikan ke node baru.

Contoh konfigurasi class komputasi berikut mencakup kolom leadTimeSeconds dan maxRunDuration:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: dws-model-inference-class
spec:
  priorities:
    - machineType: g2-standard-24
      spot: true
    - machineType: g2-standard-24
      maxRunDurationSeconds: 72000
      flexStart:
        enabled: true
        nodeRecycling:
          leadTimeSeconds: 3600
  nodePoolAutoCreation:
    enabled: true

Untuk mengetahui informasi selengkapnya tentang cara menggunakan daur ulang node, coba tutorial Menyajikan LLM di GKE dengan strategi penyediaan GPU yang hemat biaya dan memiliki ketersediaan tinggi.

Batasan

  • Anti-afinitas antar-pod tidak didukung. Autoscaler cluster tidak mempertimbangkan aturan anti-afinitas antar-pod selama penyediaan node, yang dapat menyebabkan workload tidak dapat dijadwalkan. Situasi ini dapat terjadi saat node untuk dua atau lebih objek Dynamic Workload Scheduler disediakan di node pool yang sama.
  • Hanya node GPU yang didukung.
  • Pemesanan tidak didukung dengan Dynamic Workload Scheduler. Anda harus menentukan flag --reservation-affinity=none saat membuat node pool. Dynamic Workload Scheduler hanya memerlukan dan mendukung ANY kebijakan lokasi untuk penskalaan otomatis cluster.
  • Satu permintaan Dynamic Workload Scheduler dapat membuat hingga 1.000 virtual machine (VM), yang merupakan jumlah maksimum node per zona untuk satu node pool.
  • GKE menggunakan kuota ACTIVE_RESIZE_REQUESTS Compute Engine untuk mengontrol jumlah permintaan Dynamic Workload Scheduler yang tertunda dalam antrean. Secara default, kuota ini memiliki batas 100 permintaan per project. Google CloudJika Anda mencoba membuat permintaan Dynamic Workload Scheduler yang lebih besar dari kuota ini, permintaan baru akan gagal.
  • Node pool yang menggunakan Dynamic Workload Scheduler rentan terhadap gangguan karena node disediakan bersama-sama. Untuk mempelajari lebih lanjut, lihat Mengelola gangguan dalam workload yang menggunakan Dynamic Workload Scheduler.
  • Anda mungkin melihat VM tambahan yang berumur pendek tercantum di konsol Google Cloud . Perilaku ini memang disengaja karena Compute Engine dapat membuat lalu segera menghapus VM hingga kapasitas untuk menyediakan semua mesin yang diperlukan tersedia.
  • Spot VM tidak didukung.
  • Dynamic Workload Scheduler tidak mendukung volume sementara. Anda harus menggunakan volume persisten untuk penyimpanan. Untuk memilih jenis penyimpanan terbaik yang menggunakan volume persisten, lihat Ringkasan penyimpanan untuk cluster GKE.
  • Jika workload menggunakan daur ulang node dan di-deploy oleh Job, konfigurasi Job dengan mode penyelesaian yang disetel ke Indexed.

Langkah berikutnya