Google TurboQuant：把大模型内存占用最高降 6 倍，质量几乎不掉

大模型越来越强，但它们有个老问题一直没变：太吃内存。
尤其是在长上下文推理里，KV Cache 会越堆越大，最后把显存和成本一起顶上去。也正因为这样，量化、压缩、缓存优化这些词，最近越来越像大模型工程里的硬需求，而不是“有空再做”的附加项。

Google Research 在 2026 年 3 月 24 日 发布了一篇技术博客，介绍新的压缩算法 TurboQuant。一天后的 2026 年 3 月 25 日，Ars Technica 也跟进做了报道。简单说，TurboQuant 想解决的问题就是：把大模型推理里的内存占用压下来，同时尽量不牺牲输出质量。

如果只看结果，最吸引人的数字有两个：

在部分测试里，KV Cache 内存占用最多可降低 6 倍
在 H100 上，4-bit TurboQuant 的 attention logits 计算速度最高可提升 8 倍

TurboQuant 到底在压什么？

它主要针对的是 KV Cache。

KV Cache 可以理解成模型推理时的“速记本”或“临时备忘录”。模型已经算过的 key 和 value 会先存起来，后面生成新 token 时就不用每次都从头重算。这个机制对长上下文非常重要，但代价也很明显：上下文越长，缓存越大，显存压力也越大。

Google 的思路不是简单粗暴地把精度直接砍低，而是试图用一种更聪明的量化方式，把高维向量压缩得更小，同时尽量保留它们的结构信息。因为一旦向量被压得太狠，模型对上下文关系的判断就会变差，最终反映到回答质量、检索能力和生成稳定性上。

它是怎么做到的？

按 Google 的介绍，TurboQuant 可以理解成一个两阶段方案。

第一步是 PolarQuant。
它会先对向量做随机旋转，然后把原本常见的直角坐标表达，换成更紧凑的极坐标表达。你可以把它理解成，从“向东走几格、向北走几格”，改成“朝某个方向走多远”。这样做的好处是，向量能被更高效地压缩，而且还能减少传统量化方法里额外的内存开销。

第二步是 QJL（Quantized Johnson-Lindenstrauss）。
这一步更像是一个误差修正层。PolarQuant 已经做了大部分压缩，但压缩之后总会有一点残余误差。QJL 用额外很少的位数去修这部分偏差，让最终 attention score 的估计更稳，不至于因为量化而把模型判断带偏。

如果把它说得更直白一点，TurboQuant 的目标不是“把数据压小就行”，而是“压小之后，模型还能大体像原来那样工作”。

为什么这件事值得关注？

因为大模型的很多现实问题，本质上都和内存有关。

模型跑不起来，不一定是算力不够，很多时候是缓存太大；
上下文开不上去，不一定是架构不行，很多时候是显存装不下；
边缘设备和手机端难做，不一定是模型能力不够，而是本地资源太紧张。

如果 TurboQuant 真的能稳定落地，它的意义就不只是“某个论文数字很好看”，而可能直接影响：

长上下文推理成本
单卡或小显存设备的可用性
本地端侧 AI 的质量上限
向量检索和近邻搜索这类高维计算场景

Google 在官方博客里还特别提到，这套方法不只适合 KV Cache，也适合向量搜索。换句话说，它不只是 LLM 推理优化工具，也可能影响搜索、召回和语义检索这类底层系统。

目前公开的数据大概怎么样？

根据 Google Research 博客和论文摘要里公开的信息，TurboQuant 的亮点主要有这些：

在 Gemma 和 Mistral 等开源模型的长上下文测试中，表现接近无损
KV Cache 可以压到 3-bit 级别，而且不需要额外训练或微调
在一些基准中，KV Cache 内存占用可以减少到原来的 1/6
在 Nvidia H100 上，4-bit TurboQuant 的 attention logits 计算速度，相比 32-bit 未量化 keys，最高可达到 8 倍 提升

论文里还提到，它在最近邻搜索任务里也比一些现有量化方法有更好的 recall，同时索引构建时间几乎可以忽略。

当然，这里也要补一句：这些结果主要来自 Google 给出的论文、博客和基准测试。它说明这项技术很有潜力，但和“已经在所有生产环境里成熟部署”还不是一回事。真正落到不同框架、不同 GPU、不同模型结构上，效果通常还要继续看工程实现。

我对这项技术的简单理解

这类工作之所以重要，是因为它抓住了大模型落地里一个很现实的瓶颈：模型越来越大，但内存和带宽不会无限涨。

过去大家谈模型进展，更多盯着参数量、训练数据和 benchmark 分数；现在真正影响产品体验的，越来越是另一类问题：

一次推理到底要吃多少显存
长上下文到底能不能开得起
手机上能不能本地跑
同样一台机器能不能多跑几个并发

TurboQuant 这类方法的价值就在这里。它不是在“重新发明一个更强的大模型”，而是在想办法让现有模型更便宜、更轻、更容易部署。

不过它最终带来的结果，未必全都会变成“更省钱”。
现实里很可能会出现两种同时发生的情况：

一部分团队用它来降成本、降显存压力
另一部分团队把省出来的内存继续拿去跑更复杂的模型或更长的上下文

也就是说，这种优化不一定让 AI 立刻变便宜，但很可能会让 AI 系统的设计空间变大。

最后

如果只看标题，TurboQuant 很像又一个“模型压缩新方法”。
但它真正值得注意的地方，是它切中的问题非常现实：内存才是很多大模型场景里最先撞上的天花板。

Google 这次给出的方向很明确：不是单纯把模型做得更大，而是把高维向量和 KV Cache 这类真正烧资源的部分，压得更小、更快，而且尽量不伤质量。

如果后续工程化效果也能跟上，那这类技术对端侧 AI、长上下文推理和向量搜索都会很有价值。

参考链接

关于

关注我获取更多资讯

📢 公众号

💬 个人号