Gateway API Inference Extension: EPP Moves to llm-d, What Now

Catatan riset yang memulai artikel ini menyebut pemindahan Endpoint Picker diumumkan bersama v1.6.2 pada 17 September. Itu tidak sesuai dengan sumbernya. Issue proposal ditutup sebagai selesai pada 13 Mei, release notes v1.6.0 sudah mencatat pemindahannya, dan v1.6.2 hanyalah patch release. Tanggal ini penting, karena menentukan sudah berapa lama cluster Anda menjalankan kode yang tidak lagi menerima perubahan di repositori asalnya.

Ini catatan migrasi dari apa yang saya baca: README repositori SIG, issue proposal, release notes v1.6.0 dan v1.6.2, halaman InferencePool API, serta repositori llm-d router dan payload processor, termasuk README Helm chart dan operations guide. Jika sumber diam, saya katakan begitu dan tidak menebak. Saya sendiri tidak menjalankan chart-chart ini.

Apa yang pindah, apa yang tetap, dan di mana tiap bagian sekarang

README repositori SIG menyatakan bahwa paket Endpoint Picker (EPP), API InferenceObjective dan InferenceModelRewrite, serta Body Based Router (BBR) sudah pindah. EPP beserta API-nya ke llm-d/llm-d-router, dan BBR ke llm-d/llm-d-inference-payload-processor. README juga menyebut tidak ada kode baru yang diterima di paket-paket itu pada repositori SIG, dan paket tersebut akan segera di-archive.

Artinya begini: jika Anda pernah men-deploy EPP upstream untuk scheduling sungguhan, dependency produksi Anda kini proyek lain, dengan jadwal rilis dan maintainer yang berbeda. Jika Anda hanya butuh resource InferencePool dan picker setingkat conformance, tidak ada yang berubah.

Timeline yang benar: pemindahan di Mei, release di Agustus

Issue proposal (nomor 2430) dibuka pada 26 Februari 2026. Dua maintainer menyetujui pada 9 Maret, judulnya diperluas mencakup BBR pada 12 Maret, rencana eksekusi dibagikan pada 11 April, dan issue ditutup pada 13 Mei dengan maintainer menulis bahwa pemindahan sudah terjadi. Release notes v1.6.0, bertanggal 17 Agustus di halaman releases, mencatat penghapusan InferenceObjective, InferenceModelRewrite dan EndpointPickerConfig dari repositori ini.

Release v1.6.2 pada 17 September mem-pin image conformance manifest ke tag baru dan mencantumkan tiga perbaikan: body response pada mode FULL_DUPLEX_STREAMED membawa BodyMutation streamed response yang benar supaya gateway stream tidak terputus (nomor 3028), request header dikirim sebelum body pada ext_proc gRPC stream untuk menghentikan HTTP 500 palsu dengan chunked body (3033), dan perbaikan buildx TARGETARCH untuk exec format error di arm64 (3032). Itu alasan bagus untuk memakai 1.6.2, tetapi bukan pemindahannya.

Yang tetap di upstream: kontrak InferencePool

Yang bergantung pada integrasi gateway Anda adalah resource InferencePool, dan itu tetap berada di proyek SIG pada group inference.networking.k8s.io/v1. Halaman API mendokumentasikannya dengan selector yang harus persis cocok dengan label pod model server, targetPorts, dan endpointPickerRef yang menunjuk ke Service EPP. Sejak v1.5.0 referensi itu opsional, dan release notes v1.6.0 mengulang perubahan tersebut.

# InferencePool as shown on the API page: still upstream, still the contract
# between your Gateway and whichever EPP you run.
apiVersion: inference.networking.k8s.io/v1
kind: InferencePool
metadata:
  name: vllm-qwen3-32b
spec:
  selector:
    matchLabels:
      app: vllm-qwen3-32b      # must exactly match the model server Pod labels
  targetPorts:
    - number: 8000
  endpointPickerRef:
    name: vllm-qwen3-32b-epp   # the EPP Service, now typically from llm-d charts
    port:
      number: 9002
    failureMode: FailOpen      # gateway picks an endpoint itself if EPP does not answer

Jadi pertanyaan re-pointing-nya sempit. Pool dan route tetap sama; yang berubah adalah chart dan image mana yang menghasilkan Service yang dinamai endpointPickerRef. Situs docs menyatakannya langsung: pengguna produksi sebaiknya membuat EPP sendiri atau memakai yang sudah ada, dan contohnya llm-d-router.

Re-pointing install Helm: key lama membuat install gagal

llm-d router menyediakan tiga chart di config/charts: llm-d-router-gateway untuk Gateway mode, llm-d-router-standalone untuk proxy yang dikelola sendiri, dan routerlib, library chart yang tidak bisa di-deploy sendiri. README-nya menyebut chart baru gagal di-install jika menemukan key top-level lama atau flag command-line lama. Ini membantu, karena migrasi setengah jalan yang diam-diam jauh lebih buruk, tetapi berarti file values lama tidak bisa dipakai begitu saja.

Gateway mode adalah setup produksi yang direkomendasikan README: EPP mendukung sebuah InferencePool yang direferensikan HTTPRoute pada Gateway bersama. Prasyarat di README chart adalah meng-install CRD Gateway API Inference Extension terlebih dahulu, pengingat bahwa CRD tetap datang dari proyek SIG.

# values-llm-d.yaml - keys taken from the llm-d-router chart README.
# modelServers.matchLabels is required and defaults to empty.
router:
  modelServers:
    matchLabels:
      app: vllm-qwen3-32b      # same label your InferencePool selector used
    type: vllm                 # default; sglang and triton variants exist
    targetPorts:
      - number: 8000
  inferencePool:
    create: true
    failureMode: FailOpen      # chart default
  epp:
    replicas: 1

# Gateway mode install, from the chart README (path is local to the repo checkout).
# Wrong: helm upgrade with your old values file - legacy keys abort the install.
# Right: translate keys first, then install the gateway chart.
helm install vllm-qwen3-32b ./config/charts/llm-d-router-gateway \
  -f values-llm-d.yaml \
  --set provider.name=gke     # none, gke or istio

Perhatikan apa yang tidak diberikan README: path OCI registry atau URL Helm repository. Semua perintah yang didokumentasikan meng-install dari checkout lokal config/charts. Saya akan mem-pin checkout itu ke sebuah tag di CI, bukan mengikuti main.

Body Based Router menjadi Inference Payload Processor

BBR pindah ke llm-d-inference-payload-processor, yang README-nya menjelaskan Inference Payload Processor (IPP) sebagai framework pluggable untuk memeriksa dan mengubah payload inference sebagai layanan ext-proc di samping proxy gateway. Kegunaan utamanya routing berbasis payload: membaca sinyal seperti nama model lalu menyuntikkan header sehingga satu endpoint Gateway bisa melayani banyak model dan LoRA adapter. IPP memilih pool, dan EPP memilih pod di dalamnya.

Hati-hati dengan kata ganti nama. README IPP tidak pernah menyebut BBR, jadi saya tidak bisa memastikan dari sumber bahwa ia pengganti langsung dengan konfigurasi yang sama. Yang bisa saya pastikan adalah bentuk deployment-nya: chart-nya punya tiga mode. Istio meng-install EnvoyFilter, GKE meng-install GCPRoutingExtension, dan None hanya men-deploy resource inti sehingga integrasi proxy Anda pasang sendiri. Baca README chart-nya sebelum berasumsi konfigurasi BBR Anda bisa diterjemahkan.

Failure mode dan high availability di router baru

Operations guide adalah tempat pemindahan ini menjadi soal reliabilitas. Di Gateway mode, router.inferencePool.failureMode secara default FailOpen, sehingga Gateway merutekan langsung ke model server bila EPP tidak terjangkau. Di standalone mode, router.proxy.failOpen default true dan request yang tidak dipilih masuk ke cluster inference_pool_fallback. Agentgateway tidak punya pengaturan fail-open dan menolak request selama EPP tidak terjangkau.

Fail-open hanya untuk EPP yang tidak terjangkau, bukan EPP yang sedang draining dan mengembalikan error response. Leader election juga ada biayanya: panduan menyebut failover butuh 10 sampai 30 detik sebelum standby mulai melayani, dengan routing yang belum optimal di jeda itu. Panduan merekomendasikan priority routing di standalone service mode untuk failover di bawah satu detik.

# HA examples from the llm-d router operations guide.

# Active-active: replicas share load, flow control is per replica.
router:
  epp:
    replicas: 3
    haMode: all-active
    crossReplica:
      enabled: true            # alpha Redis syncer; needs Redis 7.4+ you provision
      redis:
        address: redis.example:6379

---
# Active-passive with priority routing (standalone, service mode).
router:
  proxy:
    mode: service
    priorityRouting:
      enabled: true
      primaryReplicas: 1
      standbyReplicas: 1

Trade-off dan jebakan yang bisa menggigit

Perdebatan governance itu nyata dan belum selesai. Di thread proposal, seorang peserta menulis bahwa yang tidak disediakan llm-d tetapi disediakan proyek upstream adalah neutral governance, dan memindahkan kode ke satu implementasi belum ada preseden. Thread berakhir dengan peserta sepakat untuk berbeda pendapat. Motivasi di sisi lain adalah duplikasi: EPP ada di upstream dan di llm-d scheduler, dan plugin lanjutan sebagian besar dikembangkan di llm-d.

Tiga risiko konkret muncul dari sumbernya. Pertama, pengguna Envoy Gateway: komentar pada 26 Mei bertanya bagaimana mereka tetap memakai EPP karena llm-d tidak mencantumkannya sebagai implementasi yang didukung, dan thread tidak menunjukkan jawaban. Kedua, vendor downstream: thread mencatat Dynamo melakukan vendoring kode EPP dan menambahkan plugin. Ketiga, README router menyebut satu-satunya body mode Envoy yang didukung adalah FULL_DUPLEX_STREAMED untuk request maupun response body, jadi proxy dengan setelan lain tidak akan berjalan benar.

Yang dikerjakan hari Senin

Anggap ini tugas inventaris dulu, migrasi kemudian. Urutannya:

1. Cari tahu EPP mana yang Anda jalankan: image, Helm release, dan chart asal Service yang dinamai endpointPickerRef pool Anda.
2. Putuskan apakah Anda butuh scheduling sungguhan atau hanya conformance. Jika hanya conformance, image lwepp tetap di upstream; jika scheduling, rencanakan llm-d router.
3. Terjemahkan file values dengan pemetaan empat baris, lalu install chart baru ke namespace staging di samping yang lama.
4. Pastikan proxy memakai body FULL_DUPLEX_STREAMED, lalu uji streaming completion dari ujung ke ujung.
5. Pindah ke v1.6.2 untuk komponen upstream yang Anda pertahankan, dan berhenti menerapkan perbaikan pada paket yang di-archive.

# 1. Which InferencePools exist, and which EPP Service does each name?
kubectl get crd | grep inference.networking
kubectl get inferencepools -A -o yaml | grep -A4 endpointPickerRef

# 2. Which images from the old repo are running?
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.spec.containers[*].image}{"\n"}{end}' \
  | grep gateway-api-inference-extension

# 3. Do your Helm values still use legacy top-level keys the new charts reject?
helm list -A
helm get values RELEASE -n NAMESPACE -o yaml \
  | grep -nE '^(inferenceExtension|inferencePool|inferenceObjectives|experimentalHttpRoute):'

Hasil kosong pada langkah 3 belum membuktikan Anda aman, karena values bisa juga datang dari parent chart; anggap ini pemeriksaan awal.

Aturan yang saya ambil: pisahkan kontrak API dari implementasinya, dan lacak keduanya sebagai dependency yang berbeda. Kontrak InferencePool tetap bersama Kubernetes; picker yang melakukan scheduling kini bersama llm-d, dan file values, image serta perilaku kegagalan Anda harus mengikutinya.