
TurboQuant Google Baru Saja Menyusutkan Indeks AI 31GB Jadi 4GB — Ini Arti Sebenarnya
31GB jadi 4GB. Angka itulah yang memangkas beberapa persen saham Micron pada Juni 2026, dan yang membuat separuh dev Twitter panik soal apakah tagihan RAG mereka baru saja runtuh. Hitungan di baliknya memang nyata: TurboQuant Google (arXiv 2504.19874, diterima di ICLR 2026) mengompresi memori LLM sekitar 6x hingga sekitar 3 bit per nilai dengan kehilangan akurasi nyaris nol. Tapi sebagian besar artikel salah di satu hal, dan itu mengubah cara Anda membaca keseluruhan ceritanya.
Kisah kompresi memori AI Google TurboQuant sebenarnya adalah dua cerita yang memakai hoodie yang sama. Mari kita urai.
Poin-Poin Utama
- TurboQuant adalah algoritma kompresi tanpa pelatihan milik Google: pengurangan KV-cache ~6x hingga ~3 bit, kehilangan akurasi nyaris nol (ICLR 2026).
- TurboVec adalah library Rust pihak ketiga terpisah yang mengimplementasikan TurboQuant. Google tidak merilisnya.
- Demo viral "31GB → 4GB, mengalahkan FAISS" itu milik TurboVec, bukan TurboQuant mentah.
- Keuntungan nyata bagi developer adalah inferensi konteks panjang yang lebih murah dan indeks RAG yang lebih kecil, tapi rilis resmi Google adalah paper, bukan produk.
Apa Itu TurboQuant Google, dalam Bahasa Sederhana?
TurboQuant adalah algoritma kuantisasi vektor tanpa pelatihan dan data-oblivious dari Google Research. Algoritma ini mengompresi KV cache LLM sekitar 6x, hingga sekitar 3 bit per nilai, dengan kehilangan akurasi nyaris nol. Dipublikasikan di arXiv 2504.19874 dan diterima di ICLR 2026. "Tanpa pelatihan" artinya algoritma ini bekerja langsung pada model yang sudah ada, tanpa perlu fine-tuning.
Jadi apa yang sebenarnya dikompresi? Terutama dua hal.
Pertama, KV cache. Saat model membaca percakapan Anda, ia menyimpan ringkasan berjalan dari semua yang sudah terjadi, yang disebut key-value cache. Anggap saja sebagai memori jangka pendek model. Semakin panjang context window Anda, semakin banyak memori ini yang ditahan, dan semakin banyak GPU RAM yang dimakan. Chat 128k token bisa membuat KV cache membengkak hingga beberapa gigabyte. Itulah kenapa serving konteks panjang cepat jadi mahal, dan kenapa prompt caching untuk memangkas biaya API jadi tren sejak awal.
Kedua, indeks vektor. Embedding yang menggerakkan pencarian semantik dan RAG adalah array besar berisi angka floating-point. Simpan jutaan embedding pada presisi penuh dan Anda akan membutuhkan puluhan gigabyte RAM.
TurboQuant menyusutkan keduanya. Ini bagian kerennya: algoritma ini tidak butuh data Anda sama sekali untuk melakukannya. Kebanyakan skema kuantisasi mempelajari sampel vektor Anda dulu, lalu membangun codebook yang disetel untuknya. TurboQuant melewatkan itu. Algoritma ini data-oblivious, artinya mencapai rasio kompresi tanpa pernah melihat distribusi data Anda.
Trik sesungguhnya dari TurboQuant bukan rasio kompresinya. Melainkan fakta bahwa ia butuh nol data pelatihan untuk mencapainya.
Itulah terobosan yang sesungguhnya. Anda bisa mengarahkannya ke model yang sudah Anda jalankan dan langsung mendapat penghematannya.
TurboQuant vs TurboVec: Kebingungan yang Salah Dipahami Semua Orang
TurboQuant adalah algoritma kompresi Google (arXiv 2504.19874, ICLR 2026). TurboVec adalah library Rust dan Python pihak ketiga terpisah (RyanCodrai/turbovec) yang mengimplementasikan TurboQuant untuk pencarian vektor. Google tidak merilis TurboVec. Hasil viral "31GB → 4GB, mengalahkan FAISS" itu milik TurboVec, bukan TurboQuant mentah. Jika Anda hanya mengingat satu hal dari artikel ini, ingatlah itu.
Di sinilah semuanya jadi kacau. Ketika benchmark 31GB→4GB viral di awal Juni 2026, beberapa media (termasuk Tech Startups) memasang judul yang mengatakan Google telah "merilis TurboVec." Itu tidak terjadi. Cek sumbernya: TurboVec ada di RyanCodrai/turbovec di GitHub dan PyPI. Itu library open-source yang dibangun oleh developer bernama Ryan Codrai. MarkTechPost mendapat framing yang tepat, menggambarkannya sebagai "indeks vektor Rust dengan binding Python, dibangun di atas algoritma TurboQuant Google."
Jadi hubungannya sederhana: Google mempublikasikan matematikanya, dan komunitas membangun tools dengannya. TurboVec adalah yang paling terlihat di antara tools tersebut.

| TurboQuant | TurboVec | |
|---|---|---|
| Apa itu | Algoritma kompresi | Library indeks vektor (Rust + Python) |
| Siapa yang membangun | Google Research + DeepMind | Ryan Codrai (pihak ketiga) |
| Di mana | arXiv 2504.19874, ICLR 2026 | GitHub RyanCodrai/turbovec, PyPI |
| Angka utama | Pemotongan KV-cache ~6x hingga ~3 bit | 31GB jadi ~4GB untuk indeks 10 juta dokumen |
| Status | Paper riset + algoritma | Library open-source yang berfungsi |
Google membangun algoritmanya. Developer bernama Ryan Codrai membangun library yang di-screenshot semua orang. Keduanya bukan hal yang sama.
Jika Anda sedang menimbang di mana indeks berbasis TurboQuant cocok di samping setup Anda saat ini, rangkuman kami tentang database vektor terbaik di 2026 membandingkan FAISS, Qdrant, dan indeks terkompressi yang lebih baru secara berdampingan.
Bagaimana TurboQuant Mengompresi Memori Tanpa Merusak Akurasi?
TurboQuant menggunakan rotasi acak ditambah skema kuantisasi koordinat polar (PolarQuant) dan proyeksi bergaya Johnson-Lindenstrauss (QJL, Quantized Johnson-Lindenstrauss) untuk menyebarkan nilai secara merata sebelum mengkuantisasi. Distorsi nyaris optimal inilah yang memungkinkannya turun hingga sekitar 3 bit per nilai sambil menjaga akurasi nyaris utuh, tanpa perlu retraining model.
Biar saya jelaskan, karena jargon ini menyembunyikan ide yang cukup intuitif.
Saat Anda mengkuantisasi, Anda membulatkan angka ke bit yang lebih sedikit. Bahayanya adalah beberapa dimensi vektor membawa bobot jauh lebih besar dari yang lain, jadi membulatkannya secara serampangan akan merusak hasilnya. Solusi TurboQuant adalah merotasi vektor secara acak terlebih dahulu. Bayangkan mengocok kartu secara merata sebelum membagikan, sehingga tidak ada satu tangan pun yang timpang. Setelah rotasi, nilai-nilai tersebar sehingga tidak ada satu dimensi pun yang mendominasi, dan pembulatan jadi jauh lebih tidak merusak.
Itulah bagian QJL: proyeksi acak yang mencampur semuanya sambil mempertahankan jarak. PolarQuant (dipresentasikan di AISTATS 2026) kemudian mengkuantisasi nilai yang sudah dirotasi dalam koordinat polar, yang lebih cocok dengan distribusinya dibanding pembulatan grid biasa.
Hasilnya adalah yang disebut paper ini sebagai distorsi nyaris optimal, artinya mendekati batas teoretis Shannon untuk seberapa sedikit kualitas yang bisa hilang pada anggaran bit tertentu. Dalam bahasa sederhana: untuk 3 bit per nilai, pada dasarnya Anda tidak bisa berbuat banyak lebih baik, dan TurboQuant mencapainya tanpa mempelajari data Anda.
Untuk mekanisme lengkapnya, blog Google Research dan paper arXiv adalah sumber utamanya. InfoQ juga punya penjelasan berorientasi developer yang rapi tentang sisi KV-cache jika Anda ingin framing praktisinya.
Apa Artinya 31GB → 4GB untuk Tagihan RAM Anda?
Indeks RAG 10 juta vektor yang butuh ~31GB RAM pada presisi penuh turun menjadi sekitar ~4GB dengan kompresi berbasis TurboQuant milik TurboVec, cukup kecil untuk muat di instance biasa alih-alih tier yang berat memori. Untuk KV cache, pengurangan ~6x berarti sekitar 6x lebih banyak sesi konteks panjang bersamaan pada GPU yang sama. Itulah bagian yang benar-benar muncul di tagihan.
Kami menjalankan angka yang tidak dijalankan kompetitor. Catatan kejujuran singkat terlebih dahulu: semua di bawah ini adalah estimasi dan pemodelan (Juni 2026) dari harga cloud publik dan rasio yang dinyatakan paper. Kami belum menjalankan TurboVec di produksi, jadi perlakukan ini sebagai hitungan matematika, bukan benchmark yang kami ukur secara fisik. Tier harga mengikuti basis yang sama dengan yang kami gunakan di panduan mengurangi biaya API LLM.

Berikut indeks embedding 10 juta dokumen, presisi penuh vs terkompressi TurboVec, dipetakan ke tier RAM cloud yang benar-benar Anda butuhkan:
| Indeks RAG 10 juta vektor | RAM yang dibutuhkan | Tier instance tipikal | Kisaran biaya RAM bulanan kasar |
|---|---|---|---|
| Presisi penuh (float32) | ~31 GB | 32GB+ memory-optimized | lebih tinggi (tier memory-optimized) |
| Terkompressi TurboVec | ~4 GB | 8GB general-purpose | jauh lebih rendah (tier commodity) |
Lompatan dari box memory-optimized ke general-purpose kecil adalah keseluruhan ceritanya. Untuk indeks self-hosted, itu sering kali perbedaan antara tagihan yang membuat Anda meringis dan yang nyaris tidak terasa. Jika Anda sedang membangun pipeline yang berjalan di atasnya, panduan kami tentang membangun aplikasi RAG mencakup di mana indeks ini berada.
Sekarang sisi KV-cache, dimodelkan pada GPU 24GB tetap yang melayani sesi konteks 128k:
| KV cache, GPU 24GB @ konteks 128k | Sesi bersamaan (dimodelkan) |
|---|---|
| Presisi penuh | baseline (sebut saja ~N) |
| TurboQuant ~3-bit (~6x) | sekitar 6x N |
Pemotongan KV-cache 6x tidak hanya menghemat RAM. Itu bisa mengubah satu GPU menjadi enam untuk serving konteks panjang.
Itulah kenapa ini lebih penting untuk workload konteks panjang dibanding yang lain. Jika Anda melayani banyak chat pendek, KV cache Anda tidak pernah jadi bottleneck. Jika Anda menjalankan agen 128k token atau analisis dokumen, pemotongan 6x mengubah ekonomi per-GPU Anda dalam semalam. Laporan VentureBeat menyebutkan kenaikan throughput batas atas hingga 8x pada H100 dengan penghematan biaya 50%+, yang sejalan dengan hitungan konkurensi yang kami modelkan.
Kenapa Saham Chip Memori Turun, dan Apakah Wall Street Bereaksi Berlebihan?
Setelah pengungkapan TurboQuant, saham Micron, Western Digital, dan Seagate jatuh karena kekhawatiran bahwa memori AI yang jauh lebih murah akan menyusutkan permintaan DRAM dan HBM di masa depan — framing yang disebut "momen DeepSeek." Analis termasuk Wells Fargo berargumen sebaliknya: memori yang lebih murah mendorong lebih banyak penggunaan total, bukan lebih sedikit, melalui paradoks Jevons.
Narasinya menulis dirinya sendiri. AI adalah pembeli terbesar high-bandwidth memory saat ini, jadi jika algoritma Google memangkas kebutuhan memori 6x, logikanya, permintaan chip turun dan begitu juga pembuat chipnya. TechCrunch bahkan menggapai perbandingan "Pied Piper", startup kompresi fiktif dari Silicon Valley HBO yang berjanji menyusutkan data dunia. Saham jatuh karena ketakutan itu.
Ini pandangan yang lebih tenang, dan yang sebagian besar dilewatkan siklus berita. Wells Fargo menunjuk paradoks Jevons: ketika sesuatu jadi lebih murah dan lebih efisien, kita biasanya mengonsumsi lebih banyak secara keseluruhan, bukan lebih sedikit. Memori AI yang lebih murah berarti lebih banyak aplikasi yang merilis fitur konteks panjang, lebih banyak tim yang self-host indeks RAG lebih besar, dan lebih banyak inferensi yang terjadi, titik. Peningkatan efisiensi punya sejarah panjang dalam menumbuhkan permintaan total alih-alih membunuhnya.
Pasar menilai TurboQuant sebagai pembunuh permintaan. Sejarah bilang komputasi yang lebih murah biasanya berarti kita justru menggunakannya lebih banyak.
Jadi apakah penurunan itu reaksi berlebihan? Mungkin, setidaknya dalam jangka pendek. Paper riset bukan perombakan instan seluruh industri. Pasar bereaksi terhadap judul berita; deployment sebenarnya akan memakan waktu beberapa kuartal, dan efek induksi permintaan mungkin jauh melampaui penghematannya.
Bisakah Anda Benar-Benar Menggunakan TurboQuant Hari Ini?
Ya, sebagian. Rilis resmi Google untuk TurboQuant adalah paper dan algoritmanya, bukan produk siap pakai. Tapi implementasi komunitas sudah ada: TurboVec (RyanCodrai/turbovec, di PyPI) untuk indeks vektor, dan AmesianX/TurboQuant untuk llama.cpp (sekitar 5.2x, dengan dukungan DeepSeek-V2/V3 dan GLM-4.7-Flash via MLA). Ekosistemnya masih muda tapi sudah bisa digunakan.
Jika Anda ingin mencoba sisi indeks vektor, TurboVec tinggal pip saja:
pip install turbovec
# Rust + Python bindings, implements Google's TurboQuant for vector search
# llama.cpp KV-cache impl (DeepSeek/MLA): github.com/AmesianX/TurboQuant
# Python reference impl: github.com/yashkc2025/turboquantUntuk sisi KV-cache pada model lokal, implementasi llama.cpp AmesianX/TurboQuant adalah yang perlu dipantau, terutama jika Anda menjalankan model DeepSeek atau GLM dengan multi-head latent attention. Ini berpadu bagus dengan setup LLM lokal, karena KV cache yang lebih kecil berarti Anda bisa mendorong konteks lebih besar pada kartu yang sama. Dan jika Anda sedang memilih model open mana yang akan dijalankan, benchmark LLM open-source terbaik kami mencakup keluarga DeepSeek dan GLM secara langsung.
Peringatan jujur: ini paper-sekarang, ekosistem-matang-nanti. Deliverable resmi Google adalah riset, bukan produk yang didukung dengan SLA.
Jawaban jujurnya: TurboQuant adalah matematika yang bisa dikirim, bukan tombol unduh. Untuk saat ini.
TurboQuant Hype atau Nyata? Vonis Jujur
TurboQuant nyata dan benar-benar cerdas. Desain tanpa pelatihannya adalah terobosan sesungguhnya, dan kemenangan KV-cache paling penting untuk workload konteks panjang. Tapi ini bukan sihir: ini satu kemajuan kuantisasi di antara banyak lainnya, angka utama 31GB→4GB milik TurboVec bukan Google, dan kepanikan saham membaca berlebihan hasil riset.
Dari pengalaman kami menyetel biaya inferensi dan RAM untuk klien, hal yang menentukan apakah teknik seperti ini layak diadopsi adalah friksi. Tanpa pelatihan menang besar di sini, karena tidak ada siklus fine-tuning, tidak ada codebook yang perlu dipelihara, tidak ada operasi model. Anda bisa memasangnya ke sesuatu yang sudah Anda jalankan.
Yang berubah:
- Inferensi konteks panjang yang lebih murah, di situlah biaya memori benar-benar terasa.
- Indeks RAG self-hosted yang lebih kecil yang muat di hardware lebih murah.
- Opsi kompresi yang bisa Anda adopsi tanpa retraining apa pun.
Yang tidak berubah:
- Tidak akan banyak membantu workload konteks pendek dan model kecil, di mana KV cache tidak pernah jadi bottleneck.
- Tidak membuat kuantisasi Anda yang sudah ada usang dalam semalam; ini tambahan, bukan pengganti.
- Rilis resmi Google masih berupa paper, jadi tooling kelas produksi untuk sementara diserahkan ke komunitas.
Jika Anda sedang mencoba memahami apa artinya ini untuk tagihan inferensi atau RAM Anda sendiri, itu persis jenis pemodelan biaya yang kami lakukan untuk klien di Techsy. Dapatkan konsultasi gratis jika Anda ingin pendapat kedua.
Tentang Penulis
Mert Batur Gurbuz adalah Co-Founder Techsy.io, di mana timnya mengirim agen AI, sistem otomasi, dan pipeline voice/SDR untuk klien B2B. Ia belajar di University of Birmingham dan menulis tentang stack tooling LLM yang benar-benar digunakan tim Techsy di produksi. Terhubung di LinkedIn.
Pertanyaan yang Sering Diajukan
Apa itu Google TurboQuant?
TurboQuant adalah algoritma kuantisasi vektor tanpa pelatihan dari Google Research, dipublikasikan di arXiv 2504.19874 dan diterima di ICLR 2026. Algoritma ini mengompresi KV cache LLM sekitar 6x, hingga sekitar 3 bit per nilai, dengan kehilangan akurasi nyaris nol. Karena bersifat data-oblivious, ia bekerja pada model yang sudah ada tanpa fine-tuning atau retraining apa pun.
Apakah Google benar-benar merilis TurboVec?
Tidak. TurboQuant adalah algoritma Google. TurboVec adalah library Rust dan Python pihak ketiga terpisah (RyanCodrai/turbovec) yang dibangun di atas TurboQuant oleh developer independen. Beberapa media salah mengaitkan Google dengan perilisan TurboVec ketika benchmark 31GB→4GB viral, tapi GitHub menunjukkan itu proyek komunitas.
Apakah TurboQuant sama dengan TurboVec?
Tidak. TurboQuant adalah algoritma kompresi yang dipublikasikan Google. TurboVec adalah satu library yang mengimplementasikan algoritma itu untuk pencarian vektor. Yang satu adalah matematikanya; yang lain adalah tool yang dibangun dengan matematika itu. Hasil terkenal "31GB → 4GB, mengalahkan FAISS" adalah milik TurboVec, bukan sesuatu yang dikirim Google secara langsung.
Apakah TurboQuant kehilangan akurasi?
Kehilangan akurasi nyaris nol adalah klaim utama dari paper, bahkan pada sekitar 3 bit per nilai. Algoritma ini mencapai distorsi nyaris optimal (mendekati batas Shannon) dengan merotasi vektor secara acak sebelum mengkuantisasi, sehingga tidak ada satu dimensi pun yang mendominasi. Dalam praktiknya, penurunan kualitas cukup kecil untuk diabaikan pada kebanyakan workload.
Berapa banyak RAM yang dihemat TurboQuant?
Sekitar 6x pada KV cache, menurunkannya hingga sekitar 3 bit per nilai. Di sisi indeks vektor, TurboVec mendemokan indeks 10 juta dokumen menyusut dari 31GB menjadi sekitar 4GB, pemotongan memori hingga 92%. Penghematan aktual Anda tergantung pada baseline presisi dan apakah Anda mengompresi KV cache, embedding, atau keduanya.
Apakah ini hanya hype, kenapa saham memori turun?
Ini kemajuan nyata, tapi kepanikannya membaca berlebihan hasil riset. Micron, Western Digital, dan Seagate jatuh karena kekhawatiran bahwa memori AI lebih murah memangkas permintaan chip. Wells Fargo menyanggah dengan paradoks Jevons: memori yang lebih murah dan lebih efisien biasanya meningkatkan penggunaan total. Paper juga bukan perombakan industri instan, jadi reaksi jangka pendek terlihat berlebihan.
Bisakah saya menggunakan TurboQuant hari ini?
Sebagian. Rilis resmi Google adalah paper dan algoritmanya, bukan produk. Implementasi komunitas sudah ada sekarang: TurboVec di PyPI untuk indeks vektor, AmesianX/TurboQuant untuk llama.cpp (DeepSeek-V2/V3 dan GLM-4.7-Flash via MLA), dan yashkc2025/turboquant sebagai referensi Python. Ekosistemnya masih muda tapi sudah bisa digunakan.
Bagaimana TurboQuant berbeda dari kuantisasi yang sudah saya lakukan?
Kebanyakan kuantisasi mempelajari sampel data Anda untuk membangun codebook yang disetel. TurboQuant tanpa pelatihan dan data-oblivious, jadi mencapai rasionya tanpa pernah melihat distribusi Anda. Ia juga menargetkan KV cache dan indeks vektor secara spesifik, dengan distorsi nyaris optimal, alih-alih hanya mengompresi bobot model.
Apakah TurboQuant bekerja dengan DeepSeek atau llama.cpp?
Ya, melalui implementasi llama.cpp AmesianX/TurboQuant, yang melaporkan kompresi sekitar 5.2x dan mendukung DeepSeek-V2/V3 dan GLM-4.7-Flash via multi-head latent attention (MLA). Itu menjadikannya opsi praktis jika Anda self-host model tersebut dan ingin KV cache lebih kecil untuk konteks lebih panjang pada hardware yang sama.
Kapan TurboQuant benar-benar paling membantu?
Paling membantu untuk inferensi konteks panjang dan indeks RAG self-hosted besar, di mana memori adalah bottleneck sesungguhnya. Pemotongan KV-cache 6x berarti lebih banyak sesi konteks 128k bersamaan per GPU, dan indeks embedding terkompressi muat di instance lebih murah. Paling tidak membantu untuk chat konteks pendek dan model kecil, di mana KV cache tidak pernah jadi pendorong biaya Anda.