Tentang TPU di GKE

Halaman ini memperkenalkan Cloud TPU dengan Google Kubernetes Engine (GKE). Tensor Processing Unit (TPU) adalah sirkuit terintegrasi khusus aplikasi (ASIC) Google yang dikembangkan khusus dan digunakan untuk mempercepat beban kerja machine learning (ML) yang menggunakan framework seperti TensorFlow, PyTorch, dan JAX.

Sebelum menggunakan TPU di GKE, sebaiknya pelajari cara kerja akselerator machine learning dengan Pengantar Cloud TPU.

Halaman ini membantu Anda memahami dasar-dasar Cloud TPU dengan Google Kubernetes Engine (GKE), termasuk terminologi, manfaat TPU, dan pertimbangan penjadwalan beban kerja.

Untuk mempelajari cara menyiapkan Cloud TPU di GKE, lihat referensi berikut:

Manfaat menggunakan TPU di GKE

GKE memberikan dukungan penuh untuk pengelolaan siklus proses node TPU dan node pool, termasuk membuat, mengonfigurasi, dan menghapus VM TPU. GKE juga mendukung Spot VM dan menggunakan Cloud TPU yang dicadangkan. Manfaat menggunakan TPU di GKE meliputi:

  • Lingkungan operasional yang konsisten: Anda dapat menggunakan satu platform untuk semua machine learning dan workload lainnya.
  • Upgrade otomatis: GKE mengotomatiskan update versi yang mengurangi overhead operasional.
  • Load balancing: GKE mendistribusikan beban, sehingga mengurangi latensi dan meningkatkan keandalan.
  • Penskalaan responsif: GKE secara otomatis menskalakan resource TPU untuk memenuhi kebutuhan workload Anda.
  • Pengelolaan resource: Dengan Kueue, sistem antrean tugas native Kubernetes, Anda dapat mengelola resource di beberapa tenant dalam organisasi menggunakan antrean, preemption, prioritas, dan pembagian yang adil.

Manfaat menggunakan TPU Trillium (v6e)

TPU Trillium (v6e) adalah akselerator AI generasi terbaru Cloud TPU. Di semua antarmuka teknis (API, log) dan di seluruh dokumentasi GKE, TPU Trillium (v6e) disebut sebagai v6e, yang mewakili TPU generasi ke-6 Google.

  • TPU v6e meningkatkan performa komputasi per chip dibandingkan dengan TPU v5e.
  • TPU v6e meningkatkan kapasitas dan bandwidth High Bandwidth Memory (HBM), dan juga meningkatkan bandwidth Interchip Interconnect (ICI) dibandingkan TPU v5e.
  • TPU v6e dilengkapi dengan SparseCore generasi ketiga, akselerator khusus untuk memproses penyematan berukuran sangat besar yang umum dalam workload rekomendasi dan peringkat lanjutan.
  • TPU v6e lebih hemat energi hingga 67% dibandingkan TPU v5e.
  • TPU v6e dapat diskalakan hingga 256 TPU dalam satu slice TPU latensi rendah dan bandwidth tinggi.

Untuk mempelajari manfaat TPU Trillium lebih lanjut, baca postingan blog pengumuman TPU v6e. Untuk memulai penyiapan TPU, lihat Merencanakan TPU di GKE.

Terminologi yang terkait dengan TPU di GKE

Halaman ini menggunakan terminologi berikut yang terkait dengan TPU:

  • Jenis TPU: jenis Cloud TPU, seperti v5e.
  • Node slice TPU: node Kubernetes yang diwakili oleh satu VM yang memiliki satu atau beberapa chip TPU yang saling terhubung.
  • Node pool slice TPU: sekelompok node Kubernetes dalam cluster yang semuanya memiliki konfigurasi TPU yang sama.
  • Topologi TPU: jumlah dan pengaturan fisik TPU chip dalam slice TPU.
  • Atomik: GKE memperlakukan semua node yang saling terhubung sebagai satu unit. Selama operasi penskalaan, GKE menskalakan seluruh kumpulan node ke 0 dan membuat node baru. Jika mesin dalam grup gagal atau dihentikan, GKE akan membuat ulang seluruh kumpulan node sebagai unit baru.
  • Tidak dapat diubah: Anda tidak dapat menambahkan node baru secara manual ke kumpulan node yang saling terkoneksi. Namun, Anda dapat membuat node pool baru dengan topologi TPU yang diinginkan dan menjadwalkan workload di node pool baru.

Jenis TPU node pool slice

GKE mendukung dua jenis node pool TPU:

Jenis dan topologi TPU menentukan apakah node slice TPU Anda dapat berupa multi-host atau single-host. Sebaiknya:

  • Untuk model berskala besar, gunakan node slice TPU multi-host
  • Untuk model berskala kecil, gunakan node slice TPU host tunggal

Node pool slice TPU multi-host

Node pool slice TPU multi-host adalah node pool yang berisi dua atau beberapa VM TPU yang saling terhubung. Setiap VM memiliki perangkat TPU yang terhubung. TPU dalam slice TPU multi-host terhubung melalui interkoneksi berkecepatan tinggi (ICI). Setelah node pool slice TPU multi-host dibuat, Anda tidak dapat menambahkan node ke dalamnya. Misalnya, Anda tidak dapat membuat node pool v4-32, lalu menambahkan node Kubernetes tambahan (VM TPU) ke node pool tersebut. Untuk menambahkan slice TPU tambahan ke cluster GKE, Anda harus membuat node pool baru.

VM dalam node pool slice TPU multi-host diperlakukan sebagai satu unit atomik. Jika GKE tidak dapat men-deploy satu node dalam slice, tidak ada node dalam node slice TPU yang di-deploy.

Jika node dalam slice TPU multi-host perlu diperbaiki, GKE akan mematikan semua VM dalam slice TPU, sehingga memaksa semua Pod Kubernetes dalam beban kerja dihapus. Setelah semua VM di slice TPU aktif dan berjalan, Pod Kubernetes dapat dijadwalkan di VM di slice TPU baru.

Diagram berikut menunjukkan slice TPU multi-host v5litepod-16 (v5e). Slice TPU ini memiliki empat VM. Setiap VM dalam slice TPU memiliki empat chip TPU v5e yang terhubung dengan interkoneksi berkecepatan tinggi (ICI), dan setiap chip TPU v5e memiliki satu TensorCore.

Diagram slice TPU multi-host

Diagram berikut menunjukkan cluster GKE yang berisi satu slice TPU v5litepod-16 (v5e) (topologi: 4x4) dan satu slice TPU v5litepod-8 (v5e) (topologi: 2x4):

Diagram Pod TPU v5e

Node pool slice TPU host tunggal

Node pool slice host tunggal adalah node pool yang berisi satu atau beberapa VM TPU independen. Setiap VM memiliki perangkat TPU yang terhubung. Meskipun VM dalam node pool slice host tunggal dapat berkomunikasi melalui jaringan pusat data (DCN), TPU yang terpasang ke VM tidak saling terhubung.

Diagram berikut menunjukkan contoh slice TPU satu host yang berisi tujuh mesin v4-8:

Diagram node pool slice host tunggal

Karakteristik TPU di GKE

TPU memiliki karakteristik unik yang memerlukan perencanaan dan konfigurasi khusus.

Topologi

Topologi menentukan pengaturan fisik TPU dalam slice TPU. GKE menyediakan slice TPU dalam topologi dua atau tiga dimensi, bergantung pada versi TPU. Anda menentukan topologi sebagai jumlah chip TPU dalam setiap dimensi, sebagai berikut:

Untuk TPU v4 dan v5p yang dijadwalkan di node pool slice TPU multi-host, Anda akan menentukan topologi dalam 3 tuple ({A}x{B}x{C}), misalnya 4x4x4. Produk {A}x{B}x{C} menentukan jumlah TPU chip dalam node pool. Misalnya, Anda dapat menentukan topologi kecil yang memiliki kurang dari 64 chip TPU dengan bentuk topologi seperti 2x2x2,2x2x4, atau 2x4x4. Jika Anda menggunakan topologi yang lebih besar yang memiliki lebih dari 64 chip TPU, nilai yang Anda tetapkan ke {A},{B}, dan {C} harus memenuhi kondisi berikut:

  • {A},{B}, dan {C} harus berupa kelipatan empat.
  • Topologi terbesar yang didukung untuk v4 adalah 12x16x16 dan v5p adalah 16x16x24.
  • Nilai yang ditetapkan harus mempertahankan pola A ≤ B ≤ C. Misalnya 4x4x8 atau 8x8x8.

Jenis mesin

Jenis mesin yang mendukung resource TPU mengikuti konvensi penamaan yang mencakup versi TPU dan jumlah TPU chip per slice node, seperti ct<version>-hightpu-<node-chip-count>t. Misalnya, jenis mesin ct5lp-hightpu-1t mendukung TPU v5e dan hanya berisi satu chip TPU.

Mode dengan hak istimewa

Mode dengan hak istimewa mengganti banyak setelan keamanan lainnya di securityContext. Untuk mengakses TPU, container yang berjalan di node GKE di:

  • Versi 1.28 dan yang lebih lama harus mengaktifkan mode dengan hak istimewa.
  • Versi 1.28 atau yang lebih baru tidak memerlukan mode hak istimewa.

Cara kerja TPU di GKE

Pengelolaan dan prioritas resource Kubernetes memperlakukan VM di TPU sama seperti jenis VM lainnya. Untuk meminta chip TPU, gunakan nama resource google.com/tpu:

    resources:
        requests:
          google.com/tpu: 4
        limits:
          google.com/tpu: 4

Saat menggunakan TPU di GKE, Anda harus mempertimbangkan karakteristik TPU berikut:

  • VM dapat mengakses hingga 8 chip TPU.
  • Slice TPU berisi chip TPU dalam jumlah tetap, dengan jumlah yang bergantung pada jenis mesin TPU yang Anda pilih.
  • Jumlah google.com/tpu yang diminta harus sama dengan jumlah total TPU chip yang tersedia di node slice TPU. Container apa pun di Pod GKE yang meminta TPU harus menggunakan semua TPU chip dalam node. Jika tidak, Deployment akan gagal karena GKE tidak dapat memakai sebagian resource TPU. Pertimbangkan skenario berikut:
    • Jenis mesin ct5l-hightpu-8t memiliki satu node slice TPU dengan 8 chip TPU sehingga pada node, Anda:
      • Dapat men-deploy satu Pod GKE yang memerlukan delapan chip TPU.
      • Tidak dapat men-deploy dua Pod GKE yang masing-masing memerlukan empat chip TPU.
    • Jenis mesin ct5lp-hightpu-4t dengan topologi 2x4 berisi dua node slice TPU dengan masing-masing empat TPU chip, sehingga totalnya delapan TPU chip. Dengan jenis mesin ini, Anda dapat:
      • Tidak dapat men-deploy Pod GKE yang memerlukan delapan chip TPU di node dalam node pool ini.
      • Dapat men-deploy dua Pod yang masing-masing memerlukan empat chip TPU, setiap Pod di salah satu dari dua node dalam node pool ini.
    • TPU v5e dengan topologi 4x4 memiliki 16 chip TPU di empat node. Workload Autopilot GKE yang memilih konfigurasi ini harus meminta empat chip TPU di setiap replika, untuk satu hingga empat replika.
  • Di cluster Standar, beberapa Pod Kubernetes dapat dijadwalkan di VM, tetapi hanya satu penampung di setiap Pod yang dapat mengakses chip TPU.
  • Untuk membuat Pod kube-system, seperti kube-dns, setiap cluster Standar harus memiliki setidaknya satu node pool slice non-TPU.
  • Secara default, node slice TPU memiliki google.com/tpu taint yang mencegah workload non-TPU dijadwalkan di node slice TPU. Workload yang tidak menggunakan TPU dijalankan di node non-TPU, sehingga membebaskan komputasi di node slice TPU untuk kode yang menggunakan TPU. Perhatikan bahwa taint tidak menjamin resource TPU digunakan sepenuhnya.
  • GKE mengumpulkan log yang dikeluarkan oleh container yang berjalan di node slice TPU. Untuk mempelajari lebih lanjut, lihat Logging.
  • Metrik penggunaan TPU, seperti performa runtime, tersedia di Cloud Monitoring. Untuk mempelajari lebih lanjut, lihat Kemampuan observasi dan metrik.

Langkah selanjutnya