⚡ 压缩与速度的博弈——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 的索引。 原来的实现是逐个元素提取： ```c 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 项目做了详细的测试： | Bits | MSE-only Top-1 | +QJL Top-1 | 差距 | |------|----------------|------------|------| | 2-bit | 65.6% | 50.0% | **-15.6%** | | 3-bit | 71.0% | 61.2% | **-9.8%** | | 4-bit | 80.4% | 69.6% | **-10.7%** | 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 向量的范数差异巨大。** | 模型 | K mean norm | V mean norm | 比例 | |------|-------------|-------------|------| | GPT-2 (124M) | 11.8 | 2.0 | **6x** | | Phi-2 (2.8B) | 13.1 | 3.0 | **4x** | | Qwen2.5-3B | 172.1 | 3.3 | **52x** | | Qwen2.5-7B | 274.0 | 2.6 | **106x** | | Qwen2.5-1.5B | 778.6 | 4.3 | **182x** | 这是因为现代 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 的来源。 ### 三种变体 | 方法 | 旋转方式 | 块大小 | FMAs (d=128) | 参数量 | |------|----------|--------|--------------|--------| | TurboQuant | WHT（Walsh-Hadamard） | 128 | 16,384 | 16,384 | | RotorQuant | Clifford 转子（Cl(3,0)） | 3 | ~2,400 | 372 | | IsoQuant | 四元数（SO(4)） | 4 | 512 | 128 | | PlanarQuant | Givens 2D 旋转 | 2 | 256 | 128 | 核心洞察来自 RotorQuant 的论文： **你不需要一个满秩的 d×d 变换来解相关 KV 缓存向量。小块的正交变换就足够了，因为真实的 attention 向量生活在低维流形上。** 从代数复杂度来说： - TurboQuant 的 WHT 是 O(d log d) - PlanarQuant 的 2D Givens 旋转是 O(d) 这个差距在长上下文、多层、多头的情况下会被放大。 ### 宣称的数字 RotorQuant 项目的 README 给出了非常诱人的数字（Llama 3.1 8B，RTX 5090）： | 配置 | Decode tok/s | Prefill tok/s | PPL | |------|--------------|---------------|-----| | FP16 baseline | 140 | 6,156 | 6.63 | | **iso3 / iso3** | **118** | **3,397** | **6.91** | | **planar3 / planar3** | **119** | **3,822** | **7.05** | | turbo3 / turbo3 | 93 | 722 | 7.07 | **对比 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 比。 **真正的比较应该是：** | 方法 | 压缩比 | PPL 损失 | Prefill 速度 | Decode 速度 | |------|--------|----------|--------------|-------------| | FP16 | 1x | 0% | 100% | 100% | | TurboQuant (优化后) | 4.4-5x | ~1-2% | ~98-110% | ~90-95% | | PlanarQuant/IsoQuant | 10.3x | ~5-6% | ~60% | ~85% | 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 #小凯