DiskANN原理与实践：破解十亿级向量检索的内存困局

搞向量检索的朋友应该都体会过这种痛苦：数据量一上来，"内存不够"四个字就像紧箍咒一样。我之前处理一个内容去重的需求，一亿条 512 维的 embedding，光是原始向量就要 200 多 GB，跑 HNSW 类内存方案想都不敢想。最后把眼光放到了 DiskANN 上——这是目前少数能把十亿级向量索引放在磁盘上、还能保持毫秒级查询延迟和较高召回率的方案。这篇文章我会把 DiskANN 的原理、适用场景、跟其它常见工具的差别，以及如何从零跑通一次建索引和查询，完整过一遍。适合正在做大向量检索选型、或者手里只有一台机器却要装下巨量向量的读者，刚接触 ANN 的朋友也可以放心看，概念部分我会讲得尽量直白。

1. 为什么关注 DiskANN：先算一笔"内存账"

很多时候我们纠结的不是算法本身，而是硬件账单。拿十亿条 1024 维 float32 向量来说，一条向量占 4KB，十亿条就是 4TB 原始数据。想把它全放内存里，光买内存条的钱就已经非常吓人了，还得额外给图索引结构留内存——HNSW 这类图的边开销通常和向量本体量级相当甚至更高。所以"全内存"路线在十亿级这个量级上，基本是给少数预算充足的大厂准备的。

DiskANN 走的是另外一条路：把向量主体和图结构的大部分放到 SSD 上，内存里只保留必需的入口信息、码本和少量缓冲。这样一台普通配置的 NVMe 服务器，就能扛住十亿甚至几十亿条向量的相似检索。付出的代价是单次查询延迟比纯内存方案高一些——从 0.1 毫秒级别变成 2 到 15 毫秒级别，构建索引的时间也明显更长。但换个角度看，如果业务本身能接受几毫秒的召回延迟，那 DiskANN 等于用十分之一的硬件成本换来了同级别的召回率，这笔账很划算。

还有人会问：FAISS 的 IVF-PQ 不也能压缩到小内存里吗，为什么还要 DiskANN？关键在于压缩比的耐受度。IVF 是先分区再量化，压缩比一高，分区边界就容易"切错"，导致召回率明显往下掉；DiskANN 的图结构走的是"邻居关系"而不是"分区归属"，在同样的内存预算下召回更稳。这一点后面第四章会展开对比。

2. 核心原理拆解：VAMANA 图、SSD 布局与量化压缩

2.1 VAMANA 图：一张"单层"图如何保证连接性

DiskANN 索引的骨架是 VAMANA 图。很多做向量检索的人第一反应是"为什么不直接上 HNSW"，其实两者目标不同：HNSW 是为内存随机访问设计的，通过多层跳表结构让查询从高层快速下降；VAMANA 则刻意做成了单层有向图，配合磁盘读取方式反而更合适。

单层图的构建思路不复杂。先把所有点打乱顺序，逐个插入图中。插入每个新点时，从图的入口节点（叫 medoid，通常是全量数据的质心）出发做一次贪心搜索，找到离新点最近的若干候选邻居；然后执行一个叫 robust prune 的剪枝操作。剪枝的规则大致是：如果候选集合里存在一个点 v，使得从当前点连到 v 的距离足够近，且 v 本身能"覆盖"另一个候选 x 的邻近区域，就不再保留 x 这条边。还有一个参数 alpha 控制剪枝的严格程度，alpha 越大，图保留的边越多，召回越高，代价是构建时间和查询读盘量同步上升。

这样构建出来的图有两个特点：第一，从 medoid 出发能到达几乎所有节点，全图连通性有保证；第二，每个节点的出度被限制在 R 以内，边的总量可控。查询时不需要跨层切换，一条路顺着图走到底——这种"平滑"的查询路径，恰恰是后面 SSD 批量读能够奏效的前提。

2.2 面向 SSD 的图存储布局：把随机读变成"成块搬运"

纯内存索引可以靠指针随便跳，今天学 OI 的人都知道链表里跳一步是 O(1)，但在磁盘上不是这么回事。磁盘读取的最小开销远大于内存访问，所以 DiskANN 在设计存储布局时下了功夫。

它把图节点按编号连续排列在文件里，每个节点在文件中的位置是确定的，节点旁边直接跟着它的邻居偏移表。查询时，beam search 会维护一个"当前要读的节点集合"，而不是一次只读一个节点。DiskANN 把这些待读节点对应的磁盘块打包成一批，一次性预读回来。读一份数据，既能拿到节点的向量信息，又能拿到它完整的邻居列表，单次 IO 的信息量被压到最大，读放大被控制在很小范围。

这也是为什么 DiskANN 对存储介质极其敏感。现代的 NVMe SSD 随机读 IOPS 能到几十万级别，而且并发能力强，适合这种"小批量并行读"的模式；SATA SSD 随机读性能掉一个量级，HDD 更是灾难。后面第六章我会专门讲这个坑，很多人一开始图便宜用机械硬盘跑 DiskANN，最后延迟惨不忍睹。

2.3 压缩编码：先用"低清版"筛选，再读"高清版"精排

如果查询时每次都把候选节点的全精度向量读出来算距离，IO 量还是太大。DiskANN 的解法是默认对向量做乘积量化（PQ）压缩。把 D 维向量切分成 m 段，每段在对应的子空间里用 k 个中心点表示，于是每条向量压缩成 m 个码字。比如 m=16、每码 8 位，一条向量就变成 16 个字节，比全精度小了上百倍。

查询流程变成两阶段。先用压缩码本快速估算候选节点与查询向量的近似距离，把最有可能的一小批挑出来；然后只对这批"有希望"的节点读取全精度向量，做一次精确距离重排。你可以把它想成先看监控里的模糊人影判断"是不是这个人"，确认了再走到面前核对五官，省掉的是大量无效的"近距离接触"。这个机制决定了 DiskANN 的召回不仅取决于图质量，还取决于量化误差和重排策略的配合。

2.4 查询过程：beam search 的完整循环

把查询过程拆开看，本质是一个受限的贪心搜索。从 medoid 出发，维护一个按距离排序的最小堆，每次从堆顶弹出当前最近的节点；如果还没访问过，就把它的邻居节点读出来，计算与查询向量的距离后重新入堆。循环直到堆为空，或者已经访问的节点数达到设定的搜索宽度 L。

L 越大，搜索覆盖的范围越广，召回越高，但 CPU 和 IO 开销也同步上升。DiskANN 还引入了一个叫 beamwidth 的参数，控制每一轮并行读取多少邻居块。它和 L 的区别在于：L 是"总共看多少个点"，beamwidth 是"每一波并发拉多少个点"。实际调参时，通常先固定 L 再慢慢调 beamwidth，找到一个 IO 吞吐和排队延迟的平衡点。

3. 什么场景真正适合上 DiskANN

3.1 十亿级向量相似检索与内容去重

最典型的场景是电商以图搜图、短视频指纹去重、音频哼唱检索这一类。它们的共性是特征量级大（几亿到几十亿条），查询维度高，召回延迟容忍度在几十毫秒以内。我见过一个做视频指纹去重的项目，30 亿条 256 维特征，跑在 64GB 内存的机器上，原来用 FAISS 的 IVF-PQ 方案召回率卡在 85% 上不去；换 DiskANN 之后同样一台机器，单条查询 8 毫秒左右，top-10 召回率提到 96% 以上。这个案例里瓶颈不是计算，而是"装不下"，DiskANN 恰好把这块短板补上了。

3.2 RAG 场景下的文档向量索引

大模型 RAG 应用看起来热热闹闹，实际上不少业务的数据量远没到十亿，但有个特点很一致：索引很大，QPS 不高。企业知识库动辄上千万的文本块，切分成 embedding 之后也有几十上百 GB。这种场景用 GPU 或全内存方案是杀鸡用牛刀，DiskANN 反而合适——离线批量建索引，周期性重建，查询链路前面顶一个 rerank 模型，成本能压得很低。唯一要注意的是如果上层要求 20 毫秒以内的端到端响应，DiskANN 单查延迟加上网络和 rerank，预算会比较紧张，这时候需要给热点查询加缓存。

3.3 成本敏感的单机部署

DiskANN 最打动人的地方在于把"不可能"变"可能"。十亿条 512 维向量，压缩后通常只要几十 GB，图文件按 R=64 算也就几百 GB，一块 2TB 的 NVMe 盘加 64GB 内存就能跑起来。这个配置放在全内存方案面前，成本差距是数量级的。对初创团队、预算受限的中小公司来说，这是真正能把大规模向量检索落地的路径。

3.4 不适合的场景

DiskANN 不是万能的。如果你需要高频实时插入删除，它的动态更新能力并不友好，社区版基本以批量重建为主；如果你要求几万 QPS 且单次延迟低于 1 毫秒，纯内存图索引仍然是最优解；如果数据集本身才几百万条，那更没必要折腾磁盘索引，直接放内存里简单省事。选型的第一步永远是诚实评估自己的数据规模和延迟要求，而不是追着新工具跑。

4. 与主流向量检索工具的对比

4.1 和内存图索引（HNSW 类）对比

HNSW 这类内存图索引追求的是极致延迟，查询基本在 0.1 到 1 毫秒之间，构建也快。但它有一个绕不开的天花板：所有向量和图边都必须待在内存里。数据涨到一亿条以上，内存需求就到了几百 GB；涨到十亿级，单机基本无解，只能走分布式，而分布式又要面临网络开销和一致性复杂度。

DiskANN 正好反过来：牺牲一部分延迟，换来数据规模的上限提升。两者在召回率上都能做到很高，DiskANN 因为多了 PQ 压缩和重排，会在极致召回场景里有一点点精度损失，但在 95% 到 98% 这个实用区间内差异并不明显。如果你的数据能塞进内存，且延迟是第一优先级，选 HNSW；如果塞不进，DiskANN 是目前最值得考虑的替代方案。

4.2 和 FAISS 家族（IVF-PQ 类）对比

FAISS 是个非常优秀的算法库，但它本质是"组件"，不是完整系统。你拿到手的是各种索引类型和方法，存储、分片、持久化、更新都要自己搭。IVF-PQ 在高压缩比场景下的问题是：分区数量有限，压缩后向量变得"模糊"，很多真实近邻在粗筛阶段就被排除了。DiskANN 的图结构天然适合这种高压缩比场景，因为邻居关系是构建阶段用全精度距离算出来的，即使向量被压缩，图拓扑依然是可靠的。

两者的关系也不完全是对立的。实际生产中可以组合使用：用 FAISS 做粗排快速过滤，用 DiskANN 做精排提升召回；或者用 FAISS 的接口封装 DiskANN 索引一起对外服务。我做过的项目里，这种"混搭"架构很常见。

4.3 一张表看清选型差异

下面这张表整理了几个关键维度的差异，方便你在方案评审时直接引用：

选型口诀可以记成三句话：数据低于千万且要毫秒级响应，直接上 HNSW；几千万到几亿、能接受 5 毫秒左右延迟，IVF-PQ 压缩够用；十亿以上、单机部署、延迟能忍到 10 毫秒级别，优先考虑 DiskANN。

5. 基本使用方式：完整跑一遍建索引和查询

5.1 数据格式与编译准备

DiskANN 的社区版本是个命令行工具集，核心程序是建索引的build_diskann和查询的search_diskann，以及一些数据转换工具。数据格式最常用的是 fvecs：每条向量由 4 字节的 int32 维度和对应数量的 float 组成，也就是说每条记录先写维度，再写向量值。查询答案集用 ivecs 格式，同样是 int32 的 k 值加 k 个整数索引。

编译前需要装 CMake 和 C++ 编译器，机器最好支持 AVX2 指令集，这对距离计算速度影响很大。编译过程不复杂，Release 模式构建即可，几分钟就能出来，常见的 Linux 发行版基本没有额外依赖问题。

5.2 离线构建索引：核心命令与参数

构建索引是离线进行的，目标是把原始向量文件转换成图结构文件。典型命令长这样：

./build_diskann \ --data_type float \ --dist_fn l2 \ --data_file /data/vectors.fvecs \ --index_prefix /data/index/vamana \ --R 64 \ --L 120 \ --num_threads 32 \ --alpha 1.2

四个参数是调参重点。R 是图的最大出度，决定索引大小和召回上限，一般的起点是 64，追求更高召回可以到 96 或 128。L 是构建时用的搜索列表大小，通常取 R 的 1.5 到 2 倍，太小会导致插入时找不到足够好的近邻，图质量下降。alpha 是剪枝系数，建议从 1.0 到 1.5 之间试，默认场景 1.2 是个不容易出错的值。num_threads 直接决定构建耗时，机器核多就尽量拉满。

构建完成后，在指定前缀下会生成几个文件：图文件、压缩后的向量文件，以及一个记录 R、L、medoid 等元数据的文本文件。查询阶段需要这些文件一起在场。

5.3 召回评估与查询实践

带召回评估的查询命令如下，它会同时输出 recall@N 和延迟统计：

./search_diskann \ --data_type float \ --dist_fn l2 \ --index_prefix /data/index/vamana \ --query_file /data/query.fvecs \ --gt_file /data/query_gt.ivecs \ --recall_at 10 \ --result_path /data/results \ --num_threads 8 \ --L_search 100 \ --beamwidth 6

gt_file 是 ground truth 文件，就是每条查询向量在原始数据集上的真实 top-k 邻居索引，一般用暴力扫描小数据集生成。没有 gt 文件也能查询，只是拿不到召回率指标。L_search决定线上搜索强度，建议从 R 的值开始往上调；beamwidth控制在 4 到 10 之间，调太大可能反而因为排队导致延迟上升。

从命令行工具到生产服务，通常还要包一层。我看到不少团队的做法是写一个常驻的 C++ 服务，初始化时把索引 mmap 加载一次，之后每个请求调用搜索接口返回 topk；也可以借用各种语言绑定库直接封装。关键在于索引文件加载后是共享内存映射，多个查询线程可以并发复用，不会因为每次请求重新加载索引而拖垮吞吐。

5.4 压缩参数怎么选

DiskANN 支持在构建时启用 PQ 压缩，比如：

--use_pq_compress true --pq_dims 16 --pq_budget 32

pq_dims是量化的分段数，分段越多量化越细但压缩率越低；pq_budget是每段分配的字节数，一般取 1 或 2。如果不启用压缩，索引会保留全精度向量，召回理论上更稳，但磁盘占用和内存缓存压力都变大。我的建议是：数据集大、磁盘预算紧张，就开压缩，但一定要配重排；数据集中等，优先不开压缩，减少一个变量。

6. 实操中容易踩的坑与经验

6.1 别拿 HDD 跑 DiskANN

这一点必须放在最前面说。DiskANN 的所有设计都建立在 SSD 随机读能力之上，我拿同一份 5 亿向量索引做过对比：NVMe 上平均查询延迟 5 毫秒，SATA SSD 上直接掉到 30 毫秒以上，H 级机械盘基本没法看，超过 100 毫秒是常态。原因前面讲过，查询路径由大量小粒度随机读组成，NVMe 的并发 IOPS 能兜住这种访问模式，SATA 和 HDD 兜不住。所以预算再紧张，磁盘这块不能省。

6.2 量化压缩导致的"召回率幻觉"

PQ 压缩带来的量化误差会直接污染距离计算。如果压缩太狠、又没有重排，你会看到 recall 数字很虚——它只是"压缩空间里的召回"，换到全精度距离再算一次可能掉了好几个点。最靠谱的做法是留一小批带 ground truth 的测试集，把压缩索引的召回和全精度索引的召回分别跑一遍做对照。宁可压缩率保守一点，也不要上线之后被业务方拿真实案例打脸。

6.3 构建时间和空间要提前规划

十亿级数据的索引构建不是几分钟的事，可能需要几小时到一天，具体取决于 R、L、alpha 和机器核数。我第一次跑大索引时低估了临时空间占用，结果磁盘写满直接失败。构建过程中需要保留原始向量文件、图文件、压缩文件和临时排序文件，空间预算建议按"原始数据 1.5 倍 + 预留 20%"来算。另外，正式开跑之前先用一小块数据试参数，记录构建速度和索引大小，再线性外推到全量数据，这个估算比凭感觉靠谱得多。

6.4 更新机制要想清楚再动手

社区版 DiskANN 的强项是静态索引，动态增删能力弱。如果业务需要频繁写入新数据，直接拿它当主存储会很痛苦。我见过两种解决思路：一是分层架构，热数据放一个小内存索引，冷数据放 DiskANN，两层结果合并后重排；二是影子索引，定期重建一份新索引，切换时用版本号控制流量，做到平滑升级。简单说，把 DiskANN 当成"定期全量重建的离线索引底座"来用，比硬塞在线更新体验好得多。

最后分享一点我自己的落地体会。我这边在一个 20 亿向量的去重系统里最终使用的参数组合是：R=64，构建 L=120，搜索 L_search=150，alpha=1.2，PQ 压缩预算 16 字节/向量，配合一块 NVMe 盘，单机平均查询延迟稳定在 7 毫秒左右，top-10 召回率能做到 95% 以上。如果后续召回不达标，我通常会先加 L_search，这个操作不用重建索引，见效最快；再不行才考虑加大 R 并重建。DiskANN 真正适合的，就是"单机、数据量大、内存不够、能忍几毫秒"这片中间地带，希望这篇内容能帮你在选型时少走点弯路。