作者：来自 ElasticThomas Veasey

从向量搜索到强大的 REST 应用程序编程接口，Elasticsearch为开发者提供最全面的搜索工具包。深入查看我们在 Elasticsearch Labs 代码库中的示例笔记本来尝试新内容。你也可以今天开始免费试用或在本地运行 Elasticsearch。

---

在 CPU 向量检索中，Elasticsearch 的 优化标量量化 (Optimized Scalar Quantization– OSQ) （更好的二值量化 (BBQ) 背后的算法）在生产系统最关心的方面击败 TurboQuant：吞吐量、排序准确率和存储效率。在我们对 Apple M2 Max 的测试中，OSQ 的对称核速度提升 10-40倍，并且在平移嵌入上，其 1比特文档编码在排序准确率上以 4比特的 TurboQuant 表现更优，同时使用更少存储。TurboQuant 在原始重建均方误差上仍然胜出，但这一优势主要来自 哈达玛旋转（Hadamard rotation），并不会转化为更好的 CPU 向量检索行为。

简要的量化入门

向量检索索引通常存储数百万或数十亿个嵌入向量，每个向量包含数百或数千个浮点数维度。标量量化将每个浮点坐标独立压缩为小整数，通常为1、2或4比特，从而将存储减少8-32倍，并支持快速整数算术打分。

为什么按坐标的量化是可行的？因为期望平方误差可以分解为各个坐标独立项的求和：
，由于期望的线性性。每个坐标都可以独立量化，而不依赖联合分布。剩下的问题是如何让每个按坐标的量化器表现更好。

BBQ 和优化标量量化

更好的二值量化（BBQ）及其底层算法优化标量量化（OSQ）已经成为 Elasticsearch 多个版本的一部分。OSQ 是多种技术的演进，用于让标量量化更加准确，特别针对向量检索。

每个向量的分量都会被映射到区间 [a,b] 上的均匀网格。该区间根据向量的统计信息初始化（假设残差近似服从正态分布），使用与 TurboQuant 完全相同的优化目标，但增加了对质心位置的额外约束。随后它们通过坐标下降法进行优化，以最小化各向异性损失：

其中 e 是量化误差向量。在生产默认值()下，这会有意牺牲部分均方误差（MSE），以便将准确性集中在查询方向上。而这正是排序所关心的方向。

在量化之前，会从每个向量中减去分段（或者在倒排向量文件（IVF）索引中的聚类）质心c。这会移除主导性的共享分量，否则它会浪费量化器的动态范围。对称和非对称点积路径也都会使用相同的分段质心对查询进行中心化，因此唯一被量化的内积是中心化残差之间的内积。修正项⟨c,x⟩（针对每个向量）以及只依赖单个向量，因此可以被精确预计算。因此，中心化不会增加任何成对计算成本。

文档以1比特进行量化（32倍压缩），查询以 4 比特进行量化（因为每次检索只有少量查询，所以成本较低）。存储约束作用于文档，而不是查询，因此在查询侧使用更多比特可以恢复浮点查询精度，同时保持每个文档占用最小。

一个块对角正交预条件器会在量化之前均衡各坐标方差并归一化其分布。这与 TurboQuant 使用完整 Hadamard 旋转的目标相同，但不会带来 2 的幂次填充开销。

由于网格是均匀的，量化点积可以分解为整数点积和标量修正。这使得 NEON/SVE 和 SSE/AVX 的 popcount 和乘加流水线成为可能：针对1比特和2比特使用位平面分解，针对4比特使用半字节乘法，以及一种 RaBitQ 风格的混合 41 内核，它可以分解为四个1比特内核。

想更深入了解稀疏旋转及其对鲁棒性的提升，请参阅《鲁棒优化标量量化》博客。想完整了解优化标量量化，请参阅这篇 OSQ 深度解析。

TurboQuant

TurboQuant（ Google ， ICLR 2026 ）采用了一条略有不同的路径，但起点观察相同：集中且可预测的逐坐标分布更容易被高质量量化。

TurboQuant 并不是针对每个向量自适应量化器，而是对向量进行归一化，并对整个数据集应用共享的随机 Hadamard 旋转。这种通用思想最早由 RaBitQ 提出并形式化，它证明了随机旋转能够对其量化方案中的数据产生最坏情况界限，并且对于任意固定单位向量都成立。通过 Hadamard 旋转实现这一思想则是由 Weaviate 为旋转量化提出的。

在归一化与旋转之后，每个坐标的分布在高维情况下几乎总会收敛到，而与原始数据无关。 TurboQuant 在这个基础上继续构建：在分布被固定后，它会求解最优 Lloyd-Max 标量量化器，即已知密度上的一维 k-means 问题。得到的非均匀质心会在密度最高的位置（接近零）更加密集，而在尾部区域更加稀疏。这实现了可证明的近最优 MSE ：在一般情况下距离信息论下界约 2.7 以内，而在 1-bit 情况下可以收紧到 1.45 。

对于内积而言， MSE 最优量化器会引入乘法偏差（在 1-bit 情况下最严重：）。 TurboQuant 通过两阶段设计（ ​）来修正这一点：先使用 b−1 个 bit 用于 MSE 量化器，然后将剩余的 1 bit 用于残差的量化 Johnson-Lindenstrauss（ QJL ） sketch ，从而得到一个可证明无偏的内积估计器。

论文中的最近邻实验是在 GPU（ NVIDIA A100 ）上进行的，其中查找表访问模式能够自然映射到共享内存。

关键设计分歧：整数算术与查找表

均匀与非均匀质心之间的差异看起来可能很小，但它会带来巨大的计算差距。

OSQ 的均匀网格意味着每个量化坐标都是一个保留算术意义的整数。两个量化向量的点积可以分解为整数点积，从而能够被 SIMD 直接利用：x86上的 vpdpbusd，以及 ARM NEON 上的乘加和 vcnt（位计数）。整个流水线没有分支，并且数据访问模式是顺序的。

TurboQuant的非均匀质心破坏了这一点。每个坐标对都需要从共享码本中查找一个质心值，并且访问模式依赖于数据，因为每个索引都会选择不同的表项。在缺少浮点 gather 指令的 NEON 上，这意味着在执行融合乘加（FMA）之前，需要通过标量加载来构建每个向量寄存器。即使预先计算每坐标乘积表（个条目，在所有文档之间摊销）也没有帮助：在现代核心上，FMA相对便宜，因此瓶颈仍然是依赖数据的 gather，而不是算术运算。我们的基准测试证实了这一点：预计算 ADC 表并不会更快（有时由于更大的工作集甚至更慢），相比之下还不如内联质心查找。

术语

下面的结果部分提到了几种 OSQ 打分配置。它们都使用均匀网格量化以及标量修正项，以在量化噪声范围内恢复精确点积。

对称 比特会将查询和文档都以每坐标 比特进行量化。

非对称会将查询保留为完整浮点向量，而只对文档进行量化。点积是浮点数与整数的求和。与对称方式相比，这种方式在每对计算上的成本更高，但可以避免任何查询量化噪声。TurboQuant 的打分始终是非对称的（浮点查询通过质心查找与量化文档做点积）。

1-4 是 OSQ 的生产配置：文档使用1比特（32 倍压缩），查询使用 4 比特。这利用了检索的不对称性：只有一个查询，但有数百万文档，因此查询存储几乎免费，而文档存储才是真正的约束。

中心化表示在量化之前，已经从所有向量（以及查询）中减去了分段质心 c，并通过预计算标量项恢复精确修正。中心化会让量化器的动态范围聚焦于携带信息的残差，而不是共享均值。

控制各向异性损失的权衡：会最小化纯均方误差（MSE），而（生产默认值）会牺牲部分 MSE，以便将准确性集中在查询方向上，而这个方向正是决定排序的方向。

在实践中它们如何比较？

以下结果是在 Apple M2 Max 上获得的。用于复现所有结果的代码可在这里获取。

一对一： MSE

在重建 MSE 上（该指标是 TurboQuant 设计时优化的目标），TurboQuant 在所有 bit-width 上都优于基础 OSQ。

相对 MSE（），在 d=768 高斯向量（1000个向量，越低越好）上：

比特	OSQ (=0.1)	OSQ (=1)	TurboQuant	TQ 对 OSQ (=1)
1	0.512	0.362	0.307	1.18
2	0.138	0.118	0.092	1.28
3	0.038	0.037	0.026	1.42
4	0.011	0.011	0.007	1.61

列显示OSQ 的生产设置（ = 0.1）有意牺牲 MSE 来换取点积精度。在 = 1（纯 MSE）时，这个差距明显缩小，在 1-bit 时仅为 1.18。

但 TurboQuant 剩余的 MSE 优势到底来自哪里，是来自 Lloyd-Max 质心，还是来自 Hadamard 旋转？我们可以通过直接对 OSQ 应用相同的随机 Hadamard 旋转来回答这个问题（零填充 768→1024，随机符号翻转，Walsh-Hadamard 蝶形变换，在旋转空间量化，再逆变换）。理论上预测 MSE 会按比例改善一个因子

d / d′ = 768 / 1024 = 0.75

比特	OSQ ( = 1 )	OSQ + 哈达玛	TurboQuant	比例 ( OSQ / QSQ + 哈达玛 )	理论 ( d’ / d )
1	0.362	0.306	0.307	1.19	1.33
2	0.118	0.092	0.092	1.28	1.33
3	0.037	0.028	0.026	1.31	1.33
4	0.011	0.009	0.007	1.33	1.33

OSQ + Hadamard 在 1-bit（ 0.306 vs 0.307 ）和 2-bit（ 0.092 vs 0.092 ）时几乎与 TurboQuant 完全一致。TurboQuant 的 MSE 优势来自旋转，而不是质心。在 3–4 bit 时，Lloyd-Max 的位置带来约 1.1 的小幅优势，真实但很小。

将 Hadamard 变换应用到 OSQ 后得到的提升比值的收敛本身也具有信息量：在 4-bit 时它精确达到理论值 1.33，但在 1-bit 时只有 1.19。这个缺口量化了 OSQ 的数据依赖区间细化的价值：它已经捕捉了 Hadamard 提供的约 40% 的维度扩展与分量均衡收益。坐标下降在某种程度上在做与旋转相同的工作，通过对每个向量进行自适应调整，而不是依赖数据无关的变换。然而真正的优势在于，这种形式允许我们将精度集中在查询方向上。

这引出了一个自然问题：在实践中，OSQ 的块对角稀疏预条件器与完整 Hadamard 旋转相比如何？

正面对比：稀疏预条件器 vs Hadamard

OSQ 的稀疏预条件器采用块对角随机正交变换：将维度随机置换为多个块（生产环境中为 6464），每个块分别乘以一个独立的随机正交矩阵。这样可以在每个块内均衡坐标分布。Hadamard 旋转在全局范围内实现相同目标，但需要填充零以达到 2 的幂次。

我们在各向异性高斯数据上进行测试（ d = 768 ， i 在各坐标上从 1 递增到 5 ），这是一个具有挑战性的分布，其中部分坐标的方差远高于其他坐标。

变换延迟（ d = 768 ， 1,100 向量， ARM NEON ，越低越好）：

方法	ns/vec	有效维度
块 3232	1,811	768
块 6464	4,887	768
全密集	244,752	768
Hadamard	1,556	1,024

Hadamard 是最快的非平凡选项，这得益于 O(d log d) 的蝶形计算，而块大小为 b 时为 O(db)，尽管所有块对角变体在实践中都足够快，即使 6464 块在 4.9 s/vec 也已经很小，相比典型搜索延迟几乎可以忽略。全密集 dd 旋转在244 s/vec 下是不可行的，但作为理论参考存在。注意块对角变换适用于任意维度：不需要补齐到 2 的幂次，并且有效维度保持为 d。

MSE（相对 MSE，=1，各向异性数据，越低越好）：

方法	1 bit	2 bit	4 bit
无变换	0.443	0.157	0.0182
块 3232	0.368	0.121	0.0120
块 6464	0.365	0.119	0.0117
全密集	0.362	0.118	0.0113
Hadamard	0.362	0.118	0.0112

即使 3232 块也能从无变换（0.443）到完整旋转（0.362）之间恢复大部分差距，在1-bit 时达到93%。6464 块进一步缩小差距。在各向同性数据（未展示）上，所有方法产生完全相同的 MSE（约 0.362 在1-bit 时），这证实当各坐标已经具有相同方差时不需要任何均衡处理。

点积精度（1 – 4中心化，原始相对点积误差；注意这些是包含乘性偏差的原始 RMSE，用于比较不同预条件器变体是合适的，因为偏差结构相似，越低越好）：

方法	各向异性	各向同性
无变换	0.690	0.722
块 3232	0.606	0.724
块 6464	0.602	0.720
全密集	0.595	0.723
Hadamard	0.566	0.629

在各向同性数据上，块对角方法和全密集旋转产生与无变换相同的点积误差，因为没有需要被修正的结构问题。Hadamard 是唯一的例外，它将误差从 0.723 降低到 0.629。但这种改进并不是来自更好的预条件处理：全密集旋转作为同样有效的随机正交变换，却完全没有改善结果。差异来自填充效应。Hadamard 在 1024 维空间中运行，因此 1-bit 文档实际存储 1024 bit，而不是 768 bit。这带来了 33% 的额外存储。改进比率（0.723 / 0.629 = 1.15）几乎精确匹配

这表明点积优势完全来源于额外 bit，而不是旋转本身。

在各向异性数据上，块对角旋转确实改善了点积精度（0.690 → 0.602，块 64），这才是坐标均衡带来的真实收益。Hadamard 进一步降低到 0.566，但它相对于同维度的全密集旋转（0.595 → 0.566）的增益，同样与填充效应一致。

实际意义是：在 CPU 检索且存储效率重要的场景下，块对角预条件器在相同有效 bit rate 下能提供与 Hadamard 相同的 MSE 改善，并且无需维度填充即可适用于任意维度，而我们实验中看到的点积差距，本质上是填充带来的副作用，而不是预条件能力的优势。

头对头：点积精度

MSE衡量的是重建质量，但搜索引擎的排序依据是点积。这两者是不同的优化目标，而OSQ的设计取舍正是在这个差异中体现价值。

我们衡量的是相对点积误差：并随着查询与文档之间的夹角变化进行测试。小角度区域（0–20）最为重要：真实的transformer嵌入在球面上并非均匀分布，而是集中在一个狭窄的锥体中（Ethayarajh 2019）。此外，近似平行的向量——即查询在数据集中最近邻 —— 正是排序准确性最关键的区域。

我们的生产配置为：1-比特文档、4-比特查询、质心中心化，以及整数打分。

原始点积误差混合了两个不同成分：乘性偏差（一个全局尺度因子，不改变排序顺序）和噪声（会导致每对结果随机偏移，从而可能交换排序）。对于检索而言，只有噪声是关键：一个始终对所有分数进行相同缩放的有偏估计器，其排序与精确分数完全一致。TurboQuant在1比特MSE量化下具有著名的乘性偏差 ()，这意味着约 0.36 的原始点积误差几乎完全来自与排序无关的尺度因子。为了公平比较，我们报告去偏后的RMSE：先拟合并移除最优乘性缩放因子然后计算。

零均值语料（d=768，500 个向量，每个向量 5 个查询，越低越好）：

角度	OSQ 非对称（去偏）	OSQ 1-4（去偏）	TQ 1-bit（去偏）	TQ 4-bit（去偏）
0	0.0035	0.0067	0.0083	0.0052
5	0.0042	0.0060	0.0085	0.0052
10	0.0057	0.0074	0.0091	0.0052
20	0.010	0.011	0.012	0.0053
45	0.027	0.029	0.025	0.0060
60	0.048	0.049	0.042	0.0074

平移语料（shift = 2.0，模拟真实 embedding 偏置，越低越好）：

角度	OSQ 非对称（去偏）	OSQ 1-4（去偏）	TQ 1-bit（去偏）	TQ 4-bit（去偏）
0	0.0008	0.0013	0.0073	0.0054
5	0.0013	0.0015	0.0076	0.0054
10	0.0021	0.0023	0.0084	0.0054
20	0.0041	0.0043	0.012	0.0055
45	0.012	0.012	0.025	0.0064
60	0.022	0.022	0.043	0.0078

在零均值数据上，原始误差数值（为简洁起见省略，TQ @1-bit 约为 0.363，几乎完全来自 2/ 的乘性偏差）具有误导性；真正有意义的是去偏后的排序噪声。

非对称列（浮点查询，1-bit 文档）与 TQ 最可直接对比，因为两者都只对文档进行量化：在 0 时 OSQ 的噪声低 2.4（0.0035 vs 0.0083）。这是各向异性损失（ = 0.1）的收益，它将精度集中在查询方向上，以牺牲非主方向为代价。

对称的 4-bit 查询恢复了一部分优势（0.0035 → 0.0067），说明在小角度下查询量化已经成为主要噪声来源。即便如此，OSQ 对称在 10 以内仍然以 1.2–1.4 优于 TQ @1-bit。

但在大角度下出现反转：TQ @1-bit 在 60 时噪声更低（0.042 vs 0.049）。这是因为 Hadamard 旋转将信息均匀分布到所有方向，而 OSQ 刻意偏向搜索中重要的方向。

TurboQuant 的 Qprod 呢？

TurboQuant 的内积版本 的设计目标正是修正这种偏差：用 b−1 bit 做 MSE 量化，再用 1 bit 做残差的 QJL sketch，从而构造无偏估计器。

但在 1-bit 情况下 不可行（MSE 位数为 0），因此最低只能从 2-bit 开始。然而对于排序任务，这种“修偏”反而更差：

用 ranking 不相关的无偏性，换取 ranking 相关的噪声控制能力。

在 60 时，的去偏噪声始终高于纯 MSE 方案（2-bit：0.031 vs 0.025；4-bit：0.011 vs 0.007），因为用于 QJL 修正的 bit 本可以更有效地用于量化本身。由于搜索只关心排序，MSE-only 反而更优：bias 是无害的，而额外 bit 降低的才是真正重要的噪声。

shift 数据上的变化

在 shift = 2.0 的数据上，OSQ 的质心中心化带来决定性优势。

在 0 时，去偏噪声降至 0.0008，比 TQ @1-bit 的 0.0073 低 9，比 TQ @4-bit 的 0.0054 低 7。中心化在量化前移除了主导共享分量，使量化器可以专注于信息残差。

TQ 的数据无关旋转无法利用这种结构，因此优势持续存在：

• 20：0.0041 vs 0.012

• 60：0.022 vs 0.043

OSQ 仍然保持竞争力。

关键结论

在 shift 数据上：

OSQ（1-bit/文档，去偏噪声 ≈ 0.001）优于
TurboQuant（4-bit/文档，去偏噪声 ≈ 0.006）

即：

更低噪声 + 5 更低存储（768 bits vs 4096 bits）

原因是：

• OSQ：数据依赖（中心化 + 各向异性优化）

• TQ：数据无关（旋转 + 均匀化）

最终观察

• TQ @4-bit：在零均值数据上是最低噪声（0.005–0.008）

• 但代价是约 5 存储

• 在 shift 数据上，它在小角度甚至不如tgcode OSQ symmetric

• OSQ 的优势来自“结构利用”，而不是 “空间均匀化”

正面对比：吞吐量

吞吐量正是均匀网格约束真正发挥优势的地方。以下是在 d=768、10k documents、Apple M2 Max 上的吞吐量数据，100 repetitions：

Bits	OSQ asymmetric	OSQ symmetric	OSQ 1-4	TurboQuant
1	67 ns/doc	7 ns/doc	—	275 ns/doc
2	132 ns/doc	14 ns/doc	—	293 ns/doc
4	94 ns/doc	22 ns/doc	14 ns/doc	216 ns/doc

OSQ 的对称 kernel 比 TurboQuant 快 10 – 40！

我们在 ARM NEON 上对两种实现都做了较为公平的优化尝试，但不能保证是最优实现。关键技术如下：

1-bit kernel

1-bit kernel 可简化为 popcount(a AND b)，使用 NEON 的 vcntq_u8 实现，每次处理 32 bytes，通过双 accumulator 实现流水线并行。

对于 d = 768，整个 packed 向量为 96 bytes，一次 pass 即可完成计算，因此达到 7 ns/doc。

2-bit kernel

2-bit kernel 将每个 2-bit index 分解为两个 bit-plane（在量化阶段预计算）。点积变为 4 次 AND + popcount：

在 14 ns/doc 下，其速度是 1-bit 的约 2 而不是 4，因为四个 plane pair 共享相同的数据加载；每个 96-byte plane 只读取一次，并在多个 pass 中复用。

4-bit kernel

4-bit kernel 使用直接 NEON nibble multiply，通过 vandq / vshrq 分离高低 nibble，再用 vpaddlq_u8 做扩展累加。

在 22 ns/doc 下，这比 16 次 bit-plane popcount 更快（16 = 4），因为避免了多次分解开销。

混合 41 kernel（生产主力）

混合 kernel 是生产核心方案：

• 4-bit query 被分解为 4 个 bit-plane（与 1-bit doc 同结构）

• 每个 document scoring 是 4 次 AND + popcount

即 RaBitQ 式分解

在 14 ns/doc 下，该方法：

• 比 TurboQuant 的 1-bit 路径快约 21.3

• 同时仅使用 3/4 的 document 存储

为什么 TurboQuant 慢？

TurboQuant 的瓶颈是 数据依赖 gather：

• 每个 coordinate 都需要从 centroid table 做 scalar load

• 再构造 NEON float vector

• 然后做 FMA

在 CPU 上：

gather + cache miss 成本远高于浮点计算本身
tgcode 因此 arithmetic 基本“免费”，memory access 才是瓶颈

---

核心结论

• OSQ：纯 SIMD bitwise + stream access（cache-friendly）

• TurboQuant：data-dependent gather（memory-bound）

因此：

OSQ 的优势本质是 memory layout + SIMD 可流式执行
TurboQuant 的瓶颈是 不可向量化的随机访问

也就是说，这个差距不是 “算得更快”，而是 “根本没有在等计算”。

结论

TurboQuant 是一个理论上非常优雅的构造，它直接建立在 OSQ 的形式化基础之上。其可证明的 MSE 上界、无偏内积估计器以及干净的数据无关设计，都是真正的贡献。对于需要校准分数（而不仅是排序）的应用，或者运行在 GPU 硬件上（gather 操作成本较低）的场景，TurboQuant 的架构是合理且有动机的。其无需校准的设计也非常适合“必须即时量化且零训练开销”的场景，例如 LLM 推理中的 KV cache 压缩。在这种情况下，每个向量在进入 cache 时被量化一次并在前向传播后丢弃，因此无法摊销逐向量的坐标下降开销。基于已知旋转后分布构造的固定 codebook 是恰当工具：旋转、量化、存储。

但对于 CPU 上的向量检索（Elasticsearch 及大多数在线系统的执行环境），从三个维度看经验结果非常一致：

MSE

TurboQuanttgcode 的优势主要来自 Hadamard 旋转，而不是 Lloyd-Max 质心优化。使用相同旋转的 OSQ 在 1–2 bit 时即可匹配 TurboQuant，在 3–4 bit 时仅落后约 1.1。OSQ 的稀疏预条件器已经在无 padding 的情况下提供了这一收益。

点积精度

在去除与排序无关的乘性偏差（包括 TQ 在 1-bit 下的 2/ 缩放因子）后：

• 在零均值数据上，小角度下 OSQ 比 TQ @1-bit 具有 1.2–1.4 更低的排序噪声

• 即使使用量化 query，并且没有 25% padding

• 这来自 = 0.1 的各向异性损失，将精度集中在 query 方向

在 shift 数据（更接近真实 embedding 分布）上，这种优势进一步扩大：

• 0：OSQ 0.0008 vs TQ @1-bit 0.0073

• 甚至优于 TQ @4-bit 的 0.0054

OSQ 在 1-bit 下的排序精度优于 TurboQuant 的 4-bit，同时存储不到其 1/5。TurboQuant 的 Qprod 试图修正偏差，但以增加噪声为代价，使得 MSE-only 对检索更优。

吞吐

对称 kernel 下 OSQ 速度提升 10–40，混合 41 kernel 达到 14 ns/doc，而 TurboQuant 为 293 ns/doc（使用 NEON intrinsics）。

这种差异不是微优化可以消除的常数项，而是结构性差异：

integer streaming arithmetic vs lookup-table + gather

总结

均匀网格看似是一种折中方案，但实际上是正确的设计选择：

• 在旋转对齐后，MSE 优势几乎消失

• 但统一网格释放了整数 SIMD pipeline

• 从而实现亚毫秒级大规模搜索

换句话说：

TurboQuant 优化的是 “统计最优性”
OSQ 优化的是 “机器执行路径”

而在 CPU 检索系统中，后者才是决定性因素。

原文：https://www.elastic.co/search-labs/blog/elasticsearch-bbq-osq-vs-turbo