Di Balik Perdebatan TurboQuant-RaBitQ: Mengapa Kuantisasi Vektor Penting untuk Biaya Infrastruktur AI

Makalah TurboQuant Google (ICLR 2026) melaporkan kompresi cache 6x KV dengan kehilangan akurasi yang mendekati nol - hasil yang cukup mencolok untuk menghapus $90 miliar dari stok chip memori dalam satu hari. SK Hynix turun 12%. Samsung turun 7%.

Makalah tersebut dengan cepat menarik perhatian. Jianyang Gao, penulis pertama RaBitQ (SIGMOD 2024), mengajukan pertanyaan tentang hubungan antara metodologi TurboQuant dan karya sebelumnya tentang kuantisasi vektor. (Kami akan segera mempublikasikan percakapan dengan Dr. Gao - ikuti kami jika Anda tertarik).

Artikel ini bukan untuk memihak dalam diskusi tersebut. Yang mengejutkan kami adalah sesuatu yang lebih besar: fakta bahwa satu makalah kuantisasi vektor dapat menggerakkan nilai pasar sebesar $90 miliar menunjukkan betapa pentingnya teknologi ini untuk infrastruktur AI. Baik itu mengompresi cache KV di mesin inferensi atau mengompresi indeks di database vektor, kemampuan untuk mengecilkan data berdimensi tinggi sambil mempertahankan kualitas memiliki implikasi biaya yang sangat besar - dan ini adalah masalah yang sedang kami tangani, dengan mengintegrasikan RaBitQ ke dalam database vektor Milvus dan mengubahnya menjadi infrastruktur produksi.

Inilah yang akan kami bahas: mengapa kuantisasi vektor sangat penting saat ini, bagaimana TurboQuant dan RaBitQ dibandingkan, apa itu RaBitQ dan bagaimana cara kerjanya, pekerjaan teknik di balik pengirimannya di dalam Milvus, dan seperti apa lanskap pengoptimalan memori yang lebih luas untuk infrastruktur AI.

Mengapa Kuantisasi Vektor Penting untuk Biaya Infrastruktur?

Kuantisasi vektor bukanlah hal baru. Yang baru adalah seberapa mendesak industri membutuhkannya. Selama dua tahun terakhir, parameter LLM telah membengkak, jendela konteks telah membentang dari 4K hingga 128K+ token, dan data yang tidak terstruktur - teks, gambar, audio, video - telah menjadi input kelas satu untuk sistem AI. Setiap tren ini menciptakan lebih banyak vektor dimensi tinggi yang perlu disimpan, diindeks, dan dicari. Lebih banyak vektor, lebih banyak memori, lebih banyak biaya.

Jika Anda menjalankan pencarian vektor dalam skala besar - pipeline RAG, mesin rekomendasi, pencarian multimodal - biaya memori kemungkinan merupakan salah satu masalah infrastruktur terbesar Anda.

Selama penerapan model, setiap tumpukan inferensi LLM utama bergantung pada cache KV - menyimpan pasangan nilai-kunci yang telah dihitung sebelumnya sehingga mekanisme perhatian tidak menghitung ulang untuk setiap token baru. Hal inilah yang membuat inferensi O(n) menjadi mungkin, bukan O(n²). Setiap kerangka kerja dari vLLM hingga TensorRT-LLM bergantung pada ini. Tetapi cache KV dapat menghabiskan lebih banyak memori GPU daripada bobot model itu sendiri. Konteks yang lebih panjang, lebih banyak pengguna yang bersamaan, dan itu berputar dengan cepat.

Tekanan yang sama juga terjadi pada basis data vektor - miliaran vektor berdimensi tinggi yang tersimpan di memori, masing-masing berukuran 32-bit per dimensi. Kuantisasi vektor memampatkan vektor-vektor ini dari 32-bit float menjadi representasi 4-bit, 2-bit, atau bahkan 1-bit - mengecilkan memori hingga 90% atau lebih. Baik itu cache KV di mesin inferensi atau indeks di database vektor Anda, matematika yang mendasarinya sama, dan penghematan biayanya nyata. Itulah mengapa satu makalah yang melaporkan terobosan dalam bidang ini telah menggerakkan nilai pasar saham sebesar $90 miliar.

TurboQuant vs RaBitQ: Apa Bedanya?

Baik TurboQuant maupun RaBitQ dibangun di atas teknik dasar yang sama: menerapkan rotasi acak(transformasi Johnson-Lindenstrauss) pada vektor input sebelum kuantisasi. Rotasi ini mengubah data yang terdistribusi tidak teratur menjadi distribusi seragam yang dapat diprediksi, membuatnya lebih mudah untuk dikuantisasi dengan kesalahan yang rendah.

Di luar fondasi bersama itu, keduanya menargetkan masalah yang berbeda dan mengambil pendekatan yang berbeda:

	TurboQuant	RaBitQ
Target	Cache KV dalam inferensi LLM (data sesaat, per permintaan)	Indeks vektor yang persisten dalam basis data (data tersimpan)
Pendekatan	Dua tahap: PolarQuant (kuantizer skalar Lloyd-Max per koordinat) + QJL (koreksi sisa 1-bit)	Satu tahap: proyeksi hypercube + estimator jarak yang tidak bias
Lebar bit	Kunci 3-bit, nilai 2-bit (presisi campuran)	1-bit per dimensi (dengan varian multi-bit yang tersedia)
Klaim teoretis	Tingkat distorsi MSE yang hampir optimal	Kesalahan estimasi produk dalam yang optimal secara asimtotik (sesuai dengan batas bawah Alon-Klartag)
Status produksi	Implementasi komunitas; tidak ada rilis resmi dari Google	Dikirim dalam Milvus 2.6, diadopsi oleh Faiss, VSAG, Elasticsearch

Perbedaan utama bagi para praktisi: TurboQuant mengoptimalkan cache KV sementara di dalam mesin inferensi, sementara RaBitQ menargetkan indeks persisten yang dibangun, dipecah, dan ditanyakan oleh basis data vektor di miliaran vektor. Untuk sisa artikel ini, kita akan fokus pada RaBitQ - algoritme yang telah kami integrasikan dan kirimkan dalam produksi di dalam Milvus.

Apa itu RaBitQ dan Apa yang Diberikannya?

Pertama-tama, inilah intinya: pada set data 10 juta vektor dengan 768 dimensi, RaBitQ memampatkan setiap vektor menjadi 1/32 dari ukuran aslinya dengan tetap menjaga tingkat pengingatan di atas 94%. Dalam Milvus, ini berarti 3,6x lipat throughput kueri yang lebih tinggi daripada indeks presisi penuh. Ini bukan proyeksi teoretis - ini adalah hasil benchmark dari Milvus 2.6.

Sekarang, bagaimana cara mencapainya.

Kuantisasi biner tradisional memampatkan vektor FP32 menjadi 1 bit per dimensi - kompresi 32x. Pengorbanannya: recall runtuh karena Anda telah membuang terlalu banyak informasi. RaBitQ (Gao & Long, SIGMOD 2024) mempertahankan kompresi 32x yang sama tetapi mempertahankan informasi yang benar-benar penting untuk pencarian. Versi yang diperluas (Gao & Long, SIGMOD 2025) membuktikan bahwa ini optimal secara asimtotik, sesuai dengan batas bawah teoretis yang ditetapkan oleh Alon & Klartag (FOCS 2017).

Mengapa Sudut Lebih Penting Daripada Koordinat dalam Dimensi Tinggi?

Wawasan utama: dalam dimensi tinggi, sudut antara vektor lebih stabil dan informatif daripada nilai koordinat individual. Ini adalah konsekuensi dari konsentrasi ukuran - fenomena yang sama yang membuat proyeksi acak Johnson-Lindenstrauss bekerja.

Artinya dalam praktiknya: Anda dapat membuang nilai koordinat yang tepat dari vektor berdimensi tinggi dan hanya menyimpan arahnya relatif terhadap kumpulan data. Hubungan sudut - yang merupakan dasar dari pencarian tetangga terdekat - tetap bertahan dari kompresi.

Bagaimana Cara Kerja RaBitQ?

RaBitQ mengubah wawasan geometris ini menjadi tiga langkah:

Langkah 1: Normalisasi. Pusatkan setiap vektor relatif terhadap pusat dataset dan skala ke satuan panjang. Hal ini mengubah masalah menjadi estimasi inner-product antara vektor satuan - lebih mudah untuk dianalisis dan diikat.

Langkah 2: Rotasi acak + proyeksi hypercube. Terapkan matriks ortogonal acak (rotasi tipe Johnson-Lindenstrauss) untuk menghilangkan bias ke arah sumbu manapun. Proyeksikan setiap vektor yang dirotasi ke titik terdekat dari hypercube {±1/√D}^D. Setiap dimensi runtuh menjadi satu bit. Hasilnya: kode biner D-bit per vektor.

Langkah 3: Estimasi jarak yang tidak bias. Buatlah sebuah estimator untuk hasil kali dalam (inner product) antara kueri dan vektor asli (yang tidak dikuantisasi). Estimator ini terbukti tidak bias dengan kesalahan yang dibatasi oleh O(1/√D). Untuk vektor 768 dimensi, hal ini menjaga recall di atas 94%.

Komputasi jarak antara vektor biner direduksi menjadi bitwise AND + popcount - operasi yang dilakukan oleh CPU modern dalam satu siklus. Inilah yang membuat RaBitQ cepat, bukan hanya kecil.

Mengapa RaBitQ Praktis, Bukan Hanya Teoritis?

• Tidak perlu pelatihan. Terapkan rotasi, periksa tanda-tanda. Tidak ada pengoptimalan berulang, tidak ada pembelajaran buku kode. Waktu pengindeksan sebanding dengan kuantisasi produk.
• Ramah perangkat keras. Komputasi jarak adalah bitwise AND + popcount. CPU modern (Intel IceLake+, AMD Zen 4+) memiliki instruksi AVX512VPOPCNTDQ khusus. Estimasi vektor tunggal berjalan 3x lebih cepat daripada tabel pencarian PQ.
• Fleksibilitas multi-bit. Perpustakaan RaBitQ mendukung varian di luar 1-bit: 4-bit mencapai ~ 90% recall, 5-bit ~ 95%, 7-bit ~ 99% - semua tanpa perangkingan ulang.
• Dapat dikomposisikan. Menyatu dengan struktur indeks yang sudah ada seperti indeks IVF dan grafik HNSW, dan bekerja dengan FastScan untuk penghitungan jarak batch.

Dari Kertas ke Produksi: Apa yang Kami Bangun untuk Mengirimkan RaBitQ di Milvus

Kode RaBitQ yang asli adalah prototipe penelitian mesin tunggal. Untuk membuatnya bekerja di seluruh cluster terdistribusi dengan sharding, failover, dan konsumsi waktu nyata, diperlukan pemecahan empat masalah teknik. Di Zilliz, kami melakukan lebih dari sekadar mengimplementasikan algoritme - pekerjaan ini mencakup integrasi mesin, akselerasi perangkat keras, pengoptimalan indeks, dan penyetelan waktu proses untuk mengubah RaBitQ menjadi kemampuan tingkat industri di dalam Milvus. Anda dapat menemukan detail lebih lanjut di blog ini juga: Membawa Kompresi Vektor ke Tingkat Ekstrim: Bagaimana Milvus Melayani Kueri 3× Lebih Banyak dengan RaBitQ

Membuat RaBitQ Siap Didistribusikan

Kami mengintegrasikan RaBitQ secara langsung ke dalam Knowhere, mesin pencari inti Milvus - bukan sebagai plugin, tetapi sebagai jenis indeks asli dengan antarmuka terpadu. Ia bekerja dengan arsitektur terdistribusi penuh Milvus: sharding, partisi, penskalaan dinamis, dan manajemen koleksi.

Tantangan utamanya: membuat buku kode kuantisasi (matriks rotasi, vektor centroid, parameter penskalaan) yang sadar-segmen, sehingga setiap pecahan membangun dan menyimpan status kuantisasi sendiri. Pembuatan indeks, pemadatan, dan penyeimbangan beban semuanya memahami tipe indeks baru secara native.

Memeras Setiap Siklus dari Popcount

Kecepatan RaBitQ berasal dari popcount - menghitung set bit dalam vektor biner. Algoritmanya pada dasarnya cepat, tetapi seberapa besar throughput yang Anda dapatkan tergantung pada seberapa baik Anda menggunakan perangkat kerasnya. Kami membuat jalur kode SIMD khusus untuk kedua arsitektur server yang dominan:

• x86 (Intel IceLake+ / AMD Zen 4+): Instruksi VPOPCNTDQ AVX-512 menghitung jumlah popcount di beberapa register 512-bit secara paralel. Loop bagian dalam Knowhere direstrukturisasi untuk menghitung jarak biner secara batch ke dalam potongan-potongan selebar SIMD, sehingga memaksimalkan hasil.
• ARM (Graviton, Ampere): Instruksi SVE (Scalable Vector Extension) untuk pola popcount paralel yang sama - sangat penting karena contoh ARM semakin umum dalam penerapan cloud yang dioptimalkan dengan biaya.

Menghilangkan Overhead Runtime

RaBitQ membutuhkan parameter floating-point tambahan pada waktu kueri: centroid dataset, norma per-vektor, dan inner product antara setiap vektor yang dikuantisasi dengan vektor aslinya (yang digunakan oleh penaksir jarak). Menghitung semua ini per kueri akan menambah latensi. Menyimpan seluruh vektor asli mengalahkan tujuan kompresi.

Solusi kami: melakukan pra-komputasi dan menyimpan parameter-parameter ini selama pembuatan indeks, menyimpan parameter-parameter ini di dalam cache di samping kode-kode biner. Overhead memori kecil (beberapa float per vektor), tetapi ini menghilangkan komputasi per kueri dan menjaga latensi tetap stabil dalam konkurensi tinggi.

IVF_RABITQ: Indeks yang Sebenarnya Anda Gunakan

Dimulai dengan Milvus 2.6, kami mengirimkan IVF_RABITQ - Indeks File Terbalik + kuantisasi RaBitQ. Pencarian bekerja dalam dua tahap:

1. Pencarian kasar (IVF). K-means mempartisi ruang vektor ke dalam kelompok-kelompok. Pada waktu pencarian, hanya nprobe cluster terdekat yang dipindai.
2. Penilaian halus (RaBitQ). Di dalam setiap klaster, jarak diestimasi menggunakan kode 1-bit dan penaksir yang tidak bias. Popcount melakukan pekerjaan berat.

Hasil pada set data 768 dimensi, 10 juta vektor:

Metrik	IVF_FLAT (garis dasar)	IVF_RABITQ	IVF_RABITQ + SQ8 memperbaiki
Mengingat kembali	95.2%	94.7%	~95%
QPS	236	864	-
Jejak memori	32 bit/dim	1 bit/dim (~3% dari aslinya)	~25% dari aslinya

Untuk beban kerja yang tidak dapat mentoleransi bahkan celah pemanggilan sebesar 0,5%, parameter refine_type menambahkan scoring pass kedua: SQ6, SQ8, FP16, BF16, atau FP32. SQ8 adalah pilihan yang umum digunakan - ini mengembalikan pemanggilan ke tingkat IVF_FLAT pada sekitar 1/4 memori asli. Anda juga dapat menerapkan kuantisasi skalar ke sisi kueri (SQ1-SQ8) secara independen, memberi Anda dua kenop untuk menyesuaikan tradeoff latency-recall-biaya per beban kerja.

Bagaimana Milvus Mengoptimalkan Memori di Luar Kuantisasi

RaBitQ adalah tuas kompresi yang paling dramatis, tetapi ini adalah satu lapisan dalam tumpukan pengoptimalan memori yang lebih luas:

Strategi	Apa yang dilakukannya	Dampak
Kuantisasi tumpukan penuh	SQ8, PQ, RaBitQ dengan pengorbanan biaya-presisi yang berbeda	Pengurangan memori 4x hingga 32x
Pengoptimalan struktur indeks	Pemadatan grafik HNSW, pembongkaran SSD DiskANN, pembuatan indeks yang aman untuk OOM	Lebih sedikit DRAM per indeks, set data yang lebih besar per node
I/O yang dipetakan dengan memori (mmap)	Memetakan file vektor ke disk, memuat halaman sesuai permintaan melalui cache halaman OS	Dataset berskala TB tanpa memuat semuanya ke dalam RAM
Penyimpanan berjenjang	Pemisahan data panas/hangat/dingin dengan penjadwalan otomatis	Bayar harga memori hanya untuk data yang sering diakses
Penskalaan cloud-native(Zilliz Cloud, Milvus yang dikelola)	Alokasi memori yang elastis, pelepasan sumber daya yang menganggur secara otomatis	Bayar hanya untuk apa yang Anda gunakan

Kuantisasi Tumpukan Penuh

Kompresi ekstrem 1-bit RaBitQ tidak cocok untuk setiap beban kerja. Milvus menawarkan matriks kuantisasi yang lengkap: SQ8 dan kuantisasi produk (PQ) untuk beban kerja yang membutuhkan tradeoff presisi-biaya yang seimbang, RaBitQ untuk kompresi maksimum pada dataset yang sangat besar, dan konfigurasi hibrida yang menggabungkan beberapa metode untuk kontrol berbutir halus.

Pengoptimalan Struktur Indeks

Di luar kuantisasi, Milvus terus mengoptimalkan overhead memori dalam struktur indeks intinya. Untuk HNSW, kami mengurangi redundansi daftar kedekatan untuk mengurangi penggunaan memori per-grafik. DiskANN mendorong data vektor dan struktur indeks ke SSD, sehingga mengurangi ketergantungan DRAM secara dramatis untuk kumpulan data yang besar. Kami juga mengoptimalkan alokasi memori perantara selama pembuatan indeks untuk mencegah kegagalan OOM saat membuat indeks pada set data yang mendekati batas memori node.

Pemuatan Memori Cerdas

Milvus's mmap (memory-mapped I/O) mendukung pemetaan data vektor ke file disk, dengan mengandalkan cache halaman OS untuk pemuatan sesuai permintaan - tidak perlu memuat semua data ke dalam memori pada saat startup. Dikombinasikan dengan strategi pemuatan malas dan pemuatan tersegmentasi yang mencegah lonjakan memori secara tiba-tiba, hal ini memungkinkan pengoperasian yang lancar dengan set data vektor skala TB dengan biaya memori yang lebih rendah.

Penyimpanan Berjenjang

Arsitektur penyimpanan tiga tingkat Milvus mencakup memori, SSD, dan penyimpanan objek: data panas tetap berada di memori untuk latensi rendah, data hangat di-cache di SSD untuk keseimbangan kinerja dan biaya, dan data dingin tenggelam ke penyimpanan objek untuk meminimalkan biaya. Sistem menangani penjadwalan data secara otomatis - tidak diperlukan perubahan lapisan aplikasi.

Penskalaan Cloud-Native

Di bawah arsitektur terdistribusi Milvus, data sharding dan load balancing mencegah memori node tunggal kelebihan beban. Penyatuan memori mengurangi fragmentasi dan meningkatkan pemanfaatan. Zilliz Cloud (Milvus yang dikelola sepenuhnya) mengambil langkah lebih jauh dengan penjadwalan elastis untuk penskalaan memori sesuai permintaan - dalam mode Tanpa Server, sumber daya yang menganggur secara otomatis dilepaskan, sehingga mengurangi total biaya kepemilikan.

Bagaimana Lapisan-Lapisan Ini Bersatu

Pengoptimalan ini bukanlah alternatif - mereka bertumpuk. RaBitQ mengecilkan vektor. DiskANN menyimpan indeks pada SSD. Mmap menghindari pemuatan data dingin ke dalam memori. Penyimpanan berjenjang mendorong data arsip ke penyimpanan objek. Hasilnya: penerapan yang melayani miliaran vektor tidak membutuhkan RAM sebesar miliaran vektor.

Memulai

Karena volume data AI terus bertambah, efisiensi dan biaya basis data vektor akan secara langsung menentukan seberapa jauh aplikasi AI dapat berkembang. Kami akan terus berinvestasi dalam infrastruktur vektor berkinerja tinggi dan berbiaya rendah - sehingga lebih banyak aplikasi AI yang dapat beralih dari prototipe ke produksi.

Milvus adalah sumber terbuka. Untuk mencoba IVF_RABITQ:

• Lihat dokumentasi IVF_RABITQ untuk panduan konfigurasi dan penyetelan.
• Baca posting blog integrasi RaBitQ lengkap untuk tolok ukur yang lebih dalam dan detail implementasi.
• Bergabunglah dengan komunitas Milvus Slack untuk mengajukan pertanyaan dan belajar dari pengembang lain.
• Pesan sesi Jam Kerja Milvus gratis untuk membahas kasus penggunaan Anda.

Jika Anda lebih suka melewatkan penyiapan infrastruktur, Zilliz Cloud (dikelola sepenuhnya oleh Milvus) menawarkan tier gratis dengan dukungan IVF_RABITQ.

Kami akan mengadakan wawancara mendatang dengan Profesor Cheng Long (NTU, VectorDB@NTU) dan Dr. Jianyang Gao (ETH Zurich), penulis pertama RaBitQ, di mana kami akan membahas lebih dalam tentang teori kuantisasi vektor dan apa yang akan terjadi selanjutnya. Tuliskan pertanyaan Anda di kolom komentar.

Pertanyaan yang Sering Diajukan

Apa itu TurboQuant dan RaBitQ?

TurboQuant (Google, ICLR 2026) dan RaBitQ (Gao & Long, SIGMOD 2024) adalah metode kuantisasi vektor yang menggunakan rotasi acak untuk memampatkan vektor berdimensi tinggi. TurboQuant menargetkan kompresi cache KV dalam inferensi LLM, sementara RaBitQ menargetkan indeks vektor persisten dalam database. Keduanya telah berkontribusi pada gelombang ketertarikan saat ini dalam kuantisasi vektor, meskipun keduanya memecahkan masalah yang berbeda untuk sistem yang berbeda.

Bagaimana RaBitQ mencapai kuantisasi 1-bit tanpa merusak daya ingat?

RaBitQ mengeksploitasi konsentrasi pengukuran dalam ruang dimensi tinggi: sudut antara vektor lebih stabil daripada nilai koordinat individu seiring dengan meningkatnya dimensi. Ini menormalkan vektor relatif terhadap centroid dataset, kemudian memproyeksikan masing-masing vektor ke simpul terdekat dari sebuah hypercube (mengurangi setiap dimensi menjadi satu bit). Estimator jarak yang tidak bias dengan batas kesalahan yang dapat dibuktikan membuat pencarian tetap akurat meskipun terjadi kompresi.

Apa itu IVF_RABITQ dan kapan saya harus menggunakannya?

IVF_RABITQ adalah jenis indeks vektor di Milvus (tersedia sejak versi 2.6) yang menggabungkan pengelompokan file terbalik dengan kuantisasi RaBitQ 1-bit. Tipe ini mencapai 94,7% pemanggilan kembali pada 3,6x throughput IVF_FLAT, dengan penggunaan memori sekitar 1/32 dari vektor asli. Gunakan ketika Anda perlu melayani pencarian vektor berskala besar (jutaan hingga miliaran vektor) dan biaya memori menjadi perhatian utama - umum terjadi pada RAG, rekomendasi, dan beban kerja pencarian multimodal.

Bagaimana kuantisasi vektor berhubungan dengan kompresi cache KV di LLM?

Kedua masalah tersebut melibatkan kompresi vektor floating-point berdimensi tinggi. Cache KV menyimpan pasangan kunci-nilai dari mekanisme perhatian Transformer; pada konteks yang panjang, cache ini dapat melebihi bobot model dalam penggunaan memori. Teknik kuantisasi vektor seperti RaBitQ mengurangi vektor ini menjadi representasi bit yang lebih rendah. Prinsip-prinsip matematika yang sama - mengukur konsentrasi, rotasi acak, estimasi jarak yang tidak bias - berlaku baik saat Anda mengompresi vektor dalam indeks basis data atau dalam cache KV mesin inferensi.