Buoyant baru rilis Kinference, control plane open source buat ngatur inference vLLM di Kubernetes. Dia pakai routing berbasis policy dan KV-cache-aware load balancing, dan benchmark internal nunjukin median TTFT turun 95% buat traffic shared-prefix. Masih alpha tapi udah bisa dicoba.
Buoyant, tim di balik service mesh Linkerd, baru saja drop Kinference, sebuah inference control plane open source yang dirancang buat ngatur vLLM di atas Kubernetes. Proyek ini lisensi Apache 2.0, ditulis pakai Rust, dan sekarang ada di versi v0.1.0-alpha.7. Intinya simpel: Kamu punya segudang vLLM worker yang serve model open-weight buat banyak tim internal. Kinference duduk di depan mereka, ngatur request mana yang dikirim ke worker mana, sambil menerapkan routing policy, rate limit per token, load balancing yang sadar KV-cache, dan metrik per tenant, semuanya di satu layer.
Arsitekturnya punya dua bagian utama: traffic gateway dan inference handler. Gateway nerima request OpenAI-compatible dari client, lalu tanya ke controller lewat gRPC: "Request ini harus ke mana?". Controller (Kinference) jawab dengan endpoint target plus body yang mungkin sudah dimodifikasi. Dia ngawasi event KV-cache dan metrik engine vLLM lewat crate dynamo-kv-router milik NVIDIA. Konfigurasi hidup di 5 CRD Kubernetes: GatewayBackend, InferencePolicy, InferencePool, InferenceProvider, dan InferenceWorkerSet. Jadi kamu atur semuanya lewat YAML, bisa divalidasi offline pakai CLI kinfctl sebelum di-deploy.
Policy deklaratif: kamu atur aturan, dia eksekusi
InferencePolicy itu jantungnya. Kamu tulis aturan deklaratif: misalnya, request dengan tag complexity-low untuk model glm-5.3 bisa diarahkan ke model lebih kecil qwen-3.6-27b, kecuali model besar sudah punya prefix cache-nya, lalu dia menang di predicted TTFT. Atau policy burst to cloud: worker yang antrean prompt-nya lebih dari 2 di 30 detik terakhir di-drop, lalu fallback ke provider eksternal kayak Bedrock atau Databricks. Ada juga PII stays local: kalau tag pii-detected nyala, semua provider eksternal dibuang, dan kalau gak ada worker lokal yang aman, request direject (fail closed). Batch on idle GPUs: workload batch/deferrable cuma dikirim ke worker dengan usage KV-cache di bawah 70%. Model aliasing: client cuma minta standard-model, platform team bebas ganti model di belakang layar tanpa sentuh kode client.
Benchmark: TTFT turun 95% tapi cuma kalau ada shared prefix
Buoyant publish benchmark self-reported lawan plain Kubernetes Service (kube-proxy random routing). Setup: 2 pool, masing-masing 3 vLLM 0.31.0 pod di 1 L40S GPU, model Qwen3.8-27B-FP8, load dari GuideLLM 0.8.1. Hasilnya menarik: pada workload shared-prefix, median TTFT anjlok dari 6,88 detik jadi 0,31 detik (-95%). Multiturn turun dari 1,70 ke 0,59 detik (-65%). Tapi pada control workload tanpa shared prefix, median TTFT hampir sama: 6,92 vs 6,83 detik. Artinya, keunggulan Kinference muncul banget kalau ada prefix cache yang bisa dimanfaatkan. Goodput (request per menit yang memenuhi SLO TTFT) naik 7,4x di shared-prefix dan 3,5x di multiturn. Baseline kube-proxy gak pernah meet SLO di concurrency manapun. Catatan: baseline ini random routing, bukan router cache-aware lain kayak llm-d atau Dynamo.
Posisi di antara llm-d, Dynamo, dan vLLM Production Stack
Kinference beda fokus: dia layer governance, policy, alias, provider fallback, tenant accounting. llm-d (CNCF sandbox, didukung Red Hat, Google Cloud, IBM, CoreWeave, NVIDIA) dan NVIDIA Dynamo (1.x) unggul di raw serving performance, disaggregated prefill/decode, dan coverage engine (SGLang, TensorRT-LLM). vLLM Production Stack cuma reference stack vLLM murni. Kinference punya deklarative routing policy CRD dan burst ke provider eksternal yang gak dimiliki yang lain. Tapi llm-d dan Dynamo sudah lebih matang (v0.7 dan 1.x) dan punya multi-replica controller untuk HA. Kinference masih single replica controller, faktor penting buat planning production.
Masih alpha: rate limiting, classifier, Anthropic API belum siap
README dan docs jujur: ini alpha software tanpa exposure production berkelanjutan. Token rate limiting di-promote di launch tapi README bilang belum diimplementasikan. Semantic classifier (PII, complexity tag) yang drive beberapa example policy juga belum ada. Dukungan Anthropic /v1/messages pending. Controller single replica. Jadi kalau kamu mau coba di staging atau internal tooling, silakan. Tapi buat production critical, pertimbangkan risiko HA dan fitur yang masih hilang. Installasi 5 langkah: pasang Gateway API v1.5.1 CRD, Buoyant Gateway Helm chart, terus Kinference chart. Sudah bawa Prometheus metrics dan Grafana dashboard (TTFT, ITL, end-to-end latency, cached vs uncached prompt tokens, mostly per tenant).
- Routing policy deklaratif lewat InferencePolicy CRD
- KV-cache-aware load balancing pakai predicted TTFT
- Burst ke provider eksternal (Bedrock, Databricks) saat overload
- PII tag buat fail-closed routing ke lokal only
- Model aliasing biar client gak perlu tahu model di belakang
Bottom line: Kinference itu solusi menarik buat tim platform yang udah pakai Kubernetes dan vLLM, mau tambah governance dan efisiensi cache tanpa ganti stack. Masih alpha, jadi jangan harap sempurna, tapi worth buat di-evaluasi kalau kamu ngurus inference multi-tenant internal. Cek GitHub, docs, launch post, dan benchmark report-nya buat detail lengkap.
Catatan redaksi
Kalau lo cuma ambil satu hal dari artikel ini
Buoyant baru rilis Kinference, control plane open source buat ngatur inference vLLM di Kubernetes. Dia pakai routing berbasis policy dan KV-cache-aware load balancing, dan benchmark internal nunjukin median TTFT turun 95% buat traffic shared-prefix. Masih alpha tapi udah bisa dicoba.


