LoopVQ, döngülü transformer KV cache'lerini bir bit altında saklıyor ve verimi yaklaşık iki katına çıkarıyor

Her döngüyle büyüyen cache için bit-altı sıkıştırma

LoopVQ, döngülü transformer modellerinin key-value cache'ini eleman başına bir bitin altında saklayan bir quantization yöntemi; araştırmanın dev.to'daki yazısına göre, donanımda hiçbir değişiklik yapmadan serving verimini yaklaşık iki katına çıkarıyor.

Hedeflenen nokta, mimariye özgü belirli bir sorun. Döngülü transformerlar, birbirinden farklı birçok katmanı üst üste eklemek yerine aynı katmanı tekrar tekrar çalıştırıyor ve döngüden her geçiş kendi key ve value'larını yazıyor. Bu yüzden cache, döngü adımı sayısıyla birlikte büyüyor ve serving anında bellek kullanımına hâkim duruma geliyor. dev.to'ya göre, KV cache'ler için önceki vector quantization şemaları döngü ekseni boyunca ortaya çıkan fazlalığı hiç ele almamıştı; bu da olası gecikme düşüşünün büyük kısmının kullanılmadan kalması anlamına geliyordu.\n

Yöntem nasıl çalışıyor

LoopVQ, her döngü adımını bağımsız olarak quantize etmek yerine birden fazla döngü adımını birlikte kodluyor ve ardından quantization codebook'larını ince ayarla güncelliyor. Bu adımlar birlikte, her cache elemanını bir bitin altına indirirken modelin işlevsel davranışını koruyor. İki dağıtım detayı öne çıkıyor: uygulama SGLang'in serving yığınına entegre oluyor ve altta yatan transformer'ın yeniden eğitilmesini gerektirmiyor.

Ölçümler ne gösteriyor

dev.to'nun bildirdiğine göre, eleman başına 0.5 bitte, uzun bağlamlarda decode gecikmesi 32K token'lık bir bağlamda BF16 değerinin yaklaşık yarısına düşüyor. Cache okumaları decode hattına hâkim olduğundan, kazanç bağlam uzunluğuyla birlikte artıyor.

Tepe verimi gecikmeden daha da fazla iyileşiyor: 1.4B Ouro modelinde 6.1 katı değil, 4.3 katına, 2.6B Ouro modelinde ise BF16 baselines'a göre 6.1 katına kadar çıkıyor. Tipik batch boyutları için dev.to, bunu aynı donanımda saniye başına istek sayısında yaklaşık iki kat artış olarak yorumluyor. Üretilen diziler uzadıkça ve tam duyarlıklı batch'ler küçüldükçe fark açılıyor.

Kalite 0.5 bitte korunuyor; akıl yürütme ve erişim (retrieval) görevlerindeki kayıp ihmal edilebilir düzeyde ve chain-of-thought benchmark'larında sonuçlar tam duyarlıklıyla eşleşiyor.

Uyarılar

Değerlendirme, 1.4B ve 2.6B Ouro modellerinin yanı sıra Huginn modellerini kapsıyor ve hepsi döngülü mimariler. Yöntem, eğitimden sonra uygulanan bir codebook ince ayarı adımına dayanıyor; dev.to, yöntemin diğer mimarilere taşınmasının mimariye özgü kalibrasyon gerektirebileceği konusunda uyarıyor. Bu nedenle daha geniş benimsenme muhtemelen bu işi otomatikleştiren araçlara bağlı olacak. 0.25 bite indirmekse BF16 doğruluğunun büyük kısmını yalnızca TaSQ ile birleştirildiğinde koruyor; bu da ultra düşük duyarlılığın hâlâ bir kalite ödünü taşıdığının göstergesi.

Neden önemli

KV cache, çıkarım (inference) ekonomisinin en büyük kaldıraçlarından biri: GPU başına belleğe kaç isteğin sığacağını sınırlıyor, bu da verimi ve token başına maliyeti sınırlıyor. Model ağırlıklarına, yeniden eğitime veya donanıma dokunmadan istek kapasitesini iki katına çıkaran cache düzeyinde bir değişiklik, uzun bağlamlı serving için doğrudan bir maliyet düşüşü — üstelik cache baskısının en yoğun olduğu iş yükü tam olarak bu.

Bunun bir de benchmark anlamı var. Serving yığınları decode hızını ham BF16 gecikmesine kıyasla raporlamaya devam ederse, ulaşılabilir olanın altını raporlamış olurlar; yazı, alanın uzun bağlamlı decode sayıları için bit-altı KV cache yapılandırmasını standart baseline olarak görmesi gerektiğini savunuyor.