Explore AI-native quantization that skips calibration without sacrificing quality

In just two days, I implemented TurboQuant in Python, inspired by the paper "TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate." This innovative approach challenges traditional quantization…

March 30, 20263 min readMachine Learning

Quantization without calibration data sounds like a fantasy until you see it work. The TurboQuant paper and the implementation shared by this developer deliver exactly that: a method that skips the usual tuning steps and still produces respectable results. For anyone who has wrestled with k-means clipping ranges or watched uniform quantization degrade a model's output, this is a genuinely practical advance.

The core insight is elegantly simple. Take a vector, apply a random rotation, and the coordinates start behaving like a Gaussian distribution. Once they do, you can apply optimal one-dimensional quantization per dimension with no further adjustment. No training set, no dataset-specific parameters, no calibration pass. The same quantizer works on any data that comes through. That matters most for scenarios where calibration is impractical, KV caches in transformers, where tokens stream in continuously, or vector databases that compress embeddings one at a time. This is not a theoretical curiosity; it is a tool that removes a bottleneck in real-time systems.

There is a catch, and it is worth stating plainly. The rotation step costs O(d³), which is expensive for high-dimensional vectors. The implementation in numpy works cleanly for small-scale tests, but scaling it to production workloads will require careful engineering. The paper also handles fractional bits via channel splitting, a detail the developer did not implement. These are limitations, not dealbreakers. The more surprising takeaway is how much mileage the rotation alone provides. After that step, the problem reduces to a solved one-dimensional quantization task, and the theory guarantees performance within about 2.7 times the optimal distortion bound. That is tight enough to be useful.

What this means for practitioners is straightforward: you can now compress vectors online without sacrificing quality to the degree that naive quantization demands. The method does not require a separate calibration phase, so it fits into pipelines where data arrives and must be quantized immediately. The developer's repository makes it possible to test this yourself. If you are building a system that relies on large-scale vector storage or streaming token compression, this is worth your time. The next step is to push the rotation cost down and see how the method holds up at scale. That is where the real work begins.

From Machine Learning

Spent ~2 days implementing this paper: TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate
Most quantization stuff I’ve worked with usually falls into one of these:

Read the original at Machine Learning

Briefing

Source: Machine Learning
Published: March 30, 2026

Open-source toolkit shrinks embeddings up to 42x while keeping recall high.
TL;DR: We built an open-source toolkit that compresses high-dimensional vectors (embeddings, KV cache, anything in pgvector/FAISS) by 5-42x while maintaining 0.95+ cosine similarity. Benchmarked 6 methods on 2.4M real embeddings. MIT licensed. GitHub: https://github.com/ahb-sjsu/turboquant-pro Install: pip install turboquant-pro The Problem Vector databases are eating RAM. If you're running RAG with BGE-M3 (1024-dim float32), each embedding is 4KB. At 1M vectors that's 4GB just for embeddings. At 10M you need 40GB. pgvector, FAISS, Pinecone — they all have this problem. What We Built TurboQuant Pro implements and benchmarks 6 compression methods: Method Ratio Cosine Sim Recall@10 Complexity Scalar int8 4x 0.999 0.99 Trivial Matryoshka truncation 4x 0.97 0.96 Trivial TurboQuant 3-bit 5.1x 0.978 0.97 Medium pgvector bytea (TQ) 10.5x 0.978 0.95 Medium Matryoshka + int8 16x 0.97 0.94 Low Matryoshka + TQ 3-bit 42x 0.93 0.90 Medium The core algorithm is PolarQuant + QJL from Zandieh et al. (ICLR 2026) — random rotation maps vectors onto a hypersphere, then Lloyd-Max scalar quantization compresses each coordinate to b bits. We added bit-packing, CUDA kernels, and a streaming KV cache manager on top. What's Novel First open-source implementation of the Zandieh et al. TurboQuant algorithm Multi-method benchmarking on real data (2.4M embeddings from a cross-civilizational ethics corpus spanning 5,000 years — long story) Practical recommendations — we found that for most RAG use cases, Matryoshka truncation + scalar int8 (16x, zero training, 3 lines of code) beats fancy methods. TurboQuant's rotation trick only wins for KV cache where you need quality at high compression. pgvector integration — store compressed embeddings as bytea, search in compressed space Streaming KV cache with L1 (hot, uncompressed) / L2 (cold, compressed) tiering Origin Story This started as a beam search optimization in a symbolic AI system (Theory Radar — formula search engine). The beam candidates were high-dimensional vectors that we compressed to fit wider beams in GPU memory. Then we realized the same trick works for LLM KV cache, then for RAG embeddings, then for... everything. Adapted from a production system running on 2x Quadro GV100 32GB. Benchmarked against a real pgvector database with 2.4M vectors. This isn't synthetic data — it's actual BGE-M3 embeddings from texts spanning Ancient Greek philosophy to Buddhist suttas to Reddit advice columns. Key Finding Simple beats clever for most use cases. Scalar int8 gives you 4x compression at 0.999 cosine similarity with literally 3 lines of NumPy. Matryoshka truncation (just slicing the vector) gives another free 4x if your embedding model supports it (BGE-M3 does). Combined that's 16x with zero moving parts, zero training, zero codebooks that can go stale. TurboQuant's rotation trick is worth the complexity only when you need the last bit of quality at high compression — specifically for KV cache in long-context inference where the quality/compression tradeoff directly affects output quality. Technical Details The PolarQuant step: ```python Random rotation maps any distribution onto unit hypersphere Q, _ = np.linalg.qr(rng.standard_normal((dim, dim))) rotated = x @ Q # Now each coordinate ~ N(0, 1/sqrt(dim)) Lloyd-Max scalar quantizer (optimal for Gaussian) indices = np.digitize(rotated, codebook_boundaries) # b-bit per coordinate Bit-pack: 8 x 3-bit values → 3 bytes packed = pack_3bit(indices) # 5.12x compression ``` Decompression: ```python reconstructed = codebook_centroids[unpack_3bit(packed)] original_approx = reconstructed @ Q.T # Inverse rotation cosine_similarity(original, original_approx) ≈ 0.978 ``` CuPy CUDA kernels for GPU: ~25 GB/s throughput on Volta. Usage ```python from turboquant_pro import TurboQuantKV tq = TurboQuantKV(head_dim=1024, bits=3) compressed = tq.compress(embeddings, packed=True) # 5.12x smaller recovered = tq.decompress(compressed) # 0.978 cosine sim ``` For pgvector: ```python from turboquant_pro.pgvector import TurboQuantPGVector tqpg = TurboQuantPGVector(dim=1024, bits=3) bytea_data = tqpg.to_pgbytea(embedding) # 4096 bytes → 388 bytes ``` What's Next Autotune CLI: turboquant-pro autotune --source postgres://... --min-recall 0.95 Native pgvector extension (C, not Python wrapper) FAISS integration vLLM KV cache plugin Proper paper (arXiv draft is in the repo) Links Code: https://github.com/ahb-sjsu/turboquant-pro Install: pip install turboquant-pro Paper: Zandieh et al., "Sub-linear Memory Inference via PolarQuant and QJL", ICLR 2026 License: MIT Feedback welcome. We're particularly interested in benchmarks on other embedding models (OpenAI ada-002, Cohere, etc.) and at larger scale (100M+ vectors). Built as part of the Atlas AI cognitive architecture project. The 2.4M ethics embeddings come from texts spanning Ancient Greek (Homer, Plato, Aristotle), Hebrew (Talmud, Mishnah), Buddhist (Pali Canon), Sanskrit (Vedas, Upanishads), Old Norse (Eddas), and modern advice columns. Because why not. submitted by /u/ahbond [link] [comments]
TurboQuant's response reframes the debate instead of resolving it.
I wanted to follow up to yesterday's thread and see if anyone wanted to weigh in on it. This work is far outside of my niche, but it strikes me as an attempt to reframe the issue instead of addressing concerns head on. The part that it bugging me is this: The true novelty of TurboQuant lies in our derivation of the exact distribution followed by the coordinates of rotated vectors, which we use to achieve optimal coordinate-wise quantization. This is worded as if deriving the exact distribution was part of the novelty, but from what I can gather a clearer way to state this would be that they exploited well known distributional facts and believe what they did with it is novel. Beyond that, it's just disingenuous to say "well, they didn't go through academic channels until people started noticing our paper" when you've been corresponding directly with someone and agree to fix one thing or another. OpenReview link for reference: https://openreview.net/forum?id=tO3ASKZlok In response to recent commentary regarding our paper, "TurboQuant," we provide the following technical clarifications to correct the record. TurboQuant did not derive its core method from RaBitQ. Random rotation is a standard, ubiquitous technique in quantization literature, pre-dating the online appearance of RaBitQ, e.g. in established works like https://arxiv.org/pdf/2307.13304, https://arxiv.org/pdf/2404.00456, or https://arxiv.org/pdf/2306.11987. The true novelty of TurboQuant lies in our derivation of the exact distribution followed by the coordinates of rotated vectors, which we use to achieve optimal coordinate-wise quantization. Correction on RaBitQ Optimality While the optimality of RaBitQ can be deduced from its internal proofs, the paper’s main theorem implies that the distortion error bound scales as. Because a hidden constant factor within the exponent could scale the error exponentially, this formal statement did not explicitly guarantee the optimal bound. This led to our honest initial characterization of the method as suboptimal. However, after a careful investigation of their appendix, we found that a strictbound can indeed be drawn. Having now verified that this optimality is supported by their deeper proofs, we are updating the TurboQuant manuscript to credit their bounds accurately. Materiality of Experimental Benchmarks Runtime benchmarks are immaterial to our findings. TurboQuant’s primary contribution is focused on compression-quality tradeoff, not a specific speedup. The merit of our work rests on maintaining high model accuracy at extreme compression levels; even if the runtime comparison with RaBitQ was omitted entirely, the scientific impact and validity of the paper would remain mostly unchanged. Observations on Timing TurboQuant has been publicly available on arXiv since April 2025, and one of its authors was in communication with RaBitQ authors even prior to that, as RaBitQ authors have acknowledged. Despite having nearly a year to raise these technical points through academic channels, these concerns were only raised after TurboQuant received widespread attention. We are updating our arXiv version with our suggested changes implemented. submitted by /u/Disastrous_Room_927 [link] [comments]
Turbocharge Your Vector Database with One Autotune Command
We just shipped an autotune CLI for turboquant-pro — it connects to your PostgreSQL database, samples embeddings, sweeps 12 compression configurations, and tells you exactly which one to use. bash turboquant-pro autotune \ --source "dbname=mydb user=me" \ --table chunks --column embedding \ --min-recall 0.95 10 seconds later: ``` Evaluating 12 configurations... Config Ratio Cosine Recall Var% Time PCA-128 + TQ2 113.8x 0.9237 78.7% 79.9% 2.2s PCA-128 + TQ3 78.8x 0.9390 84.0% 79.9% 0.6s PCA-256 + TQ3 41.0x 0.9700 92.0% 92.3% 0.7s PCA-384 + TQ3 27.7x 0.9823 93.7% 97.3% 0.7s PCA-384 + TQ4 20.9x 0.9906 96.0% 97.3% 0.6s PCA-512 + TQ4 15.8x 0.9949 96.3% 99.0% 0.6s Recommendation (min recall >= 95%): PCA-384 + TQ4: 20.9x compression Cosine similarity: 0.9906 Recall@10: 96.0% Storage: 758 MB -> 36 MB (saves 722 MB) ``` What it does The problem: you have a pgvector database with millions of embeddings. You want to compress them. But which configuration? PCA to how many dims? 2-bit, 3-bit, or 4-bit quantization? The quality/compression tradeoff depends on your specific data. Autotune answers this in ~10 seconds: Samples N embeddings from your table (default 5K, we used 2K here) Tries all 12 combinations of PCA dims (128, 256, 384, 512) x bit widths (2, 3, 4) Measures cosine similarity preservation and recall@10 for each Identifies the Pareto-optimal frontier Recommends the highest compression that meets your recall threshold Prints copy-paste code Real results on 194K production embeddings We ran this on a production RAG system (194K BGE-M3 1024-dim embeddings from 33 code repos): If you need 95%+ recall: PCA-384 + TQ4 gives you 20.9x compression at 0.991 cosine and 96.0% recall. Your 758 MB shrinks to 36 MB. If you can tolerate 84% recall: PCA-128 + TQ3 gives you 78.8x compression at 0.939 cosine. 758 MB becomes 10 MB. That's your entire corpus fitting in L3 cache. If you want maximum compression: PCA-128 + TQ2 hits 113.8x — nearly two orders of magnitude. Cosine still at 0.924. The whole sweep took 10.8 seconds on CPU. No GPU needed. How it works under the hood PCA-Matryoshka (our IEEE TAI submission) is a training-free technique: fit PCA once on a sample, rotate all vectors so truncation works, then quantize to 2-4 bits via TurboQuant scalar quantization. The "autotune" part is just sweeping the configuration space and measuring quality on your actual data. The key insight from our 15-method benchmark: PCA-Matryoshka + TurboQuant strictly dominates both binary quantization and product quantization across the practical compression range. Autotune finds exactly where on that frontier your data lives. Install & use ```bash pip install turboquant-pro[pgvector] turboquant-pro autotune \ --source "dbname=mydb user=me" \ --table my_embeddings \ --column embedding_vector \ --min-recall 0.95 \ --output results.json ``` Options: --sample-size, --pca-dims, --bits, --queries, --top-k. Full results saved as JSON for programmatic use. ```python After autotune recommends PCA-384 + TQ4: from turboquant_pro import PCAMatryoshka, PCAMatryoshkaPipeline, TurboQuantPGVector pca = PCAMatryoshka(input_dim=1024, output_dim=384) pca.fit(sample_embeddings) tq = TurboQuantPGVector(dim=384, bits=4) pipeline = PCAMatryoshkaPipeline(pca, tq) compressed = pipeline.compress(embedding) # 4096 bytes -> 195 bytes ``` GitHub: https://github.com/ahb-sjsu/turboquant-pro PyPI: pip install turboquant-pro Paper: IEEE TAI submission (PCA-Matryoshka: 15-method compression benchmark) License MIT submitted by /u/ahbond [link] [comments]