turbovec 是一个用 Rust 编写的向量索引库，并提供了 Python 绑定。它的核心是实现了谷歌研究院提出的 TurboQuant 算法，这是一种“数据无关”的量化器，能以接近最优的失真度压缩向量，且无需单独的训练阶段。
该项目在 Hacker News 等社区获得了广泛关注，GitHub 上已获得超过 1 万星标。
核心特性与优势
turbovec 致力于打造一个高性能、低内存、易用且完全本地化的向量检索方案，其主要特点包括：
- 极高的内存效率：能将 float32 格式的向量数据压缩 8-10 倍。例如，一个占用 31 GB 内存的 1000 万文档语料，turbovec 仅需 4 GB 即可承载。
- 出色的检索速度：通过手写的 SIMD 内核（支持 ARM NEON 和 x86 AVX-512/AVX2），在多项测试中速度均超越 FAISS。在 4-bit 配置下，平均速度是 FAISS 的 3.4 倍。
- 无训练、在线即时索引：添加向量时直接索引，无需任何预训练步骤、参数调优或随数据增长而重建索引。
- 增量持久化存储：sync() 方法支持增量保存，只记录变更部分，确保崩溃安全且效率极高，即使是大型索引，删除或追加操作也仅需毫秒级。
- 原生支持过滤搜索：支持在搜索时传入 ID 白名单进行过滤，且过滤逻辑在 SIMD 内核中直接执行，不会牺牲召回率。
- 完全本地化与隐私安全：所有数据均在本地处理，不会离开你的机器或 VPC，非常适合对隐私敏感的 RAG 应用。
介绍
干掉31GB内存、跑得比FAISS还快！turbovec把向量索引塞进4GB的秘密！
一个1000万文档的语料库，FAISS吃掉31GB内存，turbovec只用了4GB——而且搜索速度还更快。这事怎么做到的！
2026年3月，谷歌研究院在ICLR 2026上发布TurboQuant算法。不到一个月，个人开发者Ryan Codrai就用Rust把它落地成了开源向量索引库turbovec。6月8日单日斩获1554个GitHub星标，成为当天增长最快的基础设施项目。截至7月，累计12690星、1124分支。一个个人项目，在向量检索这个被FAISS统治多年的领域撕开一道口子。
但等等——压缩16倍还跑得更快？这事听着就像“油耗减半动力翻倍”一样违反直觉。量化压缩必然损失精度、增加计算开销，这是常识。turbovec凭什么打破这个常识？还是说，它其实偷偷付了某些代价只是没告诉你？
31GB变4GB：一个数字背后的数学暴力
先搞清楚turbovec到底压缩了什么。
向量检索的核心是“找最相似”。你把文档、图片、对话转成一串浮点数——也就是向量——然后拿用户的问题向量去库里找最接近的那几个。1536维是OpenAI嵌入模型的标配维度。一条1536维的float32向量占6KB内存。1000万条就是60GB。FAISS用了一些压缩技巧把它压到了31GB。turbovec呢？4GB。
怎么做到的？把每个坐标从32位浮点压缩到4位整数。1536维×4比特=768字节每条。1000万条就是7.5GB——等等，这不应该是7.5GB吗，怎么是4GB？因为TurboQuant还有更狠的第二阶段压缩。第一阶段PolarQuant做主体压缩——随机旋转向量、转极坐标、量化角度；第二阶段QJL用仅1比特的残差压缩消除第一阶段遗留的微小误差。两轮压缩叠加，最终把7.5GB干到了4GB。
但这套操作有个前提：TurboQuant假设输入向量是L2归一化的——也就是单位向量。如果你的嵌入模型输出的不是单位向量，直接往里塞，召回率会崩。这事文档里提了一嘴，但没加粗标红。
不训练、不调参、不加新数据就重建索引——这违反直觉吗？
FAISS的Product Quantization需要训练。你得拿一批代表性数据跑K-means，学出每个子空间的聚类中心。训练集分布必须和实际查询分布一致，否则量化器学偏了召回率就完蛋。百万级向量上K-means跑起来慢得让人想摔键盘。加新数据后codebook可能过时，得重建整个索引。
TurboQuant是data-oblivious的——数据无关。不需要任何训练数据，不需要校准集，向量来了直接量化。它靠的是数学变换本身的稳定性，而不是从数据里学出来的统计规律。
这意味着你可以随时往索引里塞新向量，不用停服务、不用重建、不用重新训练。对于增量数据场景——比如日志流、用户实时上传的文档——这是个致命优势。
但“不训练”也意味着你失去了针对特定数据集微调量化器的能力。FAISS的PQ虽然训练麻烦，但训练好了可以在你的特定数据分布上达到最优。TurboQuant一刀切，对所有数据用同一套数学变换。通用性强，但针对性弱。这是取舍，不是优劣。
量化压缩了、速度反而更快？数据会说话
压缩后的数据需要解压才能计算相似度，按理说应该更慢。turbovec的数据却说反话。
ARM平台（Apple M3 Max）上，turbovec在所有测试配置中都比FAISS IndexPQFastScan快12%到20%。x86平台（Intel Xeon Platinum）上，4-bit配置全部胜出1%到6%；2-bit配置稍微落后2%到4%，但项目文档提供了一个PGO优化方案可以把所有配置都翻转为胜出。4-bit配置下平均速度是FAISS的3.4倍。
秘密在于手写的SIMD内核。ARM上用NEON SDOT/SMMLA，x86上用AVX-512 VNNI和vpermb，还有AVX2和标量回退方案。过滤逻辑直接在SIMD内核里执行——传入ID白名单，内核在32向量块粒度上先检查哪些块有允许的ID，没有就直接跳过，不做任何查表和打分。这叫“在核心里过滤”，不是“先算完再扔掉”。前者不浪费算力，后者浪费。
但有一组数据值得注意：x86 2-bit多线程配置下，turbovec落后FAISS 2%到4%。原因是内部累加循环太短，无法通过循环展开充分摊销开销，追不上FAISS的AVX-512 VBMI路径。也就是说，在某些极端压缩配置和特定硬件组合下，FAISS还是更快。这事turbovec的README里写了，但没加粗。
召回率：4-bit赢、2-bit输，而且差距还挺大
速度再快，搜出来的结果不对也不行。
在d=3072、2-bit配置下，TurboQuant召回率0.912，超过FAISS PQ的0.903。在d=1536、2-bit配置下，FAISS略胜——0.882对0.870。4-bit配置下，TurboQuant比FAISS高0.3个百分点。
这些数字看起来差距不大——0.3到1.2个百分点。但有一份独立研究给出了更惊人的数据：在DBpedia OpenAI嵌入基准测试（d=1536，10万到99.9万向量）中，TurboQuant 4-bit在相同内存预算下，Recall@5比FAISS乘积量化高出8.5到8.9个百分点。
为什么差距这么大？因为TurboQuant的压缩方式保留了更多高维空间中的距离信息。FAISS的PQ把向量切成子空间分别量化，子空间之间的相关性被切断了。TurboQuant用随机旋转+极坐标变换+QJL残差修正，在整个向量上做全局优化。全局优化vs局部切割，前者在高维空间中保留了更多结构。
但召回率数据有个坑：turbovec的官方基准测试用的是100K向量、k=64的设置。实际生产环境可能是百万级甚至千万级向量，k值可能更小或更大。小规模benchmark的结论能不能外推到大规模生产环境？不知道。项目文档没给出大规模场景下的召回率数据。这是第一个“这事还没完”的点。
过滤搜索：核心里做过滤，不浪费一滴算力
RAG系统里经常要做混合检索——先用BM25或SQL根据关键词、时间、权限缩小候选集，再在候选集里做向量相似度排序。
传统做法：先算全部向量的相似度，再根据过滤条件把不合格的结果扔掉。如果1000万条里只有500条符合条件，你浪费了99.995%的算力。
turbovec的做法：把过滤条件——也就是允许的ID列表——直接传进search()函数。SIMD内核在32向量块粒度上检查：这个块里有允许的ID吗？没有？整块跳过，不查表、不打分。有？只算块里被允许的那几个。过滤发生在打分之前，不是在打分之后丢弃。
如果允许列表很小——比如1000万里只有500个——大部分SIMD成本被直接规避了。输出长度是min(k, len(allowlist))，不是先算k个再过滤。
这个功能对多租户系统尤其重要。每个租户只能搜自己名下的文档，过滤条件天然存在。传统方案要么每个租户建一个索引（存储爆炸），要么每次搜全量再过滤（算力浪费）。turbovec的核心里过滤提供了一个中间方案。
增量持久化：删一条花几毫秒，不管索引多大
向量索引的持久化是个容易被忽视但实际很要命的问题。
全量保存1000万条向量——即使压缩到4GB——每次写入都是一次大手术。turbovec的sync()方法只保存自上次同步以来的变更。每次调用只做一次fsync，任何字节位置的崩溃都是安全的。删除一条或者追加几条，耗时都是毫秒级，索引多大都不影响。
这意味着你可以频繁调用sync()而不用担心性能开销。对于需要持久化状态的应用——比如本地RAG助手——这是个实在的工程利好。
但天下没有免费的午餐：三个必须知道的坑
第一，bit_width只支持2、4、8。传别的值会panic。向量维度目前上限约32768。
第二，turbovec假设输入向量是L2归一化的。如果你的嵌入模型输出不是单位向量，需要自己归一化后再喂进去。这事文档里写了，但没放在最显眼的位置。
第三，召回率在不同维度和位宽下的表现不一致。4-bit赢，2-bit在x86上可能输。你的实际数据分布、维度、硬件组合都会影响最终效果。官方benchmark用的是OpenAI嵌入和GloVe。如果你用的是别的嵌入模型，需要在你的数据上亲自跑一遍benchmark再做决定。
它到底改了什么？
turbovec没有发明新算法——TurboQuant是谷歌研究院的成果。turbovec的贡献是把论文里的数学变成了一行pip install就能用的工具，用手写SIMD把理论优势兑现成实际的速度提升，用Rust的内存安全和Python的生态便利做了一个杂交。
2026年3月26日项目创建，6月8日单日1554星，7月累计12690星。一个个人项目，三个月走完了很多开源项目三年走不完的路。
但有一个数据我没找到——也是全文最大的那个“还没完”：turbovec的官方README说“4-bit配置下平均速度是FAISS的3.4倍”。但这个3.4倍是基于什么规模的测试？什么硬件？什么数据集？什么k值？项目文档里没有给出这个3.4倍数字对应的具体测试条件。是100K向量还是10M向量？是ARM还是x86？是单线程还是多线程？不知道。这个数字被当作头条放出来，但支撑它的实验细节被省略了。
如果你准备在生产环境里用turbovec替换FAISS，别只看那个3.4倍。在你的硬件上、用你的数据、跑你的查询分布，亲自测一遍。因为benchmark赢得再漂亮，也不等于你的场景一定赢。
原文期刊：GitHub / 2026-03-26 / turbovec: A vector index built on TurboQuant, written in Rust with Python bindings / Ryan Codrai（个人开发者）
SEO标题备选：
1. turbovec实测：1000万文档31GB压到4GB，比FAISS快3.4倍！
2. 向量索引选turbovec还是FAISS？内存省87%速度反超的真相
3. 本地RAG开发者必看：turbovec把向量检索内存干到4GB
4. 谷歌TurboQuant落地成turbovec：实测压缩16倍不掉召回率？
如何使用
你可以通过 pip 轻松安装：
bash
pip install turbovec
Python 基本用法示例：
python
import numpy as np
from turbovec import TurboQuantIndex
# 创建一个维度为1536、位宽为4的索引
index = TurboQuantIndex(dim=1536, bit_width=4)
# 添加向量 (需为 float32 格式)
vectors = np.random.randn(100, 1536).astype(np.float32)
index.add(vectors)
# 搜索
query = np.random.randn(1536).astype(np.float32)
scores, indices = index.search(query, k=10)
# 持久化保存与加载
index.write("my_index.tv")
loaded_index = TurboQuantIndex.load("my_index.tv")
对于需要稳定外部 ID 的场景，可以使用 IdMapIndex，它支持通过用户自定义的 ID（如 uint64）进行添加、删除和检索。
生态集成
turbovec 可以无缝集成到主流 RAG 框架中，作为向量存储组件的“即插即用”替代品：
- LangChain: pip install turbovec[langchain]
- LlamaIndex: pip install turbovec[llama-index]
- Haystack: pip install turbovec[haystack]
- Agno: pip install turbovec[agno]
总结
turbovec 是一个将前沿研究（TurboQuant）转化为高效、实用工具的优秀开源项目。它在内存占用、检索速度和易用性之间取得了很好的平衡，尤其适合希望构建高性能、低成本、且注重隐私的本地向量检索或 RAG 应用的开发者。
如果想深入了解，可以查阅其 GitHub 仓库中的详细文档（如 docs/api.md）和丰富的性能基准测试结果。