Mengelola traffic dan layanan inferensi dengan Gateway with Inference Extension - Container Service for Kubernetes

Arahkan permintaan ke Pod yang optimal berdasarkan metrik antrian dan cache GPU secara real-time untuk mempercepat waktu hingga token pertama (TTFT).

Fitur

Gateway with Inference Extension adalah komponen gerbang yang ditingkatkan berdasarkan Gateway API komunitas Kubernetes dan spesifikasi Inference Extension-nya. Komponen ini menyediakan perutean Lapisan 4 dan Lapisan 7 dengan kemampuan tambahan untuk inferensi AI generatif, menyederhanakan manajemen layanan inferensi, serta mengoptimalkan penyeimbangan beban di berbagai beban kerja inferensi.

Komponen ini mendukung perutean Lapisan 4 dan Lapisan 7 dengan kemampuan inferensi AI berikut:

Penyeimbangan beban yang sadar inferensi: Mengarahkan permintaan berdasarkan metrik server inferensi secara real-time (kedalaman antrian dan pemanfaatan cache KV GPU) alih-alih distribusi merata, sehingga menjaga konsistensi pemanfaatan GPU dan mengurangi latensi TTFT.
Perutean yang sadar model: Mengarahkan permintaan berdasarkan nama model sesuai spesifikasi OpenAI API. Untuk model dasar dengan beberapa adapter LoRA, rilis canary mengarahkan traffic ke adapter tertentu berdasarkan nama adapter tersebut.
Tingkat kritisitas model: Menetapkan tingkat kritisitas untuk setiap model. Permintaan Critical memiliki prioritas lebih tinggi dibandingkan beban kerja dengan tingkat kritisitas lebih rendah.

Konsep utama

Dua resource kustom memperluas Kubernetes Gateway API:

Resource	Tujuan
InferencePool	Mengelompokkan Pod yang memiliki konfigurasi komputasi, jenis akselerator, model dasar, dan server model yang sama. Dapat mencakup Pod di berbagai node ACK untuk skalabilitas dan ketersediaan tinggi.
InferenceModel	Menentukan nama model yang dilayani oleh InferencePool beserta propertinya, termasuk tingkat kritisitas.

Diagram berikut menunjukkan hubungan antara resource InferencePool, InferenceModel, dan Gateway API.

Cara kerja

Gerbang mengevaluasi metrik real-time berikut pada setiap Pod untuk mengarahkan permintaan masuk:

Panjang antrian permintaan (vllm:num_requests_waiting): Jumlah permintaan dalam antrian. Pod dengan antrian lebih pendek akan memproses permintaan baru lebih cepat.
Pemanfaatan cache KV GPU (vllm:gpu_cache_usage_perc): Persentase cache KV GPU yang sedang digunakan. Pemanfaatan yang lebih rendah berarti kapasitas lebih besar untuk permintaan baru.

Gerbang mengarahkan setiap permintaan ke Pod yang paling mampu menanganinya berdasarkan metrik tersebut.

Diagram berikut menggambarkan alur permintaan.

Mengapa diperlukan penyeimbangan beban yang sadar inferensi

Penyeimbangan beban HTTP standar mendistribusikan permintaan secara merata ke seluruh Pod. Pendekatan ini cocok untuk layanan tanpa status, tetapi tidak efektif untuk inferensi model bahasa besar (LLM), karena biaya komputasi setiap permintaan bersifat tidak dapat diprediksi.

Inferensi LLM terdiri dari dua fase:

Fase prefill: Mengenkode input.
Fase decoding: Berlangsung secara bertahap; setiap langkah mendekode input sebelumnya dan menghasilkan satu token (kira-kira setara dengan satu kata).

Karena panjang output tidak dapat diprediksi, distribusi merata justru menciptakan beban GPU yang tidak merata—beberapa Pod mengalami bottleneck sementara yang lain menganggur.

Penyeimbangan beban yang sadar inferensi mengarahkan setiap permintaan ke Pod dengan kapasitas paling tersedia berdasarkan kedalaman antrian dan pemanfaatan cache KV GPU secara real-time, sehingga menjaga beban GPU tetap seimbang, mengurangi TTFT, dan meningkatkan throughput.