AI 时代的 SQLite？TriviumDB 与主流向量检索方案性能对比

前言

这篇把 TriviumDB 的 QuIVer ANN 索引和 hnswlib、FAISS HNSW、FAISS IVF-PQ、USearch 放在同一台机器上，用同一批数据、同一批查询、同一套指标，实测 Recall@10 和 QPS 的权衡曲线。所有数字都是本机跑出来的，跑法、参数、环境都在文末，可以照着重跑。结论的边界先划清楚，再给数字。 测试环境（本文所有跑分在同一台机器上完成，完整清单见 §2.3） 组件配置CPUIntel Core i5-13490F（10 核 20 线程；本机实际只暴露 16 逻辑处理器，AVX2）内存2 × 16 GB DDR5-6000（A-DATA XPG Lancer CL36，双通道）显卡NVIDIA GeForce RTX 4060 Ti 16 GB（CPU-only，未参与计算）存储C 盘：Crucial P3 Plus 1TB（CT1000P3PSSD8，NVMe），另有 SanDisk Ultra 3D NVMe；跑分数据/索引在 C 盘桌面系统Windows 11 ANN 跑分对内存带宽很敏感，DDR5-6000 双通道和 DDR4-3200 的 QPS 能差出百分之几十；SSD 影响构建和冷数据读取。显卡这轮不参与计算，列出来是免得有人以为开了 GPU。

省流速看

先说场景。TriviumDB 的定位是 AI 嵌入式记忆引擎，服务 RAG、Agent 记忆、语义缓存这类用 LLM embedding 的应用。

同机、同数据、同查询、同指标的前提下，实测结论：

1. Recall@10 到 90% 时，TriviumDB 的 MT-QPS 是 hnswlib / FAISS HNSW 的约 2.9×（73,258 vs 25,352 / 25,615，§5.2）。它做到这点的同时还自带向量+图+文档三位一体，纯向量库不仅慢一截，还只能管一种数据。
2. QuIVer 有明确的适用边界，论文叫"不可能三角"：激进压缩 × 高吞吐 × 全数据兼容，三选二。边界外的数据，比如 SIFT 非负直方图、GloVe 低维词向量，Recall 会明显塌。这条边界用实测数据画在第七节。
3. FAISS IVF-PQ 在 768 维上是压缩之王，但要 OPQ 训练 + Refine 精排两层补丁，构建耗时是 HNSW 类的 6 倍量级。TriviumDB 的 BQ 免训练，构建时间和 HNSW 同类。
4. "LLM embedding 优势区"不能一概而论。Cohere-1M 是强主场（2.9×），但补跑的 MiniLM-1M 上 TriviumDB 没有复现优势，同召回下 MT-QPS 约为 hnswlib 的 1/4、FAISS HNSW 的 1/3（§7.2）。引用论文或评测页的"优势区"之前，建议用自己数据复测。

一句话定位：TriviumDB 的向量检索在 Cohere-1M 这类目标场景里是第一梯队，同召回下吞吐约为 HNSW 类的 2.9×，内存只有其 1/4.7；但 MiniLM-1M 等其它 LLM embedding 上优势不保证。它的护城河在三位一体和零运维，不在所有数据通吃。

一、为什么向量检索值得单独测

"能不能用"和"快不快"是两件事。RAG、Agent 记忆、语义缓存里，向量检索在主链路上：一次问答 LLM 生成要几百毫秒到几秒，召回这一步可能要并行打几万甚至上百万次相似度计算。基座慢，上层再花哨也救不回来。

TriviumDB 的卖点不是"又一个向量库"，而是"一个嵌入式文件同时管向量+图+文档"。那它作为向量引擎本身到底硬不硬？如果向量检索被纯向量库甩开一个量级，三位一体的价值就站不住。所以这篇只把向量检索拎出来，和同生态位的纯向量库对撞，用同一台机器、同一批数据、同一套指标，看清楚行在哪、不行在哪。

二、对比对象与方法论

2.1 选谁比

选的都是嵌入式方案（无独立进程、无网络），和 TriviumDB 同一生态位，也是官方脚本 benches/bench_baselines.py 原生支持的库（脚本链接）。

为什么没有 LevelDB / RocksDB / SQLite？它们是嵌入式方案，但定位是 KV / 关系型存储，原生不做 ANN 近邻搜索。拿它们比 Recall@10-QPS，得自己在外层接暴力扫描或向量索引，比的是"组装方案"而不是库本身的向量检索能力。本文只比开箱即用的向量检索库/数据库，所以不纳入。

2.2 对比守则

1. 只报同机对比：所有库同一台机器、同一轮会话跑完，不搬别处的数字。
2. 同数据、同查询、同指标：每个数据集固定同一批训练向量、同一批查询、同一份 Ground Truth；统一 L2 归一化后按余弦度量；统一 Recall@10 和 QPS 口径。
3. 放完整参数扫描：每条 Pareto 曲线都是 ef/nprobe 从松到紧扫出来的，不是挑单点。
4. 单线程和多线程分开报：正文曲线用 MT，表格附 1T。MT=16，原因见下条。
5. 线程数取本机实际可用数：CPU 标称 20 线程，但本机操作系统只暴露 16 个逻辑处理器（亲和掩码 0xFFFF，疑似虚拟化或核心隔离限制）。所有库统一 MT=16 才公平（baseline 显式设 TRIVIUM_MT_THREADS=16，TriviumDB 的 rayon 池默认就是 16）。
6. 只测向量检索：图遍历、文档过滤、混合检索不在本文范围。
7. 服务型库不硬比：Qdrant / Milvus / Weaviate 多一层独立进程和网络，硬比不公平也没信息量。

2.3 测试环境

CPU-only：所有方案只在 CPU 跑（i5-13490F 无 AVX-512，AVX2 是共同起点），不用 GPU、不用量化推理加速。这也是嵌入式方案的真实使用场景。

三、数据集：主场选对，边界画清

3.1 主数据集：Cohere-1M（768 维 LLM embedding）

选它有两个原因。它是 TriviumDB 论文的主评测数据集，也是官方基准脚本的默认配置，脚本里所有参数网格都是为 768 维设计的。更重要的是它代表 TriviumDB 的目标场景，AI 嵌入式记忆里的向量就是这种分布。用目标场景的数据做场景内对比，才公平。

3.2 边界对照：SIFT-128 与 GloVe-100

为了不把主场优势包装成全面优势，额外跑了两个边界外的数据集作对照：

预期依据：QuIVer 论文（arXiv:2605.02171）在多数据集评测里给了明确的适用边界，BQ 原生拓扑对 cosine-native 对比学习 embedding 高度有效（5 个数据集 ≥88% Recall@10 @ ef=64），对 CLIP 类多模态数据中等有效（71–78%），对欧氏原生或无结构分布实证不适合（<15%）。论文把这概括为"不可能三角"。第七节用本机实测验证这条边界。

3.3 数据准备（官方脚本）

脚本：scripts/prepare_all.py。所有数据集统一 L2 归一化 + 余弦度量；SIFT 原始是欧氏，归一化后按余弦重算了精确 Top-10 GT。

口径说明：SIFT/GloVe 的查询集从 10,000 条抽样到 1,000 条。官方脚本的暴力基准在 10k 查询 × 1M 基座下要 ~40GB 相似度矩阵，超出 32GB 内存；用固定种子确定性抽样，同批查询用于所有库。Cohere-1M 官方查询集本身就是 1,000 条，不用抽。

3.4 来自评测页的 9 数据集梯度：优势区间不是"所有 LLM embedding"

在 Moonlight 的 QuIVer 评测解读页（https://www.themoonlight.io/zh/review/quiver-rethinking-ann-graph-topology-via-training-free-binary-quantization）里，论文的 9 个数据集被分成四档：

所以"数据集在不在论文列表里"不能直接回答"是不是 QuIVer 优势区"。MiniLM/Cohere/DBpedia 才是论文声称的优势区，GloVe 只是可用，SIFT/GIST/随机是崩溃区。我们已有 Cohere（优势）、SIFT/GloVe（边界），本轮补跑了 MiniLM-1M，结果见第七节。

四、参数怎么配的

所有 HNSW 类统一 M=32、ef_construction=128（TriviumDB 的 QuIVer 也是 m=32、ef_c=128、α=1.2，默认参数对齐），只扫查询参数 ef（9 档）。

FAISS IVF-PQ 用 nlist=1024、k_factor=10、m_pq=96（768 ÷ 96 = 8 个子量化器，官方脚本为 768 维设计的典型值），扫 nprobe（8 档）。

五、主结果：Cohere-1M 的 Recall@10-QPS Pareto 曲线

[Cohere-1M Recall@10-QPS Pareto 曲线

5.1 曲线解读

图里每条线都是各自 ef/nprobe 完整扫描扫出来的，不是挑点。三个点：

1. 整条曲线上 TriviumDB 都在 HNSW 类上方，差距约 2.9×，全程没有反超。 最常用的工作点 Recall@10≈90%，TriviumDB 的 MT-QPS 约 73,258，hnswlib 25,352、FAISS HNSW 25,615、USearch 19,133。这个倍数落在论文宣称的 2.5–5.5× 区间内。不是略快一点，是量级差。
2. 往高 QPS、低 recall 的方向走，QuIVer 优势更大。 ef=10 时 TriviumDB 是 55% recall @ 161,324 QPS，hnswlib 同档 80.4% @ 40,560 QPS，用更低的召回换到近 4× 的吞吐。语义缓存、粗召回去重、实时 Top-N 这类不要求极致召回但要求扛高 QPS 的场景，正好吃这套。
3. FAISS IVF-PQ 是另一条路线。 它用 OPQ+PQ 把存储压到最低（码本 92 MB），代价是构建要训练（967.6 s，HNSW 类的 6×），到 90% recall 的吞吐约 5,490 QPS，是 TriviumDB 的 1/13。它的价值在极致压缩和磁盘友好，不在高吞吐。

5.2 关键截点：Recall@10 ≈ 90% 时的吞吐对比

下表 MT-QPS / 1T-QPS 是 Recall@10=90% 处对 ef/nprobe 曲线线性插值得到的，和图表完全自洽。同机、同数据、同查询、MT=16 线程。

横向比：同召回下 TriviumDB 的 MT 吞吐约为 hnswlib 的 2.89×、FAISS HNSW 的 2.86×。纵向比：开多线程后 TriviumDB 从 1T 8,618 涨到 MT 73,258，约 8.5× 扩展比；hnswlib 从 4,379 到 25,352，约 5.8×。QuIVer 的多线程扩展效率也更高。

Cohere-1M 同召回吞吐对比 · R@10≈90% 处插值

图：同召回下 TriviumDB（紫）领先 HNSW 类约 2.9×，USearch 居中，FAISS IVF-PQ 走极致压缩路线吞吐最低。

六、构建时间与内存占用（Cohere-1M）

内存口径：baseline 是脚本估算值（向量 2,930 MB + 邻接 244 MB），TriviumDB 是 index.stats().hot_bytes 实测值，两边不完全一致，只看量级。1M×768 的 f32 原向量本身就要 ~3 GB，TriviumDB 的 hot 区（签名索引）只要 675 MB，全量 f32 精排按需从冷区读，这是"2-bit 签名 + 冷热分离"的收益。

构建速度上，TriviumDB 的 BQ 量化免训练，对归一化向量取符号位就行，构建时间和 HNSW 同类甚至更快。IVF-PQ 要先跑 OPQ 训练，单这一步就把构建拉到近 16 分钟。

Cohere-1M 构建耗时与索引内存

图：左 — 构建耗时（对数），TriviumDB 54 s 约为 HNSW 类的 1/3、IVF-PQ 的 1/18；右 — 索引内存（对数），TriviumDB Hot 675 MB 约为其它库的 1/4.7。

七、边界：实测画出的适用边界 + 测不了的

7.1 适用边界实测（SIFT-128 / GloVe-100）

边界数据集 Recall@10 封顶对比

图：边界数据集上 TriviumDB Recall 封顶远低于 hnswlib（ef=800 口径），与论文"不可能三角"一致。

[SIFT-128 全 Pareto 曲线

图：SIFT-128 同机同查询下，TriviumDB（紫）ef 拉到 800，Recall 也封顶在 43% 左右，hnswlib / FAISS HNSW 已到 99%+。

GloVe-100 全 Pareto 曲线

图：GloVe-100 上 TriviumDB 封顶约 69% 后不再随 ef 上升，HNSW 类 ~97%。这两条完整曲线比单点更能说明边界。

QuIVer 在 LLM embedding 之外的数据上不做任何承诺。如果你的数据不是 embedding 分布（图像直方图、低维词向量、高固有维度），请选 HNSW 类方案。这条边界是论文主动划的，本文用本机实测验证了它，这也是"不可能三角"的代价。

口径说明：SIFT-128 上 QuIVer 封顶 43.4%，比论文"<15%（欧氏口径）"高，因为本文对 SIFT 做了 L2 归一化 + 余弦度量，和主场 Cohere 口径统一，归一化削弱了欧氏直方图的极端性。严格按论文的欧氏原生口径，塌得更彻底。GloVe-100 的 69.4% 说明低维 / 高固有维度是 QuIVer 的软肋。

为什么？QuIVer 的签名是 2-bit 二进制量化（BQ），对归一化后的向量按每维符号位拼成二进制签名做粗筛。SIFT 是图像局部直方图特征，归一化后几乎每维都大于 0，所有向量的符号签名几乎全为 1，签名失去判别力，粗筛退化成近似随机。GloVe 只有 100 维，符号位本来就少，量化信息量不足，天花板压在 70% 上下。论文把这套规律概括为"不可能三角"：激进压缩（2-bit BQ）、高吞吐、全数据兼容，三者只能取二。QuIVer 选了前两个，代价是放弃对 SIFT/GloVe 这类分布的通吃。

7.2 LLM embedding 内部的"反例"：MiniLM-1M 没有复现 QuIVer 优势

MiniLM-1M Recall@10-QPS Pareto

论文和评测页都把 MiniLM-1M 放在 SOTA 优势区，所以补跑了它（1M×384 维，all-MiniLM-L6-v2，同查询 1000 条，同 16 线程）。结果和 Cohere-1M 很不一样：

MiniLM-1M 上 TriviumDB 的吞吐没有超过 HNSW，约是 hnswlib 的 1/4、FAISS HNSW 的 1/3。它的 recall 能到 90% 以上，不是 SIFT 那种崩塌，但要达到同等 recall 需要更大的 ef，QPS 被精排和导航成本拖低。

口径说明：MiniLM 的 USearch 基线因为构建耗时过长没跑完，上表只有完成的两家 HNSW。TriviumDB 和 baseline 在同一台机器同一轮会话里交替跑完，但构建和搜索有重叠，绝对 QPS 会受并发影响。本文不做跨机器推广。

这个结果说明，"LLM embedding = QuIVer 优势区"不能一概而论。Cohere-1M 是强主场，MiniLM-1M 在本机是反例。论文评测页的优势区间可能依赖具体 embedding 分布、有效维度、查询难度和实现版本，引用"优势区"之前以自己的数据复测为准。

7.3 没测的项

1. VSAG 缺测：pyvsag 0.0.11 的 Windows wheel 只打包了 Linux 原生库（_pyvsag.cpython-310-x86_64-linux-gnu.so），Windows 上无法 import，官方脚本如实输出 [跳过]。同机原则下不拿别机数字顶替。
2. 只测了向量检索：图遍历、文档过滤、混合检索不在本文。
3. IVF-PQ 在 100 维的精度天花板（附带发现）：官方脚本的 IVF-PQ 网格要求 m_pq 整除维度，100 维下全部跳过；用同一套测量函数补跑 m_pq=20 时 Recall@10 封顶 ~89%，这是 PQ 量化在低维数据上的固有精度损失。
4. ef 语义不完全等价：各库 ef 是各自实现的搜索波束，数值相同不代表路径相同，曲线本身诚实。
5. 内存口径：baseline 是估算值，TriviumDB 是 index.stats().hot_bytes 实测值，不完全一致，只看量级。
6. 归一化口径：SIFT/GloVe 转余弦后与 ann-benchmarks 官网欧氏口径不可直接对比。

这些没跑的项不影响核心结论。DBpedia-1M 未跑只影响优势区覆盖面的完整度，不影响"Cohere 强主场 + MiniLM 反例 + SIFT/GloVe 边界"这条结论；MiniLM 的 USearch 没跑完，但有 hnswlib/FAISS HNSW 两个对照，足够支撑该节判断。想更完整的话可以后续补 DBpedia-1M 和 MiniLM USearch，但不阻塞这篇文章。

八、复现方式

下面是可以直接照抄的命令。先按 §2.3 准备好官方脚本和数据集，再依次跑外部库基线、IVF-PQ 补充、TriviumDB 本体，最后解析汇总画图。

8.1 官方脚本（均来自仓库 TriviumDB）

• 向量检索基线（hnswlib / FAISS HNSW / USearch / VSAG）：benches/bench_baselines.py
• TriviumDB 本体基准（QuIVer）：benches/bench_cohere1m.rs
• 数据集准备：scripts/prepare_all.py
• 方法论文档：README_QUIVER.md

8.2 本次实测命令

8.3 重跑要注意的两件事

1. 线程数取本机实际可用数：CPU 标称 i5-13490F（20 线程），但本机只暴露 16 个逻辑处理器，所有库统一用 MT=16 才公平。重跑前先 python -c "import os; print(os.cpu_count())" 确认你的可用核数，统一口径。
2. VSAG 在 Windows 上跑不了：pyvsag 0.0.11 的 wheel 只打包了 Linux 原生库，Windows 无法 import，官方脚本会输出 [跳过]。本文没有用别机的 VSAG 数字顶替，保住"只报同机对比"的底线。

所有 QPS 是 1,000 条查询 × 1M 基座下的实测吞吐均值；Recall@10 以精确暴力 Top-10 为 ground truth。换机器、换版本、换数据分布，数字都会变。本文结论只在上述环境和 LLM embedding（Cohere-1M / MiniLM-1M）场景下成立。

注：本文代码与数字基于 2026-08-17 ~ 08-18 本机两个窗口的实测（环境见 §2.3），不构成任何性能担保；换机器、换版本、换数据分布结果都会变。