Dokumen ini menyediakan arsitektur referensi untuk membuat layanan inferensi multi-model menggunakan Google Kubernetes Engine (GKE). Dalam arsitektur ini, kumpulan inferensi yang dihosting GKE ditempatkan di belakang GKE Inference Gateway. Arsitektur ini memberikan manfaat berikut:
- Satu antarmuka untuk semua permintaan inferensi Anda.
- Perutean cerdas untuk setiap permintaan ke model dan server inferensi yang dapat menanganinya secara paling efisien.
- Otorisasi, keamanan, dan layanan terpusat lainnya.
Dokumen ini ditujukan untuk arsitek jaringan yang bertanggung jawab untuk menyatukan deployment server inferensi yang berjalan di GKE. Jika semua server inferensi Anda tidak dihosting di GKE, lihat Jaringan untuk penyajian model inferensi AI di semua backend. Dokumen ini tidak memberikan panduan tentang cara mendesain aplikasi atau men-deploy model AI generatif individual. Untuk panduan tentang cara men-deploy model, lihat Membangun dan men-deploy model AI generatif dan machine learning di perusahaan.
Arsitektur ini berfungsi dengan arsitektur jaringan aplikasi Cross-Cloud Network untuk aplikasi terdistribusi dan desain lainnya.
Arsitektur
Diagram berikut menunjukkan arsitektur yang berisi Inference Gateway di depan server inferensi yang dihosting GKE. Gateway menyediakan layanan gabungan untuk semua model yang dihosting.
Arsitektur dalam diagram mencakup komponen berikut:
- Endpoint inferensi Private Service Connect: Endpoint terpadu untuk semua model yang dihosting. Pengguna akhir mengirim permintaan inferensi ke alamat IP endpoint. Diagram ini menunjukkan endpoint Private Service Connect dalam satu jaringan Virtual Private Cloud (VPC) konsumen. Anda dapat menghosting endpoint di beberapa jaringan VPC atau di jaringan VPC layanan bersama.
- Inference Gateway: Inference Gateway meningkatkan GKE Gateway
untuk mengoptimalkan cara GKE menyajikan aplikasi dan
workload AI generatif. Gateway ini merutekan traffic ke kumpulan inferensi replika model berdasarkan nama model. Gateway menggunakan pencocokan awalan untuk merutekan traffic dalam kumpulan replika. Jika tidak ada pencocokan awalan, prosesor inferensi Gateway akan menggunakan metrik Prometheus GPU atau TPU untuk memilih replika yang paling sedikit dimuat dalam kumpulan.
Prosesor inferensi juga menangani caching awalan. Dalam arsitektur ini, aplikasi yang berinteraksi dengan pelanggan melakukan panggilan OpenAI
API untuk
mengakses model melalui Gateway. Gateway di-deploy berdasarkan Load Balancer Aplikasi internal regional (
gke-l7-rilb), sehingga tidak dapat diakses langsung dari internet.- Pengelolaan API: Pengelola API menyediakan autentikasi API, keamanan, pembatasan kapasitas, pelacakan kuota, dan layanan pengelolaan API lainnya. Arsitektur ini menggunakan Apigee, tetapi arsitektur ini mendukung opsi lainnya. Untuk memanggil Apigee dari load balancer, arsitektur dan deployment Terraform menggunakan ekstensi traffic Service Extensions untuk memanggil Apigee Extension Processor.
- Model Armor: Sistem pedoman AI yang melakukan pemeriksaan keamanan pada perintah inferensi sebelum sampai ke server inferensi. Kemudian, sistem ini melakukan pemeriksaan keamanan pada respons keluar. Arsitektur ini menggunakan Model Armor untuk pedoman AI, tetapi juga mendukung opsi lain seperti NVIDIA Nemo Guardrails. Deployment Terraform yang disediakan dengan arsitektur referensi ini mencakup konfigurasi Model Armor dasar.
- Kumpulan inferensi: Kumpulan inferensi berisi replika dari model yang sama.
Saat menerima perintah, Gateway menggunakan pencarian
HTTPRouteuntuk memilih kumpulan inferensi berdasarkan ID model. Kumpulan memiliki ukuran awal, tetapi dapat dikonfigurasi untuk penskalaan otomatis. - Kumpulan replika model: Replika model adalah salinan server inferensi yang di-deploy ke satu atau beberapa GPU atau TPU. Replika model dapat berupa node tunggal atau multi-node. Kumpulan replika adalah grup replika model seragam yang berada di depan load balancer. Jika kumpulan replika adalah multi-node, GPU akan terhubung satu sama lain melalui jaringan VPC RDMA backend. Jaringan ini menyediakan jaringan inter-GPU yang selaras dengan rel, tanpa kehilangan data, dan latensi rendah.
Alur permintaan
Sistem merutekan permintaan inferensi sebagai berikut:
- Pengguna akhir mengirim permintaan OpenAI API ke endpoint Private Service Connect. Permintaan ini berisi hal berikut:
- Perintah.
- Nama model, yang harus cocok dengan nama model salah satu server inferensi yang dihosting.
- Endpoint Private Service Connect meneruskan permintaan ke versi Load Balancer Aplikasi internal regional dari Inference Gateway.
- Gateway mengekstrak nama model dari isi permintaan dan menyisipkannya ke header permintaan menggunakan perutean berbasis isi.
- Gateway meneruskan permintaan ke sistem pengelolaan API untuk layanan pengelolaan API yang diperlukan.
- Gateway mengirimkan perintah ke Model Armor untuk pemeriksaan.
- Jika perintah berisi informasi sensitif yang tidak dapat disamarkan, perintah akan diblokir dan Model Armor akan menampilkan respons untuk menunjukkan bahwa pelanggaran kebijakan telah ditemukan.
- Jika perintah berisi informasi sensitif yang dapat disamarkan, atau jika perintah tidak memiliki masalah sama sekali, Model Armor akan menyamarkan informasi sensitif apa pun dan meneruskan perintah.
- Gateway berkonsultasi dengan
HTTPRouteuntuk mendapatkan daftar Kumpulan Inferensi yang cocok dengan model permintaan. Dari daftar ini, Gateway memilih satu berdasarkan prioritas. - Gateway berkonsultasi dengan cache awalan dan beban saat ini untuk semua replika dalam kumpulan, lalu menggunakan informasi tersebut untuk memilih replika.
- Replika memproses permintaan dan mengirimkannya kembali ke Gateway.
- Gateway mengirimkan respons ke Model Armor untuk disetujui atau ditolak.
- Gateway mengirimkan respons kembali ke endpoint Private Service Connect dan ke pengguna akhir.
Diagram berikut menunjukkan tampilan perutean contoh deployment.
Dalam contoh ini, perintah ditangani bergantung pada model yang dipilih pengguna:
- Llama: Sistem melakukan load balancing perintah ini dengan rasio 90/10 antara dua kumpulan replika yang menghosting model Llama. Kedua kumpulan replika ini tidak harus dihosting dengan cara yang sama. Misalnya, satu kumpulan replika dapat dihosting di Vertex AI dan kumpulan replika lainnya dapat dihosting di GKE.
- LoRA-1-gemma atau LoRA-2-gemma: Sistem mengirimkan semua perintah ke kumpulan replika yang sama, yang dapat menangani kedua model.
Dalam semua kasus, Gateway menggunakan kombinasi pencocokan awalan dan beban terendah untuk memilih replika dalam kumpulan yang relevan.
Produk yang digunakan
Arsitektur referensi ini menggunakan produk berikut: Google Cloud
- Google Kubernetes Engine (GKE): Layanan Kubernetes yang dapat Anda gunakan untuk men-deploy dan mengoperasikan aplikasi dalam container dalam skala besar menggunakan infrastruktur Google.
- GKE Inference Gateway: Ekstensi ke Google Kubernetes Engine Gateway yang menyediakan perutean dan load balancing yang dioptimalkan untuk menyajikan workload AI generatif. Gateway ini menyederhanakan deployment, pengelolaan, dan observabilitas workload inferensi AI.
- Virtual Private Cloud (VPC): Sistem virtual yang menyediakan fungsi jaringan global dan skalabel untuk workload Anda. Google Cloud VPC mencakup Peering Jaringan VPC, Private Service Connect, akses layanan pribadi, dan VPC Bersama.
- Private Service Connect: Fitur yang memungkinkan konsumen mengakses layanan terkelola secara pribadi dari dalam jaringan VPC mereka.
- Cloud Run: Platform komputasi serverless yang dapat Anda gunakan untuk menjalankan container langsung pada infrastruktur Google yang bersifat skalabel.
- Apigee: Alat pengelolaan API yang memberi Anda kontrol terperinci atas cara API diakses dan digunakan. Alat ini menyediakan keamanan, pembatasan kapasitas, penerapan kuota, dan analisis.
- Model Armor: Layanan yang memberikan perlindungan untuk resource AI generatif dan agentic Anda terhadap injeksi perintah, kebocoran data sensitif, dan konten berbahaya.
Alternatif desain
Bagian ini menjelaskan alternatif untuk beberapa asumsi dasar arsitektur ini.
Pedoman AI
Sebaiknya gunakan Model Armor untuk pedoman AI. Untuk memusatkan administrasi, sebaiknya panggil langsung dari load balancer, seperti dalam arsitektur ini. Anda juga dapat menerapkan Model Armor dengan cara alternatif berikut:
- Gunakan kebijakan pengelolaan API untuk memanggil Model Armor.
- Deploy Model Armor hanya di replika.
Jika Anda menerapkan pedoman AI selain di endpoint model, Anda dapat menonaktifkan Model Armor di load balancer frontend jika tidak memerlukannya. Jika tidak ingin menggunakan Model Armor, Anda dapat menggunakan ekstensi traffic untuk men-deploy penawaran pedoman lainnya seperti NVIDIA NeMo Guardrails.
Pengelolaan API
Arsitektur dalam dokumen ini menggunakan Apigee untuk pengelolaan API, yang di-deploy menggunakan Ekstensi Layanan load balancer. Jika Apigee tidak memenuhi kebutuhan Anda, Anda dapat menggunakan Service Extensions untuk men-deploy layanan pengelolaan API yang berbeda.
Jika men-deploy pengelolaan API menggunakan Service Extensions tidak memenuhi kebutuhan Anda, Anda mungkin perlu men-deploy jaringan yang berinteraksi dengan klien dan jaringan yang berinteraksi dengan API. Dalam skenario ini, layanan pengelolaan API bertindak sebagai jembatan antara kedua jaringan. Untuk mengetahui informasi tentang cara men-deploy hal ini untuk Apigee, lihat Opsi jaringan Apigee.
Menghubungkan ke jaringan lain
Arsitektur dalam dokumen ini menggunakan satu jaringan VPC konsumen. Namun, Anda dapat membagikan endpoint Private Service Connect ke banyak jaringan lain dengan menggunakan jaringan VPC akses layanan dalam deployment Cross-Cloud Network.
Pertimbangan desain
Saat membangun arsitektur untuk workload Anda, pertimbangkan praktik terbaik dan rekomendasi dalam Google Cloud Well-Architected Framework.
Keamanan, privasi, dan kepatuhan
Untuk menambahkan perlindungan serangan distributed denial-of-service (DDoS), fungsi Web Application Firewall (WAF), dan pemeriksaan alamat IP ke deployment Anda, tambahkan Google Cloud Armor ke Load Balancer Aplikasi internal regional frontend Anda.
Keandalan
Untuk melindungi dari kegagalan regional, replikasi deployment Anda ke region kedua menggunakan Google Cloud arketipe deployment multi-regional.
Pengoptimalan biaya
Untuk rekomendasi pengoptimalan biaya GKE, lihat Praktik terbaik untuk menjalankan aplikasi Kubernetes yang hemat biaya di GKE.
Efisiensi operasional
Pantau performa permintaan inferensi Inference Gateway Anda menggunakan dasbor Inference Gateway. Dasbor ini menampilkan error dan metrik seperti rasio permintaan, latensi, dan saturasi. Gunakan temuan di dasbor untuk membantu mengoptimalkan deployment Anda.
Pengoptimalan performa
Ikuti rekomendasi dalam Ringkasan praktik terbaik inferensi di GKE.
Deployment
Untuk men-deploy contoh implementasi arsitektur ini, gunakan contoh kode Jaringan untuk Penyajian Model Inferensi AI yang tersedia di GitHub.
Langkah berikutnya
- Untuk mengetahui informasi tentang cara menambahkan retrieval-augmented generation (RAG) ke deployment Anda, lihat Konektivitas pribadi untuk aplikasi AI generatif yang mendukung RAG aplikasi.
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Cloud Architecture Center.
Kontributor
Penulis: Victor Moreno | Product Manager, Cloud Networking
Kontributor lainnya:
- Mark Schlagenhauf | Technical Writer, Networking
- James Duncan | Solutions Product Manager
- Ammett Williams | Developer Relations Engineer