Praktik terbaik: Inferensi AI di Cloud Run dengan GPU

Pratinjau — GPU support for Cloud Run services

Fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dalam Persyaratan Khusus Layanan. Fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Halaman ini memberikan praktik terbaik untuk mengoptimalkan performa saat menggunakan layanan Cloud Run dengan GPU untuk inferensi AI, yang berfokus pada model bahasa besar (LLM).

Anda perlu mem-build dan men-deploy layanan Cloud Run yang dapat merespons peristiwa penskalaan secara real time. Artinya, Anda harus:

• Gunakan model yang dimuat dengan cepat dan memerlukan transformasi minimal ke dalam struktur yang siap GPU, serta optimalkan cara model dimuat.
• Gunakan konfigurasi yang memungkinkan eksekusi serentak yang maksimum dan efisien untuk mengurangi jumlah GPU yang diperlukan untuk menayangkan permintaan target per detik sekaligus menekan biaya.

Cara yang direkomendasikan untuk memuat model ML besar di Cloud Run

Google merekomendasikan untuk menyimpan model ML di dalam image penampung atau mengoptimalkan pemuatan dari Cloud Storage.

Kompromi penyimpanan dan pemuatan model ML

Berikut adalah perbandingan opsi:

Lokasi model	Waktu deployment	Pengalaman pengembangan	Waktu startup penampung	Biaya penyimpanan
Image container	Lambat. Image yang berisi model besar akan memerlukan waktu lebih lama untuk diimpor ke Cloud Run.	Perubahan pada image container akan memerlukan deployment ulang, yang mungkin lambat untuk image berukuran besar.	Bergantung pada ukuran model. Untuk model yang sangat besar, gunakan Cloud Storage untuk performa yang lebih dapat diprediksi, tetapi lebih lambat.	Mungkin ada beberapa salinan di Artifact Registry.
Cloud Storage, dimuat menggunakan pemasangan volume Cloud Storage FUSE	Cepat. Model didownload selama startup container.	Tidak sulit disiapkan, tidak memerlukan perubahan pada image docker.	Cepat saat pengoptimalan jaringan. Tidak melakukan paralelisasi download.	Satu salinan di Cloud Storage.
Cloud Storage, didownload secara serentak menggunakan perintah Google Cloud CLI gcloud storage cp atau Cloud Storage API seperti yang ditunjukkan dalam contoh kode download serentak pengelola transfer.	Cepat. Model didownload selama startup container.	Sedikit lebih sulit disiapkan, karena Anda harus menginstal Google Cloud CLI pada image atau mengupdate kode untuk menggunakan Cloud Storage API.	Cepat saat pengoptimalan jaringan. Google Cloud CLI mendownload file model secara paralel, sehingga lebih cepat daripada pemasangan FUSE.	Satu salinan di Cloud Storage.
Internet	Cepat. Model didownload selama startup container.	Biasanya lebih sederhana (banyak framework mendownload model dari repositori pusat).	Biasanya buruk dan tidak dapat diprediksi: Framework dapat menerapkan transformasi model selama inisialisasi. (Anda harus melakukannya pada waktu build). Host dan library model untuk mendownload model mungkin tidak efisien. Ada risiko keandalan yang terkait dengan mendownload dari internet. Layanan Anda dapat gagal dimulai jika target download tidak aktif, dan model pokok yang didownload dapat berubah, sehingga menurunkan kualitas. Sebaiknya hosting di bucket Cloud Storage Anda sendiri.	Bergantung pada penyedia hosting model.

Menyimpan model dalam image container

Menyimpan model ML dalam image container yang di-deploy ke Cloud Run akan mendapatkan manfaat dari pengoptimalan streaming image container bawaan Cloud Run, yang memaksimalkan waktu pemuatan file tanpa pengoptimalan jaringan tambahan.

Membangun container yang menyertakan model ML dapat memerlukan waktu beberapa saat. Jika menggunakan Cloud Build, Anda dapat mengonfigurasi Cloud Build untuk menggunakan mesin yang lebih besar untuk build yang lebih cepat. Untuk melakukannya, build image menggunakan file konfigurasi build yang memiliki langkah-langkah berikut:

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'IMAGE', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'IMAGE']
images:
- IMAGE
options:
 machineType: 'E2_HIGHCPU_32'
 diskSizeGb: '500'
 

Dapat membuat satu salinan model per gambar jika lapisan yang berisi model berbeda di antara gambar (hash yang berbeda). Mungkin ada biaya Artifact Registry tambahan karena mungkin ada satu salinan model per gambar jika lapisan model Anda unik di setiap gambar.

Menyimpan model di Cloud Storage

Untuk mengoptimalkan pemuatan model ML saat memuat model ML dari Cloud Storage, baik menggunakan mount volume Cloud Storage maupun langsung menggunakan Cloud Storage API atau command line, Anda harus menggunakan VPC Langsung dengan nilai setelan traffic keluar ditetapkan ke all-traffic, bersama dengan Private Service Connect.

Memuat model dari internet

Untuk mengoptimalkan pemuatan model ML dari internet, rutekan semua traffic melalui jaringan VPC dengan nilai setelan traffic keluar ditetapkan ke all-traffic dan siapkan Cloud NAT untuk menjangkau internet publik dengan bandwidth tinggi.

Pertimbangan build, deployment, runtime, dan desain sistem

Bagian berikut menjelaskan pertimbangan untuk build, deployment, runtime, dan desain sistem.

Pada waktu build

Daftar berikut menunjukkan pertimbangan yang perlu Anda pertimbangkan saat merencanakan build:

• Pilih image dasar yang baik. Anda harus memulai dengan image dari Deep Learning Containers atau NVIDIA container registry untuk framework ML yang Anda gunakan. Image ini telah menginstal paket terkait performa terbaru. Sebaiknya jangan membuat image kustom.
• Pilih model kuantisasi 4-bit untuk memaksimalkan konkurensi, kecuali jika Anda dapat membuktikan bahwa model tersebut memengaruhi kualitas hasil. Kuantifikasi menghasilkan model yang lebih kecil dan lebih cepat, mengurangi jumlah memori GPU yang diperlukan untuk menayangkan model, dan dapat meningkatkan paralelisme pada waktu proses. Idealnya, model harus dilatih pada kedalaman bit target, bukan dikuantifikasi ke kedalaman bit target.
• Pilih format model dengan waktu pemuatan yang cepat untuk meminimalkan waktu startup penampung, seperti GGUF. Format ini mencerminkan jenis kuantisasi target secara lebih akurat dan memerlukan lebih sedikit transformasi saat dimuat ke GPU. Untuk alasan keamanan, jangan gunakan checkpoint berformat pickle.
• Membuat dan memanaskan cache LLM pada waktu build. Mulai LLM di mesin build saat mem-build image docker. Aktifkan penyimpanan ke cache perintah dan masukkan perintah umum atau contoh untuk membantu memanaskan cache untuk penggunaan di dunia nyata. Simpan output yang dihasilkannya untuk dimuat saat runtime.
• Simpan model inferensi Anda sendiri yang Anda buat selama waktu build. Hal ini menghemat waktu yang signifikan dibandingkan dengan memuat model yang disimpan secara kurang efisien dan menerapkan transformasi seperti kuantisasi saat memulai penampung.

Saat deployment

1. Pastikan Anda menetapkan konkurensi layanan secara akurat di Cloud Run.
2. Sesuaikan pemeriksaan startup berdasarkan konfigurasi Anda.

Pemeriksaan startup menentukan apakah container telah dimulai dan siap menerima traffic. Pertimbangkan poin-poin penting berikut saat mengonfigurasi pemeriksaan startup:

• Waktu startup yang memadai: Berikan waktu yang cukup bagi penampung Anda, termasuk model, untuk melakukan inisialisasi dan pemuatan sepenuhnya.
• Verifikasi kesiapan model: Konfigurasikan probe agar hanya lulus jika aplikasi Anda siap menayangkan permintaan. Sebagian besar mesin penayangan secara otomatis mencapai hal ini saat model dimuat ke memori GPU, sehingga mencegah permintaan yang terlalu dini.

Perhatikan bahwa Ollama dapat membuka port TCP sebelum model dimuat. Untuk mengatasi hal ini:

• Memuat ulang model: Lihat dokumentasi Ollama untuk mendapatkan panduan tentang memuat ulang model selama startup.

Pada waktu proses

• Mengelola panjang konteks yang didukung secara aktif. Makin kecil jendela konteks yang Anda dukung, makin banyak kueri yang dapat Anda dukung untuk berjalan secara paralel. Detail cara melakukannya bergantung pada framework.
• Gunakan cache LLM yang Anda buat pada waktu build. Berikan flag yang sama dengan yang Anda gunakan selama waktu build saat Anda membuat cache perintah dan awalan.
• Muat dari model tersimpan yang baru saja Anda tulis. Lihat Kompromi penyimpanan dan pemuatan model untuk mengetahui perbandingan cara memuat model.
• Pertimbangkan untuk menggunakan cache nilai kunci kuantisasi jika framework Anda mendukungnya. Hal ini dapat mengurangi persyaratan memori per kueri dan memungkinkan konfigurasi paralelisme yang lebih banyak. Namun, hal ini juga dapat memengaruhi kualitas.
• Sesuaikan jumlah memori GPU yang akan dicadangkan untuk bobot model, aktivasi, dan cache nilai kunci. Tetapkan setinggi mungkin tanpa mendapatkan error kehabisan memori.
• Konfigurasikan konkurensi dengan benar di dalam kode layanan Anda. Pastikan kode layanan Anda dikonfigurasi agar berfungsi dengan setelan konkurensi layanan Cloud Run.
• Periksa apakah framework Anda memiliki opsi untuk meningkatkan performa startup penampung (misalnya, menggunakan paralelisasi pemuatan model).

Di tingkat desain sistem

• Tambahkan cache semantik jika sesuai. Dalam beberapa kasus, menyimpan seluruh kueri dan respons dalam cache dapat menjadi cara yang bagus untuk membatasi biaya kueri umum.
• Mengontrol varians dalam preamble Anda. Cache perintah hanya berguna jika berisi perintah secara berurutan. Cache di-cache dengan awalan secara efektif. Penyisipan atau pengeditan dalam urutan berarti bahwa penyisipan atau pengeditan tersebut tidak di-cache atau hanya ada sebagian.

Penskalaan otomatis dan GPU

Cloud Run otomatis menskalakan jumlah instance dari setiap revisi berdasarkan faktor-faktor seperti penggunaan CPU dan konkurensi permintaan. Namun, Cloud Run tidak otomatis menskalakan jumlah instance berdasarkan penggunaan GPU.

Untuk revisi dengan GPU, jika revisi tidak memiliki penggunaan CPU yang signifikan, Cloud Run akan meningkatkan skala untuk serentak permintaan. Untuk mencapai penskalaan optimal untuk konkurensi permintaan, Anda harus menetapkan permintaan serentak maksimum per instance yang optimal, seperti yang dijelaskan di bagian berikutnya.

Permintaan serentak maksimum per instance

Setelan permintaan serentak maksimum per instance mengontrol jumlah maksimum permintaan yang dikirim Cloud Run ke satu instance sekaligus. Anda harus menyesuaikan konkurensi agar cocok dengan konkurensi maksimum yang dapat ditangani kode di dalam setiap instance dengan performa yang baik.

Konkurensi maksimum dan workload AI

Saat menjalankan beban kerja inferensi AI pada GPU di setiap instance, konkurensi maksimum yang dapat ditangani kode dengan performa yang baik bergantung pada detail framework dan implementasi tertentu. Hal berikut memengaruhi cara Anda menetapkan setelan permintaan serentak maksimum yang optimal:

• Jumlah instance model yang dimuat ke GPU
• Jumlah kueri paralel per model
• Penggunaan pengelompokan
• Parameter konfigurasi batch tertentu
• Jumlah pekerjaan non-GPU

Jika permintaan serentak maksimum ditetapkan terlalu tinggi, permintaan mungkin akan menunggu di dalam instance untuk mendapatkan akses ke GPU, yang menyebabkan peningkatan latensi. Jika permintaan serentak maksimum ditetapkan terlalu rendah, GPU mungkin tidak digunakan secara maksimal, sehingga Cloud Run menskalakan lebih banyak instance daripada yang diperlukan.

Aturan umum untuk mengonfigurasi permintaan serentak maksimum untuk beban kerja AI adalah:

(Number of model instances * parallel queries per model) + (number of model instances * ideal batch size)

Misalnya, instance memuat 3 instance model ke GPU, dan setiap instance model dapat menangani 4 kueri paralel. Ukuran batch yang ideal juga 4 karena itu adalah jumlah kueri paralel yang dapat ditangani oleh setiap instance model. Dengan aturan umum, Anda akan menetapkan permintaan serentak maksimum 24: (3 * 4) + (3 * 4).

Perhatikan bahwa formula ini hanyalah aturan umum. Setelan permintaan serentak maksimum yang ideal bergantung pada detail spesifik penerapan Anda. Untuk mencapai performa optimal yang sebenarnya, sebaiknya uji beban layanan Anda dengan setelan permintaan serentak maksimum yang berbeda untuk mengevaluasi opsi mana yang berperforma terbaik.

Kompromi throughput versus latensi versus biaya

Lihat Kompromi throughput versus latensi versus biaya untuk mengetahui dampak permintaan serentak maksimum terhadap throughput, latensi, dan biaya. Perhatikan bahwa semua layanan Cloud Run yang menggunakan GPU memiliki CPU yang selalu dialokasikan.