Son dönemde Google Research tarafında dikkatimi en çok çeken işlerden biri TurboQuant oldu. Bunun nedeni sadece yeni bir quantization yaklaşımı olması değil. Asıl mesele, TurboQuant’ın “vektörü biraz sıkıştıralım, kalite ne olursa olsun” çizgisinden gelmemesi. Tam tersine, hem teorik olarak güçlü bir çerçeve kuruyor hem de bunu KV cache sıkıştırma ve vector search gibi çok gerçek problemlere bağlıyor.
Benim açımdan TurboQuant’ı ilginç yapan şey şu: Bu iş sadece hafızayı küçültme hikâyesi değil. Aynı zamanda attention geometrisini ve inner-product davranışını mümkün olduğunca koruma hikâyesi. Yani mesele kaç bit’e indiğin kadar, bunu yaparken modelin işini ne kadar bozduğun.
Bu yazıda TurboQuant’ın ne olduğunu, nasıl çalıştığını, neden klasik vector quantization yöntemlerinden ayrıştığını ve bence neden üzerine ciddi şekilde çalışılması gerektiğini kendi perspektifimden anlatacağım.
TurboQuant tam olarak nedir?
En sade tanımıyla TurboQuant, yüksek boyutlu vektörleri çok daha düşük bit genişliğinde temsil etmeye çalışan, çevrim içi çalışabilen ve veri kümesine özel codebook eğitimi gerektirmeyen bir vektör niceleme yaklaşımı.
Buradaki iki hedef kritik:
- MSE’yi düşük tutmak
- İç çarpım davranışını bozmayı mümkün olduğunca azaltmak
Bu ikinci kısım özellikle önemli. Çünkü LLM tarafında KV cache sıkıştırma yaptığında tek derdin rekonstrüksiyon hatası değil. Gerçek hayatta attention skorları bozulursa, kağıt üstünde düşük hata veren niceleme bile aşağı akış görevlerinde can yakabiliyor.
TurboQuant burada bence oldukça akıllı bir ayrım yapıyor. Önce ana sinyali iyi sıkıştırıyor, sonra inner-product tarafındaki sistematik sapmayı ayrıca düzeltmeye çalışıyor. Yani “tek formül her şeyi çözsün” diye zorlamıyor.
Neden şimdi bu kadar önemli?
Çünkü iki büyük darboğaz giderek daha görünür hale geliyor:
1. KV cache maliyeti
Uzun bağlamlı LLM inference tarafında KV cache ciddi bir bellek tüketiyor. Bağlam uzadıkça key ve value tensörleri büyüyor, bu da hem maliyeti hem de bellek trafiğini yukarı çekiyor. Teoride daha uzun context sunmak kolay görünüyor ama pratikte sistemin duvara tosladığı yerlerden biri tam olarak burası.
2. Vector search tarafındaki ölçek problemi
Embedding tabanlı arama sistemlerinde de benzer bir durum var. Daha fazla vektör, daha büyük indeks, daha pahalı arama ve daha yüksek operasyonel maliyet demek. Vektör veritabanı tarafında sadece recall iyi olsun yetmiyor; indeksleme süresi ve bellek ayak izi de ciddi şekilde önem taşıyor.
TurboQuant’ın güçlü tarafı, bu iki problemi aynı matematik omurgası etrafında ele alması.
TurboQuant nasıl çalışıyor?
TurboQuant’ı anlamanın en kolay yolu, onu iki aşamalı bir sistem gibi düşünmek.
1. Rastgele rotasyon ile koordinatları düzenlemek
İlk adımda giriş vektörü rastgele bir ortogonal dönüşümden geçiriliyor. Bunun amacı veriyi “koordinat eksenlerine kötü dağılmış” halinden çıkarıp daha düzenli, daha homojen bir forma sokmak.
Ben bunu şöyle okuyorum: yüksek boyutlu zor bir problemi, daha yönetilebilir tek-boyutlu alt problemlere bölmek.
Bu dönüşümden sonra koordinatlar daha düzenli dağıldığı için her koordinata benzer mantıkla scalar quantization uygulamak anlamlı hale geliyor.
2. Scalar quantization ile ana sinyali taşımak
İkinci adımda her koordinat için önceden tasarlanmış bir scalar quantizer kullanılıyor. Burada amaç, vektörün asıl bilgisini düşük bit ile mümkün olduğunca iyi yakalamak.
Bu kısmın pratik değeri büyük:
- Veri-bağımlı eğitim gerekmiyor.
- Codebook tarafı hafifliyor.
- Online kullanım senaryoları için daha uygun hale geliyor.
- GPU/TPU tarafında paralelleştirme daha mantıklı bir zemine oturuyor.
3. Residual + QJL ile inner-product bias düzeltmek
TurboQuant’ın bence en kritik tarafı burada başlıyor.
Sadece MSE düşük diye iç çarpım tarafı düzgün kalmıyor. Özellikle attention skorlarında önemli olan şey, sorgu ile anahtar arasındaki iç çarpımın davranışı. TurboQuant bu nedenle ilk aşamadaki nicelemeden kalan residual hatayı ayrı ele alıyor ve bu artık hata üzerinde 1 bitlik Quantized Johnson-Lindenstrauss benzeri bir düzeltme kullanıyor.
Benim gözümde bu tasarımın değeri şu: Ana sıkıştırma ile geometri düzeltmesini aynı kaba doldurmaya çalışmıyor. Birinci aşama “ana sinyali taşı”, ikinci aşama “geometrik sapmayı düzelt” gibi çalışıyor.
TurboQuant neden klasik quantization yöntemlerinden farklı?
Bence üç nedenle ayrışıyor.
Veri-oblivious yaklaşım
Birçok pratik quantization yöntemi veri kümesine özel öğrenilmiş yapı, normalization overhead’i veya ekstra metadata ihtiyacı doğuruyor. TurboQuant ise bu bağımlılığı azaltmaya çalışıyor. Bu, özellikle online ve üretim odaklı sistemlerde büyük avantaj.
Teori ile mühendisliğin aynı sayfada olması
Piyasada çok sayıda “iyi çalışan quantization trick’i” var. Ama bunların önemli kısmı neden iyi çalıştığını rate-distortion perspektifinden bu kadar net açıklayamıyor. TurboQuant’ın asıl farkı, Shannon tabanlı alt sınırlarla ilişki kurması ve sadece benchmark kazanan bir fikir gibi kalmaması.
Inner-product meselesini ciddiye alması
Bence en kritik fark bu. Çoğu yaklaşım MSE üzerinden konuşurken TurboQuant doğrudan “inner-product tarafı ayrı bir problem” diyor. LLM attention ve retrieval gibi senaryolarda bu ayrım boş bir teorik detay değil; doğrudan ürün kalitesine dokunan nokta.
TurboQuant hangi kullanım alanlarında öne çıkıyor?
KV cache sıkıştırma
LLM inference tarafında TurboQuant’ın en doğal kullanım alanı KV cache. Özellikle uzun bağlamlı görevlerde bellek tüketimini aşağı çekmek için çok güçlü bir aday.
Resmi kaynaklardaki sonuçlar, TurboQuant’ın KV cache quantization için 3.5 bit seviyesinde kalite nötrlüğüne çok yakın bir sonuç verdiğini; 2.5 bit seviyesinde ise daha agresif sıkıştırmaya rağmen sınırlı kalite kaybıyla çalışabildiğini gösteriyor. Google Research blogunda da TurboQuant’ın, belirli uzun bağlam benchmark’larında en az 6x KV bellek azaltımıyla downstream kaliteyi koruyabildiği ve 4-bit kurulumda attention logit hesaplamasında H100 üzerinde 32-bit anahtarlara karşı 8 kata kadar performans artışı gösterebildiği aktarılıyor.
Benim yorumum şu: Kağıt üstündeki bu tablo gerçekten güçlü. Ama üretimde asıl farkı belirleyecek şey, sadece bit sayısı değil; encode/decode yolu, bit-packing, kernel tasarımı ve attention hesaplama stratejisi olacak.
Vector search
TurboQuant’ın ikinci büyük sahası vector search. Özellikle yüksek boyutlu embedding indekslerinde hem recall hem de indeksleme süresi kritik.
Paper tarafındaki sonuçlar, TurboQuant’ın product quantization tabanlı yöntemlere karşı recall tarafında güçlü kaldığını ve indeksleme maliyetini ciddi ölçüde aşağı çekebildiğini söylüyor. Ben bu kısmı özellikle önemli buluyorum çünkü burada sadece model içi bir optimizasyon yok; doğrudan retrieval altyapısı, semantic search ve vector database operasyonları için de anlamlı bir kapı açılıyor.
TurboQuant’ın bence en güçlü tarafı ne?
Benim için cevap net: araştırma iddiası ile sistem ihtiyacının çok iyi örtüşmesi.
Çünkü günün sonunda bugün herkes benzer bir problemle boğuşuyor:
- Daha uzun context istiyoruz
- Daha düşük inference maliyeti istiyoruz
- Daha hızlı vector search istiyoruz
- Ama kaliteyi çökertmek istemiyoruz
TurboQuant tam da bu dörtlünün ortasına oturuyor. O yüzden bu işi sadece akademik bir quantization makalesi gibi okumuyorum. Doğru uygulandığında bu yaklaşım, inference optimization katmanı ya da vector database acceleration modülü haline gelebilecek kadar ürünleşme potansiyeli taşıyor.
Peki TurboQuant kusursuz mu?
Hayır. Ve bence burada fazla romantik olmamak gerekiyor.
1. Teori güçlü diye üretim kolay olmuyor
Kağıttaki kalite ile gerçek hız kazancı arasında kernel mühendisliği diye çok ciddi bir köprü var. Bu köprü zayıfsa, bellek kazancı throughput kazancına dönmeyebilir.
2. Rastgele rotasyonun sistem maliyeti var
Teoride çok temiz duran bazı dönüşümler, pratikte pahalı olabilir. Bu nedenle hızlı ortogonal dönüşümler, yaklaşık Hadamard benzeri uygulamalar ve donanım dostu tasarımlar burada belirleyici olacak.
3. Her modelde aynı davranışı beklemek doğru değil
Bir benchmark setinde çok iyi görünen yöntem, her mimaride ve her görev türünde aynı sonucu vermeyebilir. Özellikle çok agresif bit rejimlerinde bazı katmanlar veya bazı head’ler daha hassas davranabilir.
4. Outlier politikası işin kalbinde
Ben TurboQuant’ı düz “3 bit quantization” etiketiyle okumayı eksik buluyorum. Asıl gerçekçi yaklaşım, outlier-aware karma bit bütçesi kullanmak. Yani bazı kanal veya head’lere daha yüksek bit verip geri kalanı daha düşük bitle taşımak.
Bu bence doğrudan üretim mantığına daha yakın.
Ben olsam TurboQuant üzerine nasıl çalışırdım?
Ben bu işi beş aşamada ele alırdım.
Faz 1: Referans implementasyon
İlk hedef hızlı olmak değil, doğru olmak olurdu.
- NumPy veya PyTorch ile referans kod
- Scalar quantizer tabloları
- MSE-only ve inner-product corrected modlar
- Monte Carlo ile bias ve variance doğrulaması
- Distortion eğrilerinin yeniden üretimi
Burada geçmeden sonraki faza atlamazdım.
Faz 2: KV cache simülasyonu
Gerçek modele dokunmadan önce yapay K/V tensörleriyle simülasyon kurmak çok daha mantıklı. Çünkü burada encode/decode yolu, bit-packing, latency ve karışık bit düzenleri daha güvenli test edilebilir.
Faz 3: Minimal model entegrasyonu
Tek model, tek backend, minimum karmaşıklık. Mesela önce sadece key tarafını niceleyip value tarafını float bırakmak bile debug açısından çok şey kazandırır.
Faz 4: Kernel optimizasyonu
İşin en sert kısmı burası.
- Fused dequant + attention
- Memory coalescing
- Shared memory baskısı
- Register kullanımı
- Warp verimliliği
- Bit-packed okuma stratejileri
Kağıttaki avantajın gerçek throughput’a dönmesi burada belli olur.
Faz 5: Ürünleştirme
Son aşamada fallback mekanizması, telemetry, A/B test, kalite drift takibi ve katman bazlı bit politikası gibi konular devreye girer. Benim için üretime hazır olmanın tanımı, sadece benchmark sonucu değil; operasyonel güvenilirliktir.
TurboQuant hakkında benim net hükmüm
Ben TurboQuant’ı fazla güçlü buluyorum.
Bunu söylerken kastım “yarın herkes production’a alsın” değil. Kastım şu: Bu yaklaşım, quantization tarafında uzun süredir aranan dengeye gerçekten yaklaşan nadir işlerden biri gibi duruyor. Yani hem teori var, hem net problem tanımı var, hem de doğrudan ürün dünyasında karşılığı olan kullanım alanları var.
Özellikle şu iki sebepten dolayı önemli buluyorum:
- Quantization’ı sadece hafıza düşürme hilesi gibi ele almıyor.
- Inner-product doğruluğunu ayrı ve ciddi bir mühendislik problemi olarak görüyor.
Bana göre TurboQuant’ın geleceği tek bir cümlede özetlenebilir: Bu iş bir paper olarak ilginç olmanın ötesinde, doğru ekipte gerçek bir altyapı bileşenine dönüşebilir.
Sonuç
TurboQuant, Google Research’ün son dönemde duyurduğu en dikkat çekici verimlilik çalışmalarından biri. Vektör nicelemeyi sadece daha küçük temsil üretme problemi olarak değil, geometriyi koruma problemi olarak ele alması bence onu ayrı bir yere koyuyor.
KV cache sıkıştırma, vector search, retrieval altyapısı ve uzun bağlamlı inference dünyasında ciddi baskılar varken; online, data-oblivious ve teorik olarak güçlü bir yaklaşımın bu kadar erken aşamada bu kadar iyi görünmesi önemli.
Benim kişisel görüşüm net: TurboQuant üzerine ciddi şekilde çalışılır. Hatta doğru uygulanırsa bunun etrafından bağımsız bir inference optimization katmanı, açık kaynak bir quantization kütüphanesi ya da doğrudan vector database hızlandırma modülü bile çıkabilir.
Ama yine aynı noktaya geliyorum: Bu işin kaderini matematik kadar sistem tasarımı belirleyecek. O yüzden TurboQuant’ı anlamanın doğru yolu, ona sadece bir paper gibi değil; yarın üretim ortamına taşınabilecek bir mühendislik adayı gibi bakmak.
Kısa cevap: TurboQuant neden önemli?
Çünkü daha az bellek kullanıp, daha hızlı çalışıp, kaliteyi daha iyi koruyan sistemler kurmak istiyorsak; quantization tarafında “yaklaşık iyi” çözümlerden “kuramsal olarak sağlam ve pratikte uygulanabilir” çözümlere geçmek zorundayız.
TurboQuant tam olarak bu geçişin adaylarından biri.
Kaynaklar
- Google Research Blog — TurboQuant: Redefining AI efficiency with extreme compression
- Amir Zandieh, Majid Daliri, Majid Hadian, Vahab Mirrokni — TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate (arXiv:2504.19874)