vLLM hatası, karışık KV-cache gruplarına sahip modellerde KV-cache offloading işleminin yanlış chunk'lanmasına neden oluyordu

vLLM'deki ince bir bellek yönetimi hatası, bir model karışık KV-cache grupları kullandığında KV-cache offloading sırasında hatalı chunk'lamaya neden oluyordu ve bu sorun için上游 bir çözüm sunuldu. dev.to'daki bir yazıda, AWS ve Kubernetes'den vLLM ve GPU'lara kadar LLM çıkarımının altındaki katmanlar üzerinde çalışan altyapı mühendisi Debasish Mohanty, hatayı nasıl bulduğunu ve bunun çıkarım altyapısında hata ayıklama konusunda ne söylediğini ele alıyor.

Hata nasıl çalışıyordu

Otoregresif üretim sırasında model, dikkat katmanlarının ürettiği key ve value tensörlerini önbelleğe alır. Yazıda belirtildiği gibi, bu KV-cache üretim sırasında GPU belleğini en çok tüketen bileşenlerden biridir. Önbellek artık cihaza sığmadığında vLLM, önbellek bloklarını başka bir bellek katmanına boşaltabilir (offload) ve sorun tam da bu offloading yolundaydı.

Yazıya göre mevcut implementasyon hesaplamalarında yapılandırılan block_size değerini kullanıyordu. Bu varsayım tek bir KV-cache grubu düzeninin yaygın olduğu durumda geçerlidir; ancak mimarileri farklı gereksinimlere sahip KV-cache gruplarını birleştiren modeller, birlikte işlenmesi gereken farklı sayıda blok gerektiriyor. Bu amaçla block_size değerini yeniden kullanmak, offloading mantığının önbelleği hatalı şekilde chunk'laması anlamına geliyordu. Yazıda etkilenen mimarilere örnek olarak DeepSeek-V4-Flash ve Gemma-4 gösteriliyor.

Mohanty'nin vurguladığı kilit ayrım, yapılandırılan blok boyutu ile gerçekten bir birim olarak ele alınması gereken blok sayısı arasındadır. Dolayısıyla hata bir bellek kapasitesi sorunu değil, API'ye ve onun aşağı akış hesaplamalarına gömülüş eski bir varsayımdı.

Çözüm

Çözüm, block_size değerinin anlamını değiştirmek yerine, offloading mantığının KV-cache grupları yapılandırılan blok boyutundan farklı bir chunk'lama davranışı gerektirdiğinde kullanabileceği ayrı bir değer olan blocks_per_chunk'ı getiriyor. Mohanty, KV-cache implementasyonunun mevcut kullanıcıları için kırıcı bir değişiklikten kaçınmanın bilinçli bir tasarım gereksinimi olduğunu vurguluyor: block_size mevcut davranışını korurken yeni değer karışık grup durumunu doğru şekilde ele alıyor. Yazıya göre değişiklik, pull request #48878 olarak vLLM projesine upstream'a gönderildi.

Belirgin bir belirti olmayan bir hata

Yazının ortaya koyduğu kadarıyla hatayı kayda değer kılan şey ne kadar görünmez olduğuydu. Model yükleniyor. İstek başlıyor. GPU sağlıklı. Sistem yine de yanlış davranıyor; çünkü dahili bir varsayım belirli bir mimari için geçerli değil.

Mohanty, söz konusu katmanları şematikleştiriyor — model, attention ve KV cache, bellek yöneticisi, GPU belleği, runtime ve altındaki Kubernetes ya da bulut altyapısı — ve bir üretim çıkarım sisteminin her katmanının aynı varsayımlarda hemfikir olması gerektiğine dikkat çekiyor. Bir katmanın varsayımı sessizce bayatladığında, API yüzeyinde bunu gösteren hiçbir şey olmuyor.

Neden önemli

Yeni model mimarileri, eski altyapı kodunun hiç öngörmediği önbellek düzenleriyle gelmeye devam ediyor. KV-cache gruplarının tek tip olduğu dönemde yazılmış bellek yönetimi yolları, karışık gruplu modellerde sessizce hatalı davranabiliyor ve bu hata, daha geleneksel hataları yakalayan olağan "çöktü mü?" kontrollerinden bile sıyrılacak kadar ince.

Yazıdan çıkarılabilecek hata ayıklama dersi iyi genellenebilir: Son belirtiyi kovalamadan önce değişmezi (invariant) tanımlayın — API neyi vaat ediyor, scheduler ne varsayıyor, bellek yöneticisi ne hesaplıyor — ve ardından bu varsayımın daha yeni mimariler için hâlâ geçerli olup olmadığını sorun. Bu vakada hata runtime'da değil, varsayımdaydı ve önce onu tespit etmek, çözümü offloading yolunun baştan yazılması yerine küçük, geriye dönük uyumlu bir değişikliğe dönüştürdü.