把 6000 万个文本块的 RAG 向量索引从 201 GB 压到 6 GB，直接砍掉 97% 的存储体积。2026 年 10 月 27 日，开源向量索引项目 LEANN 靠这组扎眼的数字刷了屏。这个由 StarTrail-org 开源的项目来头不小，其论文《LEANN: A Low-Storage Overhead Vector Index》于 2025 年 6 月 9 日首次提交至 arXiv（arXiv:2506.08276），并在 2026 年 5 月 18 日至 22 日举办的 MLSys 2026 上拿下了最佳研究论文奖。但在计算机系统里，守恒定律从不失效，省下的磁盘空间，迟早要用算力、延迟和工程限制连本带利还回去。
丢掉向量实时重算：6 GB 魔术的真实底牌
做过大模型检索增强生成（RAG）的人都知道，传统向量索引是个吞硬盘的无底洞。无论是常用的 HNSW 还是 DiskANN，都要把高维浮点向量和图结构持久化存下来，最后索引文件往往比原始文本还要大好几倍。行业常规解法是做标量量化（SQ）或乘积量化（PQ），把浮点数压短，但这总会伤及召回率。
LEANN 选了一条极端得多的路。它在构建完索引后，直接丢弃绝大部分原始向量，硬盘里只留一套压缩后的导航图结构；等到真正查询时，再调用 GPU 实时重算候选文档的 Embedding。
但宣传口径里的 6 GB 需要先挤掉两层水分：
- GitHub 仓库展示的 6000 万 Wikipedia 文本块从 201 GB 降到 6 GB，仅指索引文件本身，底层的原始文本和 Embedding 模型权重都得另外占地方。
- 2025 年 11 月 25 日修订版论文的正规实验里（76 GB 文本语料、6000 万个 768 维 Contriever 向量、目标 90% Recall@3），FAISS HNSW Flat 索引占 188 GB，DiskANN 占 270 GB，LEANN 压到了 4 GB，但那 76 GB 的原始语料一字节都不能少。
慢 50 倍的检索延迟，被端到端测试巧妙藏了起来
韩非子讲，左手画圆，右手画方，不能两成。系统设计也是如此，把存储压到极限，延迟必然爆表。
同样在上面那组 6000 万向量的基准测试里，FAISS HNSW 的检索延迟是 50 ms，DiskANN 是 30 ms，而 LEANN 高达 2480 ms。也就是说，LEANN 的索引体积比 HNSW 小约 47 倍，但检索慢约 50 倍；比 DiskANN 小约 68 倍，但检索慢约 83 倍。即便插上 RTX 4090 显卡，达到 90% Recall@3 时，LEANN 的检索延迟依然分布在 1.12 秒至 7.12 秒之间，而传统 HNSW 只要 0.04 至 0.05 秒。
官方文档里那组 5000 条文本的小规模测试（搜索复杂度 32）同样印证了这一交换比：
| 索引后端与模式 | 索引存储体积 | 单次检索耗时 | 核心工程代价 |
|---|---|---|---|
| HNSW 关闭重算 | 16.6 MB | 12 ms | 占用常规磁盘空间 |
| HNSW 开启重算 | 1.1 MB | 818 ms | 延迟暴增约 68 倍 |
| DiskANN 关闭重算 | 24.6 MB | 13 ms | 磁盘开销最高 |
| DiskANN 开启重算 | 5.9 MB | 41 ms | 压缩率不及 HNSW |
为什么很多读者看论文时没察觉它这么慢？因为作者在 NQ 数据集上做了一组完整 RAG 端到端测试。大模型生成答案本来就要花二十秒，于是 HNSW 端到端总延迟测出来是 20.95 秒，LEANN 是 23.34 秒。用漫长的生成耗时做分母，2 秒多的检索劣化在视觉上就被抹平了。
拿二十秒的大模型生成时间当遮羞布，掩盖不了检索慢五十倍的工程硬伤。
我不太买账这种端到端对比。在真实生产环境里，检索层和生成层是分开计费、分开调度的；把单次检索从 30-50 毫秒拖慢到 2.48 秒，意味着它彻底告别了需要 100 毫秒内响应的高并发在线服务。
只读枷锁与孤儿进程：走出实验室的隐性账单
如果真要把 LEANN 搬进工程项目，论文重点章节之外还有三笔隐性账单要算清楚。
最致命的限制在增量更新上。当前代码里，只有 IVF 后端支持增删改，但选了 IVF 就拿不到宣传里的极致压缩比；非紧凑型 HNSW 仅支持增量添加，一旦修改或删除文档就会触发全量重建；而最省空间的紧凑型（compact）HNSW 干脆拒绝就地更新，任何变动都必须推倒重来。不仅如此，构建阶段依然得先把文档向量全部算出来再丢弃，为了压住构建期的峰值存储开销，论文专门做了一套分片构建方案，才把实验里的峰值存储降低了约 5 倍。
再看 GitHub 社区里开发者踩出来的真实痛点，具体包括：
- 无显卡寸步难行，Issue #43 反映在没有 GPU 的 Linux 虚拟机上运行极慢，因为实时重算全靠显卡硬扛。
- 冷启动耗时惊人，Issue #159 显示，即便在 RTX 4090 配 BGE-large 模型下检索 180 MB 文本，维护者复现出的首次冷启动（含服务失败回退）耗时高达 58.87 秒，之后热检索也要 3.44 秒。
- 后台内存黑洞，2026 年 10 月 7 日提交的 Issue #432 报告，Windows 环境下空闲的 MCP 进程就吃掉约 2.4 GB 内存，遗留的孤儿 Embedding 守护进程每个还要占用约 2.7 GB 内存。
这事让人想起早年大数据架构里的冷热分层，磁带库和冷存储能把每 GB 成本压到极低，但谁也不会拿磁带库去跑双十一的实时交易。LEANN 并不是来砸 Milvus、Pinecone 或 Qdrant 饭碗的，企业在线业务既受不了秒级延迟，也付不起每次查询都调 GPU 重算的算力账单；但向量数据库厂商完全可以把这套图压缩加按需重算的思路吸纳进来，专门伺候极少被访问的冷数据归档层。
- 建议.如果你手里有一台插着 RTX 4090 的工作站或高配 MacBook，想在本地塞进几千万条百年不改的静态文献做个人检索，单人低频查询完全能容忍 2 到 3 秒的等待，LEANN 确实能帮你省下一块大容量 SSD。
- 风险.只要你的业务语料每天都在增删修改，或者运行在没有独立 GPU 的轻量服务器上，千万别被 201 GB 压到 6 GB 的标题诱惑——省下的那点硬盘钱，还不够填全量重建和算力阻塞的坑。