---
title: "Buoyant'ın Kinference'ı Kubernetes'te vLLM iş yüklerini yönetiyor"
description: "Buoyant, Kubernetes'te vLLM iş yüklerini yöneten açık kaynak Kinference control plane'ini yayımladı. GPU kullanımı ve cloud'a taşma kurallarını inceledik."
image: "https://sezer.in/wp-content/uploads/2026/11/buoyant_kinference_kubernetes_770x330.jpg"
url: "https://sezer.in/haberler/kinference-control-plane-kubernetes-vllm/"
date: "2026-11-06T15:41:10+03:00"
updated: "2026-11-06T15:41:10+03:00"
author: "Sezer Şanlıkan"
lang: "tr"
source: "https://sezer.in/haberler/kinference-control-plane-kubernetes-vllm/"
---

# Buoyant'ın Kinference'ı Kubernetes'te vLLM iş yüklerini yönetiyor

Buoyant, Kubernetes cluster'larında vLLM üzerinde çalışan yapay zekâ iş yüklerini yönetmek için açık kaynak Kinference control plane'ini yayımladı. Araç, istekleri dağıtırken GPU cache verisini ve kuyruk durumunu kullanıyor, GPU tüketimini tenant, grup veya ekip bazında izliyor. Tanımlanan koşullarda inference isteklerini cloud sağlayıcılarına yönlendirebiliyor.

## vLLM nedir?

vLLM, büyük dil modellerini servis etmek için kullanılan açık kaynak bir inference motorudur. Bellek yönetimini PagedAttention adlı yöntemle yaparak aynı GPU üzerinde daha fazla eşzamanlı istek işlemeyi hedefler. Kendi altyapısında model barındıran ekipler tarafından sıkça tercih edilir; OpenAI uyumlu bir API sunucusuyla gelir. Alternatifleri arasında Text Generation Inference ve SGLang sayılabilir.

## Kinference control plane hangi boşluğu dolduruyor

Kubernetes'te vLLM ile model servis ediyorsanız iki katmanınız var: vLLM'in inference server'ı ve Kubernetes'in genel scheduling'i. İsteğin hangi replica'ya gideceği, kuyruk dolunca ne olacağı ve GPU'yu kimin harcadığı bu iki katmanın cevapladığı sorular değil.

Kinference control plane bu araya oturuyor. Buoyant'ın tarifine göre siz performans, maliyet ve compliance sınırlarını tanımlıyorsunuz, Kinference de istekleri bu sınırlar içinde dağıtıyor. Dağıtım kararında GPU üzerindeki cache verisi ve kuyruk durumu kullanılıyor.

Cache verisinin karara nasıl girdiğini Buoyant henüz ayrıntılandırmadı. Performans testi planlıyorsanız önce bu mekanizmayı dokümantasyonda bulun; yoksa ölçtüğünüz farkın nereden geldiğini açıklayamazsınız.

## Önce kendi GPU kullanım oranınızı ölçün

William Morgan'a göre GPU kullanım oranı genelde tek haneli. Bu genel bir iddia, sizin cluster'ınızın durumunu söylemiyor. Kinference'ın getirisini hesaplamak için elinizde bir baseline olmalı.

Hangi node'larda kaç GPU'nun allocatable olduğunu ve anlık kullanımı şöyle görebilirsiniz:

```
kubectl describe nodes | grep -i "nvidia.com/gpu"
nvidia-smi
```

Birkaç günlük kullanım eğrisi alın. Oran gerçekten düşükse sorununuz GPU sayısı değil, isteklerin GPU'lara dağılımı. O durumda yeni GPU satın almadan önce Kinference gibi bir katmanı deneyin. Oran zaten yüksekse fark daha çok kuyruk yönetiminde ve gecikmede görülür.

## Cloud'a taşma kuralı bir compliance kararı

Kinference, isteğe bağlı olarak inference isteklerini cloud sağlayıcılarına gönderebiliyor. Tetikleyiciler üç türde: GPU pool'unun dolması, belirli tenant'ların kullanımı ve isteğin kendi özellikleri.

Sorun burada çıkabilir. Self-hosted inference'a çoğu zaman hassas veriyi üçüncü tarafa vermemek için geçiliyor. Yanlış yazılmış bir taşma kuralı, yoğun bir saatte bu veriyi tam da kaçındığınız yere gönderir.

Pilot aşamasında şu sırayı izleyin:

- Cloud yönlendirmesini başlangıçta kapalı tutun.
- Hassas veri işleyen tenant'ları hiç taşmayan bir sınıfa koyun.
- Taşmaya izin verdiğiniz tenant'ları açıkça listeleyin, varsayılanı reddetmeye bırakın.
- Her yönlendirme kararını log'layın ve audit kaydına bağlayın.

Maliyeti de hesaplayın. Morgan'ın tasarruf gerekçesi, token bazlı ücretlendirmeden çıkıp sabit altyapıya geçmek. GPU pool'unuz sık doluyorsa taşma trafiği token faturasını geri getirir; saturation eşiğini buna göre belirleyin.

## Tenant bazında GPU muhasebesi

Kinference, GPU kullanımını tenant, grup veya ekip bazında atfediyor. Paylaşımlı bir GPU cluster'ı işletiyorsanız showback veya chargeback raporunu bununla en kısa yoldan çıkarabilirsiniz. Hangi ekibin GPU'yu boşta tuttuğunu görmeden kullanım oranını yükseltemezsiniz.

Buoyant, tenant kavramının Kubernetes nesnelerine nasıl eşlendiğini açıklamadı. Kinference ekibi namespace'ten mi, label'dan mı, kendi tanımından mı çıkarıyor, buna bakmadan muhasebe modelinizi kurmayın. Mevcut namespace düzeniniz ekip sınırlarıyla örtüşmüyorsa raporlar yanıltıcı çıkar.

## Pilotu nasıl sınırlamalı

Duyuruda kurulum adımı, sürüm numarası veya lisans bilgisi yok. Denemeden önce projenin repo'sunu, lisansını ve hangi vLLM sürümlerini desteklediğini kontrol edin.

İlk denemeyi dar tutun: staging cluster'ında tek model, tek veya iki tenant, cloud yönlendirmesi kapalı. Kinference öncesi ve sonrası için GPU kullanım oranını ve p95 gecikmeyi aynı yük altında karşılaştırın. Taşma kurallarını ancak bu iki metrik oturduktan sonra, önce hassas veri işlemeyen bir tenant üzerinde açın.