⚡ 压缩与速度的博弈——TurboQuant 和 RotorQuant 的真相

开场：一个反直觉的困惑

有个事儿我一直没搞清楚。

谷歌的 TurboQuant 论文说，他们能把大语言模型的 KV 缓存压缩 5 倍以上。这意味着什么？意味着你同样一块显卡，本来只能跑 10 万 token 的上下文，现在能跑 50 万 token。听起来很棒对吧？

但真用起来，很多人发现一件怪事：压缩之后，处理提示词的速度反而变慢了。

这就奇怪了。压缩不应该让数据变少吗？数据变少了，传输不是应该更快吗？就像你把一箱子书压缩成 zip 文件，拷贝到 U 盘里，按理说应该比拷 raw 文件快啊。

但 TurboQuant 在 Apple Silicon 的 Metal GPU 上，预填充速度只有 Q8_0 量化的 78%。也就是说，你花了更少的显存，却换来了更慢的速度。

然后呢？社区里冒出一堆新方法——RotorQuant、IsoQuant、PlanarQuant——宣称能解决 TurboQuant 的速度问题，而且说他们能让速度提升 9 到 31 倍。

9 到 31 倍。

这个数字让我警觉。不是因为我不相信，而是因为我见过太多「货物崇拜」了——形式到位了，飞机却不会来。

所以我想搞清楚几个问题：

1. 为什么压缩了反而变慢？
2. 那 9-31 倍的速度提升是真的吗？
3. 理论完美的算法，为什么在真实硬件上总是出问题？

这就是这篇文章要搞清楚的事。

---

第一章：KV 缓存到底是什么？

在聊 TurboQuant 之前，我们得先搞清楚 KV 缓存是什么，以及为什么它成了瓶颈。

从物理存储说起

想象你有一个非常大的仓库。这个仓库里放的不是货，而是记忆。

大语言模型（LLM）在生成文本的时候，有个特点：它是一字一字往外蹦的。你问它一个问题，它不是一下子把答案全想好了再告诉你，而是想一个字，说出来，然后基于已经说过的所有字，再想下一个字。

这意味着，为了让模型知道「前面说了什么」，我们需要把前面所有 token 的某种表示存起来。这就是 KV 缓存。

具体来说，每一层 transformer 都有两个东西：

• K（Key）：可以理解为「查询索引」，用来和当前要生成的 token 做匹配
• V（Value）：可以理解为「存储的内容」，匹配上了就拿出来用

对于每一个 token、每一层、每一个注意力头，我们都要存一个 K 向量和一个 V 向量。向量的维度通常是 64、128 或者更大。

算一笔账

假设我们有一个 70B 参数的模型，有 80 层，每层 8 个注意力头，每个头的维度是 128。

对于 32K token 的上下文：

• K 缓存：32K × 80 × 8 × 128 × 2 bytes (FP16) = 5.2 GB
• V 缓存：同样 5.2 GB
• 总共：10.4 GB

但这只是 KV 缓存。模型本身还有 70B 参数，如果是 Q4_K_M 量化，大概需要 40GB 左右。

所以，一块 48GB 显存的显卡，跑 70B 模型，32K 上下文，几乎要把显存撑爆了。

如果你想跑 128K 上下文？KV 缓存会变成 41.6 GB。不可能。

这就是问题的本质：内存墙。

模型参数可以通过量化压缩（比如用 4-bit 存权重），但 KV 缓存 traditionally 是用 FP16 存的。上下文越长，KV 缓存占用的内存就越多，最终成为瓶颈。

为什么压缩 KV 缓存这么难？

你可能想：那直接把 KV 缓存也量化成 4-bit 或者 8-bit 不就行了？

问题是，KV 缓存和模型权重不一样。

模型权重是 静态的。你可以 offline 花大量时间分析权重的分布，找到最优的量化参数，然后一劳永逸。

但 KV 缓存是动态的。每个用户的每次对话，KV 缓存的内容都不一样。而且是在线生成的——token 一个一个来，你不能等整个上下文都生成了再量化。

更麻烦的是，量化误差在 attention 计算中会累积和放大。

Attention 的核心计算是：

Attention(Q, K, V) = softmax(Q @ K.T / sqrt(d)) @ V

K 的量化误差会影响 Q@K.T 的结果，然后经过 softmax 的指数放大，再乘以 V。误差就这样一层一层传下去。

如果你用 naive 的量化方法（比如简单的线性量化），很快模型的输出就会变成 gibberish。

所以我们需要更聪明的量化方法。

---

第二章：TurboQuant 的洞察

谷歌的 TurboQuant（ICLR 2026）提出了一个核心洞察：旋转之后，世界变得更简单了。

从二维几何说起

想象你在一张纸上画了一堆点。这些点分布得很不均匀——有的方向很分散，有的方向很集中。

如果你直接在这些点上画网格，把每个点量化到最近的格子上，你会发现：在分散的方向上，很多点会被压缩到同一个格子，丢失大量信息；在集中的方向上，很多格子是空的，浪费存储空间。

但如果 先把这些点旋转一个随机角度 呢？

神奇的事情发生了：经过随机旋转后，这些点的分布趋向于 各向同性——也就是说，在各个方向上变得均匀了。

这就是 TurboQuant 的第一步：随机正交旋转。

Beta 分布的魔力

TurboQuant 的论文证明了一个数学事实：

对一个 d 维的单位向量做随机正交旋转，旋转后的每个坐标会服从 Beta(1/2, (d-1)/2) 分布。

当 d 很大时（比如 128），这个分布趋近于 N(0, 1/d)——也就是均值为 0、方差为 1/d 的正态分布。

这意味着什么？

意味着：

1. 旋转之后，所有坐标的分布变得可预测了——都是同一个正态分布
2. 不同坐标之间变得近似独立了
3. 我们可以对每个坐标单独做最优量化，而不需要考虑它们之间的相关性

这就是信息论中的「率失真理论」在起作用。当变量独立同分布时，标量量化就能接近最优的向量量化性能。

Lloyd-Max 最优量化

既然旋转后的坐标都服从 N(0, 1/d)，我们就可以预先计算出最优的标量量化器。

什么是「最优」？

给定一个分布和固定的比特数，最优量化器最小化均方误差（MSE）：

E[(X - Q(X))^2]

Lloyd-Max 算法是一个迭代算法：

1. 随机初始化一些量化中心（centroids）
2. 把输入分配到最近的中心（量化）
3. 重新计算每个区域的质心作为新的中心
4. 重复直到收敛

对于正态分布，我们可以 offline 跑好 Lloyd-Max 算法，把最优的 centroids 存下来。在线量化的时候，只需要查表就行了。

TurboQuant 论文给出了理论保证：这种旋转 + 标量量化的方法，其失真率（distortion rate）接近信息论下界，只差一个约 2.7 倍的常数因子。

这很漂亮 。从数学上看，TurboQuant 解决了在线向量量化的核心问题。

第二阶段：QJL 残差校正

但 TurboQuant 没有止步于此。

MSE 最优的量化器有一个问题：它会让量化后的向量的 范数变小。这个现象叫做 shrinkage。

为什么？因为无论怎么量化，量化误差总会让向量往各个 centroids 的中心靠拢。平均来说，量化后的向量会比原向量短。

在 attention 计算中，这会造成系统性的偏差：

<Q, K_quantized> ≈ <Q, K> - bias

TurboQuant 提出的解决方案是 QJL（Quantized Johnson-Lindenstrauss）。

思路是这样的：

1. 先用 MSE 最优量化器量化，得到近似值
2. 计算残差：residual = original - quantized
3. 对残差做一个 1-bit 的随机投影：sign(S @ residual)
4. 存储这个 1-bit 的符号信息

在反量化的时候，用这 1-bit 的信息来校正 inner product 的估计。

数学上，QJL 能保证 inner product 的估计是 无偏的（unbiased）。

理论上，这很完美。

但实践中呢？

---

第三章：理论与现实的鸿沟

为什么论文说快，实际却慢？

TurboQuant 论文里的实验非常漂亮：

• 5×+ 的 KV 缓存压缩
• Needle-in-a-haystack 测试完美通过（和 FP16 一样好）
• LongBench 上 2.5-bit 和 3.5-bit 量化保持质量

但如果你真在 llama.cpp 里跑起来，特别是在 Apple Silicon 的 Metal GPU 上，会发现一个恼人的问题：速度反而慢了。

怎么回事？

货物崇拜检测：理论 vs 工程

这里我们要做一个「货物崇拜检测」。

论文里的「快」，是指在理想的计算模型下——旋转是一个矩阵乘法，量化是查表，反量化也是查表，所有操作都是计算密集的，内存带宽是瓶颈，所以压缩后数据变少了，速度应该变快。

但真实的硬件不是理想的计算模型。

TheTom（llama.cpp TurboQuant 实现的作者）在一篇深度排查文档里记录了整个过程。

最初，Metal GPU 上的预填充速度随着上下文长度增加而 急剧下降。在 32K 上下文时，turbo3 的速度只有 q8_0 的 60% 左右。

大家首先怀疑的是旋转操作。TurboQuant 用的是 Walsh-Hadamard Transform（WHT），复杂度是 O(d log d)。会不会是 WHT 太慢了？

TheTom 尝试了各种优化：

• 把 WHT 从 dequant 移到 graph 层，和 query 一起做
• 实现自定义的 WHT kernel
• 尝试 group-32 的旋转（把 128 维分成 4 组 32 维，每组单独旋转）

都没用。

真正的瓶颈

最后，TheTom 发现了一个被忽视的细节：

Metal 的 dequant kernel 在读取量化的数据时，是逐个字节读取的。

TurboQuant 的 3-bit 量化把多个索引打包到一个字节里。反量化的时候，需要从每个字节里提取出 3-bit 的索引。

原来的实现是逐个元素提取：

for each element:
    byte = load_byte(index)
    idx = extract_3bits(byte, position)
    value = codebook[idx]

问题是，这个循环里的每一次迭代，都要 重新读取同一个 byte——因为 GPU 的线程是以 SIMD 方式执行的，相邻线程需要相邻的数据，但它们在提取 bit 的时候却要从同一个 byte 里读。

这就导致了「高图分裂计数」（high graph split count）——Metal 的 compute graph 被迫分裂成很多小块，效率极低。

修复方法其实很简单：

把 byte 读取 batch 起来，一次读一个 uint32（4 bytes），然后在 register 里提取所有的 3-bit 索引。

修复后，上下文扩展的回归问题消失了。在 M5 Max 上，turbo3 的速度稳定在 q8_0 的 98.7-99.5%。

就这么回事。

一个工程实现细节，就能让理论完美的算法从「慢 40%」变成「几乎一样快」。

这就是费曼说的：「对于一个成功的技术，现实必须优先于公关，因为自然是无法被愚弄的。」

CPU 上的表现

有趣的是，TurboQuant 在 CPU 上的表现反而更好。

Aaryan-Kapoor 的 CPU 实现显示：

• Prompt 处理速度：tq3_0 20.1 tok/s vs FP16 19.3 tok/s（反而快了 4%）
• 生成速度：tq3_0 11.4 tok/s vs FP16 10.6 tok/s

为什么 CPU 上旋转的 overhead 不明显？

因为 CPU 的内存带宽瓶颈更严重。TurboQuant 把数据压缩了 4.4 倍，从内存读的数据少了，省下来的带宽抵消了旋转的计算开销。

GPU 上 baseline 太快（2694 tok/s），旋转的 overhead 就暴露出来了。

这就是工程现实的复杂性。没有统一的答案，要看具体的硬件、具体的实现。

---

第四章：社区的真实发现

简化往往比完整更好

现在我们要聊一个 反直觉 的发现。

TurboQuant 论文提出了一个两阶段方法：

• Stage 1：MSE 最优量化（用 b-1 bits）
• Stage 2：1-bit QJL 残差校正

论文的逻辑是：MSE 量化有 bias，QJL 消除 bias，合起来就是 unbiased + low distortion。

但社区发现：去掉 Stage 2，只用 Stage 1，反而更好。

至少 6 个独立的实现团队（TheTom、Aaryan-Kapoor、arclabs001、scos-lab、tonbistudio、0xSero）都发现了这个现象。

arclabs001 的 YATQ 项目做了详细的测试：

MSE-only 在 Top-1 token 一致性率、Top-5 一致性率、KL 散度等指标上 总是更好。

为什么 QJL 反而有害？

理论上，QJL 消除了 bias，应该是好事啊？

问题出在 softmax。

Attention 的计算是：

softmax(Q @ K.T / sqrt(d))

Softmax 里面有个指数函数 exp()。而 exp() 是一个 凸函数。

根据 Jensen 不等式：

E[exp(X)] >= exp(E[X])

这意味着：

• 如果你有一个无偏的 inner product 估计，经过 exp() 之后，得到的 attention weight 是 有偏的（系统性地高估）
• 如果你有一个有偏但方差低的估计，softmax 对这种均匀的 bias 是 容忍的：softmax(scores + constant) ≈ softmax(scores)

QJL 消除了 bias，但 增加了方差。而在 attention 中，方差比 bias 更致命——它会让 Top-K 排名错乱，导致模型选错 token。

scos-lab 的测试显示：在 GPT-2 上，用 QJL 的 Prod 方法比 MSE-only 的困惑度（PPL）差了 300%（+300% vs +7.6%）。

这就是理论和实践的差距。

论文证明了 QJL 能让 inner product 无偏，但没考虑到这个无偏性在完整的 attention pipeline 中会被 softmax 破坏。

K 和 V 的非对称需求

社区还发现了一个论文没讨论的问题：

现代 LLM 的 Key 和 Value 向量的范数差异巨大。

这是因为现代 LLM 的各种 normalization 和 scaling 设计，导致 K 向量被反复放大，而 V 向量保持较小。

由于量化误差和范数的平方成正比，K 需要比 V 多得多的比特数。

社区的最佳实践是：

• 对 K 用更多的 bits（比如 4-bit 或 5-bit），或者用 mixed precision（离群通道用 8-bit，其他用 3-bit）
• 对 V 可以用更少的 bits（比如 2-bit 或 3-bit），甚至完全不用量化（保持 FP16）

这种非对称策略在实践中效果最好。

---

第五章：RotorQuant 的野心

2D/3D 旋转真的更好吗？

就在 TurboQuant 社区还在调试各种实现细节的时候，另一波人提出了一个更激进的思路：

如果根本不做完整的 d 维旋转，只用 2D 或 3D 的小块旋转呢？

这就是 RotorQuant、PlanarQuant、IsoQuant 的来源。

三种变体

核心洞察来自 RotorQuant 的论文：

你不需要一个满秩的 d×d 变换来解相关 KV 缓存向量。小块的正交变换就足够了，因为真实的 attention 向量生活在低维流形上。

从代数复杂度来说：

• TurboQuant 的 WHT 是 O(d log d)
• PlanarQuant 的 2D Givens 旋转是 O(d)

这个差距在长上下文、多层、多头的情况下会被放大。

宣称的数字

RotorQuant 项目的 README 给出了非常诱人的数字（Llama 3.1 8B，RTX 5090）：

对比 TurboQuant（turbo3）：

• PPL：iso3 6.91 vs turbo3 7.07（更好）
• Decode：119 vs 93 tok/s（快 28%）
• Prefill：3,822 vs 722 tok/s（快 5.3 倍）
• 参数量：128 vs 16,384（少 128 倍）

5.3 倍的预填充速度提升！这个数字如果是真的，那确实是革命性的。

但等等，我们需要做 货物崇拜检测。

质疑 9-31 倍速度提升

RotorQuant 项目和一些宣传材料中提到「9-31 倍速度提升」。这个数字是从哪来的？

仔细看，这个对比是：

• PlanarQuant 的预填充速度 vs TurboQuant 的预填充速度

但 TurboQuant 的预填充速度慢，很大程度上是因为 实现还没优化好（特别是 Metal 上的 dequant 问题）。

如果对比 PlanarQuant 和 FP16 baseline：

• PlanarQuant prefill：3,822 tok/s
• FP16 prefill：6,156 tok/s

PlanarQuant 实际上比 FP16 慢 38%。

所以「9-31 倍提升」是一个 misleading 的说法。它对比的是两个不同实现阶段的算法，而不是和 baseline 比。

真正的比较应该是：

PlanarQuant/IsoQuant 的优势是：

1. 压缩比更高（10.3x vs 4.4x），因为 TurboQuant 需要存储 WHT 矩阵，而 PlanarQuant 的参数极少
2. 旋转计算更快（O(d) vs O(d log d)）

代价是：

1. PPL 损失更大（6.91 vs 6.63，差距约 4%）
2. 绝对速度还是比 FP16 慢

延迟量化（Deferred Quantization）

PlanarQuant/IsoQuant 还有一个 trick：延迟量化。

在预填充阶段（prompt processing），K 缓存先以 FP16 分配，不做量化。等到解码阶段（token generation），新 token 插入时才量化。

这避免了预填充阶段的旋转开销，所以预填充速度看起来很快。但代价是：

• 预填充阶段的内存占用没有节省
• 只有在长上下文的解码阶段，压缩优势才体现出来

---

第六章：硬件的反击

Metal、CUDA、CPU 各自的问题

不同的硬件平台，对 TurboQuant/RotorQuant 这类算法的态度截然不同。

Apple Metal

Metal 是最早被诟病的平台。

TheTom 的排查文档详细记录了 Metal 上的问题：

1. 共享内存重读：dequant kernel 重复读取共享内存中的量化字节
2. 图分裂：提取 bit 的逐元素操作导致 compute graph 分裂
3. WHT 开销：即使优化后，WHT 旋转仍然有可见 overhead

修复后，TurboQuant 在 Metal 上可以达到 q8_0 的 98-99%，但很难超越 FP16。

NVIDIA CUDA

CUDA 上的问题是 带宽 vs 计算的权衡。

RotorQuant 在 RTX 5090 上的 benchmark 显示：

• PlanarQuant 的 decode 速度可以达到 119-127 tok/s
• FP16 baseline 是 140 tok/s
• 差距约 15%

这是因为：

• 量化节省了内存带宽（从显存读的数据少了）
• 但反量化 + 旋转增加了计算开销
• 在高端卡上，baseline decode 本来就不是带宽瓶颈，所以压缩的收益有限

Aaryan-Kapoor 的 CPU 实现反而表现更好（比 FP16 快），因为 CPU 的内存带宽瓶颈更严重。

CPU

CPU 是当前 TurboQuant 最成功的平台。

原因：

1. 内存带宽是真正的瓶颈（DDR 内存比 GDDR/HBM 慢得多）
2. 旋转的计算 overhead 相对于带宽节省可以忽略
3. 实现简单，没有 GPU kernel 的复杂性

Flash Attention 的集成问题

另一个工程挑战是 Flash Attention 的集成。

Flash Attention 是一个优化的 attention kernel，它把 Q、K、V 的加载、计算、写回融合成一个 kernel，减少内存访问。

如果要支持 TurboQuant 这类压缩格式，需要：

1. 在 kernel 内部反量化 K 和 V
2. 或者预先反量化到临时 buffer

llama.cpp 的 TheTom 和 RotorQuant 项目都实现了 CUDA kernel 的融合版本，但 Metal 上的融合 kernel 还在开发中。

---

第七章：诚实的结论

什么情况下该用、什么情况下不该用

经过这一通分析，我们来做一个诚实的总结。

TurboQuant 适合的场景

✅ 长上下文推理

• 如果你需要跑 128K 甚至 1M token 的上下文，TurboQuant 的 4-5x 压缩能让它 fit 进显存

✅ 内存受限的硬件

• 消费级显卡（24GB 显存跑 70B 模型）
• Apple Silicon（统一内存架构，内存容量大但带宽相对有限）

✅ CPU 推理

• 内存带宽是瓶颈，TurboQuant 的压缩能显著加速

✅ 对质量敏感的应用

• 3-bit TurboQuant 的 PPL 损失只有 1-2%，Needle-in-a-haystack 完美通过

TurboQuant 不适合的场景

❌ 短上下文

• 如果上下文只有 4K-8K，KV 缓存本来就没多大，压缩的收益抵消不了 overhead

❌ 追求极致吞吐

• 如果你追求最高的 token/s，FP16 或 Q8_0 可能更快（取决于实现优化程度）

❌ 对延迟极度敏感

• 反量化的 overhead 会增加首 token 延迟

关于 RotorQuant/PlanarQuant/IsoQuant

这些方法承诺更高的压缩比（10x+），但：

• 质量损失更大（PPL +5-6%）
• 绝对速度仍然比 FP16 慢
• 实现更复杂，生态支持还不成熟

我的建议是：

如果你现在就要用，TurboQuant 的 MSE-only 实现（TheTom 或 Aaryan-Kapoor 的版本）是更成熟的选择。社区已经验证了它的质量，速度也在可接受范围内。

RotorQuant 家族的 2D/3D 旋转思路很有前途，但「9-31 倍速度提升」的宣传是misleading的。真正的提升是对比未优化的 TurboQuant 实现，而不是对比 FP16。

最后的思考

这个领域让我想起了费曼在挑战者号调查中的经历。

NASA 的管理层有一个「官方说法」：失败概率是 1/100,000。但费曼去问工程师，工程师说大概是 1/100。

TurboQuant 论文里的数字——5x 压缩、接近信息论下界、完美质量——是 真实的，但它们是 理想条件下的真实。

当你把这些算法部署到真实的硬件上，面对真实的工程约束——memory layout、kernel fusion、图分裂、bank conflict——你会发现理论和现实之间有巨大的鸿沟。

这不是说理论错了。理论是对的，但它只是地图，不是地形。

真正重要的是：一群社区开发者花了无数个夜晚调试 Metal kernel、追踪内存访问模式、对比 PPL 数字，才让这些「理论上完美」的算法真正可用。

而那个「9-31 倍速度提升」的宣传？那是另一层货物崇拜——用数字的震撼力替代实质的理解。

搞清楚事情的真相，就是这么回事。

---

附录：核心参考资料

论文

• TurboQuant: arXiv:2504.19874 (ICLR 2026) - "TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate"
• PolarQuant: arXiv:2502.02617 (AISTATS 2026) - "PolarQuant: Quantizing KV Caches with Polar Transformation"
• QJL: arXiv:2406.03482 (AAAI 2025) - "QJL: 1-Bit Quantized JL Transform for KV Cache Quantization"
• IsoQuant: arXiv:2603.28430 - "IsoQuant: Hardware-Aligned SO(4) Isoclinic Rotations for LLM KV Cache Compression"

社区实现

• TheTurboQuant+: https://github.com/TheTom/turboquant_plus - llama.cpp Metal/CUDA 实现，含详细排查文档
• Aaryan-Kapoor/llama.cpp: https://github.com/Aaryan-Kapoor/llama.cpp/tree/turboquant-tq3_0 - CPU 实现
• YATQ: https://github.com/arclabs001/YATQ - PyTorch 实现，QJL vs MSE 的详细对比
• RotorQuant: https://github.com/scrya-com/rotorquant - PlanarQuant/IsoQuant 实现
• turboquant-pytorch: https://github.com/tonbistudio/turboquant-pytorch - PyTorch 版本，V3 改进

关键发现

1. MSE-only > MSE+QJL: 多个独立团队发现只用 Algorithm 1 比完整两阶段更好
2. K/V 非对称: 现代 LLM 的 K 向量范数远大于 V，需要不同的比特分配
3. WHT vs Random Rotation: WHT 在实践中比随机旋转更稳定
4. Metal 优化: 批量化字节读取替代逐元素提取，解决了上下文扩展回归问题

---

#AI #KV缓存 #量化 #TurboQuant #RotorQuant #费曼解读 #llamacpp #小凯