Dokumen ini menyediakan arsitektur referensi untuk membuat frontend terpadu bagi beberapa model AI yang dihosting secara lokal atau oleh penyedia mana pun, termasuk model AI pihak ketiga dan Google Cloud. Jika semua server inferensi Anda dihosting di Google Kubernetes Engine (GKE), lihat Jaringan untuk penayangan model inferensi AI di GKE.
Arsitektur ini dirancang agar developer Anda dapat memilih model tanpa harus menentukan alamat IP individual untuk setiap model. Sebagai gantinya, developer mengirim permintaan OpenAI API yang menyertakan nama model ke endpoint frontend. Sistem dalam arsitektur merutekan permintaan ke backend yang menghosting model yang ditentukan. Load balancer frontend dalam arsitektur menyediakan fungsi administratif terpusat berikut:
- Endpoint frontend tunggal untuk semua panggilan model, terlepas dari cara Anda menghosting model.
- Fungsi pengelolaan API.
- Checkpoint untuk pemandu AI.
- Titik penyisipan Service Extensions untuk ekstensibilitas di masa mendatang.
Dokumen ini ditujukan untuk administrator jaringan dan administrator aplikasi AI generatif yang ingin menempatkan model AI generatif baru atau yang sudah ada di belakang satu endpoint inferensi. Dokumen ini tidak memberikan panduan tentang cara mendesain aplikasi atau men-deploy setiap model AI generatif. Untuk mendapatkan panduan tentang cara men-deploy model, lihat Membangun dan men-deploy model AI generatif dan machine learning di perusahaan. Arsitektur ini kompatibel dengan arsitektur jaringan aplikasi seperti Cross-Cloud Network untuk aplikasi terdistribusi dan dengan desain lainnya.
Arsitektur
Diagram berikut menunjukkan arsitektur dengan endpoint di jaringan konsumen yang mengarah ke frontend Load Balancer Aplikasi internal regional. Load balancer ini menggunakan nama model yang ditentukan untuk merutekan permintaan ke set replika model yang dihosting secara lokal atau oleh penyedia mana pun. Load balancer frontend 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 di satu jaringan Virtual Private Cloud (VPC) konsumen. Anda dapat menghosting endpoint di beberapa jaringan VPC atau di jaringan VPC layanan bersama.
- Load Balancer Aplikasi internal regional: Dalam arsitektur ini, load balancer frontend adalah Load Balancer Aplikasi internal regional. Load balancer frontend merutekan traffic ke kumpulan replika berdasarkan nama model yang ditentukan dalam permintaan. Dalam arsitektur ini, aplikasi pelanggan melakukan panggilan OpenAI API ke load balancer. Jika server inferensi backend kompatibel dengan OpenAI API, maka semuanya akan berfungsi secara transparan. Jika server inferensi tidak kompatibel dengan OpenAI API, Anda harus menerapkan penerjemah API menggunakan Ekstensi Layanan. Arsitektur referensi ini tidak mencakup penerapan penerjemah API.
- Panggilan ekstensi layanan: Anda dapat menggunakan panggilan untuk menambahkan pemrosesan tambahan ke Load Balancer Aplikasi. Arsitektur dalam desain ini menggunakan
keterangan berikut:
- Router berbasis isi:
Router berbasis isi di-deploy di Cloud Run. Fungsi ini membaca nama model dari isi permintaan OpenAI API dan menuliskannya ke kolom
X-Gateway-Model-Namedi header. Peta URL load balancer menggunakan kolom untuk meneruskan permintaan ke layanan backend yang sesuai. Deployment Terraform yang disediakan dengan arsitektur referensi ini mencakup konfigurasi router berbasis isi. - Apigee: Pengelola API yang menyediakan autentikasi API, keamanan, pembatasan kapasitas, pelacakan kuota, dan layanan pengelolaan API lainnya. Arsitektur ini menggunakan Apigee, tetapi arsitektur ini mendukung opsi lain. Untuk memanggil Apigee dari load balancer, arsitektur dan deployment Terraform menggunakan ekstensi traffic Service Extensions untuk memanggil Prosesor Ekstensi Apigee.
- Model Armor: Sistem pedoman AI yang melakukan pemeriksaan keamanan pada perintah inferensi sebelum sampai ke server inferensi. Kemudian, Gemini melakukan pemeriksaan keamanan pada respons yang keluar. Arsitektur ini menggunakan Model Armor untuk pembatasan AI, tetapi juga mendukung opsi lain seperti NVIDIA NeMo Guardrails. Deployment Terraform yang disediakan dengan arsitektur referensi ini mencakup konfigurasi Model Armor dasar.
- Router berbasis isi:
Router berbasis isi di-deploy di Cloud Run. Fungsi ini membaca nama model dari isi permintaan OpenAI API dan menuliskannya ke kolom
- Layanan backend: Load balancer merutekan permintaan ke layanan backend berdasarkan nama model dalam permintaan. Layanan backend berisi grup endpoint jaringan (NEG).
- Set replika model: Replika model adalah salinan server inferensi yang di-deploy ke satu atau beberapa GPU atau TPU. Replika model dapat berupa satu node atau multi-node. Set replika adalah grup replika model seragam yang dihubungkan oleh load balancer. Dalam arsitektur, replika model terdapat di cluster Google Kubernetes Engine (GKE) di belakang GKE Inference Gateway, di Gemini Enterprise Agent Platform, di Cloud Run, di pusat data lokal atau cloud lainnya, dan di belakang endpoint di internet.
Konfigurasi set replika model
Dalam arsitektur ini, load balancer frontend mengarahkan traffic ke layanan backend tertentu berdasarkan nama model. Server inferensi untuk model yang ditentukan dapat dihosting dalam salah satu konfigurasi yang dijelaskan dalam tabel berikut.
| Jenis kumpulan replika | Deskripsi | Load balancing replika |
|---|---|---|
| Agent Platform | Replika model berjalan di Agent Platform. Anda memublikasikan endpoint Agent Platform sebagai Grup Endpoint Jaringan (NEG) Private Service Connect. Load balancer frontend menggunakan NEG Private Service Connect sebagai backend untuk setiap model yang berbeda, dengan setiap model disusun sebagai layanan backend. | Agent Platform melakukan penskalaan dan load balancing secara internal. Agent Platform melakukan load balancing berbobot berbasis metrik dan perutean berbasis cache awalan, yang mengoptimalkan pemanfaatan resource dan mempercepat inferensi. Untuk mengetahui informasi selengkapnya, lihat Men-deploy model ke endpoint. |
| GKE | Server inferensi berjalan sebagai Pod di cluster GKE dalam jaringan VPC set replika GKE. Beberapa replika model dalam GKE secara kolektif membentuk backend tunggal di balik Inference Gateway. Inference Gateway memublikasikan endpoint Private Service Connect yang diakses oleh load balancer frontend menggunakan NEG Private Service Connect. | Inference Gateway menyediakan load balancing yang mendukung model untuk backend inferensi di cluster GKE. Inference Gateway menggunakan pencocokan awalan jika berlaku. Jika tidak ada kecocokan awalan, Inference Gateway akan mendistribusikan permintaan berdasarkan metrik GPU atau TPU. Konfigurasi ini mendukung Penskalaan Otomatis Pod Horizontal. |
| Cloud Run | Server inferensi berjalan di Cloud Run. Cloud Run memublikasikan endpoint yang diakses oleh load balancer frontend menggunakan NEG Serverless. | Cloud Run secara otomatis menskalakan jumlah replika berdasarkan traffic. Fitur ini hanya terbatas pada replika node tunggal. |
| Hybrid | Server inferensi berjalan di infrastruktur lokal atau di cloud lain. Anda mengonfigurasi Load Balancer Jaringan proxy internal regional di jaringan VPC perutean. Load balancer ini memublikasikan endpoint Private Service Connect yang diakses oleh load balancer frontend menggunakan NEG Private Service Connect. Load balancer internal di jaringan VPC perutean pada gilirannya memiliki backend NEG hybrid yang mengarah ke alamat IP load balancer lokal atau cloud lain di depan server inferensi lokal. | Mekanisme load balancing load balancer eksternal dikonfigurasi oleh administrator fasilitas eksternal. |
| Internet | Server inferensi yang dapat diakses dari alamat IP internet publik. Load balancer frontend memiliki backend NEG internet yang mengarah ke alamat IP model yang dihosting di internet. | Penyedia layanan terkelola menangani penskalaan. |
Alur permintaan
Sistem merutekan permintaan inferensi sebagai berikut:
- Pengguna akhir mengirim permintaan OpenAI API ke endpoint Private Service Connect. Permintaan ini berisi hal-hal
berikut:
- Perintah.
- Nama model, yang harus cocok dengan nama model salah satu server inferensi yang dihosting.
- Endpoint Private Service Connect meneruskan permintaan ke Load Balancer Aplikasi internal frontend.
- Load balancer meneruskan permintaan ke Service Extensions.
- Kode perutean berbasis isi
Service Extensions
membaca nama model dari isi permintaan dan menuliskannya ke header
X-Gateway-Model-Name. - Load balancer menggunakan pemanggilan ekstensi traffic Service Extensions untuk mengirim permintaan ke sistem pengelolaan API untuk layanan pengelolaan API yang diperlukan.
- Load balancer menggunakan info ekstensi traffic Service Extensions
untuk mengirim perintah ke Model Armor guna melakukan penapisan.
- Jika perintah berisi informasi sensitif yang tidak dapat disamarkan, perintah akan diblokir dan Model Armor akan menampilkan respons untuk menunjukkan bahwa telah ditemukan pelanggaran kebijakan.
- Jika perintah berisi informasi sensitif yang dapat disamarkan, atau jika perintah tidak memiliki masalah sama sekali, Model Armor akan menyamarkan informasi sensitif dan meneruskan perintah tersebut.
- Jika permintaan diizinkan oleh Model Armor, load balancer akan memeriksa peta URL dan meneruskan permintaan ke layanan backend berdasarkan header kustom nama model. Jika perlu, peta URL menulis ulang URL dan jalur permintaan agar sesuai dengan yang dibutuhkan backend.
- Layanan backend meneruskan permintaan ke load balancer set replika terkait.
- Load balancer untuk layanan inferensi tertentu menetapkan permintaan ke salah satu replikanya.
- Replika memproses permintaan dan mengirimkan kembali respons.
- Load Balancer Aplikasi internal regional frontend mengirimkan respons ke Model Armor untuk pemeriksaan.
- Load Balancer Aplikasi 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:
- Gemma: Semua perintah dirutekan ke set replika yang menghosting model Gemma.
- Llama: Sistem menyeimbangkan beban perintah ini secara merata di antara dua set replika yang menghosting model Llama. Kedua set replika ini tidak harus dihosting dengan cara yang sama. Misalnya, satu set replika dapat dihosting di Agent Platform dan set replika lainnya dapat dihosting di GKE.
- LoRA-1-gemma atau LoRA-2-gemma: Sistem mengirimkan semua perintah ke set replika yang sama, yang dapat menangani kedua model.
Produk yang digunakan
Arsitektur referensi dalam dokumen ini menggunakan produk Google Cloud berikut:
- Cloud Load Balancing: Portofolio load balancer global dan regional yang berperforma tinggi dan skalabel.
- Virtual Private Cloud (VPC): Sistem virtual yang menyediakan fungsi jaringan global dan skalabel untuk workload Google Cloud Anda. 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 memungkinkan Anda menjalankan container langsung di atas infrastruktur Google yang bersifat skalabel.
- Apigee: Alat pengelolaan API yang memberi Anda kontrol terperinci atas cara API Anda diakses dan digunakan. Layanan 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.
Batasan AI
Sebaiknya gunakan Model Armor untuk pembatasan 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 pembatasan 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 pembatasan 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 menghadap klien dan jaringan yang menghadap API. Dalam skenario ini, layanan pengelolaan API bertindak sebagai jembatan antara kedua jaringan. Untuk mengetahui informasi tentang cara men-deploy-nya 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 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 dari serangan distributed denial-of-service (DDoS), fungsi Firewall Aplikasi Web (WAF), dan inspeksi alamat IP ke deployment Anda, tambahkan Cloud Armor ke Load Balancer Aplikasi internal regional frontend Anda.
- Untuk menambahkan lapisan autentikasi umum ke semua backend, terapkan Identity-Aware Proxy (IAP) untuk memverifikasi identitas dan menerapkan kebijakan otorisasi.
- Saat merutekan traffic dari aplikasi web ke model Agent Platform, Anda harus memilih model identitas untuk autentikasi:
- Identitas akun layanan (direkomendasikan untuk aplikasi web umum): Aplikasi mengautentikasi pengguna akhir melalui IAP, tetapi memanggil Agent Platform menggunakan identitas beban kerja layanan (seperti Cloud Run, GKE, atau menggunakan identitas pihak ketiga). Implementasi ini mengabstraksi Identity and Access Management (IAM) dari pengguna akhir, tetapi memerlukan logging tingkat aplikasi untuk melacak pengguna yang membuat prompt tertentu.
- Penerusan identitas pengguna akhir (direkomendasikan untuk kemampuan audit yang ketat): Aplikasi mengambil token akses OAuth Google pengguna akhir dan meneruskannya langsung ke Platform Agen di header
Authorization: Bearer. Implementasi ini menyediakan logging Cloud Audit Logs bawaan untuk tindakan pengguna, tetapi mengharuskan setiap pengguna akhir disediakan dengan izin IAM (sepertiroles/aiplatform.user). Google Cloud
Keandalan
Untuk menghindari kegagalan regional, replikasi deployment Anda ke region kedua menggunakan arketipe deployment multi-regionGoogle Cloud .
Efisiensi operasional
- Untuk memantau alur traffic sehingga Anda dapat mengidentifikasi dan memperbaiki masalah dengan cepat, gunakan log Cloud Logging untuk Load Balancer Aplikasi internal regional Anda.
- Untuk mempermudah penemuan model yang didukung organisasi Anda, terapkan daftar yang dapat dikueri untuk menampilkan model yang tersedia. Misalnya, Anda dapat membuat daftar di server yang merespons panggilan list models API.
Pengoptimalan performa
- Cloud Run: Untuk mendukung mulai instance yang lebih cepat, Anda dapat Menyimpan bobot model dalam image container.
- GKE: Ikuti rekomendasi dalam Ringkasan praktik terbaik inferensi di GKE.
Deployment
Untuk men-deploy contoh implementasi arsitektur ini, gunakan contoh kode Jaringan untuk Penayangan Model Inferensi AI yang tersedia di GitHub.
Untuk mengetahui informasi tentang cara men-deploy model AI, lihat referensi berikut:
Langkah berikutnya
- Untuk mengetahui informasi tentang cara menambahkan retrieval-augmented generation ke deployment Anda, lihat Konektivitas pribadi untuk aplikasi AI generatif yang kompatibel dengan RAG.
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.
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