Google 最新极限压缩算法，砸碎大模型本地部署的内存墙，8 倍提升！

刚刚

Google 放了一个可能改变整个 LLM 推理格局的炸弹——TurboQuant

TurboQuant 把 KV Cache 从"最贵、最慢、最难优化的部件"变成了"几乎免费"的资源。

搞过大模型部署的人都知道，KV Cache 是推理阶段最大的内存杀手。

上下文越长，KV Cache 越膨胀，显存就越不够用。

之前的量化方案要么损失精度，要么引入额外的内存开销（存储量化常数），搞半天省不了多少。

TurboQuant 的恐怖之处在于：3 bit 量化 KV Cache，质量零损失，速度还更快。

TurboQuant 到底干了什么？

用人话讲，它做了两件事：

第一步：PolarQuant —— 换个坐标系看世界

传统量化就像用网格纸去描点——每个点都需要 X、Y、Z 坐标，每个坐标都得单独算一个缩放系数，这些缩放系数本身就要占内存（就是所谓的"量化开销"）。

PolarQuant 换了个思路：先把向量随机旋转一下，让数据分布变得非常集中、可预测，然后改用极坐标来描述。就像把"往东走 3 个路口，往北走 4 个路口"变成"朝 37 度方向走 5 步"。因为角度分布已知且高度集中，不再需要给每小块数据算缩放系数了——量化开销直接消失

第二步：QJL —— 1 bit 清理残差

第一步压完还有微小的误差怎么办？TurboQuant 只用 1 个 bit 做一个 Johnson-Lindenstrauss 变换，把残差误差中的偏差干掉，保证内积计算（也就是注意力分数）不会跑偏。

这两步加在一起，就是 TurboQuant 的核心：PolarQuant 吃大头 + QJL 擦屁股，零额外开销，接近信息论下界。

论文里证明了，TurboQuant 和理论最优只差一个约 2.7 倍的常数因子

实测数据有多炸？

Google 在 Gemma 和 Mistral 模型上，用 LongBench、Needle-in-a-Haystack、ZeroSCROLLS、RULER、L-Eval 等一堆长上下文基准做了全面测试。

下面是各方法在不同任务上的聚合性能得分对比（包括问答、代码生成、摘要等任务）：

Needle-in-a-Haystack 测试结果（在海量文本中找一根针）：

TurboQuant 在所有基准上都实现了完美分数，同时将 KV 内存缩小了至少 6 倍。

再看速度——H100 上 4-bit TurboQuant 计算注意力的速度比原始 32-bit Key 快了 8 倍：

• 同样的 GPU，能跑 6 倍以上的并发用户
• 上下文长度直接拉到 6 倍（长上下文基准全部零损失）
• H100 上端到端吞吐量暴涨
• 无需重训、无需微调，直接套在现有 Llama、Gemma、Qwen 等模型上就能用

社区已经炸锅了

社区已经开始疯狂复现：

mlx-vlm 上的 TurboQuant Metal kernel 实现：

mlx-audio & mlx-vlm 创建者 Prince_Canuma 使用 Qwen3.5-35B-A3B 在 8.5K、32.7K 和 64.2K 的上下文长度中进行“大海捞针”测试：

→ 每个量化级别都达到 6/6 完全匹配 → TurboQuant 2.5 位：KV 缓存缩小 4.9 倍 → TurboQuant 3.5 位：KV 缓存缩小 3.8 倍

最棒的是：与完整 KV 缓存相比，准确率没有损失。

他在 mlx-vlm  PR #858 里提交了 TurboQuant 的 Metal kernel 实现，包括：

• _mse_score_kernel、_pack_lowbit_kernel、_unpack_lowbit_kernel —— 基础量化/反量化
• _qjl_score_kernel、_prod_score_kernel —— QJL 残差纠偏和内积计算
• _polar_prod_score_kernel、_polar_turbo_score_repeat_kernel —— 4-bit PolarQuant 路径
• 多头处理优化 kernel：_prod_score_multi_kernel、_mse_weighted_rot_multi_kernel

MLX 上的 TurboQuant kernel 已经把解码速度追到了全精度的 **85-70%**（8K prompt 下 54 tok/s vs 62.5 tok/s），还在继续优化。

这意味着 Mac 用户很快就能在本地吃到这个红利

llama.cpp 集成：TurboQuant+ 已经跑通 Apple Silicon

开发者 TheTom 做了一个叫 turboquant_plus 的项目，直接把 TurboQuant 移植到了 llama.cpp，用 Metal kernel 在 Apple Silicon 上跑通了端到端推理。

M5 Max 128GB 上的实测：

4.6 倍压缩，速度还比 q8_0 快了一丢丢，PPL 只涨了 0.8%。

这就是所谓的"三赢"：压得狠、跑得快、质量几乎不掉。

实际使用也很简单，编译好他的 llama.cpp fork 之后：

# 用 TurboQuant 3-bit KV Cache 跑推理
./build/bin/llama-server \
  -m models/your-model.gguf \
  --cache-type-k turbo3 --cache-type-v turbo3 \
  -ngl 99 -c 262144 -fa on \
  --host 0.0.0.0 --port 8080

两个参数 --cache-type-k turbo3 --cache-type-v turbo3 就搞定了，其他什么都不用改。而且他在 Qwen 3.5 35B-A3B MoE 模型上验证过，2K 到 32K 各种上下文长度，速度都稳定在 q8_0 的 99% 左右。

这哥们还在做 TurboQuant+ 扩展，包括自适应 bit 分配、时序衰减压缩、MoE 感知压缩等，后续更值得期待。

vLLM 集成也来了：

开发者 Mitko Vasilev（@iotcoi）已经在 vLLM 上实现了 TurboQuant。

他在 USB 充电器大小的 HP ZGX 设备上，GB10 显卡跑出了 4,083,072 个 KV-cache tokens。

是的，你没看错，400 万 tokens 的 KV Cache。

他已经提交了 PR 估计合并需要时间。

这意味着什么？

说实话，我个人觉得这是 2026 年目前为止 LLM 推理领域最重要的进展，意义堪比当年 FlashAttention 把注意力从 O(n²) 优化成近似线性。

对开发者：

• 同样的显卡跑更大模型、更长上下文，成本暴降
• 无需重训、无需微调，部署门槛极低——pip install 完事

对 Mac 用户：

• 16GB Mac Mini 的可用模型范围直接扩大一圈
• MLX kernel 已经在路上，本地推理速度越来越接近全精度

对云厂商：

• 这是基础设施层的一次降维打击
• 推理成本下降意味着 API 降价，意味着更多应用能跑起来

对整个 AI 生态：

• 大家卷参数、卷 MoE、卷长上下文的时候，TurboQuant 直接把"硬件限制"这个天花板往上抬了一大截
• 训练是一次性的炫技，推理才是永远的账单。TurboQuant 直接把这个账单砍了一刀

更值得尊敬的是，Google 选择了完全开放这项研究。

论文发了、代码路径清晰、社区可以自由复现。

他们完全可以把这个捂在 Gemini 里独享，但他们没有。

#TurboQuant #量化 #KVCache #推理优化 #Google