Google TurboQuant: 31GB'lık Yapay Zeka Belleği Neden 4GB'a İndi?

31GB'dan 4GB'a. Haziran 2026'da Micron hisselerinden birkaç puan düşüren ve geliştirici Twitter'ını RAG faturalarının çöküp çökmeyeceği paniğine sürükleyen de bu rakam oldu. Altındaki matematik gerçek: Google'ın TurboQuant algoritması (arXiv 2504.19874, ICLR 2026'ya kabul edildi) bir LLM'nin belleğini yaklaşık 6x sıkıştırarak değer başına ~3 bite indiriyor, doğruluk kaybı ise neredeyse sıfır. Ama pek çok kaynak bir şeyi yanlış aktardı ve bu hata, tüm hikayeyi farklı bir ışıkta okumanızı gerektiriyor.

Google TurboQuant yapay zeka bellek sıkıştırma haberi aslında aynı kapüşonu giyen iki ayrı hikaye. Önce bunları birbirinden ayıralım.

Temel Çıkarımlar

• TurboQuant, Google'ın eğitim gerektirmeyen sıkıştırma algoritması: KV önbelleğini ~6x azaltarak ~3 bit'e indiriyor, doğruluk kaybı neredeyse sıfır (ICLR 2026).
• TurboVec, TurboQuant'ı uygulayan ayrı bir üçüncü taraf Rust kütüphanesi. Google TurboVec'i yayımlamamıştır.
• Viral olan "31GB → 4GB, FAISS'i geride bırakıyor" sonucu TurboVec'e ait, ham TurboQuant'a değil.
• Gerçek geliştirici kazanımı, daha ucuz uzun bağlamlı çıkarım ve daha küçük RAG indeksleri; ancak Google'ın resmi çıktısı bir ürün değil, bir makaledir.

Google'ın TurboQuant'ı Sade Bir Dille Açıklarsak

TurboQuant, Google Research'ün eğitim gerektirmeyen, veriden bağımsız vektör kuantizasyon algoritması. Bir LLM'nin KV önbelleğini yaklaşık 6x sıkıştırarak değer başına ~3 bite indiriyor; doğruluk kaybı ise neredeyse sıfır. Algoritma arXiv 2504.19874'te yayımlanmış ve ICLR 2026'ya kabul edilmiş. "Eğitim gerektirmeyen" ifadesi şu anlama geliyor: ince ayar yapmaksızın mevcut modeller üzerinde doğrudan çalışıyor.

Peki aslında ne sıkıştırılıyor? İki temel şey var.

Birincisi, KV önbelleği. Model konuşmanızı okurken bugüne kadarki her şeyi özetleyen, anahtar-değer önbelleği adı verilen bir yapı oluşturuyor. Bunu modelin kısa süreli belleği gibi düşünebilirsiniz. Bağlam pencereniz ne kadar uzunsa model o kadar çok şeyi hafızasında tutuyor ve o kadar fazla GPU RAM'i tüketiyor. 128 bin tokenlik bir sohbet KV önbelleğini birkaç gigabayta şişirebiliyor. İşte bu yüzden uzun bağlamlı servisler hızla pahalılaşıyor ve LLM prompt önbelleğinin API maliyetlerini düşürmesi bir ihtiyaç haline geldi.

İkincisi, vektör indeksleri. Anlamsal arama ve RAG'ı besleyen embedding'ler büyük kayan noktalı sayı dizileri. Bunları tam hassasiyette milyonlarca saklarsanız onlarca gigabayt RAM ile karşı karşıya kalırsınız.

TurboQuant her ikisini de sıkıştırıyor. İşin ilginç yanı şu: bunu yapmak için verilerinizden hiçbirine ihtiyaç duymuyor. Çoğu kuantizasyon şeması önce verilerinizden bir örnek inceliyor, ardından onlara özel bir kod kitabı oluşturuyor. TurboQuant bu adımı atlıyor. Veriden bağımsız, yani dağılımınıza hiç bakmadan hedef sıkıştırma oranına ulaşıyor.

TurboQuant'ın asıl sırrı sıkıştırma oranı değil. Bunu sıfır eğitim verisiyle başarması.

İşte gerçek kazanım bu. Halihazırda çalıştırdığınız bir modeli işaret edip tasarrufları anında elde edebilirsiniz.

TurboQuant ile TurboVec: Herkesin Yanlış Anladığı Karışıklık

TurboQuant, Google'ın sıkıştırma algoritması (arXiv 2504.19874, ICLR 2026). TurboVec ise vektör araması için TurboQuant'ı uygulayan ayrı bir üçüncü taraf Rust ve Python kütüphanesi (RyanCodrai/turbovec). Google TurboVec'i yayımlamamıştır. Viral olan "31GB → 4GB, FAISS'i geride bırakıyor" sonucu TurboVec'e ait, ham TurboQuant'a değil. Bu yazıdan tek bir şey aklınızda kalsın, bu olsun.

İşlerin nasıl karıştığı şöyle özetlenebilir. Haziran 2026 başında 31GB→4GB kıyaslaması viral olduğunda bazı yayın organları (Tech Startups dahil) manşetlerinde Google'ın "TurboVec'i yayımladığını" yazdı. Olan bu değildi. Kaynağı kontrol edin: TurboVec, GitHub ve PyPI'da RyanCodrai/turbovec adresinde duruyor. Ryan Codrai adlı bir geliştirici tarafından oluşturulmuş açık kaynak bir kütüphane. MarkTechPost çerçeveyi doğru kurdu: "Google'ın TurboQuant algoritması üzerine inşa edilmiş Python bağlamalı Rust vektör indeksi."

İlişki basit: Google matematiği yayımladı, topluluk onunla araçlar geliştirdi. TurboVec bu araçların en görünür olanı.

Google algoritmayı geliştirdi. Herkesin ekran görüntüsünü aldığı kütüphaneyi ise Ryan Codrai adlı bir geliştirici inşa etti. Bunlar aynı şey değil.

TurboQuant tabanlı bir indeksin mevcut kurulumunuzla nasıl bir arada duracağını değerlendiriyorsanız 2026'nın en iyi vektör veritabanları karşılaştırmamız FAISS, Qdrant ve yeni sıkıştırılmış indeksleri yan yana inceliyor.

TurboQuant Belleği Doğruluğu Bozmadan Nasıl Sıkıştırıyor?

TurboQuant, rastgele döndürme artı kutupsal koordinat kuantizasyon şeması (PolarQuant) ve Johnson-Lindenstrauss tarzı bir projeksiyon (QJL, Quantized Johnson-Lindenstrauss) kullanarak değerleri kuantizasyon öncesi eşit biçimde dağıtıyor. Bu neredeyse optimum bozulma, model yeniden eğitimi gerektirmeksizin değer başına ~3 bite inilirken doğruluğun büyük ölçüde korunmasını sağlıyor.

Jargon biraz soyut görünse de arkasındaki fikir oldukça sezgisel.

Kuantizasyon yaparken sayıları daha az bit'e yuvarlıyorsunuz. Tehlike şu: bir vektörün bazı boyutları diğerlerine kıyasla çok daha fazla ağırlık taşıyor, dolayısıyla onları gelişigüzel yuvarlamak sonucu bozabiliyor. TurboQuant'ın çözümü vektörü önce rastgele döndürmek. Dağıtmadan önce bir desteni eşit biçimde karıştırdığınızı hayal edin; böylece hiçbir el tek taraflı çıkmıyor. Döndürme sonrasında değerler yayılıyor, tek bir boyut baskın olamıyor ve yuvarlama çok daha az hasar veriyor.

QJL kısmı bu: mesafeleri korurken her şeyi karıştıran rastgele bir projeksiyon. PolarQuant (AISTATS 2026'da sunuldu) ise döndürülmüş değerleri kutupsal koordinatlarda kuantize ediyor; bu yöntem düz ızgara yuvarlamasından daha iyi uyum sağlıyor.

Getiri, makalenin neredeyse optimum bozulma dediği şey: belirli bir bit bütçesinde kayıp açısından teorik Shannon sınırına yaklaşılıyor. Pratik söylemle: 3 bit per değer için bundan iyisini yapmak çok güç ve TurboQuant bunu verilerinize bakmadan başarıyor.

Mekanizmanın tamamı için Google Research blogu ve arXiv makalesi birincil kaynak. InfoQ'da KV önbelleği açısından geliştiriciye yönelik sade bir analiz de var.

31GB → 4GB RAM Faturanız İçin Ne Anlama Geliyor?

Tam hassasiyette ~31GB RAM gerektiren 10 milyon vektörlük bir RAG indeksi, TurboVec'in TurboQuant tabanlı sıkıştırmasıyla yaklaşık ~4GB'a iniyor; bu, pahalı bellek optimize edilmiş bir sunucu yerine sıradan bir instance kullanmanızı sağlıyor. KV önbelleği için ~6x azalma, aynı GPU'da yaklaşık 6x daha fazla eşzamanlı uzun bağlamlı oturum anlamına geliyor. Faturada gerçekten görünen fark bu.

Dürüst bir uyarı: aşağıdaki her şey, halka açık bulut fiyatlandırması ve makalenin açıkladığı oranlardan modellenmiş tahmini rakamlar (Haziran 2026). TurboVec'i canlı ortamda çalıştırmadık; bu nedenle bunları fiilen ölçtüğümüz kıyaslamalar değil, matematiksel projeksiyonlar olarak okuyun. Fiyatlandırma katmanları LLM API maliyetlerini düşürme rehberimizde kullandığımız temel ile örtüşüyor.

10 milyon belgeli bir embedding indeksi: tam hassasiyet ile TurboVec sıkıştırmalı karşılaştırma:

Bellek optimize edilmiş bir sunucudan küçük genel amaçlı birine geçiş, tüm hikayenin özeti. Kendi sunucunuzda barındırılan bir indeks için bu, gözünüzü kırpan bir fatura ile neredeyse fark etmediğiniz bir fatura arasındaki fark. Bunun üzerine bir pipeline kuruyorsanız RAG uygulaması geliştirme rehberimiz bu indeksin nereye oturduğunu açıklıyor.

KV önbelleği tarafına bakalım; 128 bin bağlamlı oturumlar sunan 24GB GPU modellemesi:

6x KV önbellek azalması yalnızca RAM tasarrufu değil. Tek bir GPU'yu uzun bağlamlı servis için altıya dönüştürebilir.

Bu yüzden konu uzun bağlamlı iş yükleri için her şeyden daha önemli. Kısa sohbetler sunuyorsanız KV önbelleği zaten darboğaz değildi. 128 bin token'lık ajan ya da belge analizi çalıştırıyorsanız 6x azalma GPU başına ekonomiyi bir gecede değiştiriyor. VentureBeat'in haberi üst sınır verim artışını H100 üzerinde %50'nin üzerinde maliyet tasarrufu ile 8x'e kadar koyuyor; bu da modellenmiş eşzamanlılık hesabımızla örtüşüyor.

Bellek Chip Hisseleri Neden Düştü ve Wall Street Aşırı Tepki Verdi mi?

TurboQuant'ın duyurulmasının ardından Micron, Western Digital ve Seagate hisseleri, ucuzlayan yapay zeka belleğinin gelecekteki DRAM ve HBM talebini daraltacağı korkusuyla geriledi; bu "DeepSeek anı" çerçevesi olarak adlandırıldı. Wells Fargo dahil analistler tam tersini savundu: daha ucuz bellek toplam kullanımı artırır, azaltmaz; Jevons paradoksu.

Anlatı kendiliğinden yazıldı. Yapay zeka şu anda yüksek bant genişlikli belleğin en büyük alıcısı, dolayısıyla bir Google algoritması bellek ihtiyacını 6x azaltırsa talep düşer ve chip üreticileri zarara uğrar mantığı işledi. TechCrunch "Pied Piper" benzetmesine başvurdu; dünyanın verilerini sıkıştırmayı vaat eden HBO'nun Silicon Valley dizisindeki kurgusal startup. Hisseler bu korku üzerine geriledi.

İşte haber döngüsünün büyük ölçüde atladığı daha sakin değerlendirme. Wells Fargo Jevons paradoksuna dikkat çekti: bir şey ucuzlayıp verimli hale geldiğinde bunu genellikle daha az değil daha çok tüketiyoruz. Daha ucuz yapay zeka belleği, daha fazla uygulamanın uzun bağlamlı özellikler sunması, daha fazla ekibin daha büyük RAG indekslerini kendi sunucusunda barındırması ve genel olarak daha fazla çıkarım gerçekleşmesi anlamına geliyor. Verimlilik kazanımlarının tarihsel olarak toplam talebi öldürmek yerine büyüttüğü biliniyor.

Piyasa TurboQuant'ı bir talep katili olarak fiyatladı. Tarih ise daha ucuz hesaplama kapasitesini genellikle çok daha fazla kullandığımızı söylüyor.

Peki düşüş abartıldı mı? Kısa vadede muhtemelen evet. Bir araştırma makalesi sektörü bir anda dönüştürmez. Piyasa bir manşete tepki verdi; gerçek dağıtım çeyrekler alacak ve talep artışı etkisi tasarrufları bastırabilir.

TurboQuant'ı Bugün Gerçekten Kullanabilir misiniz?

Kısmen evet. TurboQuant'ın Google tarafından resmi çıktısı makale ve algoritmadır, hazır bir ürün değil. Ama topluluk uygulamaları zaten var: vektör indeksleri için PyPI'da TurboVec (RyanCodrai/turbovec) ve llama.cpp için AmesianX/TurboQuant (yaklaşık 5,2x, DeepSeek-V2/V3 ve MLA üzerinden GLM-4.7-Flash desteğiyle). Ekosistem genç ama kullanılabilir durumda.

Vektör indeksi tarafını denemek istiyorsanız TurboVec bir pip komutu uzakta:

pip install turbovec
# Rust + Python bağlamaları, Google'ın TurboQuant'ını vektör araması için uygular
# llama.cpp KV önbelleği uygulaması (DeepSeek/MLA): github.com/AmesianX/TurboQuant
# Python referans uygulaması: github.com/yashkc2025/turboquant

Yerel modellerde KV önbelleği tarafı için AmesianX/TurboQuant llama.cpp uygulaması takip edilmeye değer, özellikle çok başlı gizli dikkat (MLA) kullanan DeepSeek veya GLM modelleri çalıştırıyorsanız. Daha küçük bir KV önbelleği aynı kartta daha uzun bağlam çalıştırmanızı sağladığından yerel LLM kurulum rehberiyle iyi bir uyum sağlıyor. Hangi açık kaynak modelde kullanacağınıza karar veriyorsanız en iyi açık kaynak LLM kıyaslamalarımız DeepSeek ve GLM ailelerini doğrudan ele alıyor.

Dürüst bir not: bu aşama araştırma-ilk, ekosistem-olgunlaşıyor. Google'ın resmi çıktısı araştırma, SLA'lı destekli bir ürün değil.

Dürüst yanıt: TurboQuant hazır bir matematik, henüz bir indirme düğmesi değil.

TurboQuant Abartı mı, Gerçek mi? Dürüst Bir Değerlendirme

TurboQuant gerçek ve gerçekten yaratıcı. Eğitim gerektirmeyen tasarımı asıl kilit nokta ve KV önbelleği kazanımı uzun bağlamlı iş yükleri için en çok orada önem taşıyor. Ama bu bir sihir değil: birçok kuantizasyon ilerlemesinden biri, viral olan 31GB→4GB başlığı TurboVec'e ait ve hisse senedi paniği bir araştırma sonucunu fazla yorumladı.

İstemciler için çıkarım ve RAM maliyeti ayarlarken bir tekniğin benimsemeye değer olup olmadığına karar veren şey sürtünmedir. Eğitim gerektirmemek burada büyük avantaj sağlıyor; ince ayar döngüsü yok, kod kitabı bakımı yok, model cerrahisi yok. Halihazırda çalıştırdığınız bir şeye vidaya takabilirsiniz.

Ne değiştirir:

• Belleğin gerçekten pahalıya patladığı uzun bağlamlı çıkarımı ucuzlatır.
• Daha ucuz donanıma sığan, kendi sunucunuzda barındırılan daha küçük RAG indeksleri.
• Hiçbir şeyi yeniden eğitmeden benimseyebileceğiniz bir sıkıştırma seçeneği.

Ne değiştirmez:

• Kısa bağlamlı, küçük model iş yükleri için fazla bir faydası yok; KV önbelleği zaten darboğaz değildi.
• Mevcut kuantizasyonunuzu bir gecede geçersiz kılmıyor; ekleme, değil ikame.
• Google'ın resmi çıktısı hâlâ bir makale; production seviyesi araçlar şimdilik topluluğa bağlı.

Kendi çıkarımınız veya RAM faturanız için bunun ne anlama geldiğini çözmeye çalışıyorsanız Techsy olarak tam da bu tür maliyet modellemesini müşterilerimiz için yapıyoruz. İkinci bir göz isterseniz ücretsiz danışmanlık alın.

Sıkça Sorulan Sorular

Google TurboQuant Nedir?

TurboQuant, Google Research'ün eğitim gerektirmeyen vektör kuantizasyon algoritması; arXiv 2504.19874'te yayımlanmış ve ICLR 2026'ya kabul edilmiştir. Bir LLM'nin KV önbelleğini yaklaşık 6x sıkıştırarak değer başına ~3 bite indiriyor, doğruluk kaybı ise neredeyse sıfır. Veriden bağımsız olduğundan ince ayar veya yeniden eğitim gerektirmeksizin mevcut modeller üzerinde çalışıyor.

Google TurboVec'i Gerçekten Yayımladı mı?

Hayır. TurboQuant Google'ın algoritması; TurboVec ise bağımsız bir geliştirici tarafından TurboQuant üzerine inşa edilmiş ayrı bir üçüncü taraf Rust ve Python kütüphanesi (RyanCodrai/turbovec). Viral 31GB→4GB kıyaslaması gündem olduğunda bazı yayın organları Google'ın TurboVec'i yayımladığını hatalı biçimde yazdı; ancak GitHub bunun bir topluluk projesi olduğunu açıkça gösteriyor.

TurboQuant ile TurboVec Aynı Şey mi?

Hayır. TurboQuant, Google'ın yayımladığı sıkıştırma algoritması. TurboVec, bu algoritmayı vektör araması için uygulayan kütüphanelerden biri. Biri matematik, diğeri bu matematikle inşa edilmiş bir araç. Ünlü "31GB → 4GB, FAISS'i geride bırakıyor" sonucu TurboVec'e ait; Google'ın doğrudan çıkardığı bir şey değil.

TurboQuant Doğruluk Kaybına Yol Açıyor mu?

Makalenin öne sürdüğü iddia, değer başına ~3 bit bile olsa neredeyse sıfır doğruluk kaybı. Algoritma, kuantizasyon öncesi vektörleri rastgele döndürerek hiçbir boyutun baskın olmamasını sağlıyor; böylece neredeyse optimum bozulma (Shannon sınırına yakın) elde ediliyor. Uygulamada bu, çoğu iş yükü için göz ardı edilebilecek kadar küçük bir kalite düşüşü anlamına geliyor.

TurboQuant Ne Kadar RAM Tasarrufu Sağlar?

KV önbelleğinde yaklaşık 6x, değer başına ~3 bite düşürüyor. Vektör indeksi tarafında TurboVec, 10 milyon belgeli bir indeksi 31GB'dan ~4GB'a, yani %92'ye varan bellek tasarrufu ile gösterdi. Gerçek tasarruf hassasiyet başlangıç noktanıza ve KV önbelleği, embedding veya her ikisini sıkıştırıp sıkıştırmadığınıza bağlı.

Bu Sadece Abartı mı, Bellek Hisseleri Neden Düştü?

Gerçek bir ilerleme; ancak panik bir araştırma sonucunu fazla yorumladı. Micron, Western Digital ve Seagate, daha ucuz yapay zeka belleğinin chip talebini düşüreceği korkusuyla geriledi. Wells Fargo Jevons paradoksuyla karşı argüman sundu: daha ucuz ve verimli bellek genellikle toplam kullanımı artırır. Dahası bir makale sektörü anında dönüştürmez; kısa vadeli tepki abartılı görünüyor.

TurboQuant'ı Bugün Kullanabilir miyim?

Kısmen. Google'ın resmi çıktısı makale ve algoritmadır, ürün değil. Topluluk uygulamaları şu an mevcut: vektör indeksleri için PyPI'da TurboVec, llama.cpp için AmesianX/TurboQuant (DeepSeek-V2/V3 ve MLA üzerinden GLM-4.7-Flash, yaklaşık 5,2x) ve Python referans uygulaması yashkc2025/turboquant. Ekosistem genç ama zaten kullanılabilir.

TurboQuant Kullandığım Kuantizasyondan Farkı Ne?

Çoğu kuantizasyon, ayarlanmış bir kod kitabı oluşturmak için verilerinizden bir örnek inceler. TurboQuant eğitim gerektirmeyen ve veriden bağımsız; dağılımınıza bakmadan hedef orana ulaşıyor. Aynı zamanda model ağırlıklarını sıkıştırmak yerine KV önbelleği ve vektör indekslerini hedef alıyor; neredeyse optimum bozulma ile.

TurboQuant DeepSeek veya llama.cpp ile Çalışıyor mu?

Evet, AmesianX/TurboQuant llama.cpp uygulaması üzerinden. Yaklaşık 5,2x sıkıştırma bildiriyor ve çok başlı gizli dikkat (MLA) aracılığıyla DeepSeek-V2/V3 ile GLM-4.7-Flash'ı destekliyor. Bu modelleri kendi sunucunuzda çalıştırıyorsanız ve aynı donanımda daha uzun bağlam için daha küçük bir KV önbelleği istiyorsanız pratik bir seçenek.

TurboQuant En Çok Ne Zaman İşe Yarıyor?

En çok uzun bağlamlı çıkarım ve büyük kendi sunucusunda barındırılan RAG indekslerinde, yani belleğin gerçek darboğaz olduğu yerlerde işe yarıyor. 6x KV önbellek azalması, GPU başına daha fazla eşzamanlı 128 bin tokenlik oturum ve sıkıştırılmış embedding indeksi daha ucuz instance'lara sığma anlamına geliyor. Kısa bağlamlı sohbetler ve küçük modeller için en az etkili; orada KV önbelleği zaten maliyet etkeni değildi.