Google TurboQuant：3 比特压缩零精度损失，大模型推理内存的"Pied Piper 时刻"

6 倍。

这是 Google 最新发布的 TurboQuant 算法对大模型 KV Cache 内存的压缩比。作为参考，JPEG 对原始图片的压缩比大约是 10 倍，而 ZIP 对文本文件的压缩比通常只有 2-3 倍。

更离谱的是——零精度损失。不是"几乎没有损失"，不是"可以接受的损失"，而是在 LongBench、Needle-In-Haystack 等主流基准上，压缩前后的表现完全一样。

难怪 TechCrunch 发文时，互联网上的第一反应是把它比作《硅谷》里的 Pied Piper——那个虚构的、用"中间压缩"改变世界的创业公司。区别在于，Pied Piper 是编剧写的，TurboQuant 是真的。

但等等，一个压缩算法，为什么会让 NVIDIA 的股票都跟着抖了一下？要理解这件事的分量，你得先明白一个大多数人忽略的事实：大模型推理最大的瓶颈，不是算力，而是内存。

KV Cache 为什么是大模型推理的"隐形杀手"？

你可能听过一个说法：跑大模型需要很贵的 GPU，因为大模型的"计算量"太大了。

这个说法对了一半。训练阶段确实是算力密集的。但到了推理阶段——也就是模型真正为你服务、一个 token 一个 token 往外吐的时候——瓶颈悄悄换了。

不是算不过来，是装不下。

打个比方。你去图书馆写论文。查阅资料的速度（算力）很快，翻一本书只需要几秒。但你面前的桌子（内存）只有一张学生课桌那么大。你必须把翻过的每一页的笔记都摊在桌上，因为随时可能要回头看。

论文写得越长，笔记摊得越多，桌子就越不够用。到后来，你大部分时间不是在查资料，而是在搬笔记——把旧的挪走，给新的腾地方。

这就是 KV Cache 的困境。

数据说话

LLaMA-2 13B 模型，每生成一个 token 就需要占用约 1MB 的 KV Cache。一段 4K token 的对话，光 KV Cache 就要吃掉约 4GB 显存——差不多是模型自身参数占用的大小。如果上下文窗口拉到 128K？你算算。

KV Cache 是什么？简单说，Transformer 模型在生成每个新 token 时，需要"回忆"之前所有 token 的信息。为了避免重复计算，模型会把之前每层注意力的 Key 和 Value 向量缓存下来。这就是 KV Cache——大模型的"短期记忆"。

问题在于，这个"记忆"是以全精度（通常是 FP16，每个数字 16 bit）存储的。对话越长，记忆越多，显存消耗就像滚雪球一样失控。

这导致了一个反直觉的现象：在生产环境中，决定你能同时服务多少用户、能支持多长上下文的，往往不是 GPU 的算力，而是 GPU 的显存。

所以当 Google 说"我们能把 KV Cache 从 16 bit 压到 3 bit，还不损失精度"的时候，这不是一个学术论文级别的改进。这是在说：同一块 GPU，能装下 5 倍多的用户对话，或者支持 5 倍长的上下文。

大模型推理的真正战场，从来不在 FLOPS 里，而在每一个 byte 的显存里。

TurboQuant 到底做了什么？

TurboQuant 的核心思路，用一句话概括：两步走，先大刀阔斧，再精雕细琢。

想象你要把一张高清照片发给朋友。你不会直接发原图——太大了。你会先用 JPEG 压缩，把文件缩小 10 倍。但 JPEG 压缩会引入一些模糊。如果你对画质很挑剔，你可能会再加一步"锐化"，把模糊的边缘补回来。

TurboQuant 干的就是这个：

第一步：PolarQuant——大刀阔斧的主压缩。它承担了绝大部分的压缩工作，把向量从 16 bit 压到约 3-4 bit。
第二步：QJL（Quantized Johnson-Lindenstrauss）——精雕细琢的纠错。它只用 1 bit 来修正第一步引入的偏差，几乎不占额外空间。

TurboQuant 两阶段压缩流程

这个两步架构有一个非常精巧的设计：两步是解耦的。PolarQuant 和 QJL 各自独立工作，你可以只用 PolarQuant（更快但精度略低），也可以两步都用（更慢一点但精度完美）。这种灵活性在工程部署中价值巨大。

但更让人惊讶的是它的三个"不需要"：

不需要重新训练模型——即插即用
不需要校准数据集——对数据完全"无感知"（data-oblivious）
不需要修改模型架构——纯粹的推理时压缩

这意味着什么？意味着你今天下午就可以把它用在任何一个现有的大模型上，不需要改一行训练代码。

听起来太美好了？那我们拆开看看，这"魔法"到底是怎么变的。

PolarQuant：为什么要把坐标系"掰弯"？

要理解 PolarQuant 的精妙之处，你得先知道传统量化方法的痛点。

传统向量量化（比如 GPTQ、AWQ）的基本思路是：把一组浮点数分成小块（block），每块找一个缩放因子（scale factor），然后把每个数除以这个缩放因子，四舍五入成整数。解压时再乘回来。

问题出在这个"缩放因子"上。每一个 block 都要存一个缩放因子，这是额外的存储开销。当你把数据压到极低比特（比如 3 bit 以下）时，这些"额外开销"占总数据量的比例变得越来越大——就像你买了一个很小的行李箱，结果锁头和拉杆占了箱子三分之一的重量。

Google 的研究者想到了一个绝妙的解法：换一个坐标系。

打个比方。你在城市里给朋友指路，传统的方式是说"往东走 3 个路口，往北走 4 个路口"——这就是直角坐标系（笛卡尔坐标系）。每次指路都要说两个数字，还得标明东西南北。

PolarQuant 的方式是说"朝东北方向走 5 个路口"——这就是极坐标。方向确定了，只需要说一个距离就行。

传统量化 vs PolarQuant：坐标系转换消除缩放因子开销

具体来说，PolarQuant 做了三件事：

配对转换：把 d 维向量中的坐标两两配对（x₁, x₂），映射成极坐标（r, θ），得到一个半径和一个角度
递归折叠：对产生的半径再次两两配对、再次转换……如此递归，最终整个向量变成一个"总半径"加一组"角度"
利用分布规律：关键洞察来了——经过随机旋转后，这些角度的分布变得非常集中、可预测。既然分布已知，就不需要存额外的缩放因子了

这就是 PolarQuant 的核心魔法：通过换坐标系，把"每个 block 都不一样"的数据分布，变成了"全局可预测"的分布，从而彻底消除了缩放因子的存储开销。

常见误解

很多人以为"极坐标转换"只是一个数学技巧，实际效果存疑。但 PolarQuant 的论文（即将在 AISTATS 2026 发表）给出了严格的数学证明：在高维空间中，随机旋转后的角度分布收敛到已知分布，这不是近似，是定理。这也是为什么它能做到"零精度损失"而非"几乎零损失"。

但任何量化都会引入误差——哪怕极小。当这些极小的误差在注意力计算中被累积和放大时，就可能影响输出质量。

PolarQuant 已经把误差压得很小了，但 Google 显然是个完美主义者。于是就有了第二步。

QJL：1 比特纠错，凭什么管用？

这可能是整个 TurboQuant 体系中最反直觉的部分。

你可能会问：1 个 bit 能干什么？一个 bit 只能表示 0 或 1，是或否，正或负。用 1 bit 来纠正压缩误差？这听起来就像用一根牙签加固一栋大楼。

但 QJL 的思路完全不同。它不是在修复每一个被压缩的数字，而是在修复最终的计算结果。

让我用一个例子来解释。

假设你是一个班级的老师，要统计全班 50 个人的考试成绩总分。每个学生的成绩你都做了四舍五入（量化）。有人被多算了 0.3 分，有人被少算了 0.2 分。如果这些舍入误差是随机的，你可能觉得它们会自己抵消——偏高的和偏低的差不多。

但实际情况是：量化误差往往不是随机的，它有系统性的偏差（bias）。如果你的四舍五入规则倾向于往上凑，那 50 个学生加起来，总分可能被系统性地高估了十几分。

QJL 干的事情就是：它不去修正每个学生的分数，而是算出这个系统性偏差，然后一次性从总分里减掉。

技术上，QJL 的全名是 Quantized Johnson-Lindenstrauss。Johnson-Lindenstrauss 是一个经典的数学定理，说的是：高维空间中的向量，可以被随机投影到低维空间，同时保持向量间的距离关系。QJL 利用这个原理，把量化残差（也就是压缩造成的误差向量）投影到一个低维空间，然后只保留每个维度的符号位（+1 或 -1）。

关键在最后一步：QJL 设计了一个特殊的估计器（estimator），能够利用这些符号位来修正注意力分数中的系统性偏差。数学上可以证明，这个修正是无偏的——也就是说，修正后的结果在期望上等于真实值。

insider 视角

QJL 最初作为独立论文发表（arXiv:2406.03482），当时的定位是"注意力计算的近似加速方法"。Google 的研究者后来发现，把 QJL 和 PolarQuant 组合起来，效果远超两者之和——PolarQuant 把大部分误差消除了，QJL 只需要处理极小的残差，所以 1 bit 就够了。这种 1+1 > 2 的组合，是 TurboQuant 最聪明的地方。

所以总结一下：PolarQuant 是"换一种方式记笔记，让笔记本更小"，QJL 是"用一根红线标记哪些笔记有偏差，算总账时一次性校正"。

一个负责压缩，一个负责兜底。缺一不可，但各自独立。

理论说了一大堆，实际效果到底怎么样？让数据来说话。

实测数据说了什么？

Google 在 Gemma 和 Mistral 两个模型家族上做了全面测试，覆盖了 5 个主流长文本基准。我知道你不想看一堆表格，所以我挑三个最有说服力的数字：

第一个数字：6×

KV Cache 内存压缩比。原来一段 4K 对话要吃掉 4GB 显存的 KV Cache，现在只需要不到 700MB。同一块 H100（80GB 显存），能同时服务的用户数直接翻了好几倍。

第二个数字：8×

注意力计算加速比。在 H100 GPU 上，4-bit TurboQuant 计算注意力 logits 的速度是 32-bit 未量化版本的 8 倍。注意，这不是理论值，是实测 kernel benchmark。

第三个数字：100%

Needle-In-Haystack 测试的准确率——在长文本中找一根"针"，压缩前后的表现完全一致。这个测试之所以重要，是因为它对 KV Cache 的质量极其敏感。如果压缩损失了哪怕一点信息，模型就可能"忘记"文本中间的某个关键细节。TurboQuant 通过了这个考验。

指标	未压缩（FP16）	TurboQuant（3-bit）
KV Cache 大小	1×（基准）	≈ 0.17×（6 倍压缩）
注意力计算速度（H100）	1×（基准）	最高 8× 加速
Needle-In-Haystack	100%	100%
是否需要重训练	—	否（即插即用）
是否需要校准数据	—	否（data-oblivious）

但我认为，比这些数字更值得关注的是一个"软指标"：社区反应速度。

Google 的论文最初在 2025 年 4 月发到 arXiv，当时还没有引起太大关注。本周 Google Research 博客正式发文，配合 ICLR 2026（下月开幕）的展示。结果呢？尽管 Google 还没有发布官方代码，独立开发者已经在 Triton、MLX 和 llama.cpp 上做出了可工作的实现。

当一个算法让社区在没有官方代码的情况下就争相复现，说明它击中了真实的痛点。

延伸思考

TurboQuant 的 "data-oblivious"（数据无关）特性可能是它最被低估的优势。大多数量化方法（如 GPTQ、AWQ）需要一个校准数据集来确定最优量化参数，这意味着你需要为每个场景准备合适的校准数据，一旦数据分布变了就得重新校准。TurboQuant 完全不需要——它的数学保证对任意数据分布成立。这让部署从"工程项目"变成了"换一个 flag"。

不过，有一点必须诚实地说：TurboQuant 目前还是一个实验室成果。Google 自己也强调，从论文到生产部署之间还有距离。但方向已经非常清晰了。

这对你意味着什么？

如果你只是一个 AI 应用开发者，你可能觉得"内存压缩"离自己很远。但让我换一种方式说：

TurboQuant 解决的不是 Google 的问题，是你的钱包的问题。

今天，调用大模型 API 的定价逻辑里，有一个隐藏的成本因子：上下文长度。你发送的上下文越长，服务端需要维护的 KV Cache 越大，显存占用越多，能同时服务的用户越少，于是长上下文 API 价格就更贵。

当 KV Cache 的内存占用降低 6 倍，这意味着：

API 提供商的服务成本大幅下降（VentureBeat 估计降幅超过 50%）
同一块 GPU 能支持更长的上下文窗口
本地部署大模型的硬件门槛进一步降低

还有一个更深层的影响。目前大模型推理的架构里，KV Cache 的大小直接决定了上下文窗口的上限。当压缩算法把这个限制放宽 6 倍，之前"128K 上下文就是极限"的认知可能会被改写。想象一下 768K 甚至 1M token 的上下文窗口——不是靠堆更大的 GPU，而是靠更聪明的压缩。

所以我做两个预测，给自己设个 deadline：

预测一：2026 年底之前，主流推理框架（vLLM、TensorRT-LLM、llama.cpp）将原生集成 TurboQuant 或其变体。社区已经在自发复现了，官方集成只是时间问题。

预测二：2027 年上半年，至少一家头部 API 提供商会因为类似技术的部署，将长上下文 API 价格下调 30% 以上。当推理成本结构性下降，价格战只会来得更快。

半年后回来看看，我说得对不对。

有一件事是确定的：大模型的下一场军备竞赛，不在参数量上，不在训练数据上，而在推理效率上。谁能用更少的内存、更低的成本、更快的速度跑同样质量的模型，谁就赢了。

TurboQuant 不是终点，但它标记了一个起点：大模型行业正式进入"压缩即竞争力"的时代。