Praktik terbaik untuk inferensi batch di GKE

Dokumen ini memberikan praktik terbaik untuk menjalankan workload inferensi batch di Google Kubernetes Engine (GKE). Inferensi batch adalah proses penggunaan model machine learning untuk menghasilkan prediksi pada set data besar, yang memprioritaskan throughput tinggi dan efisiensi biaya dibandingkan respons latensi rendah yang langsung.

Panduan ini membedakan inferensi batch dari batching permintaan (atau batching dinamis)—teknik sisi server di mesin seperti vLLM atau SGLang yang mengelompokkan permintaan real-time serentak untuk mengoptimalkan efisiensi akselerator. Anda dapat menerapkan batching permintaan ke beban kerja inferensi batch.

Praktik terbaik dalam panduan ini mencakup dua jenis pola inferensi batch umum:

  • Inferensi batch hampir real-time: memproses data dalam potongan segera setelah data dibuat. Dengan latensi umum dalam hitungan detik hingga menit, pendekatan ini menyeimbangkan kebutuhan akan data baru dengan efisiensi pemrosesan beberapa item secara bersamaan.
  • Inferensi batch offline: memproses data terakumulasi dalam volume besar pada interval terjadwal (misalnya, setiap malam atau mingguan). Latensi biasanya berkisar dari beberapa jam hingga beberapa hari, karena tugas ini sering dijadwalkan selama waktu di luar jam sibuk untuk memaksimalkan ketersediaan resource.

Rekomendasi ini adalah lapisan pengoptimalan khusus yang dibangun berdasarkan fondasi yang dijelaskan dalam Ringkasan praktik terbaik inferensi di GKE. Sebelum mengoptimalkan workload batch, pastikan Anda telah mengikuti praktik terbaik inti untuk pemilihan model, kuantisasi, dan pilihan akselerator.

Memilih pola arsitektur untuk pemrosesan inferensi batch

Memilih pola arsitektur yang benar adalah keputusan paling penting untuk men-deploy workload inferensi batch karena memengaruhi pertukaran antara latensi, throughput, dan biaya. Untuk menjaga efisiensi, pastikan throughput inferensi Anda melebihi kecepatan kueri yang masuk selama jam tidak sibuk untuk mencegah antrean bertambah tanpa batas.

Menggunakan inferensi batch hampir real-time untuk beban kerja yang tidak teratur

Pengelompokan batch hampir real-time berfungsi dengan baik untuk kasus penggunaan yang memerlukan update inkremental yang sering, seperti berikut:

  • Memperbarui profil rekomendasi pengguna setiap beberapa menit berdasarkan interaksi terbaru.
  • Memproses sebutan media sosial dalam interval satu menit untuk pemantauan real-time.
  • Mendeteksi sinyal penggerak pasar dari aliran data keuangan frekuensi tinggi.
  • Melakukan analisis sentimen pada masukan pelanggan atau feed berita yang masuk.

Pilih pola ini jika beban kerja Anda dapat mentoleransi latensi yang berkisar dari beberapa detik hingga beberapa menit.

Saat Anda menerapkan inferensi batch mendekati real-time, pertimbangkan karakteristik berikut:

  • Latensi: Anda dapat mengharapkan waktu hingga token pertama berkisar dari puluhan detik hingga beberapa menit.
  • Sumber data: Anda biasanya memproses set data mulai dari megabyte hingga gigabyte, seperti pesan dari Pub/Sub atau file dari Cloud Storage yang dikumpulkan selama jangka waktu singkat.
  • Pola komputasi: infrastruktur Anda harus mendukung layanan berkelanjutan yang menangani lonjakan beban kerja yang sering terjadi.
  • Pengoptimalan biaya: pola ini menawarkan keseimbangan antara inferensi real-time latensi rendah dan pemrosesan offline throughput tinggi.

Menggunakan inferensi batch offline untuk set data besar

Pengelompokan offline ideal untuk tugas episodik skala besar yang dapat mentoleransi penundaan selama berjam-jam atau berhari-hari, seperti berikut:

  • Membuat laporan penilaian risiko harian berdasarkan transaksi keuangan hari sebelumnya.
  • Membuat sematan produk untuk seluruh katalog guna mendukung sistem rekomendasi dan penelusuran hilir.
  • Memberi label pada set data gambar yang besar untuk pelatihan model atau kategorisasi pengarsipan.

Pilih pola ini jika Anda memproses data dalam volume besar dan dapat mentoleransi latensi mulai dari beberapa jam hingga beberapa hari.

Saat Anda menerapkan inferensi batch offline, pertimbangkan karakteristik berikut:

  • Latensi: latensi mulai workload biasanya berkisar dari menit hingga hari karena tugas sering dijadwalkan selama waktu di luar jam sibuk.
  • Sumber data: Anda memproses set data besar dari gigabyte hingga petabyte, yang biasanya disimpan di tabel Cloud Storage atau BigQuery.
  • Pola komputasi: Anda menggunakan tugas episodik dan bursty yang melakukan inisialisasi, memproses data, lalu menghentikan tugas.
  • Pengoptimalan biaya: pola ini sangat dapat dioptimalkan dengan model bayar per penggunaan. Karena tugas offline memiliki jangka waktu penyelesaian yang fleksibel, sebaiknya gunakan Spot VM untuk mengurangi biaya.

Mengoptimalkan throughput dan efisiensi biaya

Workload inferensi batch sangat cocok untuk infrastruktur hemat biaya yang mungkin melibatkan gangguan.

Menggunakan Spot VM untuk mengurangi biaya komputasi

Gunakan diskon Spot VM untuk tugas batch. Karena beban kerja inferensi batch biasanya toleran terhadap latensi dan gangguan, beban kerja tersebut merupakan kandidat yang baik untuk harga yang lebih rendah dari kapasitas Spot.

Pastikan kode inferensi batch Anda menerapkan pembuatan titik pemeriksaan untuk menangani potensi peristiwa penghentian sementara. Jika Spot VM di-preempt, Anda dapat membuat node baru dan melanjutkan workload dari batch terakhir yang diproses, bukan memulai ulang dari nol.

Menyesuaikan ukuran batch workload dan ukuran batch permintaan

Untuk menghindari pertentangan resource dan waktu tunggu tugas, pastikan jumlah item yang dikirim ke mesin Anda (batch workload) setidaknya sama besarnya dengan permintaan serentak yang dapat diproses server (batch permintaan) untuk menghindari kurangnya pemanfaatan akselerator.

Menyesuaikan ukuran batch workload

Ukuran batch workload adalah jumlah total item yang dikirim ke mesin inferensi Anda dalam satu unit kerja. Anda mengonfigurasi ini dalam logika pengiriman klien atau konfigurasi Job Kubernetes dengan membagi data atau mengelompokkan beberapa item ke dalam satu permintaan.

Untuk menentukan ukuran batch beban kerja yang optimal, gunakan batas berikut:

  • Hitung ukuran batch minimum: pastikan ukuran batch workload Anda setidaknya sama besar dengan ukuran batch permintaan Anda. Misalnya, mengirim satu item ke server yang dapat memproses 256 item secara bersamaan akan menyebabkan pemanfaatan yang sangat kurang. Untuk menemukan ukuran minimum, periksa konfigurasi server inferensi Anda, seperti argumen max_num_seqs di vLLM. Anda dapat mengonfigurasi logika klien untuk mengelompokkan beberapa item ke dalam satu permintaan, atau Anda dapat memecah data sehingga setiap Tugas menerima jumlah data minimum yang memenuhi atau melampaui ukuran batch permintaan.
  • Hitung ukuran batch maksimum: pastikan ukuran batch workload Anda memungkinkan Pod selesai sebelum mencapai waktu tunggu activeDeadlineSeconds yang ditentukan dalam Kubernetes Job. Perkirakan waktu yang diperlukan untuk memproses satu batch permintaan dan tetapkan ukuran beban kerja sehingga Pod dapat diselesaikan jauh sebelum batas waktu. Misalnya, jika activeDeadlineSeconds Anda adalah 3.600 detik, dan overhead startup Anda adalah 600 detik, pastikan waktu eksekusi maksimum memungkinkan Pod selesai dalam waktu kurang dari 3.000 detik.

Jika ukuran batch workload terlalu kecil, tugas Anda akan membuang waktu untuk overhead startup Pod (mendownload bobot, penyediaan, inisialisasi akselerator); jika terlalu besar, Anda berisiko Tugas dihentikan oleh GKE karena waktu tunggu activeDeadlineSeconds, sehingga menyebabkan Tugas gagal dan kehilangan progresnya.

Menyesuaikan ukuran batch permintaan

Ukuran batch permintaan adalah jumlah permintaan serentak yang diproses server inferensi secara bersamaan di akselerator. Anda mengoptimalkan parameter ini dengan menyesuaikan flag khusus server dalam konfigurasi server inferensi (misalnya, flag --max-num-seqs untuk vLLM).

Sasaran Anda adalah memaksimalkan pemanfaatan GPU tanpa memicu error Kehabisan Memori (OOM). Jika ukuran batch permintaan tidak dikalibrasi, sistem Anda akan kurang memanfaatkan akselerator atau menyebabkan server model error. Untuk vLLM, Anda dapat menggunakan alat seperti skrip vLLM auto_tune untuk menemukan nilai terbaik untuk setelan max_num_seqs dan max_num_batched_tokens untuk hardware spesifik Anda. Untuk mengetahui informasi selengkapnya, lihat Mengoptimalkan konfigurasi server inferensi Anda dalam panduan Ringkasan praktik terbaik inferensi di GKE.

Menerapkan komponen asinkron untuk pengelompokan hampir real-time

Untuk pengelompokan mendekati real-time, sebaiknya gunakan buffer pesan untuk memisahkan lapisan penyerapan dari lapisan inferensi.

Diagram arsitektur berikut mengilustrasikan contoh platform inferensi batch near real-time. Arsitektur ini melindungi server inferensi dari lonjakan traffic, mengelola backlog pekerjaan, dan memastikan penggunaan akselerator yang tinggi.

Diagram ini menunjukkan alur dari Pub/Sub ke pelanggan, gateway inferensi, dan server inferensi, dengan hasil yang dipertahankan di AlloyDB dan pesan yang gagal dikirim ke topik pesan yang tidak terkirim.

Platform inferensi batch hampir real-time di GKE.

Arsitektur ini terdiri dari komponen berikut:

  • Topik Pub/Sub: berfungsi sebagai buffer persisten untuk pesan klien yang masuk, dengan periode retensi 7 hingga 31 hari.
  • Subscriber: komponen yang membaca batch pesan, mengirim permintaan ke server inferensi, dan mengonfirmasi pemrosesan.
  • HPA Subscriber: menskalakan deployment subscriber berdasarkan metrik num_undelivered_messages (jumlah pesan yang tidak dikonfirmasi).
  • Penyimpanan: mempertahankan hasil inferensi dengan menggunakan database (seperti AlloyDB) atau penyimpanan objek (seperti Cloud Storage) .
  • Inference Gateway: mengekspos workload inferensi ke pelanggan.
  • Server Inferensi: memproses permintaan inferensi yang di-batch (misalnya, vLLM).
  • HPA server: menskalakan mesin inferensi berdasarkan metrik khusus mesin seperti vllm:num_requests_waiting.
  • Topik pesan yang dihentikan pengirimannya: mencatat pesan yang gagal diproses setelah sejumlah percobaan ulang backoff eksponensial.

Untuk mengetahui informasi selengkapnya, lihat implementasi referensi di GitHub.

Mem-buffer dan menggabungkan permintaan

Untuk mengelola alur permintaan, lakukan hal berikut:

  • Gunakan Pub/Sub sebagai buffer yang andal: terapkan Pub/Sub untuk menyimpan permintaan inferensi secara andal. Penyiapan ini bertindak sebagai buffer FIFO yang menampung permintaan hingga konsumen memiliki kapasitas untuk memprosesnya, sehingga mencegah server kelebihan beban selama traffic yang tidak terduga.
  • Gunakan langganan pull dengan kontrol alur sisi klien: konfigurasi model langganan Pull. Hal ini memungkinkan aplikasi pelanggan Anda secara eksplisit meminta pesan hanya jika memiliki kapasitas untuk memprosesnya, sehingga memberi Anda kontrol penuh atas tingkat penggunaan.
  • Gabungkan pesan untuk mengisi ukuran batch server: hindari pengiriman satu pesan Pub/Sub sebagai satu permintaan inferensi. Sebagai gantinya, pelanggan harus menggabungkan beberapa pesan ke dalam satu permintaan batch yang sesuai dengan ukuran batch optimal server inferensi Anda (misalnya, cocok dengan setelan max_num_seqs di vLLM). Pendekatan ini membantu memastikan akselerator benar-benar jenuh dan memaksimalkan throughput. Secara khusus, konfigurasi setelan penarikan max_messages pelanggan Anda ke kelipatan max_num_seqs untuk memastikan setiap penerusan model sepenuhnya jenuh.

Penskalaan otomatis pelanggan dan server

Inferensi batch yang efektif memerlukan penskalaan subscriber (terikat CPU) secara berbeda dari server inferensi (terikat GPU atau TPU).

  • Menskalakan pelanggan berdasarkan backlog pekerjaan: konfigurasikan HorizontalPodAutoscaler (HPA) untuk deployment pelanggan Anda berdasarkan metrik num_undelivered_messages dari Pub/Sub. Untuk informasi selengkapnya, lihat Mengoptimalkan penskalaan otomatis Pod berdasarkan metrik. Hitung replika yang ingin Anda gunakan menggunakan persamaan berikut:

    \[ desiredReplicas = \frac{num\_undelivered\_messages}{target\_latency\_seconds \times throughput\_per\_replica} \]

  • Mematuhi kuota infrastruktur: batasi secara eksplisit replika maksimum pelanggan Anda dengan mengonfigurasi setelan maxReplicas di HPA Anda. Jangan menskalakan pelanggan melebihi yang dapat didukung oleh kuota GPU atau TPU server inferensi Anda. Penyediaan pelanggan yang berlebihan akan mengalihkan hambatan ke server inferensi, sehingga meningkatkan persaingan resource tanpa meningkatkan throughput.

  • Menskalakan server inferensi berdasarkan metrik mesin inferensi: menskalakan deployment server inferensi berdasarkan metrik yang diekspor langsung oleh mesin inferensi (tidak hanya melalui CPU/Memori). Misalnya, gunakan setelan vllm:num_requests_waiting untuk vLLM, yang secara langsung mengukur backlog pemrosesan di level server model. Untuk mengetahui informasi selengkapnya, lihat Menskalakan Pod secara otomatis.

Menangani error dan waktu tunggu

Untuk menangani error dan waktu tunggu, lakukan hal berikut:

  • Memperpanjang batas waktu konfirmasi secara proaktif: konfigurasi pelanggan Anda untuk memperpanjang batas waktu konfirmasi (ack) Pub/Sub secara proaktif untuk pesan yang sedang diproses guna mencegah loop pengiriman ulang dan pemrosesan duplikat. Pendekatan ini diperlukan karena tugas inferensi sering kali memerlukan waktu lebih lama daripada periode tunggu default. Sebagai aturan umum, tetapkan periode perpanjangan agar lebih lama daripada waktu inferensi batch terburuk Anda.
  • Mengisolasi kegagalan dengan topik pesan yang dihentikan pengirimannya: aktifkan topik pesan yang dihentikan pengirimannya untuk mengisolasi secara otomatis pesan yang salah format dan gagal dikirim berulang kali. Pendekatan ini mencegah pesan "pil racun" memblokir antrean dan menghentikan seluruh pipeline Anda.
  • Terapkan strategi backoff: jika server inferensi menampilkan error 429 (Terlalu Banyak Permintaan) atau 503 (Layanan Tidak Tersedia), pelanggan harus menangkap error ini dan menerapkan strategi backoff eksponensial, dengan menjeda sementara konsumsi dari Pub/Sub hingga server pulih.

Mengorkestrasi tugas batch offline dalam skala besar

Ikuti praktik terbaik ini untuk memaksimalkan throughput, memastikan efisiensi biaya, menerapkan ketertelusuran yang komprehensif untuk audit, dan menerapkan kuota lanjutan pengelolaan dan prioritas tugas, saat memproses set data yang sangat besar.

Menggunakan JobSet untuk inferensi terdistribusi multi-node

Sebaiknya gunakan resource JobSet Kubernetes untuk mengorkestrasikan workload inferensi terdistribusi yang memerlukan beberapa node untuk beroperasi bersama, seperti model besar yang berjalan di Pod TPU atau cluster GPU multi-node. Job Kubernetes Standar tidak dapat menjamin bahwa semua Pod yang diperlukan dimulai secara bersamaan, yang dapat menyebabkan kebuntuan dalam workload terdistribusi.

JobSet adalah API native Kubernetes yang mengelola grup Tugas sebagai satu unit dan memberikan manfaat berikut untuk inferensi batch:

  • Penjadwalan berkelompok: membantu memastikan semua resource yang diperlukan, seperti slice TPU atau node GPU, tersedia sebelum memulai workload untuk mencegah kebuntuan.
  • Penempatan eksklusif: membantu memastikan bahwa satu JobSet memiliki akses eksklusif ke topologi jaringan (misalnya, slice TPU) untuk memaksimalkan performa interkoneksi.
  • Pemulihan kegagalan: memungkinkan Anda memulai ulang tugas yang direplikasi tertentu atau seluruh set jika pekerja gagal, bergantung pada konfigurasi Anda.

Menggunakan Tugas Terindeks untuk sharding data

Saat Anda menggunakan JobSet, konfigurasi ReplicatedJob untuk menggunakan setelan completionMode: Indexed. Setelan ini secara otomatis memasukkan variabel lingkungan JOB_COMPLETION_INDEX ke setiap Pod. Kode inferensi Anda dapat menggunakan indeks ini untuk memilih secara deterministik shard data unik yang akan diproses.

Misalnya, jika Anda memiliki bucket Cloud Storage dengan 100.000 gambar dan men-deploy JobSet dengan paralelisme 10, setiap 10 Pod akan membaca indeksnya (0-9) saat startup. Pod 0 kemudian dapat menghitung bahwa Pod tersebut harus memproses gambar 0-9.999, sementara Pod 1 memproses 10.000-19.999. Pendekatan ini mengurangi kebutuhan akan layanan antrean tugas terpisah.

Menggunakan pola sidecar untuk saturasi server

Untuk memaksimalkan pemanfaatan akselerator, konfigurasi Pod JobSet Anda dengan dua penampung menggunakan pola sidecar:

  • Server inferensi: server yang dioptimalkan (seperti vLLM) yang berfokus sepenuhnya pada komputasi GPU atau TPU.
  • Driver klien: penampung logika yang secara asinkron mengirimkan permintaan bervolume tinggi ke server di localhost.

Pemisahan ini memastikan bahwa GPU atau TPU tetap sibuk dan tidak pernah menganggur saat menunggu I/O jaringan atau pra-pemrosesan data. Tanpa pendekatan ini, model yang memuat data secara berurutan dapat menyebabkan akselerator menunggu operasi I/O selesai, sehingga menyebabkan kurangnya pemanfaatan. Misalnya, alih-alih menunggu data diproses, driver klien dapat melakukan pengambilan data terlebih dahulu dan terus mengirim permintaan asinkron ke server inferensi, sehingga memastikan antrean permintaan akselerator tetap penuh.

Ringkasan checklist

Kategori Praktik terbaik
Pola arsitektur
Biaya dan throughput
Pengiriman pesan dan penskalaan
Orkestrasi