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 membangun dan men-deploy layanan Cloud Run yang dapat merespons secara real-time ke peristiwa penskalaan. Artinya, Anda harus:

• Gunakan model yang dimuat dengan cepat dan memerlukan sedikit transformasi ke struktur yang mendukung GPU, serta optimalkan cara pemuatannya.
• Gunakan konfigurasi yang memungkinkan eksekusi maksimum, efisien, dan serentak untuk mengurangi jumlah GPU yang diperlukan untuk melayani 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 container atau mengoptimalkan pemuatannya dari Cloud Storage.

Menyimpan dan memuat kompromi model ML

Berikut adalah perbandingan opsi tersebut:

Lokasi model	Waktu deployment	Pengalaman pengembangan	Waktu startup container	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 gambar berukuran besar.	Tergantung pada ukuran model. Untuk model yang sangat besar, gunakan Cloud Storage untuk mendapatkan performa yang lebih dapat diprediksi, tetapi lebih lambat.	Berpotensi menghasilkan beberapa salinan di Artifact Registry.
Cloud Storage, dimuat menggunakan pemasangan volume FUSE Cloud Storage	Cepat. Model yang didownload selama startup container.	Tidak sulit disiapkan, tidak memerlukan perubahan pada image Docker.	Cepat saat pengoptimalan jaringan. Tidak memparalelkan 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 yang didownload selama startup container.	Sedikit lebih sulit untuk disiapkan, karena Anda harus menginstal Google Cloud CLI pada gambar atau memperbarui kode Anda untuk menggunakan di 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 yang 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 download dari internet. Layanan Anda dapat gagal dimulai jika target download menurun, dan model dasar yang didownload dapat berubah, sehingga menurunkan kualitas. Sebaiknya hosting di bucket Cloud Storage Anda sendiri.	Bergantung pada penyedia hosting model.

Menyimpan model di image container

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

Membangun container yang mencakup model ML dapat memerlukan waktu beberapa saat untuk dibangun. Jika menggunakan Cloud Build, Anda dapat mengonfigurasi Cloud Build untuk menggunakan untuk waktu 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 antar-gambar (hash yang berbeda). Mungkin ada Artifact Registry tambahan biaya karena mungkin ada satu salinan model per gambar jika lapisan model Anda bersifat unik di setiap gambar.

Menyimpan model di Cloud Storage

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

Pertimbangan build, deployment, runtime, dan desain sistem

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

Pada waktu build

Daftar berikut menunjukkan pertimbangan yang harus diperhitungkan saat sedang merencanakan build:

• Pilih model terkuantisasi 4-bit untuk memaksimalkan konkurensi kecuali jika Anda dapat membuktikannya pengaruhnya terhadap kualitas hasil. Kuantisasi menghasilkan model yang lebih kecil dan lebih cepat, mengurangi jumlah memori GPU yang diperlukan untuk menyajikan model, dan dapat meningkatkan paralelisme pada waktu proses. Idealnya, semua model harus dilatih pada kedalaman bit target, bukan dikuantisasikan hanya ke kedalaman tersebut.
• Pilih format model dengan waktu pemuatan yang cepat untuk meminimalkan waktu startup container, 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 pos pemeriksaan format acar.
• Membuat dan menghangatkan cache LLM pada waktu build. Memulai LLM di mesin build saat membangun image Docker. Aktifkan prompt caching dan feed umum atau contoh perintah{i> <i}untuk membantu memanaskan {i> cache<i} agar dapat digunakan di dunia nyata. Menyimpan output yang dihasilkannya yang akan dimuat saat runtime.
• Simpan model inferensi Anda sendiri yang Anda hasilkan selama waktu build. Cara ini menghemat waktu yang signifikan dibandingkan dengan pemuatan model yang disimpan dan diterapkan seperti kuantisasi pada startup container.

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 kemacetan. Pertimbangkan poin-poin utama berikut saat mengonfigurasi pemeriksaan startup:

• Waktu startup yang memadai: Berikan waktu yang cukup untuk container Anda, termasuk model, untuk melakukan inisialisasi dan memuat sepenuhnya.
• Verifikasi kesiapan model: Konfigurasi pemeriksaan Anda agar hanya lulus saat aplikasi siap melayani permintaan. Sebagian besar mesin inferensi otomatis mencapai hal ini saat model dimuat ke dalam memori GPU, sehingga mencegah permintaan yang bersifat dini.

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

• Model pramuat: Lihat dokumentasi Olama untuk mendapatkan panduan tentang pramuat model Anda selama startup.

Saat waktu proses

• Kelola secara aktif panjang konteks yang didukung. Semakin kecil jendela konteks yang didukung, semakin banyak kueri yang dapat Anda dukung untuk berjalan secara paralel. Detail bagaimana melakukan ini tergantung pada kerangka kerja.
• Gunakan cache LLM yang Anda buat pada waktu build. Menyediakan flag yang sama digunakan selama waktu build saat Anda membuat cache awalan dan perintah.
• 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 terkuantisasi jika framework Anda mendukungnya. Hal ini dapat mengurangi kebutuhan memori per kueri dan memungkinkan konfigurasi paralelisme. 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 yang Anda bisa tanpa mengalami error kehabisan memori.
• Konfigurasi permintaan serentak Anda dengan benar di dalam kode layanan. Pastikan kode layanan Anda yang telah dikonfigurasi agar berfungsi dengan setelan konkurensi layanan Cloud Run.
• Periksa apakah kerangka kerja Anda memiliki opsi untuk meningkatkan performa startup container (misalnya, menggunakan paralelisasi pemuatan model).

Pada tingkat desain sistem

• Tambahkan cache semantik jika sesuai. Dalam beberapa kasus, meng-cache seluruh kueri dan respons dapat menjadi cara yang bagus untuk membatasi biaya kueri umum.
• Mengontrol varians dalam field preamble. Cache perintah hanya berguna jika berisi prompt secara berurutan. Cache secara efektif di-cache terlebih dahulu. Penyisipan atau pengeditan dalam urutan menunjukkan bahwa urutan tersebut tidak di-cache atau hanya ada sebagian.

Penskalaan otomatis dan GPU

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

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

Permintaan serentak maksimum per instance

Permintaan serentak maksimum per instance mengontrol jumlah maksimum permintaan yang dikirim Cloud Run ke satu instance sekaligus. Anda harus menyesuaikan permintaan serentak untuk mencocokkan konkurensi maksimum yang dapat ditangani kode dalam setiap instance performa yang baik.

Workload AI dan konkurensi maksimum

Saat menjalankan workload inferensi AI pada GPU di setiap instance, konkurensi yang dapat ditangani kode dengan kinerja yang baik bergantung pada kerangka kerja dan implementasinya. Hal-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 akses ke GPU, yang menyebabkan peningkatan latensi. Jika permintaan serentak maksimum disetel terlalu rendah, GPU mungkin kurang dimanfaatkan yang menyebabkan Cloud Run menyebarkan skala instance lebih banyak dari yang diperlukan.

Aturan praktis untuk mengonfigurasi permintaan serentak maksimum untuk AI adalah:

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

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

Perlu diperhatikan bahwa formula ini hanyalah aturan praktis. Jumlah maksimum serentak yang ideal setelan permintaan kustom bergantung pada detail spesifik terlepas dari implementasi layanan. Untuk mencapai performa optimal yang sebenarnya, sebaiknya menguji pemuatan layanan Anda dengan kapasitas maksimum yang berbeda setelan permintaan serentak untuk mengevaluasi opsi mana yang memiliki performa terbaik.

Throughput versus latensi versus kompromi biaya

Lihat Trafficput versus latensi versus kompromi biaya dampak permintaan serentak maksimum terhadap throughput, latensi, dan biaya. Perhatikan bahwa semua layanan Cloud Run yang menggunakan GPU selalu dialokasikan oleh CPU.