项目 PPT 图1000万条文档的向量索引原本占31GB内存turbovec 只用4GB搜索速度还比 FAISS 快 20% 一、小白入门turbovec 是什么如果你做过 RAG检索增强生成或者向量搜索一定遇到过这个问题向量太大了。一个1536维的OpenAI嵌入用 float32 存储需要6KB。1000万条文档 →60GB内存。这还没算索引结构、查询时的开销。跑在单机上基本不可能。turbovec 解决了这个问题。它基于 Google Research 在 ICLR 2026 发表的TurboQuant 算法——一种不依赖数据分布的量化器数学上逼近信息论的下界而且不需要训练。 一句话理解turbovec 把 float32 向量压缩到2~4 比特/维内存降到原来的1/8 到 1/16搜索速度比 FAISS 还快 12~20%。 直观对比指标float32turbovec 4-bitturbovec 2-bit1536维向量大小6 KB768 字节384 字节1000万条内存占用~60 GB~7.7 GB~3.8 GB压缩比1x8x16x召回率(R1)100%~93–97%~87–93%你以为压缩就要牺牲速度在 ARM 芯片上turbovec 比 FAISS快 12–20%在 x86 上4-bit 配置比 FAISS 快 1–6%️ 二、安装与使用3 行代码上手Python 安装pipinstallturbovec基础用法fromturbovecimportTurboQuantIndex# 创建索引1536维4-bit量化indexTurboQuantIndex(dim1536,bit_width4)# 添加向量numpy数组shape: n×dimindex.add(vectors)index.add(more_vectors)# 搜索返回 (分数, 索引位置)scores,indicesindex.search(query_vector,k10)# 保存与加载index.write(my_index.tq)loadedTurboQuantIndex.load(my_index.tq)需要稳定 ID支持删除importnumpyasnpfromturbovecimportIdMapIndex indexIdMapIndex(dim1536,bit_width4)# 带着你的外部ID添加index.add_with_ids(vectors,np.array([1001,1002,1003],dtypenp.uint64))# 搜索返回你的IDscores,idsindex.search(query,k10)# 按ID删除O(1)index.remove(1002)# 保存/加载index.write(my_index.tvim)loadedIdMapIndex.load(my_index.tvim) 核心特性过滤搜索先让另一个系统SQL、BM25、权限系统筛选出候选ID集合然后在这个集合内做向量搜索# 第一阶段外部系统筛选出允许的IDallowednp.array(db.execute(SELECT id FROM docs WHERE tenant?,(tenant,)).fetchall(),dtypenp.uint64)# 第二阶段只在允许集合内做密集重排序scores,idsidx.search(query,k10,allowlistallowed)性能优势过滤逻辑打在SIMD 内核内部——32个向量一块如果整块都不在允许集合中直接跳过不花任何计算成本。输出长度精确为min(k, len(allowed))不会补垃圾结果。 三、高阶原理turbovec 为什么能做到 TurboQuant 的核心直觉每个向量可以看作高维球面上的一个方向长度单独存。TurboQuant 做了一个聪明的转换1. 归一化去掉长度norm只保留方向。长度单独存为一个 float32。2. 随机旋转用一个固定的随机正交矩阵乘所有向量。旋转之后每一维独立服从相同的分布Beta分布高维下逼近高斯——与原始数据无关。这就是“data-oblivious”不依赖数据的来源。3. 每维校准TQ可选理论分布是渐近的。对于有限维度尤其是低维用前几条数据算一个每维的偏移和缩放把实际分布“拉”回理论分布。校准一次就冻结后续添加不再重新训练。召回率提升最多1.4 个百分点2-bit 低维场景。4. Lloyd-Max 标量量化既然分布已知就可以离线预计算最优的量化桶边界和中心值2-bit → 4个桶4-bit → 16个桶。这些桶从数学算出来不是从数据学出来的。5. 比特打包每个坐标变成小整数0–3 或 0–15紧密打包进字节。1536维 → 384字节2-bit或 768字节4-bit。6. 长度重归一化RaBitQ 技巧量化会让向量的“长度”被低估。turbovec 在编码时额外存一个标量修正因子搜索时乘回去把有偏的估计变成无偏。零额外存储成本零查询时间成本。 搜索时发生了什么查询向量旋转一次与数据库向量相同SIMD 内核直接对着量化后的码本打分不解压任何数据库向量使用 nibble-split 查找表 u16累加器借鉴 FAISS FastScan 的 pack 布局 结果场景效果ARM (Apple M3 Max)比 FAISS FastScan 快 12–20%x86 (Intel Xeon)4-bit 比 FAISS 快 1–6%2-bit 与 FAISS 持平或略慢 2–4%召回率 (d1536)4-bit R1 ≈ 96–97%2-bit R1 ≈ 88–92%压缩比最高16:1 框架集成turbovec 提供即插即用的替换不需要改 pipeline# LangChainpipinstallturbovec[langchain]# 替换langchain_core.vectorstores.InMemoryVectorStore → turbovec# LlamaIndexpipinstallturbovec[llama-index]# 替换llama_index.core.vector_stores.SimpleVectorStore → turbovec# Haystackpipinstallturbovec[haystack]# 替换haystack.document_stores.in_memory.InMemoryDocumentStore → turbovec# Agnopipinstallturbovec[agno]# 替换agno.vectordb.lancedb.LanceDb → turbovec Rust 也能用cargoaddturbovecuseturbovec::TurboQuantIndex;letmutindexTurboQuantIndex::new(1536,4);index.add(vectors);letresultsindex.search(queries,10);index.write(index.tv)?; 实测数据搜索速度对比ARM M3 Max单线程配置FAISS (QPS)turbovec (QPS)提升d1536, 2-bit~12,000~14,50021%d1536, 4-bit~10,000~11,50015%d3072, 2-bit~6,500~7,30012%d3072, 4-bit~5,800~6,60014%多线程下趋势一致turbovec 全面领先。召回率d15364-bitk64kFAISS Rkturbovec Rk差193.8%96.7%2.9%498.1%98.8%0.7%899.0%99.4%0.4%1699.5%99.7%0.2%压缩对比turbovec 逼近 Shannon 信息论下界比标准 PQ 更接近理论极限。✅ 总结turbovec 适合谁场景为什么选 turbovecRAG 本地部署内存敏感隐私要求高不能上云边缘设备 / 移动端ARM 上速度比 FAISS 快 20%省内存实时向量检索过滤搜索在内核层做不额外开销不想碰训练环节零训练在线 ingest 直接可用已有 FAISS 代码替换 import 即可不需要重写 pipeline 立即开始pipinstallturbovecfromturbovecimportTurboQuantIndex indexTurboQuantIndex(dim1536,bit_width4)index.add(your_embeddings)scores,indicesindex.search(query,k10)论文TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate (ICLR 2026)GitHubgithub.com/RyanCodrai/turbovec文档docs/api.mdturbovec—— Google 级的向量压缩跑在你的笔记本上。MIT 协议Rust 内核Python 绑定。开源自托管不进云。