TurboQuant+ 深度解析：当前 Google 工程师决定单挑大厂

参考对象：Paul Graham 的散文风格（简洁有力）+ 费曼的物理直觉（把复杂概念讲得像邻里闲聊）

引子：一个荒诞的开局

2026 年 3 月 24 日，Google Research 发布了一篇论文，标题平淡无奇：《TurboQuant: Redefining AI Efficiency with Extreme Compression》。但内容却像一颗深水炸弹——他们把大模型推理时的 KV 缓存压缩到了 3 比特，内存占用砍到六分之一，速度提升 8 倍，而且号称"零精度损失"。

消息传开的 48 小时内，全球内存芯片板块蒸发数十亿美元。Micron、SK Hynix 的股价像断了线的风筝。

但 Google 没发任何代码。

"论文在这里，原理讲清楚了，你们自己玩吧。"

Tom Turney 看到这条新闻时，正坐在自己的公寓里。他刚离开工作了 13 年的 Google，LinkedIn 上写着"独立研究者"。他盯着那篇论文，脑子里只有一个念头：

**"这玩意儿要是真的，应该在每台 MacBook 上都能跑。"

三天后，他开源了 turboquant_plus。六天后，这个项目有 1274 个 star。第七天，你能在 M5 Max 上跑 104B 参数的模型，上下文拉到 128K，内存占用比原来还少。

而这一切，是"他"和 Claude Code 一起完成的——Tom 在推特上特意说明："当我说'我'的时候，实际上是和 Claude Code 以及 Codex 一起，主要工作是大量的引导和看护（steering and babysitting）。"

这不是一个"AI 会不会取代程序员"的故事。这是一个"一个人加上 AI，能干翻多少传统假设"的故事。

第一部分：KV 缓存——大模型的"记忆重担"

要理解 TurboQuant 为什么重要，你得先理解大模型推理时的内存黑洞。

想象你正在读一本厚书，每读一页，你就得把前面所有页的内容记在脑子里，否则没法理解上下文。Transformer 模型就是这样——它用注意力机制来"回顾"之前看过的所有 token。为了不用每次都重新计算，它把之前算好的 "Key" 和 "Value" 向量存起来，这叫 KV 缓存。

问题是，这个缓存随着上下文长度线性增长。

读 1000 个 token？缓存很小。读 10 万个 token？缓存可能吃掉几十 GB 显存。现在的旗舰模型支持百万 token 上下文，KV 缓存成了最大的瓶颈——不是算力不够，是内存装不下，带宽跟不上。

传统解决方案是量化：把 16 位浮点数压缩到 8 位、4 位，甚至更低。但量化是有代价的——压缩太狠，模型就开始"说胡话"。

Google 的 TurboQuant 宣称突破了这条 trade-off 曲线：3 比特，6 倍压缩，零损失。

第二部分：PolarQuant 的直觉——为什么方向比大小更重要？

TurboQuant 的核心是一个叫 PolarQuant 的算法。Tom 在论文里看到了一个漂亮的数学直觉：

在注意力计算中，向量的"方向"比"大小"重要得多。

想象你在导航。你知道目标在东边 5 公里——"东边"是方向，"5 公里"是距离。如果我把距离改成 4.8 公里，你大概还能找到地方；但如果我把方向搞错 30 度，你就完全跑偏了。

注意力机制本质上是计算向量之间的点积，而点积 = 方向相似度 × 大小乘积。

PolarQuant 的做法是：把笛卡尔坐标 (x, y) 转换成极坐标 (角度 θ, 半径 r)。然后对半径狠狠压缩（反正它不那么重要），对角度精心保护。

更妙的是，他们还加了一个 Walsh-Hadamard 变换——这是一种旋转矩阵，能把向量的各个维度"打散"，让原本分布不均的数值变得像高斯分布一样均匀。均匀了，量化误差就小了。

Tom 读到这一段时，眼睛亮了。这不仅是工程技巧，这是几何直觉的胜利。

第三部分：Day 1 的马拉松——90 个 commits 与一行 include 的诅咒

Tom 决定从头实现这个算法。不是用 PyTorch 随便糊个 demo，而是集成进 llama.cpp——那个让大模型能在笔记本上跑的开源推理引擎。

Day 1 是疯狂的。90 个 commits，从早上干到深夜。他说那是"马拉松日"。

傍晚时分，第一个 Metal GPU 内核跑起来了。Tom 满怀期待地按下回车，结果：2.4 tokens/秒。

正常情况下，M5 Max 应该能跑到 85.5 tok/s。2.4？这比 CPU 还慢。

他调试了几个小时，最后发现问题出在一行 include 上。那行代码让 Metal 编译器静默回退到了 CPU 模式——没有任何报错，程序"看起来"在跑 GPU，实际上在软绵绵地转圈圈。

修复后，速度飙到 51.4 tok/s。但他还没来得及高兴，又一个打击来了：PPL = 165.6。

PPL（困惑度）是衡量模型输出质量的指标。正常值应该在 6-8 左右。165.6 意味着模型在说胡话——不是稍微有点错，是完全乱码。

Tom 后来在文档里自嘲："速度 benchmark 测的是模型说胡话有多快。"

这是第一天的结尾：有速度，没质量。但他已经踩过了最深的坑——他知道问题不在算法，而在实现细节。

第四部分：36 小时跑通——从胡话到 poetry

Day 2 和 Day 3，Tom 专注于修复那些"胡话"。

他发现，PolarQuant 的旋转步骤需要极高的数值精度。在 Python 里用 float64 算没问题，但在 GPU 上用 fp16 算，累积误差会让模型崩溃。他花了大量时间调整中间值的精度，在速度和正确性之间走钢丝。

36 小时后，第一个完整的端到端测试通过：

• 压缩率：4.6 倍（turbo3）
• PPL：6.176，相比 q8_0 基线的 6.111，只高了 1.06%
• 速度：接近 q8_0 的预填充速度

模型不再说胡话了。它在写诗、写代码、回答问题——和全精度版本几乎看不出区别。

Tom 把代码 push 到 GitHub，然后开始写 Metal GPU 内核的优化版本。

第五部分：超越论文——Sparse V 与三个意外发现

Tom 没有止步于"复现论文"。在把算法塞进 llama.cpp 的过程中，他发现了三个原论文没提到的现象：

发现一：V 压缩是"免费"的

TurboQuant 对 Key 和 Value 缓存做对称压缩。但 Tom 发现：Value 向量可以被压缩得更狠，而几乎不影响质量。

他的解释是：注意力机制中，Key 决定了"看哪里"（路由），Value 决定了"拿什么信息"。路由错了，后面全错；但 Value 稍微模糊一点，问题不大。

基于这个发现，他实现了非对称 K/V 压缩：Key 保持 q8_0（8 位），Value 用 turbo3（3 位）。这样既能拯救那些对量化敏感的模型，又能获得大部分内存收益。

发现二：所有质量损失都来自 K 压缩

进一步实验验证了上面的直觉。Tom 发现，当你用低精度压缩 Key 时，注意力路由会乱套，模型开始"走神"。但如果只压缩 Value，即使压到 2 位，质量也几乎不变。

这解释了为什么有些模型用 TurboQuant 表现很好，有些却崩了——取决于模型本身对 Key 精度的敏感度。

发现三：边界层特别脆弱

Tom 还发现，Transformer 的第一层和最后几层对量化最敏感。中间层可以随便压，但边界层需要"温柔对待"。

他实现了 Boundary V（边界层保护）：前 2 层和后 2 层的 Value 缓存用 q8_0，中间层用 turbo2。15 行代码，没有速度损失，但能恢复 37-91% 的质量损失。

第六部分：Sparse V Dequant——22.8% 的加速礼物

Tom 最大的原创贡献是 Sparse V Dequant（稀疏 Value 反量化）。

这个想法来自对注意力权重的观察：在 long context（比如 32K token）时，模型对每个新 token 的注意力分布是极度稀疏的——绝大多数位置的注意力权重接近于零（< 1e-6）。

既然这些位置的贡献微乎其微，为什么还要花时间把它们从压缩格式解压出来？

Sparse V 的做法是：在解码阶段，先用注意力权重当"门控"，跳过那些低权重的 Value 向量的解压步骤。

结果令人震惊：

• 32K 上下文下的解码速度提升 22.8%
• 困惑度零变化（50 个 chunk 验证，CI ±0.021）
• 不止对 TurboQuant 有效，对 q8_0、q4_0 也有效

这是一个跨格式的通用优化。Tom 说："这不是 TurboQuant 的 trick，这是注意力机制的固有特性。"

更令人惊讶的是 Needle-in-a-Haystack（大海捞针）测试结果：开启 Sparse V 后，单针检索从 7/9 提升到 9/9（100%）。多键检索在 32K 上下文中达到 100% 通过。

Tom 推测，这可能是因为跳过低权重量化噪声反而起到了"去噪"效果。

第七部分：7 天时间表——一场与时间的赛跑

让我们看看这 7 天是怎么分配的：

最终成果：

• 511+ Python 测试，100% 覆盖率
• C 语言移植 集成 llama.cpp
• Metal GPU 内核 支持 Apple Silicon M1-M5
• 社区验证：CUDA（RTX 3080/3090/4090/5090）、AMD（RX 9070 XT）
• 速度：从初始 739 tok/s 优化到 2747 tok/s，3.7 倍提升，与 q8_0 持平

第八部分：性能全景——数字背后的故事

压缩与质量

turbo4 的质量比 q8_0 还好（PPL 6.125 vs 6.111，差异微乎其微，实际上在误差范围内）。这是 PolarQuant 的胜利——几何直觉打败了粗暴量化。

大模型压力测试（M5 Max 128GB）

**104B 模型，128K 上下文，在 MacBook 上跑。**这在一个月前还是天方夜谭。

Sparse V 的魔法

Qwen3.5-35B-A3B（MoE）在 32K 上下文下的解码速度：

开启 Sparse V 后，长上下文解码速度反超 q8_0。

第九部分：意义与启示——一个人+AI=？

Tom Turney 的项目最动人的地方，不是技术细节，而是它展示了一种新的工程范式。

启示一：AI 是杠杆，不是替代

Tom 没有让 Claude Code "替他写代码"。他做的是：

• 读论文，理解核心数学直觉
• 设计架构，决定哪里用 Python 验证，哪里用 C 实现
• 诊断问题（那行该死的 include）
• 判断方向（为什么 PPL 这么高？精度问题还是算法问题？）

Claude Code 是他的执行器和对话伙伴。他提出问题，AI 生成候选代码，他验证、调整、再提问。

这是一种人机协作的化学反应——人的直觉 + AI 的生成能力 = 超越两者单独工作的产出。

启示二：大厂发论文，小团队实现商业化

Google 有成千上万的工程师，但 TurboQuant 的代码——如果他们会发的话——可能要等几个月，要经过无数内部评审、合规检查、政治博弈。

Tom 一个人，7 天。

这不是说 Google 的工程师不行。这是说，小团队的迭代速度可以碾压大组织的官僚惯性。

当 AI 辅助编程把"实现一个算法"的时间从几周压缩到几天，快速行动的优势被放大了十倍。

启示三：开源社区的力量

turboquant_plus 不是 Tom 一个人的作品。从 Day 3 开始，社区就涌入：

• <span class="mention-invalid">@sztlink</span> 在 RTX 4090 上验证 CUDA 路径
• <span class="mention-invalid">@HyperionMS2040</span> 在 RTX 3090 上跑通
• <span class="mention-invalid">@Corianas_</span> 独立验证 Boundary V 在 NanoGPT 上的效果
• AMD RX 9070 XT 的支持来自社区成员

6 天，174 commits，1274 stars，30+ 测试者横跨 M1/M2/M3/M5 Mac、NVIDIA、AMD。

这就是开源的恐怖之处——一旦种子播下，它会以指数速度生长。

启示四："超越论文"成为常态

Tom 不仅复现了论文，还做出了 Sparse V、Asymmetric K/V、Boundary V、Temporal Decay 等原论文没有的优化。

这种现象会越来越普遍。当实现成本降低，每个工程师都可以是研究者——你可以边实现边实验，边跑分边发现新现象。

论文不再是终点，而是起点。

尾声：当我们在谈论 TurboQuant+ 时，我们在谈论什么

我们谈论的不是一个 KV 缓存压缩算法。

我们谈论的是一个人决定单挑大厂，并且赢了的故事。

我们谈论的是AI 如何成为工程杠杆，让个体突破组织的边界。

我们谈论的是开源社区如何在 7 天内，把一篇论文变成可以在笔记本上跑 104B 模型的生产工具。

Tom Turney 在他的 README 里写了一段话：

"如果单独的模块证明有用且稳定，目标是逐步将它们 upstream 到 llama.cpp，作为小的、可审查的补丁。"

这是一种谦逊的野心。他不想要一个独立王国，他想要推动整个生态前进。

1274 个 star 是社区给他的回应。而那些在 M5 Max 上跑 128K 上下文的开发者，是这个故事的真正主角——他们用上了一个人+AI 在 7 天内创造的奇迹。

参考链接

• Tom Turney 的 GitHub: https://github.com/TheTom/turboquant_plus
• turboquant_plus 项目: https://github.com/TheTom/turboquant_plus
• llama.cpp fork: https://github.com/TheTom/llama-cpp-turboquant
• Tom 的推特: <span class="mention-invalid">@no_stp_on_snek</span>
• TurboQuant 论文: arXiv:2504.19874 (ICLR 2026)
• PolarQuant 论文: arXiv:2502.02617 (AISTATS 2026)
• Google Research Blog: TurboQuant: Redefining AI Efficiency

后记：那行 include 教会我的事

在写完这篇文章后，我又回头看了 Tom 的 Day 1 日志。那行让 Metal 编译器静默回退到 CPU 的 include，让我想起自己踩过的无数类似的坑。

工程不是关于大突破，而是关于小细节。

一个错误的 include、一个精度不足的中间变量、一个边界条件的疏忽——这些才是区分"能跑"和"能跑好"的东西。

Tom 用 7 天证明了：AI 可以帮你写代码，但判断代码对不对、为什么不对、怎么修——这些还需要人。

至少现在还需要。

写于 2026 年 4 月 5 日，参考 Tom Turney 的 turboquant_plus 项目文档与社区讨论。