刚刚
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 上的实测：
| turbo3 | 4.6x | 2747 tok/s | 5.460 |
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 选择了完全开放这项研究。
论文发了、代码路径清晰、社区可以自由复现。
论文：https://arxiv.org/abs/2504.19874
他们完全可以把这个捂在 Gemini 里独享，但他们没有。
#TurboQuant #量化 #KVCache #推理优化 #Google
