pip install turbovec && python -c "print('hello turboquant')"
TurboVec
基于 Google Research TurboQuant 算法（ICLR 2026），Rust 写核心 + Python 绑定，一行 pip 安装。1000 万条 OpenAI 向量从 31GB 压到 4GB——压缩率 87%——ARM 上检索速度比 FAISS 快 12-20%，x86 持平或略优。零训练、零 GPU、在线添加、内核级过滤。
// 目录
// 概览
// 向量检索的两个老问题
每天跑 GitHub AI 日报，看过的向量数据库项目两只手数不过来。FAISS、Milvus、Qdrant、Chroma、LanceDB……各有各的用武之地。但今天这个不太一样。
RyanCodrai/turbovec，今日 Trending 涨幅最高的 AI 项目，+1,554 Star。我点进去看了十分钟就决定写它——不是因为 Star 多，是这个方案的想法确实够狠。
说人话：RAG 系统的向量存储一直有两个老问题。第一，内存吃不消。1000 万文档 × 1536 维 × float32 得 61GB，算上索引开销大概 31GB。32GB 内存的机器直接爆了。第二，每次加新数据得重建索引。传统乘积量化（PQ）得先拿一批数据训练码本，后面来了新数据要么扔掉旧的重新训，要么忍受质量下降。对于每天都在变的数据集，这个流程根本扛不住。
TurboVec 两刀都砍了。压缩到 4GB 靠的是数据无关量化——不需要看数据长什么样，数学上就能算出来最优分桶。在线添加靠的是同样的原理——来了新向量直接量化塞进去，不用回头看旧数据。
// TurboQuant 算法：五步把 31GB 变成 4GB
我不是做数学的，但这个算法思路确实漂亮。分五步走：
第一步：归一化。 把每个向量的长度（模长）去掉，存成一个标量。所有向量变成单位球面上的点。这一步把"方向"和"长度"解耦了。
第二步：随机旋转。 所有向量乘同一个随机正交矩阵。转完之后，每个坐标在高维下近似独立，都乖乖服从 Beta 分布，跟你原始数据长什么样没关系。这一步是整个"数据无关"的数学基础——ICLR 2026 论文的核心贡献。
第三步：校准（TQ+）。 有限维度下坐标不会完全服从理论分布，所以第一次加数据时，给每个坐标拟合偏移和缩放两个数，把实际分布映射到理论分布。校准结果冻住，后面不再改。低维场景下 R@1 能提升 1.4 个百分点。
第四步：Lloyd-Max 标量量化。 坐标分布已知，最优分桶方式直接从公式算。2-bit 是 4 个桶，4-bit 是 16 个桶。不需要训练，不需要迭代，一条公式出结果。做法很干净。
第五步：位打包 + 长度重归一化。 量化完的整数紧密打包成字节，1536 维 float32（6144 字节）→ 4-bit 后 768 字节 → 2-bit 更狠，384 字节。量化会导致内积被低估，TurboVec 在编码时算好修正系数塞进去，搜索时零额外开销乘回去，内积估计是无偏的。这个技巧来自 RaBitQ（SIGMOD 2024），放到 TurboQuant 的框架里刚好互补。
整个过程不需要看数据、不需要 GPU、不需要训练。所有坐标共享同样的量化器，因为旋转后它们服从同一个分布。这比传统 PQ 那种"先采样、训码本、再量化"的流程不知道清爽多少。
// TurboQuant 量化流水线
// 安装使用
装这东西就一行：
基本用法——建索引、加向量、搜、存盘、加载，一气呵成：
带自定义 ID 的版本适合关联数据库，支持 O(1) 删除：
搜索时过滤是我觉得最实用的功能。多租户 RAG 场景下，先在 SQL 里查出某个租户的文档 ID，然后在内核级直接过滤，不先拉大量结果再筛：
过滤逻辑在 SIMD 内核的 32 向量块粒度执行。允许的候选集越小，跳过的块越多，速度越快。不是那种"先搜 100 个再筛"的假过滤。
// 性能数据
基准测试环境：10 万向量、1000 条查询、k=64，跑 5 次取中位数。
召回率对比（vs FAISS IndexPQ）
搜索速度对比
内存占用
// 竞品对比
| 方案 | 核心优势 | 核心短板 | 适合场景 |
|---|---|---|---|
| TurboVec | 零训练 + 极低内存 + ARM 速度领先 + MIT | 项目新 · 单人维护 · 无分布式 · 低维 2-bit 弱 | 中小规模 · 内存敏感 · 在线增量 |
| FAISS | Meta 出品 · 生态最完善 · GPU 支持 · 十亿级 | 需训练码本 · 增量添加要重建 · 内存占用高 | 大规模离线 · GPU 加速 · 需要各种索引类型 |
| Milvus | 分布式 · 全套企业功能 · 云原生 | 重（K8s/Pulsar/MinIO）· 学习曲线陡 | 企业级 · 十亿级 · 需要高可用 |
| Qdrant | Rust 原生 · 过滤强 · API 简洁 | 内存占用比 TurboVec 高 · 非压缩专长 | 需要丰富过滤 · 中等规模 |
| LanceDB | 列式存储 · 数据湖搭配 | 搜索性能不如专用向量库 · 生态年轻 | 数据湖场景 · 多模态数据 |
| Chroma | 最简单上手 · 原型友好 | 性能弱 · 无量化压缩 · 生产扛不住 | 原型开发 · 小数据集 |
// 博主观点
TurboVec 是那种「想法干净、实现利落」的项目。它不试图做一个全家桶，就盯着向量量化这一件事做到极致。聊几个我觉得值得说的事。
第一，这个方案打中了 RAG 最真实的痛点。 不是"我们要支持十亿级向量"这种大词，而是"内存不够用了"和"数据天天长重建索引太烦了"。这两个问题每个做 RAG 的人都会遇到，TurboVec 给了一个很直接的解法。1000 万条数据从 31GB 变成 4GB，搜索还更快——这个结果本身已经足够说明问题了。
第二，ARM 上的性能优势不是运气。 手写 NEON SIMD 内核、x86 上 AVX-512BW 精准选路——这些不是调调编译选项能出来的效果。而且 ARM 正是 Mac 笔记本和边缘设备的主力平台，这块 FAISS 的优化远不如 x86。TurboVec 在 ARM 上比 FAISS 快 12-20%，对 Mac 用户来说是个实打实的甜点。
第三，数据无关这件事的价值被低估了。 传统 PQ 需要"先采集一批有代表性的数据 → 训码本 → 建索引"这个流程。如果你的数据分布跟我训码本时的不一样，量化质量就会掉。TurboVec 反其道而行——它假设"转完之后坐标都服从 Beta 分布"，然后从数学上求最优解。不需要代表性数据，不需要重训，增量数据和存量数据享受同样的量化质量。
但我也确实有几个顾虑。 项目只有 144 个 commit、25 个 tag（但没有正式的 GitHub Release），维护者只有 RyanCodrai 一个人。Bus Factor = 1，这意味着作者去休假代码就没人管了。低维 2-bit 场景下比 FAISS 差 1.2 个百分点——如果你还在用老式词向量（普遍 200-300 维），TurboVec 的增益有限。没有分布式也是硬伤，十亿级以上场景还是得找 Milvus 或 Qdrant。
还有一个隐忧：Meta 不是傻子。 TurboQuant 的论文是公开的（ICLR 2026），如果 FAISS 团队觉得这条路靠谱，把类似的东西做到 FAISS 里只是时间问题。TurboVec 的时间窗口有多长，取决于它能跑多快。
但就现在来说——如果你在用 LangChain 或 LlamaIndex 搭 RAG，把向量存储从 InMemory 换成 TurboVec 基本是零迁移成本。省下的内存可以干别的，或者在更便宜的机器上跑更大的数据集。对于资源敏感的场景，这 87% 的内存节省不是什么锦上添花，是能不能跑起来的区别。
✅ ARM 搜索速度比 FAISS FastScan 快 12-20%
✅ 零训练、零 GPU、一行 pip install
✅ 在线增量添加，无需重建索引
✅ 内核级搜索过滤（多租户 RAG 天然适配）
✅ ICLR 2026 论文背书，数学逼近香农下界
✅ 主流 RAG 框架原生集成（LangChain/LlamaIndex/Haystack/Agno）
✅ MIT 协议，Rust 核心 + Python 绑定
❌ 无分布式支持，十亿级以上得换方案
❌ 低维 2-bit 场景比 FAISS 差（GloVe d=200：R@1 -1.2pp）
❌ 无正式 GitHub Release，只有 Git Tags
❌ FAISS 团队可能跟进类似方案，时间窗口不确定
❌ 大规模用户反馈尚缺（Issue 仅 10 个）
// links
🔗 联系作者：Ryan Codrai / GitHub Profile