KV Cache GPU’dan Taşıyor: vLLM ile Bellek, Depolama ve Yeniden Hesaplama Dengesi

Uzun bir konuşmanın tekrar eden bağlamını her turda yeniden işlemek pahalı olabilir. KV cache bu tekrarın bir kısmını önler; fakat cache de bellek tüketir. Eşzamanlı oturum sayısı arttığında model ağırlıkları kadar, oturumların taşıdığı durum da kapasite kararını etkiler.

Güncel gelişme: katmanlı KV offloading

vLLM ekibinin 10 Eylül 2026 tarihli yazısı, v0.22’den beri mevcut olan katmanlı KV cache mekanizmasını açıklıyor. GPU’dan çıkarılan durum önce host belleğine taşınıyor; dosya sistemi, nesne depolama veya uzak peer gibi katmanlar kapasiteyi genişletebiliyor. Yeniden kullanımda veri host belleği üzerinden GPU’ya yükleniyor. Bu, GPU belleğinden çıkarılmış bir prefix için yeniden hesaplama yerine geri yüklemeyi mümkün kılıyor.

Önemli ayrım şu: KV cache bir yanıt arşivi veya uygulamanın uzun süreli hafızası değildir. Modelin attention hesaplamasıyla ilişkili ara durumdur. Uyumlu model, token dizisi ve cache yapılandırması olmadan rastgele başka bir istekte kullanılamaz.

Ucuz bellek her zaman ucuz istek demek değil

Örnek bir kapasite planında iki seçeneği karşılaştırırdım: aynı prefix'i yeniden hesaplamak veya daha yavaş bir katmandan getirmek. İkinci seçeneğin yalnızca veri aktarımını değil, arama, kuyruk ve GPU’ya yükleme süresini de kapsaması gerekir.

T_restore = T_lookup + T_queue + T_read + T_host_to_device
T_recompute = eşleşen prefix için ölçülen prefill süresi

Bu bir performans tahmini değil, deney planı için basitleştirilmiş bir bütçedir. Aktarımlar kısmen örtüşebilir. Geri yükleme süresi daha kısa görünse bile ortak depolama hattındaki yoğunluk p95 gecikmesini kötüleştirebilir. Bu yüzden yalnızca ortalama cache hit oranına bakmak eksik kalır.

Hangi trafik için denemeye değer?

Aynı uzun sistem bağlamını kullanan oturumlar, tekrar açılan konuşmalar veya benzer prefix'lerle çalışan agent akışları iyi deney adaylarıdır. Buna karşılık çoğu isteğin birbirinden bağımsız olduğu ve bağlamın kısa kaldığı bir sistem, cache taşıma maliyetini geri kazanamayabilir.

Benim yaklaşımım önce gerçek trafikte yeniden kullanılan prefix uzunluğunu ve tekrar aralığını ölçmek olurdu. Ardından yalnızca host belleği ile başlayıp, daha uzak bir katmanın ek kapasitesinin gerçekten işe yarayıp yaramadığını sınardım. Daha çok saklamak, daha çok işe yarayan veri saklamakla aynı şey değildir.

Deneyde tutacağım kayıtlar

• Soğuk ve sıcak başlangıç: İlk isteğin ve aynı bağlamla gelen sonraki isteğin ilk token gecikmesi.
• Katman bazında maliyet: Hit oranı, okunan/yazılan byte, geri yükleme süresi ve yeniden hesaplanan token sayısı.
• Baskı altında davranış: Host belleği dolduğunda, depolama yavaşladığında ve oturum sayısı arttığında p95 gecikmesi.
• İzolasyon: Kiracı sınırları, cache anahtarları, erişim izinleri ve silme politikalarının doğrulanması.

Paylaşılan cache için güvenlik incelemesi de kapasite incelemesinin parçası olmalı. KV durumunu zararsız bir geçici dosya gibi ele almazdım; hangi kullanıcıların durumunun nerede tutulduğunu ve ne zaman silindiğini açıkça tanımlardım.

Buradaki çıkarımım, inference kapasitesinin GPU belleğinin yanında veri hareketiyle de planlanması gerektiği. Ek katmanların değeri ancak aynı donanım, trafik ve gecikme hedefi altında karşılaştırmalı ölçümle anlaşılır. Bu yazı ölçülmüş bir hızlanma iddiası taşımıyor.