Buoyant, Kubernetes ve vLLM için açık kaynak çıkarım kontrol düzlemi Kinference'ı yayımladı

Linkerd'in arkasındaki şirket Buoyant, Kubernetes ve vLLM üzerinde çıkarım platformları kurmak için geliştirdiği Kinference adlı açık kaynak projeyi GitHub'da yayımladı. Apache 2.0 lisansıyla paylaşılan proje, bir vLLM işçi havuzunun önüne yerleşerek gelen her isteğin hangi sunucuya gideceğine karar veriyor.

Kinference şu anda v0.1.0-alpha.7 sürümünde ve Rust ile yazıldı. Buoyant'ın açıklamasına göre proje, yönlendirme politikalarını, token hız sınırlarını, KV-cache farkındalıklı yük dengelemesini ve kiracı bazlı metrikleri tek katmanda topluyor. Şirket, vLLM'i veri düzlemi, Kinference'ı ise kontrol düzlemi olarak tanımlıyor.

Kinference ne işe yarıyor?

Sistem iki parçadan oluşuyor: bir trafik geçidi ve bir çıkarım işleyicisi. Projenin GitHub README dosyasına göre işleyici gRPC arayüzü sunuyor; aldığı isteğe karşılık seçilen uç noktayı ve gerektiğinde değiştirilmiş istek gövdesini döndürüyor. Buoyant Gateway gibi bir vekil sunucuyla birlikte çalışıyor.

Kinference, vLLM'in KV-cache olaylarını ve motor metriklerini izliyor. Cache olaylarını işlemek için şu anda Nvidia'nın dynamo-kv-router kütüphanesini kullanıyor. Yapılandırma beş Kubernetes CRD'si üzerinden yapılıyor: GatewayBackend, InferencePolicy, InferencePool, InferenceProvider ve InferenceWorkerSet.

Çıkarım politikaları nasıl çalışıyor?

InferencePolicy kaynakları, her isteğin nasıl yönlendirileceğini ya da reddedileceğini tanımlayan bildirimsel kurallar içeriyor. Kurallar kiracı, istenen model, GPU havuzunun durumu ve anlamsal etiketler üzerinden eşleşme yapabiliyor. Projenin sitesindeki örnekler beş kalıbı kapsıyor: basit istemleri daha küçük modele yönlendirmek, kuyruğu şişen işçileri atlayıp Bedrock gibi bulut sağlayıcılara taşmak, kişisel veri etiketi devreye girdiğinde dış sağlayıcıları devre dışı bırakıp isteği reddetmek, boştaki GPU'larda toplu işleri çalıştırmak ve tek bir kararlı model adını birden çok modelle eşlemek.

Kuralların çoğu "minimize: PredictedTTFT" ifadesiyle bitiyor. Kinference, her aday uç nokta için cache örtüşmesini ve kuyruk uzunluğunu hesaba katarak ilk token süresini tahmin ediyor. Politikalar git üzerinde tutulabiliyor ve kinfctl komut satırı aracıyla çevrimdışı doğrulanabiliyor.

Ölçümler ne gösteriyor?

Buoyant, Kinference'ı düz Kubernetes yük dengelemesiyle karşılaştıran bir ölçüm yayımladı. Her iki kolda da Qwen3.8-27B-FP8 modeli çalıştıran 3 vLLM 0.31.0 podu kullanıldı; her pod tek bir L40S GPU üzerindeydi. Yük GuideLLM 0.8.1 ile üretildi. Referans olarak, kube-proxy'nin her bağlantı için rastgele pod seçtiği bir ClusterIP Service kullanıldı.

Şirketin paylaştığı verilere göre ortak önekli iş yükünde medyan ilk token süresi 6,88 saniyeden 0,31 saniyeye, yani yüzde 95 düştü. Çok turlu iş yükünde medyan uçtan uca gecikme yüzde 32 azaldı. Kontrol trafiğinde p95 ilk token süresi 21,46 saniyeden 12,33 saniyeye indi; Buoyant bunu kuyruk farkındalıklı dengelemeye bağlıyor.

Ortak öneki olmayan istemlerde ise medyan ilk token süresinde kazanç görülmedi: 6,92 saniyeye karşı 6,83 saniye. Buoyant, ölçümde kullandığı 8 ve 4 saniyelik hizmet seviyesi hedeflerinin sohbet uygulamalarından çok çevrimdışı ajanlara uygun olduğunu da not ediyor. Tüm bu rakamlar şirketin kendi ölçümüne dayanıyor ve referans, llm-d ya da Dynamo gibi başka bir cache farkındalıklı yönlendirici değil, rastgele yönlendirme.

Rakiplerden ayrıldığı nokta ve kurulum

Kinference'ın ayrıştığı alan ham sunum performansı değil, yönetişim: politikalar, model takma adları, sağlayıcıya geri düşme ve kiracı bazlı muhasebe. Kaynak metne göre llm-d ve Dynamo ham sunum performansı, ayrıştırma ve motor kapsamı konusunda önde.

Kurulum, başlangıç kılavuzuna göre beş adımda tamamlanıyor. Ekipler önce Gateway API v1.5.1 CRD'lerini, ardından Buoyant gateway Helm grafiğini, son olarak da Kinference grafiğini kuruyor. Proje Prometheus metrikleri ve Grafana panolarıyla birlikte geliyor; metrikler arasında ilk token süresi, tokenlar arası süre, uçtan uca gecikme ve cache'e isabet eden ve etmeyen istem tokenları çoğunlukla kiracı bazında yer alıyor.

Neden önemli?

Açık ağırlıklı modelleri kendi altyapısında çalıştıran ekipler için darboğaz giderek model sunucusunun kendisi değil, onun üstündeki yönlendirme katmanı oluyor. Kinference, aynı Kubernetes kümesinde birden çok modele ve birden çok iç müşteriye hizmet veren ekipler için bu katmanı standart Kubernetes nesneleriyle yönetilebilir hale getirmeyi hedefliyor.

Proje henüz alfa aşamasında. Buoyant'ın belirttiğine göre hız sınırlama, sınıflandırıcılar ve Anthropic API desteği henüz yayımlanmadı. Türkiye'deki ekiplerin projeyi ne zaman üretim ortamında kullanabileceğine dair bir takvim açıklanmadı; kurulum için GPU destekli bir Kubernetes kümesi ve vLLM gerekiyor.