turbovec vs FAISS终极对决：3.4倍搜索速度背后的完整实测报告

turbovec vs FAISS终极对决3.4倍搜索速度背后的完整实测报告【免费下载链接】turbovecA vector index built on TurboQuant, written in Rust with Python bindings项目地址: https://gitcode.com/GitHub_Trending/tu/turbovecturbovec 是一个用 Rust 编写的向量索引库Vector Index提供 Python 绑定底层基于 Google 研究的 TurboQuant 量化算法。在 100 万级向量、d1536/d3072 的真实数据集上它的向量搜索速度平均比 FAISS 快3.4 倍而内存占用只有 float32 原始数据的1/8——1000 万篇文档的语料FAISS 路线需要 31 GB 内存turbovec 只需 4 GB。下面这份报告全部来自项目内置基准套件跑出的真实数据覆盖 ARM 与 x86 两大架构、2-bit 与 4-bit 两种精度、单线程与多线程共 8 种组合没有一项是估算值。 先算一笔内存账量化压缩能省多少向量搜索的第一道坎往往不是速度而是内存。turbovec 用 TurboQuant 把每个浮点向量压成 2-bit 或 4-bit 编码以下是 10 万条向量的实测压缩结果数据见benchmarks/results/compression.json向量维度float32 原始大小turbovec 2-bitturbovec 4-bit2-bit 压缩比d1536586 MB37 MB74 MB15.8×d30721.17 GB74 MB147 MB15.9×d200GloVe76 MB5.1 MB9.9 MB14.8×也就是说同样 1000 万文档的 RAG 语料float32 要 31 GB 内存turbovec 2-bit 模式约 4 GB单机就能装下且无需托管服务、数据不出本机可以搭配任意开源 embedding 模型搭完全离线的 RAG 栈。⚙️ 测试方法这组数据是怎么跑出来的公平性是基准测试的生命先把环境交代清楚数据规模100K 向量 × 1K 查询k64每组取 5 次运行的中位数ARM 环境GCP c4a-standard-8Google Axion8 vCPUx86 环境Intel Xeon Platinum 8481CSapphire Rapids8 vCPU对比基线FAISSIndexPQFastScan子量化器数量按 bit 率对齐2-bit 对应 md/44-bit 对应 md/2与 turbovec 吃下相同的内存预算测试脚本每个用例都是独立脚本统一存放在benchmarks/suite/原始结果 JSON 在benchmarks/results/任何人都可以用benchmarks/download_data.py下载数据后复现。⚡ 搜索速度实测4-bit 精度下平均快 3.4 倍x86 平台单线程每查询耗时ms精度d1536d30722-bit0.961 vs 1.225快 1.3×1.934 vs 2.556快 1.3×4-bit0.739 vs 2.565快 3.5×1.480 vs 5.208快 3.5×左列为 turbovec右列为 FAISS单位 ms/查询。ARM 平台单线程每查询耗时ms精度d1536d30722-bit1.566 vs 2.026快 1.3×3.178 vs 3.946快 1.2×4-bit1.095 vs 4.023快 3.7×2.364 vs 7.947快 3.4×多线程8 线程下差距依然保持d1536 4-bit 在 x86 上 0.185 ms vs 0.59 msARM 上 0.143 ms vs 0.499 ms。8 个组合、两种架构下turbovec 全部胜出4-bit 平均快 3.4 倍2-bit 平均快 20%26%。为什么快答案在turbovec/src/里的手写 SIMD 内核ARM 上用 NEON 的 SDOT/SMMLA 点积指令直接扫向量为主的布局x86 上用 AVX-512 VNNI 加vpermb查表扫描AVX2 和标量版本自动兜底。而 FAISS 的 FastScan 需要为编码为主的布局做适配这就是差距的根源。 召回率实测更快但找得更准吗速度提升若以精度为代价就毫无意义。对照 FAISSIndexPQLUT256、nbits8生产级 PQ 的默认选择以下是校准版 TQ 的 R1 召回率数据集2-bitturbovec vs FAISS4-bitturbovec vs FAISSOpenAI d15360.901vs 0.8720.959 vs0.966GloVe d2000.572vs 0.5640.860vs 0.841四个组合里 turbovec 拿下三个的 R1唯一落后的 d1536 4-bit 也只差 0.7 个百分点且在 k≥4 后两者都达到 1.0。关键 trick 是 TQ 校准建索引前调用一次index.calibrate(sample)约 1024 条随机采样即可给每个坐标拟合一个平移和缩放就能把 2-bit 下的召回差距反超 13 个百分点——没有重训练没有重建索引。 写入与删除在线索引的真实延迟FAISS 的老问题之一是离线建库必须先训练 codebook 才能写入。turbovec 是在线摄取Online Ingest——add()之后向量立即可搜语料增长无需 rebuild。以 x86 d1536 4-bit 为例操作turbovecFAISS差距单条插入8.35 µs78.65 µs快 9.4×100 条批量插入摊薄到单条5.72 µs31.86 µs快 5.6×按 id 删除 1 条0.89 µs~512 ms快约 57 万倍删除一项是数量级差距FAISS 的remove_ids每次都要重打包全部存储编码10 万条索引删一条要半秒而IdMapIndex.remove(id)是 O(1) 的 swap-and-pop百万条索引删除仍是微秒级。 持久化增量保存只写变化的部分write(path)/load(path)整库快照fsync 原子重命名崩溃安全sync(path)增量保存只持久化上次 sync 之后变化的部分每次调用仅 1 次 fsync。删除一条向量或追加一小批无论索引多大都是毫秒级。10 万条 d1536 4-bit 索引x86的实测加载只要10 msFAISS 26 ms加载后首次搜索 13.2 msFAISS 30.3 ms。完整的改动 1K 向量 → 保存 → 重开 → 首查往返链路约 433 ms这正是真实 embedding 存储每次 checkpoint/resume 要付的成本。 三步上手从安装到第一次向量搜索Python 侧一行安装pip install turbovec核心用法只有 4 行from turbovec import TurboQuantIndex index TurboQuantIndex(dim1536, bit_width4) index.add(vectors) # float32 的 (n, dim) 数组即加即搜 scores, indices index.search(query, k10)再往上走两步即可覆盖生产场景稳定 ID 与删除换用IdMapIndexadd_with_ids()/remove(id)ID 贯穿增删改查混合检索过滤search(query, k10, allowlistallowed_ids)在 SIMD 内核内部按 32 向量块短路过滤不放大召回损失——SQL、BM25、权限系统的候选集可以直接传入框架集成官方提供了 LangChain、LlamaIndex、Haystack、Agno 四个框架的 drop-in 替换替换各自的 InMemory 向量存储见docs/integrations/完整 API 参考见docs/api.md。Rust 侧同样一行接入cargo add turbovec。 结论什么时候该把 FAISS 换成 turbovec内存敏感1000 万 文档、单机部署2-bit 下 15.8× 压缩这是最大的卖点延迟敏感RAG 在线检索、多租户过滤搜索4-bit 下平均 3.4× 搜索加速过滤内置于内核语料持续变化高频插入/删除在线摄取 O(1) 删除 增量sync()彻底告别删一条、重建一小时隐私合规纯本地、纯 Rust 核心可完全离线部署。FAISS 依然是功能最全的向量检索库但如果你只需要准、快、省三件事turbovec 的实测数据已经给出了足够有说服力的答案。想深挖实现细节源码入口在turbovec/src/全部基准脚本与结果在benchmarks/目录欢迎复现每一个数字。【免费下载链接】turbovecA vector index built on TurboQuant, written in Rust with Python bindings项目地址: https://gitcode.com/GitHub_Trending/tu/turbovec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考