Menggunakan perutean berbasis latensi yang diprediksi dengan GKE Inference Gateway

Dokumen ini menjelaskan cara mengaktifkan dan menggunakan perutean berbasis latensi yang diprediksi yang disediakan oleh llm-d dalam GKE Inference Gateway. Secara default, GKE Inference Gateway merutekan permintaan menggunakan kombinasi sinyal beban dan heuristik afinitas cache awalan. Perutean berbasis latensi yang diprediksi menggantikan bobot heuristik statis dengan model XGBoost yang terus dilatih pada traffic live, sehingga membuat keputusan perutean yang lebih akurat saat pola workload berubah.

Kapan menggunakan perutean berbasis latensi yang diprediksi

Fitur ini paling efektif jika kondisi berikut berlaku untuk workload Anda:

  • Varians tinggi dalam panjang perintah dan penyelesaian: kedalaman antrean saja adalah proxy yang buruk untuk beban server jika ukuran permintaan sangat bervariasi. Prediktor latensi memperhitungkan biaya prefill dan dekode aktual per permintaan.
  • SLO latensi per permintaan: saat aplikasi Anda menentukan target Time-to-First-Token (TTFT) atau Time-per-Output-Token (TPOT) pada permintaan individual, penjadwal akan menerapkan target ini selama perutean. Hal ini dilakukan dengan menghitung headroom (latensi yang diprediksi dikurangi target SLO) untuk setiap Pod kandidat.
  • Penyesuaian bobot statis yang rentan: jika Anda sering menyesuaikan kembali keseimbangan antara afinitas cache dan sinyal beban saat pola traffic berubah, model yang dilatih secara online akan beradaptasi secara otomatis.

Cara kerja perutean berbasis latensi yang diprediksi

Bagian ini menjelaskan arsitektur dan pipeline penjadwalan yang digunakan oleh perutean berbasis latensi yang diprediksi.

Arsitektur

Penjadwalan berbasis latensi yang diprediksi men-deploy dua container sidecar tambahan di dalam Pod EPP, bersama dengan EPP itu sendiri:

Komponen Deskripsi
Server Pelatihan Melatih ulang model XGBoost TTFT dan TPOT secara terus-menerus pada sampel permintaan yang telah selesai diterima dari EPP. Menggunakan bucketing bertingkat melalui a jendela geser sehingga rezim traffic yang jarang tidak dilupakan. Menulis model yang diupdate ke volume bersama.
Server Prediksi Menayangkan prediksi TTFT dan TPOT ke EPP di jalur aktif permintaan. Membaca model terlatih terbaru dari volume bersama. Dapat diskalakan secara horizontal — setiap instance server mempertahankan sekitar 300 QPS pekerjaan prediksi. Beberapa instance di-load balance oleh proxy penggabungan Go di EPP yang mengelompokkan permintaan prediksi serentak dalam jendela 1 md.

Pipeline penjadwalan EPP llm-d

Saat penjadwalan berbasis latensi yang diprediksi diaktifkan, EPP akan memproses setiap permintaan melalui urutan plugin yang dapat dikomposisikan berikut:

  1. predicted-latency-producer: memanggil Server Prediksi untuk mendapatkan perkiraan TTFT dan TPOT untuk setiap Pod kandidat di InferencePool, dengan kondisi penggunaan cache KV saat ini, kedalaman antrean, skor kecocokan cache awalan, dan fitur permintaan masuk setiap Pod. Setelah respons ditampilkan ke klien, produsen akan mengirimkan TTFT dan latensi antar-token yang diamati kembali ke Server Pelatihan sebagai sampel pelatihan baru.

    • Perilaku penggantian: jika Server Prediksi tidak dapat dijangkau atau menampilkan error, EPP akan otomatis beralih ke skor gabungan berdasarkan penggunaan cache KV, kedalaman antrean, dan kecocokan cache awalan.

  2. prefix-cache-affinity-filter: filter ini mempersempit kumpulan kandidat ke Pod yang memiliki cache aktif saat skor kecocokan cache awalan Pod melebihi nilai minimum afinitas (default 0,80). Nilai minimum ini memisahkan dua populasi yang diamati dalam produksi: Pod yang sudah memiliki histori percakapan yang di-cache dari giliran sebelumnya, dan Pod yang tidak. Filter ini menerapkan strategi eksploitasi dan eksplorasi epsilon-greedy:

    • Eksploitasi (jalur default): jalur ini merutekan ke Pod yang memiliki cache aktif sehingga pemberian skor memusatkan penggunaan kembali cache pada Pod tersebut.

    • Eksplorasi (probabilitas kecil): jalur ini sepenuhnya melewati filter pada fraksi permintaan yang dapat dikonfigurasi untuk mengisi entri cache pada Pod yang tidak memiliki cache aktif guna mencegah fragmentasi cache.

    • Gerbang beban TTFT: bahkan di jalur eksploitasi, jika TTFT yang diprediksi dari Pod yang memiliki cache aktif terbaik melebihi TTFT Pod keseluruhan terbaik dengan lebih dari nilai minimum yang dapat dikonfigurasi (default 5.000 md), afinitas akan rusak dan kumpulan kandidat lengkap akan digunakan.

  3. slo-headroom-tier-filter (hanya permintaan SLO): saat permintaan menyertakan header SLO, membagi Pod kandidat menjadi tingkat positif (diprediksi akan memenuhi SLO) dan tingkat negatif (diprediksi akan melanggarnya).

  4. latency-scorer: memberi skor pada Pod kandidat. Tanpa header SLO, Pod dengan latensi yang diprediksi terendah akan dipilih. Dengan header SLO, skor didasarkan pada headroom (SLO dikurangi latensi yang diprediksi) menggunakan headroomSelectionStrategy:

    • least (default): Bin-pack. Merutekan ke Pod dengan headroom positif terkecil, memaksimalkan penggunaan, dan membuat Pod yang kurang dimuat tetap tersedia untuk lonjakan traffic di masa mendatang.
    • most: Spread. Merutekan ke Pod dengan headroom positif terbesar, sehingga memberikan lebih banyak kelonggaran untuk lonjakan beban yang tidak terduga.

  5. latency-slo-admitter (hanya permintaan SLO): menolak permintaan yang dapat dihentikan (prioritas kurang dari 0) jika tidak ada Pod kandidat yang diprediksi akan memenuhi SLO, bukan menggunakan kapasitas pada permintaan yang diprediksi akan gagal memenuhi targetnya. Filter ini tidak berpengaruh jika header SLO tidak ada atau jika ada Pod yang memenuhi SLO.

  6. weighted-random-picker: memilih Pod akhir menggunakan pemilihan acak berbobot berdasarkan skor. Hal ini menyebarkan beban sekaligus tetap mengutamakan Pod dengan skor yang lebih baik.

Mode streaming

Plugin predicted-latency-producer mendukung dua mode pelatihan, yang dikonfigurasi menggunakan parameter streamingMode:

  • streamingMode: false (default): melatih latensi permintaan end-to-end (E2E). Gunakan mode ini jika workload Anda menggabungkan respons streaming dan non-streaming, atau jika Anda hanya memerlukan perutean yang mengetahui latensi tanpa penerapan SLO per permintaan.
  • streamingMode: true: melatih model TTFT dan TPOT terpisah. TTFT dicatat pada bagian streaming pertama; TPOT diambil sampelnya di seluruh token berikutnya. Gunakan mode ini jika workload Anda sepenuhnya streaming dan Anda memerlukan penerapan x-slo-ttft-ms / x-slo-tpot-ms yang bermakna.

Sebelum memulai

Sebelum memulai, pastikan Anda telah melakukan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
    • Aktifkan Google Kubernetes Engine API
  • Jika ingin menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan perintah gcloud components update. Versi gcloud CLI yang lebih lama mungkin tidak mendukung menjalankan perintah dalam dokumen ini.

  • Aktifkan Compute Engine API, Network Services API, dan Model Armor API jika diperlukan.

    Buka Mengaktifkan akses ke API dan ikuti petunjuknya.

  • Pastikan Anda memiliki deployment GKE Inference Gateway yang berfungsi. Lihat Men-deploy GKE Inference Gateway.

  • Pastikan InferencePool Anda menggunakan kumpulan Pod yang homogen—jenis GPU, bobot model, dan konfigurasi penyajian yang identik.

  • Pastikan cluster GKE Anda adalah versi 1.32.3 atau yang lebih baru.

  • Instal Helm. Lihat panduan penginstalan Helm guide.

Mengaktifkan penjadwalan berbasis latensi yang diprediksi

Langkah-langkah berikut akan memandu Anda mengaktifkan penjadwalan berbasis latensi yang diprediksi untuk deployment GKE Inference Gateway.

Langkah 1: Menginstal atau mengupgrade InferencePool dengan latensi yang diprediksi diaktifkan

Flag latencyPredictor.enabled=true men-deploy sidecar Server Pelatihan dan Server Prediksi di dalam Pod EPP dan menghubungkan pipeline plugin penjadwalan lengkap:

helm upgrade --install INFERENCE_POOL_NAME \
  --set inferencePool.modelServers.matchLabels.app=MODEL_SERVER_LABEL \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  --set inferenceExtension.latencyPredictor.enabled=true \
  --version LLM_D_VERSION \
  oci://LLM_D_REGISTRY_PATH

Ganti kode berikut:

  • INFERENCE_POOL_NAME: nama InferencePool Anda—misalnya, vllm-llama3-8b-instruct.
  • MODEL_SERVER_LABEL: kunci label yang digunakan untuk memilih Pod server model Anda.
  • LLM_D_VERSION: versi diagram Helm llm-d yang akan digunakan.
  • LLM_D_REGISTRY_PATH: jalur registry OCI llm-d.

Langkah 2: Memverifikasi deployment

Pastikan Pod EPP berjalan dengan semua container sidecar siap:

kubectl get pods -l app=INFERENCE_POOL_NAME-epp

Pod EPP harus menampilkan semua container dalam status Berjalan atau Siap: EPP itu sendiri, Server Pelatihan, dan satu atau beberapa Server Prediksi.

Langkah 3: Mengirim permintaan dasar

Kirim permintaan inferensi standar untuk mengonfirmasi bahwa perutean berfungsi sebelum mengaktifkan header SLO:

curl -i -X POST GATEWAY_IP:PORT/v1/completions \
 -H 'Content-Type: application/json' \
 -H 'Authorization: Bearer $(gcloud auth print-access-token)' \
 -H 'x-prediction-based-scheduling: true' \
 -d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "0"
 }'

Ganti kode berikut:

  • GATEWAY_IP: alamat IP layanan gateway Anda.
  • PORT: nomor port layanan gateway Anda.
  • MODEL_NAME: nama model yang akan digunakan untuk inferensi.
  • PROMPT_TEXT: perintah input.
  • MAX_TOKENS: jumlah maksimum token yang akan dibuat.

Header x-prediction-based-scheduling: true memilih permintaan ini ke pipeline penjadwalan latensi yang diprediksi. Selama periode pemanasan prediktor, EPP akan beralih ke perutean heuristik.

Langkah 4: Mengirim permintaan yang mengetahui SLO (opsional)

Untuk mengaktifkan penerapan SLO per permintaan, tambahkan header tujuan latensi TTFT dan TPOT:

curl -i -X POST GATEWAY_IP:PORT/v1/completions \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer $(gcloud auth print-access-token)' \
  -H 'x-prediction-based-scheduling: true' \
  -H 'x-slo-ttft-ms: 500' \
  -H 'x-slo-tpot-ms: 50' \
  -d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "0",
    "stream": true
  }'

Ganti kode berikut:

  • GATEWAY_IP: alamat IP layanan gateway Anda.
  • PORT: nomor port layanan gateway Anda.
  • MODEL_NAME: nama model yang akan digunakan untuk inferensi.
  • PROMPT_TEXT: perintah input.
  • MAX_TOKENS: jumlah maksimum token yang akan dibuat.

Header permintaan:

  • x-prediction-based-scheduling: true: memilih permintaan ke pipeline penjadwalan latensi yang diprediksi.
  • x-slo-ttft-ms: Time-to-First-Token maksimum yang dapat diterima dalam milidetik.
  • x-slo-tpot-ms: Time-per-Output-Token maksimum yang dapat diterima dalam milidetik.

Memantau penjadwalan latensi yang diprediksi

Saat prediktor latensi diaktifkan, EPP akan menampilkan metrik tambahan melalui Cloud Monitoring.

Metrik Deskripsi
inference_objective_request_ttft_seconds Distribusi TTFT aktual (atau latensi E2E jika streamingMode=false).
inference_objective_request_predicted_ttft_seconds Distribusi TTFT yang diprediksi (atau latensi E2E jika streamingMode=false).
inference_objective_request_tpot_seconds Distribusi TPOT aktual.
inference_objective_request_predicted_tpot_seconds Distribusi TPOT yang diprediksi.
inference_objective_request_ttft_slo_violation_total Penghitung pelanggaran SLO TTFT.

Menskalakan Server Prediksi

EPP melakukan satu panggilan prediksi per Pod kandidat per permintaan masuk. Setiap instance Server Prediksi mempertahankan sekitar 300 QPS pekerjaan prediksi.

Panduan perkiraan untuk jumlah instance Server Prediksi:

QPS Cluster (100 Pod) Server prediksi diperlukan
Hingga 1.000 QPS 1 server
Hingga 5.000 QPS 2 server
Hingga 10.000 QPS 4 server

Tambahkan instance Server Prediksi dengan mengupdate nilai Helm latencyPredictor.predictionServerCount.

Batasan

  • Homogen InferencePool diperlukan: jenis GPU, varian model, atau konfigurasi penyajian campuran dalam satu kumpulan tidak didukung.
  • Periode pemanasan: model XGBoost memerlukan sampel traffic live yang memadai sebelum prediksi menjadi akurat.
  • Penerapan SLO: penerapan hanya berada di lapisan perutean. Server model tidak menghentikan permintaan yang melebihi target SLO setelah pemilihan.
  • Status: fitur ini berada dalam Pratinjau. Fitur ini tidak direkomendasikan untuk workload produksi dengan persyaratan SLA yang ketat tanpa pengujian menyeluruh.

Langkah berikutnya