16 Bit Yerine 3 Bit: TurboQuant'ı Parçalama ve Ne Zaman Gerçekten Etkinleştirileceği

Mart 2026'da Google, dil modelleri için bir bellek sıkıştırma algoritması olan TurboQuant hakkında bir yazı yayınladı ve bu, bellek üreticisi hisselerinin bir hafta içinde toplam piyasa değerinden yaklaşık 90 milyar dolar kaybetmesine neden olan bir piyasa paniğine yol açtı. Algoritma, KV-önbellek sorununu ele alıyor: LLM'ler metin üretirken, önceki tüm belirteçler için ara hesaplamaları saklarlar; bu, bağlam uzunluğuyla doğrusal olarak büyür ve onlarca gigabayt tüketebilir. Örneğin, 128K bağlamdaki Llama 3.1 70B için KV-önbelleği BF16'da yaklaşık 40 GB yer kaplar ve bu da tek bir H100 GPU'ya sığmasını imkansız kılar. TurboQuant, vektörlere nicelemeden önce rastgele bir döndürme uygulayarak ve ardından optimal bir Lloyd-Max niceleyici kullanarak KV-önbelleğini 5-6 kat sıkıştırır; tüm bunlar kalibrasyon veya ince ayar olmadan yapılır. Bu veri-bilinçsiz yaklaşım, herhangi bir dönüştürücü modelde çalışır. Google, 'H100 GPU'larında 8 kata kadar hızlanma' iddiasında bulunuyor, ancak topluluk analizleri bunun FP32'ye göre ölçüldüğünü gösteriyor; gerçek hızlanma yalnızca dikkat için yaklaşık 4 kat ve bellek tasarrufu asıl faydayı sağlıyor. Küçük modellerdeki (8B'ye kadar) kıyaslamalar, LongBench ve Needle-in-a-Haystack üzerinde sıfır doğruluk kaybı gösteriyor, ancak 70B+ modeller için veri yok ve topluluğun 104B'lik bir modelde yaptığı testler yalnızca %3,6'lık bir şaşkınlık artışı gösteriyor. KVTC (20 kata kadar sıkıştırma ancak kalibrasyon gerektirir), RotorQuant (daha hızlı döndürme ancak daha düşük kalite) ve KIVI (16 kat sıkıştırma, Hugging Face'e entegre) gibi alternatiflerle yapılan karşılaştırmalar kapsamlı bir tablo sunuyor. Resmi kodun olmaması, 15'ten fazla topluluk uygulamasıyla hafifletiliyor.