TurboQuant: Redefining AI efficiency with extreme compression

(research.google)

250 points | by ray__ 8 hours ago

24 comments

  • amitport 5 hours ago
    This is a great development for KV cache compression. I did notice a missing citation in the related works regarding the core mathematical mechanism, though. The foundational technique of applying a geometric rotation prior to extreme quantization, specifically for managing the high-dimensional geometry and enabling proper bias correction, was introduced in our NeurIPS 2021 paper, "DRIVE" (https://proceedings.neurips.cc/paper/2021/hash/0397758f8990c...). We used this exact rotational approach and a similar bias correction mechanism to achieve optimal distributed mean estimation. I also presented this work and subsequent papers in a private invited talk at Google shortly after publication. Given the strong theoretical overlap with the mechanisms in TurboQuant and PolarQuant, I hope to see this prior art acknowledged in the upcoming camera-ready versions.
    • eecc 1 hour ago
      Pardon my simplistic question, but when you mean rotation you’re essentially talking about diagonalization aren’t you?

      So storing the diagonal as a matrix and the new bases is more compact?

    • busfahrer 2 hours ago
      I just today learned about Multi-Head Latent Attention, which is also sort of a way of compressing the KV cache. Can someone explain how this new development relates to MHLA?
      • yorwba 1 hour ago
        Multi-Head Latent attention is a redesigned attention mechanism that produces lower-dimensional KV-cache entries. Vector quantization can store KV-cache entries using a small number of bits per dimension while ensuring that the resulting attention scores don't change too much. So MLA needs to be part of the model from the beginning of training, whereas VQ can be retrofitted afterwards, and you could also combine the two.
  • akhenakh 16 minutes ago
    Someone implementing it on llamacpp already https://github.com/mudler/llama.cpp/commit/dee102db1bfd723c9...
    • cpburns2009 1 minute ago
      For some reason I thought the implementation would be way more complicated than that. I obviously lack the domain knowledge to tackle something like this, but it looks straight forward.
  • pstoll 1 hour ago
    And a group has published an independent working implementation today, nice to see:

    https://github.com/tonbistudio/turboquant-pytorch

  • bilsbie 24 minutes ago
    It seems like most breakthroughs I see are for efficiency? What are the most importsnt breakthroughs from the past two or three years for intelligence?
    • ertgbnm 3 minutes ago
      Most breakthroughs that are published are for efficiency because most breakthroughs that are published are for open source.'

      All the foundation model breakthroughs are hoarded by the labs doing the pretraining. That being said, RL reasoning training is the obvious and largest breakthrough for intelligence in recent years.

    • irthomasthomas 7 minutes ago
      Efficiency gains can be used to make existing models more profitable, or to make new larger and more intelligent models.
  • benob 5 hours ago
    This is the worst lay-people explanation of an AI component I have seen in a long time. It doesn't even seem AI generated.
    • BenoitP 5 hours ago
      It is AI generated. Or was written by someone a bit far from the technical advances IMHO. The Johnson-Lindenstrauss Lemma is a very specific and powerful concept, when in the article the QLJ explanation is vacuous. A knowledgeable human would not have left the reader wanting for how that relates to the Lemma.
    • spencerflem 5 hours ago
      I think it is though-

      “ TurboQuant, QJL, and PolarQuant are more than just practical engineering solutions; they’re fundamental algorithmic contributions backed by strong theoretical proofs. These methods don't just work well in real-world applications; they are provably efficient and operate near theoretical lower bounds.”

      • NoahZuniga 2 hours ago
        Genius new idea: replace the em-dashes with semicolons so it looks less like AI.
        • tux3 1 hour ago
          You're absolutely right. That's not just a genius idea; it's a radical new paradigm.
      • zarzavat 2 hours ago
        I read "this clever step" and immediately came to the comments to see if anyone picked up on it.

        It reads like a pop science article while at the same time being way too technical to be a pop science article.

        Turing test ain't dead yet.

      • integralid 4 hours ago
        I also instinctively reacted to that fragment, but at this point I think this is overreacting to a single expression. It's not just a normal thing to say in English, it's something people have been saying for a long time before LLMs existed.
        • g-mork 2 hours ago
          Another instinctual reaction here. This specific formulation pops out of AI all the time, there might as well have been an emdash in the title
        • nvme0n1p1 4 hours ago
          There are tells all over the page:

          > Redefining AI efficiency with extreme compression

          "Redefine" is a favorite word of AI. Honestly no need to read further.

          > the key-value cache, a high-speed "digital cheat sheet" that stores frequently used information under simple labels

          No competent engineer would describe a cache as a "cheat sheet". Cheat sheets are static, but caches dynamically update during execution. Students don't rewrite their cheat sheets during the test, do they? LLMs love their inaccurate metaphors.

          > QJL: The zero-overhead, 1-bit trick

          > It reduces each resulting vector number to a single sign bit (+1 or -1). This algorithm essentially creates a high-speed shorthand that requires zero memory overhead.

          Why does it keep emphasizing zero overhead? Why is storing a single bit a "trick?" Either there's currently an epidemic of algorithms that use more than one bit to store a bit, or the AI is shoving in extra plausible-sounding words to pad things out. You decide which is more likely.

          It's 1:30am and I can't sleep, and I still regret wasting my time on this slop.

          • veunes 3 hours ago
            Looks like Google canned all their tech writers just to pivot the budget into H100s for training these very same writers
          • pqs 4 hours ago
            There is also the possibility that the article when through the hands of the company's communication department which has writers that probably write at LLM level.
      • benob 5 hours ago
        Maybe they quantized a bit too much the model parameters...
  • lwhi 19 minutes ago
    Will this help us run models locally?
  • vaildegraff 1 hour ago
    The accuracy preservation is impressive, but I'd want to see adversarial evaluation after quantization - not just benchmark scores. Compressed models can behave identically on clean inputs while diverging on edge cases. If your safety-critical behavior lives in the long tail of the distribution, a quantizer that rounds to the nearest centroid might round away your guardrails. Nobody publishes those numbers because nobody wants to find out.
    • hellcow 38 minutes ago
      LLM slop. See their other comment which is even more obvious.
      • vlovich123 18 minutes ago
        They only have one comment on this site unless it was deleted…
        • vidarh 12 minutes ago
          They have several, but the others won't show unless you have showdead turned on, as they've already been flagged.
  • ssijak 1 hour ago
    For my grug brain can somebody translate this to ELIgrug terms?

    Does this mean I would be able to run 500b model on my 48gb macbook without loosing quality?

    • x_may 1 hour ago
      KV cache compression, so how much memory the model needs to use for extending its context. Does not affect the weight size.
  • macleginn 1 hour ago
    "TurboQuant proved it can quantize the key-value cache to just 3 bits without requiring training or fine-tuning and causing any compromise in model accuracy" -- what do each 3 bits correspond to? Hardly individual keys or values, since it would limit each of them to 8 different vectors.
  • zeeshana07x 3 hours ago
    The gap between how this is described in the paper vs the blog post is pretty wide. Would be nice to see more accessible writing from research teams — not everyone reading is a ML engineer
    • om8 3 hours ago
      These are very different media types with very different goals.
    • dev_tools_lab 2 hours ago
      Agreed. The practical implications are often more interesting than the math anyway — smaller models running locally means you can afford to run multiple models in parallel for cross-validation, which changes how you approach tasks like code analysis or bug detection.
  • bluequbit 6 hours ago
    I did not understand what polarQuant is.

    Is is something like pattern based compression where the algorithm finds repeating patterns and creates an index of those common symbols or numbers?

    • Maxious 6 hours ago
      • pstoll 1 hour ago
        Good post but link at the end is broken.

        “”” For the full technical explanation with equations, proofs, and PyTorch pseudocode, see the companion post: TurboQuant: Near-Optimal Vector Quantization Without Looking at Your Data.“

      • spencerflem 5 hours ago
        I like the visualization, but I don’t understand the grid quantization. If every point is on the unit circle aren’t all the center grid cords unused?
        • fc417fc802 13 minutes ago
          Yeah that's odd. It seems like you'd want an n-1 dimensional grid on the surface of the unit sphere rather than an n dimensional grid within which the sphere resides.

          Looking at the paper (https://arxiv.org/abs/2504.19874) they cite earlier work that does exactly that. They object that grid projection and binary search perform exceptionally poorly on the GPU.

          I don't think they're using a regular grid as depicted on the linked page. Equation 4 from the paper is how they compute centroids for the MSE optimal quantizer.

          Why specify MSE optimal you ask? Yeah so it turns out there's actually two quantization steps, a detail also omitted from the linked page. They apply QJL quantization to the residual of the grid quantized data.

          My description is almost certainly missing key details; I'm not great at math and this is sufficiently dense to be a slog.

        • vincnetas 5 hours ago
          i think grid can be a surface of the unit sphere
    • mrugge 6 hours ago
      1. Efficient recursive transform of kv embeddings into polar coordinates 2. Quantize resulting angles without the need for explicit normalization. This saves memory via key insight: angles follow a distribution and have analytical form.
      • quotemstr 5 hours ago
        Reminds me vaguely of Burrows-Wheeler transformations in bzip2.
    • viktorcode 4 hours ago
      The way I understand it, it's a way of compressing vectors by switching from their per-component representation to polar coordinates representation, where the nearby vectors are clumped together to a single line, allowing to describe them by different lengths
  • moktonar 5 hours ago
    Aren’t polar coordinates still n-1 + 1 for radius for n-dim vector? If so I understand that angles can be quantized better but when radius r is big the error is large for highly quantized angles right? What am I missing?
    • amitport 5 hours ago
      r is a single value per vector. You don't have to quantize it, you can keep it and quantize the billion+ other coordinates of the vector.
      • mungoman2 4 hours ago
        What they're saying is that the error for a vector increases with r, which is true.

        Trivially, with r=0, the error is 0, regardless of how heavily the direction is quantized. Larger r means larger absolute error in the reconstructed vector.

        • amitport 4 hours ago
          Yes, the important part is that the normalized error does not increase with the dimension of the vector (which does happen when using biased quantizers)

          It is expected that bigger vectors have proportionally bigger error, nothing can be done by the quantizer about that.

  • maurelius2 5 hours ago
    I'm somewhat at a loss here other than understanding the fundamentals. Can someone tell me how the compression impact performance?
    • dryarzeg 4 hours ago
      If in short, for many inference tasks the bottleneck is memory bandwidth. Suppose you have a machine with a memory bandwidth of 256 GB/s, and let's say you want to do inference for 4B model (model with 4 billion parameters). If you will load the model in BF16 format (16 bits), each forward pass (i.e. each token generated) will require roughly ~8 GB of memory bandwidth. So, 256/8 = 32 t/s, and that's the generation speed you will be strictly capped at even if your processing power is measured in exaFLOPS. But let's say now that you have decided to instead quantize the model and then run the quantized version. Suppose you have made a Q4_K_M version (4 bits + some weights will take more). Now each of your forward passes will take roughly 2-3 GB (rough approximations, reality is different) of memory bandwith (actually, it will be around 2 GB), and even in the worst case 256/3 = 85.3, while 256/2 = 128 t/s. Quants can reduce quality of the model and lower it's performance, but in most modern quantization methods those losses are usually negligible (although, of course, they're still present). So, as you can see, it can be concluded that quantization "widens" (it's not removing it fully) memory bottleneck while still preserving (not always though) acceptable quality.

      (Sorry for my terrible English, it's not my native language)

    • valine 4 hours ago
      So let’s start with a really simple decoder transformer with a single layer and single attention head, and train it to predict the next token in a sequence of text. To predict the next token you need a few things: a query for the very last token in the sequence, and a key and value for every prior token. You take your query and compute a dot product with every prior key (two large vectors in, scaler attention score out). That scaler attention score first goes through softmax, and then becomes the weight you use to compute a weighted average of your values, new value goes through the mlp, mlp output is projected into the logits from which you sample your next token (that’s the general idea at least skipped a few steps).

      The last query in the sequence will be new for every new token you predict, but the set of prior keys and values stay the same, ie keys and values are reusable. The key value cache gets bigger and bigger for each new token you add to the sequence, and that’s where compression comes in. You have to store the keys and values in vram, and you’d like to keep the size down by not storing the raw uncompressed tensors. To make this work well your compression needs two things: it needs to be fast so that you can compress and decompress on the fly, and it needs to play well with softmax attention. Prior attempts at compression usually suck at one or the other, either the speed to decompress is too slow and your token/s takes a hit, or you lose important precision and the model output quality suffers. The claim in the paper is that they’ve made progress on both.

      • edg5000 4 hours ago
        So limiting max context length also reduces VRAM needs a bit? If cache is 20% of total, 1/10th of context as a limit would mean 18% total memory reduction.
        • valine 4 hours ago
          Yup exactly, in principle it helps with both inference speed by reducing memory bandwidth usage and also reduces the memory footprint of your kvcache.
  • lucrbvi 4 hours ago
    Sounds like Multi-Head Latent Attention (MLA) from DeepSeek
    • veunes 3 hours ago
      Nah, those are completely different beasts. DeepSeek's MLA solves the KV cache issue via low-rank projection - they literally squeeze the matrix through a latent vector at train time. TurboQuant is just Post-Training Quantization where they mathematically compress existing weights and activations using polar coordinates
  • paxrel_ai 2 minutes ago
    [dead]
  • leontloveless 59 minutes ago
    [dead]
  • pugchat 1 hour ago
    [dead]
  • veunes 3 hours ago
    [dead]
  • aledevv 3 hours ago
    [dead]
  • rsmtjohn 4 hours ago
    [dead]
  • mohsen1 5 hours ago
    [dead]
  • hikaru_ai 5 hours ago
    [dead]
  • dev_tools_lab 2 hours ago
    [dead]
  • mskkm 3 hours ago
    Pied Piper vibes. As far as I can tell, this algorithm is hardly compatible with modern GPU architectures. My guess is that’s why the paper reports accuracy-vs-space, but conveniently avoids reporting inference wall-clock time. The baseline numbers also look seriously underreported. “several orders of magnitude” speedups for vector search? Really? anyone has actually reproduced these results?
    • NitpickLawyer 2 hours ago
      • mskkm 2 hours ago
        They confirmed on the accuracy on NIAH but didn't reproduce the claimed 8x efficiency.
    • veunes 3 hours ago
      Classic academic move. If the authors show accuracy-vs-space charts but hide end-to-end latency, it usually means their code is slower in practice than vanilla fp16 without any compression. Polar coordinates are absolute poison for parallel GPU compute