Dokumen ini menyediakan arsitektur referensi untuk membuat frontend terpadu bagi beberapa model AI yang dihosting secara lokal atau oleh penyedia mana pun, termasuk pihak ketiga dan Google Cloud. Jika semua server inferensi Anda dihosting di Google Kubernetes Engine (GKE), lihat Jaringan untuk penyajian model inferensi AI di GKE.
Arsitektur ini dirancang untuk memungkinkan developer 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 AI guardrails.
- Service Extensions titik penyisipan untuk kemampuan ekstensi 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 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 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 kumpulan 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 dalam 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, semuanya akan berfungsi secara transparan. Jika server inferensi tidak kompatibel dengan OpenAI API, Anda harus menerapkan penerjemah API menggunakan Service Extensions. Arsitektur referensi ini tidak menyertakan penerapan penerjemah API.
- Info Service Extensions: Anda dapat menggunakan info untuk menambahkan
pemrosesan tambahan ke
Load Balancer Aplikasi. Arsitektur dalam desain ini menggunakan info berikut:
- Router berbasis isi:
Router berbasis isi di-deploy di Cloud Run. Router 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 lainnya. Untuk memanggil Apigee dari load balancer, arsitektur dan deployment Terraform menggunakan ekstensi traffic Service Extensions untuk memanggil the Apigee Extension Processor.
- Model Armor: Sistem AI guardrails yang melakukan pemeriksaan keamanan pada perintah inferensi sebelum mencapai server inferensi. Kemudian, sistem ini melakukan pemeriksaan keamanan pada respons yang keluar. Arsitektur ini menggunakan Model Armor untuk AI guardrails, 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. Router 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).
- 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. Dalam arsitektur, replika model terdapat dalam cluster Google Kubernetes Engine (GKE) di belakang GKE Inference Gateway, di Vertex AI, di Cloud Run, di pusat data lokal atau cloud lainnya, dan di belakang endpoint di internet.
Konfigurasi kumpulan replika model
Dalam arsitektur, 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 |
|---|---|---|
| Vertex AI | Replika model berjalan di Vertex AI. Anda memublikasikan endpoint Vertex AI 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. | Vertex AI melakukan penskalaan dan load balancing secara internal. Vertex AI melakukan load balancing berbobot berbasis metrik dan perutean berbasis cache awalan, yang mengoptimalkan penggunaan 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 kumpulan replika GKE. Beberapa replika model dalam GKE secara kolektif membentuk backend tunggal di belakang 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. Jumlah replika dibatasi hanya untuk replika node tunggal. |
| Hybrid | Server inferensi berjalan secara lokal atau di cloud lain. Anda mengonfigurasi a 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 lainnya 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 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 body-based routing
code
membaca nama model dari isi permintaan dan menuliskannya ke header
X-Gateway-Model-Name. - Load balancer menggunakan info 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 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.
- Jika permintaan diizinkan oleh Model Armor, load balancer akan melihat peta URL dan meneruskan permintaan ke layanan backend berdasarkan header kustom nama model. Jika perlu, peta URL akan menulis ulang URL dan jalur permintaan agar sesuai dengan yang diperlukan backend.
- Layanan backend meneruskan permintaan ke load balancer kumpulan replika terkait.
- Load balancer untuk layanan inferensi tertentu menetapkan permintaan ke salah satu replikanya.
- Replika memproses permintaan dan mengirimkan respons kembali.
- 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 deployment contoh:
Dalam contoh ini, perintah ditangani bergantung pada model yang dipilih pengguna:
- Gemma: Semua perintah dirutekan ke kumpulan replika yang menghosting model Gemma.
- Llama: Sistem melakukan load balancing perintah ini secara merata di 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.
Produk yang digunakan
Arsitektur referensi dalam dokumen ini menggunakan produk berikut: Google Cloud
- Cloud Load Balancing: Portofolio load balancer berperforma tinggi, skalabel, global, dan regional.
- 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.
AI guardrails
Sebaiknya gunakan Model Armor untuk AI guardrails. 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 AI guardrails 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 guardrail lainnya seperti NVIDIA NeMo Guardrails.
Pengelolaan API
Arsitektur dalam dokumen ini menggunakan Apigee untuk pengelolaan API, yang di-deploy menggunakan Service Extension 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 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 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 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 Vertex AI
model, Anda harus memilih model identitas untuk
autentikasi:
- Identitas akun layanan (direkomendasikan untuk aplikasi web umum): Aplikasi mengautentikasi pengguna akhir melalui IAP, tetapi aplikasi memanggil Vertex AI menggunakan identitas workload layanan (seperti misalnya 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 mana yang membuat perintah.
- Passthrough identitas pengguna akhir (direkomendasikan untuk auditabilitas yang ketat): Aplikasi mengambil token akses Google OAuth pengguna akhir dan meneruskannya langsung ke Vertex AI di header
Authorization: Bearer. Implementasi ini menyediakan logging Cloud Audit Logs bawaan untuk tindakan pengguna, tetapi mengharuskan setiap pengguna akhir disediakan dengan Google Cloud izin IAM (sepertiroles/aiplatform.user).
Keandalan
Untuk melindungi dari kegagalan regional, replikasi deployment Anda ke region kedua menggunakan Google Cloud arketipe deployment multi-regional.
Efisiensi operasional
- Untuk memantau alur traffic sehingga Anda dapat mengidentifikasi dan mengatasi masalah dengan cepat, gunakan log Cloud Logging untuk Load Balancer Aplikasi internal regional Anda.
- Untuk memfasilitasi 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 API model daftar.
Pengoptimalan performa
- Cloud Run: Untuk mendukung permulaan 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 Penyajian 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 pembuatan yang didukung pengambilan 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 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