DEV Community

Cover image for Google's TurboQuant: How They Cut LLM Memory by 6x Without Losing Accuracy
Divy Yadav
Divy Yadav

Posted on

Google's TurboQuant: How They Cut LLM Memory by 6x Without Losing Accuracy

A plain-English breakdown of the Google Research paper that compresses KV cache by up to 6x with near-zero accuracy loss. No training. No calibration data. Just math.

Read the full indepth article on Medium: Link

Running large language models is not just expensive.

It is wasteful.

Every time you send a long prompt, the model stores massive amounts of intermediate data in something called the KV cache. This cache grows with every token. It quietly eats GPU memory, slows responses, and drives up inference costs.

Most compression solutions force a tradeoff. You either save memory or you keep accuracy. Pick one.

Google's TurboQuant breaks that tradeoff. It compresses the KV cache by up to 6x and, in several benchmarks, performs identically to the full-precision model.

That is a different kind of result. This post explains why, in plain English.


What Is the KV Cache?

Kv Cache

Before anything else, you need to understand what TurboQuant is actually compressing.

When a language model processes text, it breaks input into tokens (roughly one token per word). For each token, it computes two sets of numbers: a Key and a Value. Together, these let the model decide how much attention to pay to each previous token when generating the next word.

Think of it this way. The Key is a label. The Value is the actual content. When the model wants to recall something, it scans all the Keys to find relevant ones, then reads the corresponding Values.

The KV cache stores all these Key-Value pairs for the entire conversation so the model does not recompute them on every new token.

The problem: these pairs are stored as 16-bit or 32-bit floating point numbers. A single layer of a large model can hold tens of millions of them. With hundreds of layers and thousands of tokens, the KV cache can consume gigabytes of GPU memory.

What quantization does: instead of storing each number at full precision, you store it at 3 or 4 bits. Smaller footprint. Faster lookups. But you lose accuracy in the rounding. The challenge is keeping that loss small.


What Vectors Actually Are (And Why This Matters)

TurboQuant is a vector quantization algorithm. If you have not worked with vectors in AI, here is the minimum you need.

A vector is an array of numbers. In AI, vectors encode meaning. The word "cat" might be represented as 1,536 numbers. Similar words (cat, kitten, feline) have similar vectors. Distant concepts (cat, telescope, inflation) have very different ones.

Vector quantization compresses those arrays by replacing precise values (like 0.7832194...) with approximate ones drawn from a small set of allowed values. The compression is lossy. The question is how much meaning you lose.

The naive approach groups a vector into small blocks, computes the centroid of each block, and stores which block each number belongs to.

The problem: every block needs its own scaling constant stored in full precision. Those constants add 1 to 2 extra bits per number, partially defeating the compression.

TurboQuant eliminates this overhead entirely. That is the core innovation.


The Old Problem: Overhead That Defeats the Point

Traditional vector quantization has a structural flaw that researchers have tolerated for decades.

When you quantize a block of numbers, you need to know the scale of that block to recover the original values. Numbers in the range 0 to 100 compress differently than numbers in the range 0 to 0.001. So you store the scale factor alongside the quantized data.

Those scale factors require full precision (16 or 32 bits) and must be stored per block. On a 4-bit scheme, adding even one extra bit of overhead per number is a 25% storage increase. It partially cancels out what you just compressed.

Most existing methods, including KIVI (a widely used KV cache quantizer), carry this overhead. It has been treated as unavoidable.

TurboQuant's two-stage design removes it by choosing a quantization strategy that does not need per-block scaling constants.


How TurboQuant Works: Two Stages

The clever part is not one idea. It is two ideas that work together.

Stage 1: PolarQuant

Standard quantization struggles because raw vectors have unpredictable distributions. Some dimensions have large values, others tiny ones. You need those scaling constants to manage this variation.

PolarQuant solves this by converting vectors into polar coordinates before quantizing.

Here is what that means. Instead of describing a point as "3 units east, 4 units north" (Cartesian), polar coordinates say "5 units total at a 37-degree angle." The distance from origin is the radius. The direction is the angle.

When you convert a high-dimensional vector into polar form, something useful happens. The radius captures signal strength. The angles capture direction and meaning. And the angles follow a predictable, concentrated distribution that fits neatly into a fixed grid.

Because the grid boundaries are predictable from geometry alone, you do not need separate scaling constants per block. The structure of the data handles it.

But there is a catch.

PolarQuant introduces a subtle bias in inner product estimation. Inner products are what the model uses when computing attention scores: how much should token 47 attend to token 12? A biased estimate means those scores drift slightly from what a full-precision model would compute. At low bit-widths (1 to 2 bits), this drift becomes significant.

Stage 2 fixes it.

Stage 2: QJL (Quantized Johnson-Lindenstrauss)

After Stage 1 quantizes most of the information, a small residual error remains: the gap between the quantized vector and the original.

TurboQuant takes that residual and applies a 1-bit correction using the Quantized Johnson-Lindenstrauss (QJL) transform:

  1. Multiply the residual vector by a random matrix
  2. Take only the sign of each resulting number (+1 or -1)
  3. Store one bit per dimension

That sounds lossy. And it is. But mathematically, this specific random projection preserves inner product relationships in expectation. The QJL correction is unbiased: on average, it accurately corrects for the bias Stage 1 introduces, without adding any overhead for scaling constants.

Put together:

  • Stage 1 handles most of the compression and eliminates per-block overhead
  • Stage 2 uses 1 bit per dimension to correct the bias Stage 1 introduces
  • The result is near-optimal by information theory standards

The paper proves mathematically that TurboQuant's distortion is within a factor of approximately 2.7 of the theoretical minimum for any quantization algorithm. You cannot do significantly better without violating information theory.


The Results (This Is Where It Gets Interesting)

TurboQuant is not just theoretically sound. It actually holds up in benchmarks.

KV Cache Compression on LongBench

On long-context tasks (question answering, summarization, code generation):

  • At 3.5 bits: TurboQuant matches full precision exactly. That is already 4.5x smaller.
  • At 2.5 bits (~6x compression): the performance drop is minimal (50.06 to 49.44 on LongBench, a 1.2% drop).

Compared to KIVI and PolarQuant, TurboQuant either matches or outperforms at every bit level.

Needle-in-a-Haystack

This test checks if a model can locate one specific piece of information buried inside a massive document.

Method Score
TurboQuant 0.997
PolarQuant 0.995
KIVI 0.981
PyramidKV 0.895
SnapKV 0.858
Full precision ~1.000

TurboQuant works up to 100K tokens with near-perfect recall.

Attention Computation Speed

Up to 8x faster attention computation compared to standard 32-bit models on H100 GPUs. Not just smaller. Also faster.

Vector Search

This one surprised me.

Method Indexing Time
Product Quantization Seconds to minutes
RabitQ Even slower
TurboQuant ~0.001 seconds

And despite that indexing speed, TurboQuant still achieves better recall accuracy than both methods.

No training. No calibration data. Near-instant indexing.


What "Data-Oblivious" Actually Means

Most quantization methods are data-dependent. They analyze a sample of your data, learn the distribution, and build a custom codebook optimized for that distribution.

This is why methods like Product Quantization and GPTQ take seconds or minutes to build an index. It also means they degrade silently when your data distribution shifts.

TurboQuant is data-oblivious. It applies the same random rotation to any input, then uses pre-computed quantization centroids based on the mathematical properties of rotated vectors. No learning. No calibration data. No dataset-specific tuning.

This matters for three real scenarios:

KV cache quantization: tokens arrive in real time. There is no opportunity to pre-analyze the data.

Live vector search systems: new vectors are added continuously. Re-indexing periodically is expensive. Data drift degrades data-dependent quantizers silently.

Production systems with shifting distributions: TurboQuant sidesteps the re-index-or-degrade tradeoff entirely.


Where This Actually Applies

Long-context LLM inference

Running Llama-3.1 or Gemini on long documents (contracts, research papers, codebases) is expensive because the KV cache grows linearly with context length. TurboQuant compresses it 4.5x to 6x without accuracy loss. The same hardware now handles roughly 4 to 6x longer contexts at the same cost.

RAG and vector databases

If you run a retrieval-augmented generation system with Qdrant, Pinecone, Weaviate, or pgvector, those databases store embedding vectors. Compressing them with TurboQuant means smaller index storage, faster similarity lookups, near-zero indexing time for new documents, and no need to retrain the quantizer when your data changes.

Edge and on-device deployment

Phones, laptops, embedded systems have strict memory budgets. KV cache compression is sometimes the difference between a model that fits in device memory and one that does not. TurboQuant gives 4x to 6x compression with no accuracy tradeoff.

Semantic search at scale

Google's own writeup explicitly mentions this as a primary use case. Building and querying vector indices over billions of embeddings requires minimal memory and fast lookups. TurboQuant's near-zero indexing time and recall numbers make it a strong option here.


What TurboQuant Does Not Do

Being honest about scope matters.

It is not for weight quantization. TurboQuant is designed for activations (KV cache values) and vector search indices. It is not a replacement for GPTQ or AWQ, which target model weights.

It has been tested on specific models. The KV cache experiments used Llama-3.1-8B-Instruct and Ministral-7B-Instruct. Results may vary on significantly different architectures, though the algorithm is theoretically model-agnostic.

There is no plug-and-play PyPI package yet. The paper is on arXiv (arXiv:2504.19874) and was presented at ICLR 2026. Google Research has an implementation, but as of publication there is no standalone production library. The algorithms are described clearly enough that a research team could implement from the paper.

The 2.5-bit case does trade some accuracy for compression. The 1.2% drop on LongBench may or may not be acceptable depending on your use case. That is a decision that depends on your application, not something TurboQuant resolves for you.


The Mental Model

Traditional quantization stores numbers in small blocks and needs extra overhead bits to record the scale of each block. Those overhead bits eat into the compression benefit.

TurboQuant avoids the problem by rotating vectors into a geometry where the scale is already known from the structure of the data, not from per-block constants. A 1-bit residual correction from QJL handles the bias this rotation introduces.

The result is near-optimal compression with provable guarantees, no training required, and near-zero preprocessing time.

What it does Result
KV cache compression 4.5x to 6x with no accuracy loss
Needle-in-haystack 0.997 (matches full precision)
LongBench general tasks Matches full precision at 3.5 bits
Attention computation Up to 8x faster vs 32-bit on H100
Vector search indexing ~0.001 seconds vs 37 to 600 seconds
Training required None

Final Thought

For a long time, memory in large language models has been treated as a necessary cost. If you want long context, you pay for it.

TurboQuant challenges that assumption.

It shows that with the right mathematical approach, you can significantly reduce memory usage without sacrificing performance. Not by building a smarter model. By compressing the existing one more honestly.

The next wave of AI progress may not come from bigger models. It might come from making existing systems faster, cheaper, and more efficient.

If that is true, TurboQuant is not just an optimization. It is a direction worth paying attention to.


Paper: TurboQuant: Online Vector Quantization with Near-optimal Distortion — arXiv:2504.19874


If you found this useful, drop a reaction or share it with someone working on LLM inference or vector search. And if you have tried KV cache quantization in production,
I would genuinely like to hear what you ran into.

Top comments (0)