Tentang konsumsi GPU, TPU, dan H4D dengan mode penyediaan mulai fleksibel

Halaman ini menjelaskan flex-start di Google Kubernetes Engine (GKE). Flex-start, yang didukung oleh Dynamic Workload Scheduler, menyediakan teknik yang fleksibel dan hemat biaya untuk menggunakan resource komputasi khusus, seperti GPU atau TPU, saat Anda perlu menjalankan workload AI/ML.

Flex-start memungkinkan Anda menyediakan VM Flex-start secara dinamis untuk GPU, TPU, dan seri mesin H4D 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 singkat. Misalnya, pra-pelatihan model kecil, penyesuaian model, atau model inferensi yang dapat diskalakan.

Informasi di halaman ini dapat membantu Anda melakukan hal berikut:

  • Memahami cara kerja flex-start di GKE.
  • Menentukan apakah flex-start tepat untuk workload Anda.
  • Menentukan konfigurasi flex-start yang tepat untuk workload Anda.
  • Mengelola gangguan saat menggunakan VM Flex-start.
  • Memahami batasan VM Flex-start di GKE.

Halaman ini ditujukan untuk admin dan operator Platform serta engineer Machine learning (ML) yang ingin mengoptimalkan infrastruktur akselerator untuk workload mereka.

Kapan sebaiknya 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.
  • Workload Anda memerlukan hardware khusus lainnya, seperti seri mesin H4D yang dioptimalkan untuk HPC.
  • 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 dalam hal waktu dan kasus penggunaan Anda dapat menunggu untuk mendapatkan semua kapasitas yang diminta, misalnya, saat GKE mengalokasikan resource GPU di luar jam tersibuk.

Harga flex-start

Flex-start direkomendasikan jika workload Anda memerlukan resource yang disediakan secara dinamis sesuai kebutuhan, hingga tujuh hari dengan reservasi jangka pendek, tanpa pengelolaan kuota yang kompleks, dan akses yang hemat biaya. Flex-start 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 flex-start 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, lihat persyaratan versi GKE di Merencanakan TPU di GKE. Flex-start mendukung versi dan zona berikut:

    • Ironwood (TPU7x) di us-central1-c.
    • TPU Trillium (v6e) di asia-northeast1-b, us-east5-a, dan us-east5-b.
    • TPU v5e di us-west4-a.
    • TPU v5p di us-east5-a.

    TPU v3 dan v4 tidak didukung.

Cara kerja mode penyediaan flex-start

Dengan flex-start, Anda menentukan kapasitas komputasi yang diperlukan (seperti GPU atau TPU) dalam workload Anda. Selain itu, dengan cluster Standar, Anda mengonfigurasi flex-start pada node pool tertentu. GKE secara otomatis menyediakan VM Flex-start dengan menyelesaikan proses berikut saat kapasitas tersedia:

  1. Workload meminta kapasitas yang tidak langsung tersedia. Permintaan ini dapat dibuat langsung oleh spesifikasi workload atau melalui alat orkestrasi seperti class komputasi kustom atau Kueue.
  2. GKE mengidentifikasi bahwa node Anda mengaktifkan flex-start dan workload dapat menunggu dalam jumlah waktu yang tidak ditentukan.
  3. Autoscaler cluster menerima permintaan Anda dan menghitung jumlah node yang diperlukan, serta memperlakukannya sebagai satu unit.
  4. Autoscaler cluster menyediakan node yang diperlukan saat tersedia. Node ini berjalan selama maksimal tujuh hari, atau untuk durasi yang lebih singkat jika Anda menentukan nilai dalam parameter maxRunDurationSeconds. Jika Anda tidak menentukan nilai untuk parameter maxRunDurationSeconds, nilai defaultnya adalah tujuh hari.
  5. Setelah waktu berjalan yang Anda tentukan dalam parameter maxRunDurationSeconds berakhir, node dan Pod akan di-preempt.
  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 flex-start di tingkat node. Waktu yang tersedia untuk menjalankan Pod mungkin sedikit lebih kecil karena penundaan selama startup. Percobaan ulang Pod menggunakan durasi ini, yang berarti waktu yang tersedia untuk Pod setelah percobaan ulang lebih sedikit. GKE menghitung durasi untuk setiap permintaan flex-start secara terpisah.

Konfigurasi flex-start

GKE mendukung konfigurasi flex-start berikut:

  • Flex-start, tempat GKE mengalokasikan resource node demi node. Konfigurasi ini hanya mengharuskan Anda menetapkan flag --flex-start selama pembuatan node.

  • Flex-start dengan penyediaan dalam antrean, tempat 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 di Cara kerja mode penyediaan flex-start dalam dokumen ini, tetapi juga menerapkan kondisi berikut:

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

Tabel berikut membandingkan konfigurasi flex-start:

Flex-start Flex-start dengan penyediaan dalam antrean
Ketersediaan Pratinjau

Tersedia Secara Umum (GA)

Catatan: Flex-start mendukung flag flex-start dan enable-queued-provisioning dalam Pratinjau.
Akselerator yang didukung
Ukuran workload yang direkomendasikan Kecil hingga sedang, yang berarti workload dapat berjalan di satu node. Misalnya, konfigurasi ini berfungsi dengan baik jika Anda menjalankan tugas pelatihan kecil, inferensi offline, atau tugas batch. Sedang hingga besar, yang berarti workload dapat berjalan di beberapa node. Workload 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. Untuk TPU, GKE membuat satu node dalam satu waktu di node pool slice TPU host tunggal, dan slice lengkap dalam satu waktu di node pool slice TPU multi-host. GKE mengalokasikan semua resource yang diminta secara bersamaan.
Kompleksitas penyiapan Kurang kompleks. Konfigurasi ini mirip dengan VM on-demand dan Spot. 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
Quota
Strategi upgrade node Upgrade berumur pendek Upgrade berumur pendek
gcloud container node pool create flag --flex-start
  • --flex-start
  • --enable-queued-provisioning
Mulai GPU: TPU: Menjalankan workload skala besar dengan flex-start dengan penyediaan dalam antrean

Mengoptimalkan konfigurasi flex-start

Untuk membuat infrastruktur AI/ML yang tangguh dan dioptimalkan biayanya, Anda dapat menggabungkan konfigurasi flex-start 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 tentukan.

Mengelola gangguan dalam workload yang menggunakan Dynamic Workload Scheduler

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

Semua node yang menggunakan VM Flex-start, penyediaan dalam antrean, atau keduanya, menggunakan upgrade berumur pendek saat bidang kontrol cluster menjalankan versi minimum untuk flex-start, 1.32.2-gke.1652000 atau yang lebih baru.

Upgrade berumur pendek mengupdate node pool Standar atau grup node di cluster Autopilot tanpa mengganggu node yang berjalan. Node baru dibuat dengan konfigurasi baru, secara bertahap menggantikan node yang ada dengan konfigurasi lama dari waktu ke waktu. Versi GKE sebelumnya, yang tidak mendukung flex-start atau upgrade berumur pendek, memerlukan praktik terbaik yang berbeda.

Praktik terbaik untuk meminimalkan gangguan workload untuk node yang menggunakan upgrade berumur pendek

Node yang menggunakan VM Flex-start dan node yang menggunakan penyediaan dalam antrean dikonfigurasi secara otomatis untuk menggunakan upgrade berumur pendek 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 berumur pendek, lakukan tugas berikut:

Untuk node di cluster yang menjalankan versi yang lebih lama dari 1.32.2-gke.1652000, dan dengan demikian tidak menggunakan upgrade berumur pendek, lihat panduan khusus untuk node tersebut.

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

Node yang menggunakan penyediaan dalam antrean di cluster yang menjalankan GKE versi yang lebih lama dari 1.32.2-gke.1652000 tidak menggunakan upgrade berumur pendek. 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 berumur pendek.

Untuk node yang menjalankan versi sebelumnya, lihat panduan berikut:

  • Bergantung pada pendaftaran saluran rilis cluster Anda, gunakan praktik terbaik berikut untuk mencegah upgrade otomatis node mengganggu workload Anda:
    • Jika cluster Anda terdaftar di saluran rilis, gunakan masa pemeliharaan dan pengecualian untuk mencegah GKE mengupgrade node Anda secara otomatis saat workload Anda berjalan.
    • Jika cluster Anda tidak terdaftar di saluran rilis, nonaktifkan upgrade otomatis node. Namun, sebaiknya gunakan saluran rilis, tempat Anda dapat menggunakan pengecualian pemeliharaan dengan cakupan yang lebih terperinci.
  • Nonaktifkan perbaikan otomatis node.
  • Gunakan masa pemeliharaan dan pengecualian untuk meminimalkan gangguan pada workload yang berjalan, sekaligus memastikan bahwa GKE masih memiliki waktu untuk melakukan pemeliharaan otomatis. Pastikan untuk menjadwalkan waktu tersebut saat tidak ada workload yang berjalan.
  • Untuk memastikan node pool Anda tetap terbaru, upgrade node pool Anda secara manual saat tidak ada permintaan Dynamic Workload Scheduler yang aktif dan node pool kosong.

Pertimbangan saat cluster Anda bermigrasi ke upgrade berumur pendek

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

Sebaiknya pertimbangkan untuk menerapkan praktik terbaik berikut sekarang setelah node pool Anda menggunakan upgrade berumur pendek:

Daur ulang node di flex-start

Untuk membantu memastikan transisi node yang lancar dan mencegah periode nonaktif untuk tugas yang sedang berjalan, flex-start mendukung daur ulang node. Saat node mencapai akhir durasinya, GKE akan otomatis mengganti node dengan node baru untuk mempertahankan workload Anda 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 mungkin akan dikenakan biaya tambahan.

Proses daur ulang node terdiri dari langkah-langkah berikut:

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

    • creationTimestamp ditambah maxRunDurationSeconds
    • leadTimeSeconds

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

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

  3. Mengisolasi node yang akan mencapai akhir durasi tujuh harinya: setelah node baru berjalan, node lama akan diisolasi. Tindakan ini mencegah Pod baru dijadwalkan di node tersebut. Pod yang ada di node tersebut akan terus berjalan.

  4. Penghentian penyediaan node: node yang akan mencapai akhir durasi tujuh harinya pada akhirnya akan dihentikan penyediaannya setelah periode yang sesuai, yang membantu memastikan bahwa workload 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 dioptimalkan biayanya 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 beberapa objek Dynamic Workload Scheduler disediakan di node pool yang sama.
  • Reservasi 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 mesin virtual (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 Google Cloud project. Jika Anda mencoba membuat permintaan Dynamic Workload Scheduler yang lebih besar dari kuota ini, permintaan baru akan gagal.
  • Node pool yang menggunakan Dynamic Workload Scheduler sensitif 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 berumur pendek tambahan yang tercantum di Google Cloud konsol. Perilaku ini dimaksudkan karena Compute Engine mungkin membuat dan kemudian segera menghapus VM hingga kapasitas untuk menyediakan semua mesin yang diperlukan tersedia.
  • Spot VM tidak didukung.
  • Dynamic Workload Scheduler tidak mendukung volume efemeral. 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 Tugas, konfigurasi Tugas dengan mode penyelesaian yang ditetapkan ke Indexed.
  • Satu objek ProvisioningRequest hanya mendukung satu entri dalam daftar podSets. Permintaan dengan beberapa entri podSet akan gagal.

Langkah berikutnya