压缩的代价比压缩本身还贵，怎么办

问题

你有一堆 32 位浮点数要压缩到 3 位。压缩本身不难——四舍五入就行。难的是：你得告诉解压器"我是怎么四舍五入的"。这条元信息（最小值、最大值、缩放系数）本身也要存，而且要用完整精度。

当你压到 4 位、3 位，这些元信息占的比例越来越大。极端情况下，"标签"比"货物"还重。这就是量化领域的公开秘密：压缩率越高，元数据开销越致命。每个数字多花 1-2 bit 存量化常数，听着不多，3 bit 量化里这就是 30-60% 的额外负担。

之前的做法要么忍受这个开销，要么用大码本（product quantization）——码本本身又是一笔存储和计算开销，还得针对数据集调参。Google 这篇论文的路径不同：让数据自己变成不需要元信息的形状。

翻译

想象你在邮寄一箱杯子。传统做法：每个杯子用气泡纸裹好，纸箱里塞满填充物。杯子越小，填充物占的比例越大——寄一个espresso杯，包装可能比杯子重三倍。

TurboQuant 的思路：别一个个包了。先把所有杯子扔进滚筒（随机旋转），让它们自然嵌套成一个紧凑的球形团。球形有个好处——你只需要知道半径和角度就能定位每个杯子，不需要单独记录每个杯子的位置偏移。包装材料（量化常数）从每个杯子一份，变成整个球一份。接近于零。

具体分两步走：

第一步：旋转 + 极坐标（PolarQuant）

拿到一组高维向量，先乘一个随机旋转矩阵。旋转不改变向量之间的距离（内积保持不变），但改变了每个分量的分布——从任意形状变成接近均匀分布。

均匀分布的好处：你不需要记录"这组数的最大值是 0.73、最小值是 -0.41"这类信息了，因为旋转后所有组的分布几乎一样。然后转极坐标：一个半径（向量长度）加一组角度。角度的分布是已知的、高度集中的，可以用固定网格量化，不需要额外的缩放系数。

第二步：1-bit 残差修正（QJL）

第一步做完，近似误差不是零。怎么修？用 Johnson-Lindenstrauss 变换把残差投影到低维空间，然后只保留符号位（+1 或 -1）。每个分量 1 bit，零额外元数据。

两步合起来：3-4 bit 总量化，零量化常数开销。

效果

在 Llama-3.1-8B、Gemma、Mistral 上测 KV cache 压缩：内存缩 6 倍以上，下游任务准确率不掉。4-bit 配置在 H100 上注意力计算加速 8 倍。向量搜索的召回率也超过 PQ 和 RabbiQ，而且不需要针对数据集调参。

核心概念

量化常数开销

量化就是把大数变小数。但解压时你得知道"小数对应原来哪个范围"。这个"范围说明书"叫量化常数——每个数据块存一组 min/max/scale。在 16 bit 或 8 bit 量化时，量化常数占总存储的比例很小，没人在意。但压到 3 bit，常数本身要 32 bit 全精度存储，一个 128 维的块里常数占比飙升。TurboQuant 的核心贡献就是让这个开销归零：数据旋转后分布已知，不需要存范围。

Johnson-Lindenstrauss 变换

一个数学定理说：高维空间里的点可以投影到低维空间，同时几乎不改变点与点之间的距离。TurboQuant 用它来处理量化残差——把误差向量投影到低维，再只保留正负号。1 bit 拿到的信息量，够把第一步的偏差修回来。关键：这个投影是"数据无关"的（随机矩阵），所以不需要看过数据就能用，换数据集不用重新调。

洞见

压缩的极限不在于你能把数字变多小，而在于你能不能让"压缩本身的成本"消失。

这不只是量化的事。任何信息压缩——文件压缩、知识蒸馏、记忆整理——都有"描述压缩方式"的隐性成本。当压缩越激进，这层成本越显眼。TurboQuant 的做法不是在压缩算法上做文章，而是先改变数据的形状让压缩变得不需要描述——变换后的数据"自带说明书"。这个思路在信息论之外也成立：最好的简化不是找更好的简化方法，是让东西本身变得不需要简化。

博导审稿

选题扎实。量化常数开销这个问题大家都知道，但多数人的解法是"怎么更高效地存常数"。这篇论文退了一步问"能不能不存"，这个角度好。随机旋转让分布变均匀这个 trick 不新，但组合极坐标量化和 QJL 残差修正做到零开销，组合得漂亮。

方法有理论支撑——Johnson-Lindenstrauss 是成熟的数学工具，证明写得到位。PolarQuant 阶段的几何直觉清晰：旋转保内积、极坐标利用已知分布。两步串联的设计自然，不是硬拼。

实验覆盖了 KV cache（LLM 场景）和向量搜索（检索场景），baseline 包括 KIVI、PQ、RabbiQ。5 个 benchmark、3 个模型骨干，消融做了（PolarQuant 单独 vs 加 QJL），数字经得起看。但有一点偷懒：6 倍压缩和 8 倍加速的数字只给了最好配置，没看到不同 bit 宽度下的完整曲线。而且"零精度损失"这个说法在 3 bit 下是不是所有任务都成立，论文选的 benchmark 偏友好（主要是长文本理解），短文本场景和推理密集任务没测。

写作清楚，Google 博客风格偏科普，学术细节得去原论文看。

判决：weak accept。 数学漂亮，工程实用，但"零精度损失"的适用边界没交代清楚，实验在最有利场景上展示。

启发

迁移：OpenViking 的 384 个资源用 Qwen3-Embedding-4B 生成 2560 维向量，54MB 存储。TurboQuant 的随机旋转+极坐标量化可以直接套用：2560 维向量从 32-bit 压到 3-bit，存储从 54MB 降到 ~9MB，搜索延迟不变（论文验证了向量搜索场景）。Memory Pro 的 4096 维嵌入收益更大。实现路径：PolarQuant 的随机旋转矩阵只需要一个种子就能重建，加一层 Python 预处理即可，不需要改 RocksDB 存储层。

混搭：Mac Studio 跑的 Qwen3.5-27B 是 ~8bit 混合量化（25GB）。TurboQuant 针对的是 KV cache，不是权重——这意味着推理时的 KV cache 可以单独再压 6 倍。对于 256K 上下文窗口，KV cache 是内存瓶颈。如果 mlx-lm 支持 TurboQuant 风格的 KV 量化，128GB 的 Mac Studio 能推更长的上下文，或者同时跑更多并发请求。这和权重量化是正交的优化。

反转：PAI 的嵌入管线（OpenViking、Nowledge Mem、Memory Pro）全部用全精度向量存储 + cosine 检索。隐含假设是"向量精度很重要"。但 TurboQuant 说 3 bit 就够了，召回率甚至超过全精度 PQ。如果 3 bit 向量在检索质量上和 32 bit 没区别，那花在高精度嵌入模型上的算力可能用错了地方——用小模型生成嵌入然后全精度存储，不如用大模型生成嵌入然后 3-bit 存储。嵌入质量的瓶颈在模型，不在精度。