Transform and Conquer: How Google Compresses LLMs 6x by Changing Coordinates

Multiplication is hard. Addition is easy.

Any elementary school kid knows this. What they don’t know is that logarithms exist precisely to exploit this asymmetry: you convert multiplication into addition, operate in the simple world, then undo the transformation. The result is correct. The effort, a fraction.

This pattern — transform the problem to a space where solving it is trivial, solve it, then transform back — is one of the most powerful in all of engineering. FFT does this with signals. Logarithms do it with products. And now Google just published a paper that does it with language model compression.

It’s called TurboQuant, and the idea is elegant enough to deserve an article.

The problem: compress without destroying

Modern LLMs have a bottleneck that isn’t the model itself, but its working memory. Every time a model generates text, it keeps structures called key-value cache (KV cache) in memory — basically, the “context” the model needs to remember to generate the next word.

In a large model with long context, the KV cache can occupy tens of gigabytes of VRAM. That’s a serious problem: GPU VRAM is expensive, finite, and shared with everything else.

The obvious solution is quantization: reduce the precision of each number. Instead of storing each value in 32 bits (float32), you store it in 4 bits or even 3. You go from a continuous range to a discrete scale with few steps. It works reasonably well.

Until you hit the trap.

The normalization constant trap

To quantize a block of numbers, you need to know their range: the minimum and maximum. These values are called normalization constants, and you have to store them at full precision (16 bits) to be able to reconstruct the original values.

Here’s the problem: if you quantize to 3 bits per number but need to store a 16-bit constant for every, say, 8 numbers, those constants cost 2 extra bits per number. Your “3-bit” compression actually occupies 5 effective bits. You’ve lost almost half the gain.

It’s like moving to a smaller apartment and discovering that the moving boxes occupy half the new place.

And you can’t just make the blocks bigger to amortize the constants, because bigger blocks mean worse approximation — the range widens and you lose precision. You’re trapped between two opposing forces.

This problem has been open for years. Everyone has tried solving it by inventing better compressors. Adaptive blocks, non-uniform quantization, mixed schemes. More complexity, more parameters, marginal results.

Google did something different. They didn’t invent a better compressor. They changed coordinates.

The coordinate change: from Cartesian to polar

The core idea of TurboQuant is to apply a random rotation to the vector before quantizing it, then convert the result to polar coordinates.

Let’s break this down.

Step 1: Random rotation

Imagine you have a vector in a high-dimensional space. Its components are irregularly distributed — some dimensions have huge values, others are nearly zero. That imbalance is exactly what makes you need normalization constants per block: each block has a different range.

What happens if you multiply the vector by a random rotation matrix? Geometrically, you’re rotating the vector to an arbitrary orientation. The vector remains the same (same length, same relationship with other vectors), but its components redistribute.

Here comes a result from mathematics that seems like magic: in high-dimensional spaces, a random rotation makes the vector’s components become nearly uniform. It’s a phenomenon called measure concentration — in high dimensions, almost all the mass of a distribution concentrates near its mean. Rotate randomly and everything flattens out.

In plain language: rotation destroys peaks and valleys. After rotating, all blocks have similar ranges. And if all blocks have similar ranges… you don’t need to store each one’s range.

Step 2: Convert to polar coordinates

After rotation, TurboQuant converts vectors from Cartesian coordinates (x, y, z…) to polar coordinates (one radius and a bunch of angles).

Why? Because random rotation has made the angles highly predictable — they’re concentrated in narrow, known ranges. Quantization bounds are fixed. They don’t depend on the data.

That means: zero normalization constants for angles. The overhead that ate 1-2 bits per number disappears. You only need to store the radius (one number per vector) and the quantized angles with fixed bounds.

flowchart LR
    subgraph antes["   Classic quantization   "]
        direction LR
        V1[" Original vector "] --> B1[" Split into blocks "]
        B1 --> N1["&nbsp;Compute min/max&nbsp;<br/>per block&nbsp;"]
        N1 --> Q1["&nbsp;Quantize&nbsp;<br/>3 bits + 2 bits overhead&nbsp;"]
    end

    subgraph despues["&nbsp;&nbsp;&nbsp;TurboQuant&nbsp;&nbsp;&nbsp;"]
        direction LR
        V2["&nbsp;Original vector&nbsp;"] --> R2["&nbsp;Random&nbsp;<br/>rotation&nbsp;"]
        R2 --> P2["&nbsp;Polar&nbsp;<br/>coordinates&nbsp;"]
        P2 --> Q2["&nbsp;Quantize&nbsp;<br/>3 bits, overhead ≈ 0&nbsp;"]
    end

    antes ~~~ despues

The beauty is that rotation is invertible. To recover the original vector, you dequantize, return to Cartesian, and apply the inverse rotation. The result is 6x compression of the KV cache without measurable precision loss.

Why it works: adding randomness reduces uncertainty

This is the most counterintuitive part of the paper. Adding noise (random rotation) reduces uncertainty. It seems like a contradiction, but has an elegant explanation.

Without rotation, each vector has its own internal distribution. Some dimensions dominate, others are noise. You don’t know beforehand what range each block will have. That uncertainty forces you to measure and store the ranges.

With rotation, you force all vectors to have the same statistical distribution (measure concentration in action). You no longer need to measure anything because you know beforehand how the values will be distributed. Randomness destroys vector-specific information (which wasn’t useful) and replaces it with predictable regularity (which is useful for everything).

It’s like shuffling a deck of cards. Before shuffling, you don’t know what order they’re in — you need to look at each card. After shuffling well, you know exactly what order they’re in: uniformly random order. Paradoxically, you know more about the shuffled system than the ordered one if what you need is to predict statistical properties.

TurboQuant in numbers

Google evaluated TurboQuant on several benchmarks with Gemma and Mistral models. The results:

That last point is key. Most quantization techniques need a calibration dataset to adjust parameters. TurboQuant needs nothing. Random rotation works equally well with any data because measure concentration is a property of the space, not the content.

The pattern every programmer should recognize

TurboQuant is a particular case of a much broader pattern that deserves a name: transform and conquer.

The idea: when a problem resists you, ask yourself if you’re working in the right space. Sometimes the solution isn’t a smarter algorithm, but a different representation of the same problem.

Examples you already know:

In all cases, the difficulty wasn’t in the problem but in the representation. Change coordinates and what was intractable becomes trivial.

What you can apply today

You don’t need to be compressing LLMs to use this pattern. The next time you find yourself fighting with a problem that “should be easy but isn’t,” ask yourself these questions:

1. Am I in the right space? If comparing two things is hard, maybe you need to normalize before comparing. If searching for something is slow, maybe you need an index (which is just an alternative representation optimized for search).

2. Is there a known transformation for my domain? FFT has existed since 1965. Wavelet transforms since the 80s. Vector embeddings since 2013. Many “hard” problems already have standard transformations that solve them. Before inventing something, check if someone already found the right coordinates.

3. Can I add randomness to simplify? Hashing, random projections, probabilistic sketches — they all work because adding controlled randomness destroys unnecessary complexity. If your problem has irregular structure that complicates your life, sometimes the best strategy is to destroy that structure on purpose.

The next time you force a solution

TurboQuant’s lesson isn’t about model compression. It’s about resisting the temptation to invent a better compressor when what you need is to change perspective.

For years, the ML community tried solving normalization constant overhead with more sophisticated quantization schemes. More blocks, more levels, more heuristics. All within the same Cartesian coordinate framework. All with incremental improvements.

Google didn’t do any of that. They rotated the data, changed coordinates, and the problem disappeared. They didn’t solve it. They dissolved it.

The next time you spend two hours wrestling with a solution that won’t quite fit, stop for a moment and ask yourself: am I fighting the problem or the representation? Because if you’re in the wrong coordinates, the best algorithm in the world won’t save you.

Source: TurboQuant: Redefining AI Efficiency with Extreme Compression — Google Research Blog.