How to Optimize Vector Search When RAM Gets Too Expensive: On-Disk vs. In-Memory ANN Indexes

当RAM成本过高时如何优化向量搜索：磁盘与内存中的ANN索引对比 | Towards Data Science

机器学习

当RAM成本过高时如何优化向量搜索：磁盘与内存中的ANN索引

通过权衡HNSW、SPANN和DiskANN的延迟与存储开销，构建成本效益更高的基础设施

Oleg Tereshin

2026年7月25日

11分钟阅读

分享

在过去的几年里，向量搜索已成为AI基础设施的关键组成部分，从RAG和语义搜索到智能体记忆和上下文层，各种应用场景都依赖其支持。随着智能体系统的兴起，企业正试图为智能体提供尽可能多的上下文信息，这要求向量数据库索引规模从最初的百万级或数千万级扩展到数亿甚至数十亿级。在这种规模下，将索引和相关数据存储在RAM中每月可能产生数千美元的成本，而HNSW可能成为可扩展性的瓶颈。

在本文中，我想深入探讨使语义搜索快速且高效的关键因素：近似最近邻（ANN）算法，不同选项之间的差异及其权衡。

向量数据库深度解析

向量数据库主要由三个部分组成：

• 嵌入（embeddings）——语料库的数值表示
• 搜索算法和索引结构——算法决定了搜索质量和速度
• 存储（storage）——数据的存储方式（内存中、磁盘上、与嵌入一起存储等）。无论是在RAM还是磁盘上，这都决定了在大规模场景下的成本和延迟

嵌入的定义和讨论在许多文章中已有详细阐述，本文将重点放在搜索算法，特别是近似最近邻（ANN）算法上。一般来说，搜索执行有两种方法：

• 精确搜索——虽然在延迟方面扩展性较差，但能提供最佳的检索指标
• 近似最近邻（ANN）——以牺牲检索质量为代价，换取延迟和可扩展性

精确搜索是一种简单的方法，它遍历索引中的所有条目，并计算搜索查询与现有数据之间的距离。这种搜索方式在延迟和可扩展性方面没有因任何近似或泛化而产生的损失。它非常适合非常小的索引或实验，但通常不适用于生产规模。

有趣的是：许多现代向量数据库允许对小规模集合跳过索引构建过程，转而使用kNN搜索，因为为几千个向量构建索引的开销并不值得。

第二种选择是近似最近邻算法，这是一组旨在通过避免访问索引中的所有条目来提高可扩展性的算法。其核心思想是提供一些快捷方式以加快搜索和数据摄入速度。虽然实现方式各异，但许多现代ANN算法（例如HNSW和DiskANN）都依赖图结构来实现低查询延迟。

在本文中，我想重点介绍两类不同的ANN算法：

• 基于内存的 – 这类算法优化了将全部或大部分数据存储在内存中的能力，从而提供极低的延迟，但需要以成本作为权衡。标准示例是HNSW（Hierarchical Navigable Small World）

• 基于磁盘的 – 这类算法最小化内存使用，高度依赖磁盘加载所需数据。示例包括DiskANN或SPANN

需要指出的是，这两类算法的基础数据结构都可以存储在磁盘或内存中（至少部分存储），但它们针对特定存储类型进行了优化，因此使用其设计初衷的存储方式时能获得最佳效果。

内存ANN

HNSW（Hierarchical Navigable Small World）

HNSW的分层图：查询从顶层稀疏图开始，贪婪地走向最近节点，然后下移并重复此过程，直到到达底层密集图。图片由作者提供。

这是几乎所有现代向量数据库使用的最流行ANN算法。其核心思想是利用基于分层图的结构将向量与近邻连接起来，当整个索引存储在内存中时可提供极快的检索速度。它非常适合中小型使用场景，并能提供最佳检索速度。

然而，当索引规模大到无法适应内存或内存存储成本过高时，只能选择将数据转移到磁盘（这可能导致性能大幅下降），或进行高度量化（这可能导致检索质量显著下降）。性能下降的主要原因是HNSW结构未针对磁盘集群访问进行优化，导致搜索会产生大量非顺序I/O操作。考虑到每次搜索需要多次跳转且读取流量较高，磁盘I/O将成为瓶颈，可能在高I/O压力下显著增加延迟（从毫秒级到数百毫秒甚至更差）。

内存算法高度优化了将所有向量和连接存储在内存中的能力，这使其非常快速，但需要以内存消耗大作为代价。此外，这类算法在使用磁盘选项时依赖随机磁盘访问，这可能成为大规模索引（1亿+）的潜在瓶颈。

示例向量数据库：Qdrant、Milvus、pgvector、OpenSearch、Weaviate、Redis

基于磁盘的ANN

这类算法专门设计用于突破内存ANN算法的内存消耗限制，同时降低存储成本并保持可接受的延迟。如果搜索延迟不关键且预计索引规模较大，这是理想选择。我们可以考虑该组中的两种主要算法：

SPANN

SPANN的路由层：质心保留在内存中，它们代表的向量存储在磁盘中。图片由作者提供。

DiskANN 是一种基于磁盘的近似最近邻（ANN）算法，采用倒排索引（IVF）方法：向量被分组到多个聚类中，每个聚类由一个质心表示。该算法专门设计用于处理超大规模（十亿级向量以上）的索引，这些索引无法完全加载到内存中，或内存存储成本过高。其核心思想是将向量组织成聚类——这是嵌入空间的自然属性，选择聚类的质心表示，并利用质心进行路由层处理。质心和整个路由层可以存储在内存中，而质心所代表的向量则存储在磁盘上。关键细节在于，相同质心所代表的向量在磁盘上按顺序存储，因此可以快速高效地加载。在搜索过程中，通过质心找到最接近的向量组，然后从磁盘加载这些向量进行完整扫描。

注意：与支持磁盘存储的HNSW相比，SPANN确保单个质心所代表的向量在磁盘上按块存储而非随机访问，这大幅减少了磁盘I/O操作次数，同时保持可接受的延迟。

示例向量数据库：Turbopuffer（基于SPFresh，SPANN的后续版本）、Chroma DB（云服务）

DiskANN

DiskANN 的架构：量化向量和图结构存储在内存中，每次访问点时从磁盘读取完整精度的向量。图片由作者提供。

与基于质心的方法不同，DiskANN维护一个名为Vamana的单层图。其核心思想是通过保留部分长距离连接而非仅最近邻连接，从而减少找到前k个点所需的跳转次数和随机磁盘访问次数。原始向量存储在磁盘上，而高度量化的向量版本存储在内存中，这也减少了磁盘访问次数。与SPANN相比，DiskANN的Vamana图构建在每个点上，因此图结构会随数据集规模扩展，这在十亿级数据规模下是真实存在的内存考量，而SPANN只需保留质心。磁盘上的数据未进行聚类，通过路由层进行最小跳转次数即可访问相似向量，从而在实际应用中实现高效搜索。具体实现细节较多，强烈建议阅读本文参考文献中的原始论文。

示例向量数据库：Milvus、PostgreSQL（通过pg_diskann）

经济性分析

注意：以下价格为估算值，撰写时的当前价格。云服务价格会随时间变化，并因供应商、地区和承诺服务而异，因此请将这些数据视为内存与磁盘成本比例的示例而非精确报价。

通过云服务提供商，内存成本约为每GB 5美元，EBS存储成本约为内存的50分之一，即每GB 0.08-0.10美元，本地NVMe SSD成本约为每GB 0.20-0.25美元。因此，对于1024维、使用float32精度的100,000,000规模索引，每个向量需要1024 * 4字节 = 4KB存储空间，加上生产级3副本冗余，每个向量需要12KB存储空间。

因此，对于1亿个向量，所需的总存储空间为1.2 TB。当然，还有量化选项可以降低这个数字，而最流行且侵入性最小的标量量化将需要25%的存储空间，即300 GB。

因此，与存储相关的月度成本估算如下：

• 未量化（内存中）约6000美元
• 标量量化（内存中）约1500美元
• 远程磁盘约120美元
• 本地磁盘约300美元

由于这是线性关系，随着索引规模向代理系统推动的规模增长，差距只会进一步扩大：

| 向量数 | 存储（未量化） | 内存月成本 | 标量量化内存月成本 | 远程磁盘月成本 | 本地磁盘月成本 | |--------|----------------|------------|-------------------|----------------|----------------| | 1亿 | 1.2 TB | ~6,000 | ~1,500 | ~120 | ~300 | | 5亿 | 6 TB | ~30,000 | ~7,500 | ~600 | ~1500 | | 10亿 | 12 TB | ~60,000 | ~15,000 | ~1,200 | ~3000 |

表1：跨索引规模和存储层级的月度存储成本估算（不含计算成本）。图片由作者提供

因此，尽管标量量化显著降低了成本，但与磁盘选项相比仍然成本较高。

权衡

与工程中的其他事情一样，磁盘ANN算法提供的成本降低并非没有代价。虽然路由层确实确保了高效的数据检索并缩小了探索范围到较小的子集，但数据仍然需要从磁盘加载，这比从内存加载要慢得多。值得注意的是，对于许多用例来说，这可能并不是决定性因素。以RAG为例，向量数据库的结果随后会传递给重排序器和LLM，检索时100ms的延迟不会成为主要瓶颈。但对于代理内存、上下文等场景，实际上可能更希望尽可能快速执行搜索，尤其是在单个代理请求处理过程中有多次调用时。

准确给出磁盘延迟的具体数值确实很困难，这正是问题所在，它高度依赖于具体配置。例如，SPANN论文报告在十亿规模下达到90%召回率仅需约1ms，但这是在单机上使用本地SSD存储索引的平均延迟。一旦部署到实际环境，情况就会改变。Turbopuffer在1000万向量索引上的基准测试显示，当索引在快速存储上处于热状态时，p50延迟约为14ms，但当索引处于冷状态并需要从对象存储中获取时，延迟接近874ms，这在相同数据上仅因缓存状态就存在约60倍的差异。硬件条件和数据是否处于热状态（已缓存）等因素都可能使延迟数值变化10倍甚至更多。总体指导原则是，基于磁盘的ANN算法的延迟比HNSW（内存中）更慢，仅仅因为内存访问速度要快得多。

慎重选择

在磁盘和内存算法的选择上，为特定使用场景选择合适的方案至关重要。虽然HNSW为小型和中型索引提供了简单且全面的解决方案，但当索引规模扩大到内存存储向量的成本变得难以承受时，可能需要考虑磁盘方案。此外，某些边缘场景（如高维向量导致内存瓶颈提前出现，或低维索引规模巨大且能长期利用内存）也需特别关注。对于工程师而言，了解这些使用场景并权衡取舍，做出符合实际需求的决策尤为重要。

算法

| 内存中保留内容 | 延迟 | 可扩展到 | 适用场景 | |----------------|------|----------|----------| | 精确搜索 | 完整向量（或从磁盘流式读取） | 随N增长 | < ~10k | 超小集合、真实值评估 | | HNSW | 整个索引（可选磁盘，但延迟惩罚较大） | 通常低于10ms | ~1M–100M | 延迟敏感型、索引符合内存预算 | | DiskANN | PQ向量+图；图随N增长 | 冷启动时较慢，预热后低毫秒级 | 100M–1B+ | 规模大且成本敏感型 | | SPANN | 仅聚类中心 | 100M–数十亿 | 即使PQ在内存中也成本过高 |

表2：按内存占用、延迟和实际规模对ANN算法的总结。图片由作者提供。

参考文献

• HNSW论文 https://arxiv.org/abs/1603.09320
• SPANN论文 https://arxiv.org/abs/2111.08566
• DiskANN论文 https://papers.nips.cc/paper_files/paper/2019/hash/09853c7fb1d3f8ee67a61b6bf4a7f8e6-Abstract.html
• TurboPuffer性能：[turbopuffer.com/tldr](turbopuffer.com/tldr)

作者

查看Oleg Tereshin的所有文章

相关主题

嵌入向量，RAG，语义搜索，向量搜索

分享本文

• Facebook
• LinkedIn
• X

Towards Data Science是社区出版物。提交您的见解以触达全球受众，并通过TDS作者支付计划获得收益。

更新为实际投稿链接

[为TDS撰写文章](#)

✦ 结束CTA ✦