Praktik terbaik: Inferensi AI di layanan Cloud Run dengan GPU

Halaman ini memberikan praktik terbaik untuk mengoptimalkan performa saat menggunakan layanan Cloud Run dengan GPU untuk inferensi AI, dengan berfokus pada model bahasa besar (LLM). Untuk membuat dan men-deploy layanan Cloud Run yang dapat merespons peristiwa penskalaan secara real time, Anda harus:
  • Gunakan model yang dimuat dengan cepat dan memerlukan transformasi minimal ke dalam struktur yang siap digunakan GPU, dan optimalkan cara pemuatannya.
  • Gunakan konfigurasi yang memungkinkan eksekusi serentak yang efisien dan maksimal untuk mengurangi jumlah GPU yang diperlukan untuk melayani target permintaan 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.

Pertimbangan menyimpan dan memuat model ML

Berikut perbandingan opsinya:

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. Berpotensi memiliki beberapa salinan di Artifact Registry.
Cloud Storage, dimuat menggunakan pemasangan volume Cloud Storage FUSE Cepat. Model didownload selama startup container. Penyiapannya tidak sulit dan tidak memerlukan perubahan pada image Docker. Cepat saat Anda menggunakan pengoptimalan jaringan. Tidak melakukan paralel download. Satu salinan di Cloud Storage.
Cloud Storage, didownload secara bersamaan 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 untuk disiapkan, karena Anda harus menginstal Google Cloud CLI di image atau memperbarui kode untuk menggunakan Cloud Storage API. Cepat saat Anda menggunakan 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 model dan library untuk mendownload model mungkin tidak efisien.
  • Ada risiko keandalan yang terkait dengan mendownload dari internet. Layanan Anda dapat gagal dimulai jika target download tidak berfungsi, dan model 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

Dengan menyimpan model ML di image container, pemuatan model akan memanfaatkan infrastruktur streaming container yang dioptimalkan Cloud Run. Namun, membangun image container yang menyertakan model ML adalah proses yang membutuhkan banyak resource, terutama saat bekerja dengan model besar. Khususnya, proses build dapat mengalami bottleneck pada throughput jaringan. Saat menggunakan Cloud Build, sebaiknya gunakan mesin build yang lebih canggih dengan peningkatan performa komputasi dan jaringan. Untuk melakukannya, bangun 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'

Anda dapat membuat satu salinan model per gambar jika lapisan yang berisi model berbeda di antara gambar (hash yang berbeda). Mungkin ada biaya tambahan Artifact Registry 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 pemasangan volume Cloud Storage atau langsung menggunakan Cloud Storage API atau command line, Anda harus menggunakan Direct VPC dengan nilai setelan keluar yang ditetapkan ke all-traffic, bersama dengan Akses Google Pribadi.

Dengan biaya tambahan, penggunaan Anywhere Cache dapat mengurangi latensi pemuatan model dengan menyimpan data secara efisien di SSD untuk pembacaan yang lebih cepat.

Untuk mengurangi waktu baca model, coba opsi pemasangan berikut untuk mengaktifkan fitur Cloud Storage FUSE:

  • cache-dir: Aktifkan fitur caching file dengan pemasangan volume dalam memori untuk digunakan sebagai direktori pokok untuk menyimpan file. Tetapkan nilai opsi pemasangan cache-dir ke nama volume dalam memori dalam format cr-volume:{volume name}. Misalnya, jika Anda memiliki volume dalam memori bernama in-memory-1 yang ingin digunakan sebagai direktori cache, tentukan cr-volume:in-memory-1. Jika nilai ini ditetapkan, Anda juga dapat menetapkan flag file-cache lainnya yang tersedia untuk dikonfigurasi untuk cache.
  • enable-buffered-read: Setel kolom enable-buffered-read ke true untuk pengambilan data awal asinkron dari bagian objek Cloud Storage ke dalam buffer dalam memori. Hal ini memungkinkan pembacaan berikutnya ditayangkan dari buffer, bukan memerlukan panggilan jaringan. Saat mengonfigurasi kolom ini, Anda juga dapat menetapkan kolom read-global-max-blocks untuk mengonfigurasi jumlah maksimum blok yang tersedia untuk pembacaan yang di-buffer di semua handle file.

Jika cache-dir dan enable-buffered-read digunakan, cache-dir akan diprioritaskan. Perhatikan bahwa mengaktifkan salah satu fitur ini akan mengubah penghitungan resource proses Cloud Storage FUSE agar dihitung dalam batas memori container. Pertimbangkan untuk menaikkan batas memori container dengan mengikuti petunjuk cara mengonfigurasi batas memori.

Memuat model dari internet

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

Pertimbangan desain sistem, build, deployment, dan runtime

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

Pada waktu build

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

  • Pilih gambar dasar yang bagus. Anda harus memulai dengan image dari Deep Learning Containers atau NVIDIA container registry untuk framework ML yang Anda gunakan. Image ini telah diinstal dengan 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. Kuantisasi menghasilkan model yang lebih kecil dan lebih cepat, sehingga mengurangi jumlah memori GPU yang dibutuhkan untuk menyajikan model, dan dapat meningkatkan paralelisme pada waktu eksekusi. Idealnya, model harus dilatih pada kedalaman bit target, bukan dikuantisasi ke kedalaman bit tersebut.
  • Pilih format model dengan waktu pemuatan yang cepat untuk meminimalkan waktu startup container, seperti GGUF. Format ini secara lebih akurat mencerminkan jenis kuantisasi target dan memerlukan lebih sedikit transformasi saat dimuat ke GPU. Untuk alasan keamanan, jangan gunakan titik pemeriksaan format pickle.
  • Membuat dan menginisialisasi cache LLM pada waktu build. Mulai LLM di mesin build saat membangun image Docker. Aktifkan penyimpanan ke cache perintah dan berikan perintah umum atau contoh untuk membantu menginisialisasi cache agar siap digunakan di dunia nyata. Simpan output yang dihasilkan untuk dimuat saat runtime.
  • Simpan model inferensi Anda sendiri yang Anda buat selama waktu build. Hal ini menghemat waktu secara signifikan dibandingkan dengan memuat model yang disimpan secara kurang efisien dan menerapkan transformasi seperti kuantisasi saat startup penampung.

Saat deployment

Daftar berikut menunjukkan pertimbangan yang perlu Anda perhatikan saat Anda merencanakan 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 mulai yang memadai: Berikan waktu yang cukup bagi penampung, termasuk model, untuk melakukan inisialisasi dan memuat sepenuhnya.
  • Verifikasi kesiapan model: Konfigurasi pemeriksaan Anda agar hanya lulus saat aplikasi Anda siap melayani permintaan. Sebagian besar mesin inferensi otomatis mencapai hal ini saat model dimuat ke dalam memori GPU, sehingga mencegah permintaan yang terlalu dini.

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

  • Memuat model terlebih dahulu: Lihat dokumentasi Ollama untuk mendapatkan panduan tentang cara memuat model terlebih dahulu saat startup.

Saat waktu proses

  • Mengelola panjang konteks yang didukung secara aktif. Makin kecil jendela konteks yang Anda dukung, makin banyak kueri yang dapat Anda dukung untuk dijalankan secara paralel. Detail cara melakukannya bergantung pada framework.
  • Gunakan cache LLM yang Anda buat pada waktu build. Berikan tanda 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 terkuantisasi jika framework Anda mendukungnya. Hal ini dapat mengurangi persyaratan memori per-kueri dan memungkinkan konfigurasi paralelisme yang lebih besar. Namun, hal ini juga dapat memengaruhi kualitas.
  • Sesuaikan jumlah memori GPU yang akan dicadangkan untuk bobot model, aktivasi, dan cache key-value. Tetapkan setinggi yang Anda bisa tanpa mendapatkan error kehabisan memori.
  • Periksa apakah framework Anda memiliki opsi untuk meningkatkan performa startup penampung (misalnya, menggunakan paralelisasi pemuatan model).
  • Konfigurasi konkurensi dengan benar di dalam kode layanan Anda. Pastikan kode layanan Anda dikonfigurasi untuk berfungsi dengan setelan konkurensi layanan Cloud Run Anda.

Di tingkat desain sistem

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

Penskalaan Otomatis dan GPU

Jika Anda menggunakan penskalaan otomatis Cloud Run default, Cloud Run akan otomatis menskalakan jumlah instance setiap revisi berdasarkan faktor seperti pemanfaatan 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 yang 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 sesuai 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 di GPU di setiap instance, konkurensi maksimum yang dapat ditangani kode dengan performa yang baik bergantung pada framework dan detail implementasi tertentu. Berikut ini memengaruhi cara Anda menetapkan setelan permintaan serentak maksimum yang optimal:

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

Jika jumlah permintaan serentak maksimum diatur terlalu tinggi, permintaan mungkin akan menunggu di dalam instance untuk mengakses GPU, yang akan meningkatkan latensi. Jika jumlah permintaan serentak maksimum diatur terlalu rendah, GPU mungkin akan kurang dimanfaatkan sehingga menyebabkan Cloud Run menambah jumlah instance lebih daripada yang diperlukan.

Aturan praktis 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, anggaplah sebuah instance memuat 3 instance model ke GPU, dan setiap instance model dapat menangani 4 kueri paralel. Ukuran batch yang ideal juga 4 karena itulah jumlah kueri paralel yang dapat ditangani setiap instance model. Dengan menggunakan aturan praktis, Anda akan menetapkan permintaan serentak maksimum 24: (3 * 4) + (3 * 4).

Perhatikan bahwa formula ini hanyalah aturan praktis. Setelan jumlah permintaan serentak maksimum yang ideal bergantung pada detail spesifik implementasi Anda. Untuk mencapai performa optimal yang sebenarnya, sebaiknya lakukan uji beban pada layanan Anda dengan berbagai setelan permintaan konkuren maksimum untuk mengevaluasi opsi mana yang memberikan performa terbaik.

Kompromi antara throughput, latensi, dan biaya

Lihat Perbandingan 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 harus dikonfigurasi dengan penagihan berbasis instance.