NVIDIA Dynamo di Kubernetes: Rust EPP dan Upgrade v1beta1

Kalimat yang membuat saya membuka dokumentasi Dynamo cuma pendek: Rust Endpoint Picker menggantikan Go EPP. Kalau Dynamo Anda berjalan di belakang Kubernetes Gateway, komponen inilah yang menentukan worker GPU mana yang menerima setiap request, dan ia baru saja berganti bahasa, image, dan kontrak dalam satu rilis. Perubahan seperti ini bisa menghabiskan satu sore atau berujung outage, tergantung apakah Anda membaca detail kecilnya lebih dulu.

Ini adalah pembacaan dekat atas release notes Dynamo 1.5.0, ledger deprecation, pengumuman 1.0, dan how-to GAIE, ditulis dari sudut pandang operator. Saya belum menjalankan upgrade ini di cluster, jadi tidak ada benchmark milik saya di sini. Setiap angka dan flag berasal dari halaman yang saya baca pada 17 Oktober 2026, dan bila dokumentasinya saling bertentangan saya sebutkan.

Enam rilis dalam tujuh bulan: apa yang harus diserap operator

Dynamo 1.0 diumumkan pada 16 Maret 2026 dan rilis terbaru saat saya menulis adalah 1.5.1, tanggal 6 Oktober. Ledger deprecation menunjukkan seberapa banyak yang berubah di antaranya. Bagi yang men-deploy platform ini, bukan menulis kode di atasnya, bagian menarik bukan fitur melainkan penghapusan, dan 1.5.0 memuat kumpulan penghapusan terpadat sejauh ini.

Baca kolom itu dari atas ke bawah dan polanya terlihat: proyek ini melunasi sejarahnya sendiri dengan ritme bulanan. Release notes menyebut 1.5.0 sebagai feature release ke-18, dengan 658 pull request yang di-merge dari 123 kontributor. Kalau Anda mengunci versi minor dan upgrade tiap kuartal, Anda akan bertemu beberapa penghapusan ini sekaligus dalam satu jendela.

Apa yang dijanjikan 1.0, beserta syaratnya

Pengumuman 1.0 dibuka dengan angka mencolok: hingga 7x lebih banyak request yang dilayani di NVIDIA Blackwell dalam SemiAnalysis InferenceX. Kondisinya sempit dan layak diulang. Run-nya memakai DeepSeek R1-0528 dalam FP4, dengan 1k token input dan 1k output, pada sekitar 50 token per detik per user, dan NVIDIA menyebut keuntungannya berasal dari disaggregated serving dengan wide expert parallelism di GB200 NVL72. Headline kedua, loading model hingga 7x lebih cepat lewat ModelExpress, diukur pada model mixture-of-experts besar seperti DeepSeek v3 di H200.

Ini hasil yang dilaporkan vendor pada hardware tertentu, dan saya tidak akan merencanakan kapasitas dari angka itu. Yang saya ambil dari pengumuman tersebut adalah bentuk produk bagi operator: sebuah Dynamo Graph Deployment Request yang mengubah model, hardware target, dan tujuan traffic yang ditulis dalam YAML menjadi graph yang siap di-deploy, dengan menggabungkan Planner dan AIConfigurator.

Bagian kedua itu sudah berubah. Di 1.5.0 AIConfigurator menjadi AISimulate dan dirilis sebagai package tersendiri, versi 0.12.0, dengan perintah aisimulate predict dan aisimulate recommend. Perintah lama python -m dynamo.replay dihapus. Kalau runbook Anda masih menyebut AIConfigurator, ia kini menggambarkan sebuah nama, bukan sebuah tool.

Rust Endpoint Picker dan posisinya

Dynamo mendokumentasikan dua cara routing di Kubernetes. Pada Frontend routing, Dynamo Frontend melakukan tokenisasi request, menilai worker, lalu meneruskannya; dokumentasi merekomendasikan ini sebagai default. Pada Gateway API routing, sebuah Gateway menerima request dan meminta Endpoint Picker Plugin memilih worker lewat Gateway API Inference Extension, lalu Frontend sidecar milik worker meneruskannya dalam mode direct. EPP, dalam kata-kata dokumentasinya sendiri, bukan endpoint inference publik dan tidak menjalankan model. Anda baru berurusan dengannya bila traffic harus masuk lewat Gateway untuk autentikasi, rate limiting, atau policy.

Di 1.5.0 implementasi Go sudah hilang dan yang Rust menjadi default. Ia dikemas di dalam image Dynamo Frontend pada /epp, dengan image standalone direncanakan di rilis berikutnya. Replika saling sinkron lewat port tetap yang diatur DYN_EPP_REPLICA_SYNC_PORT, default 9092. Saat menerima SIGTERM ia menandai gRPC health service sebagai NOT_SERVING sebelum draining, dan ia memvalidasi bahwa Envoy mengatur response_body_mode ke FULL_DUPLEX_STREAMED, syarat yang perlu Anda cek di konfigurasi gateway. Satu perbaikan di rilis yang sama menghentikan scorer KV-router membuang request body, yang tadinya menyebabkan error 503 pada request tool-calling multi-turn.

Manifest di bawah ini disusun dari how-to GAIE untuk 1.5.1. Tiga detail yang penting adalah komponen epp tanpa eppConfig, sidecar dalam mode direct, dan block size yang sama di mana-mana.

# Rust EPP: one component of type epp, and NO eppConfig.
# eppConfig (even an empty object) selects the legacy Go contract
# and admission rejects it alongside a 1.5+ image.
spec:
  components:
  - name: Epp
    type: epp
    replicas: 1
    podTemplate:
      spec:
        containers:
        - name: main
          image: nvcr.io/nvidia/ai-dynamo/dynamo-frontend:1.5.1
          envFrom:
          - secretRef:
              name: hf-token-secret
          env:
          - name: DYN_MODEL_NAME
            value: Qwen/Qwen3-0.6B
          - name: DYN_KV_CACHE_BLOCK_SIZE
            value: "16"          # must equal the backend --block-size

  # Each routable worker gets a sidecar in direct mode: the EPP has already
  # chosen the worker, so the sidecar must not choose again.
  - name: VllmDecodeWorker
    type: decode
    frontendSidecar: sidecar-frontend
    podTemplate:
      spec:
        containers:
        - name: main
          # existing worker; publish KV events so routing sees real cache state:
          #   --enable-prefix-caching --block-size 16
          #   --kv-events-config '{"enable_kv_cache_events":true}'
        - name: sidecar-frontend
          image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:1.5.1
          args: ["-m", "dynamo.frontend", "--router-mode", "direct"]

Migrasi dari Go EPP: blue/green atau in place

Hal pertama yang ditegaskan panduan migrasi adalah apa yang tidak perlu Anda lakukan. Upgrade Operator saja tidak memerlukan migrasi EPP: Operator 1.5 mendukung DGD legacy yang lama maupun baru selama eppConfig tetap diset dan image EPP tetap terkunci di jalur 1.4. Menghapus eppConfig dan pindah ke image 1.5 atau lebih baru harus dilakukan sebagai satu pembaruan yang disengaja, karena admission menolak kedua kombinasi campuran. eppConfig kosong tetap memilih kontrak Go. Sebuah DGD juga hanya boleh punya satu komponen epp, jadi dua picker tidak bisa berjalan berdampingan.

Dokumentasi lebih menyukai blue/green selama Anda mampu menyediakan kapasitas satu DGD tambahan, dan alasannya ada di tabel: hanya jalur ini yang verifikasinya terjadi sebelum production melihat perubahan. Intinya adalah HTTPRoute canary yang menambah header match persis, sehingga hanya request dengan header itu yang mencapai pool baru, diikuti satu JSON patch pada route production.

# Blue/green cutover, condensed from the docs' ten steps.
# Canary route: only requests carrying BOTH headers reach the new pool.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: qwen-rust-epp-canary
spec:
  parentRefs:
  - name: inference-gateway
  rules:
  - matches:
    - headers:
      - name: X-Gateway-Model-Name
        type: Exact
        value: Qwen/Qwen3-0.6B
      - name: X-Dynamo-EPP-Canary
        type: Exact
        value: rust-epp
      path:
        type: PathPrefix
        value: /
    backendRefs:
    - group: inference.networking.k8s.io
      kind: InferencePool
      name: qwen-rust-epp-pool
      port: 8000
    timeouts:
      request: 300s

# Only after Accepted and ResolvedRefs are True and a canary request succeeded:
# one patch moves production. Reverting it is the rollback.
kubectl patch httproute qwen -n my-model --type='json' -p='[
  {"op":"replace","path":"/spec/rules/0/backendRefs/0/name","value":"qwen-rust-epp-pool"}
]'

Pada fleet GPU, baris kapasitas adalah biaya yang sebenarnya. Dua set worker lengkap selama masa overlap bisa berarti satu set akselerator tambahan, jadi pilihannya antara mengeluarkan biaya itu atau menerima roll tanpa verifikasi pada satu komponen yang dilewati setiap request.

CRD v1beta1: storage, webhook, dan field yang menjadi immutable

Di 1.5.0 DGD, DCD, DGDR, dan scaling adapter DGDR pindah ke storage v1beta1 sambil tetap men-serve v1alpha1. Cerita migrasinya satu baris: upgrade Operator agar CRD migrator bawaannya mengonversi objek yang tersimpan. Endpoint admission webhook v1alpha1 sudah hilang, jadi bila Anda memelihara Validating atau MutatingWebhookConfiguration sendiri yang tidak dikelola Helm chart, arahkan ke path DGD v1beta1 dengan apiVersions v1beta1. API DGDR v1alpha1 sendiri tidak dihapus di rilis ini.

Tiga perubahan kecil akan menjebak manifest yang tidak Anda sangka rapuh. Field componentType v1alpha1 dan type v1beta1 menjadi immutable setelah diset, ditegakkan oleh aturan CEL; objek legacy tanpa type boleh mengisinya sekali. Komponen DGD dan DCD mendapat daftar roles bertipe untuk multinode, dan manifest implisit yang ada tetap valid. Lalu runtimeVersionOverride pada DGD, DCD, dan DGDR menyatakan kompatibilitas runtime saat tag image tidak memuat versi, yang penting bila Anda me-mirror image dengan tag sendiri.

Baru juga: output profiler kini menghasilkan spec.components v1beta1 dengan podTemplate, dan sebuah DGDR bisa mengatur features.kvRouter.enabled untuk memasang DYN_ROUTER_MODE=kv di frontend. Perbaikan fidelity konversi untuk metadata envelope dan service annotation masuk di rilis yang sama, cara sopan untuk mengatakan bahwa konversi awal sempat kurang sempurna di beberapa tempat. Bandingkan objek Anda sebelum dan sesudah.

TLS dan mTLS untuk transport, dan apa yang belum tercakup

Rilis 1.5.0 menambah TLS opsional pada TCP request dan response dispatch plane, serta environment variable yang sepadan dan dukungan URL tls:// untuk NATS, dengan mutual TLS opsional yang menambahkan verifikasi sertifikat klien. Operator ikut membantu: sepuluh field path sertifikat di InfrastructureConfiguration-nya diinjeksikan sebagai environment variable TLS NATS dan TCP ke setiap pod DGD, dan Operator memvalidasi rantai dependensinya saat startup. Pengecekan startup itu bagian yang berguna, karena rantai yang setengah terkonfigurasi gagal dengan keras saat instalasi, bukan di tengah request.

Release notes juga menyebut enkripsi transport meluas ke HTTP server Frontend dengan mutual TLS, tetapi di bawah judul Looking Ahead, jadi anggap hop sisi klien belum tercakup di 1.5. Saat ini Anda tetap mengakhiri TLS klien di Gateway. Saya tidak menemukan contoh end-to-end lengkap dengan manifest sertifikat di halaman yang saya baca, jadi saya tidak akan mengarangnya.

Deprecation KVBM, known issue, dan jebakannya

KVBM, KV Block Manager yang membagi cache ke GPU, CPU, SSD, dan penyimpanan remote, di-deprecate di 1.5.0 dengan target penghapusan di 1.7.0. Ia masih bekerja, dan wheel kvbm serta contoh launch vLLM tidak berubah. Saran migrasi di ledger adalah memakai KV offloading bawaan engine untuk tiering host dan disk, dan ledger tegas bahwa berbagi cache lintas node adalah milik proyek terpisah yang masih awal bernama KVCR, yang tidak menggantikan KVBM. Pengumuman 1.0 menjual dukungan object storage milik KVBM, jadi siapa pun yang mengadopsinya kini punya jam yang berjalan.

Lalu apa yang rusak saat ini. Menurut release notes, setiap request inference ke SGLang sidecar masih gagal dengan HTTP 500 di 1.5.1, akibat protocol mismatch dengan SGLang bawaan yang diperbaiki di upstream v0.5.19, dengan perbaikan Dynamo ditargetkan di 1.6.0 dan tanpa workaround. Beberapa video H.264 juga bisa membuat worker crash saat PyNvVideoCodec 2.2.3 men-decode frame terakhir, dan itu berlaku juga di 1.5.0. Input gambar dan audio tidak terpengaruh.

Dua jebakan kecil. Di namespace dengan injeksi Istio, proxy Gateway tidak boleh memiliki sidecar istio-proxy atau Anda mendapat HTTP 500 lewat Gateway. Dan bila prefix overlap tampak diabaikan, dokumentasi menunjuk worker yang tidak mempublikasikan KV event atau block size yang tidak cocok. Checklist kesiapannya adalah kondisi Ready pada DGD, InferencePool yang dihasilkan, kondisi route Accepted dan ResolvedRefs keduanya True, dan log EPP yang menunjukkan pemilihan endpoint.

Yang dikerjakan hari Senin

Mulai dari audit yang tidak mengubah apa pun, lalu pilih jalur migrasi. Urutannya:

1. Temukan setiap DGD yang masih membawa kontrak Go dengan mencari eppConfig, dan catat tag image EPP yang dikunci masing-masing.
2. Pastikan stored version CRD setelah upgrade Operator dan arahkan ulang konfigurasi webhook yang Anda kelola sendiri ke path v1beta1.
3. Cari kvbm di manifest dan skrip launch, lalu putuskan apakah offloading bawaan engine sudah cukup untuk tiering Anda sebelum 1.7.0.
4. Bila Anda menjalankan worker multimodal di 1.5.1, set DYN_MM_TRUST_EGRESS_PROXY=1 hanya di tempat media benar-benar lewat proxy, dan set DYN_MM_LOCAL_PATH untuk file input lokal.
5. Latih cutover blue/green di namespace staging dengan header canary, termasuk patch rollback-nya, sebelum menyentuh production.

Perintah di bawah adalah audit dan cutover-nya. Nama CRD adalah apa pun yang ditemukan grep di cluster Anda; saya tidak memverifikasi bentuk jamaknya, jadi saya mencarinya, bukan menebak.

# 1. Which DGDs still carry the Go EPP contract, and what image do they pin?
kubectl get dynamographdeployment -A -o yaml | grep -n -E "eppConfig|dynamo-frontend:"

# 2. Did the Operator's migrator move storage to v1beta1? Look the CRD up first.
kubectl get crd | grep nvidia.com
kubectl get crd <name-from-above> -o jsonpath='{.status.storedVersions}'

# 3. Anything of yours still depending on KVBM before the 1.7.0 removal?
grep -rn -i kvbm deploy/ scripts/ charts/

# 4. Is the Gateway proxy free of an istio-proxy sidecar?
kubectl get pods -n my-model -l gateway.networking.k8s.io/gateway-name=inference-gateway \
  -o jsonpath='{.items[*].spec.containers[*].name}'

Aturan yang saya bawa dari Dynamo 1.5 adalah memisahkan upgrade yang terjadi pada Anda dari yang Anda pilih. Upgrade Operator aman diambil sendiri dan memigrasikan CRD Anda; perubahan EPP adalah pilihan dengan batas rollback, jadi jadwalkan, canary, dan simpan pool lama sampai jendelanya tutup. Perlakukan setiap benchmark vendor sebagai iklan dan setiap tanggal penghapusan sebagai tenggat.