GPU tarafında görülen utilisation değeri çoğu zaman yanlış yorumlanıyor. İzleme panellerinde görülen düşük oran, genellikle GPU’nun hesaplama birimlerinin ne kadar aktif olduğunu gösteriyor; yani cihazın Kubernetes açısından yeni bir iş yüküne açık olup olmadığını değil. Bu nedenle yüzde 5 ya da yüzde 10 compute activity görülen bir GPU, pratikte tamamen dolu ve başka bir pod için kullanılamaz durumda olabilir.
Buradaki temel ayrım allocation ile utilisation arasında. Bir model VRAM’e yüklendiğinde, istek gelmese bile belleği işgal etmeyi sürdürür. Inference servisi dakikada tek sorgu cevaplıyor olabilir; bu durumda compute activity düşük görünür. Ancak pod ilgili GPU’yu tahsis etmişse Kubernetes o cihazı başka bir iş yüküne vermez. Sonuç olarak izleme ekranında “boşmuş gibi” görünen GPU, scheduler açısından kapalıdır.
Konuyu gündeme taşıyan verilerden biri, Cast AI’nin 2026 tarihli Kubernetes optimizasyon raporunda yer alan ortalama yüzde 5 GPU compute utilisation bulgusu. Bu, üretim kümelerinde yaygın bir düşük kullanım ve fazla kaynak ayırma eğilimine işaret ediyor. Ancak bu veri, ölçülen ortamlardaki GPU kapasitesinin yüzde 95’inin hemen geri kazanılabileceği anlamına gelmiyor. Her kümede, hatta her GPU’da darboğazın tipi ayrı ayrı doğrulanmalı.
Kuyrukta bekleyen iş yükleri ile düşük utilisation görünen GPU’ların yan yana bulunmasının birkaç farklı nedeni var. İlki ve en yaygını, bir iş yükünün tüm fiziksel GPU’yu elinde tutması. NVIDIA Kubernetes Device Plugin varsayılan olarak GPU’ları paylaştırmıyor. Bir pod nvidia.com/gpu: 1 istediğinde, yaşam döngüsü boyunca o fiziksel aygıtın tek sahibi oluyor. Uygulama GPU’nun küçük bir bölümünü kullansa bile başka pod aynı cihaza yerleşemiyor.
Bu durum özellikle bursty çalışan inference servislerinde sık görülüyor. Birden fazla model kendine ayrılmış GPU üzerinde düşük yoğunluklu istekler beklerken tüm cihazlar tahsis edilmiş görünüyor. Toplam compute activity düğüm genelinde yüzde 10’un altında olsa bile, scheduler elde boş GPU sayısını sıfır gördüğü için yeni pod Pending durumuna düşebiliyor. Böyle senaryolarda sorun donanım kıtlığından çok kaynak sunum şekliyle ilgili.
İkinci önemli neden bellek kapasitesi. Düşük compute utilisation, boş VRAM anlamına gelmiyor. Büyük bir model, taban ağırlıklarıyla bile çok yüksek bellek tüketebiliyor ve KV cache eklendiğinde ihtiyaç daha da büyüyor. Daha küçük modeller de tek GPU’ya sığsa bile VRAM’i sürekli rezerve ediyor. Bu yüzden yüzde 8 compute activity görülen bir cihazda kullanılabilir bellek sıfıra yakın olabilir. Böyle bir durumda zaman dilimleme ile paylaşım denemek sorunu çözmez.
Bellek tarafı, paylaşım yöntemi seçiminde belirleyici. Time-slicing hesaplama erişimini sıraya koyarak paylaştırıyor ama belleği bölmüyor; tüm iş yükleri aynı VRAM alanını paylaşıyor. Toplam bellek ihtiyacı cihaz kapasitesini aşarsa kararlı birlikte çalışma mümkün olmuyor. MIG ise donanımsal bellek izolasyonu sağlayarak bu tip sorunların bir bölümünü çözebiliyor, ancak uygun GPU donanımı gerektiriyor ve yapılandırma yaklaşımını değiştiriyor.
Üçüncü başlık yerleşim kuralları. Bazı iş yükleri, aslında boşta GPU olsa bile node affinity, node selector, topology spread kısıtları ya da taint/toleration uyumsuzlukları yüzünden schedule edilemiyor. Örneğin belirli bir GPU modeli isteyen pod, teknik olarak daha güçlü ama farklı sınıftaki boş GPU’lara yerleşemeyebilir. Bu da dışarıdan kapasite sorunu gibi görünse de gerçekte scheduler yapılandırması problemidir.
Dördüncü olasılık ise çalışan iş yükünün GPU dışında bir yerde beklemesi. CPU üzerinde yapılan ön işleme, veri yükleme, PCIe aktarımı ya da ağ gecikmesi yüzünden GPU’nun hesaplama birimleri düşük aktivitede kalabilir. LLM sunucusu tokenisation aşamasında ya da uzak depodaki KV cache erişiminde takılıyorsa, yüzde SM değeri düşük görünür; ama bu GPU başka bir iş yükü için otomatik olarak uygun hale gelmez. Bu senaryoda çözüm daha fazla GPU eklemek değil, veri yolunu veya CPU tarafını iyileştirmektir.
Tanı sırası bu nedenle kritik. Önce tahsis durumuna bakmak gerekiyor: cihazlar gerçekten boş mu, yoksa sadece düşük aktivitede mi? Ardından VRAM doluluğu kontrol edilmeli. Sonra Pending pod olayları incelenerek yerleşim kısıtları aranmalı. En son aşamada ise zaman serisi halinde compute davranışı izlenip CPU, I/O veya ağ darboğazları değerlendirilir. Bu sıralama, yanlış nedenle donanım yatırımı yapma riskini azaltıyor.
Paylaşım tarafında tek bir doğru yöntem yok. Dedicated allocation en yüksek izolasyonu sunuyor ama düşük yoğunluklu iş yüklerinde kapasiteyi verimsiz bırakabiliyor. Time-slicing, çok sayıda küçük ve kesintili inference iş yükü için pratik; üstelik eski nesil NVIDIA GPU’larda da çalışıyor. Buna karşılık bellek ve hata izolasyonu sunmuyor. MIG, A100, A30, H100, H200 ve Blackwell sınıfı yeni GPU’larda donanımsal bölümlendirme sağlıyor; daha güçlü QoS veriyor ancak sabit profillerle çalışıyor. MPS ise CUDA süreçlerini eşzamanlı yürütmeye odaklanıyor ve farklı bir paylaşım modeli sunuyor.
Özellikle üretim ortamında time-slicing devreye alınacaksa gecikme etkisi mutlaka ölçülmeli. Ortalama değil p95 ve p99 gecikmeler izlenmeli; çünkü çakışan istek patlamaları ilk olarak kuyruk sonundaki gecikmeleri büyütüyor. VRAM ön tahsisi yapan inference sunucuları da burada önemli. Örneğin bazı sunucular, istek gelmeden önce belleğin çok büyük bölümünü ayırabiliyor. Bu durumda iki “boş” servis bile aynı GPU üzerinde belleği tamamen tüketebilir.
Sonuç olarak düşük GPU utilisation tek başına boş kapasite kanıtı değil. Kuyrukta bekleyen iş yüklerinin nedeni çoğu zaman eksik donanımdan önce tahsis modeli, VRAM sınırı, yerleşim kuralı veya uygulama katmanındaki darboğaz oluyor. Doğru soru “GPU neden boş görünüyor?” değil, “Scheduler ve uygulama açısından gerçekten ne kadar kullanılabilir kaynak var?” sorusu. Buna yanıt verilmeden yapılan yeni GPU alımı, sorunu çözmek yerine sadece maliyeti artırabilir.
