Penyediaan node GPU dengan Karpenter Penskalaan otomatis GPU vs CPU Memilih metrik penskalaan Mempraktikkan semuanya

Inferensi model AI skala otomatis pada GPU dengan Amazon EKS

Tip

Daftar untuk AI/ML lokakarya Amazon EKS mendatang.

Bagian ini mencakup konsep dan prosedur untuk penskalaan otomatis beban kerja inferensi AI pada GPU dengan Amazon EKS.

Replika model VLLM tunggal yang Anda gunakan di bagian Load & Serve Models sebelumnya dapat melayani sejumlah permintaan bersamaan sebelum permintaan baru mulai menunggu, yang meningkatkan latensi dan dapat menyebabkan batas waktu permintaan. Untuk mengimbangi lalu lintas, Anda dapat secara otomatis menskalakan penyebaran secara horizontal. Penskalaan otomatis menambahkan replika beban kerja saat permintaan meningkat dan menghilangkannya saat permintaan turun, sehingga Anda dapat menghindari penyediaan kapasitas GPU yang berlebihan.

Inferensi autoscaling terjadi dalam dua tahap.

Penskalaan node — Ketika penjadwal Kubernetes tidak memiliki ruang untuk menempatkan pod baru pada node yang ada, pod tetap ada. Pending Karpenter merespons Pending pod dengan menyediakan node GPU agar sesuai dengan mereka, dan menghapus node saat replika beban kerja kembali turun.
Penskalaan pod — Horizontal Pod Autoscaler (HPA) mengamati metrik yang dikonfigurasi. Ketika metrik tersebut melewati ambang batas yang dikonfigurasi, HPA meningkatkan jumlah replika beban kerja dan pod VllM baru dibuat.

Tahap penskalaan node menyediakan replika beban kerja kapasitas GPU yang perlu dijalankan. Tahap penskalaan pod menyesuaikan jumlah replika beban kerja agar metrik pilihan Anda tetap dekat dengan targetnya.

Penyediaan node GPU dengan Karpenter

Karpenter mengelola siklus hidup node, menyediakan node saat beban kerja membutuhkannya dan mengkonsolidasikan atau menghapus node saat tidak. Ia bekerja dengan penjadwal Kubernetes daripada menggantinya. Scheduler menempatkan pod pada node. Karpenter menyediakan kapasitas untuk pod yang tidak dapat disesuaikan dengan penjadwal, lalu membiarkan penjadwal mengikatnya begitu node berada. Ready

Karpenter menangani node GPU secara berbeda dari armada node CPU.

GPU diminta sebagai seluruh unit

Kecuali Anda menggunakan teknik berbagi GPU seperti time-slicing atau MIG, sebuah pod mendapatkan satu atau lebih GPU utuh daripada sebagian kecil seperti CPU atau memori. Setiap GPU memiliki memori khusus sendiri, jadi replika pada node yang sama tidak berbagi memori GPU. Bagaimana ini memetakan ke node tergantung pada jenis instance:

Single-GPU instance (sepertig6.xlarge) - Node memegang tepat satu replika. Replika, GPU, dan node menskalakan satu-ke-satu, dan setiap replika diisolasi pada instancenya sendiri.
Multi-GPU instance (sepertig6.12xlarge, yang memiliki 4 GPU) - Plugin perangkat mengiklankan jumlah GPU penuh, sehingga Karpenter dapat mengemas beberapa replika ke satu node, satu per GPU.
Multi-GPU Pod — Pod dapat meminta lebih dari satu GPU. Misalnya, atur nvidia.com/gpu: 2 untuk membelah model besar di dua GPU, dan Karpenter menempatkan pod pada sebuah node dengan banyak GPU yang bebas.

Karpenter mengoptimalkan ketersediaan dan biaya GPU

Karpenter menyeimbangkan pendaratan kapasitas GPU yang langka agar tidak menjalankannya dengan hemat biaya:

Pemilihan instans — Mengingat fleksibilitas NodePool, Karpenter memilih jenis instans dengan biaya terendah yang sesuai dengan pod. Pending Ketika peluncuran mencapai kapasitas yang tidak mencukupi, ia secara otomatis mencoba ulang jenis instans lain dan Availability Zone, yang meningkatkan peluang pendaratan kapasitas GPU.
Konsolidasi — Ketika permintaan turun dan skala replika masuk, Karpenter merebut kembali node yang dibebaskan. WhenEmptyOrUnderutilizedmenghapus node kosong dan mengembalikan replika ke node yang lebih sedikit, sementara WhenEmpty merebut kembali node hanya setelah tidak ada yang dijadwalkan di dalamnya.
Melindungi pod dalam penerbangan — Agar pod tidak terganggu selama konsolidasi, tambahkan karpenter.sh/do-not-disrupt anotasi, atur PodDisruptionBudget, atau gunakan consolidateAfter pengaturan untuk menunda konsolidasi.

Setelah Karpenter memiliki kapasitas GPU, tahap penskalaan pod mengambil alih: HPA menambahkan dan menghapus replika berdasarkan metrik yang Anda konfigurasikan. Sisa bagian ini mencakup cara memilih metrik penskalaan itu untuk beban kerja inferensi.

Penskalaan otomatis GPU vs CPU

Di Kubernetes, CPU-based beban kerja tradisional diskalakan otomatis di luar kotak, tetapi inferensi tidak. GPU-based Ada tiga perbedaan utama:

Ketersediaan metrik untuk penskalaan otomatis

Kubernetes menyediakan metrik CPU dan memori ke HPA out-of-the-box: Kubelet pada setiap node melaporkan penggunaan CPU dan memori ke API metrik Kubernetes, sehingga HPA dapat membaca nilai tersebut secara langsung dan menskalakan beban kerja tanpa komponen tambahan.
Beban kerja yang dipercepat memerlukan pengaturan metrik tambahan, eksportir, dan adaptor: Kubelet tidak melaporkan GPU atau metrik inferensi. Untuk mengukur GPU-based inferensi, Anda harus menambahkan eksportir yang mempublikasikan sinyal yang relevan, seperti metrik aplikasi VllM dan metrik GPU dari eksportir DCGM, dan adaptor yang mengekspos metrik tersebut ke HPA.

Alokasi dan berbagi sumber daya

Beban kerja tradisional berbagi CPU dan memori dalam pecahan: Linux cgroups membagi CPU dan memori menjadi sumber daya fraksional, memungkinkan beberapa pod untuk berbagi node yang sama. Sebuah pod dapat meminta sebagian dari kapasitas node, seperti 100 millicores CPU atau 512 MiB memori.
Beban kerja yang dipercepat mengalokasikan dan berbagi GPU melalui kerangka alokasi GPU: GPU tidak dibagikan melalui cgroup seperti CPU dan memori. Pengaturan Kubernetes yang paling umum saat ini menggunakan plugin perangkat NVIDIA, yang mengalokasikan seluruh GPU ke pod (misalnya,). nvidia.com/gpu: 1 Dynamic Resource Allocation (DRA) adalah API Kubernetes yang lebih baru yang mengalokasikan GPU melalui klaim sumber daya, menyediakan penjadwalan dan manajemen sumber daya yang lebih fleksibel. Plugin perangkat dan DRA dapat mendukung teknik berbagi GPU. Time-slicing memungkinkan beberapa pod untuk berbagi GPU dengan menyisipkan akses dari waktu ke waktu, sementara partisi Multi-Instance GPU (MIG) mendukung GPU, seperti NVIDIA A100 dan H100, ke dalam instance GPU terisolasi perangkat keras.

Sinyal penskalaan

Beban kerja tradisional biasanya berskala pada pemanfaatan CPU dan memori: Pemanfaatan adalah sinyal autoscaling standar untuk beban kerja CPU dan memori. Ini adalah indikator lagging karena naik hanya setelah beban kerja sudah di bawah beban, tetapi untuk banyak aplikasi tradisional itu cukup untuk mendorong keputusan penskalaan.
Beban kerja yang dipercepat harus diskalakan pada metrik indikator terkemuka, bukan pemanfaatan GPU: Pemanfaatan GPU (DCGM_FI_DEV_GPU_UTIL) menunjukkan apakah GPU sibuk, bukan seberapa sibuknya. Karena server inferensi seperti VllM dapat tetap mendekati 100% di berbagai permintaan yang masuk, pemanfaatan adalah sinyal penskalaan otomatis yang tidak dapat diandalkan. Skala sebagai gantinya pada indikator utama yang naik saat permintaan mendekati kapasitas, seperti kedalaman antrian permintaan, token waktu ke pertama (TTFT), dan latensi permintaan.

Dari ketiga perbedaan yang dibahas di atas, pertimbangkan dengan cermat sinyal penskalaan Anda. Karena pemanfaatan GPU bukanlah sinyal kepercayaan tinggi dari kapasitas inferensi yang tersisa, Anda perlu mengidentifikasi dan mengumpulkan sinyal yang melacak permintaan aktual pada server inferensi model.

Bagian selanjutnya mencakup sinyal mana yang akan digunakan sebagai metrik penskalaan Anda dan bagaimana mereka bekerja sama.

Memilih metrik penskalaan

Tidak ada metrik tunggal yang memberi tahu Anda kapan harus menskalakan replika inferensi model Anda, jadi Anda menskalakan kombinasi sinyal dari server inferensi. Sinyal-sinyal ini bekerja sama, masing-masing dibangun di atas yang sebelumnya untuk menangkap permintaan lebih awal dan lebih andal daripada metrik tunggal mana pun:

Sinyal	Metrik	Peran dalam penskalaan
Antrean	Permintaan kedalaman antrian (jumlah permintaan yang menunggu untuk diproses)	Indikator utama dan pemicu default terbaik, karena antrian membentuk permintaan saat melebihi kapasitas.
Latensi	Minta latensi (latensi p95 atau TTFT)	Memicu penskalaan saat respons lambat meskipun antrian belum dibangun, menjaga latensi yang dihadapi pengguna dalam target.
Memori GPU	Pemanfaatan cache KV (seberapa penuh memori permintaan GPU)	Perlindungan terhadap kehabisan memori GPU; saat mendekati batasnya, server mulai menolak atau mengantri permintaan.

Bersama-sama mereka membentuk lapisan pertahanan: kedalaman antrian permintaan adalah pemicu utama yang memicu saat permintaan melebihi kapasitas, latensi permintaan menambahkan pemeriksaan untuk respons lambat sebelum antrian terbentuk, dan pemanfaatan cache KV adalah backstop yang mencegah kehabisan memori GPU.

Mempraktikkan semuanya

Subbagian berikut menunjukkan cara menempatkan sinyal-sinyal ini untuk bekerja dengan autoscaler tertentu.

Temukan ambang metrik penskalaan. Uji beban replika VllM tunggal untuk menemukan plafon kapasitasnya serta ambang batas kedalaman antrian serta latensi untuk diskalakan. Mulai dari sini.
Skala dengan HPA dan KEDA. Replika VLLM skala otomatis dengan KEDA dan Horizontal Pod Autoscaler, menggunakan kedalaman antrian permintaan dan latensi end-to-end sebagai sinyal penskalaan.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Model Muat & Sajikan

Ambang batas metrik