谷歌 TurboQuant 深度拆解：LLM 内存压缩 6 倍、推理加速 8 倍、零精度损失，它是怎么做到的？

数据智能老司机
0 阅读16分钟

昨天互联网炸了

2026 年 3 月 24 日，谷歌研究院发了一篇不太起眼的博客，配了一个彩色方块的动图。24 小时内，相关推文获得了 1190 万次浏览。Cloudflare CEO Matthew Prince 发推说"这是谷歌的 DeepSeek 时刻"。TechCrunch 的报道标题直接把它类比成了《硅谷》里的 Pied Piper。美股存储芯片板块在消息发布后几小时内就开始下跌。

这篇博客介绍的东西叫 TurboQuant——一个把 LLM 的 KV 缓存压缩到 3 bit、内存减少 6 倍、推理速度提升 8 倍、而且零精度损失的压缩算法。

更关键的是：它不需要训练，不需要微调，不需要校准数据。即插即用。

论文将在下个月的 ICLR 2026 上正式发表。

这篇文章是我在读完谷歌原始博客、三篇论文（TurboQuant、PolarQuant、QJL）、以及所有一手报道后的深度拆解。我会把这个技术从底层原理到工程实现到产业影响讲透，尽量让不搞 ML 基础设施的人也能理解它为什么重要。

第一部分：先搞懂问题——KV 缓存为什么是 LLM 的命门

在理解 TurboQuant 之前，你必须先理解它要解决的问题。

KV 缓存是什么

当 LLM 处理一段文本时，它需要对每个 token 计算"注意力"——决定当前这个词应该关注之前哪些词。这个计算需要用到之前每个 token 的两组向量：Key（键）和 Value（值）。

为了避免重复计算，模型会把已经算过的 Key-Value 对存起来。这就是 KV 缓存——相当于 LLM 的"短期记忆"。

问题在哪

问题在于这个"记忆"太占内存了。

一个具体的数字：运行一个 700 亿参数的模型，同时服务 512 个用户，KV 缓存就要消耗 512 GB 内存——是模型权重本身所需内存的将近四倍。

随着上下文窗口越来越长（从 4K 到 32K 到 128K 到百万级别），KV 缓存的增长是线性的——上下文长度翻倍，缓存占用就翻倍。它已经成为 LLM 推理的首要内存瓶颈。

这意味着什么？意味着你不是缺算力——你是缺内存。GPU 的计算核心可能在闲置，但显存已经被 KV 缓存塞满了。

传统量化为什么不够用

面对这个问题，最直觉的想法是"量化"——把存储精度从 16 bit（FP16）降到更低的 bit 数。理论上，从 16 bit 降到 4 bit，内存就能减少 4 倍。

但传统向量量化有一个被很多人忽视的问题：量化常数的内存开销。

什么意思呢？量化需要对数据分块，每个块需要存储一些"常数"——比如每个块的最大值、最小值或者缩放因子——来确保解压时能还原数据。这些常数通常用全精度（FP16 或 FP32）存储。

听起来开销很小？但算一下——如果你把数据量化到 2 bit，每个块额外需要 1-2 bit 来存储常数，那你的有效压缩率就从理论上的 8 倍（16/2）降到了实际的 4-5 倍。额外开销吃掉了将近一半的压缩收益。

bit 数越低，这个问题越严重。当你试图极限压缩到 2-3 bit 时，量化常数的开销就变成了不可忽视的大头。

TurboQuant 要解决的核心问题就是这个：怎么在极低 bit 下实现高质量压缩，同时把量化常数的开销降到零？

第二部分：TurboQuant 的原理——两步法拆解

TurboQuant 的设计思路出人意料地清晰。它把压缩分成两步：第一步用 PolarQuant 做"重活"（用大部分 bit 预算捕获数据的主要信息），第二步用 QJL 做"纠偏"（只用 1 bit 修正第一步留下的残余误差）。

两步加起来，零额外开销，零精度损失。

我来逐步拆解。

第一步：PolarQuant——换一个坐标系来看数据

PolarQuant 的核心洞察非常巧妙：传统量化之所以需要存储常数，是因为数据在笛卡尔坐标系下的分布范围是不可预测的。如果我们把数据变换到一个分布范围已知、可预测的坐标系下呢？

具体做法分三步：

第一步：随机旋转。 先对数据向量做一个随机旋转变换。这个操作在数学上保证了一个关键性质——旋转后，每个坐标的分布变成了一个高度集中的、已知的 Beta 分布，而且这个分布不依赖于原始数据。

为什么这一步如此重要？因为传统量化需要存储常数的根本原因是——它需要知道"这一块数据的范围是多少"才能做映射。而随机旋转后，范围已知，不需要再存了。

第二步：笛卡尔坐标转极坐标。 把旋转后的向量从 X-Y-Z 坐标转换为"半径+角度"的极坐标表示。

打个比方：传统方法说"往东走 3 格，往北走 4 格"，PolarQuant 说"朝 37 度角走 5 步"。信息完全相同，但表达方式不同。

为什么要转极坐标？因为在高维空间中，随机旋转后的角度分布是高度集中且可预测的。它天然地落在一个固定的"圆形网格"上，而不是一个边界不断变化的"方形网格"上。这意味着你不需要存储任何边界信息——边界是数学已知的。

第三步：递归压缩。 PolarQuant 把坐标两两配对，转换成极坐标后得到半径和角度。然后把这些半径再两两配对，再做极坐标变换——如此递归，直到所有数据被蒸馏成一个最终半径和一组描述性角度。

对这些角度，可以直接使用最优的标量量化器（比如 Lloyd-Max 量化器）来量化，而且不需要任何归一化开销。

结果：PolarQuant 用大部分 bit 预算完成了高质量压缩，量化常数的额外开销为零。

第二步：QJL——1 bit 的数学魔法

PolarQuant 已经做得很好了，但总会有一些残余误差。这些误差虽然小，但如果在注意力计算中累积，会引入系统性偏差。

QJL（Quantized Johnson-Lindenstrauss）用一种极度优雅的方式解决了这个问题。

核心思路：用 Johnson-Lindenstrauss 变换把残余误差投影到低维空间，然后对投影结果只保留符号位（+1 或 -1），每个值只需要 1 bit。

关键来了——QJL 配合一个特殊的无偏估计器，用高精度的查询（Query）和低精度的压缩数据（Key）巧妙结合，能够无偏地重建注意力分数。

"无偏"在这里是严格的数学概念——不是"接近准确"，而是"期望上精确等于真实值"。这就是为什么 TurboQuant 能声称"零精度损失"——不是因为误差小到可以忽略，而是因为数学上证明了误差的期望为零。

QJL 的额外内存开销？零。 它只用了 1 bit，而且这 1 bit 已经包含在压缩预算里了。

两步结合的效果

把 PolarQuant 和 QJL 结合起来：

  • PolarQuant 用大部分 bit（比如 2 bit）做主体压缩，消除了量化常数开销
  • QJL 用额外 1 bit 做残余纠偏，消除了系统性偏差
  • 总共 3 bit，实现了从 16 bit 到 3 bit 的超过 5 倍压缩
  • 零额外开销，零（数学意义上的）精度损失
  • 不需要训练、微调或校准——完全 data-oblivious（数据无关）

这最后一点尤其重要。传统量化方法通常需要在目标模型的数据上做校准——这意味着每换一个模型、每换一个任务，都需要重新校准。TurboQuant 是 data-oblivious 的——它的数学保证对任何数据都成立，拿来就用。

第三部分：实验结果——数字有多硬

理论再漂亮，也要看实验数据。谷歌在多个基准上做了系统测试，结果确实非常有说服力。

KV 缓存压缩

在 LongBench 基准上（覆盖问答、代码生成、摘要等多种任务），使用 Llama-3.1-8B-Instruct 模型，TurboQuant 在所有任务上的表现匹配或超越了 KIVI（现有主流 KV 缓存量化方案），同时使用更少的 bit 数。

在 Needle-in-a-Haystack 测试（在海量文本中找到特定信息）中，TurboQuant 在所有基准上取得了完美分数，同时 KV 内存减少至少 6 倍。

推理速度

在 NVIDIA H100 GPU 上，4-bit TurboQuant 在计算注意力 logits 时相比 32-bit 未量化基准加速了 8 倍。即使和高度优化的 JAX 基线比，加速也非常显著。

为什么压缩能加速？因为注意力计算是内存带宽瓶颈——瓶颈不是计算本身，而是把数据从内存搬到计算核心的速度。数据变小了，搬运就快了，计算自然就快了。

向量搜索

TurboQuant 不只能压缩 KV 缓存，它本质上是一个通用的向量量化方法。

在 GloVe 数据集（d=200）上，TurboQuant 在 1@k 召回率上全面超越了 Product Quantization（PQ）和 RabbiQ——而且后两者使用了更大的码本和数据集特定的调优。

更惊人的是索引速度：对 1536 维向量，TurboQuant 的索引时间是 0.0013 秒，而 PQ 需要 239.75 秒。差了 18 万倍。

这是因为 TurboQuant 是 data-oblivious 的——不需要在数据上学习码本，拿来就能量化。

第四部分：能力边界——TurboQuant 做不到什么

任何技术都有能力边界。在被 hype 冲昏头脑之前，必须清醒地看到 TurboQuant 的局限性。

只解决推理内存，不解决训练内存

TurboQuant 压缩的是 KV 缓存——这是推理阶段的内存消耗。训练阶段的内存消耗（梯度、优化器状态、激活值）完全不受影响。

所以那些说"AI 对内存的需求会大幅降低"的分析，至少在训练侧是站不住的。推理侧确实会有很大影响。

目前只在 8B 级别模型上验证

谷歌的实验使用了 Gemma 和 Mistral 等开源模型，参数规模在 7-8B 级别。NVIDIA 的竞争方案 KVTC 测试了从 1.5B 到 70B 的模型。TurboQuant 在更大规模模型上的表现如何，还需要更多验证。

没有官方代码

截至本文撰写时（2026 年 3 月 26 日），谷歌没有发布 TurboQuant 的官方代码。论文展示了算法，但没有提供推理框架、CUDA kernel 或者与 vLLM/TensorRT-LLM/SGLang 的集成。

开源代码普遍预计在 2026 年 Q2 发布。

不过，社区已经动起来了。有开发者用 Triton 在 PyTorch 里实现了自定义 kernel，在 RTX 4090 上用 Gemma 3 4B 测试，报告在 2-bit 精度下输出和未压缩基线逐字符完全一致。llama.cpp 社区也在追踪集成方案。MLX 上的实验报告了 5 倍压缩和 99.5% 质量保留。

竞争方案也在进步

TurboQuant 不是 ICLR 2026 上唯一的 KV 缓存压缩论文。NVIDIA 的 KVTC 实现了 20 倍压缩，精度损失不到 1 个百分点——但它需要对每个模型做校准，不是 data-oblivious 的。这是两种不同的设计哲学：TurboQuant 追求零损失和通用性，KVTC 追求极限压缩率。

QJL 的实现细节至关重要

有社区反馈指出，如果不正确实现 QJL 的无偏内积估计器，量化误差会复合累积，输出直接崩溃。这不是"效果差一点"的问题，而是"完全不可用"的问题。

这意味着正确的实现不是 trivial 的——数学公式到工程代码之间有一段不短的路要走。

第五部分：产业影响——为什么芯片股在跌

对推理基础设施的影响

如果 TurboQuant 被广泛采用，最直接的影响是：同样的 GPU 内存可以服务更多用户，或者支持更长的上下文窗口。

Wells Fargo 分析师 Andrew Rocha 的评论很直接——TurboQuant 直接攻击了 AI 系统中内存的成本曲线。如果广泛采用，它立刻提出一个问题：行业到底需要多少内存容量？

但他和其他分析师也提醒，AI 对内存的需求仍然很强，而且压缩算法存在多年并没有从根本上改变采购量。内存只是数据中心成本的一部分——减少 6 倍内存需求不等于减少 6 倍支出。

对本地 LLM 运行的影响

这可能是对个人开发者最激动人心的部分。

KV 缓存是本地运行大模型的主要瓶颈之一——它限制了你能使用的上下文长度。TurboQuant 把 KV 缓存减少 6 倍，意味着：

  • 原本只能处理 16K 上下文的 GPU，可能可以处理 100K+
  • 原本需要 80GB GPU 才能跑的长上下文推理，可能 24GB 就够了
  • 本地 LLM 的"每秒 token 数"（TPS）会显著提升——因为内存带宽是核心瓶颈

一些观点把这称为"推理主权"——当大模型可以在个人硬件上高效运行，对云服务的依赖就减少了。

对向量搜索的影响

TurboQuant 作为通用向量量化方法的潜力可能比 KV 缓存压缩还大。

现代搜索正在从关键词匹配演化为语义搜索——需要在数十亿个向量中找到"最相似"的结果。RAG 系统也依赖大规模向量检索。

TurboQuant 在这些场景下的优势是压倒性的——索引时间接近于零（比 PQ 快 18 万倍），召回率更高，内存消耗更低。对于需要实时构建和查询大型向量索引的应用场景（推荐系统、语义搜索、RAG），这是一个颠覆性的改进。

对更广泛的 AI 生态的影响

谷歌在博客结尾的定位很有野心——他们把 TurboQuant 定位为统一 KV 缓存和向量搜索的压缩方法。这暗示它的应用范围远超 LLM 推理：

  • 推荐系统中的用户/物品嵌入压缩
  • 多模态模型中的视觉/音频特征压缩
  • 任何需要高效存储和检索高维向量的场景

第六部分：技术深度——为什么 PolarQuant 的数学这么优美

这一节写给对数学感兴趣的读者。如果你只关心应用层面，可以跳过。

量化的理论下界

向量量化有明确的信息论下界。给定 b bit 预算：

  • 均方误差下界：DMSE≥1/4bD_MSE ≥ 1/4^b
  • 内积失真下界：Dprod≥(‖y‖2/d)⋅1/4bD_prod ≥ (‖y‖² / d) · 1/4^b

传统方法在实践中远高于这些下界。TurboQuant 声称接近理论下界。

为什么随机旋转这么关键

高维空间有一个反直觉的性质：如果你对一个单位球面上的向量做随机旋转，旋转后的每个坐标会服从一个高度集中的分布： fX(x)=Γ(d/2)/(√π⋅Γ((d−1)/2))×(1−x2)((d−3)/2)f_X(x) = Γ(d/2) / (√π · Γ((d-1)/2)) × (1 - x²)^((d-3)/2)

其中 x∈[−1,1]x ∈ [-1, 1]，dd 是维度。维度越高，这个分布越集中——几乎所有坐标值都挤在一个很窄的范围内。

这就是 PolarQuant 能省掉量化常数的根本原因：分布范围是数学已知的，不需要从数据中估计。

无偏估计的数学保证

QJL 的核心定理是：给定高精度查询向量 y 和 1-bit 量化的键向量 sign(Rx)sign(Rx)（其中 R 是 JL 随机矩阵），存在一个估计器 ⟨y, x⟩ 的估计值使得：

  • 期望等于真实内积（无偏）
  • 方差以 1/m 的速率衰减（m 是投影维度）

这不是近似——这是严格的数学证明。这就是为什么 TurboQuant 能说"零精度损失"而不是"近似零精度损失"。

第七部分：未来展望——这项技术走向何方

短期（2026 Q2-Q3）

代码开源和框架集成。 官方代码预计 Q2 发布。社区已经在 llama.cpp、MLX、Triton 上做实现。预计 Q3 会进入 vLLM、TensorRT-LLM 等主流推理框架。

在更大模型上验证。 70B、100B+ 规模模型上的实验数据将是采用的关键门槛。

中期（2026-2027）

与其他优化技术组合。 TurboQuant + 推测解码（Speculative Decoding）+ 稀疏注意力（Sparse Attention）的组合可能产生叠加效果，进一步释放 LLM 推理效率。

向量数据库原生支持。 Pinecone、Weaviate、Milvus 等向量数据库可能会原生集成 TurboQuant 或类似方法，提供开箱即用的极致压缩。

长期

重新定义 AI 硬件需求。 如果 3-bit KV 缓存成为标准，AI 推理芯片的设计逻辑可能需要调整——内存带宽 vs 计算能力的平衡点会发生变化。

推动端侧 AI。 当大模型的内存需求大幅降低，在手机、笔记本等端侧设备上运行有意义的 LLM 推理变得更加可行。

最后的话

我读完所有材料后最大的感受是：TurboQuant 的创新不在于"又一个量化方法"，而在于它从根本上改变了量化的成本结构。

传统量化是"用精度换内存"——压得越狠，精度越差。TurboQuant 通过数学手段消除了量化本身的开销，实现了"不用精度换内存"——至少在 KV 缓存这个场景下是这样。

这背后是两个漂亮的数学洞察：PolarQuant 的随机旋转把"数据相关的分布"变成了"数学已知的分布"；QJL 的无偏估计器实现了"用 1 bit 做零开销的误差修正"。两者结合，产生了一加一大于二的效果。

但冷静地看，它也确实有局限——只解决推理不解决训练，目前缺乏大规模验证，官方代码尚未发布，正确实现有一定工程门槛。

我的判断是：TurboQuant 本身可能不会直接改变世界，但它代表的方向——通过数学创新而非硬件堆砌来突破 AI 效率瓶颈——是确定性的趋势。 无论是 TurboQuant 还是它的后继者，KV 缓存压缩在 2026 年下半年进入生产级推理框架是大概率事件。

如果你在做 LLM 推理优化、向量数据库、或者端侧 AI，这是一个值得深入关注的方向。如果你是研究者，PolarQuant 的极坐标变换思路和 QJL 的无偏估计技术有很大的迁移空间——任何涉及高维向量压缩的场景都可能受益。

评论区聊聊？特别好奇已经在做推理优化的同学怎么看这个方案和 NVIDIA KVTC 的对比。

论文与资源

  • TurboQuant 论文：arxiv.org/abs/2504.19874（ICLR 2026）
  • PolarQuant 论文：arxiv.org/abs/2502.02617（AISTATS 2026）
  • QJL 论文：ACM DL（AAAI 2025）
  • 谷歌官方博客：research.google/blog/turboquant-redefining-ai-efficiency-with-extreme-compression
  • 社区实现追踪：llama.cpp Discussion #20969
  • 竞争方案参考：NVIDIA KVTC（ICLR 2026）——20x 压缩，需要校准
avatar
文章
阅读
粉丝