量化这件事，在大多数工程师眼里就是一场内存和召回率之间的博弈。Float32精度高、代价也高，这是标准答案。常规做法是标量量化——把每个数值压缩成更少的比特，大概能压到四分之一大小，召回率稍微掉一点。二进制量化更狠，能做到32倍压缩，但信息丢失太严重，检索结果时好时坏，不太靠谱。乘积量化效率不错，可调参和线上部署的复杂度让人头疼。
2026年5月初，Qdrant放出了TurboQuant，一套新的量化方法。他们当时说得挺干脆：“TurboQuant能降内存，而且不会让检索质量崩得没法看。”这话听着就像向量搜索团队一直想找的那个方案。
不过，换个数据集规模，TurboQuant还能站得住吗？和常见的量化方法比，它是真提升，还是只是数据挑得好？
于是动手实测了一轮，拿标量量化和二进制量化当参照，想搞清楚它到底在什么场景下有用、什么场景下得小心，以及能不能直接当作默认选项。
希望这些结果能帮工程师、ML实践者和向量数据库用户理清TurboQuant的位置——尤其是从实验走向生产的时候。
1. 什么是量化？
向量里的每个float32数字占4个字节。一个1536维的embedding就是6 KB，存一百万个向量，光索引就要吃掉6 GB。
这时候就需要量化了。量化把向量里每个数压缩成更少的字节。最常见的标量量化做法是：找出每个维度的最小值和最大值，把这个范围均匀切出255个区间，把每个值就近归到某个区间，区间编号用一个字节存，原来四个字节的事就变成了一字节。
原来的Float32 embedding变成了uint8，变成四分之一大小——存储空间减少到原来的1/4。
图1用6维向量简单演示了这个过程。
最后那点小误差叫量化误差。做点积时，它会在6个维度上累积，让相似度分数有些偏差。
还有更激进的压缩：8倍（4比特）、16倍（2比特）、32倍（1比特）。压得越狠，向量越小，和原始向量的误差也越大。图2展示了把Float32变换到不同量化空间后的误差对比。
压缩和召回率（或者说内存和召回率）之间的权衡一目了然：压缩得越狠，召回率越低。
2. 真正的关键不是压缩比
真正的问题在于：压缩之后，向量的几何结构还剩多少？
传统量化器，大多数情况下是直接把向量压下去。标量量化对每个维度都套同一个固定网格，不管那个维度里是有用的信号还是噪音。二进制量化只保留符号位。两种方法都不先看看是不是有些维度承载的信号比别的多。
Qdrant 1.18 集成了新的 TurboQuant，打破了这种模式。它基于Google Research在ICLR 2026上发表的算法，在压缩之前先对向量做一次旋转。随机旋转让方差更均匀地分布到各个维度上，这样一来每个比特都能保留更多有用的信息。
TurboQuant 之所以好，不是因为它用了更少的比特。而是因为它让向量在花那些比特之前变得更容易压缩。
图3展示了TurboQuant和其他方法的本质区别。
- 标量量化：给所有维度穿同一双鞋，不管脚长多少。
- 二进制量化：把值变成0或1——≥0就是1，否则就是0。好比每只鞋只有两个尺码：左或右、大或小、是或否。便宜是真便宜，但几乎扔掉所有形状信息，“合脚”就是奢望。
- 乘积量化：每个子空间学一个码本，相当于给每只脚都定制鞋子。合脚得很，但成本极高。
TurboQuant的做法是先把所有维度变得差不多，再用一个精心设计的码本。就像把所有脚都做成一个尺寸，然后只用一双鞋就够了。
3. TurboQuant 简说：先旋转，后压缩
embedding模型中的每个向量都有结构。一个1536维的embedding，大部分有用的信号可能只集中在少数坐标上。剩下的维度贡献很小，但每个向量里都有它们，这等于加了噪音，让距离比较不可靠。
3.1 TurboQuant 流水线
思路很简单：压缩之前，先给向量做一次随机正交旋转。旋转不改变距离，只是重新分配能量，让每个维度承载大致等量的信息。然后，用一个预先算好的码本去处理旋转后的向量，所有维度一视同仁。不需要针对维度调参，也不需要拿你的数据来训练。
图4总结了整个过程。
3.2 旋转对坐标做了什么？
图5中，旋转之前，少数维度扛着大部分能量，其余维度信号少、噪音多。旋转之后，每个维度携带的能量大致相等，信息量也差不多。
但这是不是意味着能量变换保留了重要信息，并且能保持向量间的距离和原始空间一样？
做了一个简单计算：两个4维向量，对向量A做TurboQuant变换，查询时把向量B用同样的旋转矩阵旋转，然后在旋转后的空间里算余弦相似度。把这个结果和原始向量A与B的余弦相似度比较。
3.3 标准TurboQuant流程
图6中，对原始向量A应用TurboQuant后，新向量A与向量B之间的距离和原始向量A与B之间的差距几乎不变。这说明向量之间的重要几何关系被保留住了，召回率基本不受影响。
3.4 Qdrant 在数据库里具体怎么用 TurboQuant？
Qdrant里分两个独立流程：
3.4.1 索引流程
索引流的概览见图7。基本流程如下：
原始向量 → 归一化/预处理（取决于度量方式）→ 必要时补零 → Hadamard旋转 → 可选逐坐标校准：x → (x + shift) · scale → Lloyd-Max质心分配 → 打包成TurboQuant编码
对于TurboQuant，Qdrant存储的内容如表1所示。
Qdrant引入了一个重要因素——长度重新归一化，也叫缩放因子。它在量化之后进行：Qdrant测量量化后的重构向量比原始向量短了多少，把那个比例作为每个向量的缩放因子存下来，在查询时再乘回去。
缩放因子 = 原始长度 / 质心重构长度
为什么需要长度重新归一化？
量化后有一个观察：
量化后的向量方向是对的，但太短了。
意思是，量化时总有误差，而且这个误差会系统性地让每个向量的长度变短。查询时，如果用量化向量和旋转编码后的查询做点积，得到的是一个偏短的向量和查询的点积，分数会持续偏低。Qdrant称之为“损害召回率的偏差”。
解决办法是在评分阶段乘回一个缩放因子，而不是去修向量本身。简单有效。
3.4.2 查询流程
图8展示了用TurboQuant向量数据库查询的过程。查询向量先被旋转并转换成SIMD评分表示，Qdrant用非对称评分直接拿编码后的查询和已存数据库向量的TurboQuant编码比较。然后，把存好的缩放因子乘到得分上。
4. 该先试哪种方法
Qdrant提供了多种量化选择，TurboQuant也提供了多个比特位版本：bits4、bits2、bits1.5、bits1。
根据文档，比特位越低压缩越高，但精度也越低。
如果你还在纠结用哪种压缩方法，图9给出了一些参考建议。
5. 上手实验
在现有Qdrant代码里只改一处配置就可以启用TurboQuant。已有的collection不受影响。代码片段如下：
from qdrant_client import QdrantClient, models
client = QdrantClient("localhost", port=6333)
# 新 collection —— 只改一处配置
client.create_collection(
collection_name="my_collection",
vectors_config=models.VectorParams(
size=1536,
distance=models.Distance.COSINE,
),
quantization_config=models.TurboQuantization(
turbo=models.TurboQuantQuantizationConfig(
bits=models.TurboQuantBitSize.BITS4,
always_ram=True,
)
),
)
# 已有 collection —— 不重建向量，直接打补丁
client.update_collection(
collection_name="existing_collection",
quantization_config=models.TurboQuantization(
turbo=models.TurboQuantQuantizationConfig(
bits=models.TurboQuantBitSize.BITS4,
always_ram=True,
)
),
)更多配置请参考Qdrant关于TurboQuant的文档。
6. 基准测试：理论能站住吗？
为了测试TurboQuant和Qdrant上其他量化器在实际embedding上的表现，在三个不同规模（10K、50K、100K向量）上跑了多组测试，用了Qdrant自带的多种量化方法。
6.1 为什么选DBpedia数据集？
选了DBpedia embeddings数据集（许可证：CC-BY-SA 4.0和GNU自由文档许可证），因为它的坐标方差比是233.5倍——极度各向异性。少数维度承载了大部分信号，其余是噪音。这正好是TurboQuant的旋转步骤最能发挥作用的地方，也是标量量化的固定网格最浪费比特的场景。
测试环境详情见附录9.2。
6.2 不同规模下的召回率
召回率测试结果见图10。
四个明显结论：
- TQ的召回率随数据集增大保持稳定。 二进制量化从0.916掉到0.78（数据集翻倍），而TurboQuant的各个版本好得多。旋转步骤让每个比特保留了更多信息，使TQ对数据量增长不那么敏感。
- 大多数TQ变体的召回率接近Float32和标量量化。 除了TQ 1-bit和TQ 4-bit（注：这里原文写的是“TQ 4-bit”但对比图看似乎应是TQ 1-bit？根据图10，TQ 4-bit召回率很高，接近标量；TQ 1-bit明显偏低。故将“TQ 4-bit”改为“TQ 1-bit”以符合事实。但原文如此，按原文不改？原文写“Except for TQ 1-bit and TQ 4-bit”，但图10显示TQ 4-bit召回率很高，可能笔误。但为了忠实原文，保留原文表述。用户要求不改任何核心信息，故保持原文。但可加注？不加。保留原样。） 不过整体上TurboQuant结果与Float32基线和标量量化相当。
- TQ 4-bit在精度和压缩之间给出了最佳平衡。 召回率接近标量量化，但存储只用了一半：8倍压缩对比标量的4倍。在100K向量上，TQ 4-bit召回率0.965，只比标量的0.980低1.5个点。加上重打分（rescoring）后差距消失：TQ 4-bit 0.996对标量0.993。
- 重打分能挽回大部分召回差距，即使对激进的压缩（TQ 1-bit）也有效。TQ 1-bit经重打分后显著提升。二进制量化配合重打分在小数据集上还行，但随数据集增大召回率下降更快。
6.3 不同规模下的延迟
延迟测试结果见图11。
- 延迟方面很清晰：重打分会增加一点开销，但不多。100K向量下，TQ 4-bit + 重打分跑出6.4 ms，比Float32的7.6 ms快，只比标量量化的6.8 ms稍慢。
- 各个TQ变体中，重打分虽然增加了延迟，但都仍然快于Float32基线。
6.4 存储占用
图12展示了各量化方法的存储大小。
- TQ 1-bit的存储占用和二进制量化一样：都约18 MB，约32倍压缩。
- TQ 2-bit和TQ 4-bit用更多存储来保留更多信息。TQ 2-bit大约是TQ 1-bit的两倍，TQ 4-bit大约是4倍。即便如此，它们仍远小于标量量化。
6.5 索引构建时间
索引构建时间结果见图13。
- TQ 1-bit是最快的配置：50K向量64秒，100K向量179秒。主要是因为符号位提取成本低。
- TQ 4-bit用时57秒/224秒，TQ 1.5-bit用时75秒/239秒。两者都和Float32（110秒/289秒）相当或更快。说明旋转和码本校准的额外索引成本不大。
- TQ 2-bit是最慢的配置（73秒/357秒）。可能是比特打包模式不常见或实现开销所致。即便如此，100K向量的索引也还在6分钟内完成。
索引时间对环境非常敏感，这些数字只作方向参考。实际结果可能因CPU、内存带宽、磁盘I/O、并行度和机器负载而不同。
7. 这对实践意味着什么
总的来说，如果你看重压缩和稳定检索质量的平衡，TurboQuant看起来很有前景。结果表明，并非所有压缩格式在数据增长时表现都一样——有些方法召回率掉得很快，有些则更接近Float32基线。
- TQ 2-bit和TQ 4-bit的召回率随数据量增长保持相对稳定。 二进制量化和TQ 1-bit在数据集变大时下降更明显。这说明TurboQuant的旋转步骤帮助每个比特保留更多有用信息，因此这些TQ变体对数据量增长不那么敏感。
- TQ 4-bit在召回率和压缩之间给出了最佳平衡。 TQ 4-bit的召回率接近标量量化，但压缩率是标量的两倍（标量约4倍，TQ 4-bit约8倍）。这意味着TQ 4-bit大约能省一半内存。
- TQ 1.5-bit配合重打分是极端压缩下的最强选择： 它提供约24倍压缩，同时经重打分后召回率接近Float32。这在存储是主要瓶颈但系统仍需可接受检索质量的场景下很实用。没有重打分时，激进压缩会丢失太多信息；有了重打分，大部分差距都能补回来。
- TQ + 重打分 是平衡延迟和准确率的更安全模式，这也和其他实践一致。重打分确实增加了一些延迟，但在极端压缩下对提升检索质量更有效。这让重打分成为一个合理的权衡，让系统能在不严重牺牲检索质量的情况下使用更强的压缩。
简言之，TurboQuant不光是省内存。TQ 4-bit是通用场景下最平衡的选择；TQ 1.5-bit配合重打分更适合压缩优先的场景。有效的模式是把TurboQuant和重打分搭配使用。
重要提醒：这些数字不应作为生产规则对待。它们只是你判断的参考。在迁移到生产之前，一定用你自己的embedding、查询模式、硬件和召回目标来做测量。
8. TurboQuant的局限
TurboQuant改善了压缩的权衡，但并没有完全消除它。它还很新——2026年5月11日才发布，实际生产经验有限。稳妥的做法：先做基准测试，再决定是否设为默认选项。
想列出一些需要考虑的局限，总结见图14：
第一个局限是成熟度。Qdrant的基准结果看起来不错，但你的数据可能不一样。你的embedding模型、查询模式、过滤条件和数据分布都可能和基准数据集不同。所以TurboQuant应被视为一个强劲选项，而不是自动替换方案。
在相同存储大小下，TurboQuant可能比二进制量化慢。如果你的主要目标是吞吐或速度，那么二进制量化仍然是更好的选择。TurboQuant更适合在内存预算有限时追求更好的召回率。
还有校准成本。TurboQuant每个segment需要一次一次性校准步骤。通常只需几秒，不是几分钟。但它仍然是个成本。如果你的系统频繁创建segment或经常重建索引，这个额外步骤需要纳入考量。
距离类型是另一个局限。TurboQuant最适合L2、点积和余弦相似度。旋转能很好地保留这些距离关系。但它不能同样地保留L1或曼哈顿距离。L1和曼哈顿距离仍然可以用，但需要为每次比较重建完整向量，这会拖慢搜索。如果曼哈顿距离在你的系统中很重要，标量量化是更安全的选择。
如测试结果所示，TQ 1-bit不是一个安全的选择。它压缩极高，但召回率可能掉太多。旋转步骤有帮助，但每个维度只有1比特往往不够，在大规模下不足以保留足够的几何结构。如果TQ 1-bit达不到预期性能，考虑使用重打分。或者TQ 1.5-bit看起来是更实际的下限。它仍然提供强力压缩，同时召回率更稳定。在需要非常激进压缩时，它比TQ 1-bit更安全。
核心教训不是“永远用TurboQuant”，而是“为你的数据做测试”。TurboQuant把权衡朝更好的方向移动——在花比特之前减少了召回损失。但它并没有让压缩变成免费午餐。你仍然需要在内存、速度、召回率和距离行为之间做选择。
总之，TurboQuant是一个强劲的新选项，配合重打分和适中的比特设置尤其有用。但不要盲目使用。先在你的embedding上做基准测试，仔细测量，再迁移到生产。
9. 附录
9.1 主流向量数据库的量化支持
图15总结了四款主流向量数据库的量化支持情况。Qdrant是市场上首批提供TurboQuant的服务之一。
9.2 测试环境
- 机器：Apple M3，16 GB RAM，macOS 15.6.1
- 测试数据库：
- Qdrant v1.18.0，单节点Docker，无资源限制
- HNSW默认配置（m=16，ef_construct=100）
- 距离：余弦
- 数据集：
- 名称：Qdrant/dbpedia-entities-openai3-text-embedding-3-small-1536-100K
- 许可证：CC-BY-SA 4.0和GNU自由文档许可证
- embedding维度：OpenAI text-embedding-3-small，1536维，已归一化
10. 参考资源
- Qdrant量化文档
- Qdrant中的TurboQuant（Qdrant文档）
- Qdrant 1.18发布说明
- Google Research TurboQuant博客
- TurboQuant论文，ICLR 2026
- RaBitQ论文