一、澄清索引和向量库的关系“向量库”本质上就是一个专门存储向量索引的数据库。组件说明原始向量数据每一条文本对应的浮点数数组索引结构HNSW的图、IVF的聚类中心、PQ的压缩码本 — 这些都是为了加速检索而额外构建和存储的数据结构二者关系索引是向量库的一部分就像书的目录是书的一部分所以“建索引” 在向量库里创建这些加速结构“索引在内存” 向量库把这些结构加载到 RAM 中“索引在磁盘” 向量库只在需要时从 SSD 读取二、索引到底存在哪里向量库的存储架构以 Milvus / Qdrant 为例向量库 ├── 原始向量数据 ──► 存储在磁盘.bin/.col 文件 │ │ │ └──► 查询时根据配置决定是否加载到内存 │ └── 索引结构 ──► 根据索引类型和配置决定存储位置 │ ├── HNSW图结构 (邻接表) — 默认全量加载到内存快 ├── IVF聚类中心 倒排列表 — 可配置内存或磁盘 └── PQ压缩码本 — 体积小通常放内存各索引类型的实际存储位置索引存储的物理内容典型位置原因Flat无索引只有原始向量磁盘查询时顺读不需要额外结构暴力计算HNSW多层图每个向量的邻居指针全量内存检索需要频繁随机访问邻居磁盘太慢IVF聚类中心 每个簇的向量 ID 列表可配置内存或磁盘检索时先算中心需内存再遍历簇可从磁盘读IVFPQ聚类中心 压缩码本 倒排 ID码本放内存倒排查磁盘PQ 压缩后内存很小倒排可放磁盘以节省内存三、为什么 HNSW 必须放在内存HNSW 的检索过程是从高层入口点开始沿着图结构反复跳跃到最近的邻居直到底层。这个过程需要极其频繁的随机访问访问某个向量的邻居列表。如果是磁盘 I/O一次查询可能触发几百上千次随机读延迟会从毫秒级变成秒级甚至分钟级。所以 HNSW 几乎总是要求全量加载到内存——这也是它内存消耗大的根本原因。四、为什么 IVF 可以放磁盘IVF 的检索过程是计算问题向量与聚类中心的距离 → 选出 Top-1 个簇需要内存在这个簇内遍历所有向量的 ID 列表可以从磁盘顺序读取关键区别第二步是顺序遍历一个簇不是 HNSW 那种随机跳跃。SSD 的顺序读取很快几十微秒/条所以 IVF 可以接受从磁盘读取向量。配置示例Milvus# IVF 索引数据放磁盘查询时按需加载 index_type: IVF_FLAT index_params: { nlist: 1024 } storage: disk # 可选memory、disk、mmap五、实战选型时的内存估算场景数据量 (1536 维 float32)FlatHNSWIVFIVFPQ原始向量存储100 万条~6.1 GB6.1 GB6.1 GB1.5 GB (PQ 8x 压缩)索引额外开销100 万条0~8-12 GB(图结构)~0.5-1 GB (聚类中心倒排)~0.5-1 GB总计内存占用100 万条6.1 GB (全磁盘)~14-18 GB~6.6-7.1 GB (混合)~2.0-2.5 GB命中延迟—200 ms8 ms50 ms60 ms选型逻辑内存充足 32 GB、要求极低延迟 →HNSW内存有限16 GB、中等延迟可接受 →IVF(混合存储)内存极有限4-8 GB、海量数据 →IVFPQ六、一句话总结索引是向量库的一部分可以配置在内存或磁盘上。HNSW 必须全量内存快但贵IVF/PQ 可以混合存储省内存但稍慢。选型的本质是内存预算 vs 延迟要求的权衡。