向量数据库Qdrant TurboQuant全面深度解析：它真的是银弹吗

量化这件事，在大多数工程师眼里就是一场内存和召回率之间的博弈。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基线。

1. TQ 2-bit和TQ 4-bit的召回率随数据量增长保持相对稳定。 二进制量化和TQ 1-bit在数据集变大时下降更明显。这说明TurboQuant的旋转步骤帮助每个比特保留更多有用信息，因此这些TQ变体对数据量增长不那么敏感。
2. TQ 4-bit在召回率和压缩之间给出了最佳平衡。 TQ 4-bit的召回率接近标量量化，但压缩率是标量的两倍（标量约4倍，TQ 4-bit约8倍）。这意味着TQ 4-bit大约能省一半内存。
3. TQ 1.5-bit配合重打分是极端压缩下的最强选择： 它提供约24倍压缩，同时经重打分后召回率接近Float32。这在存储是主要瓶颈但系统仍需可接受检索质量的场景下很实用。没有重打分时，激进压缩会丢失太多信息；有了重打分，大部分差距都能补回来。
4. 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论文

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：向量数据库Qdrant TurboQuant全面深度解析：它真的是银弹吗要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题