Tentang GKE Inference Gateway yang didukung oleh llm-d

Halaman ini menjelaskan konsep dan fitur utama GKE Inference Gateway Google Kubernetes Engine (GKE), ekstensi ke GKE Gateway untuk inferensi aplikasi AI generatif yang dioptimalkan.

Halaman ini mengasumsikan bahwa Anda mengetahui hal berikut:

• Orkestrasi AI/ML di GKE
• Terminologi AI generatif
• Konsep jaringan GKE, termasuk Layanan, dan GKE Gateway API
• Load balancing di GKE Cloud de Confiance, terutama cara load balancer berinteraksi dengan GKE

Halaman ini ditujukan untuk persona berikut:

• Engineer machine learning (ML), Admin dan operator platform, serta Spesialis data dan AI yang tertarik menggunakan kemampuan orkestrasi container Kubernetes untuk inferensi workload AI/ML.
• Arsitek cloud dan Spesialis jaringan yang berinteraksi dengan jaringan Kubernetes.

Ringkasan

GKE Inference Gateway adalah ekstensi ke GKE Gateway yang menyediakan load balancing dan pemilihan rute yang dioptimalkan untuk inferensi workload Kecerdasan Buatan (AI) generatif. Layanan ini menyederhanakan deployment, pengelolaan, dan kemampuan observasi workload inferensi AI.

Untuk memilih strategi load balancing yang optimal untuk workload AI/ML Anda, lihat Memilih strategi load balancing untuk inferensi AI di GKE.

Fitur dan manfaat

GKE Inference Gateway menyediakan kemampuan utama berikut untuk inferensi model AI generatif secara efisien untuk aplikasi AI generatif di GKE:

• Metrik yang didukung:
  • KV cache hits: jumlah pencarian yang berhasil di cache nilai kunci (KV).
  • Penggunaan GPU atau TPU: persentase waktu GPU atau TPU memproses secara aktif.
  • Panjang antrean permintaan: jumlah permintaan yang menunggu untuk di proses.
• Load balancing yang dioptimalkan untuk inferensi: mendistribusikan permintaan untuk mengoptimalkan performa penyajian model AI. Layanan ini menggunakan metrik dari server model, seperti KV cache hits dan queue length of pending requests untuk menggunakan akselerator (seperti GPU dan TPU) secara lebih efisien untuk workload AI generatif. Hal ini memungkinkan Prefix-Cache Aware Routing, fitur utama yang mengirimkan permintaan dengan konteks bersama, yang diidentifikasi dengan menganalisis isi permintaan, ke replika model yang sama dengan memaksimalkan cache hits. Pendekatan ini secara signifikan mengurangi komputasi yang berlebihan dan meningkatkan Time-to-First-Token, sehingga sangat efektif untuk AI percakapan, Retrieval-Augmented Generation (RAG), dan workload AI generatif berbasis template lainnya.
• Penyajian model yang di-fine-tune LoRA dinamis: mendukung penyajian model yang di-fine-tune LoRA dinamis pada akselerator umum. Hal ini mengurangi jumlah GPU dan TPU yang diperlukan untuk inferensi model dengan melakukan multiplexing beberapa model yang di-fine-tune LoRA pada model dasar dan akselerator umum.
• Penskalaan otomatis yang dioptimalkan untuk inferensi: GKE Horizontal Pod Autoscaler (HPA) menggunakan metrik server model untuk melakukan penskalaan otomatis, yang membantu memastikan penggunaan resource komputasi yang efisien dan performa inferensi yang dioptimalkan.
• Pemilihan rute yang mendukung model: merutekan permintaan inferensi berdasarkan nama model yang ditentukan dalam OpenAI API spesifikasi dalam cluster GKE Anda. Anda dapat menentukan kebijakan pemilihan rute Gateway, seperti pemisahan traffic dan pencerminan permintaan, untuk mengelola berbagai versi model dan menyederhanakan peluncuran model. Misalnya, Anda dapat merutekan permintaan untuk nama model tertentu ke objek InferencePool yang berbeda, yang masing-masing menginferensi versi model yang berbeda. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi hal ini, lihat Mengonfigurasi Pemilihan Rute Berbasis Isi.
• Keamanan AI dan pemfilteran konten terintegrasi: GKE Inference Gateway terintegrasi dengan Cloud de Confiance Model Armor untuk menerapkan pemeriksaan keamanan AI dan pemfilteran konten ke perintah dan respons di gateway. Anda juga dapat menggunakan NVIDIA NeMo Guardrails. Model Armor menyediakan log permintaan, respons, dan pemrosesan untuk analisis dan pengoptimalan retrospektif. Antarmuka terbuka GKE Inference Gateway memungkinkan penyedia dan developer pihak ketiga mengintegrasikan layanan kustom ke dalam proses permintaan inferensi.
• Inferensi khusus model Priority: memungkinkan Anda menentukan inferensi Priority model AI. Prioritaskan permintaan yang sensitif terhadap latensi daripada tugas inferensi batch yang toleran terhadap latensi. Misalnya, Anda dapat memprioritaskan permintaan dari aplikasi yang sensitif terhadap latensi dan menghilangkan tugas yang kurang sensitif terhadap waktu saat resource dibatasi.
• Pemilihan rute berbasis latensi yang diprediksi: merutekan permintaan inferensi menggunakan model XGBoost yang dilatih secara terus-menerus pada info lalu lintas real time, yang dioptimalkan untuk tujuan Time-to-First-Token (TTFT) dan Time-per-Output-Token (TPOT) per permintaan. Lebih akurat daripada heuristik statis dalam workload varian tinggi. Lihat Menggunakan pemilihan rute berbasis latensi yang diprediksi dengan GKE Inference Gateway.
• Kemampuan observasi inferensi: menyediakan metrik kemampuan observasi untuk permintaan inferensi, seperti rasio permintaan, latensi, error, dan saturasi. Pantau performa dan perilaku layanan inferensi Anda melalui Cloud Monitoring dan Cloud Logging, dengan memanfaatkan dasbor bawaan khusus untuk mendapatkan insight mendetail. Untuk mengetahui informasi selengkapnya, lihat Melihat dasbor GKE Inference Gateway.
• Konfigurasi CORS: mendukung Cross-Origin Resource Sharing (CORS) pada HTTPRoute resource. CORS membantu aplikasi web yang berjalan di domain yang berbeda mengakses endpoint inferensi Anda dengan aman. CORS didukung untuk Gateway cluster tunggal.
• Pengelolaan API Lanjutan dengan Apigee: terintegrasi dengan Apigee untuk meningkatkan gateway inferensi Anda dengan fitur seperti keamanan API, pembatasan kapasitas, dan kuota. Untuk mengetahui petunjuk mendetail, lihat Mengonfigurasi Apigee untuk autentikasi dan pengelolaan API.
• Ekstensibilitas: dibangun di atas Ekstensi Inferensi Kubernetes Gateway API open source yang dapat diperluas yang mendukung algoritma llm-d Endpoint Picker (EPP) yang dikelola pengguna, yang didukung oleh llm-d. Algoritma llm-d Endpoint Picker (EPP), yang didukung oleh llm-d, menyediakan inteligensi pemilihan rute inti untuk ekstensi ini.
• Dukungan multiport: mendukung server model yang mengekspos beberapa port, yang penting untuk skenario inferensi lanjutan seperti perhatian Data Paralel.
• Batas Grup Endpoint Jaringan (NEG): memiliki batas 50 NEG per Cloud de Confiance by S3NS Layanan Backend. Saat menggunakan InferencePool multiport, setiap port di setiap zona akan membuat NEG khusus. Misalnya, InferencePool dengan delapan port dalam cluster regional biasa (tiga zona) menghasilkan 24 NEG. Oleh karena itu, Gateway multi-cluster hanya dapat menggabungkan InferencePool tersebut dari maksimum dua cluster (dua cluster × 24 NEG = 48 NEG) sebelum mencapai batas 50 NEG.

Memahami konsep utama

GKE Inference Gateway meningkatkan GKE Gateway yang ada yang menggunakan GatewayClass objek. GKE Inference Gateway memperkenalkan Definisi Resource Kustom (CRD) Gateway API baru berikut , yang selaras dengan ekstensi OSS Kubernetes Gateway API untuk Inferensi:

• Objek InferencePool: mewakili grup Pod (container) yang menggunakan konfigurasi komputasi, jenis akselerator, model bahasa dasar, dan server model yang sama. Hal ini secara logis mengelompokkan dan mengelola resource penyajian model AI Anda. Satu objek InferencePool dapat mencakup beberapa Pod di berbagai node GKE dan memberikan skalabilitas serta ketersediaan tinggi. Anda dapat menentukan hingga delapan targetPorts dalam resource InferencePool untuk mendukung server model yang memerlukan beberapa port.
• Objek InferenceObjective: menentukan nama model inferensi dari InferencePool sesuai dengan spesifikasi OpenAI API. Objek InferenceObjective juga menentukan properti inferensi model, seperti Priority model AI. GKE Inference Gateway memberikan preferensi pada workload dengan nilai prioritas yang lebih tinggi. Hal ini memungkinkan Anda melakukan multiplexing workload AI yang penting dan toleran terhadap latensi di cluster GKE. Anda juga dapat mengonfigurasi objek InferenceObjective untuk menginferensi model yang di-fine-tune LoRA.

Diagram berikut mengilustrasikan GKE Inference Gateway dan integrasinya dengan keamanan AI, kemampuan observasi, dan penyajian model dalam cluster GKE.

Diagram berikut mengilustrasikan model resource yang berfokus pada dua persona yang berfokus pada inferensi baru dan resource yang mereka kelola.

Router llm-d

Router llm-d adalah komponen pemilihan rute permintaan cerdas yang digunakan Inference Gateway untuk membuat keputusan endpoint per permintaan. Router ini terdiri dari dua sub-komponen:

Mode Gateway

GKE Inference Gateway adalah llm-d Router yang beroperasi dalam Mode Gateway. Dalam Mode Gateway, Proxy adalah Kubernetes Gateway formal yang disediakan dan dikelola secara terpisah dari layanan EPP. Gateway memanggil EPP melalui ext-proc untuk membuat keputusan pemilihan rute, lalu meneruskan permintaan langsung ke Pod server model yang dipilih.

Pemisahan Gateway (data plane) dari EPP (inteligensi pemilihan rute) ini memungkinkan:

• Infrastruktur bersama: satu GKE Gateway melayani beberapa InferencePool bersama dengan Layanan Kubernetes standar.
• Pengelolaan traffic lanjutan: HTTPRoute kebijakan mendukung pemisahan berbobot splitting, peluncuran bertahap, dan pencerminan permintaan.
• Penskalaan independen: layanan EPP menskalakan secara independen dari Gateway.
• Integrasi berbasis cloud: berfungsi dengan pengontrol Gateway terkelola GKE, Cloud Load Balancing, dan alat kemampuan observasi yang ada.

Cara kerja GKE Inference Gateway

GKE Inference Gateway menggunakan ekstensi Gateway API dan logika pemilihan rute khusus model untuk menangani permintaan klien ke model AI. Langkah-langkah berikut menjelaskan alur permintaan.

Cara kerja alur permintaan

GKE Inference Gateway merutekan permintaan klien dari permintaan awal ke instance model. Bagian ini menjelaskan cara GKE Inference Gateway menangani permintaan. Alur permintaan ini umum untuk semua klien.

1. Klien mengirimkan permintaan, yang diformat seperti yang dijelaskan dalam spesifikasi OpenAI API, ke model yang berjalan di GKE.

2. GKE Inference Gateway memproses permintaan menggunakan ekstensi inferensi berikut:

   1. Ekstensi pemilihan rute berbasis isi: mengekstrak ID model dari isi permintaan klien dan mengirimkannya ke GKE Inference Gateway. GKE Inference Gateway kemudian menggunakan ID ini untuk merutekan permintaan berdasarkan aturan yang ditentukan dalam objek HTTPRoute Gateway API. Pemilihan rute isi permintaan mirip dengan pemilihan rute berdasarkan jalur URL. Perbedaannya adalah pemilihan rute isi permintaan menggunakan data dari isi permintaan.
   2. Ekstensi keamanan: menggunakan Model Armor, NVIDIA NeMo Guardrails, atau solusi pihak ketiga yang didukung untuk menerapkan kebijakan keamanan khusus model, yang mencakup pemfilteran konten, deteksi ancaman, sanitasi, dan logging. Ekstensi keamanan menerapkan kebijakan ini ke jalur pemrosesan permintaan dan respons.
   3. llm-d Endpoint Picker (EPP): memantau metrik utama dari server model dalam InferencePool dan merutekan permintaan ke replika model yang optimal. Untuk mengetahui informasi selengkapnya, lihat Router llm-d.

3. GKE Inference Gateway merutekan permintaan ke replika model yang ditampilkan oleh ekstensi endpoint picker.

Diagram berikut mengilustrasikan alur permintaan dari klien ke instance model melalui GKE Inference Gateway.

Cara kerja distribusi traffic

GKE Inference Gateway mendistribusikan permintaan inferensi secara dinamis ke server model dalam objek InferencePool. Hal ini membantu mengoptimalkan penggunaan resource dan mempertahankan performa dalam kondisi beban yang bervariasi. GKE Inference Gateway menggunakan dua mekanisme berikut untuk mengelola distribusi traffic:

• Pemilihan endpoint: memilih server model yang paling sesuai secara dinamis untuk menangani permintaan inferensi. Layanan ini memantau beban dan ketersediaan server, lalu membuat keputusan pemilihan rute yang optimal dengan menghitung score untuk setiap server yang menggabungkan sejumlah heuristik pengoptimalan:

  • Pemilihan rute yang mendukung cache awalan: GKE Inference Gateway melacak indeks cache awalan yang tersedia di setiap server model, dan memberikan skor yang lebih tinggi ke server dengan kecocokan cache awalan yang lebih panjang.
  • Pemilihan rute yang mendukung beban: GKE Inference Gateway memantau beban server (penggunaan cache KV dan kedalaman antrean yang tertunda), dan memberikan skor yang lebih tinggi ke server dengan beban yang lebih rendah.
  • Pemilihan rute yang mendukung LoRA: saat inferensi LoRA dinamis diaktifkan, GKE Inference Gateway memantau adaptor LoRA aktif per server, dan memberikan skor yang lebih tinggi ke server dengan adaptor LoRA yang diminta aktif, atau ruang tambahan untuk memuat adaptor LoRA yang diminta secara dinamis. Server dengan skor total tertinggi dari semua hal di atas akan dipilih.

• Antrean dan penghilangan: mengelola alur permintaan dan mencegah kelebihan beban traffic. GKE Inference Gateway menyimpan permintaan masuk dalam antrean dan memprioritaskan permintaan berdasarkan prioritas yang ditentukan.

GKE Inference Gateway menggunakan sistem Priority numerik, yang juga dikenal sebagai Criticality, untuk mengelola alur permintaan dan mencegah kelebihan beban. Priority ini adalah kolom bilangan bulat opsional yang ditentukan oleh pengguna untuk setiap InferenceObjective. Nilai yang lebih tinggi menandakan permintaan yang lebih penting. Saat sistem mengalami tekanan, permintaan dengan Priority kurang dari 0 dianggap sebagai prioritas yang lebih rendah dan akan dihilangkan terlebih dahulu, yang menampilkan error 429 untuk melindungi workload yang lebih penting. Secara default, Priority adalah 0. Permintaan hanya dihilangkan karena prioritas jika Priority-nya ditetapkan secara eksplisit ke nilai yang kurang dari 0. Sistem ini memungkinkan Anda memprioritaskan traffic inferensi online yang sensitif terhadap latensi daripada tugas batch yang kurang sensitif terhadap waktu.

GKE Inference Gateway mendukung inferensi streaming untuk aplikasi seperti chatbot dan terjemahan langsung, yang memerlukan pembaruan berkelanjutan atau hampir real-time. Inferensi streaming memberikan respons dalam bagian atau segmen inkremental, bukan output lengkap tunggal. Jika terjadi error selama respons streaming, streaming akan dihentikan, dan klien akan menerima pesan error. GKE Inference Gateway tidak mencoba ulang respons streaming.

Menjelajahi contoh aplikasi

Bagian ini memberikan contoh penggunaan GKE Inference Gateway untuk mengatasi berbagai skenario aplikasi AI generatif.

Contoh 1: Inferensi beberapa model AI generatif di cluster GKE

Sebuah perusahaan ingin men-deploy beberapa model bahasa besar (LLM) untuk menginferensi berbagai workload. Misalnya, mereka mungkin ingin men-deploy model Gemma3 untuk antarmuka chatbot dan model DeepSeek untuk aplikasi rekomendasi. Perusahaan harus memastikan performa inferensi yang optimal untuk LLM ini.

Dengan GKE Inference Gateway, Anda dapat men-deploy LLM ini di cluster GKE dengan konfigurasi akselerator yang Anda pilih di InferencePool. Kemudian, Anda dapat merutekan permintaan berdasarkan nama model (seperti chatbot dan recommender) dan properti Priority.

Diagram berikut mengilustrasikan cara GKE Inference Gateway merutekan permintaan ke model yang berbeda berdasarkan nama model dan Priority.

Diagram ini mengilustrasikan cara permintaan ke layanan GenAI di example.com/completions ditangani oleh GKE Inference Gateway. Permintaan pertama mencapai Gateway di namespace Infra. Gateway ini meneruskan permintaan ke HTTPRoute di namespace GenAI Inference, yang dikonfigurasi untuk menangani permintaan untuk model chatbot dan sentimen. Untuk model chatbot, HTTPRoute membagi traffic: 90% diarahkan ke InferencePool yang menjalankan versi model saat ini (dipilih oleh {pool: gemma}), dan 10% masuk ke pool dengan versi yang lebih baru ({pool: gemma-new}), biasanya untuk pengujian canary. Kedua pool ditautkan ke InferenceObjective yang menetapkan Priority 10 ke permintaan untuk model chatbot, sehingga memastikan permintaan ini diperlakukan sebagai prioritas tinggi.

Contoh 2: Inferensi adaptor LoRA di akselerator bersama

Sebuah perusahaan ingin menginferensi LLM untuk analisis dokumen dan berfokus pada audiens dalam beberapa bahasa, seperti Inggris dan Spanyol. Mereka telah melakukan fine-tuning model untuk setiap bahasa, tetapi perlu menggunakan kapasitas GPU dan TPU secara efisien. Anda dapat menggunakan GKE Inference Gateway untuk men-deploy adaptor yang di-fine-tune LoRA dinamis untuk setiap bahasa (misalnya, english-bot dan spanish-bot) pada model dasar umum (misalnya, llm-base) dan akselerator. Hal ini memungkinkan Anda mengurangi jumlah akselerator yang diperlukan dengan mengemas beberapa model secara padat pada akselerator umum.

Diagram berikut mengilustrasikan cara GKE Inference Gateway menginferensi beberapa adaptor LoRA di akselerator bersama.

Langkah berikutnya

• Men-deploy GKE Inference Gateway
• Menyesuaikan konfigurasi GKE Inference Gateway
• Menginferensi LLM dengan GKE Inference Gateway
• Menggunakan pemilihan rute berbasis latensi yang diprediksi dengan GKE Inference Gateway(Pratinjau)