Google's TurboQuant Claims Don't Survive Closer

When Google announced TurboQuant a few weeks ago, the headlines were remarkable: up to 6x memory reduction for language models, 8x speedups, 83% of hardware memory freed up. The research post racked up 38,000 likes. Memory chip stocks dropped 30%. For a moment, it looked like Google had pulled off something genuinely transformative.

Then people started reading the actual paper.

The problem isn't that TurboQuant is fake science or that the technique doesn't work. The core compression method is technically sound—clever, even. The problem is how it's being presented, and what that presentation reveals about the gap between research claims and production reality.

The Baseline Nobody Uses

That "8x speedup" claim? It compares TurboQuant's 4-bit compression against a 32-bit unquantized baseline. As YouTube creator bycloud points out in a detailed technical breakdown, "They are comparing 4bit against 32bit unquantized baseline. So of course on paper that gives you the cleanest tell line imaginable because 32-bit down to 4bit is exactly an 8:1 reduction in data movement."

This would be fine if anyone actually ran language model inference at 32 bits in production. They don't. Modern LLM deployments already use various forms of quantization. The meaningful question—how much better is TurboQuant than what people already use?—gets no clear answer in either Google's blog post or the research paper itself.

It's the research equivalent of claiming you run 100 times faster than a toddler when you should be comparing yourself to other sprinters.

What TurboQuant Actually Does

The technical approach is worth understanding because it illustrates both the sophistication and the limitations. TurboQuant compresses the KV cache—the memory structure that stores key and value vectors for each token a language model processes. As conversations or documents get longer, this cache grows linearly, and its size becomes a major bottleneck.

The challenge with compressing these vectors is that you can't just reduce their bit depth arbitrarily. The dot products between query and key vectors determine which past tokens influence the current one. Mess up those relationships and the model's behavior degrades.

TurboQuant's solution involves two steps. First, it applies a random rotation to the vectors, redistributing information evenly across all dimensions. This idea comes from an earlier paper called PolarQuant, which shares authors with TurboQuant. Once rotated, the vectors can be compressed with simple uniform quantization—no fancy schemes needed because every dimension now carries roughly the same amount of information.

The rotation is invertible and preserves dot products, so relationships between tokens stay intact. But some precision still gets lost. Step two addresses this by computing the quantization error, applying another random projection, and storing just the sign of each component—one bit per dimension. This sign information, borrowed from yet another earlier paper called QJL, provides an unbiased estimate of dot products. Individual computations might be slightly off, but errors cancel out across dimensions.

The result: compression from 16 bits per value down to around 2.5-4 bits while keeping model behavior mostly intact. At 3.5 bits, the paper claims "quality neutral" performance—meaning the model behaves almost identically to full precision.

The Comparison Problems

Here's where things get messy. The 6x memory savings figure comes from comparing a theoretical 16-bit KV cache against TurboQuant at 2.5 bits. It only applies to the KV cache, not model weights, so the total memory footprint reduction is smaller than headlines suggest. And that 16-bit baseline? It's what bycloud calls "a theoretical baseline that lacks optimization"—not representative of current production systems.

More problematic is how TurboQuant was benchmarked against prior research. A technique called RabbitQ, published a year earlier, uses similar rotation methods and shares its C++ implementation openly. The TurboQuant authors ported RabbitQ to Python for comparison—but in a version that doesn't support multithreading. Then they ran RabbitQ on a CPU while running TurboQuant on an H100 GPU.

Comparing different hardware isn't automatically invalid, but it makes the performance comparison essentially meaningless. What makes it worse is that the paper dismissed RabbitQ as "suboptimal" without fully engaging with its ablation studies—something the TurboQuant authors acknowledged in OpenReview comments after RabbitQ's creator reached out multiple times requesting clarification.

One peer reviewer gave TurboQuant a 10 out of 10. Others gave it a 4 and a 6. The paper was published nearly a year ago, then recently accepted to ICLR 2026, then promoted by Google as if it were breaking news. Whether this represents a coordinated media push or just poor timing awareness is unclear, but the effect is the same: headlines that don't match the substance.

What This Tells Us About OSS AI Research

Every company serving LLMs at scale already uses some form of KV cache quantization. This isn't new territory—it's an ongoing optimization arms race where incremental improvements matter but rarely constitute breakthroughs. Google may have achieved modest gains in their own infrastructure, but the idea that they freed up 83% of memory on top of current state-of-the-art methods strains credibility, especially without released code to verify.

The TurboQuant authors have promised improvements to the paper following community feedback. That's good. But the initial presentation reveals something familiar to anyone who covers corporate research: the distance between what a technique actually does and what the marketing claims it does.

"This sort of optimization at KV cache level is not something new and every company that serves LLM definitely uses some sort of quantizations there," bycloud notes. "So no, nothing crazy revolutionary about AI is discovered and everyone has already been maxing the compression efficiency in their own ways."

The memory chip stocks recovered within days. The technique might find its way into production systems as one tool among many. The headlines will fade. What remains is a case study in how research gets packaged for maximum impact, and how the baselines you choose determine the story you can tell.

When a paper's most dramatic claims rest on comparisons nobody uses in practice, that's not necessarily fraud. But it's not science communication in good faith either.

Dev Kapoor covers open source software, developer communities, and the politics of code for Buzzrag.